اختبار اختراق السحابة (Azure)
أخطاء الإعدادات السحابية لا تبدو كالثغرات التقليدية؛ إنها سلسلة من إسنادات الأدوار «المقبولة» تتراكم حتى تصل إلى اختراق المستأجر بالكامل. اختبار بشهادة AZ-500 لـ Entra ID وRBAC وطبقة الهوية التي يستهدفها المهاجمون فعليًا.
ما الذي يشمله
- مراجعة إعدادات Entra ID (Azure AD)
- رسم مسارات تصعيد الصلاحيات في Azure RBAC
- اختبار انكشاف حسابات التخزين & حاويات Blob
- إساءة استخدام مبادئ الخدمة & الهويات المُدارة
- تحليل ثغرات Defender for Cloud
- مراجعة مجموعات أمان الشبكة
المُخرَجات
- ملخص تنفيذي للإدارة
- تقرير تقني بنتائج مُقيَّمة بـ CVSS
- أدلة على مسارات تصعيد الصلاحيات
- خارطة طريق للمعالجة حسب الأولوية
- جلسة شرح مباشرة
- خطاب إثبات للمدققين والعملاء، عند الطلب
- إثبات المعالجة بعد إعادة الاختبار، كوثيقة مستقلة
الجدول الزمني
من 3 إلى 7 أيام عمل، بحسب حجم المستأجر وعدد الاشتراكات.
لماذا تُعد الهوية السحابية سطح الهجوم الحقيقي
في Azure، المحيط ليس جدارًا ناريًا، بل هو الهوية. فحساب ضيف بإسناد دور أوسع مما ينبغي، أو مبدأ خدمة بصلاحيات تفوق ما تحتاجه أتمتته فعلًا، أو هوية مُدارة مرتبطة بمورد ذي سياسة وصول ضعيفة - كلها «مقبولة» كل على حدة، إلى أن تتشابك في مسار يمتد من وصول منخفض الصلاحيات إلى المسؤول العام أو مالك الاشتراك. وهذا بالضبط سطح الهجوم الذي بُني هذا المشروع لاكتشافه.
المنهجية
مراجعة إعدادات Entra ID وسياسات الوصول المشروط، ورسم إسنادات أدوار RBAC بحثًا عن سلاسل تصعيد الصلاحيات، واختبار حسابات التخزين وحاويات Blob بحثًا عن وصول عام أو مُعدّ بشكل خاطئ، ومراجعة نطاق صلاحيات مبادئ الخدمة والهويات المُدارة، والتحقق مما إذا كان Defender for Cloud يرصد فعلًا التقنيات المستخدمة أثناء الاختبار - فأداة أمنية لا تكتشف مسار هجوم حقيقيًا هي بحد ذاتها نتيجة تستحق الإبلاغ.
النطاق والتفويض
يغطي الاختبار مستأجر Azure واشتراكاتك الخاصة بك. وقواعد الاشتباك الخاصة بمايكروسوفت لاختبار الاختراق تسمح بذلك عادةً دون إشعار مسبق للموارد التي تملكها، لكن البنية التحتية المشتركة أو متعددة المستأجرين تتطلب تفويضًا صريحًا من جميع الأطراف المتأثرة - يُؤكَّد ضمن قواعد الاشتباك الموقَّعة قبل أن يبدأ أي شيء.
أسئلة حول اختبار السحابة
بالدرجة الأولى Microsoft Azure - فهناك العمق، مدعومًا بشهادة AZ-500 (Azure Security Engineer Associate) وبخبرة عملية في Entra ID وAzure RBAC وDefender for Cloud. وإذا كانت بيئتك على AWS أو GCP، فاسأل خلال مكالمة تحديد النطاق؛ فمبادئ أمن السحابة العامة (أخطاء إعدادات IAM، وانكشاف التخزين، ومسارات تصعيد الصلاحيات) تنتقل بين المزوّدين، لكن الخبرة المعتمدة والعميقة هي في Azure.
مراجعة إعدادات Entra ID (Azure AD)، وAzure RBAC ومسارات تصعيد الصلاحيات، وانكشاف حسابات التخزين وحاويات Blob، ومبادئ الخدمة والهويات المُدارة المُعدّة بشكل خاطئ، وثغرات تغطية Defender for Cloud، وأخطاء إعدادات مجموعات أمان الشبكة - أي سطح الهجوم الخاص بالسحابة، وهو ما لا يصل إليه اختبار الشبكات التقليدي.
قواعد الاشتباك الخاصة بمايكروسوفت لـ Azure تسمح عادةً باختبار مواردك الخاصة دون إشعار مسبق، لكن النطاق يجب أن يقتصر على مستأجرك ومواردك وحدها؛ أما البنية التحتية المشتركة أو متعددة المستأجرين فتتطلب تفويضًا كتابيًا صريحًا من أي طرف آخر متأثر. ويُؤكَّد ذلك ضمن قواعد الاشتباك الموقَّعة قبل بدء الاختبار.
مراجعة الإعدادات تقارن الإعدادات بمعيار مرجعي (CIS، أو توصيات مايكروسوفت نفسها) - وهي مفيدة لكنها ساكنة. أما هذا المشروع فيختبر فعليًا ما إذا كانت أخطاء الإعدادات قابلة للاستغلال: هل تستطيع هوية منخفضة الصلاحيات أن تتصاعد حقًا عبر سلسلة من إسنادات الأدوار إلى شيء حسّاس؟ وهذا الفارق يهم تمامًا كما يهم في اختبار Active Directory المحلي.
من 3 إلى 7 أيام عمل بحسب حجم المستأجر وعدد الاشتراكات أو مجموعات الموارد المشمولة بالنطاق.
من 1,500 دولار، بحسب حجم المستأجر وتعقيده. راجع صفحة الأسعار للتفاصيل.
اكتشف مسارات تصعيد الصلاحيات في مستأجرك قبل أن يكتشفها مهاجم
مكالمة تحديد نطاق مجانية، وعرض بسعر ثابت خلال 24 ساعة.