في منظمة AWS متعددة الحسابات، يحتاج كل فريق وتطبيق وعملية آلية إلى المصادقة. بشكل ساذج، يعني ذلك آلاف مستخدمي IAM المنتشرين عبر عشرات الحسابات، كل منها بسياسة كلمة مرور خاصة وحالة MFA وجدول تدوير مفاتيح وصول مستقل. على النطاق الواسع، ينهار هذا النموذج: قد يحتفظ موظف واحد غادر الشركة بصلاحيات نشطة في سبعة حسابات. اتحاد الهوية يحل هذه المشكلة بجعل مزود الهوية الحالي للشركة (IdP) هو المصدر الوحيد للحقيقة، ويُصدر بيانات اعتماد AWS قصيرة الأجل عند الطلب. لا مستخدمو IAM دائمون، لا مفاتيح وصول طويلة الأمد، ولا ثغرات في إلغاء الصلاحيات.
المفهوم الأساسي: الثقة الموحدة
يعمل الاتحاد عن طريق إنشاء ثقة بين طرفين: مزود الهوية (IdP) — مثل Okta أو Azure AD أو Google Workspace أو أي نظام متوافق مع SAML/OIDC — ومزود الخدمة (SP)، وهو AWS في هذه الحالة. يؤكد مزود الهوية هوية المستخدم (المصادقة) والمجموعات التي ينتمي إليها (السمات). تُعيِّن AWS تلك التأكيدات إلى أدوار IAM وتُصدر بيانات اعتماد مؤقتة عبر STS صالحة لمدة تتراوح بين ساعة و12 ساعة. عند انتهاء صلاحية الجلسة يُعيد المستخدم المصادقة؛ ولا يوجد شيء يستلزم الإلغاء لأن بيانات الاعتماد لا تبقى بشكل دائم.
تدفق الهوية الموحدة: يؤكد مزود الهوية (IdP) الهوية، يُعيِّن IAM Identity Center مجموعات الصلاحيات، ويُصدر STS بيانات اعتماد مؤقتة لكل حساب مستهدف.
SAML 2.0 مقابل OIDC — متى تستخدم كلًا منهما
SAML 2.0 (لغة ترميز تأكيد الأمان) هو المعيار الأقدم المستند إلى XML. هو الخيار الصحيح عندما يكون مزود هويتك المؤسسي هو Okta أو Azure AD أو PingFederate وتريد دمج المستخدمين البشريين في وحدة تحكم AWS أو بوابة IAM Identity Center. رموز SAML كبيرة الحجم لكن الجلسة تعتمد على المتصفح لذا لا يُعدّ الحجم قيدًا عمليًا.
OIDC (OpenID Connect) هو البروتوكول الحديث المبني على JSON/JWT فوق OAuth 2.0. إنه الخيار الصحيح لهويات الأجهزة: سير عمل GitHub Actions، أو وظيفة GitLab CI، أو حساب خدمة Kubernetes يحتاج إلى افتراض دور IAM دون تخزين مفتاح وصول طويل الأمد. رموز OIDC مضغوطة وقابلة للتحقق عبر نقطة نهاية JWKS العامة وتناسب طبيعيًا خطوط الأنابيب الآلية.
قاعدة عمل في شركات التقنية الكبرى: يمر SSO للبشر عبر SAML من خلال IAM Identity Center؛ أما الاتحاد للـ CI/CD وأحمال العمل فيمر عبر OIDC مباشرةً مع مزود هوية IAM. لا تخلط بين حالتَي الاستخدام أبدًا — رموز SAML لا يمكن استخدامها في خطوط أنابيب بلا رأس، وOIDC وحده لا يمنحك بوابة التبديل بين الحسابات التي يحتاجها المهندسون.
AWS IAM Identity Center (خليفة AWS SSO)
IAM Identity Center هو مستوى التحكم الأصلي لـ AWS للوصول الموحد. يعيش في حساب الإدارة، يتزامن مع مزود هويتك عبر SCIM (توفير تلقائي للمستخدمين والمجموعات)، ويتيح لك تعيين مجموعات الصلاحيات (Permission Sets) للمجموعات عبر الحسابات. يمكن لمهندس في مجموعة Okta المسماة platform-engineers الحصول على AdministratorAccess في حسابات الاختبار وReadOnlyAccess في الإنتاج — كل ذلك من عنوان URL بوابة واحدة دون الحاجة إلى مستخدم IAM خاص بالحساب.
يتضمن إعداد Okta كمزود هوية خارجي لـ IAM Identity Center ثلاث خطوات: تسجيل تطبيق AWS في Okta، تنزيل بيانات تعريف SAML من Okta، ورفعها إلى IAM Identity Center. ثم تفعيل SCIM حتى تنتشر تغييرات عضوية المجموعات في Okta تلقائيًا في غضون دقائق بدلًا من إجراء تحديثات IAM يدوية.
# الخطوة 1 — تفعيل IAM Identity Center في حساب الإدارة (مرة واحدة)
# يتم عبر Console أو Control Tower؛ ينشئ دور SSO المرتبط بالخدمة تلقائيًا.
# الخطوة 2 — تكوين Okta كمزود هوية خارجي عبر AWS CLI
aws sso-admin create-identity-provider \
--instance-arn "arn:aws:sso:::instance/ssoins-EXAMPLE" \
--identity-provider-type "SAML" \
--identity-provider-config file://okta-metadata.xml
# الخطوة 3 — إنشاء مجموعة صلاحيات (مثل PlatformEngineer)
aws sso-admin create-permission-set \
--instance-arn "arn:aws:sso:::instance/ssoins-EXAMPLE" \
--name "PlatformEngineer" \
--description "Full access to infra accounts, read-only in prod" \
--session-duration "PT8H" # الحد الأقصى للجلسة 8 ساعات
# إرفاق سياسة AWS المُدارة بمجموعة الصلاحيات
aws sso-admin attach-managed-policy-to-permission-set \
--instance-arn "arn:aws:sso:::instance/ssoins-EXAMPLE" \
--permission-set-arn "arn:aws:sso:::permissionSet/ssoins-EXAMPLE/ps-EXAMPLE" \
--managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"
# الخطوة 4 — تعيين المجموعة ومجموعة الصلاحيات للحساب المستهدف
aws sso-admin create-account-assignment \
--instance-arn "arn:aws:sso:::instance/ssoins-EXAMPLE" \
--target-id "111122223333" \ # معرف حساب AWS
--target-type "AWS_ACCOUNT" \
--permission-set-arn "arn:aws:sso:::permissionSet/ssoins-EXAMPLE/ps-EXAMPLE" \
--principal-type "GROUP" \
--principal-id "abcd1234-OKTA-GROUP-ID" # من مزامنة SCIM
اتحاد OIDC لخطوط أنابيب CI/CD
أهم نمط لهوية الأجهزة في DevOps الحديث هو اتحاد OIDC لـ CI/CD. بدلًا من تخزين AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY كأسرار في المستودع (التي تُدار بشكل سيئ وتتسرب عبر حوادث السجلات)، تُبادل خط الأنابيب رمز OIDC قصير الأجل صادرًا من GitHub Actions (أو GitLab CI أو CircleCI وغيرها) مقابل بيانات اعتماد AWS مؤقتة عبر sts:AssumeRoleWithWebIdentity. تُحدد سياسة ثقة IAM أي المستودعات والفروع يمكنها افتراض الدور — لا يمكن لرمز مسرَّب من نسخة مشتقة (fork) افتراض دور النشر في بيئة الإنتاج.
# Terraform: إنشاء مزود OIDC لـ GitHub Actions (مرة واحدة لكل حساب)
resource "aws_iam_openid_connect_provider" "github" {
url = "https://token.actions.githubusercontent.com"
client_id_list = ["sts.amazonaws.com"]
thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}
# دور IAM الذي يمكن لسير عمل GitHub Actions افتراضه
resource "aws_iam_role" "github_deploy" {
name = "github-actions-deploy"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Federated = aws_iam_openid_connect_provider.github.arn }
Action = "sts:AssumeRoleWithWebIdentity"
Condition = {
StringEquals = {
"token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
}
StringLike = {
# فقط الفرع الرئيسي لمستودع محدد يمكنه النشر في الإنتاج
"token.actions.githubusercontent.com:sub" =
"repo:acme-org/platform:ref:refs/heads/main"
}
}
}]
})
}
# خطوة سير عمل GitHub Actions (بدون أسرار مخزنة)
# jobs:
# deploy:
# permissions:
# id-token: write # مطلوب — يمنح الوظيفة رمز OIDC
# contents: read
# steps:
# - uses: aws-actions/configure-aws-credentials@v4
# with:
# role-to-assume: arn:aws:iam::111122223333:role/github-actions-deploy
# aws-region: us-east-1
خطأ شائع في الإنتاج — شروط ثقة واسعة جدًا: خطأ شائع هو ضبط شرط sub على repo:acme-org/* (حرف بديل لجميع المستودعات) أو إغفال قيد الفرع كليًا. هذا يعني أن أي مستودع في مؤسستك على GitHub — بما في ذلك مستودع مُخترق أو جديد — يمكنه افتراض دور النشر في الإنتاج. دائمًا حدد المستودع والفرع المحددين. للبيئات متعددة، أنشئ أدوارًا منفصلة لكل بيئة بشروط مقيدة بالفرع: refs/heads/main للإنتاج، refs/heads/release/* للاختبار.
إعداد ملف تعريف AWS CLI لـ SSO
يُصادق المهندسون عبر بوابة IAM Identity Center ثم يستخدمون aws sso login لملء بيانات الاعتماد المحلية. يدعم AWS CLI الإصدار 2 ملفات تعريف مدعومة بـ SSO أصليًا. كل ملف تعريف يُعيَّن إلى مجموعة حساب + مجموعة صلاحيات، مما يتيح للمهندسين التبديل بين السياقات باستخدام --profile أو متغير البيئة AWS_PROFILE.
# ~/.aws/config — ملف تعريف واحد لكل حساب/دور يحتاجه المهندس
[profile platform-sandbox]
sso_session = acme-sso
sso_account_id = 111122223333
sso_role_name = PlatformEngineer
region = us-east-1
output = json
[profile platform-prod-readonly]
sso_session = acme-sso
sso_account_id = 444455556666
sso_role_name = ReadOnlyAccess
region = us-east-1
output = json
[sso-session acme-sso]
sso_start_url = https://acme.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access
# المصادقة (يفتح المتصفح، يخزن الرمز مؤقتًا لمدة 8 ساعات)
aws sso login --sso-session acme-sso
# استخدام حساب محدد — بدون مطالبات MFA ولا دوران مفاتيح
aws s3 ls --profile platform-prod-readonly
aws ec2 describe-instances --profile platform-sandbox
اعتبارات الحوكمة والتدقيق
كل استدعاء لـ AssumeRole يُسجَّل في AWS CloudTrail مع إرفاق هوية مصدر الاتحاد (حقل sourceIdentity). هذا يعني أنه يمكنك الإجابة على سؤال "من وصل إلى قاعدة بيانات الإنتاج في الساعة الثانية صباحًا" باستعلام Athena واحد عبر بحيرة CloudTrail للمؤسسة — عنوان البريد الإلكتروني للموظف، لا ARN دور مجهول. طبِّق sts:SetSourceIdentity في حدود مجموعة صلاحيات IAM Identity Center واشترطها في جميع سياسات التحكم في الخدمة حتى لا يتمكن أي خط أنابيب من افتراض دور دون نشر الهوية الأصلية.
قرار معماري محوري: مركِّز الهوية في مزود هوية واحد ولا تنشئ أبدًا مستخدمي IAM دائمين للبشر في حسابات الأعضاء. تعامل مع مستخدمي IAM كآلية طوارئ فحسب (واحد لكل حساب، محمي بـ MFA، بيانات اعتماده في Secrets Manager، وصوله مُسجَّل وخاضع للتنبيه). في اللحظة التي تسمح فيها للفرق بإدارة مستخدمي IAM ذاتيًا، ينهار نموذج الثقة الموحدة — يكفي مفتاح مُشفَّر مباشرةً في مستودع GitHub واحد لتعريض الحساب بأكمله للخطر.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية