اختبار اختراق السحابة والتقييم
منهجية اختبار اختراق السحابة
4 دقيقة للقراءة
اختبار اختراق السحابة يتطلب نهجاً مختلفاً عن اختبار البنية التحتية التقليدية. فهم نموذج المسؤولية المشتركة وسطح الهجوم المتمركز حول API والتقنيات الخاصة بالسحابة ضروري لتقييمات أمنية فعالة.
اختبار اختراق السحابة مقابل التقليدي
الفروقات الرئيسية
| الجانب | تقليدي | سحابة |
|---|---|---|
| النطاق | محيط الشبكة | APIs، IAM، الخدمات |
| سطح الهجوم | الخوادم، المنافذ | البيانات الوصفية، بيانات الاعتماد |
| الحركة الجانبية | الارتكاز الشبكي | الوصول عبر الحسابات |
| تسريب البيانات | نقل الملفات | واجهات تخزين السحابة |
| تصعيد الصلاحيات | مستوى نظام التشغيل | إساءة سياسة IAM |
| التفويض | نطاق مكتوب | موافقة مزود السحابة |
متطلبات اختبار اختراق السحابة
قبل اختبار بيئات السحابة:
- تفويض مكتوب من مالك حساب السحابة
- إشعار مزود السحابة (سياسة AWS Pentest، ROE لـ Azure، الاستخدام المقبول لـ GCP)
- نطاق محدد - حسابات ومناطق وخدمات محددة
- جهات اتصال طوارئ للاستجابة للحوادث
- اتفاقية معالجة البيانات لبيانات الاعتماد المكتشفة
إطار اختبار اختراق السحابة
مصفوفة MITRE ATT&CK للسحابة
┌─────────────────────────────────────────────────────────────┐
│ ATT&CK للسحابة │
├─────────────────────────────────────────────────────────────┤
│ الوصول الأولي → التنفيذ → الثبات → تصعيد الصلاحيات │
│ │ │ │ │ │
│ حسابات صالحة Cloud API أدوار IAM إساءة السياسة │
│ التصيد Lambda مفاتيح وصول عبر الحسابات │
│ تطبيقات عامة Functions الثقة أدوار الخدمة │
├─────────────────────────────────────────────────────────────┤
│ تجنب الدفاع → وصول بيانات الاعتماد → الاكتشاف │
│ │ │ │ │
│ تعطيل التسجيل Metadata API Cloud APIs │
│ تعديل السياسات مخازن الأسرار تعداد الحسابات │
│ تبديل المنطقة سرقة الرمز اكتشاف الموارد │
├─────────────────────────────────────────────────────────────┤
│ الحركة الجانبية → الجمع → التسريب │
│ │ │ │ │
│ افتراض الأدوار S3 buckets تخزين السحابة │
│ حسابات الخدمة قواعد البيانات النقل للخارج │
│ إساءة الثقة النسخ الاحتياطية النسخ الظلية │
└─────────────────────────────────────────────────────────────┘
المرحلة 1: الاستطلاع
الاستطلاع الخارجي:
# اكتشاف أصول السحابة
# تعداد النطاقات الفرعية لخدمات السحابة
subfinder -d target.com | grep -E '(aws|azure|gcp|s3|blob|cloud)'
# سجلات DNS تشير لاستخدام السحابة
dig +short txt target.com | grep -E '(spf|dkim|amazonses)'
# سجلات شفافية الشهادات
curl "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -u
# البحث في GitHub/GitLab عن بيانات الاعتماد
# ابحث: "target.com" aws_access_key OR aws_secret
اكتشاف خاص بالخدمة:
# أنماط تسمية S3 bucket
# company-name, company-backups, company-logs
aws s3 ls s3://target-company --no-sign-request
# أنماط Azure blob
curl -s "https://targetcompany.blob.core.windows.net/public?restype=container&comp=list"
# تخزين GCP
gsutil ls gs://target-company-bucket
المرحلة 2: التعداد
بمجرد حصولك على بيانات الاعتماد:
# AWS - من أنا؟
aws sts get-caller-identity
# ماذا يمكنني أن أفعل؟
aws iam list-attached-user-policies --user-name compromised-user
aws iam list-user-policies --user-name compromised-user
# Azure - السياق الحالي
az account show
az ad signed-in-user show
# GCP - الهوية الحالية
gcloud auth list
gcloud config list
المرحلة 3: تصعيد الصلاحيات
تحديد مسارات التصعيد:
# AWS - متجهات التصعيد الشائعة
# iam:PassRole + lambda/ec2 - إنشاء مورد يفترض الدور
# iam:CreatePolicyVersion - تعديل سياسة موجودة
# iam:AttachUserPolicy - إرفاق سياسة admin
# sts:AssumeRole - افتراض دور ذو صلاحيات أعلى
# التحقق من الأدوار القابلة للافتراض
aws iam list-roles --query 'Roles[*].{Name:RoleName,Trust:AssumeRolePolicyDocument}'
المرحلة 4: الحركة الجانبية
# AWS عبر الحسابات
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/CrossAccountRole \
--role-session-name pentester
# رمز service account (Kubernetes)
kubectl auth can-i --list
kubectl get secrets -A
المرحلة 5: تقييم التأثير
توثيق النتائج:
- مخاطر كشف البيانات
- مسارات تصعيد الصلاحيات
- آليات الثبات
- انتهاكات الامتثال
حدود الاختبار
الأنشطة ضمن النطاق
| النشاط | مسموح عادة | يتطلب موافقة |
|---|---|---|
| تعداد API | نعم | - |
| تحليل سياسة IAM | نعم | - |
| اختبار صلاحيات التخزين | نعم | - |
| مسح الشبكة | محدود | نعم |
| اختبار DoS | لا | موافقة خاصة |
| الوصول لبيانات الإنتاج | حسب الحالة | نعم |
سياسات مزود السحابة
AWS:
- لا حاجة لموافقة مسبقة لمعظم الاختبارات
- محظور: DoS، مسح منطقة DNS، إغراق المنافذ
- الإبلاغ عن الثغرات عبر HackerOne
Azure:
- اتبع قواعد الاشتباك
- لا اختبار للبنية التحتية لـ Microsoft
- إشعار 24 ساعة لاختبارات معينة
GCP:
- سياسة الاستخدام المقبول القياسية
- لا اختبار للبنية التحتية لـ Google
- المسح الآلي يتطلب إشعار
أنواع التقييم
| النوع | التركيز | المدة |
|---|---|---|
| مراجعة التكوين | معايير CIS، الأخطاء في التكوين | 1-2 أسابيع |
| اختبار اختراق (محدود) | خدمة/تطبيق محدد | 1-2 أسابيع |
| اختبار اختراق (شامل) | تقييم حساب كامل | 3-4 أسابيع |
| فريق أحمر | محاكاة هجوم كاملة | 4-8 أسابيع |
| اختبار مستمر | تقييم مستمر | مستمر |
التالي، سنغطي تقنيات التعداد والاستطلاع لبيئات السحابة. :::