مخطط تفصيلي خطوة بخطوة لعزل بيئات متعددة المستأجرين في Docker

ملخص

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

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

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

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

---

1. فرض حصص موارد صارمة باستخدام مجموعات التحكم (Control Groups)

قم بتعيين حدود صريحة لوحدة المعالجة المركزية (CPU)، والذاكرة، ومدخلات/مخرجات القرص (Disk I/O) على كل حاوية على الفور. عندما يتشارك عدة مستأجرين خادمًا مضيفًا واحدًا، تتنافس الحاويات غير المقيدة على موارد النظام. يمكن لاستعلام قاعدة بيانات واحد غير منضبط أو حملة ذات زيارات مكثفة أن تستهلك ذاكرة المضيف بالكامل، مما يحفز أداة إنهاء العمليات عند نفاد الذاكرة في Linux (OOM Killer) لإنهاء عمليات نظام عشوائية.

تتحكم مجموعات تحكم Linux (cgroups) في مقدار السعة الحاسوبية التي يمكن لأي حاوية استهلاكها. طبّق هذه الحدود مباشرة في تعريفات النشر الخاصة بك:

services:
  tenant_app:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

• حدود الذاكرة (limits.memory): تحدد سقفًا أقصى صارمًا. إذا تجاوزت الحاوية 512 ميجابايت، تقوم النواة بإنهاء العمليات داخل تلك الحاوية دون التأثير سلبًا على المستأجرين المجاورين.
• حجوزات الذاكرة (reservations.memory): تضمن تخصيصًا أساسيًا للذاكرة حتى تظل التطبيقات ذات الزيارات المنخفضة سريعة الاستجابة.
• حدود وحدة المعالجة المركزية (limits.cpus): تقصر الحاوية على نسبة محددة كحد أقصى من نوى المعالج المتاحة، مما يمنع استنزاف موارد المعالج بواسطة مستأجر واحد.

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

---

2. تجزئة عمليات المستأجرين باستخدام مساحات الأسماء والمستخدمين غير الجذر (Non-Root Users)

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

افرض عزل العمليات من خلال مساحات أسماء المستخدمين والتنفيذ الصريح بدون صلاحيات root:

1. تحديد مستخدمي تشغيل غير مميزين: أنشئ مستخدمي خدمة مخصصين وذوي صلاحيات منخفضة داخل ملفات Dockerfile الخاصة بك.

   FROM php:8.2-fpm-alpine
   RUN addgroup -g 10001 tenantgroup && \
       adduser -u 10001 -D -G tenantgroup tenantuser
   USER tenantuser
   

2. تمكين مساحات أسماء المستخدمين (userns-remap): اضبط برنامج Docker الخفي (/etc/docker/daemon.json) لإعادة تعيين معرّفات مستخدمي الحاوية إلى نطاق غير مميز على المضيف.

   {
     "userns-remap": "default"
   }
   

تعمل مساحات أسماء Linux على تقسيم رؤية النظام. تضمن مساحة أسماء معرفات العمليات (PID) عدم قدرة المستأجر (أ) على رؤية عمليات المستأجر (ب) أو إرسال إشارات إليها أو إنهائها. تمنح مساحة أسماء نقاط التثبيت (MNT) كل مستأجر رؤية معزولة لنظام الملفات، بينما تحظر مساحات أسماء IPC الاتصال غير المصرح به بين العمليات.

تؤدي إعادة تعيين مساحات أسماء المستخدمين إلى إبطال وسائل الهروب من الحاويات؛ فالعملية التي تعتقد أنها root (UID 0) داخل حاويتها يتم تعيينها إلى معرف غير مميز (مثل UID 165536) على الجهاز المضيف. وإذا تجاوزت ثغرة أمنية حواجز الحاوية، فسيجد المهاجم نفسه في واجهة أوامر غير مميزة وغير قادرة على تعديل إعدادات المضيف أو الوصول إلى أدلة المستأجرين المجاورين.

---

3. تجريد امتيازات النواة وفرض أنظمة ملفات للقراءة فقط

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

أحكم إغلاق حاويات وقت التشغيل عن طريق إسقاط جميع الإمكانيات الافتراضية وإعادة إضافة الإشارات التشغيلية الأساسية فقط:

services:
  tenant_web:
    image: custom-nginx:latest
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
      - seccomp=default.json
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
      - /var/run:rw,noexec,nosuid,size=16m

• cap_drop: - ALL: يجرّد عملية الحاوية من كل إمكانيات النواة.
• cap_add: - NET_BIND_SERVICE: يسمح صراحةً بالربط بالمنافذ المميزة (مثل 80 و443) مع حظر التلاعب المباشر بمقابس الشبكة (raw sockets).
• read_only: true: يثبت نظام الملفات الجذري للحاوية بالكامل كوضع للقراءة فقط. لا يمكن للمهاجمين تنزيل ملفات ثنائية ضارة، أو تعديل نصوص PHP البرمجية، أو تغيير ملفات تكوين خادم الويب.
• tmpfs: يخصص أدلة مؤقتة داخل الذاكرة للملفات المؤقتة الضرورية (مثل /tmp) مع حظر تنفيذ البرامج الثنائية (noexec) وتصعيد الامتيازات (nosuid).

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

---

4. تقسيم الشبكات بين بيئات المستأجرين

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

اعزل حركة مرور المستأجرين تمامًا عن طريق تحديد جسور شبكة مستقلة لكل مستأجر:

networks:
  tenant_alpha_net:
    driver: bridge
    internal: true
  tenant_beta_net:
    driver: bridge
    internal: true
  public_gateway_net:
    driver: bridge

services:
  alpha_app:
    image: tenant_a_app:latest
    networks:
      - tenant_alpha_net
      - public_gateway_net

  alpha_db:
    image: mariadb:10.11
    networks:
      - tenant_alpha_net

  beta_app:
    image: tenant_b_app:latest
    networks:
      - tenant_beta_net
      - public_gateway_net

  beta_db:
    image: mariadb:10.11
    networks:
      - tenant_beta_net

• عزل المستأجرين: يتواصل alpha_app وalpha_db حصريًا عبر tenant_alpha_net. لا يمكن لـ beta_app الوصول إلى alpha_db، حتى إذا أجرى مهاجم فحصًا للشبكة الفرعية الداخلية.
• الخاصية الداخلية (internal: true): تمنع شبكات قواعد البيانات من توجيه حركة المرور مباشرة إلى الإنترنت الخارجي، مما يقصر الوصول الوارد والصادر على حاويات التطبيق فقط.
• بوابة الوكيل العكسي (Reverse Proxy Gateway): يتصل وكيل الدخول فقط بـ public_gateway_net لتوجيه طلبات HTTP/HTTPS الواردة إلى حاوية المستأجر المحددة حسب اسم المضيف.

بالنسبة للبيئات المتقدمة، فكّر في استخدام أوضاع عزل الحاويات المحسّنة (ECI) من Docker أو بيئات تشغيل مثل Sysbox، والتي تفرض تلقائيًا حدودًا أكثر صرامة لمساحة أسماء المستخدمين وأنظمة ملفات افتراضية لـ /proc و/sys دون الحاجة إلى برمجة نصية معقدة للشبكة يدويًا.

---

5. وضع مصفوفة قرارات موضوعية لتعدد المستأجرين

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

استخدم مصفوفة المقارنة التالية لتقييم متطلبات أعباء العمل وتقديم استراتيجية نشر منطقية لصناع القرار:

مستوى العزل	التقنية الأساسية	الحدود الأمنية	استهلاك الموارد الإضافي	أفضل حالات الاستخدام
حاويات مكدس مشترك	مساحات الأسماء ومجموعات التحكم على نظام تشغيل واحد	عزل منطقي على مستوى نظام التشغيل	منخفض جدًا	صفحات الهبوط عالية الحركة، وبيئات الاختبار الداخلية، ومواقع الحملات المؤقتة
حاويات مقواة (ECI / Sysbox)	مساحات أسماء المستخدمين، وAppArmor، ونظام جذر للقراءة فقط	مستوى نظام تشغيل متقدم ومحاكاة افتراضية	منخفض	استضافة الوكالات لعملاء متعددين، والبوابات المصادق عليها، ونماذج التسويق الحساسة
أجهزة افتراضية مخصصة (VMs)	المحاكاة الافتراضية للعتاد عبر Hypervisor	فصل صارم على مستوى العتاد/النواة	مرتفع	معالجة المدفوعات، وبيانات HIPAA/PCI الخاضعة للوائح التنظيمية، وتنفيذ التعليمات البرمجية المخصصة غير الموثوقة
هجين (حاويات داخل أجهزة افتراضية مخصصة)	حاويات مقواة داخل أجهزة افتراضية خاصة بكل مستأجر	حدود متعددة الطبقات من العتاد ونظام التشغيل	متوسط إلى مرتفع	عملاء المؤسسات من الفئات العليا الذين يطلبون الامتثال الصارم للعقود المخصصة

قيّم كل مشروع وفقًا لمعايير صارمة قبل تخصيص ميزانية البنية التحتية:

1. حساسية البيانات: هل يخزن المشروع بيانات خاضعة للتنظيم (مثل سجلات بطاقات الائتمان أو المعلومات الصحية والطبية)؟ إذا كانت الإجابة بنعم، فانشره على جهاز افتراضي مخصص.
2. مصدر الكود: هل تنشر تعليمات برمجية قياسية ومدققة من قبل الفريق، أم تسمح بإضافات خارجية غير مفحوصة؟ ينتمي الكود القياسي إلى الحاويات المقواة؛ بينما يتطلب الكود الخارجي غير المختبر عزل Hypervisor.
3. الميزانية والعمر الافتراضي: بالنسبة لصفحات الهبوط الموسمية ومواقع الويب الأساسية للشركة، يوفر تعدد المستأجرين عبر الحاويات المقواة أقصى أداء مقابل كل دولار.

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

---

الخلاصة: تحويل الضوابط الأمنية إلى عائد استثماري للأعمال

لا يتطلب تأمين بيئة Docker متعددة المستأجرين ميزانية بنية تحتية سحابية للمؤسسات الكبرى، بل يتطلب تطبيقًا دقيقًا ومنضبطًا لضوابط نظام التشغيل.

عند مراجعة البنية التحتية مع القيادة غير التقنية، ضع هذه التكوينات التقنية في إطار ثلاثة مقاييس تنفيذية:

• كفاءة التكلفة: تتيح الحاويات متعددة المستأجرين للفريق استضافة العشرات من مواقع التسويق بجزء بسيط من البصمة الحاسوبية التي تتطلبها الأجهزة الافتراضية الفردية.
• حماية وقت التشغيل (Uptime): تضمن مجموعات التحكم ألا تؤدي الزيادات المفاجئة في زيارات حملة موسمية إلى تدهور أداء مواقع العلامة التجارية الأساسية.
• احتواء نطاق التأثير (Blast Radius): تضمن أنظمة الملفات المخصصة للقراءة فقط، وتجريد الإمكانيات، وجسور الشبكات المعزولة عدم إمكانية وصول أي اختراق على موقع واحد إلى قواعد بيانات العملاء المجاورة أو عناصر التحكم في المضيف.

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