عند إعداد نطاق اختبار الاختراق PCI DSS للتقييم السنوي، تحدد العديد من شركات المدفوعات والمستحوذين ومعالجي المعاملات السعودية النطاق على أنه "تطبيق الدفع" أو "بوابة الدفع" أو "واجهة برمجة المعاملات"، ثم تسلمه إلى المختبر. لكن متطلب PCI DSS v4.0 رقم 11.4.2 الصادر عن مجلس معايير أمن صناعة بطاقات الدفع لا يطلب اختبار تطبيق واحد — بل يطلب اختبار تدفق بيانات حامل البطاقة بالكامل من نقطة الالتقاط عبر النقل والمعالجة والتخزين حتى الحذف أو الخروج. عندما يصل المدقق لمراجعة الأدلة، يفحص ما إذا كان بيان النطاق وتقرير اختبار الاختراق يغطيان كل مكون يلمس بيانات حامل البطاقة — وإذا اقتصر الاختبار على نقطة نهاية واحدة، فإن المتطلب يُعتبر غير مستوفٍ بغض النظر عن جودة الاختبار نفسه.
يشرح هذا المقال الأخطاء الأربعة الأكثر شيوعًا في تحديد نطاق اختبار الاختراق لمتطلب 11.4.2، وكيفية تجنب كل منها، والخطوات العملية لرسم تدفق البيانات قبل وصول المختبر.
الخطأ الأول: تحديد النطاق على أنه "تطبيق الدفع" دون تحديد التدفق
ما يحدث
يصل بيان النطاق إلى المختبر على شكل عنوان URL واحد أو اسم نظام واحد — "تطبيق الدفع الإلكتروني" أو "بوابة المعاملات" — دون وصف لما يحدث قبل وصول البيانات إلى هذا التطبيق أو بعد مغادرتها. يختبر المختبر التطبيق المحدد، ويصدر تقريرًا، لكن المدقق يطلب رؤية كيف اختُبرت نقطة البيع، وقناة النقل المشفرة، وقاعدة البيانات، وواجهة البرمجة التي تُرسل البيانات إلى المعالج الخارجي — وكلها خارج النطاق المحدد.
لماذا يبطل المتطلب
المتطلب 11.4.2 يطلب اختبار "جميع المكونات التي تدعم وظائف بيانات حامل البطاقة" — وهذا يعني كل نقطة دخول وخروج، وكل طبقة معالجة، وكل مخزن مؤقت أو دائم. إذا لم يُختبر أي مكون في التدفق، فإن الاختبار ناقص.
ما يجب فعله بدلًا من ذلك
قبل كتابة بيان النطاق، ارسموا مسار البيانات الكامل من أول نقطة التقاط (نقطة البيع، أو نموذج الويب، أو واجهة البرمجة) حتى آخر نقطة (قاعدة البيانات، أو الإرسال إلى شبكة البطاقات، أو الحذف الآمن). ثم حددوا كل مكون في هذا المسار — الخوادم، وواجهات البرمجة، وقواعد البيانات، وأجهزة التوجيه، وأنظمة إدارة المفاتيح — وأدرجوها جميعًا في بيان النطاق.
الخطأ الثاني: افتراض أن اختبار نقطة النهاية يغطي التدفق بالكامل
ما يحدث
تفترض بعض الشركات أن اختبار تطبيق الويب أو واجهة البرمجة التي تستقبل بيانات حامل البطاقة يكفي لتغطية المتطلب، لأن "كل شيء يمر عبر هذه الواجهة". لكن المدقق يسأل: هل اختُبر التشفير أثناء النقل بين الواجهة وقاعدة البيانات؟ هل اختُبرت صلاحيات الوصول إلى الجداول التي تخزن البيانات؟ هل اختُبرت واجهة البرمجة التي تُرسل البيانات إلى المعالج الخارجي؟
لماذا يبطل المتطلب
اختبار نقطة النهاية يكشف الثغرات في تلك النقطة فقط — مثل حقن SQL أو ضعف المصادقة — لكنه لا يكشف ضعف التشفير في قناة النقل الداخلية، أو تخزين البيانات غير المشفرة في ذاكرة التخزين المؤقت، أو صلاحيات الوصول المفرطة إلى قاعدة البيانات، أو ضعف التحقق من الشهادات في الاتصالات الخارجية. كل هذه المكونات جزء من تدفق البيانات، ويجب اختبارها.
ما يجب فعله بدلًا من ذلك
قسّموا التدفق إلى ثلاث قطاعات:
- الدخول: نقاط الالتقاط (نقطة البيع، نموذج الويب، واجهة البرمجة الخارجية) وقنوات النقل إلى البيئة الداخلية.
- المعالجة: الخوادم التي تعالج البيانات، وقواعد البيانات المؤقتة، ومنطق التطبيق، وأنظمة إدارة المفاتيح.
- الخروج والتخزين: قواعد البيانات الدائمة، وواجهات البرمجة التي تُرسل البيانات إلى شبكات البطاقات أو المعالجين، وآليات الحذف الآمن.
حددوا في بيان النطاق المكونات في كل قطاع، واطلبوا من المختبر اختبار كل قطاع على حدة.
الخطأ الثالث: استبعاد المكونات "الموثوقة" من النطاق
ما يحدث
تستبعد بعض الشركات من النطاق المكونات التي تعتبرها "آمنة بالتصميم" — مثل قاعدة البيانات التي "تُدار من قبل فريق قواعد البيانات ولها صلاحيات محدودة"، أو قناة النقل الداخلية التي "تستخدم TLS دائمًا"، أو واجهة البرمجة الخارجية التي "يديرها المعالج وليس نحن". لكن المدقق يطلب دليلًا على أن هذه المكونات اختُبرت فعليًا — لا افتراضًا بأنها آمنة.
لماذا يبطل المتطلب
المتطلب 11.4.2 لا يستثني المكونات بناءً على الثقة أو الملكية — بل يطلب اختبار كل مكون في التدفق. حتى لو كانت قاعدة البيانات تُدار بشكل جيد، فإن اختبار الاختراق قد يكشف عن صلاحيات مفرطة لحساب التطبيق، أو ضعف في سياسة كلمات المرور، أو إعدادات تدقيق ناقصة. وحتى لو كانت واجهة البرمجة الخارجية يديرها طرف ثالث، فإن الشركة مسؤولة عن اختبار كيفية اتصالها بهذه الواجهة — التحقق من الشهادات، وإدارة الجلسات، ومعالجة الأخطاء.
ما يجب فعله بدلًا من ذلك
أدرجوا في بيان النطاق جميع المكونات التي تلمس بيانات حامل البطاقة، بغض النظر عن من يديرها أو مدى ثقتكم بها. بالنسبة للمكونات التي يديرها طرف ثالث، حددوا في النطاق الواجهات والاتصالات التي تتحكمون بها — مثل كيفية استدعاء واجهة البرمجة، وكيفية تخزين بيانات الاعتماد، وكيفية معالجة الاستجابات.
الخطأ الرابع: عدم توثيق تدفق البيانات في بيان النطاق
ما يحدث
يصل بيان النطاق إلى المختبر على شكل قائمة بالمكونات — عناوين IP، وأسماء نطاقات، وأسماء أنظمة — دون وصف لكيفية تدفق البيانات بينها. يختبر المختبر كل مكون على حدة، لكن المدقق يسأل: كيف تنتقل البيانات من المكون الأول إلى الثاني؟ ما هي البروتوكولات المستخدمة؟ أين تُخزن البيانات مؤقتًا؟ هل هناك نقاط تحويل أو ترجمة؟
لماذا يبطل المتطلب
المدقق يحتاج إلى دليل على أن اختبار الاختراق غطى التدفق وليس فقط المكونات. إذا لم يوثق بيان النطاق كيفية انتقال البيانات، فلا يمكن للمدقق التحقق من أن الاختبار غطى كل نقطة انتقال — وهذه النقاط هي غالبًا حيث تحدث الثغرات (مثل تخزين البيانات غير المشفرة في ذاكرة التخزين المؤقت، أو استخدام بروتوكول قديم في قناة داخلية).
ما يجب فعله بدلًا من ذلك
أرفقوا مع بيان النطاق رسمًا تخطيطيًا لتدفق البيانات يوضح:
- نقطة الدخول الأولى (مثل نقطة البيع أو نموذج الويب).
- كل خطوة معالجة (مثل التحقق من البطاقة، والترخيص، والتسوية).
- كل قناة نقل (مثل HTTPS بين المتصفح والخادم، وTLS بين الخادم وقاعدة البيانات).
- كل نقطة تخزين (مؤقتة أو دائمة).
- نقطة الخروج النهائية (مثل الإرسال إلى شبكة البطاقات، أو الحذف الآمن).
هذا الرسم يساعد المختبر على فهم التدفق الكامل، ويساعد المدقق على التحقق من أن الاختبار غطى كل نقطة.
ما يفحصه المدقق لتأكيد تغطية التدفق
عند مراجعة أدلة المتطلب 11.4.2، يفحص المدقق:
- بيان النطاق: هل يسرد جميع المكونات التي تلمس بيانات حامل البطاقة؟ هل يصف التدفق بينها؟
- تقرير اختبار الاختراق: هل يوثق الاختبار الفعلي لكل مكون في بيان النطاق؟ هل يوضح كيف اختُبرت نقاط الانتقال؟
- رسم تدفق البيانات: هل يطابق بيان النطاق وتقرير الاختبار؟ هل هناك مكونات في الرسم لم تُختبر؟
- الأدلة التقنية: لقطات شاشة، وسجلات، ونتائج الأدوات التي تثبت أن الاختبار غطى كل قطاع من التدفق.
إذا كان بيان النطاق يسرد تطبيقًا واحدًا فقط، أو إذا كان تقرير الاختبار لا يذكر قاعدة البيانات أو قنوات النقل الداخلية، فإن المدقق يطلب إعادة الاختبار — وهذا يؤخر الشهادة ويضيف تكلفة.
ورشة العمل المكونة من أربع خطوات لرسم مسارات البيانات قبل وصول المختبر
لتجنب هذه الأخطاء، نديرها العديد من الشركات ورشة عمل داخلية قبل إعداد بيان النطاق:
1. جمع الفريق المناسب
اجمعوا ممثلين من فريق التطبيقات، وفريق البنية التحتية، وفريق قواعد البيانات، وفريق الأمن، وفريق الامتثال. كل فريق يعرف جزءًا من التدفق — والورشة تجمع المعرفة.
2. رسم التدفق من البداية إلى النهاية
ابدأوا من أول نقطة التقاط — مثل عميل يُدخل رقم بطاقته في نقطة البيع أو في نموذج ويب — وتتبعوا البيانات خطوة بخطوة:
- إلى أين تُرسل البيانات أولًا؟
- ما هو البروتوكول المستخدم؟
- هل تُخزن البيانات مؤقتًا في أي مكان؟
- ما هي الخوادم أو الخدمات التي تعالج البيانات؟
- أين تُخزن البيانات بشكل دائم؟
- هل تُرسل البيانات إلى طرف ثالث؟ كيف؟
- متى تُحذف البيانات؟
ارسموا كل خطوة على لوحة بيضاء أو في أداة رسم، وسجلوا اسم كل مكون وعنوان IP أو اسم النطاق.
3. تحديد نقاط الانتقال
نقاط الانتقال — حيث تنتقل البيانات من مكون إلى آخر — هي حيث تحدث معظم الثغرات. حددوا كل نقطة انتقال في الرسم، وسجلوا:
- البروتوكول المستخدم (مثل HTTPS، TLS، SSH).
- آلية المصادقة (مثل شهادات، مفاتيح API، كلمات مرور).
- ما إذا كانت البيانات مشفرة أثناء النقل.
- ما إذا كانت البيانات تُخزن مؤقتًا في أي مكان أثناء الانتقال.
4. كتابة بيان النطاق من الرسم
بعد اكتمال الرسم، اكتبوا بيان النطاق على شكل قائمة بالمكونات مع وصف موجز لدور كل مكون في التدفق. مثال:
- نقطة البيع (IP: x.x.x.x): نقطة الالتقاط الأولى؛ تُرسل البيانات عبر HTTPS إلى بوابة الدفع.
- بوابة الدفع (domain.example.sa): تستقبل البيانات، وتتحقق من صحة البطاقة، وتُرسل طلب الترخيص إلى خادم المعالجة.
- خادم المعالجة (IP: y.y.y.y): يعالج طلب الترخيص، ويتصل بقاعدة البيانات لتسجيل المعاملة، ويُرسل الطلب إلى شبكة البطاقات عبر واجهة برمجة خارجية.
- قاعدة البيانات (IP: z.z.z.z): تخزن بيانات المعاملة مشفرة؛ تُحذف البيانات بعد 90 يومًا.
- واجهة البرمجة الخارجية (domain.processor.example): تُرسل طلب الترخيص إلى شبكة البطاقات عبر TLS.
أرفقوا الرسم التخطيطي مع بيان النطاق، وسلموهما إلى المختبر.
كيف نساعد
نقدم اختبار الاختراق وفق متطلبات PCI DSS ومتطلبات الإطار السيبراني للبنك المركزي السعودي وإطار الضوابط الأساسية للأمن السيبراني للهيئة الوطنية للأمن السيبراني. تشمل عملية الاختبار أربع مراحل: النطاق حيث نحدد الأهداف وقواعد الاشتباك ونوافذ الاختبار، ثم الاختبار الذي يتضمن الاستطلاع والاختبار والاستغلال اليدوي، ثم التقرير الذي يوثق الملاحظات مع الأدلة والمعالجات وشرحها لفريقكم، وأخيرًا إعادة الاختبار للتحقق بعد المعالجة.
نسلمكم أربعة مخرجات: ملخص تنفيذي لمجلس الإدارة والإدارة العليا، وتقرير تقني مع الأدلة لفريق الأمن، وملاحظات مصنفة المخاطر مع المعالجات لفريق التطوير والبنية التحتية، وتقرير إعادة الاختبار بعد المعالجة.
تشمل خدمة اختبار الاختراق اختبار تطبيقات الويب وواجهات البرمجة والجوال، واختبار الشبكات الداخلية والخارجية، واختبار إعدادات السحابة، واستغلال يدوي واختبار منطق الأعمال، مع إعادة اختبار مجانية للملاحظات المعالجة. تستغرق الخدمة من أسبوع إلى أربعة أسابيع حسب النطاق.
إذا كنتم تحتاجون إلى مراجعة تصميم بيئة الدفع قبل الاختبار — لتحديد نقاط الضعف المحتملة في التقسيم أو تدفقات البيانات أو التكامل — فإننا نقدم أيضًا خدمة مراجعة البنية الأمنية التي تراجع أمن تصاميم الأنظمة والشبكات الجديدة والقائمة وتوصي بتحسينات عملية قبل الإطلاق.
