تصميم شبكات DMZ وApplication وDatabase لحماية تطبيقات الشركات

يُعدّ تصميم شبكات DMZ وApplication وDatabase (البنية الثلاثية الطبقات) من أقوى أساليب حماية تطبيقات الشركات. فالشركات اليوم تعتمد على تطبيقات رقمية مترابطة تشمل المواقع والمتاجر وأنظمة ERP وتطبيقات SaaS وواجهات API وقواعد البيانات؛ ومع زيادة هذه الخدمات، يصبح تشغيل جميع الخوادم داخل شبكة واحدة خطراً أمنياً كبيراً، ما يجعل فصلها إلى طبقات معزولة ضرورة.

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

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

لهذا تعتمد البنية التحتية الاحترافية على تقسيم التطبيق إلى طبقات شبكية منفصلة، أهمها:

• شبكة DMZ للخدمات المتاحة عبر الإنترنت.
• شبكة Application لخوادم التطبيقات والمنطق البرمجي.
• شبكة Database لقواعد البيانات والبيانات الحساسة.
• شبكة Management للإدارة والمراقبة.
• شبكة Backup لحماية النسخ الاحتياطية.

يسمى هذا التصميم غالباً Three-Tier Network Architecture أو البنية الشبكية ثلاثية الطبقات، وهو من أكثر التصاميم استخداماً لحماية تطبيقات الشركات، وأنظمة ERP، ومنصات SaaS، والمواقع الإلكترونية ذات البيانات الحساسة.

داخل مرام بلاتفورم يمكن إنشاء هذه الشبكات باستخدام Proxmox وVLAN وLayer 3 Routing، مع تشغيل Firewall افتراضي مثل OPNsense أو pfSense، وربط كل طبقة بقواعد اتصال دقيقة تمنع الوصول غير الضروري وتقلل مساحة الهجوم.

في هذا الدليل سنتعرف على كيفية تصميم شبكات DMZ وApplication وDatabase، ودور كل شبكة، وكيفية ضبط الاتصال بينها، وأفضل الممارسات لحماية تطبيقات الشركات داخل بيئة Proxmox Private Cloud.

لماذا تحتاج تطبيقات الشركات إلى تقسيم شبكي؟

قد يتكون تطبيق الشركة من عدة أجزاء، مثل:

💡 اقرأ أيضاً: ما هي مرام بلاتفورم؟ منصة البنية التحتية السحابية الكاملة

• واجهة المستخدم.
• خادم الويب.
• Reverse Proxy.
• خادم التطبيق.
• واجهة API.
• قاعدة البيانات.
• Redis.
• نظام تخزين الملفات.
• خدمات النسخ الاحتياطي.
• لوحة الإدارة.
• نظام المراقبة.

وضع جميع هذه الخدمات داخل شبكة واحدة يجعل عملية الإدارة أسهل في البداية، لكنه يرفع المخاطر الأمنية بشكل كبير.

إذا استطاع المهاجم اختراق خادم واحد، فقد يتمكن من:

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

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

ما هي بنية Three-Tier Architecture؟

تعتمد البنية ثلاثية الطبقات على فصل مكونات التطبيق إلى ثلاث مناطق رئيسية:

تقوم فكرة شبكات DMZ وApplication وDatabase على فصل واجهة الإنترنت عن منطق التطبيق عن قاعدة البيانات، بحيث لا يصل أي طرف خارجي إلى بياناتك مباشرة.

طبقة العرض Presentation Layer

تشمل الخدمات التي تتعامل مباشرة مع المستخدمين، مثل:

• الموقع الإلكتروني.
• Reverse Proxy.
• Load Balancer.
• Web Application Firewall.
• بوابة API العامة.

توضع هذه الخدمات عادة داخل شبكة DMZ.

طبقة التطبيق Application Layer

تحتوي على منطق التطبيق والخدمات الخلفية، مثل:

• Odoo Application Server.
• Laravel Backend.
• Node.js Services.
• Java Applications.
• ASP.NET Applications.
• API Services.
• Queue Workers.
• Redis في بعض التصاميم.

توضع هذه الخوادم داخل Application Network.

طبقة البيانات Database Layer

تحتوي على البيانات الحساسة وقواعد البيانات، مثل:

• PostgreSQL.
• MySQL.
• MariaDB.
• Microsoft SQL Server.
• MongoDB.
• قواعد بيانات ERP.
• أنظمة التخزين الداخلية.

توضع هذه الخدمات داخل Database Network مع أعلى مستوى من العزل.

ما هي شبكة DMZ؟

كلمة DMZ هي اختصار لعبارة Demilitarized Zone، وتعني المنطقة الشبكية المعزولة التي توضع بين الإنترنت والشبكة الداخلية.

تحتوي DMZ على الخوادم التي تحتاج إلى استقبال الاتصالات العامة، لكنها لا تمنح هذه الخوادم وصولاً مفتوحاً إلى بقية البنية التحتية.

يمكن وضع الخدمات التالية داخل DMZ:

• Reverse Proxy.
• NGINX.
• HAProxy.
• Traefik.
• Load Balancer.
• Web Application Firewall.
• Mail Gateway.
• VPN Gateway.
• Public API Gateway.
• Bastion Host في بعض التصاميم.

تعتبر DMZ طبقة حماية أولى تفصل الإنترنت عن خوادم التطبيقات وقواعد البيانات.

لماذا لا يوضع خادم التطبيق مباشرة في DMZ؟

خادم التطبيق يحتوي عادة على:

• منطق الأعمال.
• مفاتيح API.
• بيانات اتصال قاعدة البيانات.
• ملفات الإعداد.
• أسرار التطبيقات.
• صلاحيات داخلية.
• جلسات المستخدمين.

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

يفضل بدلاً من ذلك وضع Reverse Proxy أو Load Balancer داخل DMZ، ثم السماح له بإرسال الطلبات إلى خادم التطبيق عبر منافذ محددة فقط.

ما هي شبكة Application؟

شبكة Application هي الشبكة التي تحتوي على خوادم التطبيق والخدمات الخلفية.

لا تكون هذه الشبكة متاحة مباشرة من الإنترنت، بل تستقبل الاتصالات فقط من الخدمات المسموح لها داخل DMZ أو من شبكة الإدارة.

يمكن أن تحتوي Application Network على:

• Odoo Server.
• ERPNext.
• Laravel Applications.
• Node.js Applications.
• Java Services.
• ASP.NET Core.
• Docker Hosts.
• Kubernetes Worker Nodes.
• Backend APIs.
• Queue Workers.
• Authentication Services.
• Redis.
• Message Brokers.

يتم التحكم في الاتصال إليها من خلال Firewall.

ما هي شبكة Database؟

شبكة Database هي أكثر طبقات التطبيق حساسية، لأنها تحتوي على البيانات الأساسية للشركة والعملاء.

يمكن أن تشمل:

• PostgreSQL.
• MySQL.
• MariaDB.
• Microsoft SQL Server.
• Oracle Database.
• MongoDB.
• Redis عندما يحتوي على بيانات حساسة.
• Object Storage داخلي.
• أنظمة تخزين الملفات.
• قواعد بيانات التحليلات.

يجب ألا تكون قاعدة البيانات متاحة مباشرة من الإنترنت أو من DMZ.

يسمح فقط لخوادم التطبيق المحددة بالوصول إلى منافذ قاعدة البيانات المطلوبة.

التصميم الأساسي لشبكات DMZ وApplication وDatabase

يمكن تصميم البنية على الشكل التالي:

الإنترنت ← Firewall أو WAF ← شبكة DMZ ← شبكة Application ← شبكة Database

مع إضافة شبكات مستقلة للإدارة والنسخ الاحتياطي والمراقبة.

يتعامل Firewall مع جميع الاتصالات بين الطبقات، ويطبق سياسة تمنع الاتصال افتراضياً وتسمح فقط بما يحتاج إليه التطبيق.

مثال عملي على تقسيم الشبكات

يمكن تخصيص الشبكات التالية لشركة تستخدم نظام ERP:

في هذا المثال يتّضح كيف يصمّم فريق تقني شبكات DMZ وApplication وDatabase بحيث تُوضع الخوادم العامة في DMZ، وخوادم التطبيقات في شبكة Application، وقواعد البيانات في شبكة Database معزولة تماماً.

DMZ Network

• VLAN: 310
• الشبكة: 10.31.10.0/24
• Reverse Proxy: 10.31.10.10
• WAF: 10.31.10.11

Application Network

• VLAN: 320
• الشبكة: 10.31.20.0/24
• Odoo Server 1: 10.31.20.10
• Odoo Server 2: 10.31.20.11
• Redis Server: 10.31.20.20

Database Network

• VLAN: 330
• الشبكة: 10.31.30.0/24
• PostgreSQL Primary: 10.31.30.10
• PostgreSQL Replica: 10.31.30.11

Management Network

• VLAN: 340
• الشبكة: 10.31.40.0/24
• Monitoring: 10.31.40.10
• Jump Server: 10.31.40.20

Backup Network

• VLAN: 350
• الشبكة: 10.31.50.0/24
• Proxmox Backup Server: 10.31.50.10

كل شبكة تكون معزولة، ولا يسمح بالاتصال بينها إلا عبر قواعد Firewall محددة.

قواعد الاتصال بين الطبقات

يمكن تطبيق سياسة اتصال مثل:

• الإنترنت يصل إلى Reverse Proxy على المنفذين 80 و443.
• Reverse Proxy يصل إلى خوادم التطبيق على منافذ الخدمة فقط.
• خوادم التطبيق تصل إلى قاعدة البيانات على منفذ قاعدة البيانات فقط.
• قاعدة البيانات لا تستقبل أي اتصال من DMZ.
• قاعدة البيانات لا تخرج إلى الإنترنت إلا عند الضرورة.
• شبكة الإدارة تصل إلى الخوادم عبر SSH أو RDP أو واجهات الإدارة.
• شبكة النسخ الاحتياطي تصل إلى الخوادم عبر منافذ النسخ المطلوبة.
• جميع الاتصالات الأخرى مرفوضة.

هذا التصميم يطبق مبدأ Least Privilege، أي منح كل نظام أقل قدر ممكن من الوصول.

مثال على قواعد Firewall

يمكن أن تكون القواعد الأساسية بالشكل التالي:

من الإنترنت إلى DMZ

السماح بـ:

• TCP 80.
• TCP 443.
• منفذ VPN عند الحاجة.

منع بقية الاتصالات.

من DMZ إلى Application

السماح فقط من عنوان Reverse Proxy إلى خوادم التطبيقات على المنافذ المحددة، مثل:

• TCP 8069 لتطبيق Odoo.
• TCP 3000 لتطبيق Node.js.
• TCP 8000 لتطبيق Django.
• TCP 5000 لتطبيق ASP.NET.
• TCP 8080 لخدمات Java.

منع جميع الاتصالات الأخرى.

من Application إلى Database

السماح فقط من خوادم التطبيقات إلى قاعدة البيانات.

على سبيل المثال:

• TCP 5432 لخادم PostgreSQL.
• TCP 3306 لخادم MySQL.
• TCP 1433 لخادم Microsoft SQL Server.
• TCP 6379 لخادم Redis إذا لزم الأمر.

من DMZ إلى Database

منع كامل.

من Management إلى جميع الشبكات

السماح فقط من Jump Server أو شبكة VPN الإدارية إلى منافذ الإدارة المطلوبة.

من Backup إلى الخوادم

السماح بالاتصالات الضرورية للنسخ الاحتياطي فقط.

مبدأ Default Deny

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

بدلاً من السماح بجميع الاتصالات ثم حظر بعضها، يتم:

1. منع الترافيك بين الشبكات.
2. تحديد الخدمات الضرورية.
3. إضافة قواعد محددة للمصدر والوجهة والمنفذ.
4. مراقبة السجلات.
5. إزالة أي قاعدة لم تعد مطلوبة.

يقلل ذلك من فرص الحركة الجانبية داخل الشبكة عند اختراق أحد الخوادم.

كيف تمنع DMZ المهاجم من الوصول إلى قاعدة البيانات؟

إذا تم اختراق Reverse Proxy داخل DMZ، يحاول المهاجم عادة اكتشاف الشبكات الداخلية.

لكن في التصميم الصحيح:

• لا يوجد مسار مباشر من DMZ إلى Database.
• يسمح Firewall فقط بالاتصال بخادم التطبيق.
• لا يستطيع Reverse Proxy الاتصال بمنفذ PostgreSQL أو MySQL.
• لا توجد بيانات اعتماد قاعدة البيانات على خادم Reverse Proxy.
• تسجل محاولات الاتصال المرفوضة.
• يمكن لنظام IDS/IPS اكتشاف النشاط المشبوه.

وبذلك يبقى الوصول إلى قاعدة البيانات محدوداً حتى بعد اختراق إحدى خدمات DMZ.

حماية طبقات التطبيق والبيانات

رغم أن Application Network غير متاحة مباشرة من الإنترنت، فإنها قد تتعرض لمحاولات اختراق من DMZ.

لذلك يجب:

• تحديث التطبيقات باستمرار.
• تشغيل الخدمات الضرورية فقط.
• استخدام Firewall محلي على كل خادم.
• إدارة الأسرار بطريقة آمنة.
• عدم تخزين كلمات المرور داخل ملفات مكشوفة.
• استخدام حسابات خدمة محدودة الصلاحيات.
• مراقبة الاتصالات.
• تطبيق المصادقة بين الخدمات.
• تقييد الوصول إلى قاعدة البيانات.

حماية شبكة Database

يجب أن تحصل Database Network على أعلى مستوى من الحماية.

من أفضل الممارسات:

• عدم منح قاعدة البيانات عنوان IP عاماً.
• منع الوصول المباشر من الإنترنت.
• منع الوصول المباشر من DMZ.
• السماح فقط لعناوين Application Servers.
• تشفير الاتصالات بين التطبيق وقاعدة البيانات.
• استخدام حساب مختلف لكل تطبيق.
• عدم استخدام حساب Administrator أو Root داخل التطبيق.
• تطبيق نسخ احتياطي دوري.
• مراقبة الاستعلامات.
• تحديث نظام قاعدة البيانات.
• تسجيل محاولات الدخول.
• تشفير البيانات الحساسة عند الحاجة.

عزل الطبقات بـ VLAN و Layer 3

يمكن تخصيص VLAN مستقلة لكل طبقة داخل Proxmox.

💡 اقرأ أيضاً: شبكات VLAN وLayer 3 في مرام بلاتفورم: كيف يتم عزل شبكة كل شركة؟

على سبيل المثال:

• VLAN 310 لشبكة DMZ.
• VLAN 320 لشبكة Application.
• VLAN 330 لشبكة Database.
• VLAN 340 لشبكة Management.
• VLAN 350 لشبكة Backup.

يتم تمرير هذه الشبكات عبر VLAN-Aware Bridge داخل Proxmox، ثم تعيين VLAN Tag مناسب لكل بطاقة شبكة افتراضية.

لا تستطيع الآلات الافتراضية التواصل بين VLAN المختلفة دون المرور عبر Layer 3 Gateway أو Firewall.

دور Layer 3 Routing

يستخدم Layer 3 Routing لربط الشبكات المنفصلة ببعضها بطريقة خاضعة للسيطرة.

يمكن تنفيذ التوجيه من خلال:

• OPNsense.
• pfSense.
• MikroTik CHR.
• Layer 3 Switch.
• Linux Router.
• Proxmox SDN Gateway.

في البنى الحساسة، يفضل تمرير الاتصال بين DMZ وApplication وDatabase عبر Firewall للحصول على:

• قواعد دقيقة.
• تسجيل كامل.
• مراقبة الجلسات.
• IDS/IPS.
• Rate Limiting.
• سياسات NAT.
• تحكم أفضل في الوصول.

أدوات العزل: الجدار الناري و Reverse Proxy

يمكن تشغيل OPNsense أو pfSense كـ Firewall افتراضي داخل مرام بلاتفورم.

ويمكن استخدام OPNsense أو pfSense لتطبيق قواعد العزل بين الطبقات بدقّة.

💡 اقرأ أيضاً: كيفية إنشاء Firewall خاص داخل مرام بلاتفورم بـ OPNsense/pfSense

يرتبط Firewall بواجهة عامة وعدة VLAN داخلية، مثل:

• WAN.
• DMZ.
• Application.
• Database.
• Management.
• Backup.

ثم يتم إنشاء قاعدة مستقلة لكل واجهة.

يوفر ذلك:

• Stateful Firewall.
• Inter-VLAN Routing.
• NAT.
• VPN.
• IDS/IPS.
• GeoIP Blocking.
• DNS Resolver.
• DHCP.
• تسجيل الاتصالات.
• High Availability عند الحاجة.

استخدام MikroTik CHR

يمكن استخدام MikroTik CHR لإدارة Layer 3 Routing بين الشبكات.

يدعم:

• VLAN.
• Firewall.
• NAT.
• WireGuard.
• IPsec.
• OSPF.
• BGP.
• VRF.
• Traffic Shaping.
• Policy Routing.

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

Reverse Proxy داخل DMZ

يعتبر Reverse Proxy من أهم مكونات DMZ.

💡 اقرأ أيضاً: كيفية إنشاء Reverse Proxy لنشر عدة مواقع من IP واحد

يستقبل الطلبات عبر عنوان IP عام واحد، ثم يوجهها إلى التطبيقات الداخلية حسب اسم النطاق.

مثلاً:

• www.company.com إلى Web Application.
• erp.company.com إلى Odoo.
• api.company.com إلى API Server.
• portal.company.com إلى Customer Portal.

تظل خوادم التطبيقات بعناوين خاصة ولا تكون متاحة مباشرة عبر الإنترنت.

Web Application Firewall داخل DMZ

يمكن إضافة WAF أمام التطبيقات للمساعدة في حماية طبقة الويب.

يساعد WAF في تقليل بعض أنواع الهجمات مثل:

• SQL Injection.
• Cross-Site Scripting.
• الطلبات الآلية الضارة.
• استغلال بعض ثغرات التطبيقات.
• محاولات فحص المسارات.
• الهجمات على صفحات تسجيل الدخول.

يمكن استخدام:

• ModSecurity.
• Coraza.
• Cloudflare WAF.
• حلول WAF تجارية.
• WAF مدمج مع بعض منصات Load Balancing.

يجب ألا يعتبر WAF بديلاً عن تحديث التطبيق وتأمينه، بل طبقة حماية إضافية.

Load Balancer داخل DMZ

عند تشغيل أكثر من Application Server، يمكن استخدام Load Balancer لتوزيع الطلبات.

مثلاً:

الإنترنت ← Load Balancer ← Application Server 1 وApplication Server 2

يوفر ذلك:

• توزيع الحمل.
• زيادة القدرة الاستيعابية.
• الاستمرار عند تعطل خادم.
• Health Checks.
• صيانة خادم دون إيقاف الخدمة.
• التوسع الأفقي.

يمكن استخدام:

• HAProxy.
• NGINX.
• Traefik.
• Envoy.

هل توضع Web Servers في DMZ أم Application Network؟

يعتمد ذلك على التصميم.

في تصميم بسيط، يمكن وضع Web Server أو Reverse Proxy داخل DMZ.

أما إذا كان Web Server يحتوي على أجزاء كبيرة من منطق التطبيق أو بيانات حساسة، فمن الأفضل إبقاء خادم العرض في DMZ ووضع Backend الحقيقي داخل Application Network.

الهدف الأساسي هو تقليل الخدمات والبيانات الموجودة في المنطقة المكشوفة للإنترنت.

حماية التطبيقات حسب النوع

يمكن تصميم استضافة Odoo بالشكل التالي:

💡 اقرأ أيضاً: استضافة Odoo وERP على مرام بلاتفورم: بنية آمنة قابلة للتوسّع

DMZ

تحتوي على:

• NGINX Reverse Proxy.
• WAF.
• Load Balancer.

Application Network

تحتوي على:

• Odoo Server.
• Odoo Workers.
• Redis عند الحاجة.
• خدمات التكامل.

Database Network

تحتوي على:

• PostgreSQL.
• PostgreSQL Replica.
• Storage للبيانات الحساسة.

يسمح Reverse Proxy بالاتصال مع Odoo، ويسمح Odoo فقط بالوصول إلى PostgreSQL.

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

حماية تطبيقات SaaS

يمكن لمنصة SaaS استخدام التصميم التالي:

DMZ

• Public Load Balancer.
• API Gateway.
• WAF.
• Reverse Proxy.

Application

• Authentication Service.
• Billing Service.
• Backend APIs.
• Queue Workers.
• Notification Services.
• Docker أو Kubernetes Services.

Database

• PostgreSQL Cluster.
• Redis.
• Object Storage.
• Analytics Database.

يمكن تطبيق Micro-Segmentation بين الخدمات، بحيث لا تستطيع كل خدمة الوصول إلى جميع قواعد البيانات.

حماية تطبيقات التجارة الإلكترونية

تحتوي المتاجر على بيانات عملاء وطلبات ومدفوعات، لذلك تحتاج إلى عزل قوي.

يمكن وضع:

• CDN وWAF أمام DMZ.
• NGINX أو Load Balancer داخل DMZ.
• WooCommerce أو Magento أو التطبيق داخل Application Network.
• MySQL أو PostgreSQL داخل Database Network.
• Redis داخل شبكة داخلية.
• Backup داخل شبكة مستقلة.

يجب ألا تكون قاعدة بيانات المتجر متاحة مباشرة للعامة.

حماية تطبيقات Laravel

يمكن تقسيم تطبيق Laravel إلى:

DMZ

• NGINX Reverse Proxy.
• WAF.

Application

• Laravel Application Server.
• Queue Workers.
• Laravel Scheduler.
• Redis.

Database

• MySQL أو PostgreSQL.

يمكن السماح لخادم التطبيق بالوصول إلى قاعدة البيانات، بينما يمنع Reverse Proxy من الوصول إليها مباشرة.

حماية تطبيقات Node.js

يمكن تشغيل تطبيق Node.js على منافذ داخلية مثل 3000 أو 4000.

يستقبل Reverse Proxy الاتصال العام على 443، ثم يرسله إلى Node.js داخل Application Network.

إذا كان التطبيق يستخدم WebSocket، يجب السماح بالترويسات والاتصالات المطلوبة دون فتح منفذ التطبيق للإنترنت.

حماية تطبيقات ASP.NET

يمكن تشغيل تطبيق ASP.NET Core باستخدام Kestrel داخل Application Network.

يوضع NGINX أو HAProxy داخل DMZ لإدارة:

• HTTPS.
• الشهادات.
• أسماء النطاقات.
• Load Balancing.
• Rate Limiting.
• تمرير الطلبات.

يمكن وضع Microsoft SQL Server داخل Database Network والسماح لخادم التطبيق بالوصول إليه فقط.

حماية قواعد البيانات

يجب السماح بالاتصال بمنفذ PostgreSQL، وهو 5432 عادةً، من عناوين Application Servers المطلوبة فقط.

كما ينصح بـ:

• ضبط pg_hba.conf.
• استخدام TLS.
• إنشاء مستخدم محدود للتطبيق.
• منع حساب superuser.
• تطبيق نسخ احتياطي باستخدام pg_dump أو أدوات مناسبة.
• مراقبة الاتصالات والاستعلامات.
• تشغيل Replica عند الحاجة.

حماية MySQL وMariaDB

يمكن تقييد المنفذ 3306 ليكون متاحاً فقط من شبكة Application.

ينصح أيضاً بـ:

• استخدام مستخدم منفصل لكل تطبيق.
• تقييد المستخدم بعنوان IP محدد.
• تعطيل الحسابات غير المستخدمة.
• استخدام TLS.
• تطبيق نسخ احتياطية دورية.
• مراقبة الاستعلامات البطيئة.
• عدم فتح phpMyAdmin للعامة.

حماية Microsoft SQL Server

يجب عدم فتح SQL Server مباشرة على الإنترنت.

يمكن السماح بالوصول إليه فقط من:

• Application Server.
• Backup Server.
• Monitoring Server.
• شبكة الإدارة عبر VPN.

ينصح باستخدام:

• حسابات محدودة الصلاحيات.
• تشفير الاتصال.
• مراقبة تسجيل الدخول.
• نسخ احتياطية كاملة وتفاضلية.
• فصل ملفات البيانات والسجلات وفق التصميم.

شبكة الإدارة والوصول الآمن

إضافة إلى الطبقات الثلاث، يجب إنشاء شبكة إدارة منفصلة.

تحتوي على:

• Proxmox Web Interface.
• Jump Server.
• Monitoring.
• واجهات إدارة Firewall.
• SSH.
• RDP الإداري.
• أدوات الأتمتة.
• أنظمة Logging.

لا ينبغي إتاحة شبكة الإدارة عبر الإنترنت مباشرة.

يتم الوصول إليها من خلال VPN أو عناوين IP موثوقة.

استخدام Bastion Host أو Jump Server

يسمح Jump Server للإداريين بالدخول إلى نقطة مركزية آمنة، ثم الوصول منها إلى الخوادم الداخلية.

يساعد ذلك على:

• تقليل عدد مصادر الإدارة.
• تسجيل الجلسات.
• تطبيق MFA.
• منع SSH وRDP المباشر.
• التحكم في الصلاحيات.
• تسهيل التدقيق الأمني.

يجب حماية Jump Server بدرجة عالية لأنه يمثل بوابة الإدارة.

شبكة النسخ الاحتياطي وحمايتها

يفضل وضع خادم النسخ الاحتياطي داخل شبكة مستقلة.

💡 اقرأ أيضاً: Proxmox Backup Server في مرام بلاتفورم: حماية واستعادة احترافية

يمكن أن تحتوي على:

• Proxmox Backup Server.
• NAS.
• Storage Server.
• Backup Repository.
• أنظمة أرشفة.

يجب ألا تستطيع خوادم DMZ الوصول إلى شبكة Backup.

يسمح فقط بالاتصالات الضرورية من خوادم الإنتاج أو من Backup Server وفق طريقة النسخ المستخدمة.

حماية النسخ الاحتياطية من Ransomware

قد يحاول المهاجم حذف النسخ الاحتياطية بعد اختراق الشبكة.

لتقليل الخطر:

• افصل Backup Network.
• استخدم حسابات منفصلة.
• امنع الوصول من DMZ.
• لا تستخدم بيانات اعتماد الإدارة نفسها.
• طبق سياسات احتفاظ.
• احتفظ بنسخة خارج الموقع.
• اختبر الاستعادة.
• استخدم تشفيراً مناسباً.
• راقب عمليات الحذف والتغيير.

المراقبة والكشف عن التسلل

يمكن تخصيص شبكة مستقلة للمراقبة تحتوي على:

• Zabbix.
• Prometheus.
• Grafana.
• Wazuh.
• Uptime Kuma.
• Netdata.
• Central Logging.

يسمح لخادم Monitoring بالوصول إلى منافذ ووكلاء المراقبة فقط.

لا يجب أن تمنحه صلاحيات إدارية كاملة دون حاجة.

تسجيل الترافيك بين الطبقات

يجب تسجيل الاتصالات المهمة، خاصة:

• الاتصالات المرفوضة من DMZ.
• محاولات الوصول إلى Database.
• تغييرات Firewall.
• الاتصالات الإدارية.
• تسجيلات VPN.
• أخطاء التطبيقات.
• محاولات فحص المنافذ.
• الطلبات المشبوهة.

يمكن إرسال السجلات إلى:

• Wazuh.
• Graylog.
• Elasticsearch.
• Grafana Loki.
• SIEM.

استخدام IDS وIPS

يمكن تشغيل IDS/IPS لمراقبة الترافيك بين الإنترنت وDMZ أو بين بعض الشبكات الداخلية.

يساعد في اكتشاف:

• محاولات استغلال الثغرات.
• Port Scanning.
• Malware Traffic.
• Command and Control.
• اتصالات غير معتادة.
• هجمات على تطبيقات الويب.

من الأدوات الشائعة:

• Suricata.
• Snort.
• Zenarmor في بعض البيئات.
• حلول NDR وSIEM.

يجب ضبط القواعد بعناية لتقليل الإنذارات الخاطئة.

العزل الدقيق والتشفير وإدارة الأسرار

قد تحتوي Application Network على عشرات الخدمات.

بدلاً من السماح لها جميعاً بالتواصل، يمكن إنشاء سياسات دقيقة مثل:

• Frontend يصل إلى Backend API فقط.
• Backend يصل إلى Database.
• Worker يصل إلى Queue وDatabase.
• Authentication Service تصل إلى User Database.
• Billing Service تصل إلى Billing Database.
• Notification Service تصل إلى Mail Gateway فقط.

هذا يقلل تأثير اختراق خدمة واحدة.

فصل قواعد البيانات حسب التطبيق

يفضل عدم استخدام قاعدة بيانات واحدة وحساب إداري واحد لجميع التطبيقات.

يمكن تخصيص:

• Database منفصلة لكل مشروع.
• مستخدم منفصل لكل تطبيق.
• Schema مستقلة عند الحاجة.
• صلاحيات محددة.
• شبكة أو قواعد Firewall خاصة للخدمات الحساسة.

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

التشفير بين الطبقات

رغم أن الشبكات داخلية، يفضل تشفير الاتصالات الحساسة.

يمكن استخدام:

• HTTPS بين Reverse Proxy والتطبيق.
• TLS بين التطبيق وقاعدة البيانات.
• mTLS بين الخدمات.
• SSH للنقل الإداري.
• WireGuard بين المواقع.
• IPsec لربط الفروع.

التشفير الداخلي مهم خصوصاً في البيئات متعددة العملاء أو عند مرور الترافيك عبر بنية مشتركة.

إدارة الأسرار

لا ينبغي تخزين كلمات مرور قواعد البيانات ومفاتيح API داخل الكود أو الصور البرمجية.

يمكن استخدام:

• Environment Variables.
• Docker Secrets.
• Kubernetes Secrets مع حماية إضافية.
• HashiCorp Vault.
• Ansible Vault.
• Secret Managers.
• ملفات محمية بصلاحيات دقيقة.

يجب تدوير الأسرار دورياً وإلغاء أي مفتاح لم يعد مستخدماً.

التحكم في الاتصالات الخارجة

تركز بعض الشركات على الاتصالات الواردة وتنسى الاتصالات الخارجة.

يجب تقييد Egress Traffic حسب الحاجة.

مثلاً:

• قاعدة البيانات لا تحتاج إلى الوصول الكامل للإنترنت.
• خادم التطبيق قد يحتاج إلى API محددة فقط.
• خادم DMZ قد يحتاج إلى تحديثات أو DNS.
• Backup Server قد يحتاج إلى موقع تخزين خارجي.

يساعد التحكم في الاتصالات الخارجة على منع البرامج الضارة من التواصل مع خوادم خارجية.

خدمات الشبكة الداخلية

يمكن تشغيل DNS داخلي لحل أسماء الخوادم الخاصة.

مثلاً:

• app01.internal.company
• db01.internal.company
• backup01.internal.company

يجب عدم نشر هذه الأسماء والعناوين في DNS العام.

يمكن تشغيل DNS Resolver من خلال:

• OPNsense.
• pfSense.
• Windows DNS.
• BIND.
• CoreDNS.

DHCP أم Static IP؟

يفضل استخدام عناوين ثابتة للخوادم الأساسية مثل:

• Reverse Proxy.
• Application Servers.
• Databases.
• Firewalls.
• Monitoring.
• Backup.

يمكن استخدام DHCP Reservations عند وجود نظام إدارة عناوين منظم.

المهم هو توثيق كل عنوان ومنع التعارض.

الجدران النارية على مستوى النظام

يمكن إضافة Proxmox Firewall كطبقة حماية إضافية.

يمكن تطبيق السياسات على مستوى:

• Datacenter.
• Node.
• VM.
• Container.

مثلاً يمكن السماح لخادم Application بالوصول إلى Database محددة فقط، حتى إذا حدث خطأ في قواعد Firewall المركزي.

يسمى هذا النهج Defense in Depth.

استخدام Firewall داخل نظام التشغيل

يجب أيضاً تشغيل Firewall محلي على كل خادم.

يمكن استخدام:

• nftables.
• iptables.
• UFW.
• firewalld.
• Windows Defender Firewall.

يتم فتح المنافذ المطلوبة فقط من الشبكات المسموح بها.

لا يجب الاعتماد على Firewall الشبكي وحده.

حماية Proxmox

يجب وضع إدارة Proxmox داخل Management Network منفصلة.

ينصح بـ:

• عدم فتح المنفذ 8006 للعامة.
• الوصول عبر VPN.
• استخدام 2FA.
• تحديد صلاحيات المستخدمين.
• تحديث Proxmox.
• مراقبة محاولات الدخول.
• استخدام شهادات موثوقة.
• فصل شبكة Cluster.
• فصل Migration وStorage عند الحاجة.

عزل شبكة Proxmox Cluster

ينبغي فصل ترافيك Corosync وCluster عن شبكات التطبيقات والعملاء.

كما يفضل إنشاء شبكات مستقلة لـ:

• Management.
• Corosync.
• Live Migration.
• Storage.
• Backup.
• Customer Traffic.

يمنع ذلك ضغط التطبيقات من التأثير في استقرار Cluster.

التوافر العالي وموازنة التحميل

في البيئات التي تتطلب استمرارية عالية، يمكن تشغيل:

• Firewall أساسي واحتياطي.
• Reverse Proxy مزدوج.
• Application Servers متعددة.
• Database Primary وReplica.
• Proxmox Cluster.
• Storage عالي التوفر.
• Proxmox Backup Server منفصل.

يمكن استخدام:

• CARP.
• VRRP.
• Keepalived.
• HAProxy Health Checks.
• Database Replication.
• Proxmox HA.

يجب اختبار الفشل الفعلي، وليس الاكتفاء بوجود مكونات احتياطية.

Load Balancing بين خوادم التطبيق

يمكن تشغيل أكثر من نسخة من التطبيق داخل Application Network.

يقوم Load Balancer بتوزيع الطلبات بينها باستخدام خوارزميات مثل:

• Round Robin.
• Least Connections.
• Source Hash.
• Weighted Balancing.

يجب تصميم الجلسات بطريقة تسمح بالتوزيع، إما باستخدام Sticky Sessions أو تخزين الجلسة في Redis أو قاعدة مشتركة.

حماية بيئات Development وStaging

يجب عدم خلط Development وStaging مع Production.

💡 اقرأ أيضاً: كيف تبني بيئة تطوير وStaging وProduction داخل Proxmox؟

يمكن تخصيص شبكات مستقلة:

• Development DMZ.
• Development Application.
• Development Database.
• Staging Networks.
• Production Networks.

وقد يكون التصميم الأبسط هو إنشاء VLAN منفصلة لكل بيئة.

يمنع ذلك:

• استخدام بيانات Production في الاختبارات.
• فتح خدمة تجريبية للعامة.
• تأثير خطأ مطور في النظام الحقيقي.
• مشاركة الأسرار بين البيئات.

الوصول الآمن والحماية المتقدمة

يمكن للموظفين الوصول إلى الأنظمة الداخلية عبر:

• WireGuard.
• OpenVPN.
• IPsec.

يتم تحديد الشبكات التي يمكن لكل مجموعة الوصول إليها.

مثلاً:

• المطور يصل إلى Development فقط.
• فريق DevOps يصل إلى Application وManagement.
• مسؤول قاعدة البيانات يصل إلى Database.
• المحاسبة تصل إلى ERP فقط.
• الدعم يصل إلى لوحة العملاء دون قواعد البيانات.

ربط فروع الشركة

يمكن ربط الفروع بالبنية السحابية عبر Site-to-Site VPN.

يصبح بإمكان الفرع الوصول إلى:

• ERP.
• File Server.
• تطبيقات داخلية.
• قواعد بيانات وفق الصلاحيات.
• خدمات VoIP.

دون تعريض الخدمات للإنترنت العام.

استخدام Zero Trust

يتوافق تقسيم DMZ وApplication وDatabase مع مبادئ Zero Trust.

يعتمد Zero Trust على:

• عدم الثقة بأي اتصال افتراضياً.
• التحقق من الهوية.
• منح أقل صلاحية.
• تقييد الاتصال حسب الخدمة.
• مراقبة مستمرة.
• مصادقة قوية.
• تشفير الترافيك.
• تسجيل الأحداث.

لا يعني وجود الخادم داخل الشبكة الخاصة أنه موثوق تلقائياً.

حماية APIs

يمكن وضع API Gateway داخل DMZ، بينما تعمل خدمات API الفعلية داخل Application Network.

يوفر API Gateway:

• Authentication.
• Rate Limiting.
• Request Validation.
• Logging.
• Routing.
• TLS Termination.
• API Keys.
• Version Management.

لا يجب فتح الخدمات المصغرة الداخلية مباشرة على الإنترنت.

Rate Limiting

يمكن تفعيل Rate Limiting على Reverse Proxy أو API Gateway لحماية:

• تسجيل الدخول.
• إنشاء الحسابات.
• استعادة كلمة المرور.
• إرسال OTP.
• واجهات البحث.
• APIs العامة.

يساعد ذلك على تقليل:

• Brute Force.
• Bots.
• Abuse.
• استهلاك الموارد.
• بعض هجمات حجب الخدمة البسيطة.

حماية لوحة الإدارة

يجب عدم نشر لوحات الإدارة بالطريقة نفسها التي تنشر بها الواجهة العامة.

يمكن حمايتها من خلال:

• VPN.
• IP Allowlist.
• MFA.
• Identity-Aware Proxy.
• نطاق منفصل.
• Basic Authentication كطبقة إضافية.
• عدم إتاحتها للعامة عند عدم الحاجة.

استخدام CDN أمام DMZ

يمكن وضع CDN أمام Reverse Proxy للحصول على:

• تخزين مؤقت.
• حماية DDoS.
• تسريع المحتوى.
• إخفاء عنوان الخادم الأصلي.
• WAF.
• تقليل الترافيك المباشر.

يصبح المسار:

المستخدم ← CDN ← DMZ Reverse Proxy ← Application ← Database

يجب تقييد Reverse Proxy لقبول الترافيك من مصادر CDN فقط عندما يكون ذلك مناسباً.

المراقبة والنسخ الاحتياطي والتعافي

إضافة إلى الأمان، يجب مراقبة أداء كل طبقة.

DMZ

• عدد الطلبات.
• اتصالات HTTPS.
• أخطاء 4xx و5xx.
• زمن الاستجابة.
• استهلاك الشبكة.

Application

• CPU وRAM.
• عدد Workers.
• Queue Length.
• أخطاء التطبيق.
• زمن تنفيذ الطلبات.

Database

• عدد الاتصالات.
• الاستعلامات البطيئة.
• استخدام الذاكرة.
• مساحة التخزين.
• Replication Lag.
• Locks.

النسخ الاحتياطي لكل طبقة

يجب حماية:

• إعدادات Firewall.
• إعدادات Reverse Proxy.
• ملفات التطبيق.
• Docker Volumes.
• قواعد البيانات.
• ملفات المستخدمين.
• مفاتيح التشفير.
• إعدادات الشبكات.

يمكن استخدام Proxmox Backup Server لحماية الآلات الافتراضية، مع نسخ منطقية إضافية لقواعد البيانات.

اختبار الاستعادة

لا يكفي أن تظهر عمليات النسخ الاحتياطي على أنها ناجحة.

يجب اختبار:

• استعادة Application Server.
• استعادة قاعدة بيانات.
• استعادة إعداد Reverse Proxy.
• استعادة Firewall.
• تشغيل نسخة معزولة للاختبار.
• زمن العودة إلى الخدمة.

يحدد ذلك مدى واقعية خطة التعافي من الكوارث.

RPO وRTO

عند تصميم النسخ الاحتياطي يجب تحديد:

RPO

مقدار البيانات الذي يمكن للشركة تحمل فقدانه.

إذا كان RPO ساعة واحدة، فيجب إنشاء نسخ أو Replication تسمح بخسارة ساعة كحد أقصى.

RTO

المدة المقبولة لإعادة تشغيل الخدمة بعد العطل.

قد يكون RTO:

• دقائق للخدمات الحساسة.
• ساعات للخدمات المتوسطة.
• يوماً للأنظمة غير الحرجة.

يؤثر RPO وRTO في تكلفة وتصميم البنية.

أخطاء شائعة في التصميم

من أكثر الأخطاء شيوعاً:

• وضع DMZ وApplication وDatabase في شبكة واحدة.
• فتح قاعدة البيانات للإنترنت.
• السماح من DMZ إلى جميع الشبكات.
• استخدام قاعدة Allow Any بين VLAN.
• استخدام الحساب الإداري داخل التطبيق.
• عدم تشفير الاتصال بقاعدة البيانات.
• فتح SSH وRDP للعامة.
• وضع النسخ الاحتياطية في شبكة الإنتاج.
• عدم مراقبة الترافيك الداخلي.
• عدم توثيق المنافذ والقواعد.
• ترك قواعد مؤقتة مفتوحة.
• عدم فصل Development عن Production.
• الاعتماد على VLAN دون Firewall.
• عدم اختبار الاستعادة.

خطوات تصميم البنية الصحيحة

حصر مكونات التطبيق

يجب تحديد:

• ما الذي يستقبل اتصالاً من الإنترنت؟
• ما الخدمات الخلفية؟
• ما قواعد البيانات؟
• ما الأنظمة الإدارية؟
• ما الاتصالات الخارجية المطلوبة؟

تصنيف البيانات

حدد الخدمات التي تحتوي على:

• بيانات شخصية.
• معلومات مالية.
• بيانات عملاء.
• أسرار تجارية.
• مفاتيح API.
• بيانات تشغيلية حساسة.

إنشاء الشبكات

أنشئ شبكات منفصلة لـ:

• DMZ.
• Application.
• Database.
• Management.
• Backup.
• Monitoring.

تحديد تدفقات الاتصال

وثق كل اتصال مطلوب مع:

• المصدر.
• الوجهة.
• البروتوكول.
• المنفذ.
• سبب السماح.
• المسؤول عن الخدمة.

تطبيق Default Deny

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

اختبار التصميم

اختبر:

• الوصول الشرعي.
• منع الاتصالات غير المسموحة.
• Failover.
• Backup.
• Monitoring.
• استعادة الخدمة.

توثيق قواعد Firewall

ينبغي أن تحتوي كل قاعدة على وصف واضح.

مثلاً:

• Allow Reverse Proxy to Odoo Production.
• Allow Odoo to PostgreSQL.
• Allow Monitoring to Application Nodes.
• Allow PBS Backup Traffic.
• Deny DMZ to Database.

يساعد التوثيق على مراجعة القواعد وإزالة الصلاحيات غير المستخدمة.

مراجعة الصلاحيات دورياً

مع مرور الوقت، تتم إضافة تطبيقات وخوادم وقواعد جديدة.

يجب إجراء مراجعات دورية من أجل:

• حذف القواعد القديمة.
• إزالة الخوادم المتوقفة.
• إغلاق المنافذ غير المستخدمة.
• تحديث عناوين الإدارة.
• مراجعة مستخدمي VPN.
• تدوير كلمات المرور والمفاتيح.
• تحديث مخطط الشبكة.

قابلية التوسّع والانتقال إلى Dedicated

يمكن البدء بتصميم بسيط يحتوي على:

• Reverse Proxy واحد.
• Application Server واحد.
• Database Server واحد.

ثم التوسع إلى:

• Load Balancer.
• عدة Application Servers.
• Database Replica.
• Firewall مزدوج.
• Cluster Proxmox.
• Proxmox Backup Server.
• Monitoring مركزي.
• شبكة Storage مستقلة.

يمكن زيادة CPU وRAM وNVMe وإنشاء خوادم جديدة دون تغيير الأساس الأمني للبنية.

الانتقال إلى Dedicated Server

عند نمو المشروع، يمكن نقل بعض الطبقات إلى Dedicated Servers.

مثلاً:

• نقل قاعدة البيانات إلى خادم مخصص.
• نقل Application Cluster إلى Dedicated.
• إبقاء Reverse Proxy وFirewall في موقعهما.
• تخصيص شبكة Storage مستقلة.
• توزيع الخدمة على عدة عقد.

إذا تم تصميم VLAN وLayer 3 وFirewall بصورة صحيحة منذ البداية، يصبح الانتقال أكثر سهولة دون إعادة بناء التطبيق بالكامل.

لماذا مرام بلاتفورم مناسبة لهذا التصميم؟

توفر مرام بلاتفورم بيئة Proxmox خاصة تسمح للشركات ببناء بنية تحتية متعددة الطبقات داخل منصة واحدة.

وتُسهّل مرام بلاتفورم بناء شبكات DMZ وApplication وDatabase معزولة عبر VLAN وجدارٍ ناري مركزي وProxmox SDN، ما يمنح شركتك تصميماً أمنياً احترافياً قابلاً للتوسّع.

💡 اقرأ أيضاً: كيف تبني مركز بيانات افتراضي خاص لشركتك؟

يمكن إنشاء:

• DMZ Network.
• Application Network.
• Database Network.
• Management Network.
• Backup Network.
• VLAN مستقلة لكل طبقة.
• Firewall باستخدام OPNsense أو pfSense.
• MikroTik CHR للتوجيه.
• Reverse Proxy.
• Load Balancer.
• WireGuard VPN.
• Proxmox Backup Server.
• Monitoring Server.
• خوادم Linux وWindows.

هذا يمنح الشركات مستوى أعلى من التحكم والعزل مقارنة بتشغيل جميع الخدمات على VPS واحد أو شبكة مشتركة.

الخلاصة

يعد فصل البنية التحتية إلى شبكات DMZ وApplication وDatabase من أهم الخطوات لحماية تطبيقات الشركات ومنع أي اختراق محدود من التحول إلى اختراق شامل لجميع الأنظمة.

تستقبل DMZ الاتصالات العامة وتحتوي على Reverse Proxy وWAF وLoad Balancer، بينما تعمل خوادم التطبيقات داخل شبكة داخلية معزولة. أما قواعد البيانات، فتوضع داخل شبكة أكثر حماية لا يمكن الوصول إليها إلا من خوادم التطبيقات المصرح لها.

عند دمج هذا التصميم مع VLAN وLayer 3 Routing وقواعد Default Deny وVPN وProxmox Firewall، تحصل الشركة على بنية أمنية متعددة الطبقات تقلل مساحة الهجوم وتحمي البيانات الحساسة.

توفر مرام بلاتفورم البيئة المناسبة لبناء هذا التصميم داخل منصة Proxmox خاصة، مع إمكانية تشغيل Firewall وReverse Proxy وقواعد البيانات والنسخ الاحتياطي والمراقبة ضمن شبكات مستقلة وقابلة للتوسع.

إذا كانت شركتك تدير نظام ERP أو Odoo أو منصة SaaS أو متجراً إلكترونياً أو تطبيقاً يحتوي على بيانات عملاء حساسة، فإن تصميم شبكات DMZ وApplication وDatabase داخل مرام بلاتفورم يمنح مشروعك أساساً قوياً للأمان والاستقرار والنمو المستقبلي.