بنية تحتية آمنة على GCP
قائمة التحقق من تعزيز أمان GCP للفرق الصغيرة والمتوسطة
خط أساس عملي للفرق التي تشغّل أحمال عمل إنتاجية على Google Cloud دون قسم أمن مخصص. ابدأ حيث يسهل تقليص المسارات الأكثر ترجيحًا لوقوع حادث خطير.
مسارات التهديد الشائعة في GCP
تبدأ معظم الحوادث السحابية بفجوة صغيرة في الملكية أو الإعدادات. ابحث عن هذه المسارات قبل أن يجدها المهاجم.
- يمكن لمستخدم أو حساب خدمة أو هوية حمل عمل يتمتع بأذونات زائدة أن يحوّل بيانات اعتماد مسروقة واحدة إلى وصول واسع عبر المشاريع.
- يمكن لنقطة نهاية إدارية مكشوفة، أو منفذ لتصحيح الأخطاء، أو قاعدة جدار حماية متساهلة أن تتجاوز كل ضابط مصمم لحركة مرور التطبيقات العادية.
- يمكن لحزمة تخزين عامة أو عنوان URL موقَّع واسع النطاق أكثر من اللازم أن يكشف بيانات العملاء دون أي اختراق ظاهر للتطبيق.
- تُنشئ أحمال العمل المهملة خطرًا مستمرًا عندما تظل صور الحاويات القديمة ومساحات الأسماء المنسية وحسابات الخدمة غير المستخدمة والموارد التي لا مالك لها قابلة للنشر.
- إن أدلة التدقيق المفقودة أو القصيرة الأمد تجعل من الصعب تحديد من قام بتغيير السياسة، ومتى بدأ الوصول، وما هي البيانات التي تم الوصول إليها.
- النسخ الاحتياطي غير المختبر هو مجرد أمل. يمكن أن يؤدي فشل الاستعادة، والاحتفاظ غير الكامل، ومفاتيح التشفير التي لا يمكن الوصول إليها إلى تحويل حدث أمني إلى خسارة دائمة.
الهوية والوصول
تعامل مع الهوية باعتبارها مستوى التحكم الأساسي. يجب أن تكون لكل شخص ولكل عملية أتمتة ولكل حمل عمل هوية مميزة ذات غرض محدد.
اجعل حدود المورد واضحة
استخدم المؤسسة والمجلدات لوضع ضوابط الحماية، وافصل بيئات التطوير والتجهيز المرحلي والإنتاج في مشاريع منفصلة أو حدود ثقة أقوى. طبّق سياسات المؤسسة على أعلى مستوى عملي، وقيّد استخدام الخدمات، وتجنّب مشاركة مشاريع الإنتاج بين منتجات غير مرتبطة.
امنح الحد الأدنى من الأدوار في أضيق نطاق
فضّل الأدوار المحددة مسبقًا أو المخصصة على الأدوار الأساسية الواسعة، وامنحها للمجموعات ولهويات أحمال العمل، واستخدم شروط IAM حيث يمكن لاسم المورد أو العلامة تضييق نطاق الوصول. راجع الأذونات غير المستخدمة، وأزِل الوصول الدائم إلى الإنتاج الذي يجب أن يقتصر على إجراء وصول الطوارئ (break-glass).
أزِل بيانات الاعتماد طويلة الأمد
استخدم Workload Identity Federation for GKE لكي تتلقى وحدات Pod بيانات اعتماد قصيرة الأمد دون مفاتيح حسابات خدمة مُصدَّرة. احظر إنشاء المفاتيح وتحميلها عبر سياسة المؤسسة حيثما أمكن، وأنشئ جردًا لأي مفاتيح متبقية، وفعّل التنبيهات على تغييرات IAM عالية الخطورة في Cloud Audit Logs.
الشبكة والحافة
افترض أن عيبًا ما في التطبيق سيصبح في النهاية قابلًا للوصول من الشبكة. قيّد ما يمكن لهذا العيب الوصول إليه.
ابدأ بالرفض وأضف مسارات محددة بالاسم
استخدم قواعد جدار حماية VPC وفق مبدأ الحد الأدنى من الامتيازات، وKubernetes NetworkPolicies لحركة مرور وحدات Pod. افصل البيئات في شبكات مستقلة، ووثّق كل مسار للحركة الواردة، وأزِل قواعد التصحيح الواسعة التي تسمح بمنافذ الإدارة أو بجميع البروتوكولات من نطاقات عناوين كبيرة.
أبقِ العُقد ومستويات التحكم خاصة
عطّل عناوين IP الخارجية على عُقد GKE. فضّل نقطة نهاية مستوى التحكم الخاصة المستندة إلى DNS، وعندما لا مفر من نقطة نهاية IP، قيّدها باستخدام الشبكات المعتمدة. امنح أحمال العمل مسارًا مدروسًا للحركة الصادرة بدلًا من وصول واسع إلى الإنترنت.
انشر الخدمات العامة المقصودة فقط
اعرض التطبيقات عبر بوابة أو موازن تحميل خضع للمراجعة، لا عبر عناوين عرضية لوحدات Pod أو العُقد. نفّذ إنهاء TLS باستخدام شهادات مُدارة، وقيّد مضيفي الحركة الواردة ومساراتها، وطبّق حدودًا للطلبات والمعدّل، وأبقِ واجهات الإدارة خلف وصول مستند إلى الهوية.
البيانات والأسرار
احمِ البيانات في حالة السكون وأثناء النقل وأثناء الاستخدام، ثم أثبت قدرتك على استعادتها. اكتشاف البيانات جزء من الضابط.
امنع الوصول العام غير المقصود
افرض منع الوصول العام والوصول الموحّد على مستوى الحزمة في Cloud Storage. صنّف الحِزم حسب الحساسية، وقيّد الوصول إلى العناصر والمفاتيح، وفعّل التسجيل للبيانات عالية القيمة، واستخدم مفاتيح التشفير التي يديرها العميل حيث يتطلبها نموذج المخاطر أو الامتثال لديك.
أبقِ الأسرار خارج صور الحاويات والشيفرة المصدرية
خزّن بيانات الاعتماد في Secret Manager، وامنح الوصول لهوية حمل عمل محددة ولإصدار سرّ محدد. دوّر الأسرار بشكل مدروس، وتجنّب نسخها إلى Git أو إلى صور الحاويات، ولا تعامل Kubernetes Secrets العادية كحدّ حماية كامل.
اختبر الاسترداد، لا إنشاء النسخ الاحتياطية فقط
حدّد أهداف نقطة الاسترداد ووقت الاسترداد، واحتفظ بنسخ خارج نطاق أعطال بيئة الإنتاج، واحمِ الوصول إلى النسخ الاحتياطية ومفاتيح التشفير من هوية حمل العمل. نفّذ الاستعادة في بيئة معزولة وفق جدول زمني، وتحقق من البيانات، وسجّل الوقت المستغرق وأي خطوات يدوية.
تعزيز أمان GKE
يؤمّن GKE مستوى التحكم المُدار، لكن إعدادات العنقود ومساحات الأسماء وسياسات القبول وأحمال العمل تبقى مسؤوليتك في الحوكمة.
اجعل مساحات الأسماء أساس عقد العزل
افصل الفرق والبيئات في مساحات أسماء أو عناقيد، واربط فيها أدوار Kubernetes RBAC ضيقة النطاق، وطبّق حصص الموارد وNetworkPolicies. تجنّب منح صلاحية الكتابة على مستوى العنقود لتسليم التطبيقات، وامنح كل حمل عمل حساب خدمة خاصًا به عندما يحتاج إلى هوية مميزة.
اقبل فقط صور الحاويات والإعدادات التي تثق بها
افرض معيار Pod Security المقيَّد (restricted) أو قواعد Policy Controller مكافئة. انشر صور الحاويات باستخدام ملخص (digest) غير قابل للتغيير، وافحصها بحثًا عن الثغرات، واستخدم Binary Authorization حيث يهم مصدر الصور، وارفض الوصول غير المتوقع إلى المضيف وتصعيد الامتيازات وروابط cluster-admin.
أزِل صلاحيات الحاويات غير الضرورية
شغّل الحاويات كمستخدم غير جذري، وأسقِط إمكانات Linux (capabilities)، واستخدم نظام ملفات جذر للقراءة فقط حيثما أمكن، وطبّق ملف تعريف seccomp باسم RuntimeDefault. لا تركّب رمز حساب الخدمة المميز دون حاجة، وتجنّب الحاويات ذات الامتيازات ومساحات أسماء المضيف، وأبقِ حساب خدمة العقدة بأدنى الصلاحيات، واستخدم Shielded Nodes مع Container-Optimized OS.
الكشف والاسترداد
الضوابط تفشل. اعتمد على الأدلة والإجراءات التي جرى التدرّب عليها، لا على الثقة بأن أحدًا لم يرتكب خطأ.
اجمع الأدلة التي ستحتاجها
احتفظ بـ Cloud Audit Logs وسجلات النظام وأحمال العمل في GKE في وجهة مركزية بمدة احتفاظ تلائم احتياجات التحقيق لديك. فعّل سجلات الوصول إلى البيانات (Data Access) بشكل انتقائي للبيانات الحساسة، وقيّد الوصول إلى السجلات، وسجّل التغييرات الإدارية على IAM وجدار الحماية والتخزين وإعدادات العنقود.
فعّل التنبيه على التغييرات ذات الأثر الأمني
فعّل التنبيهات عند كشف التخزين للعامة، والتغييرات الواسعة في جدار الحماية أو IAM، ومفاتيح حسابات الخدمة غير المتوقعة، وحالات الرفض في مرحلة القبول، وكشف مستوى التحكم، وتكرار فشل المصادقة، وتعطيل التسجيل، وفشل النسخ الاحتياطية، والشهادات التي تقترب صلاحيتها من الانتهاء. وجّه كل تنبيه إلى مالك مع خطوات تأكيده أو رفضه.
تدرّب على الاستجابة
اكتب أدلة تشغيل قصيرة لحالات تسرّب بيانات الاعتماد، والبيانات المكشوفة للعامة، وأحمال العمل المخترقة، وفقدان مناطق أو مشاريع. حدّد فيها من يمكنه الإذن بالاحتواء، وكيفية إلغاء الوصول، وكيفية الحفاظ على الأدلة، وكيفية استعادة الخدمة. اختبر أدلة التشغيل مع الأشخاص الذين سيستخدمونها.
قائمة تحقق مرتبة حسب الأولوية لمدة 30 و60 و90 يومًا
إذا كنت تبدأ من خط أساس غير مكتمل، فقم بتسلسل العمل لتقليل التعرض أولاً وجعل المراجعات اللاحقة قابلة للتكرار.
الأيام من 1 إلى 30: أوقف المسارات الواضحة
أنشئ جردًا بالمشاريع ومالكيها، وأزِل بيانات الاعتماد غير المستخدمة وطويلة الأمد، وتأكّد من تفعيل سجلات التدقيق، واحظر الحِزم العامة، وراجع أوسع قواعد جدار الحماية ومنح أذونات IAM، وحدّد الثغرات في النسخ الاحتياطية للإنتاج، وعالج أي نقطة نهاية عامة لا مالك لها. عيّن مالكًا وتاريخ استحقاق لكل نتيجة.
الأيام من 31 إلى 60: اجعل خط الأساس قابلاً للتكرار
انقل إعدادات الشبكة والهوية وأحمال العمل إلى بنية تحتية كرمز خاضعة للمراجعة وإلى التسليم عبر GitOps. اعتمد Workload Identity، والعُقد الخاصة، ومعيار Pod Security المقيَّد، والتحقق من صور الحاويات الموثوقة، والسجلات المركزية، والتنبيهات على أهم التغييرات.
الأيام من 61 إلى 90: أثبت النتائج وحافظ عليها
نفّذ اختبارات الاستعادة وتمرين محاكاة للحوادث على الطاولة (tabletop)، وراجع الوصول المميز وانتهاء صلاحية الاستثناءات، وافحص صور الحاويات والتبعيات مجددًا، وتحقق من أن المالكين يتلقون التنبيهات، وقِس الثغرات المتبقية. أدرج عمليات التحقق ضمن دورة مراجعة دورية قبل أن تصبح الأدلة قديمة.
استخدم قائمة التحقق هذه كنقطة انطلاق. يمكن لـ Snow Tree تطبيق خط الأساس عبر تشغيل المنصة المُدارة أو مهمة استشارية مركّزة.
المراجع الرسمية
استخدم إرشادات Google الحالية كمصدر الحقيقة التقني عندما تتغير الإعدادات الافتراضية للمنصة أو إمكانات المنتجات.
المنصة المُدارة