ما الذي يحدّه حدّ الأذونات

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

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

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

تسمح سياسة الحد هذه بإجراءات S3 وCloudWatch فقط. وبغض النظر عما تنص عليه سياسة الهوية، لا يمكن للمستخدم تجاوز هاتين الخدمتين.

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

يضع كل من الحدود وSCPs سقفًا للصلاحيات، لكنهما يختلفان في النطاق. ينطبق حد الصلاحيات على مستخدم أو دور واحد ويتم تعيينه داخل IAM. أما SCP فينطبق على حسابات كاملة داخل مؤسسة. ويختبر الامتحان اختيار الأداة المناسبة: استخدموا الحد لكل هوية، وSCP على مستوى الحساب.

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

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

من النقاط التي يختبرها الامتحان: تحد حدود الصلاحيات ما يمكن لسياسات الهوية المستندة إلى الهوية تنفيذه، لكنها لا تحد في بعض الحالات الوصول الذي تمنحه سياسة مستندة إلى الموارد لذلك الكيان الرئيسي. لذلك، قد يظل دور يقتصر حده على S3 قادرًا على الحصول على وصول إلى SQS من خلال سياسة قائمة الانتظار. صمموا مع مراعاة هذه الفجوة.

لفرض إرفاق حد دائمًا بالكيانات الرئيسية المفوَّضة، تكتبون سياسة صلاحيات تتضمن شرطًا يفرض أن تساوي iam:PermissionsBoundary مع ARN لحد معين في أي دور ينشئونه. ويمنع ذلك المطور من إنشاء أدوار بلا وسيلة الحماية، مما يغلق ثغرة التفويض.

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

اختبر منطق حدود الصلاحيات.

يحدد حد الصلاحيات الحد الأقصى لصلاحيات مستخدم أو دور واحد؛ ويكون الوصول الفعلي هو تقاطع الحد وسياسة الهوية. ولا يمنح الحد صلاحيات بمفرده، كما يظل الرفض الصريح متغلبًا على كل شيء. والغرض الأساسي منه هو التفويض الآمن، الذي يُفرض باستخدام شرط iam:PermissionsBoundary.