iam:PassRole: كيف يعمل، وكيف يستغله المهاجمون، وكيف تحدد نطاقه

Ian Austin · 3 نوفمبر 2026 · قراءة 12 دقيقة

iam:PassRole هو إذن AWS IAM الذي يتحكم في الأدوار التي تستطيع جهة فاعلة تسليمها إلى خدمة AWS، مثل دور التنفيذ لدالة Lambda، أو ملف تعريف المثيل لمثيل EC2، أو دور الخدمة لمشروع CodeBuild. وهو أيضاً الإذن الأكثر ظهوراً في خريطة الهجوم من Pathbreak: إذ يعتمد عليه 55 بالمئة من مسارات تصعيد الامتيازات في الخريطة، وتصل هذه المسارات إلى 23 خدمة من خدمات AWS، لأن كل خدمة تشغّل أحمال العمل نيابةً عنك تقبل دوراً تسلّمه إليها. ومن السهل منحه على نطاق أوسع من اللازم، إذ يبدو المورد ذو حرف البدل غير مؤذٍ عند مراجعة السياسة، ولا يظهر التمرير نفسه في CloudTrail أبداً. تشرح هذه المقالة ما يفعله هذا الإذن، والفحوص التي يجريها AWS، وكيف يستخدمه المهاجم، وما تُظهره السجلات، وكيف تحدد نطاقه بحيث يُغلق المسار.

ما هو iam:PassRole

تعمل كثير من خدمات AWS بدور IAM تمنحه لها عند تهيئة مورد. فدالة Lambda تعمل بهوية دور التنفيذ الخاص بها، ومثيل EC2 يحصل على بيانات الاعتماد من ملف تعريف المثيل، ومشروع CodeBuild يستدعي AWS بدور الخدمة الخاص به. ويُسمّى تسليم ذلك الدور إلى الخدمة تمرير الدور، ويتحقق AWS مما إذا كان يُسمح للجهة المستدعية بفعل ذلك.

هذا الفحص هو iam:PassRole. وتنص وثائق AWS صراحةً على أن PassRole إذن وليس له استدعاء API، لذا لا توجد عملية PassRole في SDK. وينتقل ARN الدور معاملاً في استدعاء آخر، مثل المعامل Role في CreateFunction الخاص بـ Lambda، وتتحقق الخدمة من إذن iam:PassRole لدى الجهة المستدعية أثناء معالجتها لذلك الاستدعاء.

يوجد هذا الإذن لمنع جهة فاعلة من منح خدمة صلاحيات وصول تتجاوز ما تملكه هي. فلو استطاع مطوّر لا يملك أي أذونات على Amazon S3 أن يمرر دوراً يسمح بـ S3، لنفّذت الخدمة إجراءات S3 تلك نيابةً عنه، وهذا بالضبط هو التصعيد الذي يحذّر منه AWS في الصفحة نفسها.

الفحوص الثلاثة التي يجريها AWS عند تمرير دور

يحدد مقال مدونة AWS Security عن PassRole ثلاثة شروط يجب أن تتحقق جميعها قبل أن تتمكن خدمة من استخدام دور ممرَّر.

1. يُسمح للجهة المستدعية بتمرير ذلك الدور. يجب أن تسمح سياسة قائمة على الهوية مرفقة بالجهة المستدعية بـ iam:PassRole مع وجود الدور في عنصر Resource، وأن يتحقق كل شرط في تلك العبارة، وألا يرفضه أي شيء آخر، بما في ذلك سياسات التحكم في الخدمات وحدود الأذونات وسياسات الجلسة وسياسات نقاط نهاية VPC.
2. يثق الدور بالخدمة المستهدفة. يجب أن تسمح سياسة الثقة للدور بالجهة الأساسية للخدمة (service principal)، على سبيل المثال lambda.amazonaws.com لدور تنفيذ Lambda. ويشير AWS إلى أن المورد يُنشأ في بعض الحالات رغم غياب الثقة، لكن الخدمة لا تستطيع حينها استخدام الدور.
3. الدور والجهة المستدعية في الحساب نفسه. ينص دليل مستخدم IAM على أن iam:PassRole لا يمرر دوراً إلا إلى خدمة في حساب AWS نفسه، لذا يحتاج التصميم العابر للحسابات إلى دور في الحساب الثاني يستطيع تقمّص الأول.

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

أين يجري فحص PassRole

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

الخدمات التي تستخدم الأدوار المرتبطة بالخدمة تنشئ هذه الأدوار وتديرها بنفسها عادةً، لذا لا يحدث أي تمرير. وحيث تتيح لك خدمة اختيار دور مرتبط بالخدمة، مثل مجموعة Amazon EC2 Auto Scaling تُنشأ بدور مسمّى من هذا النوع، يتحقق AWS من iam:PassRole بالطريقة نفسها.

يسرد الجدول بعض الاستدعاءات الشائعة التي تمرر دوراً، ومعامل الطلب الذي يحمله. وهذا المعامل نفسه هو ما تحتاج قاعدة الاكتشاف إلى قراءته.

تسرد الخريطة كل عملية تمرير يتتبعها Pathbreak، بما في ذلك مهام Glue ومهام التدريب في SageMaker ومهام ECS وStep Functions وBedrock AgentCore، ويمكن تصفية خريطة الهجوم على iam:PassRole لرؤيتها معاً.

كيف يستغل المهاجمون iam:PassRole

يتبع الاستغلال الخطوات الثلاث نفسها أياً كانت الخدمة المعنية.

العثور على دور ذي امتيازات يثق بخدمة. يعيد iam:ListRoles سياسة الثقة لكل دور في الحقل AssumeRolePolicyDocument، لذا يكشف استدعاء واحد الأدوار التي تثق بـ Lambda أو EC2 أو CodeBuild أو أي خدمة أخرى. ويبحث المهاجم عن دور بأذونات واسعة تذكر سياسة الثقة الخاصة به خدمةً يستطيع إنشاء موارد فيها.

إنشاء مورد مرفق به ذلك الدور. بامتلاك iam:PassRole على الدور مع lambda:CreateFunction، ينشئ المهاجم دالة يكون دور التنفيذ لها هو الدور ذو الامتيازات. ويقبل AWS التمرير لأن سياسة الجهة المستدعية تسمح به، ولأن الدور يثق بـ lambda.amazonaws.com.

تشغيل شيفرة بهوية الدور. يستدعي المهاجم الدالة، فتعمل أي شيفرة كتبها بأذونات الدور ذي الامتيازات. وإذا كان الدور مسؤولاً، يكفي إنشاء واحد واستدعاء واحد للاستيلاء على الحساب. والخطوة نفسها تنجح عبر بيانات المستخدم في EC2، أو ملف buildspec في CodeBuild، أو قالب CloudFormation، أو نص مهمة Glue، ولهذا يمكن لمنح واحد واسع أكثر من اللازم لـ iam:PassRole أن يفتح مسارات كثيرة دفعة واحدة.

نسخة Lambda من هذه السلسلة، مع أحداث CloudTrail لكل خطوة، مشروحة في مقال ثلاث هجمات لتصعيد الامتيازات في AWS، مع أدلة CloudTrail والإصلاح.

لماذا لا يكفي iam:PassedToService بمفرده

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

توضح السياسة المُدارة من AWS AWSLambda_FullAccess هذه الفجوة بوضوح. فهي تمنح lambda:* وiam:ListRoles وiam:GetRole، وتسمح بـ iam:PassRole على "Resource": "*" مع ضبط iam:PassedToService على lambda.amazonaws.com. والجهة الفاعلة التي تملك هذه السياسة تستطيع سرد الأدوار في الحساب، والعثور على أي دور تسمح سياسة الثقة الخاصة به بـ Lambda، وإنشاء دالة به واستدعاءها. وإذا كان دور ذو امتيازات في الحساب يثق بـ Lambda، فلن يفعل الشرط شيئاً لإيقاف التصعيد، لأن التمرير يتم فعلاً إلى Lambda.

يثبت الشرط قيمته عند اقترانه بمورد محدد. فـ ARN لدور محدد يقرر أي دور يمكن تمريره، وiam:PassedToService يقرر الخدمة التي يمكن تمريره إليها، وهذا مهم عندما يثق الدور بأكثر من خدمة واحدة.

كيفية اكتشاف استغلال iam:PassRole في CloudTrail

يذكر AWS أنه لا تُنشأ أي سجلات CloudTrail لـ PassRole، لذا يكون الدليل دائماً هو استدعاء الإنشاء أو التحديث الذي تلقّى الدور.

• راقب المعامل. في Lambda، هذا هو حدث الإدارة CreateFunction الذي يحمل ARN الدور في معاملات الطلب. ويُظهر مرجع CloudTrail الخاص بـ Lambda اسم الحدث على أنه CreateFunction20150331، لذا يجب أن تطابق القاعدة بادئة اسم الحدث. ويشير المرجع نفسه إلى أن المعاملين Environment وZipFile لا يُدرجان في السجل، لذا لا تكون الشيفرة التي رفعها المهاجم موجودة في الحدث.
• قارن الدور بالجهة المستدعية. الإشارة القوية هي استدعاء إنشاء يرفق دوراً يملك أذونات أكثر من الجهة الفاعلة التي تجري الاستدعاء، خاصةً إذا صدر من جهة فاعلة ليس لها سجل في إنشاء ذلك النوع من الموارد.
• فعّل الأحداث اللاحقة. Invoke في Lambda حدث بيانات، ولا يسجّله CloudTrail افتراضياً، كما يؤكد AWS. وتفعيل أحداث بيانات Lambda يتيح للقاعدة ربط الإنشاء باستدعاء يأتي بعده ببضع دقائق.
• اقرأ حالات الإخفاق. يسجّل CloudTrail الاستدعاءات الفاشلة مع رمز الخطأ ورسالة الخطأ. وعند رفض تمرير، يذكر الخطأ الذي يعيده AWS iam:PassRole وARN الدور، كما هو موضح في إرشادات استكشاف الأخطاء وإصلاحها من AWS. وسلسلة من استدعاءات الإنشاء المرفوضة يذكر كل منها دوراً مختلفاً هي ما يبدو عليه مهاجم يختبر الأدوار التي يستطيع تمريرها.

بعد نجاح التمرير، يكون نشاط الدور نفسه آخر مكان للبحث. فاستدعاءات API التي تُجرى بهوية الدور الممرَّر من دالة أو مثيل لم يكن موجوداً قبل ساعة تستحق نظرة أدق.

كيف تحدد نطاق iam:PassRole

الهدف أن تستطيع كل جهة فاعلة تمرير الأدوار التي يحتاجها عملها فقط، وإلى الخدمات التي تستخدمها فقط.

• سمِّ الأدوار. ضع ARN لأدوار محددة في عنصر Resource. وحيث تُنشأ الأدوار كثيراً، استخدم مسار IAM مثل arn:aws:iam::111122223333:role/application_role/* أو بادئة اسم، بحيث تُغطّى الأدوار الجديدة في ذلك المسار دون تغيير السياسة، كما توصي مدونة AWS Security.
• أضف iam:PassedToService. استخدمه إلى جانب مورد محدد، بحيث لا يمكن تمرير دور يثق بعدة خدمات إلا إلى الخدمة التي يستخدمها حمل العمل.
• استخدم iam:AssociatedResourceArn حيث يناسب. يقيّد مفتاح الشرط هذا المورد الذي يمكن إرفاق الدور به. ولأن ARN بعض الموارد يتغير عند إعادة إنشاء المورد، يشير AWS إلى أن كثيراً من المؤسسات تقيّد بدلاً من ذلك من يستطيع تعديل المورد.
• تجنّب التحكم القائم على الوسوم. يحذّر AWS من أن شروط ResourceTag على iam:PassRole لا تعطي نتائج موثوقة، لذا فالوسوم على الدور ليست أداة التحكم المناسبة لهذا الإذن.
• احمِ المسارات ذات الامتيازات بسياسة SCP. يمكن لسياسة التحكم في الخدمة أن ترفض iam:PassRole على مسار محمي، مثل الأدوار التي يستخدمها فريق الأمن، ما لم تحمل الجهة المستدعية وسماً محدداً أو تكن ضمن مسار معتمد.
• ضع حدوداً للأدوار التي ينشئها المطورون. إذا كان المطورون يستطيعون إنشاء أدوارهم الخاصة، فاشترط حدود أذونات على تلك الأدوار، واسمح لهم بتمرير الأدوار الموجودة في مسار مخصص فقط، بحيث لا يتجاوز الدور الذي ينشئونه ثم يمررونه تلك الحدود.

يحافظ كل تغيير على القدرة التي يعتمد عليها الفريق، ويغلق المسارات التي تمر عبر أدوار لم يحتج الفريق قط إلى تمريرها.

ما لا يصلحه تحديد نطاق PassRole

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

• شيفرة دالة Lambda. يستبدل lambda:UpdateFunctionCode شيفرة دالة قائمة ويُبقي دور التنفيذ الخاص بها في مكانه، لذا تعمل شيفرة المهاجم بهوية ذلك الدور في المرة التالية التي تُستدعى فيها الدالة.
• بيانات المستخدم في EC2. باستخدام ec2:StopInstances وec2:ModifyInstanceAttribute وec2:StartInstances، يوقف المهاجم مثيلاً، ويعيد كتابة بيانات المستخدم الخاصة به، ثم يشغّله من جديد. ولا تعمل بيانات المستخدم افتراضياً إلا عند الإقلاع الأول، لذا يقدّم المهاجم تهيئة cloud-init تعمل عند كل إقلاع، فيعمل النص البرمجي بملف التعريف الحالي للمثيل.
• أوامر SSM. يشغّل ssm:SendCommand نصاً برمجياً على مثيل مُدار، ويستطيع هذا النص قراءة بيانات اعتماد الدور المرفق بالمثيل بالفعل.
• أدوار حزم CloudFormation. يشير AWS إلى أنه بمجرد إرفاق دور خدمة بحزمة، يستطيع المستخدمون القادرون على العمل على الحزمة استخدام الدور سواء امتلكوا iam:PassRole أم لا، لذا فإن الجهة الفاعلة القادرة على تحديث الحزمة أو تنفيذ مجموعة تغييرات ترث الدور. ويعمل البديل UpdateStack بالطريقة نفسها.
• مشاريع CodeBuild. بدء عملية بناء لمشروع قائم مع ملف buildspec مستبدَل يشغّل أوامر المهاجم بدور الخدمة الخاص بالمشروع.

مراجعة الحساب التي تتوقف عند iam:PassRole ستفوّت كل ذلك، ولهذا تسردها الخريطة مدخلات منفصلة.

كيف تتحقق ممن يستطيع تمرير دور ذي امتيازات

بالنسبة إلى جهة فاعلة واحدة ودور واحد، يقدّم محاكي سياسات IAM إجابة سريعة. فهو يقيّم السياسات القائمة على الهوية وسياسات التحكم في الخدمات، بما في ذلك الشروط، للجهة الفاعلة التي تحددها.

حيث تستخدم سياسة الجهة الفاعلة iam:PassedToService، أضف الوسيطة --context-entries التي تضبط المفتاح iam:PassedToService على الخدمة المستهدفة، مثل lambda.amazonaws.com، لأن المحاكي من دونها لا يملك قيمة يقارن بها. ولا تجيب النتيجة إلا عن الفحص الأول من الفحوص الثلاثة. أما ما إذا كانت سياسة الثقة للدور تسمح بالخدمة فمسألة منفصلة، تُعرف إجابتها بقراءة AssumeRolePolicyDocument الخاص بالدور، كما تظل الجهة المستدعية بحاجة إلى إذن الإنشاء لتلك الخدمة. ويشير AWS أيضاً إلى أن نتائج المحاكي قد تختلف عن البيئة الفعلية.

هذا ممكن لزوج واحد، لكنه غير عملي عبر حساب فيه مئات الجهات الفاعلة والأدوار. وتقرأ أداة pathbreak-audit المجانية مفتوحة المصدر إعدادات IAM في حساب واحد، وتسرد الأدوار والمستخدمين الذين يملكون أذونات وتركيبات قابلة لإساءة الاستخدام، مثل iam:PassRole مع إجراء إنشاء، مع الإصلاح لكل منها، كنقطة انطلاق. ويذهب Pathbreak أبعد من ذلك، إذ يحلّ كل عملية تمرير مقابل سياسات الجهة المستدعية وحدودها وSCP وسياسة الثقة للدور، بحيث لا يُبلَّغ إلا عن المسارات التي ستنجح فعلاً، مرتبةً حسب ما يستطيع الدور الممرَّر الوصول إليه.

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