Nerd Level Tech logo
|
الدرس 21 من 24

اختبار اختراق السحابة والتقييم

منهجية اختبار اختراق السحابة

4 دقيقة للقراءة

اختبار اختراق السحابة يتطلب نهجاً مختلفاً عن اختبار البنية التحتية التقليدية. فهم نموذج المسؤولية المشتركة وسطح الهجوم المتمركز حول API والتقنيات الخاصة بالسحابة ضروري لتقييمات أمنية فعالة.

اختبار اختراق السحابة مقابل التقليدي

الفروقات الرئيسية

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

متطلبات اختبار اختراق السحابة

قبل اختبار بيئات السحابة:

  1. تفويض مكتوب من مالك حساب السحابة
  2. إشعار مزود السحابة (سياسة AWS Pentest، ROE لـ Azure، الاستخدام المقبول لـ GCP)
  3. نطاق محدد - حسابات ومناطق وخدمات محددة
  4. جهات اتصال طوارئ للاستجابة للحوادث
  5. اتفاقية معالجة البيانات لبيانات الاعتماد المكتشفة

إطار اختبار اختراق السحابة

مصفوفة 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 أسابيع
اختبار مستمر تقييم مستمر مستمر

التالي، سنغطي تقنيات التعداد والاستطلاع لبيئات السحابة. :::

اختبار

الوحدة 6: اختبار اختراق السحابة والتقييم

خذ الاختبار