مخاطر الحركة الجانبية في السحابة وكيفية منعها – الجزء 3: من الموارد السحابية المعرضة للخطر إلى الاستيلاء على مجموعة Kubernetes

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

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

TTPs لمهاجم السحابة إلى Kubernetes

يمكن للخصوم في السحابة الاستفادة العديد من التقنيات والوظائف لتنفيذ هجمات الحركة الجانبية من البيئات السحابية إلى مجموعات Kubernetes المُدارة. يتضمن ذلك – على سبيل المثال لا الحصر – استغلال مفاتيح IAM السحابية وملفات kubeconfig وصور تسجيل الحاويات.

1. مفاتيح سحابة IAM

تظهر بيانات Wiz ذلك تقريبًا 15% من البيئات السحابية التي تستخدم مجموعات Kubernetes المُدارة لديها عبء عمل سحابي واحد على الأقل (مثل VM، وظيفة بدون خادم، حاوية، تطبيق ويب) مع مفتاح سحابي طويل المدى بنص واضح مخزّن فيه مرتبط بمستخدم IAM/AAD مع أذونات K8s ذات الامتيازات العالية.

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

ومع ذلك، فإن نطاق وصولهم سيتوقف بالطبع على أذونات الهوية، والتي تختلف طبيعتها بين مقدمي خدمات الاتصالات:

قد يتمكن المهاجم الذي قام باختراق مفاتيح سحابة AWS (على سبيل المثال، مفاتيح وصول المستخدم) من إنشاء ملف kubeconfig والمصادقة على مجموعة EKS، اعتمادًا على الهوية المرتبطة بالمفاتيح:

– يتم منح الهوية التي أنشأت المجموعة تلقائيًا system:masters الأذونات في تكوين التحكم في الوصول المستند إلى الأدوار (RBAC) الخاص بالمجموعة في مستوى التحكم EKS. بمعنى آخر، تتمتع هذه الهوية بامتيازات المجموعة الإدارية الكاملة التي قد تؤدي إلى الاستيلاء الكامل على مجموعة EKS في حالة اختراقها.

– تتم إضافة هوية IAM بخلاف منشئ المجموعة يدويًا إلى ConfigMap aws-auth الخاص بالمجموعة ويتم منحها حق الوصول إلى الموارد بناءً على أذونات RBAC معينة.

قد يتمكن المهاجم الذي قام باختراق مفاتيح السحابة الخاصة بمستخدم GCP (أي الوصول إلى OAuth ورموز التحديث المميزة التي تم إنشاؤها أثناء المصادقة الأولية) من إنشاء ملف kubeconfig والمصادقة على مجموعة GKE في المستأجر، اعتمادًا على أذونات المستخدم.

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

بمجرد الدخول إلى مجموعة GKE، يقوم Google Cloud Platform بدمج كل من نموذج RBAC الأصلي لـ Kubernetes وIAM لإدارة ترخيص المجموعة.

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

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

– الحسابات المحلية مع Kubernetes RBAC:

نظرًا لعدم دمج مجموعة AKS مع AAD، يتلقى المستخدمون والمسؤولون شهادة عميل محلية للمجموعة. يتم إنشاء شهادة العميل باسم شائع (CN) يساوي masterclient وينتمي إلى system:masters مجموعة مرتبطة بدور مسؤول المجموعة على مستوى المجموعة. ونتيجة لذلك، حتى لو كانت هوية AAD المخترقة تحتوي فقط على الحد الأدنى من الأذونات المطلوبة لإدراج الملفات بيانات اعتماد المستخدم الكتلة، سيظل المهاجم قادرًا على إنشاء ملف kubeconfig الخاص بالمجموعة والمصادقة من خلال الوصول الكامل لمسؤول مجموعة AKS.

– مصادقة AAD مع Kubernetes RBAC ومصادقة AAD مع Azure RBAC:

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

تظهر بياناتنا ذلك تقريبًا 87% من البيئات السحابية التي تستخدم مجموعات AKS تستخدم الحسابات المحلية مع Kubernetes RBAC، وهي طريقة المصادقة والتفويض الأقل أمانًا.

2. ملفات كوبيكونفيغ

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

كما ذكرنا سابقًا، يقدم Azure مصادقة المجموعة عبر الحسابات المحلية أو AAD. إذا تم تكوين مجموعة لطلب المصادقة من خلال الحسابات المحلية، فإن kubeconfig يستخدم شهادات النص العادي (client-certificate-data و client-key-data)، مما يسمح لممثل خبيث بالمصادقة من خلال الوصول الكامل لمسؤول المجموعة بشكل افتراضي.

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

على عكس AKS، تتطلب ملفات kubeconfig للمجموعات المُدارة EKS وGKE استخدام المفاتيح السحابية المرتبطة بهويات IAM من أجل المصادقة على المجموعة، لذا فإن المهاجم الذي يأمل في اختراق مجموعة مُدارة سيتطلب أيضًا الوصول إلى مفاتيح IAM السحابية ذات الصلة.

3. صور تسجيل الحاوية

تستخدم العديد من الحاويات التي تعمل في مجموعات Kubernetes المُدارة صورًا تم سحبها من خدمة تسجيل الحاويات السحابية مثل ECR, جي سي آر/جار (خليفة GCR) و أكر.

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

أفضل الممارسات الموصى بها

هنا 3 أفضل ممارسات السحابة إلى K8s الرئيسية التي يجب على أي مؤسسة تنفيذها في بيئتها للتخفيف من مخاطر هجوم الحركة الجانبية:

1. تجنب تخزين المفاتيح السحابية طويلة المدى في أعباء العمل

   بدلاً من استخدام مفاتيح السحابة طويلة المدى داخل أحمال العمل السحابية لديك، فكر في ربط أدوار IAM/حسابات الخدمة/الهويات المُدارة بأحمال العمل هذه وتحديد الحد الأدنى من الأذونات المطلوبة لها. سيضمن هذا استخدام بيانات الاعتماد المؤقتة فقط (التي يتم إنشاؤها وتدويرها تلقائيًا بواسطة IMDS)، مما يقلل من خطر الاستمرارية.

2. قم بإزالة ملفات kubeconfig من أعباء العمل المكشوفة للعامة

   لتطبيق إجراءات أمنية صارمة، تأكد من إزالة أي ملفات kubeconfig من أحمال العمل السحابية المكشوفة بشكل عام مثل الأجهزة الافتراضية والوظائف بدون خادم والحاويات. يعد هذا مهمًا جدًا في AKS (حيث إن اختراق ملف kubeconfig عادةً ما يكون كافيًا للمصادقة على المجموعة)، ولكنه أقل أهمية في EKS/GKE. ومع ذلك، إذا تم استخدام عبء العمل السحابي للمصادقة على مجموعة K8s مُدارة من داخلها، فسوف يحتفظ بملف kubeconfig ومفاتيح السحابة ذات الصلة على القرص.

   فكر في تكوين نقطة نهاية خادم K8s API كنقطة خاصة – مما يجعلها قابلة للوصول فقط من خلال VPC/VNet – وتأكد من أن عبء العمل في VPC/VNet المستخدم للمصادقة (والذي يحتوي على ملف kubeconfig) يحتوي على مجموعة أمان تم تكوينها بشكل صارم والتي تقيد الوصول إلى عناوين IP محددة. سيؤدي هذا إلى تخفيف مخاطر عبء العمل وتسوية kubeconfig.

3. تقييد الوصول إلى سجلات الحاويات

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

   • في ECR، حدد سياسة صارمة قائمة على الموارد لكل مستودع، وتجنب استخدام أحرف البدل في الحقل “الرئيسي”. بالإضافة إلى ذلك، فكر في تمكين “ثبات العلامة” إشارة لكل مستودع لمنع الكتابة فوق الصور الموجودة بنفس العلامة.

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

   • في GCR، دلو اسمه “القطع الأثرية.[PROJECT-ID]”.appspot.com” يخزن الصور التي تم دفعها إلى المجال “gcr.io”. يتم إنشاء مجموعة تخزين التسجيل هذه فقط عندما يتم دفع صورة Docker. تأكد من عدم عرض هذه المجموعة للعامة عن طريق الامتناع عن تشغيل إعداد “الوصول العام” (أو عن طريق عدم منح الوصول إلى allUsers و allAuthenticatedUsers مديري المدارس). في حالة رغبتك في حظر الوصول العام إلى أي مجموعات تخزين في مؤسسة/مجلد/مشروع، فكر في تطبيق سياسة المؤسسة “storage.publicAccessPrevention” على المستوى ذي الصلة.

   • في GAR، يعد كل مستودع موردًا منفصلاً، وبالتالي يمكنك تطبيق سياسات IAM مختلفة على كل مستودع باستخدام أدوار Artifact Registry (بدلاً من أدوار Cloud Storage في GCR) لمنح الوصول. يوجد أيضًا فصل واضح بين أدوار مسؤول المستودع ومستخدم المستودع. تأكد من تطبيق سياسات IAM الصارمة على كل مستودع وتجنب تعريضه لأي شخص على الإنترنت عن طريق الحد من allUsers و allAuthenticatedUsers وصول المديرين.

ملخص

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

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

تمت كتابة منشور المدونة هذا بواسطة Wiz Research، كجزء من مهمتنا المستمرة لتحليل التهديدات التي تواجه السحابة، وبناء آليات تمنعها وتكتشفها، وتقوية استراتيجيات أمان السحابة.