Container Security Assessment

Comprehensive container security assessment for Docker and containerized applications

حول هذه الخدمة

يقيس تقييمنا لأمن الحاويات صور الحاويات (images) وبيئة تشغيلها مقابل معايير معترف بها: CIS Docker Benchmark، ومعيار CIS الخاص بـ container runtime، ووثيقة NIST SP 800-190، وقائمة OWASP Docker Top 10. ننظر إلى شقّي المشكلة معاً: ما هو مُدمَج داخل الصورة (طبقة أساس مصابة بثغرات، أو سرٌّ تُرك فيها بالخطأ، أو عملية تعمل بمستخدم root) وما يسمح به الـ runtime (صلاحيات Linux capabilities زائدة، أو تثبيت host mount قابل للكتابة، أو مسار من داخل الحاوية إلى المضيف). يُتابَع كل اكتشاف حتى إثبات عملي، ويُصنَّف بـ CVSS إلى جانب أثره الفعلي، ويُوثَّق مع خطوة تحصين ملموسة.

ما الذي يشمله

فحص ثغرات الصورة: صورة الأساس والحزم المثبّتة مقابل ثغرات CVE المعروفة

مراجعة Dockerfile وعملية البناء: مستخدم root، والأسرار المتروكة في الطبقات، ووسوم الأساس غير المثبّتة بإصدار، والانكشاف وقت البناء

إعدادات الـ runtime: الوضع المتميّز privileged، وصلاحيات Linux capabilities المضافة، وnamespaces المضيف، ونظام ملفات جذري للقراءة فقط

ضوابط العزل: ملفات seccomp وAppArmor أو SELinux، وuser namespaces

الهروب من الحاوية والوصول إلى المضيف من حاوية مُخترَقة

التعامل مع الأسرار وبيانات الاعتماد في الصور ومتغيرات البيئة وعمليات التثبيت (mounts)

انكشاف Docker daemon وsocket، بما في ذلك docker.sock المثبّت

أمن السجلّ (registry): المصادقة، وتوقيع الصور وإثبات أصلها، وسياسات السحب (pull)

حدود الموارد والانكشاف أمام حجب الخدمة

تحصين الإعدادات مقيساً على CIS Docker Benchmark

كيف يعمل

1
تحديد النطاق والوصول
نتفق على الحدود ومعايير النجاح ونرتّب الوصول: الصور التي ستُراجَع (عبر سحب من السجلّ أو ملفات tar مُصدَّرة)، وللاختبار في الـ runtime مضيفاً يشغّل الـ container runtime أو موطئ قدمٍ ضمن افتراض الاختراق داخل حاوية. ونحدّد ما إذا كانت المنصة Docker بسيطة أم خدمة مُدارة أم أداة تنسيق، لأن ذلك يقرّر أي الطبقات يقع تحصينها على عاتقكم.
2
تحليل الصورة والبناء
نفحص كل صورة بحثاً عن حزم مصابة بثغرات، ثم نقرأ Dockerfile والطبقات المبنية بحثاً عن المشكلات التي يفوّتها الفاحص: عملية تعمل بمستخدم root، وأسرار أُدرِجت في إحدى الطبقات، وصورة أساس غير مثبّتة بإصدار أو غير موثوقة، وخطوات بناء توسّع سطح الهجوم.
3
اختبار الـ runtime والعزل
نفحص كيف تعمل الحاوية فعلاً: الوضع المتميّز privileged، والصلاحيات capabilities المضافة، وnamespaces المضيف وعمليات التثبيت (mounts)، وما إذا كانت ملفات seccomp وAppArmor أو SELinux سارية. والمقياس هو CIS Docker Benchmark وNIST SP 800-190، والسؤال هو إلى أي مدى يصمد العزل.
4
الهروب والأسرار (افتراض الاختراق)
من داخل حاوية نختبر المسارات التي يسلكها مهاجم حقيقي: الهروب إلى المضيف عبر إعداد privileged أو docker.sock مثبّت، والوصول إلى نظام ملفات المضيف أو إلى نقطة metadata السحابية، وانكشاف الأسرار في متغيرات البيئة أو عمليات التثبيت (mounts) أو السجلّ. والنتيجة هي نطاق التأثير الفعلي لحاوية واحدة مُخترَقة.
5
التحقق وإعداد التقارير وإعادة الاختبار
يُتحقَّق من كل اكتشاف بإثبات مفهوم قابل لإعادة الإنتاج، ويُصنَّف بـ CVSS وبالأثر الفعلي على الأعمال، ويُوثَّق مع مسار معالجة مُرتَّب بالأولوية. وبعد المعالجة نعيد الاختبار للتأكد من ثبات الإصلاحات.
المُخرجات
  • ملخص تنفيذي مع نظرة عامة على المخاطر لصنّاع القرار
  • تقرير فني تفصيلي، مع إثبات مفهوم قابل لإعادة الإنتاج لكل اكتشاف
  • نتائج فحص ثغرات الصورة مع الحزم المتأثّرة والإصدارات المُصحَّحة
  • اكتشافات Dockerfile والبناء مع إصلاحات ملموسة
  • مراجعة الـ runtime والعزل مُسنَدة إلى CIS Docker Benchmark
  • خطورة CVSS وأثر الأعمال لكل اكتشاف
  • خارطة طريق لتحصين الحاويات مرتَّبة بالأولوية
  • إعادة الاختبار بعد المعالجة

لماذا حافظ سيكيور

خبرة في الحاويات والـ runtime
فهمٌ عميق ومحدَّث لأمن الحاويات: طبقات الصورة، وDocker daemon، وأدوات العزل في Linux، ومسارات الهروب التي لا يُنمذِجها فاحص صور عام.
الصورة والـ runtime معاً، لا نصفاً واحداً
نختبر ما بداخل الصورة وكيفية تشغيلها معاً، لأن صورة نظيفة فوق runtime متساهل، أو runtime مُحصَّناً حول صورة مُسرِّبة، يظل في كلتا الحالتين منكشفاً.
عمق افتراض الاختراق
لا نكتفي بفحص الإعدادات: فمن داخل حاوية نقيس إلى أي مدى يتقدّم مهاجم حقيقي نحو المضيف والأسرار، كي تروا المسارات القابلة للاستغلال لا مجرد قائمة تحقق.
اكتشافات قابلة للتنفيذ ومرتَّبة بالأولوية
إرشاد واضح مرتَّب بحسب المخاطر، مع إثبات مفهوم قابل لإعادة الإنتاج وخطوات تحصين ملموسة لكل اكتشاف.

الأسئلة الشائعة

ما هو تقييم أمن الحاويات؟

يقيّم صور الحاويات وبيئة تشغيلها بحثاً عن نقاط الضعف الأمنية: طبقات الصور المصابة بالثغرات، وخطوات البناء غير الآمنة، وإعدادات الـ runtime المفرطة في الصلاحيات، والهروب من الحاوية، وانكشاف الأسرار؛ مقيساً على CIS Docker Benchmark وNIST SP 800-190 وOWASP Docker Top 10، مع إثبات كل اكتشاف وتصنيفه.

على أي معايير تجرون التقييم؟

CIS Docker Benchmark ومعيار CIS الخاص بـ container runtime لتحصين الإعدادات، وNIST SP 800-190 لنموذج تهديد حاويات التطبيقات، وOWASP Docker Top 10 لفئات المخاطر الشائعة.

ما الوصول الذي تحتاجونه للبدء؟

لمراجعة الصور نحتاج إلى سحبها من سجلّكم أو تلقّي ملفات tar مُصدَّرة. ولاختبار الـ runtime والهروب نحتاج إلى مضيف يشغّل الـ container runtime، أو موطئ قدمٍ ضمن افتراض الاختراق داخل حاوية. ونتفق على النطاق وعلى كل ما يجب تجنّبه قبل أن نبدأ.

هل تختبرون الصورة فقط، أم الـ runtime أيضاً؟

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

ما هو الهروب من الحاوية، ولماذا يهمّ؟

الهروب من الحاوية هو أن تخرج عملية من حاويتها إلى المضيف؛ وغالباً عبر راية privileged، أو صلاحية capability مضافة، أو تثبيت host mount، أو مقبس Docker socket مثبّت. ويهمّ لأنه يحوّل حاوية واحدة مُخترَقة إلى سيطرة على المضيف وعلى كل حاوية أخرى عليه، ولا يراه فحص الثغرات البسيط.

هل تراجعون Docker daemon والسجلّ (registry)؟

نعم. نفحص انكشاف الـ daemon والـ socket (فـ docker.sock المثبّت داخل حاوية يعادل عملياً صلاحية root على المضيف) ونفحص السجلّ: المصادقة، وما إذا كانت الصور موقَّعة وأصلها مُتحقَّق منه، وما إذا كانت سياسات السحب (pull) تسمح بصور غير موثوقة.

هل الاختبار آمن على بيئة إنتاج قيد التشغيل؟

تحليل الصورة ومراجعة الإعدادات عمليتان للقراءة فقط وآمنتان. أما الاختبارات الفعّالة (محاولات الهروب) فيُتفَّق عليها مسبقاً وتُنفَّذ بحذر؛ ونفضّل بيئة staging تحاكي الإنتاج، وعندما يلزم الاختبار على الإنتاج نضع حدوداً ونبقي على جهة اتصال لديكم كي نتوقف فوراً إذا بدا أي شيء خاطئاً.

كيف تُحدَّد خطورة الاكتشافات؟

يحصل كل اكتشاف على درجة CVSS كأساس مشترك، تُعدَّل بحسب الأثر الفعلي في بيئتكم: إلى أين يصل المهاجم، وبأي سهولة، وهل يؤدي ذلك إلى المضيف أو إلى بيانات حسّاسة. ولهذا قد تُرتَّب مشكلتان لهما درجة CVSS نفسها بأولوية مختلفة.

هل تُشمل إعادة الاختبار بعد المعالجة، وكم تستغرق؟

نعم؛ بعد المعالجة نعيد اختبار الاكتشافات المُبلَّغ عنها للتأكد من ثبات كل إصلاح وأنه لم يفتح ثغرة جديدة. وتعتمد المدة على عدد الصور وتعقيد الـ runtime؛ ويستغرق التقييم المعتاد نحو أسبوع إلى ثلاثة أسابيع، ونقدّم تقديراً دقيقاً بعد تحديد النطاق.

هل أنتم مستعدون للبدء؟
تواصلوا مع فريقنا لمناقشة احتياجات تقييم الأمان لديكم