إذا كنت تدير متجرًا إلكترونيًّا ويقوم العملاء بالدفع لديك باستخدام البطاقات، فإن معيار الأمان PCI DSS ينطبق عليك. اعتبارًا من ربيع عام 2025، سيُطبق الإصدار 4.0 الأكثر صرامة، والذي أضاف عشرات الالتزامات الجديدة. ويشمل بعضها أيضًا المتاجر الإلكترونية الصغيرة، التي كانت تعتقد حتى ذلك الحين أنها في مأمن. يشرح هذا المقال متطلبات المعيار، ومن ينطبق عليه، وما هي عواقب عدم الامتثال له.
ما هو PCI DSS
PCI DSS هي اختصار لـ «معيار أمن بيانات صناعة بطاقات الدفع» (Payment Card Industry Data Security Standard). وهو عبارة عن مجموعة من القواعد الأمنية التي تحدد كيفية التعامل مع بيانات بطاقات الدفع. لم تصدره الاتحاد الأوروبي ولا المشرع السلوفاكي. بل يقف وراءه مجلس مكون من شركات بطاقات الائتمان Visa وMastercard وAmerican Express وDiscover وJCB.
وهو ليس قانونًا بالمعنى التقليدي، بل متطلب تعاقدي. بتوقيع العقد مع بوابة الدفع أو مع البنك لقبول البطاقات، يلتزم المشغل بالامتثال لمعيار PCI DSS. ولذلك، غالبًا ما يكون الإنفاذ في الممارسة العملية أكثر صرامةً مما هو عليه في القوانين العادية. لن تقاضي البنك المتجر الإلكتروني أمام المحكمة، بل سترفع الرسوم، أو في الحالة القصوى ستوقف إمكانية قبول البطاقات.
ينطبق المعيار على كل من يقوم بتخزين البيانات الخاصة ببطاقات الائتمان أو معالجتها أو نقلها. ولا يهم عدد الطلبات، بل ما يهم هو ما إذا كانت بيانات بطاقات الائتمان تمر عبر النظام المعني أم لا.
الإصدار 4.0 والموعد النهائي
انتهت صلاحية الإصدار 3.2.1 الذي كان ساريًا حتى الآن. وحل محله الإصدار 4.0، أو بالأحرى إصداره المعدل 4.0.1. والتاريخ المحدد هو 31 مارس 2025. وحتى ذلك الحين، كانت هناك فترة انتقالية، تم خلالها التعامل مع العديد من المتطلبات الجديدة على أنها مجرد ممارسات موصى بها. ومنذ هذا التاريخ، أصبحت هذه المتطلبات ملزمة، ويتم أخذها في الاعتبار كالتزام كامل في كل عملية تقييم المطابقة.
جلبت النسخة الجديدة 64 متطلبًا جديدًا، تم تأجيل أكثر من 50 منها حتى مارس 2025. لذا، لا يتعلق الأمر بتغييرات شكلية، بل بأكبر تحول في هذه المواصفة خلال العشر سنوات الماضية تقريبًا.
التغيير الرئيسي يكمن في النهج المتبع. لم تعد الأمان مجرد بند يتم استيفاؤه مرة واحدة سنويًا خلال عملية التدقيق. فالمعيار يحث على توفير حماية مستمرة ودائمة.
من يشملهم هذا المعيار
يُصنف التجار إلى أربعة مستويات وفقًا لعدد المعاملات السنوية. وعادةً ما تندرج المتاجر الإلكترونية التي تجري أقل من عشرين ألف معاملة ببطاقات الائتمان سنويًّا ضمن المستوى الرابع، وهو أدنى المستويات. ويُطبق عليها نظام أكثر مرونة. فبدلاً من التدقيق من قبل مدقق خارجي، يكفي ملء استبيان التقييم الذاتي السنوي، المعروف باسم SAQ.
إلا أن النظام الأقل صرامة لا يعني عدم وجود نظام على الإطلاق. تستهدف المستجدات في الإصدار 4.0 المتاجر الإلكترونية الصغيرة أيضًا، وتحديدًا متطلبين يؤثران بشكل مباشر على المشغلين الذين يمتلكون أقل القدرات التقنية.
التصنيف إلى المستوى لا يتعلق فقط بعدد المعاملات
يمكن للبنك أو شركة بطاقات الائتمان إعادة تصنيف متجر إلكتروني إلى مستوى أعلى بغض النظر عن عدد المعاملات. وغالبًا ما يكون السبب هو وقوع حادث أمني سابق أو طريقة معالجة المدفوعات. يجب على المشغل الذي واجه تسربًا للبيانات في الماضي أن يتوقع تلقائيًا تطبيق نظام أكثر صرامة وأن يتحقق من تصنيفه لدى مزوده.
أحدث مستجدتين اللتين تؤثران بشكل أكبر على المتاجر الإلكترونية
تعمل هجمات «السكيمينغ الرقمي» (digital skimming)، المعروفة أيضًا باسم Magecart أو formjacking، بشكل خفي. لا يخترق المهاجم الخادم، بل يزرع شفرة ضارة في صفحة الدفع، غالبًا عبر برنامج نصي تابع لجهة ثالثة يعمل على الموقع، مثل أدوات التحليلات أو الدردشة أو بكسل الإعلانات. يقوم العميل بإدخال رقم البطاقة، وتعمل الصفحة بشكل طبيعي، ويتم إتمام الطلب، بينما تتسرب البيانات في الخفاء إلى المهاجم. وقد يظل التسرب دون أن يلاحظه أحد لعدة أشهر.
تستجيب النسخة 4.0 لهذا الأمر بمتطلبين.
إدارة البرامج النصية على صفحة الدفع (6.4.3)
يجب أن يكون لدى المشغل نظرة عامة على كل برنامج نصي يعمل على الصفحة التي يتم فيها إدخال بيانات البطاقة. ويجب أن يعرف سبب وجود البرنامج النصي هناك، وأن يقوم بتمكينه ومراقبة سلامته، أي رصد اللحظة التي يتغير فيها بشكل غير متوقع.
مراقبة رؤوس HTTP ومحتوى الصفحة (11.6.1)
يلزم وجود نظام ينبه إلى أي تدخل غير مصرح به في صفحة الدفع. ويتعلق الأمر بمراقبة مستمرة للتأكد من عدم حدوث أي شيء غير متوقع على الصفحة الحساسة.
كلا الشرطين صعبان من الناحية التقنية. بالنسبة لمتجر إلكتروني صغير يعمل على منصة مستأجرة، تتولى المنصة نفسها أو بوابة الدفع معالجة جزء منهما. إلا أن المسؤولية عن حل هذه المتطلبات تقع على عاتق المشغل، وليس على عاتق المورد.
متطلبات أخرى أكثر صرامة
بالإضافة إلى المستجدتين في مجال التجارة الإلكترونية، شددت النسخة 4.0 أيضًا العديد من القواعد العامة السارية على جميع من يتعاملون مع البطاقات.
تم توسيع نطاق المصادقة متعددة العوامل. في السابق، كانت هذه المصادقة كافية في حالات الوصول عن بُعد والوصول الإداري، أما الآن فهي مطلوبة عند أي وصول إلى بيئة تحتوي على بيانات البطاقات، وليس فقط للمسؤولين.
تم تمديد طول كلمات المرور إلى اثني عشر حرفًا على الأقل مع درجة مناسبة من التعقيد. فكلمات المرور القديمة المكونة من ثمانية أحرف لم تعد كافية.
يجب تحديد نطاق التقييم، أو ما يُعرف بـ«scope»، وتوثيقه مرة واحدة سنويًّا. وهذا يعني تحديد المسار الذي تمر به بيانات البطاقات في النظام، والأنظمة والأشخاص والعمليات التي تتعامل معها. أما بالنسبة لمقدمي الخدمات، فيُطبق هذا على كل ستة أشهر.
كما تمت إضافة تحليلات مخاطر موجهة في العديد من عمليات المراقبة وقواعد أكثر صرامة فيما يتعلق بالتشفير. ويعتمد النطاق المحدد على طريقة معالجة المدفوعات.
عواقب عدم الامتثال
تفرض شركات بطاقات الائتمان الغرامات عن طريق البنك، وعادةً ما تكون شهريًّا، ويعتمد مقدارها على خطورة المخالفة ومدة عدم الامتثال. كما يحق للبنك زيادة رسوم المعاملات. وفي الحالات القصوى، تقوم البنك بفسخ العقد وتنتفي إمكانية قبول البطاقات.
تتجلى أخطر العواقب في حالة تسرب البيانات. إذا سرق المهاجم بيانات بطاقات العملاء وتبين أن المتجر الإلكتروني لم يستوف معايير PCI DSS، فإن المشغل يتحمل المسؤولية عن الأضرار، وعن التدقيق الجنائي الإلزامي، وتكاليف إصدار بطاقات جديدة للعملاء المتضررين. يضاف إلى ذلك فقدان ثقة العملاء، وهو ما يؤثر على المتجر الإلكتروني على المدى الطويل.
الارتباط مع اللائحة العامة لحماية البيانات (GDPR)
يتداخل معيار PCI DSS مع اللائحة العامة لحماية البيانات (GDPR). فبيانات البطاقات هي في الوقت نفسه بيانات شخصية. وبالتالي، فإن أي تسرب يمثل مشكلتين متزامنتين، وهما انتهاك معيار بطاقات الدفع وانتهاك حماية البيانات الشخصية بكل ما يترتب على ذلك من التزامات.
إجراءات التنفيذ
تحديد طريقة معالجة المدفوعات
هذا هو الأساس، وفي الوقت نفسه أهم وسيلة لتخفيف العبء. عند إعادة التوجيه إلى بوابة الدفع أو عند تضمين حقل على شكل iframe مباشرةً من المزود، لا تمر بيانات البطاقة عبر خادم المتجر، بل تنتقل مباشرةً إلى البوابة. وهذا يقلل بشكل كبير من نطاق الالتزامات، وغالبًا ما يكفي استخدام أبسط استبيان للتقييم الذاتي.
تحقق من تصنيفك ونوع الاستبيان
يجب التحقق من التصنيف حسب المستوى ونوع استبيان التقييم الذاتي (SAQ) مباشرةً لدى البنك أو بوابة الدفع. فمن واجبهم تقديم هذه المعلومات.
قم بإجراء جرد للبرامج النصية
افحص كل ما يتم تشغيله على صفحات الطلبات والدفع، أي أدوات التحليل والدردشة والبيكسلات والأدوات الخارجية. قم بإزالة البرامج النصية غير الضرورية. فكل برنامج نصي غريب على صفحة الدفع يمثل مدخلاً محتملاً للمهاجم.
تحقق من إجراءات الأمان الأساسية
ويشمل ذلك استخدام بروتوكول HTTPS في جميع أنحاء الموقع، والتحقق متعدد العوامل حيثما أمكن، وكلمات مرور طويلة بما يكفي، والتحديثات المنتظمة للنظام ووحدة الدفع. فمعظم المتاجر الإلكترونية تفشل في هذه الجوانب الأساسية.
في حالة الحلول الأكثر تعقيدًا، استعنوا بخدمات الاستشارة
في حالة ارتفاع حجم المعاملات أو وجود حل تقني أكثر تعقيدًا، من المفيد استشارة خبير في معيار PCI DSS. تكاليف الاستشارة أقل من التكاليف المرتبطة بحادث واحد.
