لقد أحدثت الحاويات (Containers) والخدمات المصغّرة (Microservices) ثورة في تطوير التطبيقات وإدارة البنية التحتية لها، وقدمت لنا تحديات أمنية جديدة دون أن تعالج التحديات السابقة. إذن ما هي أبرز التحديات الأمنية الجديدة؟ وما الذي يجب علينا فعله تجاهها؟
تقنيات جديدة وتحديات جديدة
تُعدّ الخدمات المصغّرة (Microservices) من أشهر المعماريات البرمجية في وقتنا الحالي، والتي جاءت لتحل مشاكل الطريقة التقليدية في تطوير المشاريع والتي تُعرف باسم (Monolithic) وهي معمارية تجعل كلّ خدمات المشروع عبارة عن وحدات برمجية متراصّة ومتجانسة مع بعضها بعضًا وتعمل جميعها في وقت واحد. فإذا حدث مشكلة ما في أحد خدمات المشروع سوف تتأثر جميع الأجزء المتجانسة الأخرى أمّا (Microservices) قسّمت المشروع الواحد إلى عِدّة مشاريع منفصلة، وكلّ مشروع يكون عبارة عن خدمة مصغرة، وتعمل كل خدمة منهم بشكل مستقل عن الخدمة الأخرى مع إمكانية إتصال خدمة معينة بخدمة أخرى من خلال قنوات اتصال محددة.
لقد غيّرت الخدمات المصغّرة كلّ شيء. إذ نلاحظ أن أغلب الشركات في وقتنا الحالي تتجه لوضع خارطة عملٍ معتمدة على الخدمات المصغّرة باستخدام بنى معمارية مثل البنية التحتية الثابتة (Immutable infrastructure)، أو البنية المعمارية التي لا تدعم التشارك (shared-nothing architecture)، أو التطبيقات المتوضعة في الحاويات (containerized applications).
لقد كانت طريقة الكشف عن فعالية المشاريع في حالات معينة مثل العمل في نطاق صغير، أو في الإستقلالية، أو في تحقيق الإستدامة الذاتية تُعرف عند بناء الواجهة البرمجية API وتشغيلها على الآلة الوهمية (virtual machine) أو بداخل حاوية، أو حتى بتشغيلها على القرص الصلب (حيث يكون مُثبت عليه نظام التشغيل)، أما الآن فيمكننا الكشف عن فعالية هذه المشاريع باستخدام الخدمات المصغّرة بحيث يتم إختبار كلّ حالة على حدة ومعرفة فعالية المشاريع بدون بناء واجهة برمجية.
وعلى الرغم من المزايا المتعددة لإستخدام الحاويات إلا أنها تقدم لنا مجموعة من التحديات أيضًا من بين تلك التحديات المباشرة التي تواجه الحاويات هي الزحف على الحاويات (container crawl)، وحماية الحاويات، وتعقب الخدمات المصغّرة، ومعرفة مصدر نُسخ الحاويات.
إذًا ما تأثير ذلك على الأمن في بيئة الخدمات المصغّرة؟ إن التحديات الأمنية لا تزال موجودة في بيئة التطبيقات أحادية النواة monolithic applications، ولا نزال نحتاج إلى معرفتها وتحديدها لمعالجتها. بالإضافة إلى ذلك، نحتاج إلى النظر في التحديات الأمنية الإضافية التي تفرضها الخدمات المصغّرة وتقنيات الحاويات.
ومن منظور أمني، زادت إمكانية التعرض للهجوم بشكل كبير في عالم الخدمات المصغّرة بالموازنة مع التطبيقات أحادية النواة. أن زيادة قابلية النشر للوحدات وللأجهزة البعيدة (مثل: الهواتف الذكية والأجهزة المحمولة والأجهزة اللاسلكية الأخرى) أدى إلى زيادة التعرض للخطر، وإحتمالية حدوث هجوم أمني على الأجهزة البعيدة، ومشكلات التكاملية. بالإضافة إلى ذلك، قد تحتوي نُسخ Docker الأساسية على ثغرات أمنية والتي قد تضر بالخدمات المصغّرة. لذا ينبغي إدارة مصدر نُسخ Docker لضمان صحتها وخلوها من الثغرات. ويشكّل نشر تحديثات الأمنية والترقيعات مع المحافظة على أدنى مدة زمنية لتعطل الحاويات تحديًا آخر يصعب تجاوزه. يمكن أن تضيف DevOps المزيد من التركيز على الاحتياجات الأمنية في عالم الخدمات المصغّرة. حيث تركز أدوات النشر والبناء المستمرة حاليًا على تبسيط عملية التسليم، على الرغم من عدم تركيزها كثيرًا على حماية DevOps .
أفضل الممارسات الأمنية
لمواجهة بعض التحديات المذكورة أنفًا، دعونا نُلق نظرة على أفضل الممارسات التي يمكن إتخاذها. كجزء من استراتيجية DevOps الفعالة، يجب دمج خطوات الحماية والتدقيق المستمرة في منهجية DevOps. ويجب أن يتضمن الاختبار المستمر مُميزات إختبار الأمان المختلفة ويجب إضافة التحقق من سلامة نُسخ الحاويات إلى منهجية DevOps. وكما يمكننا أيضًا استخدام السجلات الخاصة private registries والتي تضمن لنا أن النُسخ موثوق بها وموجودة داخل الشركة.
وينبغي تعزيز المراقبة من خلال آليات للكشف عن حالات الشذوذ لاكتشاف أي استخدام خاطئ للموارد أو الأحداث الغير طبيعية مع الحاويات، كما ينبغي تعزيز جميع قدرات المراقبة لتتبع العمليات المعتمدة على وكيل (agent-based) والعمليات بدون وكيل (agentless). كما يجب تحديث إدارة الترقيعات (Patch management) وتحسينها لضمان ترقيع الحاويات بأحدث التحديثات مع ضمان الحد الأدنى من وقت التوقف عن العمل.
ولقد قدم Docker آلية لتحديد مصدر النُسخ تسمى (Notary)، والتي تستند إلى TUF (اختصارًا إلى The Update (Framework الذي يُستخدم في توزيع وتحديث البرامج بشكل نموذجي). ولكن العديد من أخصائيي الحاويات في وقتنا الحالي لا يستخدمونه Notary وذلك لأنه لا يزال في مرحلة التطوير. كما أن Notary يتطلب عملية إدارة رئيسية خبيرة في الشركة. تعدّ المنطقة التي تقع بين الخدمات المصغّرة من المناطق التي تُرتكب فيها الأخطاء أمنية، ويمكن استخدام Gateway API (وهي برمجية تقع أمام الواجهة البرمجية وتعمل كنقطة دخول واحدة لمجموعة محددة من الخدمات المصغّرة) بفعالية في هذا الموقف. إن تشفير الرسائل باستخدام تشفير الرسائل التقليدي PKI (البنية التحتية للمفتاح العام Public Key Infrastructure وهو إطار التشفير والأمن السيبراني الذي يحمي الاتصالات بين الخادم والعميل) ليس خيارًا قابلًا للتوسعة في هذا الموقف. لذا بدلًا من ذلك، يمكننا استخدام JSON Web Token) JWT) وهو رمز مشفّر مع مجموعة من سياسات التأكيد assertion policies حول الطالب للخدمة (requestor).حيث يوقعّ خادم الهوية الرسائل برمز مُميز والذي يُمكن التحقق منه بواسطة نظام المستلم (recipient system). كما يمكن تشفير JWT رقميًا للحفاظ على سرية وسلامة التأكيدات (assertions) والتي تسمى حينَئِذٍ JSON Web Encryption) JWE).
غالبًا ما تكون الحماية صعبة وباهظة الثمن. لذا حاول أن تجعل من الحماية سمة أساسية للبنية التحتية للخدمات المصغّرة لتوفير أفضل مستوى من الأمان والأداء.
ترجمة -وبتصرف- للمقال Secured DevOps for microservices لصاحبه Sreekanth Nyamars
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.