كيف تدير برنامج عروض مرتبطة بالبطاقة دون توسيع نطاق PCI DSS
لا تحتاج برامج الولاء إلى أرقام البطاقات الكاملة لتعمل. إليكم كيف يحافظ التصميم المقلِّص للنطاق على فائدة العروض ويُبقي بيانات البطاقات خارج منظومة الولاء.
فرق أمن المعلومات محقّة في حذرها من برامج الولاء. فكل نظام جديد يخزّن أرقام البطاقات الكاملة أو يعالجها أو ينقلها ينضم إلى نطاق PCI DSS لدى البنك، مع كل ما يعنيه ذلك من ضوابط واختبارات وأدلة تدقيق. والمبادرة التسويقية التي تضيف بهدوء بيئة جديدة لبيانات البطاقات تمثل خطراً حقيقياً.
الخبر الجيد أن برنامج العروض المرتبطة بالبطاقة المصمم جيداً لا يحتاج إلى أرقام البطاقات الكاملة إطلاقاً. يشرح هذا الدليل مبادئ التصميم "المقلِّص للنطاق" والأسئلة التي ينبغي طرحها على أي مورّد.
هذا المقال إرشاد عام وليس رأياً في الامتثال. تحقّقوا دائماً من قرارات النطاق مع مقيّم الأمن المؤهل (QSA) وفريق الامتثال الداخلي.
تذكير سريع بنطاق PCI DSS
ينطبق معيار أمن بيانات صناعة بطاقات الدفع على الأنظمة التي تخزّن بيانات حاملي البطاقات أو تعالجها أو تنقلها، وعلى الأنظمة المتصلة بها التي قد تؤثر في أمنها. والعنصر المحوري في بيانات حامل البطاقة هو رقم الحساب الأساسي (PAN)، أي الرقم الطويل على وجه البطاقة.
ويعترف المعيار كذلك بأساليب تقلّل المخاطر، مثل الاقتطاع (الاحتفاظ بعدد محدود فقط من الأرقام الأولى والأخيرة)، والترميز البديل، والتجزئة الصارمة للشبكة. وعند استخدامها بشكل صحيح، يمكنها إبقاء الأنظمة خارج النطاق أو تقليل الضوابط المطلوبة بشكل ملحوظ.
لماذا تنتهي كثير من أنظمة الولاء داخل النطاق
كثيراً ما تستقبل البرامج التقليدية المرتبطة بالبطاقة بيانات المعاملات الكاملة، بما فيها أرقام البطاقات، لمطابقة المشتريات بالعروض. وتطلب برامج أخرى من العملاء كتابة رقم بطاقتهم الكامل في نموذج تسجيل. وكلا النهجين يجرّ منصة الولاء، وأحياناً أدوات فريق التسويق، إلى بيئة بيانات البطاقات.
والنتيجة: مراجعات أمنية أطول، وتكاليف تدقيق أعلى، ومخاطر أكبر، وغالباً برنامج يتأخر إطلاقه أشهراً.
مبادئ التصميم المقلِّص للنطاق
1. لا تجمع رقم البطاقة الكامل أبداً
أبسط طريقة لتجنب تخزين أرقام البطاقات هي ألّا تطلبها أصلاً. ويمكن أن يعتمد التسجيل بدلاً من ذلك على:
- معرّف مقتطع، مثل أول خمسة أرقام وآخر أربعة أرقام من البطاقة.
- رقم الجوال المسجل للعميل، المعروف لدى البنك أصلاً.
- رمز تحقق لمرة واحدة (OTP) يُرسل إلى ذلك الرقم للتأكد من هوية العميل.
يكفي الجمع بين الأرقام الجزئية ورقم الجوال ورمز التحقق لربط العميل بمنتج بطاقة مؤهل وبعروضه، دون أن ترى المنصة رقم البطاقة الكامل أبداً.
2. دع البنك يمتلك الربط
إذا احتاج البرنامج إلى معرفة البطاقات المؤهلة، يمكن للبنك مشاركة الأهلية باستخدام مراجع داخلية للعميل أو الحساب، أو رموز بديلة، بدلاً من أرقام البطاقات. ويبقى الربط بين المرجع ورقم البطاقة الحقيقي داخل بيئة البنك القائمة والخاضعة للتقييم أصلاً.
3. استخدم العروض دون أرقام بطاقات
لا ينبغي أن يتطلب استخدام العرض لدى التاجر رقم بطاقة أبداً. ومن الخيارات المقلِّصة للنطاق:
- رموز العميل المتغيرة التي تظهر في التطبيق ويُدخلها التاجر.
- بطاقات طاولة برمز QR أو رقم سري يمسحها العميل عند الصندوق.
- رموز القسائم والروابط المتتبَّعة للتجار الإلكترونيين.
لا تلمس أي من هذه الطرق بيانات البطاقات. فالتاجر يؤكد وجود عميل مؤهل، وأنظمة الدفع في البنك تعالج الدفع كالمعتاد.
4. أبعد التجار عن بيانات حاملي البطاقات
ينبغي ألّا يرى التجار إلا ما يحتاجونه: أن عرضاً قد استُخدم، ومتى، وبعض المعلومات الأساسية إن وافق العميل. ولا ينبغي أن يروا أرقام البطاقات أو ملفات العملاء الكاملة أبداً.
5. افصل البيئات بوضوح
حيث تتصل منصة الولاء بأنظمة البنك، عبر نقل الملفات أو API مثلاً، اجعل الواجهات ضيقة وموثقة جيداً. تبادل الحقول المطلوبة فقط، وتأكد أن أياً منها ليس رقم بطاقة كاملاً.
ما بعد PCI: ضوابط أمنية أشمل
إبقاء بيانات البطاقات خارج النطاق أمر مهم، لكن منصة الولاء تتعامل مع بيانات شخصية وعمليات حيوية للأعمال. فابحث عن ضوابط متوافقة مع أطر معترف بها مثل SOC 2 وISO 27001، ومنها:
- التحكم في الوصول حسب الأدوار والمصادقة متعددة العوامل للموظفين والتجار.
- تشفير البيانات أثناء النقل وأثناء التخزين.
- سجلات تدقيق مفصلة لتغييرات الإعدادات والاعتمادات والوصول إلى البيانات.
- ممارسات تطوير برمجيات آمنة واختبارات اختراق دورية.
- سياسات للاحتفاظ بالبيانات وحذفها تتوافق مع التنظيمات المحلية.
- إجراءات واضحة للاستجابة للحوادث.
أسئلة ينبغي طرحها على أي مورّد لمنصة عروض
- هل تخزّن منصتكم أرقام البطاقات الكاملة أو تعالجها أو تنقلها في أي وقت؟ إن كان كذلك، فأين ولماذا؟
- كيف يسجّل العملاء بطاقاتهم؟ وما البيانات التي تُجمع؟
- كيف يتحقق التجار من العروض؟ هل يرون بيانات البطاقات في أي وقت؟
- ما البيانات التي تحتاجونها من أنظمتنا، وبأي صيغة؟
- مع أي أطر أمنية تتوافق ضوابطكم، وما الأدلة التي يمكنكم مشاركتها؟
- أين تُستضاف البيانات، وكيف تلبّون متطلبات توطين البيانات المحلية؟
- كيف تُدار صلاحيات الوصول والسجلات والاستجابة للحوادث؟
المورّد الذي يملك تصميماً مقلِّصاً للنطاق حقاً سيجيب عن الأسئلة الثلاثة الأولى ببساطة وسرعة.
الفائدة التجارية
تقليص النطاق لا يقتصر على تجنب المخاطر، بل يغيّر المشروع نفسه:
- اعتمادات أسرع، لأن المراجعات الأمنية تركّز على مجموعة أضيق من الأسئلة.
- تكلفة أقل، لأن عدداً أقل من الأنظمة يحتاج إلى ضوابط PCI وأدلة تدقيق.
- مرونة أكبر، لأن فرق التسويق والمنتجات تستطيع التطوير دون المساس ببيئة بيانات البطاقات.
- ثقة أكبر لدى العملاء، لأن البنك يستطيع أن يقول بصدق إن برنامج العروض لا يحتفظ أبداً بأرقام البطاقات الكاملة.
الخلاصة
يمكن لبرنامج العروض المرتبطة بالبطاقة أن يكون جذاباً وقابلاً للقياس وآمناً دون توسيع بيئة بيانات البطاقات. عرّفوا البطاقات بأرقام مقتطعة ورمز تحقق يُرسل إلى جوال العميل، ودعوا البنك يحتفظ بالربط، واستخدموا العروض برموز لا بأرقام بطاقات، وأبعدوا التجار عن بيانات حاملي البطاقات.
صُممت cardoff.ai بهذه الطريقة منذ البداية: تُعرَّف البطاقات بأول خمسة أرقام وآخر أربعة أرقام مع رمز تحقق يُرسل إلى الجوال، دون رقم البطاقة الكامل أبداً، مع ضوابط متوافقة مع SOC 2 وISO 27001. إذا رغب فريق الأمن لديكم في مراجعة البنية، يسعدنا مشاركة التفاصيل.
