التغلب على تحديات سجل Kubernetes في الكشف

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

في منشور المدونة هذا، سنلقي نظرة فاحصة على موضوع فرعي ذي صلة مرتبط بالكشف في مجموعات Kubernetes (K8s) المُدارة وغير المُدارة: سجلات تدقيق Kubernetes. تعتمد هذه المناقشة على المحتوى الذي قدمته على fwd:cloudsec Europe (رابط التسجيل متاح هنا لمن يهمه الأمر). الحديث نفسه مستوحى من تنفيذنا لـ الكشف والاستجابة لـ Kubernetes (KDR)، حيث تعلمنا دروسًا أساسية حول اكتشاف الهجمات ومنعها في بيئات Kubernetes. أبرز تنفيذ KDR الخاص بنا الحاجة إلى سجلات تدقيق Kubernetes لاكتشاف الهجمات مثل تلك الموجودة في حملة DERO للتعدين الخفي، والتي استهدفت مجموعات Kubernetes التي تم تكوينها بشكل خاطئ.

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

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

{ 
    "kind": "Event", 
    "apiVersion": "audit.k8s.io/v1", 
    "level": "RequestResponse", 
    "auditID": "a6029022-4ff0-4c54-97ed-4099d0ca1923", 
    "stage": "RequestReceived", 
    "requestURI": "/api/v1/namespaces/default/serviceaccounts?fieldManager=kubectl-create", 
    "verb": "create", 
    "user": { 
        "username": "kubernetes-admin", 
        "groups": ["system:masters", "system:authenticated"] 
    }, 
    "sourceIPs": ["172.31.22.88"], 
    "userAgent": "kubectl/v1.23.6 (linux/amd64) kubernetes/ad33385", 
    "objectRef": { 
        "resource": "serviceaccounts", 
        "namespace": "default", 
        "apiVersion": "v1" 
    }, 
    "requestReceivedTimestamp": "2022-07-31T08:36:48.679291Z", 
    "stageTimestamp": "2022-07-31T08:36:48.679291Z" 
} 

يجيب الحدث الفردي على جميع أسئلة الطب الشرعي الضرورية:

• من نفذ الإجراء (Kubernetes-admin) ومن أي IP

• ماذا الإجراء (إنشاء)

• على ماذا المورد (حساب الخدمة في مساحة الاسم الافتراضية)

• وأخيرا، متى حدث هذا (الطوابع الزمنية).

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

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

1. سياسات التسجيل الافتراضية غير المتناسقة

تتمثل إحدى نقاط الألم الرئيسية عند التعامل مع مقدمي خدمات الاتصالات في عدم الاتساق في كيفية تكوين تسجيل تدقيق Kubernetes افتراضيًا. على سبيل المثال، في Amazon EKS (خدمة Elastic Kubernetes) وAzure AKS (خدمة Azure Kubernetes)، يتم تعطيل تسجيل التدقيق بشكل افتراضي. يجب على المسؤولين تمكينه يدويًا، عادةً من خلال واجهة برمجة تطبيقات الموفر. يمكن أن تؤدي خطوة التكوين الإضافية هذه إلى تشغيل المجموعات دون تمكين تسجيل التدقيق، مما يترك فرق الأمان غير مرئية للأنشطة الضارة المحتملة.

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

2. تنسيقات السجل الخاصة بالموردين

وينشأ تحدٍ آخر من تنسيقات السجل المختلفة التي يستخدمها مقدمو خدمات الاتصالات. على الرغم من أن Kubernetes لديه تنسيق قياسي لسجلات التدقيق، فإن العديد من موردي الخدمات السحابية يقومون بتعديل هذا التنسيق أو توسيعه لخدماتهم المُدارة. يعد محرك Google Kubernetes (GKE) وOKE من الأمثلة الرئيسية: حيث يقومان بتخصيص سجلات التدقيق بشكل كبير، وتجريد بعض حقول Kubernetes الأصلية وتقديم تنسيق التسجيل الخاص به. ونتيجة لذلك، فإن مجموعة القواعد المصممة لاكتشاف السلوك المشبوه في مجموعة Vanilla Kubernetes لن تعمل بشكل صحيح على GKE، مما يؤدي إلى فقدان الاكتشافات. على سبيل المثال، هذه هي الطريقة التي يبدو بها الحدثان جنبًا إلى جنب – تنسيق GKE مقابل تنسيق الفانيليا الأصلي لـ K8s:

ونتيجة لذلك، فإن مجموعة القواعد المصممة لاكتشاف السلوك المشبوه في مجموعة Vanilla Kubernetes لن تعمل بشكل صحيح على GKE، مما يؤدي إلى فقدان الاكتشافات. النظر في قاعدة الكشف “عبء عمل Kubernetes الذي أنشأه مستخدم مجهول”. فيما يلي مقارنة بين القاعدة المعبر عنها بلغة Rego لـ GKE (أعلاه) وEKS / Openshift / Vanilla K8s (أدناه):

match { 
startswith(input.protoPayload.serviceName, "k8s.io") 
endswith(input.protoPayload.methodName, "create") 
{"system:anonymous","system:unauthenticated"}[input.protoPayload.authenticationInfo.principalEmail] 
input.protoPayload.authorizationInfo[_].granted == true 
}

عكس

match { 
input.verb == "Create" 
{"system:anonymous", "system:unauthenticated"} 
[input.user.username] 
input.annotations["authorization.k8s.io/decision"] == "allow"  
} 

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

3. سياسة السجل

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

4. اعتبارات الأداء والكمون

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

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

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

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

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

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

يجب أن تفكر فرق الأمان في زيادة سجلات التدقيق بمصادر إضافية، مثل:

• وحدات تحكم القبول الديناميكية التي تراقب تغييرات الحالة في المجموعة، مما يوفر نظرة ثاقبة في الوقت الفعلي للتغييرات التي قد لا يتم التقاطها بواسطة سجلات التدقيق.

• السجلات الخاصة بالسحابة (على سبيل المثال، AWS CloudTrail، وسجلات نشاط Azure) لالتقاط الأحداث على مستوى البنية التحتية.

• سجلات تدفق VPC وسياسات الشبكة للرؤية على مستوى الشبكة، والتي يمكن أن تساعد في ربط إجراءات Kubernetes بسلوك الشبكة الخارجية.

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

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