← جميع المقالات AEV

التحقق العدائي من التعرّض في AWS

بقلم فريق Pathbreak · · قراءة 7 دقائق

أبرز النقاط

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

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

يتناول هذا المقال معنى ذلك في AWS تحديداً، لأن مستوى التحكم في السحابة يغيّر الطريقة والناتج معاً.

لماذا تحتاج AWS إلى نوع خاص بها من التحقق

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

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

ما الذي ينبغي التحقق منه في AWS

أربعة أنواع من التعرّض تفسّر معظم المسارات المثبتة التي نراها في الحسابات الحقيقية.

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

الثقة عبر الحسابات. أدوار تثق بحساب آخر أو بمورّد أو بحرف بدل، حيث يكون الطرف المانح للثقة ذا امتيازات والطرف الموثوق به أضعف مما افترضه أي أحد. سلسلة من قفزتين أو ثلاث عبر sts:AssumeRole قد تربط بيئة تجريبية بالإنتاج.

بيانات الاعتماد المكشوفة في الإعدادات. مفاتيح الوصول والرموز المميزة في بيانات مستخدم EC2، ومتغيرات بيئة Lambda، ومخرجات CloudFormation، وتعريفات الحاويات. مفتاح مكشوف واحد يصبح نقطة الدخول إلى كل ما يستطيع كيان المفتاح الوصول إليه.

نقاط الدخول العامة. عناوين URL للدوال، والحاويات العامة التي تتيح الكتابة، والمثيلات المكشوفة على الإنترنت التي تملك ملف تعريف مثيل، وبوابات API التي تستدعي دوراً ذا امتيازات. لا يكون التعرّض خطيراً إلا إذا كان الدور خلفه يقود إلى مكان ما، وهذا تحديداً ما يثبته التحقق.

ما الذي ينبغي أن تفعله أداة AEV لـ AWS

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

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

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

كيف يتعامل أبرز مورّدي AEV مع AWS

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

المورّدنقطة الانطلاقالنهج في AWS
Penteraالتحقق الآلي من الأمان عبر الشبكات الداخلية والهويات وسطح الهجوم الخارجيوحدة سحابية تحاكي تقنيات المهاجمين ضد حسابات AWS وAzure، بما في ذلك اختراق الهويات وتصعيد امتيازات الأدوار
Horizon3.aiاختبار اختراق مستقل من داخل الشبكةاختبار اختراق سحابي يشغّل تقنيات هجوم ضد بيئات AWS وAzure
XM Cyberنمذجة رسوم الهجوم البيانية والإدارة المستمرة للتعرّضنمذجة مسارات الهجوم القائمة على الرسوم البيانية عبر البيئات المحلية والسحابة، مع تحليل نقاط الاختناق
Cymulateمحاكاة الاختراق والهجومتقنيات هجوم محاكاة لاختبار الضوابط، مع سيناريوهات سحابية بجانب نقاط النهاية والبريد الإلكتروني
Picusمحاكاة الاختراق والهجومالتحقق من الضوابط عبر تقنيات محاكاة، مع تغطية سحابية أُضيفت إلى المنصة
Pathbreakمسارات الهجوم في مستوى التحكم في AWS، بناها ممارسون وجدوها يدوياًتحقق بوضع القراءة فقط من كل مسار بحلّ التفويض الحقيقي، وترتيب حسب نطاق الضرر، والتغيير الذي يكسر كل مسار، وتأكيد بعد الإصلاح

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

موقع AEV في برنامج CTEM

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

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

ما هو التحقق العدائي من التعرّض؟

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

هل AEV هو نفسه محاكاة الاختراق والهجوم؟

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

هل يتطلب AEV تشغيل استغلالات في حساب AWS الخاص بي؟

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

كم مرة ينبغي تشغيل التحقق من التعرّض في AWS؟

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

مقالات ذات صلة

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

اطلب عرضاً توضيحياً شاهد العرض التوضيحي