لقد أحدث نظام Kubernetes (K8s) ثورة في كيفية نشر التطبيقات السحابية الأصلية وإدارتها. وفي حين أن شعبيتها واضحة، إلا أن هناك نقصًا في البيانات اللازمة لاتخاذ قرارات مستنيرة تتعلق بإدارة هذه البيئات، خاصة عندما يتعلق الأمر بالأمن.
في تقرير أمان Kubernetes لعام 2023، وهو استنادًا إلى عمليات فحص لأكثر من 200000 حساب سحابي، نحن نقدم إحصائيات حول حالة أمان Kubernetes. نحن لا نسلط الضوء على وجود التهديدات فحسب، بل نكشف أيضًا عن المخاطر غير الملحوظة من خلال إسنادها إلى مراحل مختلفة من مسار الهجوم على مجموعات Kubernetes، بدءًا من الوصول الأولي وحتى التأثير. أثناء إجراء هذا البحث، وجدنا أن مستوى النضج العام لأمن الحاويات منخفض، على الرغم من أن هذه البيئات تمثل أهدافًا جذابة للمهاجمين (وأن محاولات اختراقها آخذة في الارتفاع). سنناقش المزيد حول سبب ذلك، وتوصياتنا لحمايتهم والدفاع عنهم.
ويحدد التقرير أيضًا الروابط الأضعف في البيئات السحابية ويقدم “منطقة الدفاع” كاستراتيجية فعالة للتخفيف منها.
أصبحت بيئات Kubernetes هدفًا مركزيًا
استنادًا إلى التجارب التي أجراها فريق بحث Wiz، يستغرق الأمر 22 دقيقة فقط حتى تبدأ مجموعة Kubernetes المنشأة حديثًا في تلقي محاولات المسح الضارة الأولية.
تُظهر البيانات من اتجاهات Shodan شعبية K8s، كما هو موضح في هذا الرسم البياني الذي يوضح العدد المتزايد لخوادم K8s API العامة:
ومع ذلك، مع استمرار ارتفاع اعتماد Kubernetes، تتزايد أيضًا المخاطر الأمنية. يوضح الرسم البياني التالي نقاط نهاية kubelet المفتوحة التي لا يمكن عادةً الوصول إليها بواسطة الماسح الضوئي الخارجي:
لا تتزايد المخاطر الأمنية في Kubernetes فحسب، بل تتزايد الهجمات أيضًا. بعد كل شيء، تعد مجموعات K8s منصات تنفيذ عالية الكفاءة، وبالتالي فهي مثالية لتدوير أعباء عمل تعدين العملات المشفرة. ومن أمثلة هذه الهجمات خلال العام الماضي PyLoose وnewhello. نرى أن أدوات التعدين القائمة مثل XMRig وCCMiner وXMR-Stak-RX تُستخدم بشكل متزايد للعمل على البنى التحتية لـ Kubernetes. بالإضافة إلى استهداف أعباء عمل التعدين المشفر، أصبح المهاجمون أكثر كفاءة في التحول من مجموعات K8s إلى السحابة والعكس. على سبيل المثال، كانت الطريقة الأولية لـ RBAC Buster للوصول إلى خادم K8s API هي استخدام امتيازات الوصول المجهول، لكن البرامج الضارة تحاول بعد ذلك سرقة بيانات اعتماد AWS والانتشار في البنية التحتية السحابية. أخيرًا، نرى المزيد من الهجمات التي لا تتوقف عند تعدين العملات المشفرة ولكنها تصل إلى حد سرقة الملكية الفكرية (IP).
هناك دليل إضافي على تزايد الاهتمام الخبيث بالبنية التحتية لـKubernetes وهو السرعة التي تصبح بها المجموعة المنشأة حديثًا هدفًا. تُظهر تجربة أجراها فريق Wiz Threat Research أنه منذ لحظة إنشاء مجموعة GKE، يستغرق الأمر أقل من ثلاث ساعات لبدء تلقي عمليات الفحص الضارة من الإنترنت. بالنسبة لمجموعات AKS، يستغرق الأمر ساعتين و13 دقيقة. بالنسبة لمجموعات EKS، تكون “فترة السماح” هذه أقصر بشكل كبير – 22 دقيقة. تشير كل هذه الأرقام بوضوح إلى أن نظام Kubernetes أصبح هدفًا مركزيًا. ينبغي أن نتعامل معها على هذا النحو.
النضج الأمني للحاويات منخفض
تستخدم 9% فقط من المجموعات سياسات الشبكة لفصل حركة المرور داخل المجموعة.
في مواجهة مجموعة المخاطر الأمنية التي يتعرض لها نظام Kubernetes البيئي، استجاب مجتمع الأمان بمجموعة من عناصر التحكم والميزات المتعلقة بالأمان وقرارات التصميم المعماري لتحسين الوضع الأمني للمجموعات المُدارة والمحلية. ومع ذلك، نلاحظ أنه على الرغم من تنوع الخيارات الأمنية، فإن اعتماد السيطرة الأمنية العامة ما زال متأخرا. يوضح الجدول التالي الإحصائيات التي تصف استخدام واعتماد ميزات الأمان الرئيسية:
وجهة نظرنا: لا يوجد نقص في الخيارات الأمنية؛ هناك نقص في التبني.
النتائج التي توصلنا إليها في سياق سلسلة هجمات K8s
الدفاع في العمق هو أفضل فرصة لك لإحباط أي هجوم محتمل.
من خلال عرض الإحصائيات المرصودة على سلسلة هجمات Kubernetes النموذجية، يمكننا التفكير في النقاط الأكثر ضعفًا في النظام البيئي. الاستنتاج المباشر هو أنه بمجرد أن يخترق المهاجم البيئة، لن يكون هناك الكثير لإيقافه. ومن منظور المخاطر، لاحظنا عدة اتجاهات مهمة:
· يتمتع المهاجم بفرصة أقل للوصول الأولي من خلال مستوى التحكم: نسبة التكوينات الخاطئة أو نقاط الضعف في مستوى التحكم في Kubernetes منخفضة نسبيًا. توفر نقاط الضعف في مستوى البيانات المزيد من الفرص للمهاجمين.
· بمجرد أن يتجاوز المهاجم الوصول الأولي، تكون الفرص كافية للحركة الجانبية وتصعيد الامتيازات داخل المجموعة.
· التأثير هو خط الدفاع الأخير، ولا توجد ممارسات أمنية هناك – خاصة فيما يتعلق بتأثير السحابة بسبب تعدد الخيارات للتحول إلى السحابة. لن تنمو هذه الخيارات إلا عندما يصبح Kubernetes أكثر اندماجًا في بيئة سحابية أكبر.
· ولعل أسوأ اتجاه شهدناه هو عدم استغلال الضوابط الأمنية الحالية المطبقة عبر مراحل الهجوم. يشير هذا إلى الحاجة إلى إعطاء الأولوية لاعتماد ميزات الأمان من قبل المجتمع على تقديم ميزات الأمان الجديدة.
تعرض الرسوم المتحركة التالية نتائج التقرير في سياق إجراءات التهديد:
الوجبات السريعة الرئيسية – الدفاع عن المنطقة
باعتبارنا مشغلي مجموعة K8، لا يمكننا التحكم في ارتفاع الهجمات، ولكن يمكننا الاستعداد لها “بذكاء”. هذه هي فرضية التقرير. للإشارة إلى تشبيه كرة السلة، نقترح استخدام دفاع المنطقة. في دفاع المنطقة، بدلاً من قيام كل لاعب بحراسة لاعب مناظر في الفريق الآخر، يتم منح كل لاعب دفاعي منطقة (منطقة) للتغطية. بدلاً من إقران عناصر التحكم الأمنية بشكل تفاعلي لكل ناقل هجوم محتمل، نقترح بشكل استباقي تغطية النقاط الأكثر ضعفًا واستخدام خيارات الأمان الأوسع كدرع احتياطي. وعلى وجه التحديد، نوصي بما يلي:
· المسح المستمر للكشف عن التعرض الخارجي ومراجعات الوضع الأمني التي تواجه الخارج – لحماية الوصول الأولي.
· اكتشاف نقاط الضعف الحرجة ومعالجتها: في الكبسولات والخدمات المكشوفة للعامة – لحماية الوصول الأولي وتقليل سطح الهجوم في مستوى البيانات؛ استراتيجية التحديث العنقودي المتكرر – لتقليل سطح الهجوم في طائرة التحكم.
· الحماية أثناء التشغيل – الكشف عن تنفيذ التعليمات البرمجية الضارة للقبض على الهجمات التي مرت بالدفاع الأولي.
· الاستخدام القوي لضوابط أمان الفصل داخل المجموعة، أولاً وقبل كل شيء معايير أمان Pod، ولكن أيضًا العزل الذكي القائم على مساحة الاسم مع RBAC المنطقي، وسياسات الشبكة، ومساحات أسماء المستخدمين – لمنع الحركة الجانبية.
· المراجعة المستمرة لنظافة IAM وRBAC لأحمال عمل K8 – لتقييد تأثير التسوية المحتملة على مستوى مساحة الاسم/المجموعة ومنع التحول إلى بيئة سحابية أوسع.
