هجوم بالذكاء الاصطناعي في 7 ساعات.. ماذا حدث داخل بنية Kubernetes

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

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

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

اختراق Kubernetes و54 خدمة مكشوفة

وقال فرح إن البنية التحتية التي تعرضت للهجوم كانت تعتمد على Kubernetes، حيث تمكن المهاجمون من الوصول إلى حساب خدمة Service Account مرتبط بأحد الحاويات.

وأضاف أن الصلاحيات التي امتلكها حساب الخدمة، إلى جانب إعدادات أخرى في البيئة، سمحت للمهاجمين بإجراء عمليات استكشاف داخل البنية التحتية، والوصول إلى 54 خدمة من خدمات Kubernetes.

وأوضح أن هذه الخطوة وفرت للمهاجمين فرصة لتنفيذ عمليات Discovery وLateral Movement داخل الكلاستر، قبل الوصول إلى حاوية تتمتع بصلاحيات مرتفعة.

ومن خلال تشغيل حاوية ذات صلاحيات عالية، تمكن المهاجمون من الوصول إلى نظام ملفات الجهاز المضيف Host File System، وهو ما منحهم صلاحيات Root على النظام المضيف الذي يشغل الحاويات.

وأشار فرح إلى أن المهاجمين تمكنوا بعد ذلك من العثور على بيانات اعتماد مرتبطة بأربع بيئات سحابية تابعة لـHugging Face، ما وسّع نطاق الوصول إلى البنية التحتية المستهدفة.

هجوم مؤتمت بالكامل دون تدخل بشري

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

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

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

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

تأمين الحاويات أصبح ضرورة

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

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

وأوضح أن أي استراتيجية فعالة لأمن الحاويات يجب أن تبدأ بتحديد الأصول والطبقات المطلوب تأمينها، ثم تحديد ما يجب مراقبته في كل مرحلة، قبل وضع الإجراءات المضادة المناسبة والاستعانة بالأدوات والتقنيات التي تستطيع تنفيذ هذه الإجراءات.

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

5 طبقات رئيسية لتأمين بيئة الحاويات

وأوضح فرح أن بيئة الحاويات تتضمن عدة طبقات رئيسية يجب تأمينها، تبدأ من العتاد Hardware، خاصة مع وجود تقنيات مثل TPM، ثم نظام تشغيل الجهاز المضيف Host Operating System الذي يوفر الموارد اللازمة لتشغيل الحاويات.

وتأتي بعد ذلك طبقة Orchestrator، مثل Kubernetes وOpenShift وRancher، أو خدمات التنسيق التي توفرها منصات سحابية مثل Azure وAWS وHuawei.

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

أما الطبقة التالية فهي Registry، وهي مساحة التخزين المخصصة لحفظ صور الحاويات Container Images، في حين تمثل الـImage المخطط الأساسي الذي يتم بناء الحاوية انطلاقًا منه، ويمكن استخدامه لتشغيل التطبيق مرات متعددة.

وتأتي الحاوية نفسها في الطبقة الأخيرة، باعتبارها البيئة التي تعمل بداخلها التطبيقات والخدمات.

فحص الصور قبل تشغيلها داخل الإنتاج

وأشار فرح إلى أن تأمين صور الحاويات والـRegistry يتطلب توفير رؤية كاملة للمكونات الموجودة داخلها، بما يشمل الثغرات الأمنية وسوء الإعدادات وأي بيانات حساسة مكشوفة.

كما يجب فحص الصور للتأكد من عدم احتوائها على برمجيات خبيثة أو مكونات ضارة قادمة من صور أساسية Base Images أو مكتبات مفتوحة المصدر تدخل ضمن مكونات الحاوية.

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

الأمن يبدأ من مرحلة التطوير

وأكد فرح أن أمن الحاويات يجب ألا يبدأ بعد الانتهاء من تطوير التطبيق، بل ينبغي دمجه منذ المراحل الأولى من عملية التطوير والبناء والنشر.

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

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

أما على مستوى الـRegistry، فأكد أهمية تطبيق نظام دقيق للتحكم في الصلاحيات Role-Based Access Control، بما يضمن أن كل مستخدم أو جهة داخل المؤسسة تحصل فقط على الصلاحيات التي تحتاجها، ويحد من فرص إساءة استخدام الوصول إلى صور الحاويات أو تعديلها.

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