شبكات AWS والهوية

أدوار وسياسات IAM بعمق

18 دقيقة الدرس 7 من 28

أدوار وسياسات IAM بعمق

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

كيف يعمل افتراض الدور

دور IAM ليس هوية تسجّل الدخول بها — بل هو مجموعة صلاحيات يمكن لأي مبدأ موثوق افتراضها بصورة مؤقتة. عندما تفترض نسخة EC2 أو دالة Lambda أو خط أنابيب CI/CD أو مستخدم بشري دوراً، يُصدر AWS STS (خدمة رموز الأمان) بيانات اعتماد قصيرة العمر: AccessKeyId وSecretAccessKey وSessionToken تنتهي صلاحيتها (ساعة واحدة افتراضياً، وقابلة للضبط حتى 12 ساعة).

لعملية الافتراض بوّابتان. البوّابة الأولى هي سياسة الثقة — من المسموح له باستدعاء sts:AssumeRole. البوّابة الثانية هي سياسة الصلاحيات المُرفقة بالدور — ما الذي تستطيع الجلسة الناتجة فعله. يجب أن تنجح كلتا البوّابتين. هذا النموذج المزدوج هو ما يجعل الأدوار أكثر أماناً جوهرياً من مفاتيح الوصول طويلة الأمد.

تدفق افتراض دور IAM: بوّابتا تفويض بالإضافة إلى حدّ اختياري للصلاحيات يقيّد الجلسة.

سياسات الثقة — البوّابة الأولى

سياسة الثقة هي سياسة JSON مُرفقة بالدور نفسه. إنها تجيب على سؤال: أي المبادئ مسموح لها باستدعاء sts:AssumeRole على هذا الدور؟ يمكن أن يشير عنصر Principal إلى حسابات AWS أو مستخدمين/أدوار IAM محددين أو خدمات AWS (مثل ec2.amazonaws.com لملفات تعريف النسخة) أو هويات OIDC/SAML المُتحدة.

# سياسة ثقة لخط أنابيب CI عابر للحسابات يفترض دور نشر
# تمنح هذا الإذن لـ GitHub Actions (OIDC) ولدور محدد في الحساب 222222222222
# مع تطبيق شروط الجلسة إلزامياً

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGitHubOIDC",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/main"
        }
      }
    },
    {
      "Sid": "AllowCrossAccountPipeline",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:role/PipelineOrchestrator"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "prod-deploy-external-id-abc123"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

هجوم النائب المُربَك (Confused Deputy): عندما تفترض خدمة SaaS خارجية دوراً في حسابك مستخدمةً معرّف حسابك فقط كدليل، يستطيع مهاجم خبيث خداع تلك الخدمة للعمل على حساب عميل آخر. اشترط دائماً sts:ExternalId في سياسة الثقة عند منح الوصول لخدمات خارجية. يجب أن يكون المعرّف الخارجي فريداً لكل عميل ويُعامَل كسرّ مشترك بينك وبين المورّد.

سياسات الصلاحيات — البوّابة الثانية

تحدد سياسات الصلاحيات ما الذي يمكن للجلسة فعله. تُقيّم AWS هذه السياسات بنموذج "الرفض الصريح أولاً": أي عبارة Deny مُطابِقة في أي سياسة — سياسة هوية أو سياسة موارد أو SCP أو حد صلاحيات — تتجاوز كل Allow. احفظ ترتيب التقييم: SCPs ← سياسات الموارد ← سياسات الهوية ← حدود الصلاحيات ← سياسات الجلسة.

يجب أن تتبع الأدوار الإنتاجية مبدأ أقل صلاحية بصرامة. استخدم ARNs محددة للموارد بدلاً من *، وحدّد الشروط لـ VPCs أو علامات بعينها، ولا تمنح أبداً iam:* أو sts:AssumeRole على * لأدوار الأحمال العملية.

# دور نشر بأقل صلاحية — يسمح بتحديثات مهام ECS في مجموعة prod فقط
# مقيّد بـ ARN المورد وشرط علامة مطلوبة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ECSDeployProd",
      "Effect": "Allow",
      "Action": [
        "ecs:UpdateService",
        "ecs:DescribeServices",
        "ecs:DescribeTaskDefinition",
        "ecs:RegisterTaskDefinition"
      ],
      "Resource": [
        "arn:aws:ecs:us-east-1:111111111111:cluster/prod",
        "arn:aws:ecs:us-east-1:111111111111:service/prod/*",
        "arn:aws:ecs:us-east-1:111111111111:task-definition/prod-*"
      ]
    },
    {
      "Sid": "ECRPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:GetAuthorizationToken"
      ],
      "Resource": "arn:aws:ecr:us-east-1:111111111111:repository/prod-*"
    },
    {
      "Sid": "DenyDeleteResources",
      "Effect": "Deny",
      "Action": [
        "ecs:DeleteCluster",
        "ecs:DeleteService",
        "ecr:DeleteRepository"
      ],
      "Resource": "*"
    }
  ]
}

حدود الصلاحيات — تقييد التفويض

حدّ الصلاحيات هو سياسة مُدارة تُرفق بدور IAM (أو مستخدم) وتعمل بمثابة سقف لما يمكن لتلك الهوية فعله في أي وقت — حتى لو أُرفقت سياسات أكثر تسامحاً لاحقاً. الصلاحيات الفعلية هي تقاطع سياسات الصلاحيات والحدّ.

حالة الاستخدام الإنتاجية الكلاسيكية: تريد أن يستطيع خط أنابيب CI/CD إنشاء أدوار IAM للخدمات المصغّرة، لكنك لا تريد أن تتجاوز تلك الأدوار المُنشأة صلاحيات خط الأنابيب نفسه. تُطبّق هذا باشتراط أن يكون لكل دور ينشئه خط الأنابيب الحدّ ذاته.

# إرفاق حدّ صلاحيات عند إنشاء دور — عبر AWS CLI
aws iam create-role \
  --role-name microservice-reader \
  --assume-role-policy-document file://trust.json \
  --permissions-boundary arn:aws:iam::111111111111:policy/ServiceBoundary

# تقيّد سياسة صلاحيات خط الأنابيب CreateRole + PutRolePermissionsBoundary:
{
  "Sid": "AllowCreateRoleWithBoundary",
  "Effect": "Allow",
  "Action": [
    "iam:CreateRole",
    "iam:AttachRolePolicy",
    "iam:PutRolePermissionsBoundary"
  ],
  "Resource": "arn:aws:iam::111111111111:role/microservice-*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/ServiceBoundary"
    }
  }
}

بدون شرط Condition على iam:PermissionsBoundary، يستطيع خط أنابيب يملك iam:CreateRole إنشاء دور بلا حدود وبصلاحيات AdministratorAccess كاملة — وهو مسار تصعيد صلاحيات كلاسيكي مُوثّق في أبحاث أمان AWS. اقرن دائماً iam:CreateRole بهذا الشرط.

شروط السياسة — التحكم الدقيق

الشروط هي الميزة الأقل استخداماً في IAM. تتيح لك جعل الصلاحيات حساسة للسياق: اشترط MFA، وقيّد على عناوين IP أو VPCs محددة، واشترط التشفير، أو اربط بعلامات الموارد. مشغّلات الشروط محددة النوع: StringEquals وArnLike وIpAddress وBool وNumericLessThan وDateGreaterThan، وغيرها.

مفاتيح الشروط الأساسية لتعزيز الأمان في الإنتاج:

aws:MultiFactorAuthPresent — اشتراط MFA للإجراءات الحساسة
aws:SourceVpc / aws:SourceVpce — تقييد وصول S3 على حركة المرور من VPC
aws:RequestedRegion — رفض الإجراءات خارج المناطق المعتمدة
aws:PrincipalTag / aws:ResourceTag — التحكم في الوصول القائم على الخصائص (ABAC)
s3:x-amz-server-side-encryption — رفض رفع الملفات إلى S3 بدون تشفير
ec2:InstanceType — تقييد أنواع النسخ التي يمكن للمطورين إطلاقها

ABAC على نطاق واسع: في المنظمات الكبيرة (مقياس Netflix وAirbnb)، تتضخم RBAC (دور واحد لكل فريق/خدمة) إلى آلاف الأدوار. يضغط التحكم في الوصول القائم على الخصائص (ABAC) عبر aws:PrincipalTag وaws:ResourceTag هذا الحجم: دور واحد، مبادئ كثيرة، وصول مقيّد ديناميكياً بعلامات مثل team=payments. ضع علامات على كل مورد باتساق واستخدم سياسة SCP لإلزام وضع العلامات عند الإنشاء.

أنماط التشغيل

ملفات تعريف النسخة هي كيفية حصول EC2 على دور — تُرفق الدور بملف تعريف النسخة، ويوزّع خدمة بيانات تعريف EC2 (http://169.254.169.254/latest/meta-data/iam/security-credentials/ أو ما يعادله في IMDSv2) بيانات اعتماد تتجدد تلقائياً. فعّل دائماً IMDSv2 (وضع اشتراط الرمز) لمنع سرقة بيانات الاعتماد عبر ثغرات SSRF.

الأدوار المرتبطة بالخدمة تُنشئها خدمات AWS مسبقاً (مثل AWSServiceRoleForECS) بسياسات ثقة مقيّدة بالخدمة. لا يمكنك تعديل سياسات ثقتها، فقط سياسات صلاحياتها.

استخدم aws sts get-caller-identity للتحقق من هوية بيانات الاعتماد الحالية. استخدم aws iam simulate-principal-policy لاختبار منطق السياسة قبل النشر — ضروري لتصحيح "Access Denied" في بيئات متعددة السياسات.

# التحقق من الهوية الحالية (يعمل مع الأدوار — يُظهر ARN الدور المفترض)
aws sts get-caller-identity

# محاكاة قدرة دور على تنفيذ إجراء على مورد
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111111111111:role/microservice-reader \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::prod-artifacts/builds/*

# التحقق من سياسة ثقة الدور
aws iam get-role --role-name my-deploy-role \
  --query 'Role.AssumeRolePolicyDocument'

# سرد جميع السياسات المُرفقة بالدور
aws iam list-attached-role-policies --role-name my-deploy-role
aws iam list-role-policies --role-name my-deploy-role   # السياسات المُدمجة

تسريب بيانات الاعتماد عبر CloudTrail: كل استدعاء AssumeRole يُسجَّل باسم الجلسة في CloudTrail تحت أحداث sts:AssumeRole. حدد دائماً --role-session-name ذا دلالة (مثل ci-pipeline-run-12345) حتى يتمكن فريق الأمان من تتبع أي تشغيل لخط الأنابيب أنتج أي استدعاءات API. لا تستخدم أبداً أسماء عامة مثل session1.