المؤسسات والوحدات التنظيمية واستراتيجية SCP

تتيح AWS Organizations إدارة العديد من حسابات AWS مركزيًا باعتبارها بنية واحدة. وضمنها، تحدد Service Control Policies (SCPs) سقوف الصلاحيات، بينما تجمع Organizational Units (OUs) الحسابات لاستهدافها بالسياسات. ويُعد تصميم هذه البنية الهرمية جيدًا مهارة أساسية في مجال الحوكمة لاختبار SCS-C02.

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

تجمع Organizational Unit (OU) الحسابات التي تتشارك احتياجات الحوكمة، مثل OU باسم "Production" وOU باسم "Sandbox" وOU باسم "Security". ويؤدي إرفاق SCP بـ OU إلى تطبيقها على كل حساب داخله، لذلك نظّموا الحسابات وفقًا للسياسات التي ينبغي أن ترثها.

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

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

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

قاعدة أساسية: لا تمنح SCPs الصلاحيات أبدًا؛ فهي تحدد الحد الأقصى فقط. يجب أن يكون الإجراء مسموحًا به من قِبل كلٍّ من SCP وIAM policy في الحساب. تجعل SCP التي تستخدم قائمة السماح الخدمات متاحة لمنحها فحسب؛ ولا يزال على IAM منحها فعليًا.

لا تنطبق SCPs على حساب الإدارة، ولا تؤثر في الأدوار المرتبطة بالخدمات. كما أنها لا تمس في بعض الحالات المنح الواردة من resource-based policies خارج المؤسسة. يساعد فهم هذه الاستثناءات على تجنب الإجابات الخاطئة عندما يتوقع السيناريو أن تمنع SCP شيئًا لا يمكنها منعه.

تمنع SCPs الوقائية الشائعة مغادرة المؤسسة (organizations:LeaveOrganization)، كما تمنع حسابات الأعضاء من تعطيل خدمات الأمان مثل GuardDuty وSecurity Hub وConfig وCloudTrail. وعند تطبيقها على الجذر، تضمن هذه السياسات ألا يتمكن أي حساب عضو من الانفصال عن الحوكمة أو تعطيل قدرة المؤسسة على الكشف، وهو خط أساس موصى به بشدة.

تصميم نموذجي: SCP أساسية تستخدم قائمة المنع على مستوى الجذر (لحماية CloudTrail ومنع مغادرة المؤسسة وتقييد المناطق)، وSCPs أكثر تشددًا على OU الخاصة بـ Production، وأخرى أكثر مرونة على OU الخاصة بـ Sandbox. يتيح تجميع الحسابات حسب مستوى المخاطر في OUs ضبط الحوكمة بدقة مع الحد الأدنى من تشتت السياسات.

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

اختبر استراتيجيتك في استخدام SCP.

تجمع AWS Organizations الحسابات في OUs تحت جذر وحساب إدارة. تنتقل SCPs بالتوارث إلى أسفل الشجرة، وتتطلب سماحًا في كل مستوى؛ وأي منع يحظر الإجراء. استخدم استراتيجية قائمة المنع (مرنة) أو قائمة السماح (صارمة). تضع SCPs حدًا أقصى فقط ولا تمنح الصلاحيات أبدًا، ولا تنطبق على حساب الإدارة أو الأدوار المرتبطة بالخدمات.