نموذج المسؤولية المشتركة

نموذج المسؤولية المشتركة هو المفهوم الأساسي لأمان السحابة. يحدد بالضبط من يؤمن ماذا—وسوء فهمه وراء معظم خروقات السحابة.

المبدأ الأساسي

مزودو السحابة يؤمنون البنية التحتية السحابية نفسها. أنت تؤمن ما تضعه فيها وكيف تكونها.

مسؤوليات المزود (أمان السحابة):

• أمان مركز البيانات المادي
• الأجهزة و hypervisor
• البنية التحتية للشبكة
• أنظمة التخزين
• العمود الفقري العالمي

مسؤولياتك (الأمان في السحابة):

• إدارة الهوية والوصول
• تشفير وحماية البيانات
• تكوين نظام التشغيل
• أمان التطبيق
• تكوين الشبكة
• قواعد جدار الحماية

كيف يتغير حسب نموذج الخدمة

التقسيم يتغير بشكل كبير بناءً على نموذج الخدمة المستخدم:

الطبقة	IaaS (EC2, VMs)	PaaS (Lambda, App Service)	SaaS (S3, DynamoDB)
البيانات	العميل	العميل	العميل
التطبيق	العميل	العميل	المزود
Runtime	العميل	مشترك	المزود
OS	العميل	المزود	المزود
Virtualization	المزود	المزود	المزود
الأجهزة	المزود	المزود	المزود

كلما كانت الخدمة أكثر إدارة، قلت مسؤوليتك—لكنك دائماً مسؤول عن:

• بياناتك
• ضوابط الوصول الخاصة بك
• تكويناتك

نماذج خاصة بالمزودين

المسؤولية المشتركة في AWS

┌─────────────────────────────────────────────────────┐
│                    العميل                            │
│  البيانات، المنصات، التطبيقات، الهوية، التشفير        │
│  OS، تكوين الشبكة، جدار الحماية، التشفير من جانب العميل│
├─────────────────────────────────────────────────────┤
│                      AWS                             │
│  الأجهزة، البرمجيات، الشبكات، المرافق               │
│  الحوسبة، التخزين، قواعد البيانات، خدمات الشبكات    │
│  البنية التحتية العالمية لـ AWS، المناطق، AZs، Edge   │
└─────────────────────────────────────────────────────┘

المسؤولية المشتركة في Azure

Azure يستخدم نفس النموذج لكن يؤكد على "الضوابط المشتركة"—المجالات التي يتحمل فيها الطرفان مسؤوليات:

• إدارة الهوية: Microsoft تؤمن Entra ID؛ أنت تكونه بشكل صحيح
• تصنيف البيانات: Azure يوفر الأدوات؛ أنت تصنف وتحمي بياناتك
• حماية النقاط الطرفية: Azure يؤمن نقاطهم؛ أنت تؤمن نقاطك

المصير المشترك في GCP

Google قدمت مفهوم "المصير المشترك"، معترفة بأن إخفاقات أمان العملاء تضر الجميع:

• GCP يوفر تكوينات آمنة افتراضياً
• Security Command Center يقدم مراقبة مستمرة
• Google تساعد العملاء بنشاط في إصلاح الأخطاء

الخلط الشائع في المسؤولية

هذه المفاهيم الخاطئة تسبب الخروقات:

المفهوم الخاطئ	الحقيقة
"AWS يشفر بياناتي"	AWS يوفر أدوات التشفير؛ أنت يجب أن تفعّلها
"S3 bucket خاص"	الافتراضي تغير إلى خاص في 2023، لكن تحقق من إعداداتك
"جدار الحماية يحميني"	أنت تكون مجموعات الأمان و NACLs
"التحديثات تلقائية"	فقط للخدمات المُدارة؛ EC2 مسؤوليتك
"بياناتي منسوخة احتياطياً"	أنت تكون النسخ الاحتياطية؛ الافتراضي غالباً لا شيء

فخ التكوين

هنا حيث تنشأ 80% من الخروقات—أخطاء التكوين:

# سياسة S3 bucket هذه تبدو معقولة...
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": "*",           # خطر: أي شخص على الإنترنت!
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::my-bucket/*"
    }]
}

المزود أعطاك الأدوات. أعطاك الافتراضيات (الآن آمنة افتراضياً لـ S3). لكن أنت أنشأت هذه السياسة. أنت كشفت بياناتك.

قائمة التحقق الأمنية

بناءً على نموذج المسؤولية المشتركة، يجب دائماً التحقق من:

1. الهوية: هل سياسات IAM بأقل صلاحيات؟
2. البيانات: هل البيانات الحساسة مشفرة (في الراحة والنقل)؟
3. الشبكة: هل مجموعات الأمان مقيدة بشكل صحيح؟
4. التسجيل: هل CloudTrail/Activity Log مفعّل؟
5. التكوين: هل الموارد تستخدم افتراضيات آمنة؟

المزود يتولى البنية التحتية. التكوين عليك.

التالي، سنفحص التهديدات المحددة التي تستهدف بيئات السحابة. :::