ما هي الأطر التي يمكن أن تساعد في حدوث ارتباك الأمن السحابي؟

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

 

أحد الأشياء التي تجعل هذا الأمر محيراً للغاية هو وفرة الاختصارات السحابية المستخدمة لشرح العديد من أطر أمان السحابة مثل إدارة وضع الأمن السحابي (cloud security posture management – CSPM)، وحماية عبء العمل السحابي (cloud workload protection – CWP)، وإستراتيجية أحدث تُعرف باسم منصة حماية التطبيقات السحابية الأصلية (cloud-native application protection platform – CNAPP). لذلك لا ينبغي إغفال الهوية السحابية وإدارة الاستحقاقات (cloud identity and entitlement management – CIEM)، والتي تهتم بأقل امتيازات الوصول واستحقاقات الموارد في السحابة العامة.

 

ولكن كيف يمكنك إنشاء برنامج الأمن السحابي عند تطوير التطبيقات واستخدام أحمال العمل السحابية العامة من Amazon Web Services وGoogle Cloud Platform (GCP) وAzure؟ تكمن المشكلة الرئيسية في أن أدوات وبرامج الأمان القديمة تكافح حقًا لإضافة قيمة كبيرة في سياق التطبيقات السحابية، والتي يمكن القول إنها أصبحت أحد أهم نواقل الهجوم وهي بلا شك أكثر ناقلات الهجوم الديناميكية. في هذه الأيام، يتعين على كل فريق أمني اليوم التعامل مع هذه المشكلة.

 

أولويات تطوير برنامج أمان سحابي شامل

 

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

 

الأولوية الأولى

 

هي حواجز الحماية، هل يمكنك إنشاء حواجز حماية ضد التكوينات الخاطئة الواضحة التي ستؤدي إلى خرق البيانات؟ كم مرة سمعنا فيها عن شركة قامت ببناء شيء ما على Amazon أو Azure فقط ليتم اختراق حاوية S3 الخاصة بها؟ أو عن قواعد بيانات Firebase أو Elastic DB أو MongoDB أو Azure التي تعرضت للاختراق؟ غالباً ما يكون السبب هو خطأ في التكوين.

 

الخبر السار هو أن الخيارات تتزايد وأن الأسعار تتناقص أخيراً لقضبان حراسة الأمان الأساسية في السحابة.

 

الأولوية الثانية

 

هي حماية أعباء العمل والتطبيقات والخدمات التي يستخدمها التطوير والعمليات (DevOps) بعد إجراءات الحماية الأساسية في برنامج الأمان السحابي. إن تحديد ومعالجة نقاط الضعف وانتهاكات السياسة بشكل مستمر هو في نهاية المطاف مسؤولية المنظمة، ووقت ما قبل الإنتاج هو الوقت المناسب للتحسينات الأمنية السحابية ووضع عناصر التحكم أثناء تشغيل التطبيق في الإنتاج. أما Amazon أو Microsoft أو Google أو Alibaba، أو أي مزود خدمة سحابية عامة آخر، فلن يكون مسؤولاً عن ذلك أبداً.

 

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

 

الأولوية النهائية

 

هي اتجاه متطور يتجاوز مجرد إعداد التقارير والتدقيق ألا وهو المراقبة؛ تعد إمكانية المراقبة من أهم أولويات جميع برامج التطوير والأمان والعمليات (DevSecOps). تستلزم إمكانية المراقبة مشاهدة البيئات ليس فقط من منظور الامتثال ولكن أيضاً من منظور المخاطر. يجب أن تستثمر المؤسسات بكثافة في الانتقال من المراقبة إلى إمكانية المراقبة من أجل فهم بيئة السحابة بشكل كامل. إنه مطلب ضروري في السحابة العامة ولكنه ليس بسيطاً.

 

مجالات الحماية في CNAPP

 

لماذا يجب أن نهتم بمنصات حماية التطبيقات السحابية الأصلية (CNAPP) – اختصار آخر للأمن السحابي – عند التفكير في مناهج جديدة للأمن السحابي؟ تشمل المبادئ التوجيهية في CNAPP حماية وقت التشغيل، وتكوين السحابة (حواجز حماية الخدمات الأساسية)، ومسح أداة التطبيق (ما قبل الإنتاج).

 

عندما يتم تطوير التطبيق وتحميله لأول مرة على السحابة، أو عندما يتم إنشاء البرنامج، فإن هذا هو أول مجال للحماية في CNAPP. أنت بحاجة إلى مسح ضوئي محسّن هنا، سواء كان في مرحلة ما قبل الإنتاج أو في مرحلة الاختبار والتطوير. لطالما حافظت برامج أمان التطبيقات (AppSec) على التحليل الثابت والتحليل الديناميكي وتحليل تكوين البرامج ومسح واكتشاف واجهات برمجة التطبيقات (APIs). تتأكد هذه الخطوة من أن المطورين على دراية بالتطبيق أثناء إنشائه، وأن لديهم نسخة منه، ويمكنهم إجراء فحوصات أمنية قبل دفعه إلى بيئة وقت التشغيل المستخدمة للإنتاج. عندما يعمل CNAPP بشكل صحيح، يمكنه الاستفادة من نتائج مسح AppSec وإدخالها في المرحلتين التاليتين من التكوين ووقت التشغيل.

 

تكوين السحابة هو مجال الحماية الثاني لـCNAPP. يعد هذا ضروريًا سواء كنا نتحدث عن CSPM أو أفضل الممارسات لتكوين السحابة. كان التهيئة السحابية الخاطئة هي المساهم الأساسي في العديد من أكبر انتهاكات البيانات التي حدثت هناك. تعتبر التوصيات الخاصة بتكوين السحابة من CNAPP أكثر شمولاً من تلك الواردة من CSPM لأنها تبدأ في الاعتماد على طبقات التطبيق وواجهة برمجة التطبيقات التي تتجاوز مجرد فحص البنية التحتية. يتم أيضًا إجراء عمليات تدقيق CNAPP للوصول إلى الامتيازات الأقل التي تفرضها إدارة الوصول إلى الهوية (IAM) وإدارة الهوية والاستحقاق السحابية (CIEM).

 

حماية وقت التشغيل هو مجال الحماية الثالث لـCNAPP، وهي تعتمد على تاريخ وضع جدران الحماية، وجدران الحماية لتطبيقات الويب، وعوامل الكشف عن نقاط النهاية والاستجابة لها. باستخدام هذه الطريقة، يمكن إيقاف الهجمات والاعتداءات الضارة أثناء تشغيل أحد التطبيقات. ولكن عندما تحاول نقل الأدوات من عصور جدار الحماية القديمة ومراكز البيانات المحلية التقليدية (جنبًا إلى جنب مع وكلاء Windows) إلى بيئة سحابية أصلية، تفشل الأدوات إلى حد كبير وتزيد المخاطر بشكل كبير على المؤسسات.

 

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

 

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