حدود الأذونات في AWS للمبتدئين

حدود الصلاحيات في AWS مربكة. أعرف أنها مربكة لأنها أربكتني، واستغرق مني الأمر عامين تقريبًا لفهمها. وأعرف أيضًا أنها مربكة لأن Corey Quinn قال ذلك، وطلب من أحدهم أن يجعلها أقل إرباكًا.

من المرجح أن أفشل، لكن لنبدأ.

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

إن وثائق AWS الرسمية تتضمن تفاصيل كثيرة، لكنها تبقى مربكة نوعًا ما. الغرض من هذه المقالة هو مساعدتك على فهم المفاهيم وسبب وجودها، لا الإلمام بتفاصيل كتابتها (مع استثناء واحد).

افترض أنني في الصف الخامس، لا مبتدئ تمامًا، واشرحها لي مرة أخرى

حسنًا، ما دمت تصر.

قبل وجود حدود صلاحيات IAM كان من الصعب جدًا السماح لشخص بإدارة صلاحيات IAM الخاصة بموارده دون التسبب في مشكلة أمنية بمنح صلاحيات مفرطة لشيء مثل مثيل EC2 أو… لنفسه. وكانت المشكلة تظهر غالبًا عندما تريد السماح له بكتابة سياسات IAM ثم إسنادها. إنها مشكلة الإدارة المفوَّضة. ”دع شخصًا يدير بعض الأمور المتعلقة بـ IAM لكن ليس تلك الأمور“.

هذا سيناريو شائع جدًا. كثيرًا ما ينشئ المطورون دورًا لمثيل أو دالة lambda أو مهمة حاوية ضمن حزمة تطبيقاتهم ثم يسندون إلى ذلك الدور صلاحيات. وقد يكون الأمر بسيطًا مثل السماح لمثيل بقراءة بيانات من حاوية S3. وتبين أن التعامل مع هذا صعب من منظور أمني:

• إذا سمحت للمطور بكتابة سياساته الخاصة، فقد يضيف صلاحيات مفرطة… مثل ‎*.*‎.
• إذا سمحت للمطور بإسناد السياسات، فقد يرفق سياسة قائمة تمنح صلاحيات أكثر من اللازم.
• وإذا سمحت للمطور بإنشاء دور جديد وإسناد سياسة إليه… تواجهك المشكلات نفسها.

نعم، يمكنك أن تترك فريق الأمن أو مسؤولًا رفيع المستوى يتولى كل هذا، لكن ذلك غير فعّال. تتيح لك حدود الصلاحيات وجود مستويين من مسؤولي IAM: المستوى الأعلى الذي يتحمل المسؤولية الأمنية الشاملة، والمستوى الأدنى الذي يتولى الأعمال اليومية.

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

لست متأكدًا أن هذا شرح لطالب في الصف الخامس، لكن ربما تعطيني مثالًا

Alice هي المسؤولة العليا عن مؤسسة على AWS. عليها الإشراف على مئات الحسابات، ولكل حساب مسؤولوه المحليون ومطوروه الذين يقومون ببناء التطبيقات فعليًا.

Bob هو أحد هؤلاء المطورين المحليين. يبني Bob تطبيقًا جديدًا، ومن الأكفأ أن ينشئ أدواره وسياساته بنفسه لأنه يعرف ما يحتاجه تطبيقه.

تقرر Alice السماح لـ Bob بإدارة IAM لأجزاء من تطبيقه. وتحديدًا:

• يستطيع Bob كتابة سياسات IAM جديدة وإسنادها بالصلاحيات التي تحتاجها مثيلاته ودوال lambda الخاصة به.
• هناك خدمات AWS أخرى قيد الاستخدام يجب ألا تمسها تلك المكوّنات إطلاقًا. لذا لا يمكنك ببساطة تعطيلها عبر سياسة تحكم بالخدمات، فذلك سيعطل تلك الخدمات على المكوّنات المسموح لها باستخدامها.
• لا يُسمح لـ Bob بإسناد سياسة جديدة لنفسه.

إنها حالة كلاسيكية للإدارة المفوَّضة: يُسمح لـ Bob بإدارة جزء من IAM فقط. هنا تستخدم حد الصلاحيات:

• تنشئ Alice حد صلاحيات ”A“ يسمح بالصلاحيات الخاصة بخدمات AWS التي يمكن لمثيلات Bob ودوال lambda التواصل معها (مثل S3 وSNS وSQS).
• تنشئ Alice حد صلاحيات ”B“ يسمح لـ Bob بإنشاء أدوار وسياسات IAM (وإسنادها) لكن دون إسنادها لنفسه.
• تمنح Alice لـ Bob صلاحيات IAM لإنشاء أدوار وسياسات جديدة وإسنادها، لكن يجب أن يحمل أي دور جديد حد الصلاحيات ”A“. وهذا يعني أن تلك المثيلات ودوال lambda لن تحصل أبدًا على صلاحيات تتجاوز ما في الحد، لكن يمكن أن تحصل على أقل منه.
• تسند Alice حد الصلاحيات ”B“ إلى Bob لمنعه من إسناد صلاحيات لنفسه. وبذلك لا يستطيع إلغاء الاشتراط الذي يلزمه بنشر الموارد وهي تحمل ”A“.

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

ذكّرني مرة أخرى لماذا لا تصلح سياسة التحكم بالخدمات هنا

أحيانًا قد تصلح سياسة SCP، لكنك لا تستطيع استخدامها إلا إذا كنت ضمن مؤسسة، في حين يعمل حد الصلاحيات في أي حساب. كذلك فإن سياسات SCP جيدة جدًا لأمور مثل تقييد استدعاءات API التي يمكن إجراؤها (وبالتالي خدمات AWS التي يمكن استخدامها)، لكنها ليست مصمَّمة فعليًا لهذا المستوى من التفصيل والشروط.

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

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

ألا يمكنني الاكتفاء بسياسات الرفض

ليس فعلًا. جرّبنا ذلك قبل وجود حدود الصلاحيات، وإلى جانب التعقيد، كانت الثغرات كثيرة جدًا.

هل يمكن الحصول على مثال بسيط آخر

بالتأكيد! إليك مثالًا نستخدمه نحن أنفسنا.

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

أظنني فهمت، لكن كيف تتفاعل كل سياسات IAM هذه

راجع وثائق AWS الخاصة بمنطق تقييم السياسات، لكن إليك ملاحظاتي المختصرة:

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

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

ذكّرني مرة أخرى متى أستخدم حدود الصلاحيات

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

وحتى عند استخدام أدوات IAM المتقدمة مثل حلنا الجديد FireMon Authorization Control، فقد تظل بحاجة إلى بعض حدود الصلاحيات، لا سيما في الحسابات شديدة الحساسية.

ما المثال الوحيد الذي قلتم إنكم ستضمّنونه؟

مع أن حدود الأذونات تهدف إلى منعكم من القيام ببعض الأمور، فإنها لا تزال تتطلب منكم تحديد جميع أذونات السماح. بعبارة أخرى، إذا كتبتم حد أذونات يتضمن عبارة DENY لحظر الأمر الوحيد الذي لا تريدون أن يقوم به ذلك المستخدم/الدور، فستظلون بحاجة إلى عبارة ALLOW * وإلا فلن يتمكنوا من فعل أي شيء.

هذا هو الجزء الذي أربكني في البداية، إذ أسأتُ قراءة وصف Amazon وظننتُ أنه يمكن استخدام حد الأذونات لحظر الإجراءات فحسب. هذا ممكن، لكن باستثناء حالة استخدام تتعلق بسياسة الموارد لا أرغب في الخوض فيها اليوم، يجب أن يتضمن حد الأذونات أيضًا كل ما تريدون السماح به. لا يمكنكم ببساطة رفض DENY أمر واحد في حد الأذونات والسماح ALLOW بأمور أخرى في سياسة أذونات IAM الاعتيادية وتوقّع أن ينجح ذلك. يجب أن يتضمن حد الأذونات أيضًا عبارات ALLOW (ونعم، أنا أحتال قليلًا وأستخدم ALLOW * هنا في بعض الأحيان).

لا يزال الأمر غير واضح بالنسبة لي

أرسلوا لي بريدًا إلكترونيًا. بصراحة، هذه الأمور مربكة فعلًا.