يتطلب الضابط 5.2.3 من المجال الخامس لإطار الأمن السيبراني الصادر عن البنك المركزي السعودي توثيق بنية DMZ المجال الخامس ساما لتقسيم الشبكة في الخدمات المواجهة للإنترنت، وهو متطلب حاسم لمعالجات الدفع والبنوك والشركات المالية الرقمية التي تدير بوابات دفع أو واجهات برمجية مفتوحة. لكن معظم التصاميم التي تُقدّم للمراجعة تُظهر المكونات — خوادم الويب، وخوادم التطبيقات، وقواعد البيانات — دون أن تُظهر بوضوح كيف تُصفّى وتُفحص وتُوجّه حركة البيانات الواردة من الإنترنت قبل وصولها إلى بيئة بيانات حاملي البطاقات.
هذا الغياب في التوثيق يؤدي إلى ملاحظات متكررة من مراجعي البنك المركزي السعودي ومدققي PCI DSS، ويؤخر الاعتماد والتشغيل. المراجعون لا يبحثون فقط عن وجود جدران الحماية، بل عن توثيق واضح لثلاثة أنماط محددة لحركة البيانات: حركة البيانات الواردة من الإنترنت، وحركة البيانات الصادرة من بيئة الإنتاج، وحركة البيانات الإدارية والصيانة. كل نمط يتطلب مستوى مختلفاً من التصفية والفحص والتسجيل، وكل نمط يجب أن يُوثّق بطريقة تُظهر الامتثال للمجال الخامس من إطار البنك المركزي السعودي والمتطلب الأول من PCI DSS.
هذا المقال يشرح الأنماط الثلاثة الإلزامية، والفجوات الشائعة في التوثيق، وكيفية إعداد مخططات تلبي توقعات المراجعين.
لماذا يركز المراجعون على أنماط حركة البيانات وليس المكونات فقط
الضابط 5.2.3 من المجال الخامس يتطلب تقسيم الشبكة بحيث تُعزل الخدمات المواجهة للإنترنت عن الأنظمة الداخلية الحساسة. لكن التقسيم ليس مجرد وضع جدار حماية بين منطقتين؛ بل هو تصميم يُحدد بدقة ما يُسمح بالمرور، وما يُفحص، وما يُسجّل، وما يُحظر.
المراجعون يريدون أن يروا أن كل طلب وارد من الإنترنت يمر بسلسلة من نقاط الفحص قبل أن يصل إلى أي نظام يُخزّن أو يُعالج بيانات حاملي البطاقات. هذا يعني توثيق:
- نقاط الدخول: أين تدخل حركة البيانات الخارجية إلى بيئتكم.
- نقاط الفحص: أين تُفحص الطلبات للكشف عن الهجمات أو البيانات الضارة.
- نقاط التصفية: أين تُطبّق قواعد جدار الحماية لحظر الحركة غير المصرح بها.
- نقاط التسجيل: أين تُسجّل الأحداث للمراقبة والتدقيق.
- نقاط العزل: أين تُفصل بيئة بيانات حاملي البطاقات عن باقي الشبكة.
بدون توثيق واضح لهذه النقاط في كل نمط من أنماط حركة البيانات، لا يمكن للمراجع أن يتحقق من أن التصميم يحقق الهدف الأساسي للضابط 5.2.3: منع الوصول المباشر من الإنترنت إلى بيئة بيانات حاملي البطاقات.
النمط الأول: حركة البيانات الواردة من الإنترنت إلى بوابة الدفع
هذا هو النمط الأكثر أهمية والأكثر تعقيداً. يشمل الطلبات الواردة من المتسوقين أو التطبيقات أو الأنظمة الخارجية التي تطلب معالجة دفع أو استعلام عن حالة معاملة.
ما يجب توثيقه
يجب أن يُظهر المخطط الطبقات التالية بالترتيب:
- طبقة الحماية من هجمات الحرمان من الخدمة: جهاز أو خدمة تُخفف من هجمات DDoS قبل وصول الحركة إلى جدار الحماية الأول.
- جدار الحماية الخارجي: يُصفّي الحركة بناءً على عناوين IP والمنافذ والبروتوكولات المسموح بها. يجب أن يُوثّق المخطط القواعد المطبقة: مثلاً، السماح فقط بـ HTTPS على المنفذ 443 من نطاقات IP محددة، وحظر كل شيء آخر.
- منطقة DMZ الخارجية: تحتوي على خوادم الويب أو موازنات الحمل أو بوابات API التي تستقبل الطلبات. هذه الخوادم لا تحتوي على بيانات حاملي البطاقات ولا تتصل مباشرة بقواعد البيانات.
- جهاز فحص التطبيقات (WAF): يفحص محتوى الطلبات للكشف عن هجمات حقن SQL وهجمات البرمجة النصية عبر المواقع وغيرها من الهجمات على مستوى التطبيق. يجب أن يُوثّق المخطط أن WAF يُسجّل كل طلب مشبوه ويحظره قبل أن يصل إلى خوادم التطبيقات.
- جدار الحماية الداخلي: يُصفّي الحركة من DMZ الخارجية إلى منطقة التطبيقات الداخلية. يجب أن يُسمح فقط بالاتصالات من خوادم محددة في DMZ إلى خوادم تطبيقات محددة على منافذ محددة.
- منطقة التطبيقات: تحتوي على خوادم التطبيقات التي تُعالج منطق الأعمال. هذه الخوادم تتصل بقواعد البيانات لكنها لا تُعرض مباشرة للإنترنت.
- جدار حماية قاعدة البيانات: يُصفّي الحركة من منطقة التطبيقات إلى منطقة قواعد البيانات. يجب أن يُسمح فقط بالاستعلامات من خوادم تطبيقات محددة إلى قواعد بيانات محددة.
- منطقة قواعد البيانات: تحتوي على قواعد البيانات التي تُخزّن بيانات حاملي البطاقات. هذه المنطقة معزولة تماماً عن الإنترنت ولا يمكن الوصول إليها إلا عبر الطبقات السابقة.
الفجوات الشائعة
- عدم توثيق WAF: كثير من التصاميم تُظهر جدران الحماية لكنها لا تُظهر جهاز فحص التطبيقات، مما يُثير تساؤلات المراجعين حول كيفية الحماية من هجمات التطبيقات.
- عدم وضوح القواعد: المخططات تُظهر خطوطاً بين المناطق دون توضيح القواعد المطبقة على كل جدار حماية.
- السماح بحركة بيانات واسعة: قواعد جدار الحماية تسمح بـ "any to any" بين منطقتين بدلاً من تحديد الخوادم والمنافذ بدقة.
النمط الثاني: حركة البيانات الصادرة من بيئة الإنتاج إلى الإنترنت
هذا النمط يشمل الاتصالات الصادرة من بيئة الإنتاج إلى أنظمة خارجية، مثل إرسال المعاملات إلى شبكات البطاقات، أو استدعاء واجهات برمجية لخدمات خارجية، أو إرسال إشعارات.
ما يجب توثيقه
يجب أن يُظهر المخطط:
- الخوادم المصدر: أي الخوادم في منطقة التطبيقات أو قواعد البيانات تحتاج إلى إرسال بيانات إلى الخارج.
- جدار الحماية الصادر: يُصفّي الحركة الصادرة بناءً على الوجهة والمنفذ والبروتوكول. يجب أن يُسمح فقط بالاتصالات إلى عناوين IP محددة لشبكات البطاقات أو مزودي الخدمات الخارجيين.
- خادم وكيل (Proxy): في بعض التصاميم، تمر كل الحركة الصادرة عبر خادم وكيل يُسجّل ويفحص الطلبات قبل إرسالها إلى الإنترنت.
- التشفير: يجب أن يُوثّق المخطط أن كل الاتصالات الصادرة التي تحتوي على بيانات حساسة تستخدم TLS 1.2 أو أعلى.
الفجوات الشائعة
- السماح بحركة صادرة غير محدودة: جدار الحماية يسمح لأي خادم في بيئة الإنتاج بالاتصال بأي وجهة على الإنترنت، مما يزيد من خطر تسريب البيانات أو الاتصال بخوادم قيادة وتحكم في حالة الاختراق.
- عدم توثيق الوجهات: المخطط لا يُحدد إلى أين تذهب الحركة الصادرة، مما يجعل من الصعب على المراجع التحقق من أن الاتصالات مشروعة.
النمط الثالث: حركة البيانات الإدارية والصيانة
هذا النمط يشمل الوصول الإداري إلى الخوادم وأجهزة الشبكة لأغراض التكوين والصيانة والمراقبة. هذا النمط حساس للغاية لأن الوصول الإداري يمنح صلاحيات واسعة ويمكن أن يُستغل للوصول إلى بيانات حاملي البطاقات.
ما يجب توثيقه
يجب أن يُظهر المخطط:
- شبكة الإدارة المنفصلة: منطقة شبكة منفصلة تماماً عن شبكة الإنتاج، تُستخدم فقط للوصول الإداري.
- خادم القفز (Jump Server): نقطة دخول واحدة للوصول الإداري، تُسجّل كل جلسة وتُطبّق مصادقة متعددة العوامل.
- جدار حماية الإدارة: يُصفّي الحركة من شبكة الإدارة إلى أجهزة الإنتاج. يجب أن يُسمح فقط بالبروتوكولات الإدارية (SSH, RDP) من خادم القفز إلى أجهزة محددة.
- التسجيل المركزي: يجب أن يُوثّق المخطط أن كل جلسة إدارية تُسجّل وتُرسل إلى نظام تسجيل مركزي للمراجعة.
الفجوات الشائعة
- الوصول الإداري من الإنترنت: السماح بالوصول الإداري مباشرة من الإنترنت، حتى لو كان محمياً بكلمة مرور قوية، يُعتبر خطراً كبيراً ولا يُقبل في المراجعات.
- عدم فصل شبكة الإدارة: استخدام نفس الشبكة للإنتاج والإدارة، مما يعني أن اختراق خادم إنتاج واحد يمكن أن يمنح الوصول إلى كل الأجهزة الأخرى.
- عدم تسجيل الجلسات الإدارية: عدم توثيق كيفية تسجيل ومراقبة الوصول الإداري، مما يجعل من الصعب اكتشاف الوصول غير المصرح به.
كيفية إعداد التوثيق الذي يلبي توقعات المراجعين
لإعداد توثيق يلبي متطلبات الضابط 5.2.3 من المجال الخامس والمتطلب الأول من PCI DSS، اتبع هذا الترتيب:
1. ارسم مخططاً منفصلاً لكل نمط
لا تحاول وضع كل شيء في مخطط واحد. أعد مخططاً منفصلاً لكل نمط من الأنماط الثلاثة، بحيث يُظهر كل مخطط بوضوح مسار حركة البيانات من نقطة الدخول إلى نقطة الخروج، مع كل نقاط الفحص والتصفية في الطريق.
2. وثّق القواعد المطبقة على كل جدار حماية
لكل جدار حماية في المخطط، أضف جدولاً يُحدد القواعد المطبقة: المصدر، الوجهة، المنفذ، البروتوكول، الإجراء (السماح أو الحظر). هذا يُظهر للمراجع أنك لا تعتمد على التكوين الافتراضي بل قمت بتصميم قواعد محددة لكل حركة بيانات.
3. حدد نقاط التسجيل والمراقبة
لكل نقطة فحص أو تصفية، وثّق ما يُسجّل وأين تُرسل السجلات. المراجعون يريدون أن يروا أن كل حركة بيانات مشبوهة أو محظورة تُسجّل وتُراقب.
4. أظهر كيف تُعزل بيئة بيانات حاملي البطاقات
تأكد من أن المخطط يُظهر بوضوح أن منطقة قواعد البيانات التي تحتوي على بيانات حاملي البطاقات معزولة تماماً عن الإنترنت ولا يمكن الوصول إليها إلا عبر طبقات متعددة من التصفية والفحص.
5. راجع التصميم مع فريق الأمن قبل التنفيذ
قبل البدء في بناء البنية التحتية، راجع التصميم مع فريق الأمن السيبراني للتأكد من أنه يلبي المتطلبات ويُعالج التهديدات المحتملة. التغييرات في مرحلة التصميم أقل تكلفة بكثير من التغييرات بعد التنفيذ.
الأخطاء التي تؤدي إلى رفض التصميم
بعض الأخطاء تؤدي إلى رفض التصميم من قبل المراجعين وتتطلب إعادة تصميم كاملة:
- السماح بالوصول المباشر من الإنترنت إلى خوادم التطبيقات أو قواعد البيانات: حتى لو كان الوصول محمياً بمصادقة، يجب أن يمر عبر DMZ وطبقات فحص.
- استخدام جدار حماية واحد فقط: التصميم يجب أن يتضمن على الأقل جدارين ناريين بين الإنترنت وبيئة بيانات حاملي البطاقات، مع منطقة DMZ بينهما.
- عدم وجود جهاز فحص التطبيقات: الاعتماد فقط على جدران الحماية دون WAF لا يكفي للحماية من هجمات التطبيقات.
- السماح بحركة بيانات واسعة بين المناطق: قواعد جدار الحماية يجب أن تتبع مبدأ الحد الأدنى من الصلاحيات، بحيث تسمح فقط بالحركة الضرورية للعمليات.
كيف تساعد سيزو في مراجعة البنية الأمنية
عندما تحتاج إلى التأكد من أن تصميم بوابة الدفع أو البنية التحتية المالية يلبي متطلبات البنك المركزي السعودي ومعايير PCI DSS قبل التنفيذ أو المراجعة، نقدم خدمة مراجعة البنية الأمنية التي تراجع أمن تصاميم الأنظمة والشبكات الجديدة والقائمة — التقسيم، والهوية، وتدفقات البيانات، والتكامل، والمرونة — وتوصي بتحسينات عملية.
تشمل العملية أربع مراحل: الجمع (المخططات وتدفقات البيانات ومستندات التصميم)، والنمذجة (التهديدات على المكونات والتدفقات الرئيسية)، والتقييم (الضوابط مقابل مبادئ التصميم الآمن)، والمشورة (الخيارات والمفاضلات والإجراءات المتفق عليها).
تشمل المخرجات تقرير مراجعة البنية، ونمذجة التهديدات للتدفقات الرئيسية، وتوصيات تصميم مرتبة الأولويات، وأنماط أمنية مرجعية. تغطي المراجعة تقسيم الشبكة ومناطقها، وحدود الهوية والثقة، ومراجعة تدفق البيانات والتشفير، والتكامل مع الأطراف الثالثة وواجهات البرمجة، وتصميم المرونة والتعافي.
المدة النموذجية للمراجعة هي 2–4 أسابيع لكل نظام، وتغطي المراجعة متطلبات إطار الأمن السيبراني للبنك المركزي السعودي والضوابط الأساسية للمركز الوطني للأمن السيبراني.
