AWS Certified Cloud Practitioner

أساسيات IAM

تعرّف على خدمة AWS Identity and Access Management، واللبنات الأربع التي تمنحها لك (المستخدمون والمجموعات والأدوار والسياسات)، وكيف تقرّر AWS السماح بأي طلب أو رفضه.

مبتدئ 16 دقائق 5 أهداف التعلّم
  1. عرّف ما خدمة AWS IAM والوصول الذي تتحكّم فيه
  2. تعرّف على اللبنات الأربع في IAM: المستخدمون والمجموعات والأدوار والسياسات
  3. وضّح الفرق بين مستخدم IAM ودور IAM
  4. صِف كيف تقيّم AWS الطلب عبر المصادقة والتفويض
  5. ميّز بين السياسات المرتبطة بالهوية والسياسات المرتبطة بالمورد

من يفعل ماذا

كل إجراء في AWS يعود إلى سؤال واحد: هل يُسمح لهذه الهوية بأن تفعل هذا الشيء بهذا المورد؟ خدمة AWS Identity and Access Management، أو IAM، هي التي تجيب عنه. في IAM تقرّر من يسجّل الدخول إلى حسابك، وماذا يُسمح لكل شخص أو تطبيق بفعله بعد دخوله.

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

ما IAM

IAM خدمة ويب تتحكّم في الوصول إلى موارد AWS. وهي تؤدّي مهمتين:

  • المصادقة (authentication) تؤكّد هوية صاحب الطلب. حين تسجّل الدخول بكلمة مرور، أو يستدعي تطبيق AWS بمفتاح، يطابق IAM بيانات الاعتماد هذه مع هوية يثق بها.
  • التفويض (authorization) يقرّر ما يُسمح لتلك الهوية بفعله. بعد أن تعرف AWS من أنت، تفحص صلاحياتك لترى هل الإجراء الذي طلبته مسموح أم لا.

حقيقتان عن IAM تمثّلان نقاطاً سهلة في الاختبار. الأولى أن IAM خدمة عامة (global): الهويات التي تنشئها لا ترتبط بمنطقة، فلا تختار منطقة حين تنشئ مستخدماً أو دوراً. والثانية أن IAM نفسه مجاني. تدفع فقط مقابل موارد AWS التي تستخدمها هوياتك، لا مقابل IAM.

اللبنات الأساسية

يمنحك IAM أربعة عناصر تعمل بها. اضبط هذه الأربعة يتّضح معظم الموضوع.

مستخدمو IAM

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

مجموعات IAM

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

أدوار IAM

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

الفرق بين المستخدم والدور نقطة متكرّرة في الاختبار. المستخدم هوية دائمة ببيانات اعتماده الخاصة. الدور قبعة مؤقتة يلبسها المُوكّل فيحصل على بيانات اعتماد قصيرة الأجل، ثم يخلعها.

سياسات IAM

السياسة وثيقة، غالباً بصيغة JSON، تُدرِج الصلاحيات. ترفق السياسات بالمستخدمين أو المجموعات أو الأدوار لتحدّد ما يمكنهم فعله. توفّر AWS أيضاً سياسات مُدارة من AWS (AWS managed policies)، وهي سياسات جاهزة للمهام الشائعة ترفقها كنقطة بداية، إلى جانب سياسات مُدارة من العميل (customer managed policies) تكتبها بنفسك.

عبارة سياسة بسيطة لها أجزاء قليلة أساسية:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-example-bucket"
    }
  ]
}
  • Effect هو Allow أو Deny.
  • Action يُدرِج العمليات، مثل s3:ListBucket.
  • Resource يسمّي ما تنطبق عليه الإجراءات.

لا تحتاج إلى كتابة JSON بيدك للاختبار، لكن يجب أن تتعرّف على هذه الأجزاء، وأن تعرف أن Effect هو ما يجعل العبارة تسمح بالإجراء أو تمنعه.

كيف يُقيَّم الطلب

حين يقدّم مُوكّل طلباً، تعالجه AWS بالترتيب.

  1. المصادقة. تطابق AWS بيانات الاعتماد في الطلب مع مُوكّل تثق به: مستخدم IAM أو جلسة دور أو هوية مُتّحدة (federated).
  2. التفويض. تجمع AWS كل سياسة تنطبق، وتفحص هل الإجراء مسموح.

الجواب الافتراضي هو لا. يُرفَض الوصول ما لم تسمح به سياسة صراحةً، والرفض (Deny) الصريح في أي سياسة يغلب دائماً، حتى على السماح. فلا ينجح الطلب إلا حين يسمح به شيء ولا يرفضه شيء.

السياسات المرتبطة بالهوية والسياسات المرتبطة بالمورد

تأتي السياسات في شكلين عريضين، والتفريق بينهما يفيدك في الاختبار.

تُرفَق بـتسمّي مُوكّلاً؟مثال
سياسة مرتبطة بالهويةمستخدم أو مجموعة أو دورلا، الهوية نفسها هي المُوكّلسياسة على مجموعة Developers تسمح بقراءة S3
سياسة مرتبطة بالموردموردنعم، تسمّي من يُمنَح الوصولسياسة حاوية S3 تمنح حساباً آخر الوصول

السياسات المرتبطة بالهوية تقول "هذه الهوية تستطيع فعل هذه الأشياء". والسياسات المرتبطة بالمورد تقول "هؤلاء المُوكّلون يستطيعون فعل هذه الأشياء بي". والدور حالة خاصة: يحمل سياسة صلاحيات وسياسة ثقة (trust policy) تسمّي من يُسمح له بتولّيه.

نصائح للاختبار

  • يتحكّم IAM في المصادقة (من أنت) والتفويض (ماذا تستطيع أن تفعل).
  • IAM خدمة عامة (global) ومجانية. تدفع فقط مقابل الموارد التي تستخدمها الهويات.
  • أربع لبنات: المستخدمون (شخص أو تطبيق)، والمجموعات (تجميع للمستخدمين)، والأدوار (تُتولّى، بيانات اعتماد مؤقتة)، والسياسات (صلاحيات JSON).
  • المستخدم له بيانات اعتماد دائمة، والدور يُتولّى للحصول على بيانات اعتماد مؤقتة. احفظ هذا الفرق.
  • المجموعات بلا بيانات اعتماد ولا تتداخل.
  • الوصول مرفوض افتراضياً، والرفض (Deny) الصريح يغلب السماح دائماً.
  • السياسات المرتبطة بالهوية تُرفَق بالمستخدمين والمجموعات والأدوار. والسياسات المرتبطة بالمورد تُرفَق بمورد وتسمّي المُوكّل.