أساسيات السحابة: خدمات AWS الأساسية

أساسيات IAM

18 دقيقة الدرس 2 من 30

أساسيات IAM

إدارة الهوية والوصول في AWS (IAM) هي العمود الفقري لأمان كل حساب AWS. قبل أن تصل أي استدعاء API إلى أي خدمة AWS — S3 أو EC2 أو RDS أو أي شيء آخر — تعترضها IAM وتجيب على سؤال واحد: هل يُسمح لهذا المُستدعي بتنفيذ هذا الإجراء على هذا المورد؟ الخطأ في IAM هو السبب الجذري الأكثر شيوعاً لاختراقات أمان AWS. الصواب يعني منح كل فريق وكل خدمة وكل خط أنابيب آلي الصلاحيات التي يحتاجها بالضبط لا أكثر.

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

المستخدمون (Users)

المستخدم في IAM هو هوية دائمة مرتبطة بشخص أو تطبيق قديم. يحصل كل مستخدم على بيانات اعتماد دائمة: كلمة مرور لوحة تحكم AWS وأحياناً زوج Access Key ID + Secret Access Key للوصول عبر API أو CLI. كلمة "دائمة" هي مصدر الخطر: بيانات الاعتماد الثابتة يمكن تسريبها أو اختراقها أو إيداعها في مستودع git ولا تنتهي صلاحيتها من تلقاء نفسها.

المعيار في شركات التقنية الكبرى للوصول البشري: استخدام IAM Identity Center (تسجيل الدخول الموحد) بدلاً من مستخدمي IAM. Identity Center يُدمج موفر الهوية في شركتك (Okta أو Azure AD أو Google Workspace) في بيانات اعتماد AWS مؤقتة قصيرة الأجل. يسجل المهندسون دخولهم بحساباتهم المؤسسية، يحصلون على جلسة محدودة زمنياً، ولا توجد مفاتيح وصول ثابتة للتسريب. يظل مستخدمو IAM مناسبين للأدوات القديمة غير القادرة على الاتحاد، وللسيناريو الطارئ لحساب الجذر.

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

المجموعات (Groups)

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

لا يمكن تداخل المجموعات (لا تنتمي مجموعة لمجموعة أخرى)، ولا يمكن افتراضها من قبل الخدمات أو الهويات المتحدة — هذا ما تُستخدم له الأدوار.

الأدوار (Roles)

الدور في IAM هو هوية مؤقتة يمكن لأي مبدأ موثوق افتراضها. خلافاً للمستخدم، لا يمتلك الدور كلمة مرور ولا بيانات اعتماد دائمة. عند افتراض دور، تُصدر AWS STS (خدمة رمز الأمان) بيانات اعتماد قصيرة الأجل — مفتاح وصول ومفتاح سري ورمز جلسة — تنتهي صلاحيتها خلال 15 دقيقة إلى 12 ساعة. يستخدم المُستدعي هذه البيانات المؤقتة لتلك الجلسة ثم يتخلص منها.

الأدوار هي الإجابة الصحيحة لكل حالة استخدام غير بشرية تقريباً:

دور نسخة EC2: نسخة EC2 تحتاج قراءة كائنات من S3. ترفق دوراً بصلاحية s3:GetObject بملف تعريف النسخة. يستدعي التطبيق نقطة نهاية بيانات النسخة (169.254.169.254) للحصول على بيانات اعتماد مؤقتة تتدوّر تلقائياً. لا مفاتيح ثابتة في أي مكان في الكود أو البيئة.
دور تنفيذ Lambda: كل دالة Lambda تملك دور تنفيذ يُحدد خدمات AWS التي يمكن للدالة استدعاؤها. تحصل الدالة على بيانات اعتماد مؤقتة مُحقونة تلقائياً من بيئة تشغيل Lambda.
دور عبر الحسابات: خط أنابيب النشر في الحساب A يحتاج نشر موارد في الحساب B. يُنشئ الحساب B دوراً بسياسة ثقة تسمح للحساب A بافتراضه. يفترض خط الأنابيب الدور، يحصل على بيانات اعتماد مؤقتة محددة النطاق بالحساب B، وينشر. لا تغادر أي بيانات اعتماد الحساب B أبداً.
خدمة-لخدمة عبر IRSA: في EKS (Kubernetes على AWS)، تستخدم Pods أدوار IAM لحسابات الخدمة (IRSA). تُشرَّح حساب خدمة Kubernetes بـ ARN دور؛ تحصل الـ Pod على بيانات اعتماد مؤقتة مُفوَّضة عبر OIDC مرتبطة بذلك الدور. لا مفاتيح وصول على العقدة، لا أسرار مشتركة.

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

السياسات (Policies)

السياسة هي مستند JSON يُحدد الصلاحيات. هي الوحدة الأساسية للترخيص في IAM. تحتوي السياسة على عبارة أو أكثر، كل منها تُحدد: Effect (السماح أو الرفض) وقائمة Actions (استدعاءات API المسموح بها) وقائمة Resources (الـ ARNs المستهدفة) واختيارياً كتلة Condition (قيود السياق كاشتراط المصادقة متعددة العوامل أو نطاق IP المصدر أو وقت اليوم).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnlyOnSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-assets",
        "arn:aws:s3:::my-app-assets/*"
      ]
    },
    {
      "Sid": "DenyDeleteUnlessMFA",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteBucket"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

تُصدر AWS مئات من السياسات المُدارة من AWS (مثل AmazonS3ReadOnlyAccess). هي مريحة لكن تكاد تكون واسعة النطاق دائماً للاستخدام الإنتاجي — AmazonS3ReadOnlyAccess تمنح القراءة على كل حاوية في الحساب. ينبغي للأحمال الإنتاجية استخدام سياسات مُدارة من العميل بأقل الإجراءات المطلوبة محددة النطاق بـ ARNs موارد بعينها. هذا هو مبدأ الصلاحيات الأدنى، وهو غير قابل للتفاوض على نطاق التقنية الكبرى.

هناك نمطان للربط:

السياسات القائمة على الهوية — مرفقة بمستخدم أو مجموعة أو دور. تُحدد ما يمكن لتلك الهوية فعله.
السياسات القائمة على المورد — مرفقة بالمورد نفسه (سياسة حاوية S3 وسياسة طابور SQS وسياسة مفتاح KMS). تُحدد من يمكنه فعل ماذا على هذا المورد بالتحديد. السياسات القائمة على المورد تُمكّن أيضاً الوصول عبر الحسابات دون افتراض دور.

منطق تقييم السياسة

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

ترتيب تقييم سياسة IAM: الرفض الصريح يفوز أولاً دائماً، ثم تضع SCPs حدود الحساب، ثم تُفحص سياسات المورد والهوية، والافتراضي دائماً هو الرفض.

قواعد التقييم بلغة واضحة:

الرفض الصريح يفوز بلا شروط. إن احتوت أي سياسة — قائمة على الهوية أو المورد أو SCP أو حدود الصلاحيات — عبارة Deny تطابق الطلب، يُرفض الطلب فوراً. لا سياسة أخرى يمكنها تجاوز رفض صريح.
SCPs تعمل كحاجز على مستوى الحساب. إن كنت تستخدم AWS Organizations، يجب أن تسمح سياسة التحكم بالخدمة (SCP) على الحساب أو وحدة المؤسسة بالإجراء. SCPs لا تمنح صلاحيات؛ فقط تُقيّد الصلاحيات القصوى المتاحة. إن لم تسمح SCP بإجراء صراحةً، يُرفض حتى لو سمحت به سياسة IAM.
السياسات القائمة على المورد يمكنها منح الوصول بمفردها (نفس الحساب). إن منحت سياسة مورد (مثل سياسة حاوية S3) الإجراء للمبدأ الطالب وكان في نفس حساب AWS، يُسمح بالوصول — حتى بدون سياسة هوية مطابقة. للوصول عبر الحسابات، يجب أن تسمح كلٌّ من سياسة المورد على المورد الهدف وسياسة الهوية على المبدأ المُستدعي بالإجراء.
يجب أن تسمح سياسات الهوية بالإجراء إن لم تكن هناك منحة من سياسة مورد.
الرفض الضمني هو الافتراضي. إن لم تُنتج أي من خطوات التقييم أعلاه سماحاً صريحاً، يُرفض الطلب. لا تمنح IAM صلاحيات بالافتراضي — يجب أن تكون صريحاً.

حدود الصلاحيات (Permissions boundaries) تُضيف طبقة سادسة: تُحدد الصلاحيات القصوى التي يمكن لسياسة قائمة على الهوية منحها لمستخدم أو دور. حتى لو سمحت سياسة هوية بـs3:*، فإن حد صلاحيات يسمح فقط بـs3:GetObject يعني أن الصلاحية الفعلية هي s3:GetObject. تُستخدم الحدود لتفويض إنشاء الأدوار للفرق دون منحهم تصعيد صلاحيات غير محدود.

IAM عملي: إنشاء دور ذو صلاحيات أدنى لـ Lambda

فيما يلي نمط إنتاجي متكامل: دالة Lambda تقرأ من جدول DynamoDB محدد وتكتب سجلات إلى CloudWatch. لا شيء آخر. ننشئ الدور والسياسة ونربطهما — كله عبر AWS CLI.

# 1. أنشئ سياسة الثقة (من يمكنه افتراض هذا الدور — خدمة Lambda)
cat > /tmp/trust-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

# 2. أنشئ الدور
aws iam create-role \
  --role-name lambda-inventory-reader \
  --assume-role-policy-document file:///tmp/trust-policy.json \
  --description "Lambda role for inventory-reader function"

# 3. أنشئ سياسة ذات صلاحيات أدنى
cat > /tmp/lambda-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBReadOnly",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:Scan"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/inventory"
    },
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/inventory-reader:*"
    }
  ]
}
EOF

# 4. ارفق السياسة بالدور
aws iam put-role-policy \
  --role-name lambda-inventory-reader \
  --policy-name inventory-reader-policy \
  --policy-document file:///tmp/lambda-policy.json

# 5. تحقق من صلاحيات الدور — محاكاة استدعاء API
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/lambda-inventory-reader \
  --action-names dynamodb:GetItem \
  --resource-arns arn:aws:dynamodb:us-east-1:123456789012:table/inventory

أمر simulate-principal-policy لا يُقدَّر بثمن أثناء التشخيص. يُخبرك بالضبط إن كان مبدأ معيناً يستطيع تنفيذ إجراء معين على مورد معين — وأي عبارة سياسة أنتجت القرار — دون إجراء استدعاء API حقيقي للخدمة الهدف.

أخطاء IAM الشائعة في الإنتاج

إجراءات بدل عام على موارد بدل عام: "Action": "*", "Resource": "*" يجعل المستخدم أو الدور مدير حساب فعلياً. أي سياسة تحتوي هذا في دور غير إداري هو نتيجة حرجة في تدقيق الأمان.
إهمال تدوير مفاتيح الوصول: يجب تدوير مفاتيح الوصول طويلة الأجل. يُشير IAM Access Analyzer إلى المفاتيح الأقدم من 90 يوماً. استخدم aws iam list-access-keys للتدقيق. الأفضل: انتقل للأدوار وتخلص من المشكلة كلياً.
الخلط بين سياسة الثقة وسياسة الصلاحيات: سياسة الثقة على الدور تتحكم في من يمكنه افتراضه. سياسة الصلاحيات تتحكم في ما يمكن للدور فعله. كلتاهما يجب أن تكون صحيحة. دور بلا سياسة ثقة لا يستطيع أحد افتراضه.
عدم تحديد نطاق ARNs الموارد: "Resource": "arn:aws:s3:::*" يمنح الإجراءات المحددة على كل حاوية في الحساب. حدد دائماً الـ ARN بدقة — arn:aws:s3:::my-specific-bucket وarn:aws:s3:::my-specific-bucket/*.

IAM تتسق في نهاية المطاف: بعد ربط أو فك ربط سياسة، ينتشر التغيير عالمياً عبر كل مراكز بيانات AWS. عملياً يستغرق ثوانٍ، لكن في حالات نادرة قد يصل لدقيقة. إن منح التشغيل الآلي دوراً صلاحية جديدة ثم استدعى فوراً API بذلك الدور، قد تحصل على خطأ AccessDenied غير متوقع. أضف انتظاراً قصيراً أو إعادة محاولة بتراجع أسي في سكريبتات نشرك بعد تغييرات IAM.

ما القادم

الدرس الثالث ينتقل إلى EC2 — طبقة الحوسبة. كل نسخة EC2 تُطلقها ستمتلك ملف تعريف نسخة IAM (حاوية دور). الأنماط من هذا الدرس — سياسات الثقة وسياسات الصلاحيات ذات الأدنى وتحديد نطاق ARNs الموارد — تُطبَّق مباشرة على كيفية منح نسخ EC2 الوصول إلى S3 وSystems Manager وCloudWatch وأي خدمة AWS أخرى تحتاج استدعاؤها.