أبرز أخطاء أمان Docker الواجب تجنبها في 2026

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

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

لماذا أمان Docker أصعب مما يبدو

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

تأتي حاويات Docker مُهيَّأة لراحة المطوّر، لا لتصليب بيئة الإنتاج. صلاحيات الجذر مفعّلة. جميع المنافذ قابلة للربط بجميع الواجهات. لا مراقبة وقت التشغيل. يقبل معظم المطوّرين هذه الإعدادات، ثم يُطلقون الحاوية ويمضون. هذا نهج مقبول للبداية، لكنه ليس وضعًا أمنيًا مكتملًا.

وفقاً لـ تقرير Red Hat لعام ٢٠٢٤ حول حالة أمان Kubernetes، أفادت ٦٧٪ من المؤسسات بأنها أخّرت أو أبطأت نشر التطبيقات بسبب مخاوف تتعلق بأمان الحاويات أو Kubernetes. هذا الاحتكاك في الغالب لا ينشأ عن هجمات، بل عن فرق تكتشف أن إعدادات حاوياتها تحتاج إلى تصليب لم تبنه من البداية.

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

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

أخطاء شائعة في إعداد Docker

معظم اختراقات الحاويات لا تبدأ بثغرة يوم الصفر، بل تبدأ بإعدادات حُدِّدت منذ اليوم الأول دون تفكير كافٍ في مدى الكشف الشبكي أو نطاق الصلاحيات.

الإعدادات الافتراضية لـ Docker مصمَّمة للعمل أولاً. الفجوة بين ما يعمل وما هو آمن هي المكان الذي تتراكم فيه مخاطر أمان حاويات Docker، لا سيما في البيئات المستضافة ذاتياً التي تُنشر مرة واحدة ولا يُعاد النظر فيها.

نرى هذا النمط كثيراً: حاويات تعمل على خوادم ذات IP عام مع ربط المنافذ وإعدادات المستخدمين والتكوينات الشبكية كما كانت عليه عند النشر الأول.

تشغيل الحاويات بصلاحيات root

عند تشغيل حاوية Docker دون تحديد مستخدم، تعمل بصلاحيات root. هذا يعني أن كل عملية داخل الحاوية، بما فيها تطبيقك، تمتلك صلاحيات root ضمن نطاق الحاوية.


صلاحية root داخل الحاوية ليست مطابقة لـ root على المضيف، لكن الفصل بينهما ليس مطلقاً. ثغرات تصعيد الصلاحيات التي تستهدف بيئة التشغيل، كثغرة runc CVE-2019-5736 الموثقة جيداً وما يماثلها، كثيراً ما تشترط وجود عملية root داخل الحاوية لتنجح.

الحاويات غير الـ root تُلغي شرط وجود عملية root الذي تعتمد عليه تلك الثغرات، مما يُضيِّق سطح الهجوم لهذه الفئة تضييقاً ملحوظاً، وإن كانت لا تُلغي خطر الإفلات من الحاوية كلياً.

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

كشف منافذ زائدة على الإنترنت العام

عند نشر منفذ عبر Docker، يكتب Docker قواعده الخاصة مباشرةً في iptables، وتُطبَّق هذه القواعد قبل قواعد جدار حماية المضيف. وهذا سلوك معروف أبلغ عنه المجتمع و موثَّق في دليل تصفية الحزم الخاص بـ Docker، وليس خطأً في الإعداد، ويعني أن UFW وأدوات مماثلة لا تحجب ما فتحه Docker بالفعل.

يكتب Docker مباشرةً في iptables، متجاوزاً إعدادات UFW وfirewalld الافتراضية على كثير من مضيفي Linux. هذا يعني أن منفذاً مرتبطاً بـ 0.0.0.0 قد يكون قابلاً للوصول من الخارج حتى حين يبدو جدار الحماية مضبوطاً. مجموعات أمان السحابة وقواعد سلسلة DOCKER-USER لا تزال قادرة على حجب هذه الحركة، لذا يتوقف الكشف الفعلي على تكوين شبكتك تحديداً.

اربط الخدمات بـ 127.0.0.1 كلما أمكن، ومرِّر الحركة الموجهة للخارج عبر reverse proxy، وانشر فقط ما يحتاج فعلاً إلى وصول خارجي. الـ reverse proxy هو الطريقة الأكثر موثوقية للتحكم فيما يُكشف خارج المضيف.

إهمال عزل الشبكة بين الحاويات

أي حاوية على تلك الشبكة تستطيع الوصول إلى أي حاوية أخرى عليها دون قيود. الـ bridge الافتراضي لا يُطبِّق أي تصفية لحركة المرور بين الحاويات التي تشاركه، وأغلب البيئات لا تُغيِّر هذا التكوين أبداً.

إذا تعرضت إحدى الحاويات للاختراق، يتحول ذلك التواصل المفتوح إلى مسار للتحرك الأفقي. حاوية frontend تستطيع الوصول إلى قاعدة البيانات، أو إلى API داخلي، أو إلى أي شيء آخر على نفس شبكة الـ bridge الافتراضي، حتى حين لم يكن ذلك الوصول مقصوداً قط.

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

إغفال socket الخاص بـ Docker

الـ socket الخاص بـ Docker في المسار /var/run/docker.sock هو واجهة التحكم لمحرك Docker بالكامل. تحميله داخل حاوية يمنح تلك الحاوية وصولاً مباشراً عبر API إلى الـ daemon العامل على المضيف.

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

في معظم حالات الاستخدام، ثمة بدائل أكثر أماناً: API محدودة النطاق أو أدوات إدارة Docker التي لا تتطلب الوصول إلى Socket. تشغيل Docker داخل Docker ينطوي على مقايضات أمنية وتشغيلية خاصة به، وليس بديلاً مباشراً.

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

أخطاء الصور والأسرار التي تعيش أطول من الحاوي

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

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

هذا النمط شائع: صورة اختُيرت بعناية عند بداية المشروع ولم تُعَد بناؤها منذ ذلك الحين، تنجرف تدريجياً عن خط الأمان الذي كانت تمثله في البداية.

استخدام صور غير موثوقة أو قديمة

السجلات العامة مفتوحة للجميع. وقد انتشرت صور خبيثة عبر Docker Hub تحمل برامج تعدين للعملات المشفرة وأبواباً خلفية مُضمَّنة في طبقات السجل، وتظل قائمة عبر إعادة تشغيل الحاويات. التحقق قبل السحب أمر ضروري، لا سيما للصور الصادرة عن جهات غير رسمية أو مجهولة.

المشكلة الأخرى هي قِدَم الصور. صورة رسمية سحبتها قبل ستة أشهر ولم تُعد بناؤها منذ ذلك الحين، تراكمت فيها ثغرات Docker غير مُرقَّعة مع كل CVE كُشف عن حزمها. الصورة ليست معطوبة، لكنها لم تعد محدَّثة.

تقرير Sonatype لعام ٢٠٢٤ حول حالة سلسلة توريد البرمجيات وجد أن في ٩٥٪ من الحالات التي يُستخدم فيها مكوّن ذو ثغرة، تكون نسخة مُصلَحة متاحة بالفعل، وأن ٨٠٪ من تبعيات التطبيقات تبقى دون ترقية لأكثر من عام. هذا النمط ينطبق أيضاً على صور Docker الأساسية، إذ تعتمد على حزم المصدر المفتوح ذاتها.

استخدم الصور الرسمية من جهات نشر موثوقة، وحدد بطاقات إصدار محددة بدلاً من الاعتماد على "latest". ضع جدولاً منتظماً لإعادة البناء لتبقي صورك محدَّثة.

تضمين الأسرار في ملفات Docker وملفات Compose

بيانات الاعتماد المكتوبة داخل تعليمة ENV أو ARG في Dockerfile، أو المُضمَّنة في كتلة environment في Compose، أو المُمرَّرة كوسائط بناء، أو المخزنة في ملف .env مُرتكب في نظام إدارة الإصدارات، لا تختفي حين توقف الحاوي. تبقى في طبقات سجل الصورة أو في نظام التحكم بالمصدر، في متناول أي شخص يمكنه الوصول إلى أي منهما.

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

يدعم Docker Compose الحديث آلية أسرار أصيلة تُحمِّل بيانات الاعتماد في وقت التشغيل دون دمجها في الصورة. تتبع واجهة API للأسرار في Docker ومديرو الأسرار الخارجيون المبدأ ذاته. هذه هي الخيارات التي تُبقي بيانات الاعتماد بعيدة تماماً عن مخرجات البناء والملفات المُرتكبة.

متغيرات البيئة في وقت التشغيل أفضل من بيانات الاعتماد المُضمَّنة في الكود، لكنها لا تزال مكشوفة عبر مخرجات Docker inspect والسجلات وتفريغات الأعطال. إنها خطوة للأمام لا حلاً نهائياً.

عدم تحديث صور الحاويات بانتظام

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

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

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

ثغرات التحكم في الوصول والرؤية

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

ذات أبحاث Red Hat لعام ٢٠٢٤ وجدت أن ٤٢٪ من الفرق تفتقر إلى القدرات الكافية للتعامل مع أمان الحاويات والتهديدات المرتبطة به.

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

ضعف المصادقة ولوحات إدارة مكشوفة

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

تأتي أدوات المراقبة والإدارة المستضافة ذاتياً عادةً بواجهة ويب مُتاحة على جميع واجهات الشبكة. تركها على IP عام دون مصادقة أمامها يعادل ترك لوحة الإدارة مفتوحة دون قفل.

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

ينطبق المبدأ ذاته على إدارة Docker عبر CLI و GUI؛ فالوصول على مستوى المسؤول إلى الخادم الخفي ينطوي على المخاطر نفسها بصرف النظر عن الواجهة المستخدمة.

عدم مراقبة ما تفعله حاوياتك

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

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

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

لماذا تُهم بيئة البنية التحتية أيضاً

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

كثير من الثغرات الأمنية في Docker تتضخم بسبب ظروف ترثها الحاويات ذاتها:

• خادم ذو استضافة مشتركة دون عزل مادي بين المستأجرين
• نواة مضيف تعمل دون تصحيحات
• مزود استضافة بدون تصفية على مستوى الشبكة

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

في Cloudzy، نقدم مسارين بحسب ما يتطلبه إعدادك:

• Linux VPS: بيئة نظيفة لنشر Docker بنفسك وتطبيق خطوات التصليب الواردة في هذا المقال
• Portainer VPS: خيار بنقرة واحدة مع تثبيت Portainer مسبقاً، يعمل الخادم مباشرةً وتجد نفسك داخل لوحة التحكم

يعمل كلا الخيارين على البنية التحتية ذاتها: افتراضية KVM، ومعالجات AMD Ryzen 9 CPU بسرعة تعزيز تصل إلى 5.7 GHz، وذاكرة DDR5، وتخزين NVMe SSD، وشبكة تصل إلى 40 Gbps، وحماية مجانية من DDoS عبر تصفية BuyVM، في 12 موقعاً حول العالم مع ضمان اتاحة بنسبة 99.95%.

للاطلاع على تفاصيل أعمق حول تشغيل Portainer على VPS، نتناول ذلك في مقال مخصص.

قائمة مراجعة أمنية عملية لعمليات نشر Docker

معظم أخطاء أمان Docker المذكورة أعلاه تنشأ من قرارات ضبط فردية اتُخذت مرة واحدة ولم يُعَد النظر فيها قط. تشغيل هذه القائمة على إعداد قائم يكشف تلك الثغرات. إنها أداة تدقيق، لا دليل نشر.

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

مرجع سريع: جميع الأخطاء التسعة

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

الحاويات تعمل بصلاحيات غير المستخدم الجذر: تحقق من وجود توجيه USER في ملفات Docker. إن لم يكن موجوداً، تعمل الحاوية بصلاحيات المستخدم الجذر.

ربط المنافذ مقيّد بـ localhost أو يمر عبر وسيط: شغّل docker ps وراجع ربط المنافذ. يعني الإدخال 0.0.0.0:PORT أن المنفذ قد يكون متاحاً للعموم على المضيفين الذين لا تحجبه فيهم مجموعة أمان خارجية أو جدار حماية أو قاعدة في سلسلة DOCKER-USER.

شبكات الجسر المخصصة قيد الاستخدام: الحاويات على جسر Docker الافتراضي يمكنها الوصول إلى بعضها بحرية. الحاويات على نفس الجسر المعرّف من قبل المستخدم لا تزال تتواصل مع بعضها، لذا وزّع الخدمات على شبكات منفصلة وفق حدود الثقة لتحقيق عزل فعلي.

مقبس Docker غير مُوصَل داخل الحاويات: تحقق من ملفات Compose وسيطات التشغيل. إن ظهر /var/run/docker.sock كمجلد مشارك، تأكد أن ذلك ضروري ومقصود.

الصور الأساسية من ناشرين موثوقين مع تثبيت الإصدارات: الأمر FROM ubuntu:latest يسحب إصداراً غير محدد وربما قديماً. ثبّت الإصدار على إطلاق محدد.

لا توجد أسرار في ملفات Docker أو ملفات Compose أو سيطات البناء: تاريخ طبقات الصورة يحتفظ ببيانات الاعتماد حتى بعد حذف الحاوية. استخدم Compose secrets أو Swarm secrets أو وحدات تحميل الأسرار في البناء أو مدير أسرار خارجي. متغيرات البيئة في وقت التشغيل أفضل من القيم المضمّنة في الكود، غير أنها تظهر في مخرجات inspect والسجلات.

جدول إعادة بناء الصور محدد: الصور القديمة تتراكم فيها الثغرات. إعادة البناء شهرياً تُبقي نافذة التعرض في حدود مقبولة لمعظم البيئات.

واجهات الإدارة محمية بمصادقة: أي لوحة تحكم على عنوان IP عام بدون مصادقة هي نقطة دخول مفتوحة. يُفضَّل وضعها على شبكة خاصة كلما أمكن ذلك.

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

خلاصة

الإعداد الافتراضي لـ Docker مصمم للسهولة، لا للأمان. معظم الأخطاء الواردة في هذا المقال مردّها إعدادات لم تُغيَّر بعد النشر الأول، لا هجمات معقدة.

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

ضبط إعداد الحاوية هو المهمة الأولى. البنية التحتية التي تعمل عليها هي الثانية. كلاهما ضروري، ولا يُغني أحدهما عن الآخر.

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