يتطلب معيار PCI DSS 4.0 في البند 8.4.2 مصادقة متعددة العوامل لكل وصول غير خاص بوحدة التحكم إلى بيئة بيانات حامل البطاقة. بالنسبة لشركات المدفوعات والتقنية المالية السعودية التي تستخدم نفاذ لمصادقة العملاء، يبدو الأمر واضحًا: نفاذ يوفر مصادقة ثنائية قوية عبر بصمة الوجه أو بصمة الإصبع. لكن السؤال الذي يطرحه مدققو PCI DSS ومدراء مكافحة الاحتيال ليس عن قوة المصادقة وحدها، بل عن ربط الأجهزة نفاذ PCI DSS احتيال المدفوعات: هل الجهاز الذي يبادر بالدفع هو نفسه الجهاز المرتبط بالهوية المصادق عليها؟ وهل يمكن للمحتال أن يصادق عبر نفاذ على جهازه ثم ينفذ المعاملة من جهاز آخر؟
هذا المقال يستعرض أربعة سيناريوهات اختبار عملية—تبديل الشريحة، نسخ الجلسة، الجهاز المخترق، والهجوم الوسيط—تكشف فجوات ربط الأجهزة والتوقيع على المعاملات، ويوضح الأدلة المطلوبة من مدققي PCI DSS في مراجعة ضوابط الاحتيال.
لماذا نفاذ وحده لا يكفي لاستيفاء البند 8.4.2
نفاذ يثبت هوية الشخص بدرجة عالية من الثقة. لكن معيار PCI DSS يتطلب أن تكون المصادقة متعددة العوامل مرتبطة بالجلسة والجهاز والمعاملة، وليس فقط بالهوية. الفجوة تظهر في ثلاث نقاط:
الفصل الزمني: المصادقة عبر نفاذ تحدث مرة واحدة عند تسجيل الدخول أو عند ربط الحساب. إذا لم يُطلب توقيع إضافي على كل معاملة دفع، فإن الجلسة تبقى مفتوحة لفترة قد تمتد لدقائق أو ساعات.
الفصل المكاني: نفاذ يصادق على الهوية، لكنه لا يصادق على الجهاز. إذا استطاع المحتال نسخ رمز الجلسة أو استخدام جهاز وسيط، فإنه يستطيع تنفيذ المعاملة من جهاز آخر غير الجهاز الذي تمت المصادقة عليه.
الفصل المنطقي: حتى لو كان الجهاز نفسه، فإن التطبيق أو المتصفح قد يكون مخترقًا، والمحتال يستطيع تعديل بيانات المعاملة بعد المصادقة وقبل الإرسال إلى الخادم.
مدققو PCI DSS يطلبون أدلة على أن الضوابط تغطي هذه الفجوات الثلاث. الأدلة ليست وثائق سياسات فقط، بل نتائج اختبار فعلية تثبت أن الضوابط تمنع السيناريوهات المعروفة.
المختبر الرباعي: سيناريوهات الاختبار لكل شركة مدفوعات
السيناريو الأول: تبديل الشريحة بعد المصادقة
الوصف: العميل يصادق عبر نفاذ على جهازه الأصلي، ثم يستخرج المحتال رمز الجلسة (session token) من ذاكرة التطبيق أو من سجلات الشبكة، ويستخدمه على جهاز آخر لتنفيذ معاملة دفع.
الاختبار: في بيئة ما قبل الإنتاج، يسجل المختبر الدخول عبر نفاذ على الجهاز A، ثم ينسخ رمز الجلسة إلى الجهاز B، ويحاول تنفيذ معاملة دفع من الجهاز B.
الضابط المطلوب: ربط رمز الجلسة بمعرف الجهاز (device fingerprint) أو بشهادة الجهاز (device certificate). إذا تغير معرف الجهاز، يجب أن يطلب النظام مصادقة جديدة عبر نفاذ.
الأدلة المطلوبة: سجلات النظام تظهر رفض المعاملة من الجهاز B، وطلب مصادقة جديدة، ورسالة خطأ واضحة للعميل.
السيناريو الثاني: نسخ الجلسة عبر الهجوم الوسيط
الوصف: المحتال يعترض الاتصال بين تطبيق العميل والخادم (man-in-the-middle attack) باستخدام شبكة Wi-Fi عامة أو برمجية خبيثة على الجهاز، وينسخ رمز الجلسة وبيانات المعاملة، ثم يعيد إرسال المعاملة بعد تعديل المبلغ أو الوجهة.
الاختبار: يستخدم المختبر أداة اعتراض (proxy tool) لنسخ طلب الدفع بعد المصادقة عبر نفاذ، ثم يعدل بيانات المعاملة (مثل المبلغ أو رقم الحساب)، ويعيد إرسال الطلب.
الضابط المطلوب: توقيع المعاملة (transaction signing) باستخدام مفتاح خاص مخزن في عنصر آمن على الجهاز (secure element أو TEE). كل معاملة يجب أن تُوقَّع بمفتاح لا يمكن نسخه، ويتحقق الخادم من التوقيع قبل تنفيذ المعاملة.
الأدلة المطلوبة: سجلات النظام تظهر رفض المعاملة المعدلة بسبب فشل التحقق من التوقيع، ورسالة خطأ تشير إلى تعديل البيانات.
السيناريو الثالث: الجهاز المخترق بصلاحيات الجذر
الوصف: جهاز العميل مخترق (rooted أو jailbroken)، والمحتال يستطيع قراءة ذاكرة التطبيق أو تعديل سلوكه. حتى لو كان التطبيق يستخدم توقيع المعاملة، فإن المحتال قد يستطيع استخراج المفتاح الخاص من الذاكرة أو تعديل البيانات قبل التوقيع.
الاختبار: يثبت المختبر التطبيق على جهاز مخترق، ويحاول استخراج المفتاح الخاص أو تعديل بيانات المعاملة قبل التوقيع، ثم يحاول تنفيذ معاملة دفع.
الضابط المطلوب: كشف الاختراق (root/jailbreak detection) عند بدء التطبيق وعند كل معاملة، ورفض تنفيذ المعاملة إذا كان الجهاز مخترقًا. بالإضافة إلى ذلك، تخزين المفتاح الخاص في عنصر آمن لا يمكن الوصول إليه حتى مع صلاحيات الجذر.
الأدلة المطلوبة: سجلات النظام تظهر كشف الاختراق ورفض المعاملة، ورسالة للعميل تطلب منه استخدام جهاز آمن.
السيناريو الرابع: الهجوم الوسيط على مستوى التطبيق
الوصف: المحتال يستخدم تطبيقًا وسيطًا (overlay attack أو accessibility service) على جهاز العميل لتعديل واجهة التطبيق الأصلي. العميل يرى مبلغًا معينًا على الشاشة، لكن التطبيق الوسيط يعدل البيانات المرسلة إلى الخادم.
الاختبار: يثبت المختبر تطبيقًا وسيطًا يعترض واجهة التطبيق الأصلي، ويعدل بيانات المعاملة (مثل المبلغ أو الوجهة) قبل الإرسال، ثم يحاول تنفيذ المعاملة.
الضابط المطلوب: إشعار خارج النطاق (out-of-band notification) عبر SMS أو إشعار push مستقل يحتوي على تفاصيل المعاملة الفعلية (المبلغ والوجهة) قبل التنفيذ، مع طلب تأكيد صريح من العميل. بالإضافة إلى ذلك، كشف التطبيقات الوسيطة (overlay detection) ورفض المعاملة إذا كان هناك تطبيق وسيط نشط.
الأدلة المطلوبة: سجلات النظام تظهر إرسال الإشعار وتأكيد العميل، أو كشف التطبيق الوسيط ورفض المعاملة.
كيف يراجع مدققو PCI DSS هذه الضوابط
مدققو PCI DSS لا يكتفون بمراجعة الوثائق والسياسات. في مراجعة البند 8.4.2، يطلب المدقق أدلة على أن الضوابط تم اختبارها فعليًا وأنها تمنع السيناريوهات المعروفة. الأدلة المطلوبة تشمل:
نتائج اختبار السيناريوهات: تقرير يوضح كل سيناريو، وخطوات الاختبار، والنتيجة (نجح الضابط في منع الهجوم أم لا)، والأدلة من سجلات النظام.
مراجعة الكود أو التكوين: دليل على أن ربط الجهاز وتوقيع المعاملة وكشف الاختراق مطبقة في الكود الفعلي، وليس فقط في الوثائق.
سجلات المراقبة: دليل على أن النظام يسجل كل محاولة فاشلة لتنفيذ معاملة من جهاز غير مرتبط أو من جهاز مخترق، وأن هناك تنبيهات لفريق مكافحة الاحتيال.
إشعارات العملاء: دليل على أن العملاء يتلقون إشعارات بتفاصيل المعاملة قبل التنفيذ، وأن الإشعارات تصل عبر قناة مستقلة.
إذا كانت هذه الأدلة غير متوفرة، فإن المدقق يسجل فجوة في الامتثال، حتى لو كان نفاذ مطبقًا بشكل صحيح.
الفجوات الشائعة في التطبيقات الحالية
من واقع المراجعات الفعلية، الفجوات الأكثر شيوعًا في شركات المدفوعات والتقنية المالية السعودية هي:
غياب ربط الجهاز: رمز الجلسة لا يرتبط بمعرف الجهاز، مما يسمح بنسخه واستخدامه على جهاز آخر.
غياب توقيع المعاملة: المصادقة تحدث عند تسجيل الدخول فقط، ولا يوجد توقيع إضافي على كل معاملة دفع.
غياب كشف الاختراق: التطبيق لا يكشف الأجهزة المخترقة، مما يسمح باستخراج المفاتيح الخاصة أو تعديل سلوك التطبيق.
غياب الإشعارات الفعالة: الإشعارات تصل بعد تنفيذ المعاملة، أو لا تحتوي على تفاصيل كافية، أو تصل عبر نفس القناة التي قد تكون مخترقة.
غياب الاختبار الدوري: الضوابط مطبقة عند الإطلاق، لكن لا يوجد اختبار دوري للتأكد من أنها لا تزال فعالة بعد التحديثات والتغييرات.
كيف تبني مختبر الاختبار الرباعي في مؤسستك
بناء مختبر اختبار لضوابط ربط الأجهزة والتوقيع على المعاملات يتطلب أربع خطوات:
رسم رحلات العملاء: حدد كل رحلة من فتح الحساب إلى تنفيذ الدفع، وحدد نقاط المصادقة ونقاط المخاطر في كل رحلة.
نمذجة التهديدات: لكل نقطة مخاطر، حدد السيناريوهات المحتملة (تبديل الشريحة، نسخ الجلسة، الجهاز المخترق، الهجوم الوسيط)، وحدد الضوابط المطلوبة لكل سيناريو.
إعداد بيئة الاختبار: أنشئ بيئة ما قبل الإنتاج تحاكي البيئة الفعلية، مع أدوات الاختبار (أجهزة مخترقة، أدوات اعتراض، تطبيقات وسيطة).
تنفيذ الاختبار وتوثيق النتائج: نفذ كل سيناريو، وسجل النتيجة، واجمع الأدلة من سجلات النظام، ووثق الفجوات والتوصيات.
الاختبار يجب أن يتكرر بعد كل تحديث كبير للتطبيق أو للبنية التحتية، وعلى الأقل مرة كل ستة أشهر.
الأدلة التي يجب أن تجهزها لمراجعة PCI DSS
عند الاستعداد لمراجعة PCI DSS، يجب أن تجهز الأدلة التالية:
تقرير اختبار السيناريوهات: يحتوي على وصف كل سيناريو، وخطوات الاختبار، والنتيجة، والأدلة من سجلات النظام.
مراجعة الكود أو التكوين: مقتطفات من الكود أو لقطات شاشة من التكوين تثبت أن الضوابط مطبقة فعليًا.
سجلات المراقبة: عينات من سجلات النظام تظهر رفض المعاملات الفاشلة والتنبيهات المرسلة إلى فريق مكافحة الاحتيال.
سياسة الاختبار الدوري: وثيقة تحدد تكرار الاختبار والمسؤوليات والإجراءات.
سجلات الإشعارات: عينات من الإشعارات المرسلة إلى العملاء قبل تنفيذ المعاملات، مع تفاصيل المعاملة وتأكيد العميل.
هذه الأدلة يجب أن تكون محدثة ومتاحة للمدقق في أي وقت.
مراجعة ضوابط الاحتيال في الخدمات المصرفية الرقمية والمدفوعات
نقدم مراجعة شاملة لضوابط الاحتيال في الخدمات المصرفية عبر الجوال والإنترنت، والتحقق الرقمي (نفاذ)، وربط الأجهزة، وتوقيع العمليات، وإشعارات العملاء. تأمين كل رحلة للعميل من فتح الحساب حتى الدفع.
المراجعة تشمل رسم رحلات العملاء وضوابطها، ونمذجة التهديدات لسيناريوهات الاحتيال لكل خطوة، واختبار الضوابط واستعراض السيناريوهات، والتوصيات في خارطة طريق حسب الأولوية مع أثرها على التجربة.
المخرجات تشمل تقييم الضوابط لكل رحلة، ونتائج اختبار سيناريوهات الاحتيال، وخارطة طريق المعالجة. المراجعة تغطي نمذجة التهديدات لرحلات العملاء، ومراجعة المصادقة وموثوقية الأجهزة، وضوابط الهندسة الاجتماعية وحسابات الوسطاء، ومراجعة توعية العملاء والإشعارات. المدة من أربعة إلى ثمانية أسابيع.
الاختبار يتم بموافقتكم في بيئة ما قبل الإنتاج، ويقتصر الاختبار على البيئة الفعلية في سيناريوهات آمنة متفق عليها. المراجعة تركز على ضوابط الاحتيال، وتتكامل جيدًا مع خدمة اختبار الاختراق لدينا.
للاستفسار عن المراجعة أو لمناقشة ضوابط الاحتيال في مؤسستك، تواصل مع فريق سيزو للاستشارات.
