تفويض إنشاء الأدوار بأمان

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

من دون وسائل حماية، يُعد منح شخص ما iam:CreateRole وiam:AttachRolePolicy بمثابة منحه صلاحيات المسؤول عمليًا. إذ يمكنه إنشاء دور يتضمن AdministratorAccess ثم توليه. ومسار تصعيد الصلاحيات هذا هو ما يجب على التفويض الآمن إغلاقه، مع الاستمرار في السماح بإنشاء الأدوار المشروع.

الحل هو اشتراط إرفاق حد صلاحيات معين بأي دور ينشئه مستخدم مفوَّض. وحتى إذا أرفق المستخدم AdministratorAccess بالدور الجديد، فسيضع الحد سقفًا لصلاحياته الفعلية. ولن يتمكن الدور المنشأ من تجاوز ما يسمح به الحد، مما يلغي خطر التصعيد.

تستخدم سياسة التفويض الآمن فحصي شرط: يضمن أحدهما أن الدور الجديد يحمل الحد المطلوب (عبر iam:PermissionsBoundary)، بينما يقيّد الآخر قدرة المستخدم على تعديل الحد أو حذفه. وكلاهما مطلوب، وإلا فقد يتمكن مطور بارع من إزالة الحد ببساطة بعد ذلك.

يفرض هذا الشرط إرفاق الحد المحدد بكل استدعاء CreateRole. وبدونه، يُرفض إجراء الإنشاء.

يجب أيضًا منع المستخدم المفوَّض من تحرير سياسة الحد أو فصله عن الأدوار. أضيفوا عبارات Deny صريحة لإجراءات مثل iam:DeleteRolePermissionsBoundary وiam:CreatePolicyVersion مقابل ARN الخاص بالحد. وإلا يمكن إزالة وسيلة الحماية بهدوء، مما يُفشل التصميم بأكمله.

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

حتى مع وجود حد، راقبوا سياسة الثقة الخاصة بالدور الجديد. فقد ينشئ المطور دورًا يثق بحساب خارجي. قيّدوا الجهات الرئيسية الموثوقة التي يمكنه تعيينها، أو ادمجوا التفويض مع SCPs وAccess Analyzer لاكتشاف الثقة الخارجية غير المتوقعة ومنعها.

عند تنفيذ التفويض بصورة صحيحة، تحصل الفرق على خدمة ذاتية حقيقية: إذ تنشئ الأدوار وتديرها بحرية ضمن الحد، بينما يطمئن فريق الأمان إلى عدم تمكن أي دور من تجاوز السقف. وهذا التوازن بين السرعة والأمان هو بالضبط ما يريد منكم اختبار SCS-C02 تصميمه.

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

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

اختبر التفويض الآمن.

يعني تفويض إنشاء أدوار IAM بأمان اشتراط حد صلاحيات لكل دور يتم إنشاؤه عبر شرط iam:PermissionsBoundary، ومنع التغييرات على ذلك الحد، وتحديد مسارات وأسماء الأدوار، وتقييد سياسات الثقة في الأدوار الجديدة. اقرنوا ذلك مع SCPs لفرض سقوف على مستوى الحساب وإغلاق مسارات تصعيد الصلاحيات مع تمكين الخدمة الذاتية.