تصعيد امتيازات AWS IAM: كيف تتشكل مسارات الهجوم وكيفية كسرها

بقلم فريق Pathbreak · 11 أغسطس 2026 · قراءة 7 دقائق

تتكشف كل حادثة AWS خطيرة تقريباً بالطريقة نفسها. يهبط مهاجم على هوية منخفضة الامتيازات، مفتاح وصول مسرّب، أو دور CI مخترق، أو بيانات اعتماد تطبيق، وخلال بضع خطوات يصبح مديراً. في معظم هذه الحالات لا توجد ثغرة يوم الصفر. يستخدم المهاجم أذونات وزّعها الحساب عن قصد، في تركيبة لم يقصدها أحد.

تلك التركيبة هي مسار تصعيد امتيازات IAM. يستعرض هذا المقال كيف تتشكل تلك المسارات في AWS، وتركيبات الأذونات التي تنشئها، ولماذا تختبئ عن المراجعة العادية، وكيفية العثور عليها وكسرها.

ما هو تصعيد امتيازات IAM؟

تصعيد امتيازات IAM هو عندما تستخدم هوية الوصول الذي تملكه بالفعل لتمنح نفسها، أو تصل إلى، وصول أكبر مما كان مقصوداً لها. في AWS يحدث هذا دائماً تقريباً على مستوى التحكم، أي واجهة API التي تدير الهويات والأذونات، لا باقتحام حمل عمل.

يفعل AWS تماماً ما أمرته به. إذا كانت هوية تستطيع تعديل سياسة، أو تمرير دور، أو إنشاء مفتاح، فإن AWS يسمح لها. يأتي التصعيد عادةً من إذن مُنح عن قصد، بأثر من الدرجة الثانية لم يتتبعه أحد.

كيف تتشكل مسارات تصعيد الامتيازات

تندرج معظم مسارات التصعيد في AWS ضمن حفنة من العائلات. لا يتطلب أي منها مديراً. كل واحدة تأخذ إذن كتابة ضيقاً وتحوّله إلى سلطة واسعة.

تمرير دور إلى خدمة تتحكم بها

الأكثر شيوعاً هو iam:PassRole مقترناً بخدمة حوسبة. إذا كانت هوية تستطيع تمرير دور مميّز إلى مثيل EC2، أو دالة Lambda، أو مهمة ECS، أو وظيفة Glue، وتستطيع أيضاً تشغيل تلك الخدمة، فيمكنها تشغيل التعليمات البرمجية بصفة الدور المميّز ووراثة أذوناته. استعارت الهوية دوراً يملك الأذونات التي كانت تفتقر إليها. ولهذا فإن iam:PassRole هو الإذن الذي يجب مراقبته عن كثب، ولهذا ينبغي دائماً تقييده بأي الأدوار يمكن تمريرها وإلى أي خدمة.

إعادة كتابة سياسة يُسمح لك بتعديلها

إذا كانت هوية تملك iam:CreatePolicyVersion، فيمكنها نشر نسخة جديدة من سياسة مُدارة من قبل العميل بأي أذونات تشاء، ثم تعيين تلك النسخة كنسخة افتراضية. تتحوّل سياسة كانت تمنح وصول قراءة إلى دلو واحد إلى سياسة تمنح كل شيء. تنطبق الفكرة نفسها على iam:PutUserPolicy و iam:PutRolePolicy و iam:PutGroupPolicy للسياسات المضمّنة. يُقرأ الإذن على أنه صيانة سياسة روتينية، ويمكنه أن يعيد كتابة أي شيء تمنحه تلك السياسة.

إرفاق سياسة أقوى

أذونات مثل iam:AttachUserPolicy و iam:AttachRolePolicy و iam:AttachGroupPolicy تتيح لهوية إرفاق سياسة مُدارة موجودة بنفسها أو بمُسند تتحكم به. أرفق AdministratorAccess وينتهي التسلق بمكالمة واحدة. ينجح هذا لأن الإذن حُدد بنطاق واسع للغاية.

إنشاء بيانات اعتماد جديدة لهوية أقوى

تتيح عدة أذونات لهوية إنشاء بيانات اعتماد جديدة لمُسند يملك بالفعل امتيازاً أكبر. يصدر iam:CreateAccessKey على مستخدم آخر مفتاحاً جديداً لذلك المستخدم. يعيّن iam:CreateLoginProfile كلمة مرور لوحة تحكم لمستخدم ليس لديه واحدة. ويعيد iam:UpdateLoginProfile تعيين واحدة. في كل حالة يكتسب المهاجم هوية أقوى ليستوثق بها، بدلاً من إضافة أذونات إلى التي يملكها بالفعل.

تخفيف سياسة ثقة

تقرر سياسة ثقة الدور من يستطيع تولّيه. إذا كانت هوية تملك iam:UpdateAssumeRolePolicy على دور مميّز، فيمكنها إعادة كتابة سياسة الثقة تلك للسماح لنفسها، ثم استدعاء sts:AssumeRole والتحوّل إلى الدور. والخطر المرتبط بذلك هو دور يثق بالفعل على نطاق واسع جداً، مُسند بأحرف بدل أو حساب كامل، بحيث لا يتطلب تولّيه تعديل أي شيء على الإطلاق.

لماذا تخفي الأذونات المنعزلة المسار

انظر إلى أي من تلك الأذونات في مراجعة سياسة وستبدو معقولة. تحتاج هوية نشر إلى iam:PassRole. يحتاج فريق منصة إلى إدارة السياسات. يحتاج مستخدم أتمتة إلى تدوير المفاتيح. لكل منح قصة جيدة.

لا يظهر التصعيد إلا عندما تربط المنح بما يمكنه الوصول إليه. iam:PassRole غير ضار حتى تسأل أي الأدوار يمكنه تمريرها وما إذا كانت الهوية تستطيع أيضاً تشغيل الخدمة التي ستشغّلها. تعديل سياسة مُدارة لا بأس به حتى تلاحظ أن السياسة مرفقة بدور مدير. لا يظهر المسار إلا عندما تنظر إلى الرسم البياني بأكمله، والمراجعة التي تتناول سياسة واحدة في كل مرة لا تفعل ذلك أبداً. ولهذا يمكن لمراجعة أن تعيد مئات النتائج وتظل تغفل السلسلة التي تصل إلى مدير.

الأدوات التي ترسمه

لست مضطراً للاستدلال على هذا يدوياً. يبلّغ AWS IAM Access Analyzer عن الوصول الخارجي وغير المستخدم ويمكنه التحقق من السياسات. تنمذج الأدوات مفتوحة المصدر العلاقات: يبني PMapper رسماً بيانياً لمن يستطيع الوصول إلى من، ويضع Cloudsplaining علامة على السياسات ذات الأذونات المعرّضة للتصعيد، وتعدّد الأطر الهجومية مثل Pacu طرق التصعيد المعروفة. هذه قيّمة، وهي ترسم المرشحين، أي الخطوات التي قد تنجح.

تتوقف معظم الأدوات قبل الإثبات. معرفة أن هوية تملك iam:PassRole ليست كمعرفة أن تلك الهوية، في ظل كل سياسة وحد وسياسة تحكم بالخدمة سارية، يمكنها الوصول إلى مدير اليوم. التحقق من ذلك هو ما يحوّل مرشحاً إلى مسار متحقق منه.

كيف يكسر المدافعون هذه المسارات

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

قيّد iam:PassRole حتى لا تستطيع هوية تمرير إلا أدوار محددة، وأضف شرط iam:PassedToService حتى لا يمكن تمرير دور مخصص لـ Lambda إلى EC2. عامل إجراءات الكتابة iam:، خصوصاً تعديلات السياسات والإرفاقات وإنشاء بيانات الاعتماد، على أنها عالية الامتياز وامنحها بضيق. ضع حد أذونات على الهويات التي يجب أن تملك أذونات كتابة IAM حتى لا تتجاوز سقفاً. استخدم سياسات التحكم بالخدمة لتحديد الامتياز الفعّال عبر المؤسسة، حتى لا يستطيع حتى حساب مُعدّ بشكل خاطئ الوصول إلى مدير. شدّد سياسات ثقة الأدوار لتسمية مُسندين دقيقين، لا حساباً عارياً أو حرف بدل أبداً. ثم راقب CloudTrail بحثاً عن الاستدعاءات الكاشفة: CreatePolicyVersion و AttachRolePolicy و UpdateAssumeRolePolicy و CreateAccessKey على هوية لا تجريها عادةً.

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

كيف يتعامل Pathbreak معه

يعامل Pathbreak IAM بالطريقة التي يعامله بها المهاجم، كرسم بياني لقابلية الوصول لا كقائمة سياسات. يستدل على هوياتك وأدوارك وسياساتك وحدودك وعلاقات الثقة الحقيقية، ثم يحسم الصلاحيات ليؤكد أي الهويات يمكنها التصعيد إلى مدير أو الوصول إلى بيانات حساسة. يفعل هذا بالقراءة فقط. لا شيء يُنفَّذ على حسابك، ولا شيء يتغير.

وحين يُحسم مسار، يعرض Pathbreak السلسلة الكاملة ويسلّمك التغيير الوحيد الذي يكسرها، منح PassRole المطلوب إزالته، أو السياسة المطلوب تشديدها، أو علاقة الثقة المطلوب إغلاقها. تصلح تلك الحافة بدلاً من فرز ألف نتيجة غير مرتّبة. يمكنك الاطلاع على الآلية في صفحة كيف يعمل، والسلاسل التي نغطيها في صفحة مسارات الهجوم، وكيفية تعاملنا مع الوصول في صفحة الثقة والأمن.

الأسئلة الشائعة