تأمين الانتقال إلى السحابة المختلطة

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

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

يصبح السؤال بعد ذلك: كيف يمكن لمؤسسة الحفاظ على حوكمة متسقة وإنفاذ السياسة والضوابط عبر السحب المختلفة؟ وكيف تتأكد من أنها تحافظ على وضعها الأمني ​​عند التنقل بينها؟ لحسن الحظ ، هناك خطوات يمكن للمحترفين اتخاذها للتأكد من أن التطبيقات آمنة باستمرار ، بدءًا من المراحل الأولى من التطوير وتمتد طوال دورة الحياة.

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

بالإضافة إلى ذلك ، في بيئة السحابة الديناميكية والمتنوعة ، لم تعد الحلول الأمنية تتوقع أو تعتمد على بنية أساسية وموقع دائمين. إذا علمنا في الماضي أن خادمًا معينًا قام بتشغيل تطبيق معين (على سبيل المثال ، خادم أو قاعدة بيانات Microsoft Exchange) ، فلا يمكننا افتراض أن نفس السيناريو ينطبق اليوم. ترتبط حلول التطبيقات السحابية الحديثة بالتطبيق نفسه ، وليس بعنوان IP الخاص به أو موقع خادم معين. يعني التنظيم الآلي لأحمال العمل أن قاعدة البيانات قد تعمل على حاوية واحدة الآن وعلى حاوية مختلفة ، بعنوان IP مختلف ، بعد 10 دقائق. أو ، ربما ، غدًا ، ستنتقل المجموعة بأكملها إلى موفر سحابة مختلف تمامًا. لهذا السبب تحتاج المؤسسات إلى استخدام حلول أكثر حداثة خاصة بالسحابة بدلاً من الحلول القديمة غير المخصصة للسحابة.

أدوات الأمان الخاصة بموفري السحابة: إجابة محدودة
يستخدم جميع موفري الخدمات السحابية الرئيسيين ما يسمى “نموذج المسؤولية المشتركة” ، والذي يميز ، على مستوى مبسط للغاية ، بين أمان “السحابة” (مسؤولية الموفر) والأمان “في السحابة” (مسؤولية العميل). “المسؤولية المشتركة” لا تترجم إلى مساءلة مشتركة. عندما يتعلق الأمر بالأمن المادي لمراكز البيانات السحابية العامة ، فلا داعي للقلق على المؤسسات ؛ يقوم موفرو السحابة بتشغيل مثل هذا الأمان بأعلى المعايير ، على غرار تلك المستخدمة من قبل البنوك الكبرى والوكالات الحكومية. ولكن بالنسبة لكل شيء آخر ، تقع المسؤولية بشكل مباشر على عاتق مؤسسات العملاء – في الواقع ، تتوقع شركة Gartner أنه حتى عام 2025 ، ستحدث 99٪ من حالات فشل أمان السحابة من جانب العميل.

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

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

نظرًا لأن الحاويات مصنوعة لتكون محمولة ، فقد تم تصميم Kubernetes لتكون قابلة للتشغيل مع أي بيئة سحابية