كيف تتكامل SCPs مع أذونات IAM

تخضع صلاحيات الوصول في المؤسسة إلى طبقتين: الحد الأقصى الذي تحدده SCP عبر AWS Organizations، وصلاحيات IAM الممنوحة داخل الحساب. ويُعد فهم كيفية تعاونهما من أكثر الأفكار قابلية للاختبار في مجال الحوكمة، لأن النتيجة تعتمد على توافقهما معًا.

القاعدة بسيطة لكنها صارمة: لا يُسمح بالإجراء إلا إذا كان مسموحًا به من قِبل كلٍّ من SCPs المعنية وIAM policies الخاصة بالحساب. الصلاحية الفعلية هي تقاطع الصلاحيات. لا تمنح SCP من دون IAM allow مطابق أي صلاحية؛ كما لا تمنح IAM allow المحظورة بواسطة SCP أي صلاحية.

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

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

لا يكون الطلب مسموحًا به إلا عندما تسمح كلٌّ من SCP وIAM policy بالإجراء، ولا يوجد منع صريح في أي موضع. يشبه منطق التقاطع هذا طريقة عمل permission boundaries، ويمكن تطبيق كليهما في الوقت نفسه لتضييق الصلاحيات أكثر.

في بيئة محكومة بالكامل، تتراكم عدة حدود: SCP (على مستوى الحساب)، وpermission boundary (على مستوى الهوية)، وأي session policy (على مستوى الجلسة)، وidentity policy (للمنح). الصلاحية الفعلية هي تقاطع جميع الحدود مع المنح، بعد طرح أي منع صريح.

لنفترض وجود IAM policy تمنح s3:* وec2:*، وpermission boundary تسمح بـ s3:* فقط، وSCP تسمح بـ s3:GetObject فقط. ستكون الصلاحية الفعلية هي s3:GetObject فقط، أي تقاطع الطبقات الثلاث. يقلص كل حد الصلاحيات أكثر.

في جميع الطبقات، يؤدي وجود منع صريح في أي policy أو SCP أو boundary أو session أو identity أو resource إلى حظر الإجراء فورًا. ولا يمكن لأي مجموعة من أذونات السماح تجاوزه. عند تحليل سيناريو، ابحث أولًا عن أي منع صريح؛ فإذا وجدته، فالإجابة هي الرفض.

يمكن للـ resource-based policies منح الوصول داخل الحساب نفسه بصورة مستقلة عن identity policy، لكن SCPs تظل تضع حدًا أقصى لحساب principal. أما في الوصول بين الحسابات، فتُطبق ضوابط الحسابين وسياسات الطرفين. يتسع نطاق قاعدة التقاطع، لكن الفكرة الأساسية تبقى كما هي: يجب أن يسمح كل حد من الحدود المنطبقة.

عندما يفشل الوصول بصورة غير متوقعة داخل مؤسسة، ابدأ من الداخل إلى الخارج: تأكد من أن identity policy تمنح الإجراء، ثم افحص permission boundary، ثم SCPs المطبقة على الحساب وكل OU أب، ثم أي session policy، وأخيرًا ابحث في جميع الطبقات عن منع صريح. أول حد لا يتضمن الإجراء، أو أي منع، هو سبب المشكلة.

تتعاون SCPs وIAM وفق التقاطع: يحتاج الإجراء إلى سماح من كليهما، إضافة إلى حدود boundary وsession إن وجدت، مع عدم وجود منع صريح في أي موضع. تقتصر SCPs وboundaries على التقييد؛ أما IAM policies فـتمنح الصلاحيات. للسماح بإجراء ما، يجب أن تسمح به كل الحدود، وأن يوجد منح واحد على الأقل.

اختبر منطق الجمع بين الصلاحيات.

تتعاون SCPs وIAM وفق التقاطع: لا يُسمح بالإجراء إلا إذا سمحت به كلتاهما، إضافة إلى حدود permission boundary وsession policy إن وجدت، مع عدم وجود منع صريح في أي موضع. تقتصر SCPs وboundaries على التقييد؛ أما IAM policies فـتمنح الصلاحيات. ويتغلب المنع الصريح في أي طبقة دائمًا على أي سماح.