تدفق اتخاذ قرار تقييم السياسات

عندما يصل أي طلب إلى AWS، يشغّل محرك IAM تدفق تقييم دقيقًا ليقرر السماح أو الرفض. يُعد حفظ هذا الترتيب من أكثر الأمور فائدة التي يمكنك فعلها لاختبار SCS-C02، لأن أسئلة السيناريو الصعبة تعتمد على معرفة نوع السياسة الذي تكون له الأولوية عند وجود عدة سياسات.

نقطة البداية دائمًا هي الرفض الضمني. إذا لم يمنح أي شيء في عملية التقييم صلاحية الوصول، فسيُرفض الطلب. يعني هذا النهج القائم على الرفض الافتراضي أنه يجب السماح صراحةً بإجراء ما في موضعٍ ما حتى ينجح؛ فالصمت يعني الرفض.

القاعدة الأهم على الإطلاق هي: إن وجود رفض صريح في أي موضع ضمن أي سياسة منطبقة يتجاوز كل Allow. وبغض النظر عن عدد العبارات التي تمنح الإجراء، فإن وجود Deny مطابق واحد يحظره. بهذه الطريقة تفرض الضوابط الوقائية وSCPs حدودًا صارمة لا يمكن للسياسات ذات المستوى الأدنى تجاوزها.

تُجري AWS التقييم بالترتيب المفاهيمي التالي: 1) البحث عن Deny صريح في أي سياسة (SCPs والحدود وسياسات الهوية والموارد والجلسة) — فإذا وُجد، يُرفض الطلب. 2) إذا انطبقت SCP ولم تسمح بالإجراء، يُرفض الطلب. 3) التحقق من حدود الصلاحيات وسياسات الجلسة وسياسات الهوية/المورد بحثًا عن Allow. وتؤدي أي فجوة إلى الرفض الضمني.

تحدد Service Control Policies (SCPs) في AWS Organizations الحد الأقصى للصلاحيات الخاصة بالحساب. يجب أن يكون الإجراء مسموحًا به من قِبل SCP ومن قِبل سياسة IAM حتى ينجح. لا تمنح SCPs صلاحية الوصول بمفردها؛ بل تضع حدًا أقصى للصلاحيات أو ترفضها فقط. وإذا لم تسمح SCP بإجراء ما، فلن تتمكن أي صلاحية Allow في IAM من إنقاذه.

حد الصلاحيات هو سياسة متقدمة تضع حدًا أقصى لصلاحيات مستخدم أو دور محدد. والصلاحيات الفعلية هي تقاطع الحد مع سياسة الهوية. وكما هي الحال مع SCPs، لا يمكن للحد إلا تقييد الصلاحيات؛ فهو لا يوسّع ما تمنحه السياسة المستندة إلى الهوية.

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

بالنسبة إلى الطلبات ضمن الحساب نفسه، يمكن لـ Allow مستند إلى المورد أن يمنح الوصول حتى من دون Allow مستند إلى الهوية (اتحاد الصلاحيات). أما في الطلبات بين الحسابات، فكلاهما مطلوب. وفي جميع الحالات، يظل أي Deny صريح في أي من هذه السياسات هو الغالب. وتشارك سياسة المورد في مسار التقييم العام نفسه.

لنفترض أن سياسة هوية تسمح بـ s3:DeleteObject، لكن SCP ترفض جميع إجراءات s3:Delete* في بيئة الإنتاج. النتيجة: مرفوض، لأن الرفض الصريح في SCP يتجاوز السماح في سياسة الهوية. وبالعكس، إذا سمحت SCP بالإجراء ولم تمنحه أي سياسة هوية، فسيُرفض أيضًا بسبب الرفض الضمني. يجب أن تتفق الطبقتان على السماح.

تجمع أسئلة الامتحان بين SCPs والحدود وسياسات الهوية والموارد، ثم تسأل عن النتيجة. والطريقة الموثوقة هي البحث أولًا عن أي رفض صريح، ثم التأكد من أن SCP تسمح، وأن الحد والجلسة يسمحان، وأن هناك Allow للهوية أو المورد. فإذا توافقت جميع هذه العناصر من دون رفض، فالإجابة هي السماح.

احتفظ بقائمة التحقق التالية: (1) هل يوجد رفض صريح؟ ارفض. (2) هل تسمح SCP؟ إذا لم تسمح، فارفض. (3) هل يسمح الحد/الجلسة؟ إذا لم يسمح، فارفض. (4) هل يوجد Allow للهوية أو المورد؟ إذا كان موجودًا ولم يوجد رفض، فاسمح؛ وإلا فهو رفض ضمني. طبّقها آليًا، وستصبح حتى الأسئلة التي تتضمن سياسات متعددة مباشرة وسهلة.

اختبر مسار التقييم.

يبدأ تقييم IAM بـالرفض الضمني، ويفوز الرفض الصريح دائمًا. للسماح بإجراء ما: يجب ألا يوجد رفض صريح في أي موضع، ويجب أن تسمح به SCP، وأن تسمح به حدود الصلاحيات وسياسات الجلسات (بوصفها تقاطعات)، وأن يوجد Allow للهوية أو المورد. تقتصر SCPs والحدود على التقييد؛ فهي لا تمنح الصلاحيات مطلقًا.