أمان الحاويات: تقوية الصور والحماية أثناء التشغيل
قوّوا صور Docker بإزالة الحزم غير الضرورية وتشغيلها كمستخدم غير root، واستخدموا أدوات أمان وقت التشغيل (Falco وSysdig) لاكتشاف سلوك الحاويات الشاذ.
أمان الحاويات: تقوية الصور والحماية أثناء التشغيل درس مجاني في Cloud & IT Cert Prep على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Cloud & IT Cert Prep، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
أساسيات أمان الحاويات
تجمع الحاويات شيفرة التطبيق وتبعياته في وحدات معزولة تتشارك نواة نظام التشغيل المضيف، بخلاف الأجهزة الافتراضية التي تتضمن نظام تشغيل ضيفاً كاملاً. يجعل هذا التشارك الحاويات خفيفة وسريعة، لكنه يقدم نموذجاً أمنياً مختلفاً: فقد تسمح ثغرة هروب من الحاوية للمهاجم بالخروج منها والوصول مباشرة إلى نواة المضيف، ما يؤثر في جميع الحاويات الأخرى. ويركز أمان الحاويات على ثلاث طبقات: الصورة (ما يتم تضمينه فيها)، ووقت التشغيل (ما يمكن للحاوية فعله أثناء التشغيل)، ومنصة التنسيق (كيفية إدارة الحاويات).
الصور الأساسية الدنيا: تقليل سطح الهجوم
تمثل كل حزمة مثبتة في صورة الحاوية سطح هجوم محتملاً. ويعني مبدأ الصور الأساسية الدنيا البدء من أصغر أساس ممكن: Alpine Linux (بحجم 5MB وحزم قليلة)، أو الصور الخالية من التوزيعة (صور Google التي لا تحتوي إلا على بيئة التشغيل والتطبيق، دون shell أو مدير حزم)، أو scratch (صورة فارغة تماماً، مخصصة للملفات الثنائية المترجمة بشكل ثابت). إن عدم احتواء الحاوية على shell يعني أن المهاجم الذي ينجح في تنفيذ شيفرة لن يستطيع بسهولة تشغيل wget أو curl أو أدوات أخرى لتوسيع هجومه، وهو مبدأ يُسمى الدفاع عبر تقليل التعرض.
# Bad: starts from a full OS image
FROM ubuntu:22.04
# Better: minimal Alpine base
FROM alpine:3.18
# Best: distroless for Java apps
FROM gcr.io/distroless/java17-debian11التشغيل كمستخدم غير root: القاعدة الأولى
بشكل افتراضي، تعمل حاويات Docker كمستخدم root (UID 0). فإذا استغل المهاجم ثغرة في التطبيق الموجود داخل الحاوية، فسيحصل على امتيازات root داخل الحاوية. وإذا كانت الحاوية تشارك وحدة تخزين أو لديها عمليات تحميل من المضيف، فقد تعادل صلاحيات root داخل الحاوية صلاحيات root على المضيف. والحل بسيط: إنشاء مستخدم مخصص في Dockerfile والتبديل إليه باستخدام توجيه USER قبل CMD/ENTRYPOINT النهائي. وستبلغ العديد من أدوات فحص أمان الحاويات عن أي صورة لا تحتوي على مستخدم غير root باعتبار ذلك نتيجة فحص.
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup app /app/app
USER appuser
CMD ["/app/app"]الحاويات غير القابلة للتغيير وأنظمة الملفات للقراءة فقط
الحاويات غير القابلة للتغيير هي حاويات لا يمكن تعديل نظام ملفاتها أثناء التشغيل. ويمنع تفعيل --read-only في Docker (أو readOnlyRootFilesystem: true في Kubernetes) المهاجمين من كتابة برمجيات خبيثة على القرص أو تعديل ملفات الإعداد أو تثبيت أدوات داخل حاوية قيد التشغيل. ويمكن للتطبيقات التي تحتاج فعلاً إلى كتابة البيانات، مثل السجلات والملفات المؤقتة، تحميل وحدات تخزين tmpfs مخصصة للكتابات المؤقتة. وتفرض الحاويات غير القابلة للتغيير مبدأ أن حالة وقت التشغيل يجب أن تأتي فقط من الصورة والإعدادات، لا من تعديلات داخل الحاوية تتجاوز مسار أمان CI/CD الخاص بكم.
# Run container with read-only root filesystem
docker run --read-only \
--tmpfs /tmp \
--tmpfs /var/run \
myapp:latestفحص الصور: اكتشاف CVEs قبل النشر
تحلل أدوات فحص صور الحاويات الحزم المثبتة في صورة Docker، وتقارنها بقواعد بيانات الثغرات (NVD وCVE)، ثم تُبلغ عن CVEs المعروفة. ومن أبرز أدوات الفحص Trivy (من Aqua Security، وسريع ومجاني)، وGrype (من Anchore)، وSnyk Container، وAWS ECR image scanning. ينبغي دمج الفحص في مسار CI/CD بحيث يفشل المسار قبل دفع الصورة إلى السجل إذا كانت تحتوي على CVEs حرجة أو عالية الخطورة. وينبغي أن تتحقق أدوات الفحص أيضًا من عدم تضمين أسرار (مثل مفاتيح API وكلمات المرور) عن طريق الخطأ في طبقات الصورة.
# Scan a Docker image with Trivy
trivy image --severity HIGH,CRITICAL myapp:latest
# Fail CI pipeline if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latestإدارة الأسرار: لا تضعها أبدًا في طبقات الصور
من الأخطاء الشائعة والخطيرة تضمين الأسرار (مثل مفاتيح API وكلمات مرور قواعد البيانات وشهادات TLS) داخل صور Docker، سواء في متغيرات البيئة المضمّنة في الصورة أو في الملفات المضافة باستخدام COPY. ويمكن لأي شخص لديه صلاحية الوصول إلى الصورة رؤية هذه الأسرار باستخدام docker history أو باستخراج طبقات الصورة. وحتى إذا حذفت طبقة لاحقة الملف، فإنه يظل موجودًا في سجل الصورة. ينبغي حقن الأسرار في وقت التشغيل عبر متغيرات البيئة من مدير أسرار، أو باستخدام Docker secrets، أو Kubernetes Secrets المثبّتة كوحدات تخزين.
# Never bake secrets into images
# Bad: ENV DATABASE_PASSWORD='supersecret'
# Good: inject at runtime via environment
docker run -e DATABASE_PASSWORD=$(vault read -field=password secret/db) myapp:latest
# Or use Docker secrets in Swarm/K8sالحماية في وقت التشغيل: Falco ومراقبة استدعاءات النظام
تراقب أدوات أمن وقت التشغيل سلوك الحاوية أثناء تشغيلها، وتصدر تنبيهات بشأن النشاط غير المعتاد أو تمنعه. إذ يتصل Falco (وهو مشروع من CNCF) بنواة Linux باستخدام eBPF أو وحدات النواة لاعتراض استدعاءات النظام ومقارنتها بالقواعد. فعلى سبيل المثال، يمكن لقاعدة أن تُصدر تنبيهًا إذا أنشأت حاوية غلافًا (shell) (execve('/bin/sh'))، أو فتحت اتصالًا شبكيًا على منفذ غير متوقع، أو قرأت /etc/shadow. وغالبًا ما تشير هذه المؤشرات السلوكية إلى هجوم نشط حتى إذا لم تُستغل أي CVE معروفة. وتوفر Sysdig Secure وAqua Security منصات تجارية للحماية في وقت التشغيل.
# Example Falco rule: alert on shell execution in container
# - rule: Shell Spawned in Container
# desc: A shell was spawned in a container
# condition: container and proc.name in (bash, sh, zsh)
# output: Shell spawned (user=%user.name container=%container.name)
# priority: WARNINGإمكانات Linux وملفات تعريف Seccomp
تسقط حاويات Docker افتراضيًا العديد من إمكانات Linux، لكنها تحتفظ مع ذلك بإمكانات أكثر مما تحتاج إليه معظم التطبيقات. وتُجزّئ الإمكانات امتيازات الجذر إلى وحدات منفصلة (مثل CAP_NET_ADMIN وCAP_SYS_ADMIN). وتتمثل أفضل ممارسة في إسقاط جميع الإمكانات ثم إعادة إضافة ما هو مطلوب فقط باستخدام --cap-drop=ALL --cap-add=NET_BIND_SERVICE. وتحدد ملفات تعريف Seccomp (Secure Computing Mode) استدعاءات النظام التي يُسمح للحاوية بإجرائها؛ إذ يتضمن Docker ملف تعريف Seccomp افتراضيًا يحظر نحو 44 من استدعاءات النظام الخطيرة. ويمكن لملفات تعريف Seccomp المخصصة لتطبيقات محددة تقييد ذلك بدرجة أكبر، بحظر جميع استدعاءات النظام التي لا يستخدمها التطبيق استخدامًا مشروعًا.
# Drop all capabilities, add only what's needed
docker run \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--security-opt seccomp=/etc/docker/seccomp-custom.json \
myapp:latestسجلات الحاويات وتوقيع الصور
تخزّن سجلات الحاويات (Docker Hub وAWS ECR وGoogle Artifact Registry) الصور وتوزّعها. ويتضمن تأمين السجل: تفعيل فحص الثغرات عند الدفع، وقصر صلاحية الدفع على حسابات خدمة CI/CD فقط، وتفعيل توقيع الصور باستخدام Sigstore/Cosign أو Docker Content Trust (Notary) بحيث لا تسحب بيئات التشغيل إلا الصور الموقّعة تشفيريًا من مصادر موثوقة، وتهيئة عدم قابلية الصور للتغيير بحيث لا يمكن استبدال الوسوم (Tags)، مما يلغي هجمات تغيير الوسوم التي يستبدل فيها المهاجم وسمًا موثوقًا مثل :latest بصورة خبيثة.
# Sign a container image with Cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3
# Verify signature before deployment
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3تقنيات الهروب من الحاويات ووسائل الدفاع
قد يحاول المهاجمون الذين ينجحون في تنفيذ تعليمات برمجية داخل حاوية إجراء هروب من الحاوية للوصول إلى المضيف. ومن التقنيات الشائعة: استغلال الحاويات ذات الامتيازات الضعيفة (--privileged يمنح وصولًا شبه غير مقيّد إلى المضيف)، وإساءة استخدام مقابس Docker المكشوفة (إذ يمنح تركيب /var/run/docker.sock داخل حاوية وصولًا كاملًا إلى Docker API، بما في ذلك إنشاء حاويات ذات امتيازات)، واستغلال ثغرات النواة عبر الإمكانات غير المؤمّنة. وتشمل وسائل الدفاع: عدم استخدام الوضع ذي الامتيازات إلا عند الضرورة القصوى، وعدم تركيب مقبس Docker داخل حاويات التطبيقات مطلقًا، والحفاظ على تحديث نواة المضيف بالتصحيحات، واستخدام gVisor أو Kata Containers لأحمال العمل التي تتطلب عزلًا قويًا.
# DANGEROUS: never do this in production
# docker run --privileged -v /:/host myapp:latest
# Check if a container is running privileged
docker inspect mycontainer | grep -i privilegedالامتثال لمعيار CIS Docker
يوفر Center for Internet Security (CIS) Docker Benchmark إرشادات تفصيلية لتهيئة أمان مضيفي Docker وحاوياته، وتشمل تهيئة البرنامج الخدمي، ونظافة الصور، وإعدادات وقت تشغيل الحاويات، وضوابط الشبكة. وتعمل أدوات مثل Docker Bench for Security على أتمتة فحص الامتثال لمعيار CIS، وإنشاء تقرير مُقيّم لعناصر النجاح والفشل. ويضمن تشغيل هذا المعيار دوريًا ودمجه في CI/CD اكتشاف انحراف إعدادات الأمان بسرعة. وينبغي للمتقدمين لشهادة Security+ معرفة أن CIS Benchmarks تُعد مرجعًا أساسيًا لتقوية أنظمة التشغيل والمنصات في سياق الاختبار.
# Run Docker Bench for Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
-v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
-v /etc:/etc docker/docker-bench-securityتحقق سريع
اختبر مدى فهمك لمفاهيم CompTIA Security+ (SY0-701) الواردة في هذا الدرس.
مراجعة الدرس
تعلمت في هذا الدرس أن الصور الأساسية الدنيا والمستخدمين غير الجذر يقللون سطح الهجوم ومستوى الامتيازات لأحمال العمل التي تعمل داخل الحاويات، وأن أدوات الحماية في وقت التشغيل مثل Falco تكتشف أنماط استدعاءات النظام غير المعتادة التي تشير إلى هجمات نشطة داخل الحاويات، وأنه يجب عدم استخدام الحاويات ذات الامتيازات أو تركيب مقبس Docker مطلقًا داخل حاويات التطبيقات، لأن هذه الإعدادات تتيح الهروب من الحاوية. بعد ذلك سنتناول أمن Kubernetes، بما في ذلك RBAC وسياسات الشبكة ومعايير أمان الـ Pods.
الأسئلة الشائعة
هل درس «أمان الحاويات: تقوية الصور والحماية أثناء التشغيل» مجاني؟
نعم — نص درس «أمان الحاويات: تقوية الصور والحماية أثناء التشغيل» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Cloud & IT Cert Prep، انتقل إلى CoddyKit PRO. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.
ماذا ستتعلم في «أمان الحاويات: تقوية الصور والحماية أثناء التشغيل»؟
قوّوا صور Docker بإزالة الحزم غير الضرورية وتشغيلها كمستخدم غير root، واستخدموا أدوات أمان وقت التشغيل (Falco وSysdig) لاكتشاف سلوك الحاويات الشاذ. تتمرن على Cloud & IT Cert Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Cloud & IT Cert Prep؟
لا تُشترط خبرة سابقة. Cloud & IT Cert Prep على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.
كم من الوقت يستغرق درس «أمان الحاويات: تقوية الصور والحماية أثناء التشغيل»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Cloud & IT Cert Prep هذا؟
نعم. كل درس في Cloud & IT Cert Prep يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- أمان الحاويات: تقوية الصور والحماية أثناء التشغيل
- أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod
- أمان الحوسبة عديمة الخوادم والدوال
- فحص أمان البنية التحتية باعتبارها شيفرة