تحليل مسارات الهجوم مقابل التحقق من مسارات الهجوم في AWS

بقلم فريق Pathbreak · 22 أكتوبر 2026 · قراءة 8 دقائق

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

فبدلاً من قائمة تضم 3,000 مشكلة منفصلة، ينتج التحليل سلاسل: هذا المثيل العام يحمل هذا الدور، وهذا الدور يستطيع تمرير ذلك الدور إلى Lambda، وذلك الدور مسؤول إداري. تقدّم معظم منصات أمان السحابة اليوم شكلاً منه، وهو تحسّن كبير على القوائم المرتبة حسب الخطورة.

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

ما الذي يفعله تحليل مسارات الهجوم

يبدأ التحليل من جرد: الكيانات، والأدوار، والسياسات، وعلاقات الثقة، وموارد الحوسبة، والتخزين، والروابط الشبكية بينها. ثم يبني رسماً بيانياً ويبحث فيه عن طرق تنتهي عند شيء حساس، مثل دور مسؤول إداري أو قاعدة بيانات إنتاجية أو حاوية تضم بيانات العملاء. كل قفزة هي تقنية معروفة. iam:PassRole مع lambda:CreateFunction قفزة. وsts:AssumeRole إلى حساب يمنح الثقة قفزة. وعنوان URL عام لدالة نقطة دخول.

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

أين يتوقف التحليل

تقيّم AWS كل استدعاء API مقابل عدة وثائق في آن واحد، وأي واحدة منها قد تحوّل السماح إلى رفض. والمسار الموجود على الرسم البياني قد يمنعه أي مما يلي:

• سياسات التحكم في الخدمات. يمكن لـ SCP على الوحدة التنظيمية أن يرفض lambda:CreateFunction للوحدة كلها، ولا تستطيع أي سياسة هوية داخلها تجاوز ذلك.
• حدود الأذونات. الحدّ المفروض على الكيان المصدر يقيّد ما يمكن أن تمنحه سياسات هويته. فإذا أغفل الحدّ iam:PassRole، يفشل التمرير حتى لو سمحت به سياسة الهوية.
• سياسات الثقة. يجب أن يثق الدور الهدف بالخدمة أو الكيان الذي تعتمد عليه القفزة. والدور الذي لا يثق بـ lambda.amazonaws.com لا يمكن تمريره إلى Lambda، أياً كان ما يملكه المستدعي.
• سياسات الموارد. الحاوية أو المفتاح أو قائمة الانتظار أو الدالة في نهاية المسار لها سياستها الخاصة، وقد ترفض الكيان الذي وصلت به السلسلة.
• مفاتيح الشروط. iam:PassedToService وaws:SourceAccount وaws:PrincipalOrgID وفحص sts:ExternalId كلها تضيّق منحاً يبدو واسعاً في قائمة الإجراءات.
• الرفض الصريح. عبارة رفض في أي مكان من التقييم تتغلب على كل سماح، وغالباً ما تكون في سياسة مختلفة عن تلك التي قرأها الرسم البياني.

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

كيف تتحقق من مسار هجوم سحابي في AWS

لنأخذ سلسلة شائعة. دور CI اسمه ci-deploy يملك iam:PassRole على دور اسمه data-pipeline، إضافة إلى lambda:CreateFunction وlambda:InvokeFunction. ودور data-pipeline يملك AdministratorAccess. على الرسم البياني هذا مسار من قفزتين بين دور CI وصلاحيات المسؤول الإداري: أنشئ دالة مرفقاً بها data-pipeline، ثم استدعها، فتعمل شيفرة الدالة بصلاحيات المسؤول الإداري.

يصنّف التحليل المسار على أنه قابل للوصول. ثم يمرّ عليه التحقق فحصاً بعد فحص:

1. هل تسمح سياسة الهوية على ci-deploy بـ iam:PassRole على ARN الخاص بـ data-pipeline، أو على حرف بدل يشمله؟ نعم، على arn:aws:iam::*:role/data-*.
2. هل يضيّق iam:PassedToService التمرير؟ لا يوجد أي شرط، لذا تُقبل أي خدمة.
3. هل تثق سياسة الثقة لـ data-pipeline بـ lambda.amazonaws.com؟ نعم، فقد أُنشئ الدور لخط معالجة قائم على Lambda.
4. هل يرفض SCP على الوحدة التنظيمية للحساب lambda:CreateFunction أو iam:PassRole؟ للوحدة SCP، ولا يرفض أياً منهما.
5. هل يستبعد حدّ أذونات على ci-deploy أياً من الإجراءين؟ لا يوجد حدّ على الدور.
6. هل يصل تنفيذ الدالة إلى شيء مهم؟ data-pipeline مسؤول إداري، لذا الإجابة هي كل شيء في الحساب، ومن خلال علاقتي ثقة عبر الحسابات، حسابان آخران.

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

الإصلاح ينبع من الخطوة الثانية. أضيق تغيير هو إضافة iam:PassedToService إلى منح التمرير بحيث لا تستقبل الدور إلا الخدمة المقصودة، أو استبدال ARN ذي حرف البدل بالدور الوحيد الذي يحتاجه CI. بعد التغيير تُشغَّل الفحوص الستة نفسها مرة أخرى فتفشل الخطوة الثانية. يختفي المسار، ويُسجَّل التأكيد بجانب النتيجة. يحتوي مدخل الخريطة لهذه السلسلة على أحداث CloudTrail والشرح الكامل.

هل التحقق من مسارات الهجوم آمن في بيئة الإنتاج؟

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

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

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

لماذا يحدد الفرق ما تصلحه أولاً

ترتيب المسارات حسب الأثر لا ينفع إلا إذا كانت المسارات حقيقية. فالقائمة التي تخلط السلاسل المثبتة بسلاسل يمنعها SCP أصلاً ستدفع الفرق نحو عمل لا يغيّر شيئاً. في حساب المختبر لدى Pathbreak، أنتج التحليل 4,942 مساراً مرشحاً. وبعد التحقق والترتيب حسب نطاق الضرر، أزالت عبارة Deny واحدة على دور واحد 3,893 من أصل 4,087 مساراً متبقياً، وأزال تغييران معاً 80 بالمئة من المخاطر في الحساب. هذا الترتيب لا يظهر إلا بعد حلّ كل مسار مقابل التفويض الحقيقي.

كيف يفعل Pathbreak ذلك

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

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