هجمات الثقة عبر الحسابات في AWS: كيف يصل تسلسل الأدوار إلى الجواهر الثمينة

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

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

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

كيف تعمل الثقة عبر الحسابات

لكل دور IAM سياستان. تقول سياسة الأذونات ما يمكن للدور فعله. وتقول سياسة الثقة، أي سياسة تولّي الدور، من يُسمح له بأن يصبحه. للانتقال إلى دور، يستدعي مُسند sts:AssumeRole ويحصل على بيانات اعتماد مؤقتة، طالما أن سياسة ثقة الدور الهدف تسمح لذلك المُسند ويملك المستدعي إذن sts:AssumeRole.

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

أين تسوء الثقة

المُسندون بأحرف بدل في سياسات الثقة

أخطر سياسة ثقة وأكثرها إساءة فهم هي مُسند بحرف بدل. عبارة تسمح بـ "Principal": { "AWS": "*" } مع "Action": "sts:AssumeRole" لا تعني أي هوية في حسابك. إنها تفتح الدور لكل حساب AWS في العالم. هناك شرط ثانٍ، إذ يجب أن تملك الهوية المستدعية أيضاً إذن sts:AssumeRole على الدور، لكن هذا هو سبب كون حرف البدل خطراً عملياً: يمنح المهاجم ذلك الإذن لنفسه في حساب AWS الخاص به، فيوفّر الشرط الثاني مجاناً. يقرأ الفرق حرف البدل على أنه "كل من في فريقي" ويشحنه. ما نشروه هو دور يستطيع أي مهاجم تولّيه من حساب يتحكم به. على دور بأذونات ذات شأن، يعطي ذلك كل ما يستطيع الدور فعله. إن كنت بحاجة فعلاً إلى مُسند واسع، فقيّده بـ Condition مثل aws:PrincipalAccount أو aws:PrincipalOrgID، والأفضل من ذلك، سمِّ ARNs الأدوار الدقيقة التي تنوي الوثوق بها.

النائب المرتبك على الأدوار الخارجية

عندما تسمح لبائع SaaS بتولّي دور في حسابك، يستخدم ذلك البائع حساب AWS واحداً لخدمة عملاء كثر. إذا كانت سياسة ثقتك تسمّي حساب البائع فقط، فقد يستحث عميل آخر من عملاء البائع ذلك البائع على تولّي دورك. الإصلاح هو معرّف خارجي، سرّ مشترك في الشرط، أو شرط aws:SourceArn أو aws:SourceAccount يربط التولّي بعلاقتك المحددة. دور خارجي بلا واحد منها هو تعرّض نائب مرتبك كلاسيكي.

تسلسل الأدوار عبر الحسابات

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

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

يضيف AWS بعض الاحتكاك. تُحدد جلسات الأدوار المتسلسلة بساعة واحدة ولا يمكن تجديدها بالتسلسل أكثر. يحد ذلك من عمر الجلسة، لكنه لا يغلق المسار.

لماذا تبدو حدود الحسابات أكثر أماناً مما هي عليه

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

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

تساعد الأدوات القائمة على الرسم البياني. يستطيع PMapper و Cartography نمذجة الأدوار وعلاقات الثقة عبر الحسابات، ويبلّغ AWS IAM Access Analyzer عن الوصول الخارجي إلى أدوارك، بما في ذلك الثقة عبر الحسابات التي ربما نسيتها. تعطيك هذه حواف مرشحة. والسؤال المتبقي هو أي من تلك السلاسل المرشحة تُحسم، كل القفزات، كل الشروط، كل سياسات الأذونات السارية، إلى شيء يهمك. حافة ثقة لا تؤدي إلى أي مكان حساس هي ضجيج، وسلسلة من أربع قفزات إلى بيانات إنتاجك هي التي تحتاج إلى إصلاحها.

كيف تكسر السلسلة

كما هي الحال مع أي مسار، يكفي قطع حافة واحدة. استبدل مُسندي الحساب الجذر في سياسات الثقة بـ ARNs أدوار دقيقة. اشترط معرّفاً خارجياً أو شرط aws:SourceArn على كل دور خارجي. احذف الثقة عبر الحسابات التي لم تعد تخدم غرضاً، فأدوار البائعين الخاملة اكتشاف شائع. حيثما أمكن، استخدم سياسات التحكم بالخدمة لمنع فئات كاملة من الحسابات من تولّي أدوار حساسة. ثم نبّه على استدعاءات AssumeRole إلى الأدوار الحرجة من مصادر غير متوقعة.

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

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

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

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

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