مستخدمو IAM والمجموعات والـ roles والسياسات

في نهاية القسم الأول شغّلت aws sts get-caller-identity فأجابت AWS. خلف تلك الإجابة، وخلف كل استدعاء آخر، يقف AWS Identity and Access Management (IAM). إنه يجيب عن سؤال واحد مليارات المرات يوميًا: هل يحق لـ هذا الـ principal أن ينفّذ هذا الإجراء على هذا المورد، الآن؟ كان لخادم Lantern القديم جواب واحد لكل شيء: من يملك مفتاح SSH يستطيع فعل أي شيء. يمنحك هذا الدرس المفردات اللازمة لتفعل ما هو أفضل.

تشريح الطلب

كل طلب إلى AWS، سواء من الـ console أو الـ CLI أو الكود، يحمل أربعة أشياء:

• الـ principal (الجهة الطالبة): من يسأل. مستخدم، أو جلسة role، أو خدمة من خدمات AWS.
• الإجراء (action): ما يريده، ويُكتب بالشكل service:Operation، مثل s3:GetObject أو dynamodb:PutItem.
• المورد (resource): ما يريد تنفيذ الإجراء عليه، ويُعرَّف بـ ARN (اسم مورد Amazon).
• السياق (context): كل ما يستطيع IAM رؤيته غير ذلك، مثل عنوان IP المصدر، والوقت، وهل استُخدم MFA، وهل استخدم الطلب TLS.

تتبع الـ ARNs النمط arn:partition:service:region:account-id:resource. وتبقى بعض الأجزاء فارغة حين لا تنطبق:

arn:aws:iam::111122223333:user/amara
arn:aws:s3:::lantern-posters/2026/street-food-festival.jpg
arn:aws:dynamodb:eu-west-1:111122223333:table/lantern-rsvps

IAM خدمة عامّة (global)، لذا لا يحتوي ARN المستخدم على Region. وأسماء الـ buckets في S3 فريدة على مستوى AWS كلها، لذا لا يحتوي ARN الخاص بـ S3 على Region ولا على حساب. أما جداول DynamoDB فإقليمية وتنتمي إلى حساب، لذا يحتوي الـ ARN الخاص بها على الاثنين. ستكتب الـ ARNs باستمرار في الدرس القادم.

الهويات

المستخدمون (users) هويات طويلة الأمد لشخص واحد، أو لتطبيق واحد في الإعدادات القديمة. يمكن أن يكون للمستخدم كلمة مرور للـ console وما يصل إلى مفتاحَي وصول. المستخدمون أقدم أجزاء IAM، وفي القسم الأول أنشأت واحدًا فقط، هو المدير.

المجموعات (groups) تجمّعات من المستخدمين. ترفق السياسات بالمجموعة، فيحصل عليها كل أعضائها. ينشئ Lantern المجموعات Admins وDevelopers وBilling، فعندما ينضم متطوّع أو يغادر، تغيّر عضوية واحدة بدلًا من البحث في الصلاحيات الفردية. المجموعات ليست principals: لا يمكنك تسجيل الدخول كمجموعة، ولا تسمية مجموعة في سياسة bucket.

الـ roles هويات لها صلاحيات لكن بلا بيانات اعتماد طويلة الأمد. يتقمّص principal موثوق الـ role، فتعيد AWS Security Token Service (STS) بيانات اعتماد مؤقتة تنتهي صلاحيتها. وتحدّد سياسة الثقة (trust policy) الخاصة بالـ role من يحق له تقمّصه: دالة Lambda، أو instance في EC2، أو مستخدم في حساب آخر، أو أشخاص سجّلوا الدخول عبر IAM Identity Center. الـ roles هي الطريقة التي يحصل بها الكود على صلاحيات دون أسرار، والدرس الثالث من هذا القسم يبني عليها.

aws iam create-group --group-name Developers
aws iam attach-group-policy --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam add-user-to-group --group-name Developers --user-name sam

أين تعيش السياسات

السياسة (policy) مستند JSON من العبارات (statements) التي تسمح بإجراءات على موارد أو ترفضها. ومكان إرفاقها يغيّر طريقة قراءتها:

• السياسات القائمة على الهوية (identity-based policies) تُرفق بمستخدم أو مجموعة أو role، وتصف ما يحق لـ تلك الهوية فعله. وتأتي على شكل سياسات تديرها AWS (مثل ReadOnlyAccess)، أو سياسات يديرها العميل تكتبها وتعيد استخدامها، أو سياسات مضمّنة (inline) مدمجة في هوية واحدة.
• السياسات القائمة على المورد (resource-based policies) تُرفق بمورد وتسمّي الـ principal الذي تنطبق عليه. سياسة الـ bucket في S3، وسياسة المورد الخاصة بدالة Lambda، وسياسة الثقة الخاصة بالـ role، كلها قائمة على المورد.

داخل حساب واحد، يُسمح بالطلب إذا سمح به أيٌّ من النوعين ولم يرفضه شيء. أما عبر الحسابات، فيجب أن يسمح به الطرفان.

كيف يقرّر IAM

قاعدة التقييم تتّسع لها بطاقة صغيرة، وهي تفسّر تقريبًا كل خطأ AccessDenied ستصادفه.

1. الرفض الافتراضي. كل طلب يبدأ مرفوضًا.
2. الرفض الصريح ينتصر. إذا احتوت أي سياسة منطبقة على Deny مطابق، فالجواب لا. ولا شيء يستطيع تجاوزه.
3. السماح الصريح يُجيز. وإلا، إذا احتوت سياسة على Allow مطابق، فالجواب نعم.
4. لا تطابق يعني لا. إذا لم يسمح بالطلب شيء، يبقى الرفض الافتراضي قائمًا. ويُسمّى هذا الرفض الضمني (implicit deny).

وتضيف الإعدادات الأكبر طبقات أخرى لا تستطيع إلا تضييق ما هو مسموح، مثل سياسات التحكّم في الخدمات (service control policies) في AWS Organizations، وحدود الصلاحيات (permissions boundaries) على مستخدمين وroles بعينهم. تظل القاعدة أعلاه صحيحة؛ كل ما تفعله تلك الطبقات أنها تضيف أماكن أخرى قد يأتي منها الرفض.

يمكنك أن تطلب من IAM تقييم طلب دون تنفيذه:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:user/sam \
  --action-names s3:DeleteBucket \
  --resource-arns arn:aws:s3:::lantern-posters \
  --query "EvaluationResults[].EvalDecision"

يكون الجواب allowed أو explicitDeny أو implicitDeny، فيخبرك لا بـ هل فقط، بل بـ لماذا أيضًا.

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