{"id":"l-aws-2-1","courseId":"aws-cloud-foundations","lang":"ar","kind":"lesson","summary":"ميّز بين مستخدمي IAM والمجموعات والـ roles، واعرف أين تُرفق السياسات القائمة على الهوية والسياسات القائمة على المورد، وتوقّع هل تسمح AWS بطلب ما باستخدام قاعدة الرفض والسماح والرفض.","html":"

في نهاية القسم الأول شغّلت aws sts get-caller-identity فأجابت AWS. خلف تلك الإجابة، وخلف كل استدعاء آخر، يقف AWS Identity and Access Management (IAM). إنه يجيب عن سؤال واحد مليارات المرات يوميًا: هل يحق لـ هذا الـ principal أن ينفّذ هذا الإجراء على هذا المورد، الآن؟ كان لخادم Lantern القديم جواب واحد لكل شيء: من يملك مفتاح SSH يستطيع فعل أي شيء. يمنحك هذا الدرس المفردات اللازمة لتفعل ما هو أفضل.

\n

تشريح الطلب

\n

كل طلب إلى AWS، سواء من الـ console أو الـ CLI أو الكود، يحمل أربعة أشياء:

\n\n

تتبع الـ ARNs النمط arn:partition:service:region:account-id:resource. وتبقى بعض الأجزاء فارغة حين لا تنطبق:

\n
Text
arn:aws:iam::111122223333:user/amara\narn:aws:s3:::lantern-posters/2026/street-food-festival.jpg\narn:aws:dynamodb:eu-west-1:111122223333:table/lantern-rsvps
\n

IAM خدمة عامّة (global)، لذا لا يحتوي ARN المستخدم على Region. وأسماء الـ buckets في S3 فريدة على مستوى AWS كلها، لذا لا يحتوي ARN الخاص بـ S3 على Region ولا على حساب. أما جداول DynamoDB فإقليمية وتنتمي إلى حساب، لذا يحتوي الـ ARN الخاص بها على الاثنين. ستكتب الـ ARNs باستمرار في الدرس القادم.

\n

الهويات

\n

المستخدمون (users) هويات طويلة الأمد لشخص واحد، أو لتطبيق واحد في الإعدادات القديمة. يمكن أن يكون للمستخدم كلمة مرور للـ console وما يصل إلى مفتاحَي وصول. المستخدمون أقدم أجزاء IAM، وفي القسم الأول أنشأت واحدًا فقط، هو المدير.

\n

المجموعات (groups) تجمّعات من المستخدمين. ترفق السياسات بالمجموعة، فيحصل عليها كل أعضائها. ينشئ Lantern المجموعات Admins وDevelopers وBilling، فعندما ينضم متطوّع أو يغادر، تغيّر عضوية واحدة بدلًا من البحث في الصلاحيات الفردية. المجموعات ليست principals: لا يمكنك تسجيل الدخول كمجموعة، ولا تسمية مجموعة في سياسة bucket.

\n

الـ roles هويات لها صلاحيات لكن بلا بيانات اعتماد طويلة الأمد. يتقمّص principal موثوق الـ role، فتعيد AWS Security Token Service (STS) بيانات اعتماد مؤقتة تنتهي صلاحيتها. وتحدّد سياسة الثقة (trust policy) الخاصة بالـ role من يحق له تقمّصه: دالة Lambda، أو instance في EC2، أو مستخدم في حساب آخر، أو أشخاص سجّلوا الدخول عبر IAM Identity Center. الـ roles هي الطريقة التي يحصل بها الكود على صلاحيات دون أسرار، والدرس الثالث من هذا القسم يبني عليها.

\n
Terminal
aws iam create-group --group-name Developers\naws iam attach-group-policy --group-name Developers \\\n  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess\naws iam add-user-to-group --group-name Developers --user-name sam
\n

أين تعيش السياسات

\n

السياسة (policy) مستند JSON من العبارات (statements) التي تسمح بإجراءات على موارد أو ترفضها. ومكان إرفاقها يغيّر طريقة قراءتها:

\n\n

داخل حساب واحد، يُسمح بالطلب إذا سمح به أيٌّ من النوعين ولم يرفضه شيء. أما عبر الحسابات، فيجب أن يسمح به الطرفان.

\n

كيف يقرّر IAM

\n

قاعدة التقييم تتّسع لها بطاقة صغيرة، وهي تفسّر تقريبًا كل خطأ AccessDenied ستصادفه.

\n
\n مخطّط انسيابي. يفحص الطلب أولًا وجود أي رفض صريح؛ فإن وُجد كانت النتيجة الرفض. وإلا يفحص وجود أي سماح؛ فإن وُجد كانت النتيجة السماح، وإلا كانت النتيجة رفضًا ضمنيًا.\n \n الطلب\n \n \n Deny صريح\n في أي مكان؟\n \n نعم\n \n مرفوض\n \n لا\n \n هل يطابق\n أيُّ Allow؟\n \n نعم\n \n مسموح\n \n لا\n \n مرفوض ضمنيًا\n
الرفض الصريح ينتصر، ثم أي سماح، وإلا فالرفض الافتراضي
\n
    \n
  1. الرفض الافتراضي. كل طلب يبدأ مرفوضًا.
    2. \n
  2. الرفض الصريح ينتصر. إذا احتوت أي سياسة منطبقة على Deny مطابق، فالجواب لا. ولا شيء يستطيع تجاوزه.
    3. \n
  3. السماح الصريح يُجيز. وإلا، إذا احتوت سياسة على Allow مطابق، فالجواب نعم.
    4. \n
  4. لا تطابق يعني لا. إذا لم يسمح بالطلب شيء، يبقى الرفض الافتراضي قائمًا. ويُسمّى هذا الرفض الضمني (implicit deny).
    5. \n
\n

وتضيف الإعدادات الأكبر طبقات أخرى لا تستطيع إلا تضييق ما هو مسموح، مثل سياسات التحكّم في الخدمات (service control policies) في AWS Organizations، وحدود الصلاحيات (permissions boundaries) على مستخدمين وroles بعينهم. تظل القاعدة أعلاه صحيحة؛ كل ما تفعله تلك الطبقات أنها تضيف أماكن أخرى قد يأتي منها الرفض.

\n

يمكنك أن تطلب من IAM تقييم طلب دون تنفيذه:

\n
Terminal
aws iam simulate-principal-policy \\\n  --policy-source-arn arn:aws:iam::111122223333:user/sam \\\n  --action-names s3:DeleteBucket \\\n  --resource-arns arn:aws:s3:::lantern-posters \\\n  --query \"EvaluationResults[].EvalDecision\"
\n

يكون الجواب allowed أو explicitDeny أو implicitDeny، فيخبرك لا بـ هل فقط، بل بـ لماذا أيضًا.

\n\n\n

أصبحت تستطيع قراءة من يسأل وكيف يُتّخذ القرار. في الدرس التالي تكتب السياسات نفسها، سطرًا سطرًا.

\n","toc":[{"id":"sec-1","text":"تشريح الطلب","level":2},{"id":"sec-2","text":"الهويات","level":2},{"id":"sec-3","text":"أين تعيش السياسات","level":2},{"id":"sec-4","text":"كيف يقرّر IAM","level":2}],"takeaways":["يحمل كل طلب إلى AWS أربعة أشياء، هي الـ principal والإجراء والـ ARN الخاص بالمورد والسياق، ويقيّمها IAM كلها قبل أن يحدث أي شيء.","المستخدمون هويات طويلة الأمد، والمجموعات وسيلة لمنح المستخدمين السياسات نفسها، والـ roles هويات بلا بيانات اعتماد طويلة الأمد يتقمّصها principals موثوقون للحصول على بيانات اعتماد مؤقتة.","تُرفق السياسات القائمة على الهوية بالمستخدمين والمجموعات والـ roles؛ أما السياسات القائمة على المورد، مثل سياسات الـ buckets في S3، فتُرفق بالمورد وتسمّي principal.","كل شيء مرفوض افتراضيًا، ويلزم سماح صريح لإجازة أي طلب، والرفض الصريح في أي مكان ينتصر دائمًا."],"further":[{"title":"IAM identities (users, user groups, and roles)","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html"},{"title":"Policy evaluation logic","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html"},{"title":"IAM identifiers (ARNs)","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-identifiers.html"}],"quiz":[{"q":"

ليس لدى Sam، المطوّر في Lantern، أي سياسات تذكر DynamoDB. شغّل Sam الأمر aws dynamodb scan --table-name lantern-rsvps. ماذا يحدث؟

","options":[{"text":"ينجح، لأن لا شيء يرفضه.","why":"يعمل IAM بمبدأ الرفض الافتراضي. يحتاج الطلب إلى سماح صريح من سياسة ما، ولا شيء يسمح بهذا الطلب."},{"text":"يُرفض، لأن لا سياسة تسمح بالإجراء (رفض ضمني).","why":"صحيح. في غياب سماح مطابق، يبقى الرفض الافتراضي قائمًا ويعيد الـ CLI خطأ AccessDenied."},{"text":"ينجح فقط إذا سجّل Sam الدخول باستخدام MFA.","why":"لا يهمّ MFA إلا عندما يتحقّق منه شرط في سياسة ما. ولا يستطيع أن يخلق صلاحيات لا تمنحها أي سياسة."}],"answer":1},{"q":"

سياسة تسمح بـ s3:* على الـ bucket الخاص بملصقات Lantern لمجموعة Developers، وسياسة ثانية ترفض صراحةً s3:DeleteBucket للمجموعة نفسها. حاول مطوّر حذف الـ bucket. ماذا يحدث؟

","options":[{"text":"يُرفض، لأن الرفض الصريح يتغلّب على أي سماح.","why":"صحيح. عبارات الرفض تُفحص أولًا وتنتصر دائمًا، ما يجعلها حاجز حماية موثوقًا."},{"text":"ينجح، لأن السماح الأعمّ أُرفق أولًا.","why":"ترتيب الإرفاق وترتيب العبارات لا يهمّان. يقيّم IAM كل السياسات المنطبقة معًا."},{"text":"ينجح، لأن s3:* أقوى من إجراء منفرد.","why":"الرموز البديلة (wildcards) توسّع فقط ما يطابقه السماح. ولا تتفوّق أبدًا على الرفض."}],"answer":0},{"q":"

أيّ عبارة عن الـ roles في IAM صحيحة؟

","options":[{"text":"للـ role كلمة مرور خاصة به، تشاركها مع الفريق الذي يستخدمه.","why":"ليس للـ roles كلمة مرور ولا مفاتيح وصول طويلة الأمد. وهذه ميزتها الأمنية الرئيسية."},{"text":"الـ role نوع من المجموعات، لذا تضيف المستخدمين إليه.","why":"المجموعات تحتوي مستخدمين؛ أما الـ roles فلا. يتقمّص الـ principal الـ role ويحصل على صلاحياته طوال الجلسة."},{"text":"يتقمّص الـ role principal موثوق، فيحصل على بيانات اعتماد مؤقتة تنتهي صلاحيتها.","why":"صحيح. تحدّد سياسة الثقة (trust policy) الخاصة بالـ role من يحق له تقمّصه، وتُصدر AWS STS بيانات اعتماد تنتهي بعد مدة الجلسة."},{"text":"لا يمكن أن تستخدم الـ role إلا خدمات AWS، ولا يستخدمه البشر أبدًا.","why":"يتقمّص الناس الـ roles طوال الوقت، مثلًا عبر IAM Identity Center أو عند تبديل الـ role في الـ console."}],"answer":2}],"exercise":{"kind":"choice","multiple":true,"options":["sam-get","sam-delete","sam-scan","role-get","group-principal"],"correct":["sam-get","role-get"],"title":"مسموح أم مرفوض؟","prompt":"

كل ما يلي يحدث في حساب AWS الوحيد الخاص بـ Lantern.

\n\n

اختر كل طلب تسمح به AWS.

\n","hints":["مرّر كل طلب عبر الترتيب: هل يوجد رفض صريح في أي مكان؟ ثم هل يوجد أي سماح؟ ثم الرفض الافتراضي.","داخل حساب واحد، يكفي سماح في سياسة قائمة على الهوية أو في سياسة قائمة على المورد، ما دام لا شيء يرفض.","طلبان مسموح بهما. أحدهما تسمح به سياسة الـ bucket وحدها."],"explanation":"

يطابق GetObject الذي ينفّذه Sam السماحَ في سياسة المجموعة ولا شيء يرفضه، فينجح. وDeleteObject الذي ينفّذه Sam تسمح به سياسة المجموعة أيضًا، لكن الرفض الصريح في سياسة الـ bucket ينتصر. أما مسح Sam لجدول DynamoDB فلا يطابق أي سماح في أي مكان، فيبقى الرفض الافتراضي قائمًا. وليس للـ role الخاص بإنشاء الصور المصغّرة سياسات هوية، لكن سياسة الـ bucket تسمّيه كـ principal وتسمح له بـ GetObject؛ وداخل حساب واحد يكفي هذا السماح القائم على المورد. وأخيرًا، المجموعات ليست principals، لذا لا تستطيع سياسة bucket أن تسمّي مجموعة Developers أصلًا؛ وبدلًا من ذلك تمنح المجموعة الصلاحية عبر سياستها القائمة على الهوية.

\n","checkLabels":{},"optionText":{"sam-get":{"text":"ينزّل Sam الملف s3://lantern-posters/2026/street-food-festival.jpg باستخدام aws s3 cp.","why":"مسموح. تسمح سياسة المجموعة بـ s3:GetObject على الكائنات في الـ bucket، ولا ترفضه أي سياسة."},"sam-delete":{"text":"يحذف Sam ملصقًا قديمًا باستخدام aws s3 rm.","why":"مرفوض. تسمح به المجموعة، لكن الرفض الصريح في سياسة الـ bucket ينطبق على كل الـ principals، والرفض الصريح ينتصر دائمًا."},"sam-scan":{"text":"يمسح Sam جدول DynamoDB المسمّى lantern-rsvps.","why":"مرفوض. لا شيء يسمح لـ Sam بأي إجراء في DynamoDB، فهذا رفض ضمني."},"role-get":{"text":"دالة Lambda تعمل بالـ role المسمّى lantern-thumbnailer تقرأ ملصقًا.","why":"مسموح. سياسة الـ bucket سياسة قائمة على المورد تسمّي الـ role وتسمح بالقراءة؛ وداخل حساب واحد يكفي هذا."},"group-principal":{"text":"تُعدَّل سياسة الـ bucket لتسمح بـ s3:PutObject مع جعل مجموعة Developers هي الـ principal، ثم يرفع Sam ملصقًا.","why":"مرفوض، بل إن تعديل السياسة نفسه يفشل في التحقّق. المجموعات ليست principals، لذا لا تستطيع سياسة قائمة على المورد أن تسمّي مجموعة."}}},"words":771,"readMinutes":5}