أمن البنية التحتية السحابية المتعددة: استراتيجية موحدة للامتثال والحماية

أين يتحرك خط المسؤولية المشتركة؟

كل مزود خدمة سحابية، سواء كان AWS أو Azure أو Google Cloud، يرسم الخط الفاصل بين ما يؤمنه وما تؤمنه أنت بشكل مختلف، ويتغير هذا الخط حسب الخدمة.

إن وجود آلة افتراضية وقاعدة بيانات مُدارة ووظيفة بدون خادم على نفس السحابة ينقل كل منها حصة مختلفة من المسؤولية إلى فريقك، ونادراً ما يتطابق ذلك مع تقسيم المسؤولية لدى مزود الخدمة الآخر لنفس نوع الخدمة.

الفرق التي تفترض أن نموذج المسؤولية المشتركة ينطبق في كل مكان تميل إلى اكتشاف الفجوة فقط بعد أن يبدأ انحراف التكوين، بمجرد أن لا أحد يملك فعليًا عنصر التحكم الذي فشل.

لماذا قد تكون بالفعل تستخدم بيئات متعددة السحابات؟

قلة من المؤسسات تختار بيئة الحوسبة السحابية المتعددة كقرار أمني. عادةً ما يحدث ذلك لأسباب أخرى، ويتعين على الأمن أن يواكب هذا التطور لاحقاً.

تشمل برامج التشغيل الشائعة ما يلي:

• استقلالية البائع، وتجنب الاعتماد على تسعير أو خطة عمل مزود واحد
• قابلية التوسع، أو الوصول إلى ميزة لا يقدمها إلا مزود واحد بشكل جيد
• المتطلبات الإقليمية أو التعاقدية المتعلقة بمكان معالجة البيانات
• وراثة سحابة ثانية، أو بصمة سحابة هجينة، من خلال عملية استحواذ أو نظام قديم

مهما كان السبب، نادراً ما يتم التخطيط للأمن بالتزامن مع القرار الذي أدى إلى فرضه.

تأمين أحمال عمل الذكاء الاصطناعي عبر السحابات الخاصة بك

تُدخل أنظمة الذكاء الاصطناعي مخاطر لم يتم تصميم حماية أحمال العمل التقليدية لاكتشافها، حيث تنقل البيانات وبيانات الاعتماد وواجهات برمجة التطبيقات بين أحمال العمل السحابية وتوسع نطاق الهجوم بطرق يغفل عنها الفحص الروتيني.
"" html

تمتد هذه المخاطر لتشمل أي سحابة تتصل بها أحمال عمل الذكاء الاصطناعي الخاصة بك، مما يجعل هذه مشكلة أمنية متعددة السحابات بشكل افتراضي.

استمرارية الأعمال عبر مختلف مقدمي الخدمات

غالباً ما يتم بناء خطط التعافي من الكوارث واختبارها في حالة تعطل سحابة واحدة، وليس في حالة حدوث عطل منهجي في منطقة أو خدمة كاملة لمزود الخدمة.

تأخذ خطة استمرارية الأعمال الحقيقية لبيئة متعددة السحابات في الاعتبار أحمال العمل التي يمكن أن تنتقل إلى مزود مختلف تمامًا، وليس مجرد منطقة مختلفة داخل نفس المزود.

قلة من الفرق تتدرب على هذا، لأن اختبار تجاوز الفشل الحقيقي بين مزودي الخدمة أصعب من اختبار تجاوز الفشل بين نفس المزود، لذلك تبقى الفجوة نظرية حتى تصبح غير ذلك.

حدود الشبكة بين سحاباتك

تميل المحادثات الأمنية إلى التركيز على الهوية والتكوين، وتتجاهل مسار الشبكة الذي تنتقل فيه البيانات فعليًا بين مقدمي الخدمات.

لا تمر حركة البيانات عبر اتصال التناظر أو بوابة العبور تلقائيًا بنفس نقاط الفحص التي يطبقها نموذج الثقة الصفرية داخل سحابة واحدة، مما يخلق نقاط عمياء:

• حركة مرور عبر السحابة تتجاوز الرؤية المركزية
• تختلف مسارات تحليل نظام أسماء النطاقات (DNS) باختلاف مزود الخدمة، ونادراً ما تخضع للتدقيق معاً.
• يتم تعريف قواعد التجزئة مرة واحدة لكل سحابة، دون وجود رؤية موحدة عبرها.

لا يظهر أي من هذا في فحص تكوين حساب واحد، لأن الخطر يكمن في الاتصال بين الحسابات.

حسابات السحابة التي لم يوافق عليها أحد

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

نادراً ما تظهر هذه الحسابات في إطار حوكمة مبني حول حسابات تعرفها تكنولوجيا المعلومات بالفعل، وغالباً ما تحتوي على بيانات حساسة لم تقم أي عملية لإدارة وضع أمن البيانات بفحصها.

إن العثور عليهم يعني البحث خارج وحدة التحكم، في تقارير المصروفات، وسجلات نظام أسماء النطاقات، والأدوات التي اعتمدها الموظفون بهدوء لتجاوز الموافقات البطيئة.

الحساب الذي لا يوافق عليه أحد هو أيضاً حساب لا يقوم أحد بتصحيحه، مما يؤدي بهدوء إلى توسيع نطاق الهجوم.

تكاليف الخروج المضمنة في أدوات الأمان

تُعدّ أدوات الأمان الأصلية لمزود الخدمة مريحة لأنها مُدمجة بالفعل في وحدة التحكم التي تستخدمها. لكن هذه الراحة لها ثمنٌ لا تكتشفه معظم الفرق إلا عند محاولتها التخلي عنها.

نادراً ما تنتقل قواعد الكشف ومنطق التنبيهات وسير عمل إدارة الثغرات الأمنية المبنية حول أدوات أحد الموفرين إلى موفر آخر دون إعادة بنائها من الصفر، وهي تكلفة تستحق أخذها في الاعتبار قبل اختيار الأدوات.

من يتم استدعاؤه أولاً

إن وقوع حادثة تؤثر على اثنين من مزودي الخدمات السحابية في وقت واحد يميل إلى كشف شيء لا يمكن للمخطط إظهاره: أي فريق يمتلك فعلياً مسؤولية الاستجابة للحوادث.

هذا سؤال تنظيمي بقدر ما هو سؤال تقني، ويستحق الإجابة عليه قبل أن يؤدي اكتشاف التهديد إلى وقوع حادث حقيقي عبر السحابة.

الصناعات ذات المتطلبات الإضافية

تفرض بعض القطاعات التزامات امتثال تنظيمي تتجاوز الأطر الشائعة بالفعل في قطاعات البرمجيات والخدمات المالية والرعاية الصحية.

• يتعين على المتعاقدين الحكوميين والدفاعيين عادةً إثبات التوافق مع أطر عمل مثل CMMC و NIST SP 800-171، لا سيما عند التعامل مع المعلومات غير المصنفة الخاضعة للرقابة.
• تواجه مؤسسات الطاقة والبنية التحتية الحيوية مجموعة مختلفة من التوقعات، والتي غالباً ما ترتبط بمتطلبات NERC CIP المتعلقة بالتكنولوجيا التشغيلية والأنظمة السيبرانية الفيزيائية

كلاهما يعتمد على نفس الأساس الأمني ​​متعدد السحابات، ويتم تطبيقه على مجموعة أكثر تحديدًا من الضوابط وأولويات إدارة المخاطر.

أسئلة تستحق طرحها قبل اتخاذ القرار

هناك بعض الأسئلة التي تفصل بين استراتيجية أمن الحوسبة السحابية المتعددة المُعدة بشكل حقيقي وتلك التي تبدو مكتملة على الورق فقط:

• هل يعرف أحد أين يقع خط المسؤولية المشتركة لكل خدمة، وليس فقط لكل مزود خدمة؟
• هل يتم فحص حركة البيانات بين السحابات الخاصة بك بنفس سياسة تطبيق حركة البيانات داخل السحابة الواحدة؟
• هل يمكنك ذكر جميع حسابات الحوسبة السحابية التي يتم تحصيل رسوم منها حاليًا على شركتك، بما في ذلك الحسابات التي لم تقم إدارة تقنية المعلومات بإنشائها؟
• إذا حدث حادث مروري عبر السحب الليلة، فمن المسؤول عن الاستجابة؟

تكشف الإجابات ما إذا كانت إدارة الأمن المركزية قد تم بناؤها للحوسبة السحابية المتعددة منذ البداية، أم تم تكييفها معها بعد ذلك.