ستة مفاهيم خاطئة عن معيار PCI DSS في إصدار البطاقات

اسأل في أي بنك عن معيار PCI DSS وإصدار البطاقات، وستسمع مجموعة من الافتراضات المريحة تتكرر بثقة. معظمها صحيح جزئيًا، وهذا بالضبط ما يجعلها خطِرة. فهي مطمئنة بما يكفي لمنع طرح سؤال أصعب، والثغرة التي تتركها عادةً ما تظهر في أسوأ وقت ممكن: أثناء التقييم، أو بعد أن تصل بطاقة إلى مكان لا ينبغي أن تصل إليه.

هذه نظرة على ستة من تلك الافتراضات، وما تتطلبه الحقيقة وراء كل واحد منها فعلًا. وإذا كنت مسؤولًا عن برنامج بطاقات، فمن المفيد أن تقيس وضعك الحالي عليها.

المفهوم الأول: «نحن ملتزمون بمعيار PCI، إذن إصدار البطاقات مغطّى.»

كثيرًا ما نتحدث عن الالتزام باعتباره حالة واحدة، شهادة إما تملكها المؤسسة أو لا. وهذه النظرة تخفي المكان الذي تكمن فيه مخاطر الإصدار فعلًا.

الحقيقة أن معيار PCI DSS على مستوى الإصدار ليس حالة واحدة، بل مجموعة من القرارات المنفصلة في التصميم، يغلق كل قرار منها بابًا محددًا قد تتسرب منه البيانات الحساسة أو يصبح من الصعب تتبّعها. تشفير رقم البطاقة قرار. وعدم تخزين البيانات الممنوعة قرار آخر. وإحكام الصلاحيات قرار ثالث. يمكن لمؤسسة أن تكون ملتزمة بشكل عام على مستوى الشبكة، ويظل لديها تطبيق إصدار يفشل في عدد من هذه القرارات، كل واحد على حدة. السؤال المفيد ليس «هل نحن ملتزمون» بشكل عام، بل «بالنسبة لكل نقطة يهتم بها المعيار، ماذا يفعل نظام الإصدار لدينا تحديدًا؟»

المفهوم الثاني: «الالتزام يتحقق على مستوى الشبكة.»

جدران الحماية، وفصل الشبكات، والتشفير أثناء النقل، والتقييم السنوي. هنا تقضي معظم النقاشات حول PCI وقتها، وكل ذلك مهم. لكنه يفترض بهدوء أن الخطر يكمن في المسارات وحدها.

الحقيقة أن جزءًا كبيرًا من مخاطر الإصدار يوجد في التطبيق الذي يتعامل مع البطاقات وقت إصدارها. فلعدة أيام، يتعامل هذا التطبيق مع بيانات بطاقات حقيقية، وبيانات عملاء حقيقيين، ومع البطاقات نفسها وهي تنتقل من المطبعة إلى شركة الشحن إلى العميل. وما يخزّنه، وما يعرضه، ومن يسمح له بالدخول، وما يسجّله، كل ذلك يحدد ما إذا كانت تلك الفترة محكومة أم مكشوفة. قد تكون الشبكة سليمة تمامًا بينما يعرض التطبيق بهدوء أرقام بطاقات كاملة في تقرير يذهب إلى الفرع. الالتزام على مستوى التطبيق أهدأ من أمن الشبكة، لكنه لا يقل عنه أهمية.

المفهوم الثالث: «الموظفون يعرفون أن عليهم عدم كشف أرقام البطاقات.»

كل بنك يدرّب موظفيه. والافتراض أن الموظف الحريص والسياسة الواضحة يكفيان لمنع كشف رقم الحساب الأساسي، أي الرقم الطويل الموجود على وجه البطاقة.

الحقيقة أن أي وسيلة رقابة تعتمد على أن يتذكّر الناس إخفاء البيانات ستفشل في النهاية، لأنها لا تحتاج سوى لحظة إرهاق واحدة. الأسلوب الأكثر ثباتًا هو أسلوب مبني في النظام نفسه: الرقم الكامل يبقى مشفّرًا في مكان تخزينه، وفي كل موضع قد يراه فيه شخص أو ملف لاحق، يظهر مخفيًا جزئيًا بدلًا من ظهوره كاملًا. على الشاشة، وفي التقارير، وفي ملفات الإكسل المرسلة إلى الفروع، وفي الملفات المسلَّمة لشركات الشحن، لا تظهر إلا نسخة مخفية جزئيًا، تكفي للتعرّف على البطاقة دون كشفها. وحين لا يحتاج القائمون على العمل اليومي إلى الرقم الكامل، فإنهم ببساطة لا يرونه، ولا يوجد ما يجب تذكّره. وهذا بالضبط نوع الضمان الذي يفرضه نظام مثل PCI Tracker تلقائيًا، لا عن طريق التدريب.

المفهوم الرابع: «نحتفظ ببيانات البطاقة تحسّبًا للحاجة إليها لاحقًا.»

يبدو الاحتفاظ بالبيانات تصرفًا حكيمًا. فإذا احتاج أمر ما إلى مراجعة لاحقًا، كما يقول المنطق، فمن الأفضل أن تكون البيانات متاحة. لكن هذا التفكير، حين يُطبَّق على إصدار البطاقات، يتحول إلى عبء ومسؤولية.

الحقيقة أن بعض البيانات لا يُسمح ببساطة بالاحتفاظ بها بعد اعتماد البطاقة: رمز الأمان على ظهرها، والرقم السري نفسه، وبيانات الشريط المغناطيسي كاملة. النظام المبني بشكل سليم لا يحتفظ بهذه البيانات «تحسّبًا». وأوضح طريقة للتفكير في الأمر أن نظام تتبّع الإصدار موجود لتتبّع أحداث الإصدار، أي أن بطاقة انتقلت من مرحلة إلى التي تليها، ومن تعامل معها، ومتى، وليس للاحتفاظ بالأسرار. فليس لديه سبب لتخزين القيم التي يمنع المعيار الاحتفاظ بها، ولذلك لا يخزّنها. أكثر البيانات أمانًا هي البيانات التي لم تُحفَظ من الأساس.

قِس وضعك الحالي على المفاهيم الستة كلها. اطّلع على كيف يبني PCI Tracker هذه القرارات داخل طبقة الإصدار تلقائيًا.

اكتشف PCI Tracker

المفهوم الخامس: «كل من يعمل في العمليات يحتاج صلاحية كاملة لأداء عمله.»

تبدو الصلاحية الواسعة وكأنها كفاءة. امنح الفريق صلاحية الوصول إلى كل شيء ولن يتعطّل أحد في انتظار الأذونات. لكن في برنامج البطاقات، الصلاحية الواسعة هي الطريق الذي يتحول به حادث صغير إلى حادث كبير.

الحقيقة هي مبدأ أقل الصلاحيات: كل مستخدم يصل فقط إلى ما يتطلبه عمله تحديدًا، وليس أكثر. مستخدم الفرع يرى البطاقات الخاصة بفرعه، لا المؤسسة كلها. ويتم التحقق من الدخول عبر الدليل المركزي للبنك بدلًا من قائمة كلمات مرور منفصلة. وتنتهي الجلسات بعد فترة من عدم النشاط حتى لا تبقى شاشة مفتوحة دون مراقبة، ومحاولات الدخول الفاشلة المتكررة تقفل الحساب بدلًا من السماح بالمحاولة إلى ما لا نهاية. كل إجراء منها صغير بمفرده. لكنها معًا تجعل الوصول قرارًا مقصودًا لا أمرًا عابرًا، وتقلّل ما يمكن لأي حساب مخترَق واحد أن يصل إليه.

المفهوم السادس: «إذا حدث خطأ، سنتمكن من معرفة ما جرى لاحقًا.»

بعد وقوع الحادث، تكون الخطة هي تجميع القصة من أي سجلات متاحة. وهذا ينجح تمامًا حتى اللحظة التي نحتاج إليه فيها فعلًا، وعندها تكون الثغرات هي بالضبط موضع المشكلة.

الحقيقة أن سجل تدقيق يغطّي بعض الإجراءات فقط لا يكاد يكون أفضل من لا شيء، لأن المشكلات تختبئ في المساحات غير المغطّاة. التسجيل الشامل يعني أن عمليات الدخول، والوصول إلى الشاشات، ورفع الملفات، والمحاولات الفاشلة، وإقفال الحسابات، كلها مسجَّلة، كل واحدة منها باسم المستخدم، وعنوان الـ IP الخاص به، والإجراء المحدد، ووقته. وعلى مستوى البطاقة الواحدة ينطبق المبدأ نفسه: كل تغيير في الحالة، وكل رسالة، وكل ملاحظة ومرفق ومحاولة تسليم، مسجَّل على تلك البطاقة. وهذا هو الانضباط الذي يعمل به PCI Tracker فعليًا في QNB الأهلي مصر، حيث يكتب كل إجراء لأي مستخدم متحكّم اسمه وعنوان الـ IP الخاص به ووقته كأمر معتاد. والهدف أن لا يحدث أي أمر مهم دون معرفة صاحبه، فلا تصبح إعادة تجميع القصة ضرورية أصلًا، لأن السجل كان كاملًا من البداية.

افتراض أخير يستحق التخلي عنه

تحت المفاهيم الستة كلها يكمن مفهوم أعمق واحد: أن الالتزام يمكن أن يوضع فوق النظام كطبقة من السياسات والانتباه، بدلًا من أن يكون مبنيًا داخل النظام نفسه. وهذا نادرًا ما يصمد. فالإخفاء الذي يعتمد على تذكّر الناس، وقواعد الوصول التي تُفرَض بالثقة لا بالبرمجيات، وسجلات التدقيق التي تُجمَّع بعد وقوع الأمر، كلها ترتيبات تبدو سليمة حتى يوم اختبارها.

البديل هو جعل السلوك الملتزم هو الخيار الافتراضي والأسهل، من خلال بناء هذه القرارات داخل تطبيق الإصدار نفسه، بحيث يصبح أداء العمل بشكل صحيح وأداؤه بشكل ملتزم شيئًا واحدًا. وسواء كنت تقيّم منصة مثل PCI Tracker أو نظامك الحالي، فهذا هو الاختبار الحقيقي: ليس ما إذا كان الالتزام موعودًا حول النظام، بل ما إذا كان مبنيًا داخله.

الخلاصة العملية

الالتزام على مستوى التطبيق لا يعلن عن نفسه. يظهر في صورة رقم مخفي جزئيًا في موضع كان يمكن أن يظهر فيه رقم كامل، وقيمة لم تُخزَّن أبدًا، وجلسة انتهى وقتها، وسطر في السجل جعل لكل إجراء صاحبًا مسؤولًا. كل قرار هادئ بمفرده. لكنها معًا تفصل بين برنامج بطاقات يصمد أمام التدقيق وآخر يبدو فقط وكأنه يصمد.

أمضينا خمسة وعشرين عامًا في بناء أنظمة لبنوك ومؤسسات لا يكون فيها هذا المستوى من الدقة اختياريًا — ومن بينها PCI Tracker، الذي يعمل فعليًا في QNB الأهلي مصر باعتباره نظام السجل لإصدار البطاقات والأرقام السرية لديه. وإذا كنت تختبر مدى صمود إصدار البطاقات لديك على مستوى التطبيق، يسعدنا أن نستعرضه معك.

الأسئلة الشائعة

الحل وراء هذا المقالPCI Tracker — إصدار البطاقاتالإخفاء الجزئي، ومبدأ أقل الصلاحيات، وسجلات التدقيق الشاملة، مبنيّة داخل طبقة الإصدار تلقائيًا.