استخدام مجموعات IAM: لماذا تُعدّ أفضل من إرفاق السياسات مباشرةً بالمستخدمين؟

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

ملخص سريع (TL;DR): مجموعات IAM مقابل إرفاق السياسات المباشر

المعيار	إرفاق السياسات مباشرةً بالمستخدم	استخدام مجموعات IAM
قابلية التوسع	تتدهور مع زيادة عدد المستخدمين	تتوسع بسهولة — عدّل السياسة مرة واحدة
مراجعة الصلاحيات	يتطلب فحص كل مستخدم على حدة	مراجعة مركزية على مستوى المجموعة
إلغاء الوصول عند المغادرة	يستلزم إزالة كل سياسة يدويًا	إزالة المستخدم من المجموعة فقط
الالتزام بمبدأ الامتياز الأدنى	صعب التطبيق المتسق	سهل التطبيق والتدقيق
خطر الانجراف في الصلاحيات	مرتفع — تتراكم الصلاحيات بمرور الوقت	منخفض — الصلاحيات مُعرَّفة مركزيًا

كيف تعمل مجموعات IAM؟

مجموعة IAM ليست 'مستخدمًا' ولا 'دورًا' — إنها حاوية منطقية تُرفق بها سياسات IAM، ثم يُضاف إليها المستخدمون. عند تقييم طلب وصول، يجمع AWS IAM الصلاحيات من ثلاثة مصادر: السياسات المُرفقة مباشرةً بالمستخدم، والسياسات المُرفقة بكل مجموعة ينتمي إليها، وسياسات الجلسة إن وُجدت. المجموعة نفسها لا تملك هوية مستقلة ولا يمكنها تنفيذ طلبات API.

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

graph LR U1["علي"] U2["سارة"] U3["أحمد"] G["مجموعة: Developers"] P1["AmazonS3ReadOnlyAccess"] P2["CloudWatchReadOnlyAccess"] U1 --> G U2 --> G U3 --> G G --> P1 G --> P2

1. المستخدمون (علي، سارة، أحمد) ينتمون إلى مجموعة 'Developers'.
2. المجموعة تحمل السياسات المُعرِّفة للصلاحيات (مثل ReadOnlyAccess لـ S3).
3. عند إضافة مستخدم جديد، يرث صلاحيات المجموعة فورًا دون أي إعداد إضافي.
4. عند إزالة مستخدم من المجموعة، تنتهي صلاحياته المُستمَدة منها فورًا.

لماذا يفشل إرفاق السياسات المباشر في الممارسة العملية؟

المشكلة ليست تقنية في جوهرها — بل تشغيلية. عندما ترفق سياسات مباشرةً بمستخدمين فرديين، تبدو الأمور مُحكمة في البداية. لكن مع مرور الوقت، يحدث ما يُسميه المهندسون 'انجراف الصلاحيات': يحصل المستخدم على صلاحية استثنائية لمهمة محددة، وتُنسى إزالتها. يُنقل مستخدم من فريق إلى آخر، وتبقى صلاحياته القديمة سارية. يصعب على المدققين تحديد 'من يملك ماذا' دون فحص كل مستخدم على حدة.

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

إنشاء مجموعة IAM وإدارتها: الأوامر الكاملة

الخطوات التالية تُغطي دورة حياة المجموعة كاملةً — من الإنشاء إلى إضافة المستخدمين وإرفاق السياسات والتحقق.

الخطوة 1: إنشاء المجموعة

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

aws iam create-group \
  --group-name Developers

الخطوة 2: إرفاق سياسة مُدارة بالمجموعة

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

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

الخطوة 3: إضافة مستخدم إلى المجموعة

المستخدم يجب أن يكون موجودًا مسبقًا في حساب AWS قبل إضافته. إذا كنت تُعدّ بيئة جديدة، أنشئ المستخدمين أولًا.

aws iam add-user-to-group \
  --group-name Developers \
  --user-name ali

الخطوة 4: التحقق من عضوية المجموعة وسياساتها

لا تفترض أن الإعداد صحيح — تحقق منه. هذا الأمر يكشف السياسات المُرفقة والمستخدمين الأعضاء في خطوة واحدة.

# عرض السياسات المُرفقة بالمجموعة
aws iam list-attached-group-policies \
  --group-name Developers

# عرض أعضاء المجموعة
aws iam get-group \
  --group-name Developers

الخطوة 5: إزالة مستخدم مغادر من المجموعة

هذا هو الاختبار الحقيقي للنهج — إزالة وصول مستخدم مغادر تستغرق ثانية واحدة، وتُلغي جميع الصلاحيات المُستمَدة من المجموعة فورًا.

aws iam remove-user-from-group \
  --group-name Developers \
  --user-name ali

سياسة IAM لإدارة المجموعات: مبدأ الامتياز الأدنى

إذا كنت تُفوّض إدارة المجموعات لمسؤول فريق، لا تمنحه صلاحيات IAM كاملة. السياسة التالية تسمح له بإدارة مجموعة 'Developers' فقط دون غيرها.

🔽 انقر لعرض سياسة IAM المقيّدة لإدارة المجموعة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageDevelopersGroupOnly",
      "Effect": "Allow",
      "Action": [
        "iam:AddUserToGroup",
        "iam:RemoveUserFromGroup",
        "iam:GetGroup"
      ],
      "Resource": "arn:aws:iam::123456789012:group/Developers"
    },
    {
      "Sid": "ListUsersForGroupManagement",
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:GetUser"
      ],
      "Resource": "*"
    }
  ]
}

لاحظ أن iam:ListUsers وiam:GetUser تتطلبان "Resource": "*" لأن هذه الإجراءات لا تدعم تقييد الموارد على مستوى المستخدم الفردي — تحقق دائمًا من مرجع تفويض خدمة IAM للتأكد من دعم مستوى الموارد لكل إجراء.

تشخيص مشكلة حقيقية: 'لماذا لا يزال المستخدم يملك صلاحيات بعد إزالته من المجموعة؟'

هذا سيناريو حدث فعلًا: أزلنا مستخدمًا من مجموعة 'Developers'، لكنه لا يزال قادرًا على قراءة بيانات S3. الافتراض الأول كان خطأً في الأمر — لكن المشكلة الحقيقية كانت مختلفة تمامًا.

graph TD A["المستخدم لا يزال يصل إلى S3"] --> B["فحص عضوية المجموعة"] B --> C{"هل هو عضو في المجموعة؟"} C -- نعم --> D["تحقق من السياسات المباشرة على المستخدم"] C -- لا --> E["إزالة صحيحة — تحقق من مصدر آخر"] D --> F{"هل توجد سياسات مباشرة؟"} F -- نعم --> G["إزالة السياسات المباشرة"] F -- لا --> H["فحص سياسة الـ Bucket أو SCP"]

1. الأعراض: المستخدم لا يزال يصل إلى S3 رغم إزالته من المجموعة.
2. التشخيص الخاطئ: ظننا أن الأمر لم يُنفَّذ بشكل صحيح.
3. السبب الفعلي: كانت هناك سياسة مُرفقة مباشرةً بالمستخدم بشكل منفصل — موروثة من إعداد قديم.
4. الحل: فحص السياسات المُرفقة مباشرةً بالمستخدم وإزالتها.

# فحص جميع السياسات المُرفقة مباشرةً بالمستخدم
aws iam list-attached-user-policies \
  --user-name ali

# فحص السياسات المُضمَّنة (Inline Policies)
aws iam list-user-policies \
  --user-name ali

إذا أعاد الأمر الأول نتائج، فهذا يعني وجود سياسات مُرفقة مباشرةً تتجاوز منطق المجموعة. إزالتها:

aws iam detach-user-policy \
  --user-name ali \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

الدرس المستفاد: حتى عند اعتماد نهج المجموعات، تحقق دوريًا من السياسات المُرفقة مباشرةً بالمستخدمين — خاصةً في البيئات التي مرّت بمراحل إعداد يدوي سابقة.

أنماط متقدمة: مستخدم في مجموعات متعددة

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

graph LR U["سارة"] G1["مجموعة: Developers"] G2["مجموعة: OnCallSupport"] P1["CodeCommit: ReadWrite"] P2["CloudWatch: FullAccess"] U --> G1 U --> G2 G1 --> P1 G2 --> P2

1. المستخدم 'سارة' عضو في مجموعتَي 'Developers' و'OnCallSupport'.
2. تحصل على صلاحيات مجمّعة من كلتا المجموعتين.
3. أي 'Deny' صريح في أي سياسة يُلغي جميع 'Allow' الأخرى — بغض النظر عن المصدر.

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

استخدام مجموعات IAM: الخلاصة والخطوات التالية

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

الخطوات الموصى بها:

• راجع السياسات المُرفقة مباشرةً بمستخدميك الحاليين وانقلها إلى مجموعات.
• استخدم IAM Access Advisor لتحديد الصلاحيات غير المُستخدمة قبل الترحيل.
• فعّل IAM Credential Report للحصول على نظرة شاملة على حالة المستخدمين والمجموعات.
• للبيئات الأكبر، ادرس استخدام AWS IAM Identity Center (المعروف سابقًا بـ SSO) لإدارة الوصول على مستوى المؤسسة.

مسرد المصطلحات الأساسية

المصطلح	التعريف
مجموعة IAM (IAM Group)	حاوية منطقية لمستخدمي IAM تُرفق بها السياسات وتُطبَّق على جميع الأعضاء
سياسة مُدارة (Managed Policy)	سياسة IAM مستقلة يمكن إرفاقها بمستخدمين أو مجموعات أو أدوار متعددة
سياسة مُضمَّنة (Inline Policy)	سياسة مُضمَّنة مباشرةً في كيان IAM واحد وتُحذف معه
انجراف الصلاحيات (Permission Drift)	تراكم الصلاحيات بمرور الوقت بما يتجاوز ما تتطلبه المهام الفعلية
مبدأ الامتياز الأدنى (Least Privilege)	منح الصلاحيات الضرورية فقط لأداء المهمة المحددة، لا أكثر

Related Posts

• 📄 هيكل سياسة IAM الأساسي: الفرق بين Effect وAction وResource وCondition
• 📄 الفرق بين IAM User و IAM Role في AWS: متى تستخدم كل منهما؟