مرحلة التحقق في CTEM داخل AWS، بأرقام حقيقية

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

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

أين تتعثر برامج AWS

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

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

شكل التحقق في مستوى التحكم في AWS

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

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

الأرقام من حساب المختبر

حساب المختبر لدى Pathbreak هو البيئة التي تقف خلف الأرقام في الصفحة الرئيسية. وهذا ما أنتجته مرحلة التحقق هناك.

تُظهر هذه الأرقام الغرض من التحقق. آلاف المسارات المرشحة لم تكن آلاف المشكلات المستقلة. فمعظمها مرّ عبر الأدوار القليلة نفسها، لذا كسر عدد صغير من التغييرات، الموضوعة على الكيانات الصحيحة، معظم المسارات المثبتة دفعة واحدة. أما القائمة المرتبة حسب الخطورة فكانت ستعرض الحساب نفسه على أنه 4,942 عنصراً بأوزان متقاربة، وترسل الفريق لإصلاحها واحداً تلو الآخر.

ما الذي تحتاجه التعبئة من التحقق

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

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

جعل المرحلة مستمرة

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

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

ما الذي تسأل عنه منصة CTEM بشأن AWS

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

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

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