الوصول الآمن بين حسابات AWS

المهارة والحد

تقرر هذه المهارة من يستطيع طلب دور في حساب آخر، وماذا يستطيع فعله بعد تسلم جلسة ذلك الدور، وما القيد التنظيمي الذي قد يمنع الفعل رغم وجود إذن في IAM. لا يعني ظهور زر «تبديل الدور» نجاح الوصول إلى البيانات، ولا تعني سياسة الثقة إذن القراءة. المثال التالي تدريب على تحليل سياسة، وليس تعليمات لنشر مورد فعلي. أرقام الحسابات والأسماء افتراضية. يرتبط الدرس بمهمة 1.1 من مخطط SAA-C03: تصميم الوصول الآمن إلى موارد AWS.

نموذج القرار

افصل الطلب إلى عمليتين. الأولى هي `sts:AssumeRole`: لدى هوية المصدر إذن لاستدعائها على ARN الدور الهدف، وتقبلها سياسة ثقة الدور الهدف. الثانية هي استعمال بيانات الاعتماد المؤقتة للدور: تسمح سياسة أذونات الدور بالفعل على المورد المحدد، ولا يحجبه `Deny` صريح أو قيد نافذ في سياسات المؤسسة أو المورد أو المفتاح. سياسة الثقة تحدد من يمكنه تسلم الدور؛ سياسة الأذونات تحدد ما يمكن للجلسة فعله. لا تمنح سياسة التحكم بالخدمة SCP إذنًا بحد ذاتها، بل تحد أقصى الأذونات الممكنة للحسابات الأعضاء؛ لا تطبق على هويات حساب إدارة المؤسسة. يجب تحديد نوع الحساب قبل الاحتجاج بها.

ابدأ بالفاعل والفعل والمورد، لا باسم الخدمة وحده. إذا احتاج محلل إلى قراءة تقارير شهرية في بادئة واحدة من S3، فاكتب `s3:ListBucket` على ARN الحاوية مع شرط البادئة، و`GetObject` على ARN الكائنات في تلك البادئة. صلاحية `GetObject` على ARN الحاوية وحدها لا تصف مورد الكائن الصحيح. ولا يلزم منح `PutObject` لمجرد أن الخدمة S3. إذا كانت الكائنات مشفرة بمفتاح KMS يديره العميل، افحص سماح فك التشفير وسياسة المفتاح أيضًا؛ لا يفترض هذا المثال تشفير KMS، ولذلك لا يضيف إذنًا زائدًا صوريًا.

حالة محلولة

حل الحالة يبدأ بتحديد موضع الفشل: استدعاء STS ينجح، لأن إذن المصدر والثقة متوافقان. الفشل في العملية الثانية، لا في تبديل الدور. أضف إلى سياسة الدور الهدف `s3:GetObject` على `arn:aws:s3:::monthly-reports-demo/2026/*`، وقيّد `s3:ListBucket` على `arn:aws:s3:::monthly-reports-demo` بشرط `s3:prefix` الموافق للبادئة المطلوبة. لا تمنح `s3:*` ولا ARN `*`. اختبر كائنًا داخل `2026/` فينجح، وكائنًا في `2025/` فيُرفض، وطلب كتابة فيُرفض. افحص سجل CloudTrail وقرار المحاكي حيث ينطبق، لأن نتيجة الاختبار الفعلية تكشف سياسات أو شروطًا لم تتضمنها معطيات الورقة.

جدول القرار: `AssumeRole` مسموح في المصدر + ثقة الهدف = جلسة مؤقتة؛ `ListBucket` على الحاوية مع البادئة = سرد محدود؛ `GetObject` على الكائنات داخل `2026/*` = قراءة محدودة؛ `PutObject` غير ممنوح = لا كتابة. إذا أظهرت المؤسسة SCP يحظر `s3:GetObject` في الحساب الهدف، فلن يصلح توسيع سياسة IAM: اطلب مراجعة الحاجز التنظيمي ضمن صلاحيات المؤسسة، أو غيّر التصميم وفق السياسة، ولا تتجاوز الحاجز. هذا مثال مضاد محدد: يتغير القرار من «إضافة إذن الدور» إلى «حل التعارض التنظيمي»، مع بقاء الحاجة إلى إذن الدور بعد رفع الحظر.

لتحويل القرار إلى مسودة سياسة قابلة للمراجعة، اكتب ثلاثة أسطر منفصلة بدل عبارة «امنح وصول S3». سطر المصدر: `Action=sts:AssumeRole` و`Resource=arn:aws:iam::444455556666:role/ReadMonthlyReports`. سطر ثقة الهدف: `Principal=arn:aws:iam::111122223333:role/ReportAnalyst` و`Action=sts:AssumeRole`. سطر أذونات الهدف: `Action=s3:GetObject` و`Resource=arn:aws:s3:::monthly-reports-demo/2026/*`. يضاف سطر مستقل للسرد على ARN الحاوية مع شرط البادئة، لأن ARN الكائن لا يصلح لفعل السرد. هذه صياغة تحليلية مختصرة لا ملف JSON صالحًا للتطبيق؛ يلزم عند التنفيذ بناء مستندات السياسة بصيغ AWS والتحقق من شروطها ونطاقها.

افحص أيضًا نوع الثقة قبل نسخ هذه المسودة إلى حالة أخرى. إذا كان الفاعل مزودًا خارجيًا يدير حسابه هو، فتعريف الحساب الموثوق وحده قد يفتح باب «النائب الحائر» إذا استعمل المزود الدور لخدمة عميل مختلف؛ تعالج حالة الطرف الثالث المناسبة بشرط ExternalId صادر ومُدار وفق تصميم العلاقة، مع التحقق من أن العميل الصحيح فقط يعرف القيمة المخصصة. أما منح موظفي المؤسسة وصولًا بين حسابين تملكهـما المؤسسة في المثال، فلا تفرض ExternalId لمجرد أن الحسابين مختلفان. وإذا كان المستخدمون يدخلون عبر مركز هوية IAM Identity Center، فتتغير إدارة هوية المصدر، لكن تحليل الثقة والأذونات والحواجز بعد تكوين الجلسة يظل لازمًا. هذه الفروق تحدد قرار التصميم؛ ليست قائمة مفردات للحفظ.

اختبار القرار في بيئة متعددة الحسابات يبدأ بطلبين منفصلين في سجل الأحداث. في الأول حدّد ARN الدور الذي حاول الفاعل افتراضه والهوية التي وصلت إلى سياسة الثقة؛ إذا فشل هنا فلا معنى لتغيير سياسة S3. في الثاني استعمل هوية الجلسة المؤقتة لا هوية المصدر عند تفسير قراءة الكائن. افحص فعل GetObject وARN الكائن، ثم أي شرط على بادئة ListBucket وأذونات مفتاح KMS إذا كان التشفير معطى في الحالة. النتيجة المرغوبة ليست نجاح طلب واحد فقط: يجب أن تنجح قراءة كائن مقصود، وأن تُرفض قراءة بادئة أخرى والكتابة، وأن يبقى سبب الرفض مفهومًا. إذا كانت سياسة مورد تمنح الإذن مباشرة لنوع هوية مختلف، غيّر رسم مسار الأذن بدل نسخ سياسة الدور آليًا. هذا التفريق يفسر لماذا قد يظهر تبديل الدور ناجحًا بينما لا يزال الوصول إلى التقرير محجوبًا.

تمرين ومراجعة الناتج

خلاصة الاستعداد

في أسئلة الشهادة، اقرأ عبارة مثل «يستطيع تبديل الدور لكن قراءة الكائن مرفوضة» بوصفها دليلًا على نجاح مرحلة الثقة، لا دليلًا على كفاية أذونات المورد. ابدأ بأول طلب فاشل ثم تحقق من ARN الفعل والمورد والشروط والحواجز. قد تسمح سياسة مورد S3 بنمط وصول مختلف؛ لا تعمم وصفة الدور على كل مشاركة عبر الحسابات. المطلوب تفسير قرار الوصول من معطيات السؤال، لا حفظ سياسة JSON واحدة لكل حالة.