الهوية المتقدمة: Organizations وIdentity Center

في الجزء الثاني كان عندنا حساب واحد وكم مستخدم. الحين تخيل شركة فيها خمسين حساب وخمسمية موظف: إنشاء مستخدم في كل حساب لكل شخص بيكون كابوس، وغلطة وحدة ممكن توصل لكل شي.

هذا الجزء يغطي أدوات هذا الحجم، ويكمل IAM باللي تركناه في البداية.

AWS Organizations #

Organizations يجمع عدة حسابات تحت حساب إدارة واحد، مرتبة في وحدات تنظيمية (OUs).

ليه حسابات كثيرة، مو حساب واحد كبير؟

• العزل: غلطة أو اختراق في حساب التطوير ما توصل للإنتاج.
• تكاليف واضحة: كل حساب يبين فاتورة فريقه.
• الحدود: كل حساب له حصص خدماته.

ووش تكسب من Organizations؟

• فاتورة موحدة: فاتورة وحدة، والاستخدام المجمع يوصل لخصومات الكمية أسرع. وSavings Plans وReserved Instances ممكن تتشارك بين الحسابات.
• إدارة مركزية: إنشاء حسابات عبر API، وCloudTrail Trail واحد للكل.
• السياسات: قواعد تنطبق على مجموعات كاملة من الحسابات.

سياسات المنظمة #

Service Control Policies (SCP) #

النقطة الأهم: SCP ما تعطي أي شي. تحدد سقف بس، وكل مستخدم لسا يحتاج صلاحية IAM. هي سقف على المسموح:

• لما تنربط بـ OU تنطبق على كل اللي تحتها، ولازم كل مستوى يسمح بالإجراء.
• ما تأثر على حساب الإدارة، فلا تشغّل شغلك فيه.
• تنطبق على الكل في الحساب العضو، ومعهم Root حق الحساب.

مثلاً هذي الـ SCP تمنع الشغل خارج منطقتين، إلا الخدمات العالمية:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OnlyTwoRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["me-central-1", "eu-west-1"] }
    }
  }]
}

الشروط في سياسات IAM #

عنصر Condition في السياسة يضيق متى تنطبق الصلاحية. وهذي أشهرها:

والأخير هدية للحاويات المشتركة. بدل ما تعدد خمسين حساب في سياسة الحاوية، سطر واحد يسمح لمنظمتك كلها:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::shared-files/*",
  "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } }
}

غلطة S3 الكلاسيكية #

إجراءات S3 تشتغل على مستويين، وكل واحد يحتاج ARN خاص فيه:

حط الغلط ويجيك AccessDenied، مهما بدت السياسة صحيحة. وبنجرب هذا في التجربة العملية.

دور أو سياسة مورد؟ #

عشان تخلي مستخدم في حساب A يوصل لشي في حساب B، عندك طريقين:

ووراء كل دور تفترضه خدمة AWS STS (Security Token Service). هي اللي تعطي الصلاحيات المؤقتة، وتنتهي لحالها. وبهذي الطريقة يشتغل الوصول بين الحسابات بدون مشاركة مفاتيح طويلة المدى: مستخدم أو خدمة تنادي AssumeRole، وSTS تفحص سياسة الثقة في الدور، وترجع مفاتيح تشتغل فترة محدودة.

حدود الصلاحيات (Permissions Boundaries) #

تبي قادة الفرق ينشئون أدوار لخدماتهم، بدون ما يقدرون يعطون أحد أكثر مما لازم. Permissions Boundary يحدد الحد الأقصى لمستخدم أو دور معين، ومثل SCP ما يعطي شي.

والصلاحية الفعلية هي المسموح في سياسة الهوية والحد وSCP مع بعض. وهي طريقة ممتازة للتفويض بأمان.

كيف تقرر AWS؟ #

كل طلب يمر بهذا التفكير. وهذي نسخة مبسطة:

تذكر ثلاث قواعد: المنع الصريح يكسب دايماً، وأي شي غير مسموح ممنوع، وداخل الحساب الواحد، سياسة المورد تقدر تعطي الوصول لحالها في حالات كثيرة.

IAM Identity Center: دخول واحد #

بدل مستخدم في كل حساب، IAM Identity Center يعطي كل موظف دخول واحد وبوابة فيها الحسابات والأدوار المتاحة له، وياخذ بيانات دخول مؤقتة بدون مفاتيح دائمة.

وللـ CLI، الأمر aws configure sso يسجل دخولك عبر المتصفح ويعطيك بيانات مؤقتة. وهذي الطريقة الموصى فيها للناس عشان يشتغلون مع AWS هالأيام، بدل مستخدمي IAM بمفاتيح طويلة الأمد.

الدخول من هوية خارجية (Federation) #

Federation يعني أشخاص أو أنظمة يدخلون بهوية موجودة خارج AWS وياخذون صلاحيات مؤقتة، بدون إنشاء مستخدم IAM. واختيارك يعتمد على مين يدخل:

Active Directory على AWS #

شركات كثيرة تحفظ مستخدميها في Microsoft Active Directory. وAWS Directory Service يربطه بـ AWS:

AWS Control Tower #

تجهيز كل هذا بيدك ياخذ أسابيع. Control Tower يبني Landing Zone بأفضل الممارسات فوق Organizations، ومعها حسابات السجلات والتدقيق، ويضيف:

• Account Factory: إنشاء حسابات جديدة بإعدادات جاهزة.
• Controls: وقائية عبر SCP، وكشفية عبر Config، واستباقية تفحص الموارد قبل إنشائها.
• لوحة: تبين الملتزم من غيره بنظرة وحدة.

لو تبدأ بيئة حسابات متعددة من الصفر، ابدأ من هنا.

عملي: اختبر السياسات بدون ما تلمس شي #

محاكي السياسات يقيّم السياسة بدون ما ينشئ شي أو ينفذ الإجراء، وهذا ممتاز للتعلم. من CloudShell، اكتب سياسة تسمح بـ S3 وEC2، وحد يسمح بـ S3 فقط:

cat > identity.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:*", "ec2:*"],
    "Resource": "*"
  }]
}
EOF

cat > boundary.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}
EOF

اختبر ثلاث إجراءات بالسياسة لحالها:

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --action-names s3:GetObject ec2:RunInstances iam:CreateUser \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

S3 وEC2 يطلع لهم allowed، وIAM يطلع له implicitDeny لأن ما فيه شي يسمح به. الحين أضف الحد:

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --permissions-boundary-policy-input-list file://boundary.json \
  --action-names s3:GetObject ec2:RunInstances \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

EC2 صار implicitDeny، مع إن السياسة تسمح به. الحين شوف إن المنع يكسب دايماً، بإضافة منع صريح لحذف الحاويات:

cat > deny.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "s3:DeleteBucket",
    "Resource": "*"
  }]
}
EOF

aws iam simulate-custom-policy \
  --policy-input-list file://identity.json file://deny.json \
  --action-names s3:GetObject s3:DeleteBucket \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

s3:GetObject يبقى allowed، وs3:DeleteBucket يطلع له explicitDeny، مع إن السياسة الأولى تسمح بـ s3:*. جرب بعدها شرط: الوصول من شبكة المكتب فقط، واختبر من عنوانين:

cat > office.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "*",
    "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
  }]
}
EOF

for ip in 203.0.113.10 198.51.100.7; do
  aws iam simulate-custom-policy --policy-input-list file://office.json \
    --action-names s3:GetObject \
    --context-entries "ContextKeyName=aws:SourceIp,ContextKeyValues=$ip,ContextKeyType=ip" \
    --query "EvaluationResults[0].EvalDecision" --output text
done

العنوان الأول allowed، والثاني implicitDeny. وأخيراً، غلطة S3 الكلاسيكية، صلاحية عرض مع ARN الكائن:

cat > list.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::shop/*"
  }]
}
EOF

aws iam simulate-custom-policy --policy-input-list file://list.json \
  --action-names s3:ListBucket --resource-arns arn:aws:s3:::shop \
  --query "EvaluationResults[0].EvalDecision" --output text

يطلع implicitDeny. السياسة تبدو صحيحة، بس الصلاحية تنطبق على الحاوية، مو على اللي فيها. غيّر المورد إلى arn:aws:s3:::shop وجرب مرة ثانية، وبيطلع allowed.

الخلاصة #

• Organizations يجمع الحسابات تحت فاتورة وحدة، وSCP تحدد سقف وما تعطي شي.
• الشروط تضيق الصلاحيات بالشبكة والمنطقة وMFA والوسوم، وaws:PrincipalOrgID يفتح الوصول لمنظمتك فقط.
• الدور يخليك تترك صلاحياتك الأصلية، وسياسة المورد تبقيها.
• Permissions Boundary يفوض بأمان، والمنع الصريح يكسب دايماً.
• Identity Center يعطي دخول واحد ببيانات مؤقتة، وControl Tower يبني كل هذا بأفضل الممارسات.

اختبر نفسك #

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

ضبطت مين يوصل لبياناتك. طيب لو وصل لها أحد بأي طريقة، أو هاجم موقعك من برا؟ في الجزء السابع والعشرين نغطي التشفير والأسرار والحماية من الهجمات.