كيفية أتمتة تنسيق حقوق الوصول داخل حاويات AWS S3

منذ سنوات ، عندما كانت خوادم Unix المحلية المزودة بأنظمة ملفات كبيرة أمرًا مهمًا ، كانت الشركات تبني قواعد واستراتيجيات شاملة لإدارة المجلدات لإدارة حقوق الوصول إلى مجلدات مختلفة لأشخاص مختلفين.

عادةً ما يخدم النظام الأساسي للمؤسسة مجموعات مختلفة من المستخدمين ذوي الاهتمامات المتميزة تمامًا أو قيود مستوى السرية أو تعريفات المحتوى. في حالة المؤسسات العالمية ، قد يعني هذا أيضًا فصل المحتوى بناءً على الموقع ، أي بشكل أساسي ، بين المستخدمين الذين ينتمون إلى بلدان مختلفة.

قد تشمل الأمثلة النموذجية الأخرى ما يلي:

• فصل البيانات بين بيئات التطوير والاختبار والإنتاج
• محتوى المبيعات لا يمكن الوصول إليه من قبل جمهور عريض
• المحتوى التشريعي الخاص بكل بلد والذي لا يمكن رؤيته أو الوصول إليه من داخل منطقة أخرى
• المحتوى المرتبط بالمشروع حيث يتم توفير "بيانات القيادة" لمجموعة محدودة من الأشخاص وما إلى ذلك.

هناك قائمة يحتمل أن لا تنتهي من مثل هذه الأمثلة. النقطة المهمة هي أن هناك دائمًا نوع من الحاجة لتنظيم حقوق الوصول إلى الملفات والبيانات بين جميع المستخدمين الذين يوفر النظام الأساسي الوصول إليهم.

في حالة الحلول داخل الشركة ، كانت هذه مهمة روتينية. قام مسؤول نظام الملفات بإعداد بعض القواعد ، واستخدم أداة من اختيارك ، ثم تم تعيين الأشخاص في مجموعات مستخدمين ، وتم تعيين مجموعات المستخدمين في قائمة المجلدات أو نقاط التحميل التي يمكنهم الوصول إليها. على طول الطريق ، تم تحديد مستوى الوصول للقراءة فقط أو الوصول للقراءة والكتابة.

الآن بالنظر إلى منصات AWS السحابية ، من الواضح أن نتوقع أن يكون لدى الأشخاص متطلبات مماثلة لقيود الوصول إلى المحتوى. ومع ذلك ، يجب أن يكون حل هذه المشكلة مختلفًا الآن. لم تعد الملفات تقاوم على خوادم Unix ولكن في السحابة (ومن المحتمل الوصول إليها ليس فقط للمؤسسة بأكملها ولكن حتى للعالم بأسره) ، ولا يتم تخزين المحتوى في مجلدات ولكن في حاويات S3.

الموصوفة أدناه هي بديل للتعامل مع هذه المشكلة. إنه مبني على تجربة العالم الحقيقي التي مررت بها أثناء تصميم مثل هذه الحلول لمشروع ملموس.

نهج بسيط ولكن شائع يدويا

طريقة واحدة لحل هذه المشكلة دون أي أتمتة هي طريقة مباشرة وبسيطة نسبيًا:

• أنشئ دلوًا جديدًا لكل مجموعة مميزة من الأشخاص.
• قم بتعيين حقوق الوصول إلى الحاوية حتى تتمكن هذه المجموعة المحددة فقط من الوصول إلى حاوية S3.

هذا بالتأكيد ممكن إذا كان الشرط هو الذهاب مع حل بسيط وسريع للغاية. ومع ذلك ، هناك بعض الحدود التي يجب أن تكون على دراية بها.

افتراضيًا ، لا يمكن إنشاء سوى ما يصل إلى 100 حاوية S3 ضمن حساب AWS واحد. يمكن تمديد هذا الحد إلى 1000 عن طريق إرسال زيادة في حد الخدمة إلى بطاقة AWS. إذا لم تكن هذه الحدود أمرًا يثير قلق حالة التنفيذ الخاصة بك ، فيمكنك السماح لكل مستخدم من مستخدمي المجال المميز الخاص بك بالعمل في حاوية S3 منفصلة والاتصال بها يوميًا.

قد تنشأ المشاكل إذا كانت هناك مجموعات من الأشخاص لديهم مسؤوليات متعددة الوظائف أو ببساطة بعض الأشخاص الذين يحتاجون إلى الوصول إلى محتوى المزيد من المجالات في نفس الوقت. علي سبيل المثال:

• يقوم محللو البيانات بتقييم محتوى البيانات لعدة مناطق ومناطق مختلفة ، إلخ.
• شارك فريق الاختبار الخدمات التي تخدم فرق التطوير المختلفة.
• يتطلب الإبلاغ عن المستخدمين إنشاء تحليل لوحة القيادة فوق البلدان المختلفة داخل نفس المنطقة.

كما قد تتخيل ، يمكن أن تنمو هذه القائمة مرة أخرى بقدر ما تتخيل ، ويمكن لاحتياجات المؤسسات أن تولد جميع أنواع حالات الاستخدام.

كلما زادت تعقيد هذه القائمة ، زادت الحاجة إلى تنسيق حقوق الوصول الأكثر تعقيدًا لمنح جميع هذه المجموعات المختلفة حقوق وصول مختلفة إلى حاويات S3 المختلفة في المؤسسة. ستكون هناك أدوات إضافية مطلوبة ، وربما سيحتاج مورد مخصص (مسؤول) إلى الحفاظ على قوائم حقوق الوصول وتحديثها كلما طُلب أي تغيير (والذي سيكون في كثير من الأحيان ، خاصة إذا كانت المنظمة كبيرة).

إذن ، كيف نحقق نفس الشيء بطريقة أكثر تنظيماً وتلقائية؟

تقديم علامات للجرافات

إذا لم ينجح نهج الحاوية لكل مجال ، سينتهي أي حل آخر بحاويات مشتركة لمزيد من مجموعات المستخدمين. في مثل هذه الحالات ، من الضروري بناء منطق كامل لتعيين حقوق الوصول في بعض المناطق التي يسهل تغييرها أو تحديثها ديناميكيًا.

تتمثل إحدى طرق تحقيق ذلك في استخدام العلامات في حاويات S3. يوصى باستخدام العلامات في أي حال (إذا لم يكن هناك شيء سوى لتمكين تصنيف الفواتير بشكل أسهل). ومع ذلك ، يمكن تغيير العلامة في أي وقت في المستقبل لأي مجموعة.

إذا تم إنشاء المنطق بالكامل استنادًا إلى علامات الحاوية والباقي وراء التكوين يعتمد على قيم العلامات ، فإن الخاصية الديناميكية مضمونة حيث يمكن للمرء إعادة تعريف الغرض من الحاوية فقط عن طريق تحديث قيم العلامة.

ما نوع العلامات التي يجب استخدامها لإنجاح هذا؟

هذا يعتمد على حالة الاستخدام الملموسة الخاصة بك. علي سبيل المثال:

• يمكن أن تكون هناك حاجة لفصل الجرافات حسب نوع البيئة. لذلك ، في هذه الحالة ، يجب أن يكون أحد أسماء العلامات شيئًا مثل "ENV" وبقيم محتملة مثل "DEV" و "TEST" و "PROD" وما إلى ذلك.
• ربما تريد فصل الفريق على أساس البلد. في هذه الحالة ، ستكون علامة أخرى هي "COUNTRY" وتقدر اسم بلد ما.
• أو قد ترغب في فصل المستخدمين بناءً على القسم الوظيفي الذي ينتمون إليه ، مثل محللي الأعمال ومستخدمي مستودعات البيانات وعلماء البيانات وما إلى ذلك ، لذا يمكنك إنشاء علامة باسم "USER_TYPE" والقيمة ذات الصلة.
• قد يكون الخيار الآخر هو أنك تريد تحديد بنية مجلد ثابتة بشكل صريح لمجموعات مستخدمين معينة مطلوب منهم استخدامها (لعدم إنشاء مجلدات فوضى خاصة بهم وتضيع هناك بمرور الوقت). يمكنك القيام بذلك مرة أخرى باستخدام العلامات ، حيث يمكنك تحديد العديد من أدلة العمل مثل: "البيانات / الاستيراد" ، "البيانات / المعالجة" ، "البيانات / الخطأ" ، إلخ.

من الناحية المثالية ، تريد تحديد العلامات بحيث يمكن دمجها منطقيًا وجعلها تشكل بنية مجلد كاملة في الحاوية.

على سبيل المثال ، يمكنك دمج العلامات التالية من الأمثلة أعلاه لإنشاء بنية مجلد مخصصة لأنواع مختلفة من المستخدمين من بلدان مختلفة مع مجلدات استيراد محددة مسبقًا من المتوقع أن يستخدموها:

• / <ENV> / <USER_TYPE> / <البلد> / <تحميل>

فقط عن طريق تغيير قيمة <ENV> ، يمكنك إعادة تحديد الغرض من العلامة (سواء تم تخصيصها لاختبار النظام البيئي لبيئة التشغيل ، أو dev ، أو prod ، وما إلى ذلك)

سيمكن هذا من استخدام نفس المجموعة للعديد من المستخدمين المختلفين. لا تدعم الحزم المجلدات بشكل صريح ، لكنها تدعم "التصنيفات". تعمل هذه التسميات مثل المجلدات الفرعية في النهاية لأن المستخدمين يحتاجون إلى المرور بسلسلة من التسميات للوصول إلى بياناتهم (تمامًا كما يفعلون مع المجلدات الفرعية).

أنشئ سياسات ديناميكية وخريطة علامات دلو بالداخل

بعد تحديد العلامات في شكل قابل للاستخدام ، فإن الخطوة التالية هي بناء سياسات حاوية S3 التي قد تستخدم العلامات.

إذا كانت السياسات تستخدم أسماء العلامات ، فأنت تنشئ شيئًا يسمى "السياسات الديناميكية". يعني هذا أساسًا أن سياستك ستتصرف بشكل مختلف بالنسبة للحاويات ذات قيم العلامات المختلفة التي تشير إليها السياسة في النموذج أو العناصر النائبة.

من الواضح أن هذه الخطوة تتضمن بعض الترميز المخصص للسياسات الديناميكية ، ولكن يمكنك تبسيط هذه الخطوة باستخدام أداة محرر سياسة Amazon AWS ، والتي ستوجهك خلال العملية.

في السياسة نفسها ، ستحتاج إلى ترميز حقوق الوصول الملموسة التي يجب تطبيقها على الحاوية ومستوى الوصول لهذه الحقوق (قراءة ، كتابة). سيقرأ المنطق العلامات الموجودة على الحاويات وسيبني بنية المجلد على الحاوية (إنشاء ملصقات بناءً على العلامات). بناءً على القيم الملموسة للعلامات ، سيتم إنشاء المجلدات الفرعية ، وسيتم تعيين حقوق الوصول المطلوبة على طول الخط.

الشيء الجميل في مثل هذه السياسة الديناميكية هو أنه يمكنك إنشاء سياسة ديناميكية واحدة فقط ثم تعيين نفس السياسة الديناميكية للعديد من المجموعات. ستعمل هذه السياسة بشكل مختلف بالنسبة للمجموعات ذات قيم العلامات المختلفة ، ولكنها ستكون دائمًا جنبًا إلى جنب مع توقعاتك لحاوية بها قيم العلامات هذه.

إنها طريقة فعالة حقًا لإدارة تعيينات حقوق الوصول بطريقة منظمة ومركزية لعدد كبير من الحاويات ، حيث يُتوقع أن تتبع كل مجموعة بعض هياكل القوالب المتفق عليها مسبقًا وسيستخدمها المستخدمون داخل المنظمة بأكملها.

أتمتة إعداد الكيانات الجديدة

بعد تحديد السياسات الديناميكية وتخصيصها للحاويات الموجودة ، يمكن للمستخدمين البدء في استخدام نفس المستودعات دون المخاطرة بأن المستخدمين من المجموعات المختلفة لن يصلوا إلى المحتوى (المخزن في نفس الحاوية) الموجود ضمن بنية مجلد حيث لا يملكون التمكن من.

أيضًا ، بالنسبة لبعض مجموعات المستخدمين التي تتمتع بوصول أوسع ، سيكون من السهل الوصول إلى البيانات لأنه سيتم تخزينها جميعًا في نفس المجموعة.

تتمثل الخطوة الأخيرة في جعل عملية إعداد مستخدمين جدد ، ومجموعات جديدة ، وحتى علامات جديدة بسيطة قدر الإمكان. يؤدي هذا إلى ترميز مخصص آخر ، والذي ، مع ذلك ، لا يحتاج إلى التعقيد المفرط ، بافتراض أن عملية الإعداد الخاصة بك تحتوي على بعض القواعد الواضحة جدًا التي يمكن تغليفها بمنطق خوارزمية بسيط ومباشر (على الأقل يمكنك أن تثبت بهذه الطريقة أن العملية لها بعض المنطق ولا يتم إجراؤها بطريقة فوضوية للغاية).

يمكن أن يكون هذا بسيطًا مثل إنشاء برنامج نصي قابل للتنفيذ بواسطة أمر AWS CLI مع المعلمات اللازمة لإدخال كيان جديد بنجاح في النظام الأساسي. يمكن أن تكون سلسلة من نصوص CLI ، قابلة للتنفيذ بترتيب معين ، مثل ، على سبيل المثال:

• create_new_bucket (<ENV> ، <ENV_VALUE> ، <COUNTRY> ، <COUNTRY_VALUE> ، ..)
• create_new_tag (<bucket_id> ، <tag_name> ، <tag_value>)
• update_existing_tag (<bucket_id> ، <tag_name> ، <tag_value>)
• create_user_group (<user_type>، <country>، <env>)
• إلخ.

تحصل على هذه النقطة.

نصيحة احترافية

هناك نصيحة احترافية واحدة إذا كنت ترغب في ذلك ، والتي يمكن تطبيقها بسهولة فوق ما سبق.

يمكن الاستفادة من السياسات الديناميكية ليس فقط لتعيين حقوق الوصول لمواقع المجلدات ولكن أيضًا لتعيين حقوق الخدمة للحاويات ومجموعات المستخدمين تلقائيًا!

كل ما هو مطلوب هو توسيع قائمة العلامات على الحاويات ثم إضافة حقوق وصول ديناميكية للنهج لاستخدام خدمات محددة لمجموعات محددة من المستخدمين.

على سبيل المثال ، قد يكون هناك مجموعة من المستخدمين الذين يحتاجون أيضًا إلى الوصول إلى خادم كتلة قاعدة البيانات المحدد. يمكن تحقيق ذلك بلا شك من خلال سياسات ديناميكية تستفيد من مهام المجموعة ، خاصة إذا كانت عمليات الوصول إلى الخدمات مدفوعة بنهج قائم على الدور. ما عليك سوى إضافة جزء إلى رمز السياسة الديناميكي ، والذي سيعالج العلامات المتعلقة بمواصفات مجموعة قاعدة البيانات وتعيين امتيازات الوصول إلى السياسة إلى مجموعة قواعد البيانات ومجموعة المستخدمين هذه مباشرةً.

بهذه الطريقة ، سيكون إعداد مجموعة مستخدمين جديدة قابلاً للتنفيذ فقط من خلال هذه السياسة الديناميكية الفردية. علاوة على ذلك ، نظرًا لكونها ديناميكية ، يمكن إعادة استخدام نفس السياسة لإلحاق العديد من مجموعات المستخدمين المختلفة (من المتوقع أن تتبع نفس النموذج ولكن ليس بالضرورة نفس الخدمات).

يمكنك أيضًا إلقاء نظرة على أوامر AWS S3 هذه لإدارة الحاويات والبيانات.