ما هو دور IAM فعلًا

دور IAM هو هوية يمكنك تولّيها للحصول على مجموعة من الصلاحيات، لكنه بخلاف المستخدم لا يملك بيانات اعتماد دائمة. فعندما يتولى كيان دورًا، تصدر AWS بيانات اعتماد أمنية مؤقتة تنتهي صلاحيتها بعد مدة محددة. وتُعد الأدوار الطريقة الآمنة والحديثة لمنح الوصول إلى AWS، وتظهر في مواضع كثيرة من اختبار SCS-C02.

يتكوّن كل دور من جزأين من السياسات:

• سياسة ثقة (تُسمى أيضًا سياسة assume-role) توضّح من المسموح له بتولّي الدور.
• سياسة صلاحيات واحدة أو أكثر توضّح ما الذي يمكن للدور فعله بعد تولّيه.

ويُعد هذا الفصل جوهر تمكين الأدوار للتفويض الآمن: إذ تحدد من يُسمح له باستعارة الهوية، وتحدد بشكل منفصل ما الذي يُسمح لتلك الهوية بفعله.

عند تولّي دور، تصدر خدمة Security Token Service (STS) مجموعة بيانات اعتماد تتضمن معرّف مفتاح وصول، ومفتاحًا سريًا، ورمز جلسة، وتظل جميعها صالحة لفترة محدودة (من 15 دقيقة إلى 12 ساعة). وبما أنها تنتهي تلقائيًا، تصبح بيانات الاعتماد المؤقتة المسربة عديمة الفائدة بسرعة، مما يقلل المخاطر بدرجة كبيرة مقارنة بمفاتيح الوصول طويلة الأجل.

تسرد سياسة الثقة principals المسموح لها بتولّي الدور. ويمكن أن تكون:

• خدمة AWS (مثل EC2 أو Lambda) لمنح حمل عمل هوية.
• مستخدم أو دور IAM في الحساب نفسه أو في حساب آخر للوصول بين الحسابات.
• هوية federated من موفّر SAML أو OIDC.

إذا لم يُذكر principal في سياسة الثقة، فلن يتمكن مطلقًا من تولّي الدور، مهما سمحت سياسات الصلاحيات.

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

فيما يلي مقتطف من سياسة ثقة تسمح لخدمة EC2 بتولّي دور. يحدد Principal من يمكنه تولّي الدور، ويكون الإجراء دائمًا sts:AssumeRole.

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

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

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

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

استخدم دورًا كلما احتاج حمل عمل إلى الوصول إلى AWS، أو عندما يجب على حساب أن يتصرف في حساب آخر، أو عندما تتم مصادقة البشر عبر موفّر خارجي. وتُعد الأدوار إجابةً عن معظم أسئلة الاختبار من نوع «كيف أمنح الوصول من دون مفاتيح طويلة الأجل؟». فهي تجمع بين سياسة الثقة (من) وسياسات الصلاحيات (ما) لتوفير وصول آمن ومؤقت وقابل للتدقيق.

تأكد من فهمك للأدوار.

دور IAM هو هوية بلا بيانات اعتماد يتم تولّيها للحصول على صلاحيات مؤقتة من STS. وهو يجمع بين سياسة الثقة (من يمكنه تولّيه) وسياسات الصلاحيات (ما الذي يمكنه فعله). وتتيح الأدوار وصول الخدمات والتفويض بين الحسابات وfederation، مع إزالة الأسرار طويلة الأجل. ويؤدي تولّي دور إلى استبدال هويتك بهوية الدور طوال الجلسة.