لماذا تقدم Kubernetes مخاطر مختلفة؟
يعد Kubernetes قويًا لأنه يقوم بأتمتة النشر والقياس والتنسيق ، ولكن نفس مستوى التحكم هذا يوسع أيضًا عدد الأماكن التي يمكن أن يكون فيها للخطأ تأثير واسع. يمكن أن يمنح التصميم الضعيف للمكتب الإقليمي لأفريقيا الوسطى وصولاً مفرطًا إلى البنية التحتية الأساسية ، بما في ذلك الموارد الحساسة ، وفي بعض الحالات ، الرقابة الإدارية. يمكن أن يسمح إعداد القبول المتساهل بأعباء العمل المحفوفة بالمخاطر في الإنتاج. يمكن لسياسة الشبكة المفتوحة بشكل مفرط أن تجعل الحركة الجانبية أسهل.
يقوم Kubernetes أيضًا بتغيير النموذج التشغيلي. إنهم يدافعون عن البنية التحتية المستندة إلى API وأحمال العمل المؤقتة والوظائف الإضافية للمجموعة وحسابات الخدمة وصور الحاويات وبيانات النشر التي قد تتغير باستمرار.
ما هي أكبر مخاطر أمان Kubernetes؟
تكوينات أحمال العمل غير الآمنة: قد تؤدي إعدادات أمان البودات الضعيفة ، أو الحاويات المميزة ، أو الإمكانات الواسعة ، أو أنظمة الملفات الجذرية القابلة للكتابة ، أو الإعدادات الافتراضية غير الآمنة في البيانات إلى تعريض المجموعة غير الضرورية. في كثير من الحالات ، يكون هذا هو المكان الذي يتم فيه تشغيل المخاطر أولاً.
- أذونات مفرطة وأخطاء RBAC: إذا كان لدى المستخدمين أو حسابات الخدمة أو أعباء العمل امتيازات أكثر مما يحتاجون إليه ، فإن نطاق الانفجار ينمو. يمكن أن يؤدي تصميم الوصول الضعيف إلى جعل التصعيد أسهل والاسترداد أكثر صعوبة.
- الثغرات الأمنية في سلسلة التوريد: يمكن أن تحتوي صور الحاوية على نقاط ضعف معروفة أو أسرار مكشوفة أو تبعيات غير موثوق بها أو مكونات تم العبث بها. يساعد فحص الصور ، لكن المصدر والترقيع ونظافة الصورة مهمة أيضًا.
- تطبيق سياسة ضعيف: إذا لم تتحقق المجموعة من صحة ما يمكن نشره ، فيمكن أن تنتقل التكوينات الخطرة مباشرة إلى وقت التشغيل. تساعد عناصر التحكم في السياسة فقط عند تطبيقها بشكل متسق.
- تجزئة الشبكة المسطحة أو الضعيفة: يمكن لشبكات Kubernetes أن تجعل الحركة بين الشرق والغرب فعالة للتطبيقات والمهاجمين على حد سواء إذا كانت الحدود فضفاضة للغاية. يجعل التقسيم الضعيف الاحتواء أكثر صعوبة بمجرد حدوث خطأ ما.
- التسجيل والمراقبة غير الملائمين: إذا لم تقم الفرق بجمع السجلات الصحيحة ومراجعتها ، فيمكن للمهاجمين العمل مع وجود فرصة أقل للاكتشاف ويكون لدى المحققين أدلة أقل للعمل بها بعد الواقعة.
كيف تظهر هذه المخاطر في البيئات الحقيقية؟
من الناحية العملية ، نادرًا ما تظهر مخاطر Kubernetes كفشل مأساوي واحد. وعادة ما يظهر كتراكم لنقاط الضعف الصغيرة القابلة للإصلاح: الصور غير الممسوحة ضوئيًا ، أو أذونات حساب الخدمة الواسعة ، أو سياسات مساحة الاسم غير المتسقة ، أو الملكية غير الواضحة للمجموعات ، أو فحوصات القبول الضعيفة ، أو المراقبة التي تتوقف عند العقدة بدلاً من عبء العمل.
هذا هو السبب في صعوبة أمان Kubernetes من الناحية التشغيلية. يتعين على الفرق تأمين النظام الأساسي ونموذج التسليم حوله. تؤثر التنمية وهندسة النظام الأساسي والعمليات السحابية والأمن على النتيجة.
لماذا تستمر هذه المخاطر؟
وهي مستمرة لأن نظام Kubernetes يمنح الفرق مرونة هائلة ، وللمرونة تكلفة أمنية دائمًا إذا كانت حواجز الحماية ضعيفة. يمكن للفرق التحرك بسرعة ونشرها بشكل متكرر ودعم التطبيقات الموزعة المعقدة ، ولكن يصبح من الصعب إدارة نموذج التحكم إذا كانت المعايير غير متسقة من مجموعة إلى أخرى أو من فريق إلى فريق.
سبب آخر هو تجزئة المسؤولية. قد يمتلك الأمان إرشادات السياسة ، وقد تمتلك فرق النظام الأساسي عمليات الكتلة ، وقد تمتلك الفرق الهندسية بيانات ومهام سير عمل التسليم. ولكن إذا لم يتم محاذاة هذه المجموعات ، فعادةً ما تكون النتيجة مجموعة وظيفية من الناحية الفنية ولكنها غير متساوية من الناحية التشغيلية من منظور أمني.
ما الذي يجب أن توليه الفرق عن كثب؟
عادةً ما تكون مناطق التركيز الأعلى قيمة هي التحكم في الوصول وسياسة النشر وتكوين عبء العمل وإمكانية الرؤية. بمعنى آخر ، يجب أن تركز الفرق أولاً على من يمكنه فعل ماذا ، وما المسموح به للتشغيل ، ومدى أمان تحديد أعباء العمل ، وما إذا كان يوجد دليل كافٍ لاكتشاف السلوك المشبوه والتحقيق فيه.
هذا مهم لأنه نادرًا ما يتم تحسين أمان Kubernetes من خلال لوحة معلومات أخرى فقط. يتحسن عندما تقوم المنظمة بتشديد القرارات التي تتحكم في النشر والوصول وسلوك وقت التشغيل.
من أين تحصل المنظمات على خطأ أمان Kubernetes؟
أحد الأخطاء هو التركيز بشكل ضيق للغاية على الحاوية وليس التركيز الكافي على الكتلة. صور الحاوية مهمة ، لكن أمان Kubernetes يعتمد أيضًا على التحكم في الدخول و RBAC وتصميم حساب الخدمة وسياسة الشبكة وتكوين عبء العمل.
هناك خطأ آخر وهو افتراض أن الإعدادات الافتراضية قوية بما يكفي للإنتاج. توفر Kubernetes ضوابط أمان قوية ، لكن الكثير منها يتطلب تصميمًا وصيانة مدروسة.
والثالث هو فصل الأمن بعيدًا جدًا عن التسليم. إذا لم يتم إجراء فحوصات الأمان إلا في النهاية ، فسيتم اكتشاف التكوينات الخاطئة والصور الخطرة بعد فوات الأوان ، عندما تكون المعالجة أكثر إزعاجًا وأقل عرضة للترحيب من قبل الفرق الهندسية.
الوجبات الجاهزة الرئيسية
تتعلق مخاطر أمان Kubernetes في الغالب بفشل التحكم على نطاق واسع: وصول كبير جدًا ، وسياسة قليلة جدًا ، وإعدادات عبء عمل ضعيفة ، وتجزئة ضعيفة ، ومحدودية الرؤية. ليست المجموعات الأكثر أمانًا هي تلك التي تحتوي على أكثر الأدوات - بل هي تلك التي تحتوي على حواجز حماية واضحة تبدأ قبل النشر وتستمر خلال وقت التشغيل.
تعزيز أمان Kubernetes باستخدام Kaspersky
غالبًا ما تبدأ مخاطر Kubernetes بالتكوين الخاطئ ، والوصول المفرط ، وتنفيذ السياسة الضعيف والرؤية المحدودة عبر المجموعات. يساعد Kaspersky Container Security على حماية بيئات المنظم من خلال فحوصات التكوين والمصادقة ومراقبة التخويل والتحكم في العملية والشبكة ورؤية موارد المجموعة.
المصادر وقراءات إضافية:
