ملاحظة perev. : كتب المقال الأصلي مهندس من السويد - كريستيان عبد المسيح ، وهو مولع بالهندسة المعمارية على مستوى المؤسسات ، وأمن تكنولوجيا المعلومات ، والحوسبة السحابية. في الآونة الأخيرة ، حصل على درجة الماجستير في علوم الكمبيوتر وهو في عجلة من أمره لمشاركة عمله - أطروحة الماجستير ، أو بالأحرى ، جزء منه ، مكرس لمشاكل عزل تطبيق حاويات [وأطلق في Kubernetes]. بصفته "العميل" الذي تم إعداد هذا العمل البحثي له ، فإنه يتصرف على الأقل في شرطة وطنه.
أصبحت تزامن الحاويات والحوسبة السحابية شائعة للغاية في السنوات الأخيرة. لقد بلغ تكيفهم هذا المستوى لدرجة أن المؤسسات المالية والبنوك والقطاع العام أبدت اهتمامًا بها. مقارنة بالشركات الأخرى ، فهي تتميز بمتطلبات واسعة في مجال أمن المعلومات وتكنولوجيا المعلومات.
أحد الجوانب المهمة هو كيف يمكن استخدام الحاويات في بيئات الإنتاج وفي الوقت نفسه ، يمكن الحفاظ على فصل النظام بين التطبيقات. نظرًا لأن مثل هذه المؤسسات تستخدم بيئات السحابة الخاصة القائمة على المحاكاة الافتراضية أعلى المعدن العاري ، فإن فقدان مثل هذه العزلة عند الترحيل إلى بيئة مع الحاويات المدبرة أمر غير مقبول. نظرًا لهذه القيود ، تمت كتابة رسالتي ، وتعتبر الشرطة السويدية عميلًا مستهدفًا.
القضية المحددة للدراسة التي تم بحثها في الأطروحة هي:
كيف يتم دعم ترسيم التطبيق في Docker و Kubernetes مقارنة بالأجهزة الافتراضية التي تعمل على برنامج Hypervisor ESXi المعدني العاري؟
هذه القضية تتطلب دراسة متأنية. لتبدأ بشيء ما ، انظر إلى القاسم المشترك - التطبيقات.
تطبيقات الويب مربكة
نقاط الضعف في تطبيقات الويب - حديقة حيوانات حقيقية لمتجهات الهجوم. يتم عرض أهم المخاطر في OWASP Top 10 (
2013 ،
2017 ). تساعد هذه الموارد في تثقيف المطورين في تقليل المخاطر النموذجية. ومع ذلك ، حتى إذا قام المطورون بكتابة تعليمات برمجية خالية من العيوب ، فإن التطبيق لا يزال عرضة للتأثر - على سبيل المثال ، من خلال تبعيات الحزمة.
كتب David Gilbertson
قصة رائعة عن كيفية حقن الشفرة من خلال حزمة ضارة موزعة ، على سبيل المثال ، كجزء من NPM للتطبيقات المستندة إلى Node.js. للكشف عن الثغرات الأمنية ، يمكنك استخدام ماسحات التبعية ، ولكنها
تقلل من المخاطر فقط ، ولكنها لا تقضي عليها تمامًا.
حتى إذا قمت بإنشاء تطبيقات بدون تبعية تابعة لجهات خارجية ، فلا يزال من غير الواقعي الاعتقاد بأن التطبيق لن يصبح عرضة للخطر أبدًا.
بسبب هذه المخاطر ، لا يمكننا القول أن تطبيقات الويب آمنة.بدلاً من ذلك ، التمسك باستراتيجية
الدفاع (DID)
العميقة . دعونا نلقي نظرة على المستوى التالي: الحاويات والأجهزة الافتراضية.
حاويات مقابل الأجهزة الافتراضية - قصة العزلة
الحاوية هي بيئة معزولة للمستخدم - الفضاء والتي يتم تنفيذها في كثير من الأحيان باستخدام قدرات النواة. على سبيل المثال ، يستخدم
Docker مساحات أسماء Linux ومجموعات cg والقدرات الخاصة بذلك. وبهذا المعنى ،
يختلف عزل حاويات Docker
اختلافًا كبيرًا عن الأجهزة الافتراضية التي يتم تشغيلها بواسطة برامج Hypervisor من النوع 1
(أي ، تعمل مباشرة على الأجهزة ؛ أجهزة مراقبة الأجهزة الفائقة العارية) .
يمكن تنفيذ التمييز بين هذه الأجهزة الافتراضية عند مستوى منخفض كما هو الحال في الأجهزة الحقيقية ، على سبيل المثال ، من خلال
Intel VT . حاويات الإرساء ، بدورها ، تعتمد على نواة لينكس للترسيم. من المهم جدًا مراعاة هذا الاختلاف عندما يتعلق الأمر
بهجمات الطبقات السفلية .
إذا كان المهاجم قادرًا على تنفيذ تعليمات برمجية في جهاز أو حاوية افتراضية ، فمن المحتمل أن يصل إلى مستوى أدنى من خلال تنفيذ
هجوم هروب .
اعتمادًا على استخدام الحاويات أو الأجهزة الافتراضية على الأجهزة ، يتم تطبيق التمايز على مستويات مختلفة من البنية التحتية.تم إثبات إمكانية حدوث مثل هذه الهجمات لبرنامج
VMware ESXi hypervisor خلال مسابقة Pwn2Own 2017 للقراصنة ، وكذلك GeekPwn2018. وكانت النتيجة هي زوج من
CVEs (
CVE-2017–4902 ،
CVE-2018–1981 ) والتي يمكن استخدامها في هجمات الطبقة السفلية
للخروج من الأجهزة الظاهرية ( الهروب الظاهري من الماكينة ) . لا تضمن الأجهزة الافتراضية على خوادم الحديد الأمان المطلق ، على الرغم من أنها تستخدم التكنولوجيا للتمييز بين مستوى الحديد.
من ناحية أخرى ، إذا نظرنا إلى متجهات الهجوم على برنامج Hypervisor المعدني مقابل Linux kernel ، فمن الواضح أن هذا الأخير له سطح هجوم أكبر بكثير - بسبب حجمه [kernel Linux] ومجموعة من إمكانياته. يتضمن السطح الأكبر للهجوم المزيد من متجهات الهجوم المحتملة للبيئات السحابية باستخدام عزل الحاوية. يتجلى ذلك في الاهتمام المتزايد
بهجمات هروب الحاويات ، والتي أصبحت ممكنة بفضل عمليات استغلال kernel (على سبيل المثال ،
CVE-2016–5195 [أي DOW COW - تقريبا. ترجمة.] ،
CVE-2017–1000405 )
يمكن استخدام وحدات مثل
SELinux أو
AppArmor لزيادة العزل
داخل الحاوية. لسوء الحظ ، فإن مثل هذه الآليات الأمنية في النواة لا تمنع هجمات الهروب على النواة نفسها. سيقومون فقط بتحديد الإجراءات المحتملة للمهاجم إذا كان تجاوز الحدود غير
ممكن . إذا كنا نريد التعامل مع المخارج خارج الحاوية ، فإن هناك حاجة إلى آلية عزل
خارج الحاوية أو حتى القلب. على سبيل المثال ، رمل
(رمل) !
gVisor عبارة عن صندوق رمل لوقت
تشغيل الحاوية ، تم فتح الكود الخاص به بواسطة Google ويضيف نواة إضافية بين الحاوية ونواة نظام التشغيل. يمكن لهذا النوع من صندوق الحماية تحسين الموقف من خلال هجمات الحاويات خارج الحدود التي تحدث
على مستوى kernel . ومع ذلك ، فإن مآثر أساسية هي مجرد واحدة من أدوات المهاجم.
لمعرفة كيف يمكن للهجمات الأخرى أن تؤدي إلى نتائج مماثلة ، تحتاج إلى إلقاء نظرة على صورة أكثر عمومية عن كيفية استخدام الحاويات في عصر السحابة الأصلي.
تأثير تزامن الحاوية على العزلة
لإدارة الحاويات التي تعمل في بيئات مع العديد من العقد ، فإنها تقدم تزامن ، والتي Kubernetes إعطاء الدور الريادي. كما اتضح ، يمكن أن تؤثر حشرات الأوركسترا على عزل الحاوية.
قدم تيم Allclair عرضًا رائعًا في KubeCon 2018 ، حيث لاحظ بعض أسطح الهجوم.
ويذكر في تقريره مثالاً (
CVE-2017-1002101 ) ، كيف يمكن أن تؤثر أخطاء التنسيق في العزلة - في هذه الحالة ، من خلال القدرة على تحميل مساحة على القرص خارج الحافظة. نقاط الضعف من هذا النوع إشكالية للغاية ، لأنه يمكن تجاوز صندوق الرمل الذي يتم فيه تغليف الحاوية.
من خلال تقديم Kubernetes ، قمنا بتوسيع سطح الهجوم. ويشمل النظم التي يتم استضافتها على سيد Kubernetes. أحدهم هو خادم Kubernetes API ، حيث اكتشفوا مؤخرًا ثغرة أمنية قد تسمح بامتيازات
مفرطة (
CVE-2018–1002105 ). نظرًا لأن سطح هجوم Kubernetes master خارج نطاق رسالتي ، فلا يتم مراعاة مشكلة عدم الحصانة هذه.
لماذا تعتبر هجمات الهروب مهمة جدًا؟ قدمت الحاويات القدرة على تشغيل العديد من التطبيقات التي تستضيفها نفس نظام التشغيل. لذلك كان هناك خطر يرتبط بعزل التطبيق. إذا كان هناك تطبيق حرج للأعمال وتطبيق آخر عرضة للتأثر يعمل على نفس المضيف ، يمكن للمهاجم الوصول إلى تطبيق حرج من خلال هجوم على تطبيق ضعيف.
اعتمادًا على نوع البيانات التي تعمل معها المنظمة ، يمكن أن يتسبب تسربها في إلحاق الضرر ليس فقط بالمنظمة نفسها ، ولكن أيضًا بالأفراد والبلد بأكمله. كما تتذكر ، نحن نتحدث عن القطاع العام والمالية والبنوك ... - يمكن أن يؤثر التسرب بشكل خطير على حياة الناس.
إذن هل يمكن استخدام تزامن الحاويات في مثل هذه البيئات؟ قبل الشروع في مزيد من التفكير ، يجب إجراء تقييم للمخاطر.
ما الخطر مقبول؟
قبل تقديم تدابير الأمان ، من المهم التفكير في نوع المعلومات التي تحاول المنظمة حمايتها بالفعل. يعتمد القرار بشأن ما إذا كانت هناك حاجة إلى مزيد من الخطوات لمنع هجمات الهروب المحتملة على الحاويات على البيانات التي تعمل معها المؤسسة والخدمات التي تقدمها.
على المدى الطويل ، يعني هذا أنه من أجل تحقيق إمكانية الخروج من الحاوية على مضيف تم
تكوينه بشكل صحيح ومحمي بواسطة صندوق الحماية للحاوية ، يجب على المهاجم:
- تنفيذ التعليمات البرمجية في الحاوية ، على سبيل المثال ، من خلال حقن الكود أو استخدام الثغرات الأمنية في كود التطبيق ؛
- استفد من ثغرة أخرى ، اليوم صفر ، أو التي لم يتم تطبيق التصحيح عليها حتى الآن للخروج من الحاوية على الرغم من وجود صندوق رمل .
كما قد تتخيل ، يجب على المنظمة التي لا تعتبر هذا السيناريو مقبولاً أن تعمل مع البيانات أو تقدم خدمات تتطلب الكثير من
السرية والنزاهة و / أو
إمكانية الوصول .
نظرًا لأن الرسالة مكرسة لمثل هؤلاء العملاء فقط ، فإن فقدان عزل النظام عن طريق الخروج من الحاوية أمر غير مسموح به ، لأن عواقبه كبيرة جدا. ما هي الخطوات التي يمكن اتخاذها لتحسين العزلة؟ لرفع المستوى في سلم العزل ، يجب عليك أيضًا النظر في صناديق الرمل التي يتم لف نواة نظام التشغيل عليها ، أي آلات افتراضية!
ستعمل تقنيات المحاكاة الافتراضية التي تستخدم برامج Hypervisor المستضافة على تحسين الموقف ، لكننا نرغب في الحد من سطح الهجوم
بدرجة أكبر . لذلك ، دعونا نفحص برامج Hypervisor المثبتة على الحديد ونرى ما الذي سيؤدي بنا إليه.
المشرفين على الحديد
بحثت
دراسة أجرتها وكالة أبحاث الدفاع السويدية السويدية مخاطر الافتراضية فيما يتعلق بالقوات المسلحة السويدية. تحدث خاتمته عن فوائد هذه التقنيات للجيش ، حتى مع المتطلبات الأمنية الصارمة والمخاطر التي تجلبها الافتراضية.
في هذا الصدد ، يمكننا القول أن المحاكاة الافتراضية تستخدم (إلى حد ما) في صناعة الدفاع ، لأنها تنطوي على
مخاطر مقبولة . نظرًا لأن الوكالات والمؤسسات العاملة في صناعة الدفاع هي واحدة من أكثر العملاء تطلبًا لأمن تكنولوجيا المعلومات ، يمكننا أيضًا القول بأن الخطر المقبول بالنسبة لهم يعني قبوله للعملاء الذين تم بحثهم في الرسالة. وكل هذا - على الرغم من المخارج المحتملة وراء الجهاز الظاهري ، التي نوقشت أعلاه.
إذا قررنا استخدام هذا النوع من الصندوق الرملي للحاويات ، فهناك بعض الأشياء التي يجب مراعاتها في سياق التفاصيل الخاصة بالسحابة الأصلية.
عقد الصندوق الرمل للأجهزة الافتراضية
الفكرة هي أن عقد نظام Kubernetes هي أجهزة افتراضية تستخدم محاكاة الأجهزة الافتراضية. نظرًا لأن الأجهزة الافتراضية ستلعب دور الصناديق الرملية للحاويات التي تعمل في القرون ، يمكن اعتبار كل عقدة بيئة محمية بالرمل.
ملاحظة مهمة حول صناديق الرمل هذه في سياق صناديق رمل الحاوية التي سبق ذكرها: تتيح لك هذه الطريقة وضع العديد من الحاويات في صندوق رمل واحد. تتيح لك هذه المرونة تقليل الحمل عند مقارنتها بالحالة عندما يكون لكل حاوية صندوق رمل خاص بها. نظرًا لأن كل صندوق رمل يجلب نظام التشغيل الخاص به ، فإننا نريد تقليل عددهم مع الحفاظ على العزلة.
الأجهزة الظاهرية المثبتة على الأجهزة - العقد العنقودية - بمثابة صناديق الرمل للحاويات. يتم تحديد حاويات التشغيل في أجهزة VM مختلفة بمستوى مقبول من المخاطرة. ومع ذلك ، لا ينطبق هذا على الحاويات التي تعمل على نفس VM.ومع ذلك ، نظرًا لأن Kubernetes قادر على تغيير موضع القرون لأسباب مختلفة ، والتي يمكن أن
تدمر فكرة صناديق الرمل المستخدمة ، فسيكون من الضروري إضافة قيود على آلية مشاركة القرون. يمكنك تحقيق المطلوب في نواح كثيرة.
في وقت كتابة هذا التقرير ، كان Kubernetes (الإصدار 1.11) يدعم ثلاث طرق رئيسية للتحكم في تخطيط و / أو إطلاق السنفات:
تعتمد الطريقة (الطرق) التي يجب استخدامها على تطبيق المؤسسة. ومع ذلك ، من المهم ملاحظة أن الطرق تختلف في قدرتها على تجاهل السنفات بعد دخولها مرحلة التنفيذ. الآن فقط taints قادرة على ذلك - من خلال الإجراء
NoExecute . إذا لم تقم بمعالجة هذه اللحظة بأي شكل من الأشكال وتغيرت بعض الملصقات ، فقد يؤدي كل شيء إلى موقع مشترك غير مرغوب فيه.
الامتثال لمتطلبات الموقع المشترك
تقترح الأطروحة فكرة استخدام نظام تصنيف يوضح كيف تنعكس الحساسية في الموقع المشترك. تتمثل الفكرة في استخدام العلاقة 1: 1 بين الحاوية والقرنة وتحديد الموقع المشترك للقرون بناءً على تصنيف التطبيقات الحاوية.
من أجل البساطة وإعادة الاستخدام ، يتم استخدام نظام التصنيف ثلاثي الخطوات التالي:
- الفئة O : التطبيق غير حساس ولا يحتوي على متطلبات العزل. يمكن وضعها على أي عقد لا تنتمي إلى فصول أخرى.
- فئة PG (مجموعة خاصة) : يشكل التطبيق ، مع مجموعة من التطبيقات الأخرى ، مجموعة خاصة تتطلب عقدة مخصصة لها. لا يمكن استضافة التطبيق إلا على عقد فئة PG التي لها معرف مجموعة خاصة مناظرة.
- الفئة P (خاصة) : يتطلب التطبيق عقدة خاصة ومنفصلة ولا يمكن وضعه إلا على عقد فارغة من فئته (P).
للوفاء بمتطلبات الموقع المشترك للعديد من التطبيقات المصنفة ، يتم استخدام مواد التشويش والتحمل ، حيث يتم تعيين فئة لكل عقدة ، و PodAffinity لتطبيق قيود إضافية على القرون مع تطبيقات الفئة P أو PG.
يوضح هذا المثال المبسط كيف يمكن استخدام مواد التحمل والتسامح لتطبيق التحكم في الموقع المشترك:
تحتوي السنتان 2 و 3 على تطبيقات من مجموعة خاصة واحدة ، والتطبيق على السلك 1 أكثر حساسية ويتطلب عقدة مخصصة.ومع ذلك ، ستتطلب فئتي P و PG قواعد تقارب إضافية لضمان تنفيذ طلبات الترسيم مع نمو الكتلة والتطبيقات المستضافة. دعونا نرى كيف يمكنك تطبيق
هذه القواعد لفئات مختلفة:
# Class P affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" namespaces: ["default"] labelSelector: matchExpressions: - key: non-existing-key operator: DoesNotExist
تتطلب قواعد التقارب لتطبيقات الفئة P عقدًا مخصصة. في هذه الحالة ، لن يتم تحديد الجدول في حالة خروج البود بدون
non-existing-key . كل شيء سوف يعمل حتى جراب واحد لديه هذا المفتاح.
# Class PG affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchLabels: class-pg-group-1: foobar podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: class-pg-group-1 operator: DoesNotExist
بالنسبة للتطبيقات من فئة PG ، ستشارك قواعد التقارب في المضيفات التي لها معرف مجموعة من
class-pg-group-1 وعلى العقد التي لها حاضن بدون معرف.
سيسمح لنا هذا النهج باستخدام نظام تصنيف لتحديد الحاويات استنادًا إلى المتطلبات ذات الصلة للتطبيق الذي تم حاوياته.
ماذا حصلنا عليه؟
الخاتمة
لقد نظرنا في طريقة لتنفيذ صناديق الرمل استنادًا إلى برنامج Hypervisor من النوع الأول (أي ، الذي تم إطلاقه على المعدن العاري) لإنشاء عقد في مجموعات Kubernetes وقدمنا نظام تصنيف يحدد متطلبات تحديد التطبيقات في حاويات. إذا قارنا هذا النهج مع الحلول الأخرى التي تم أخذها في الاعتبار ، فسيكون لها مزايا من حيث ضمان عزل النظام.
الاستنتاج المهم هو أن استراتيجية العزل
تقيد انتشار هجمات الهروب إلى الحاوية.
بمعنى آخر ، لا يتم منع ترك الحاوية بمفردها ، ولكن يتم تخفيف آثارها. من الواضح ، إلى جانب ذلك ، تأتي صعوبات إضافية يجب مراعاتها عند إجراء مقارنات مماثلة.
لاستخدام الطريقة المحددة في بيئة سحابية وتوفير قابلية التوسع ، سيتم فرض متطلبات إضافية على التشغيل الآلي. على سبيل المثال ، لأتمتة إنشاء أجهزة افتراضية واستخدامها في نظام Kubernetes. الشيء الأكثر أهمية هو تنفيذ والتحقق من التصنيف
الواسع للتطبيقات.
هذا جزء من رسالتي حول
عزل التطبيق ذي الحاوية .
لمنع احتمال قيام أحد المهاجمين بالخروج من الحاوية على عقدة لمهاجمة خدمات العقد الأخرى ، من الضروري مراعاة
الهجمات التي يتم نشرها عبر الشبكة . لأخذ هذه المخاطر في الاعتبار ، تقترح
أطروحتي تجزئة شبكة نظام المجموعة ويقدم تصميمات سحابية ، إحداها
مزودة بجدار حماية للأجهزة .
يمكن لأولئك الذين يرغبون في الاطلاع على الوثيقة كاملة - نص الرسالة في متناول الجمهور: "
تزامن الحاويات في البيئات التي تتطلب الأمن في هيئة الشرطة السويدية ".
PS من المترجم
اقرأ أيضًا في مدونتنا: