بيانات اختبار PCI DSS: ما يجوز حفظه في بيئة الاختبار

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

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

هل ينطبق المعيار على بيئات الاختبار؟

ينطبق. فالنطاق في معيار أمن بيانات صناعة البطاقات مرتبط بنوع البيانات التي تلمسها البيئة، لا بالاسم الذي أعطيته لها. فإذا كان نظام ما يخزن أرقام بطاقات، أو يمررها، أو يمكنه قراءتها، فذلك النظام داخل النطاق، سواء كان اسمه الإنتاج أو التجهيز أو الاختبار.

والسبب عملي بحت. فبيئة الاختبار تحتفظ غالبا بعينات من بيانات الإنتاج ليكون الاختبار واقعيا. وهذه العينات قيم حقيقية قابلة للاستخدام، والمهاجم الذي يعثر عليها لا يفرق بينها وبين بيانات الإنتاج إن كانت بنيتها سليمة.

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

نوعان من البيانات: أرقام البطاقات وبيانات المصادقة

التمييز الأول والأهم هو بين ما يجوز الاحتفاظ به وما يجوز استخدامه فقط. ويصنف المعيار الأرقام في فئة بيانات الحساب، ويصنف العناصر التي تثبت حمل البطاقة في فئة بيانات مصادقة حساسة.

الفرق يقرر ما تستطيع فعله:

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

وهذا الجدول هو الجزء الذي يخالف أكثر من غيره، والسبب أنه يبنى ببطء وبقرارات صغيرة لا تبدو قرارات.

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

ثلاث طرق للحصول على عينات آمنة

إذا كان الاحتفاظ ببيانات حقيقية مقيدا إلى هذا الحد، فمن أين تأتي عينات الاختبار؟ هناك ثلاث إجابات، ولكل منها ثمنها.

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

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

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

لماذا تكون الأرقام المنشأة أكثر أمانا من رقم مقنع؟

قد تبدو المقارنة غير عادلة، لأن الرقم المقنع يأتي من قيمة حقيقية فهو واقعي بحكم تعريفه. لكن الواقعية هنا ليست ميزة.

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

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

ولهذا فإن أداة إنشاء رقم البطاقة هي المصدر المفضل لهذه العينات على هذا الموقع: قيم صحيحة بنيويا لم تصدر قط. وتشرح مقالة أرقام البطاقات للاختبار ما تعنيه هذه العبارة بالضبط وما لا تعنيه.

للمطورين: ضوابط عملية تمنع التسرب

القواعد وحدها لا تكفي؛ التسربات تحدث عبر مسارات لا علاقة لها بالنية. وهذه الضوابط الخمسة هي التي تحقق أكبر فرق.

1. افصل بيانات الاعتماد. يجب ألا يملك أي نظام في بيئة الاختبار مفتاحا يفتح على بيئة الإنتاج. والفصل هنا يعني مفاتيح مختلفة، وحسابات مختلفة، وقواعد وصول مختلفة. أما مشاركة المفتاح نفسه فتسقط الفصل كله.
2. لا تستعد بيئة الاختبار من نسخة إنتاجية. فالاستعادة تنقل البيانات الحقيقية كاملة، ومعها تصير كل ضوابطك على التخزين بلا معنى. وإن كانت الاستعادة ضرورية لسبب ما، فاجعلها تخضع لتحويل قبل أن تفتح للاستخدام.
3. دقق ما يخرج من النظام. السجلات والتصديرات وتقارير الأخطاء ولوحات المراقبة كلها مخارج، وأي واحدة منها يمكن أن تحمل قيمة كاملة. وافحص هذه المخارج كمحتوى لا كإعدادات، لأن الفارق بين مصفاة تعمل وأخرى معطلة لا يظهر في ملف التكوين.
4. قلص ما تحتفظ به أصلا. أغلى خطأ هو الاحتفاظ بقيمة لا تحتاجها. حدد لكل جدول لماذا يحتوي عمودا لبيانات الدفع، واحذف ما لا يجد سببا واضحا.
5. راجع مسارات إعادة المحاولة. فمعالجة الفشل هي الحالة التي تنقل الدفعات من الذاكرة إلى مخزن دائم دون أن يلاحظ أحد، لأن هدفها أن تعيد الإرسال لاحقا.

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

الخطوات التالية

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