الفرق بين IAM User و IAM Role في AWS: متى تستخدم كل منهما؟

أحد أكثر الأسئلة شيوعاً عند البدء بـ AWS هو: هل أُنشئ IAM User أم IAM Role لتطبيقي الذي يعمل على EC2 ويحتاج للوصول إلى S3؟ الخلط بين الاثنين ليس مجرد مسألة مفاهيمية — الاختيار الخاطئ يعني إما ثغرة أمنية حقيقية أو تعقيداً تشغيلياً لا داعي له.

ملخص سريع (TL;DR): IAM User مقابل IAM Role

المعيار	IAM User	IAM Role
الهوية	شخص أو تطبيق محدد بمعرّف ثابت	هوية مؤقتة قابلة للتبني
بيانات الاعتماد	كلمة مرور أو Access Key طويلة الأمد	بيانات اعتماد مؤقتة تُجدَّد تلقائياً
الاستخدام الأمثل	مستخدم بشري يسجل دخوله للـ Console	خدمات AWS، تطبيقات EC2، Lambda، حسابات أخرى
إدارة المفاتيح	يدوية — تدوير يدوي مطلوب	تلقائية — STS يتولى التجديد
التوصية لـ EC2 + S3	❌ غير موصى به	✅ الطريقة الصحيحة

كيف يعمل كل منهما: الآلية الداخلية

قبل الدخول في التفاصيل التشغيلية، من المهم فهم الفرق الجوهري في طريقة عمل كل منهما.

IAM User هو كيان دائم في حسابك. عند إنشائه، يحصل على Access Key ID و Secret Access Key — هذان المفتاحان لا ينتهيان تلقائياً. إذا وضعتهما في كود تطبيقك أو في ملف إعداد على الخادم، فهما يبقيان صالحَين حتى تحذفهما يدوياً. هذا هو بالضبط ما يجعلهما خطرين في السياقات التلقائية.

IAM Role بطبيعته مختلف — لا يملك بيانات اعتماد ثابتة. بدلاً من ذلك، يُعرّف مجموعة صلاحيات يمكن 'تبنّيها' (Assume) من قِبل كيان موثوق. عندما تُرفق Role بـ EC2 Instance، تتواصل الـ Instance مع خدمة STS (Security Token Service) عبر Instance Metadata Service للحصول على بيانات اعتماد مؤقتة تُجدَّد تلقائياً قبل انتهاء صلاحيتها.

sequenceDiagram participant App as التطبيق على EC2 participant IMDS as Instance Metadata Service participant STS as AWS STS participant S3 as Amazon S3 App->>IMDS: طلب بيانات اعتماد مؤقتة IMDS->>STS: طلب توكن للـ Role المُرفقة STS-->>IMDS: Access Key + Secret Key + Session Token (مؤقتة) IMDS-->>App: بيانات الاعتماد المؤقتة App->>S3: طلب GetObject / PutObject S3-->>App: الاستجابة Note over IMDS,STS: التجديد التلقائي قبل انتهاء الصلاحية

1. طلب الاعتماد: التطبيق على EC2 يطلب بيانات اعتماد من Instance Metadata Service على العنوان 169.254.169.254.
2. STS يُصدر توكن مؤقت: AWS STS يُصدر Access Key و Secret Key و Session Token صالحة لفترة محدودة.
3. الوصول إلى S3: التطبيق يستخدم هذه البيانات المؤقتة للوصول إلى S3.
4. التجديد التلقائي: AWS SDK يتولى تجديد البيانات تلقائياً قبل انتهاء صلاحيتها — لا تدخل يدوي مطلوب.

الفرق العملي بين IAM User و IAM Role في بيئة الإنتاج

المشكلة الحقيقية مع استخدام IAM User لتطبيق على EC2 ليست مفاهيمية — إنها تشغيلية. عندما تضع Access Key في متغير بيئة أو ملف إعداد، ثلاثة أشياء تحدث في الغالب:

• المفتاح يُنسخ إلى صور AMI أو يظهر في logs بالخطأ.
• تدوير المفتاح يتطلب إعادة نشر التطبيق أو تحديث الإعداد يدوياً على كل instance.
• إذا تسرّب المفتاح، صلاحيته لا تنتهي تلقائياً — يجب حذفه يدوياً وإنشاء مفتاح جديد.

مع IAM Role، هذه المشاكل الثلاث تختفي. لا يوجد مفتاح لتخزينه، ولا مفتاح لتدويره، ولا مفتاح يمكن أن يتسرب بشكل دائم.

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

إنشاء IAM Role لـ EC2 للوصول إلى S3: الخطوات الكاملة

هذا هو المسار الموصى به. سنُنشئ Role بصلاحيات S3 محدودة ونُرفقها بـ EC2 Instance.

الخطوة 1: إنشاء IAM Role بـ Trust Policy لـ EC2

أول شيء يجب تحديده هو من يُسمح له بتبني هذه الـ Role — في حالتنا خدمة EC2. هذا يُعرَّف في Trust Policy، وهو ما يميز الـ Role عن الـ User من الناحية المعمارية.

# إنشاء ملف Trust Policy
cat > ec2-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# إنشاء الـ Role
aws iam create-role \
  --role-name EC2-S3-Access-Role \
  --assume-role-policy-document file://ec2-trust-policy.json \
  --description 'Role for EC2 instances to access S3'

الخطوة 2: إنشاء Permission Policy بمبدأ الصلاحية الأدنى

بدلاً من إرفاق AmazonS3FullAccess الجاهزة — وهو خطأ شائع — نُنشئ policy مخصصة تُحدد الـ bucket والعمليات المطلوبة فقط. الصلاحية الأدنى ليست مجرد توصية، بل هي الفارق بين اختراق محدود واختراق كامل.

# إنشاء Permission Policy مخصصة
cat > s3-limited-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-app-bucket"
    }
  ]
}
EOF

# إنشاء الـ Policy
aws iam create-policy \
  --policy-name EC2-S3-Limited-Policy \
  --policy-document file://s3-limited-policy.json

الخطوة 3: إرفاق الـ Policy بالـ Role

استبدل 123456789012 برقم حسابك الفعلي.

aws iam attach-role-policy \
  --role-name EC2-S3-Access-Role \
  --policy-arn arn:aws:iam::123456789012:policy/EC2-S3-Limited-Policy

الخطوة 4: إنشاء Instance Profile وإرفاق الـ Role

EC2 لا تتعامل مباشرة مع IAM Role — بل تحتاج إلى Instance Profile كغلاف. هذا تفصيل يغفله كثيرون عند العمل مع CLI بدلاً من Console.

# إنشاء Instance Profile
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-Access-Profile

# إضافة الـ Role للـ Instance Profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-Access-Profile \
  --role-name EC2-S3-Access-Role

الخطوة 5: إرفاق الـ Instance Profile بـ EC2 Instance

إذا كانت الـ Instance تعمل بالفعل، يمكن إرفاق الـ Profile دون إيقافها.

# إرفاق بـ Instance موجودة
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=EC2-S3-Access-Profile

الخطوة 6: التحقق من عمل الـ Role داخل الـ Instance

هذه الخطوة ضرورية للتأكد من أن الـ metadata service يُعيد بيانات اعتماد صحيحة — وليس فقط أن الـ Role مُرفقة على الورق.

# من داخل الـ EC2 Instance — التحقق من الـ Role المُرفقة
aws sts get-caller-identity

# التحقق من إمكانية الوصول إلى S3
aws s3 ls s3://my-app-bucket/

graph TD A[هل الكيان بشري يسجل دخولاً يدوياً؟] -->|نعم| B[استخدم IAM User] A -->|لا| C[هل هو خدمة AWS أو تطبيق تلقائي؟] C -->|نعم| D[استخدم IAM Role] D --> E[هل يعمل على EC2؟] E -->|نعم| F[أنشئ Instance Profile وأرفق الـ Role] E -->|Lambda أو ECS| G[أرفق Execution Role مباشرة] C -->|أداة خارجية CI/CD| H[فكّر في OIDC Federation أو IAM Identity Center] B --> I[فعّل MFA وطبّق سياسة تدوير المفاتيح] F --> J[التطبيق يحصل على بيانات مؤقتة تلقائياً]

متى تستخدم IAM User إذن؟

IAM User له مكانه الصحيح — لكنه ليس للتطبيقات التلقائية. الحالات المشروعة لاستخدامه:

• مستخدم بشري يحتاج للوصول إلى AWS Console أو CLI من جهازه الشخصي.
• أدوات CI/CD خارج AWS لا تدعم OIDC أو لا يمكنها تبني Role مباشرة — وحتى هنا، الأفضل استخدام IAM Identity Center أو OIDC Federation.
• حالات طوارئ Break-Glass حيث تحتاج وصولاً مباشراً لا يعتمد على خدمة أخرى.

خطأ شائع: تشخيص خاطئ لمشكلة صلاحيات EC2 إلى S3

المشهد: تطبيق على EC2 يُعطي خطأ AccessDenied عند محاولة الكتابة إلى S3، رغم أن الـ Role مُرفقة والـ Policy تبدو صحيحة.

التشخيص الأول الخاطئ: 'المشكلة في الـ Policy — سأُضيف صلاحيات أوسع.' بعد إضافة s3:*، المشكلة لا تزال موجودة.

السبب الفعلي: الـ S3 Bucket يملك Bucket Policy تحتوي على Deny صريح لعمليات الكتابة من خارج VPC معين، أو أن S3 Block Public Access أو إعدادات Object Ownership تتعارض مع العملية. في AWS، Explicit Deny في أي policy يتغلب على أي Allow — حتى لو كانت الـ IAM Policy تسمح بالعملية.

# التحقق من Bucket Policy
aws s3api get-bucket-policy \
  --bucket my-app-bucket

# التحقق من إعدادات Block Public Access
aws s3api get-public-access-block \
  --bucket my-app-bucket

# التحقق من Object Ownership
aws s3api get-bucket-ownership-controls \
  --bucket my-app-bucket

الدرس: عند تشخيص مشاكل الصلاحيات في S3، تحقق دائماً من طبقتين — IAM Policy المُرفقة بالـ Role، والـ Bucket Policy على الـ S3 نفسه. الطبقة الثانية تُلغي الأولى عند وجود Deny صريح.

الخلاصة والخطوات التالية: IAM User مقابل IAM Role

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

لتطبيق يعمل على EC2 ويحتاج الوصول إلى S3، المسار الصحيح هو: إنشاء Role بـ Trust Policy لـ EC2، إرفاق Permission Policy بأدنى صلاحية ممكنة، إنشاء Instance Profile، وإرفاقه بالـ Instance. AWS SDK يتولى كل شيء بعد ذلك تلقائياً.

• توثيق AWS: استخدام IAM Roles مع EC2
• أفضل ممارسات IAM في AWS

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

المصطلح	التعريف
IAM User	كيان دائم في AWS يملك بيانات اعتماد طويلة الأمد، مخصص للمستخدمين البشريين
IAM Role	هوية قابلة للتبني تُصدر بيانات اعتماد مؤقتة، مخصصة للخدمات والتطبيقات
Trust Policy	سياسة تُحدد من يُسمح له بتبني الـ Role (مثل خدمة EC2)
Instance Profile	غلاف يربط IAM Role بـ EC2 Instance ويُمكّنها من الحصول على بيانات اعتماد مؤقتة
STS (Security Token Service)	خدمة AWS التي تُصدر بيانات الاعتماد المؤقتة عند تبني Role
Explicit Deny	رفض صريح في أي policy يتغلب على أي Allow، بغض النظر عن مصدره