حوكمة الحسابات المتعددة والامتثال

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

ما الذي يغطيه هذا الموضوع

• بنية منظمة AWS: الجذر والوحدات التنظيمية وحساب الإدارة والحسابات الأعضاء، ومجموعتا الميزات
• قواعد وراثة سياسات SCP: الـ Allow التي تحتاج كل مستوى، والـ Deny التي يكفيها مستوى واحد، ودور FullAWSAccess في ذلك
• الاختيار بين قائمة السماح وقائمة المنع، وما لا تستطيع سياسات SCP تقييده، ومتى تكون سياسة RCP هي الجواب
• IAM Identity Center: أنواع المثيلات، ومصدر الهوية الواحد، والـ permission sets والتخصيصات وأدوار IAM التي تنتج عنها
• مُدد الجلسات، والتحكّم في الوصول بالسمات، والإدارة المفوَّضة وحدودها
• فحوص Trusted Advisor الأمنية: ما تفحصه فعلاً، وأثر خطة الدعم، وقواعد التحديث، وأتمتة المعالجة عبر EventBridge وSystems Manager
• AWS Config: مسجّل الإعدادات، وأنواع محفّزات القواعد وأوضاع تقييمها، والمعالجة الآلية، وحزم الامتثال، والنشر على مستوى المنظمة والمجمِّعات

لماذا هذا مهم

أسئلة هذا الموضوع في اختبار SOA-C03 نادراً ما تسألك عن تعريف. تعطيك تسلسلاً من جذر ووحدات تنظيمية وحسابات وتطلب منك توقّع نتيجة نداء واحد، أو تصف متطلّب امتثال وتضع أمامك أربع خدمات تبدو كلها معقولة. والفصل بينها هو المهارة: Trusted Advisor فحوص جاهزة تكتبها AWS، وConfig تعريفك أنت للصواب مع خطّ زمني، وسياسات SCP وقاية قبل وقوع الفعل.

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