الأمان والامتثال

مطوّر لا يستطيع الكتابة إلى bucket في S3، ولا أحد يعرف السبب. سياسة IAM المرتبطة بالدور تبدو صحيحة، ما يعني أن القرار اتُّخذ في مكان آخر: permissions boundary، أو سياسة SCP على مستوى المنظمة، أو سياسة الـ bucket نفسه، أو مفتاح KMS لم يمنح صلاحية فك التشفير أصلاً. هذا المجال يبني عندك القدرة على معرفة أين يُتخذ قرار التصريح فعلياً، وكيف تثبت لاحقاً أنه كان القرار الصحيح.

يحمل هذا المجال 16% من درجات اختبار SOA-C03، وهو أقل المجالات وزناً وأكثرها عرضة لأن يُستهان به. أعطال الأمان لا تبقى داخل حدودها: instance لا يصل إلى S3، ودالة Lambda تفشل عند استدعاء KMS، وstack يتراجع برسالة AccessDenied، كلها تبدو مشكلات في مجالات أخرى حتى تتتبع مسار السياسات.

ما الذي يغطيه هذا المجال

• مستخدمو IAM ومجموعاته وأدواره وأنواع السياسات، ومتى يحل الدور محل مفتاح وصول طويل العمر
• كيف تقيّم AWS أي طلب: الرفض الصريح، والسماح، وpermissions boundaries، وسياسات SCP، ومفاتيح الشروط
• MFA واتحاد الهوية وحماية حساب root ونظافة بيانات الاعتماد
• تشخيص إجراء مرفوض عبر IAM Access Analyzer وpolicy simulator وبيانات آخر وصول وسجلات CloudTrail
• AWS Organizations وسياسات التحكم في الخدمات، وإدارة وصول الموظفين مركزياً مع IAM Identity Center
• الامتثال المستمر عبر قواعد AWS Config وconformance packs، والتعامل مع فحوصات Trusted Advisor
• تصنيف البيانات مع Macie، والتشفير أثناء التخزين مع KMS، وشهادات TLS مع ACM، والأسرار في Secrets Manager وParameter Store
• اكتشاف التهديدات مع GuardDuty وInspector، وتجميع النتائج والاستجابة الآلية في Security Hub

لماذا هذا مهم

أسئلة هذا المجال نادراً ما تسألك ما هو IAM. تعطيك استدعاء API مرفوضاً مع أربعة أسباب محتملة، أو متطلب امتثال تستطيع عدة خدمات تلبيته، ثم تسألك أيها يناسب. الإجابة تتطلب إتقان الحدود بين الخدمات: Config يسجّل انحراف الإعدادات بينما GuardDuty يراقب السلوك، وInspector يفحص الثغرات بينما Security Hub يجمّع ما تجده الخدمات الأخرى.

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