PCI DSS परीक्षण डेटा: परीक्षण वातावरण में क्या रखा जा सकता है

हर इंजीनियरिंग टीम के जीवन में एक क्षण आता है जब कोई यह मान लेता है कि चूँकि यह वातावरण परीक्षण का है, इसलिए यहाँ कोई नियम लागू नहीं होते। यह मान्यता महँगी पड़ती है। भुगतान कार्ड उद्योग का मानक वातावरण के नाम पर कोई छूट नहीं देता; वह इस पर देखता है कि किस तरह का मान आपकी प्रणालियों में मौजूद है।

इस लेख में हम उन कुछ नियमों का सार देखेंगे जो परीक्षण कार्यप्रवाह को सबसे ज़्यादा प्रभावित करते हैं, यह समझेंगे कि कौन सा मान संवेदनशील माना जाता है, और यह देखेंगे कि बनाया गया डेटा छिपाए गए असली डेटा से सुरक्षित क्यों है।

वह नियम जो इंजीनियरिंग टीमों को चौंका देता है

नियम सरल है और उसका दायरा पूरी तरह स्पष्ट है: जो मान संग्रहित करना चालू वातावरण में वर्जित है, वह परीक्षण वातावरण में भी वर्जित है। कोई ऐसी धारा नहीं है जो कहे कि परीक्षण प्रणालियाँ अपवाद हैं, और कोई ऐसा प्रावधान नहीं है कि कम ट्रैफ़िक वाला वातावरण कम ज़िम्मेदारी वाला होता है।

इसका व्यावहारिक अर्थ यह है कि प्रश्न यह नहीं है कि आपका वातावरण किस नाम से पुकारा जाता है, बल्कि यह कि उसमें क्या पड़ा है। जिस डेटाबेस में असली कार्ड के सुरक्षा कोड भरे पड़े हैं, वह परीक्षण वातावरण कहलाने से सुरक्षित नहीं हो जाता। जो स्टेजिंग प्रणाली उत्पादन का कोई प्रतिबिंब है, वह अपने जुड़वाँ की सारी बाध्यताएँ विरासत में पाती है।\n\nइसकी एक और परत है जो अक्सर अनदेखी रह जाती है। नियम मान की यात्रा पर भी लागू होते हैं। यदि उत्पादन से डेटा परीक्षण वातावरण में कॉपी किया जाता है, तो जो डेटा उठाया गया है वह अपने साथ अपनी शर्तें लेकर आता है, और वह अब उस प्रणाली की समस्या नहीं रहती जहाँ से आया था। जो पथ उत्पादन में निषिद्ध मान को हटा देते हैं, उन्हें प्रतिलिपि बनाते समय भी लागू करना होगा, अन्यथा मान पूरी सीमा को चुपचाप पार कर जाता है।

क्या PCI DSS परीक्षण वातावरणों पर लागू होता है?

हाँ। मानक किसी नेटवर्क को यह कहते हुए बाहर नहीं रखता कि वह परीक्षण के लिए है। जो भी प्रणालियाँ कार्ड के मान संग्रहित, संसाधित या संचारित करती हैं, वे दायरे में आती हैं, और यह इस पर निर्भर नहीं करता कि परिसर के भीतर कोई उन्हें किस नाम से जानता है।

इसलिए सही सवाल यह होता है कि आपके वातावरण में किस तरह का मान मौजूद है, न कि वह किन उद्देश्यों के लिए बनाया गया था। जिस सैंडबॉक्स में केवल ऐसे मान हों जो कभी जारी नहीं हुए, उसकी स्थिति ऐसे स्टेजिंग वातावरण से मूल रूप से अलग है जिसमें उत्पादन का कोई हालिया डंप पड़ा हो।

नियम यह भी नहीं कहते कि परीक्षण वर्जित है। परीक्षण पूरी तरह अपेक्षित है; जो वर्जित है वह असली कार्ड का परीक्षण के लिए दोबारा उपयोग है, क्योंकि हर हजार टेस्ट रिकॉर्ड में अदायगी करने वाले असली ग्राहकों की संख्या बढ़ती जाती है और हर अतिरिक्त प्रतिलिपि किसी डेटा उल्लंघन की कीमत बढ़ा देती है।

संवेदनशील प्रमाणीकरण डेटा में क्या गिना जाता है?

कार्ड से जुड़े मान कई परतों में बाँटे गए हैं, और यह बँटवारा याद रखना उपयोगी है क्योंकि हर श्रेणी के साथ अलग आचरण जुड़ा है।

सुरक्षा कोड और पूरा पट्टी-डेटा ऐसे मान हैं जिन्हें एक बार इस उद्देश्य से पढ़े जाने के बाद रखा ही नहीं जा सकता। इनका जीवन केवल उस एक अनुरोध तक है जिसमें ये आए थे, और इन्हें लॉग, डिबग आउटपुट, त्रुटि रिपोर्ट या डेटाबेस में दर्ज करना तकनीकी रूप से आसान है और नीति के अनुसार वर्जित।

इसीलिए जब किसी परीक्षण प्रतिलेख या बग रिपोर्ट में पूरा कार्डचित्र दिखे तो उसे उतनी ही गंभीरता से लेना चाहिए जितनी किसी उत्पादन घटना को। अंतर केवल यह है कि इस बार दर्ज किया गया मान किसी परीक्षण फ़ाइल से आया था, जो आगे किसी ऑडिट में मदद नहीं करता।

छिपाना, सांकेतिकरण और संश्लेषित डेटा

असली मान को छोटा करके कुछ अंक दिखाना उसे उपयोगी तो बना देता है, पर कई अनुप्रयोगों में काफी नहीं होता। छिपाया गया मान पहचान के लिए अच्छा रहता है, क्योंकि आप देख सकते हैं कि कोई पंक्ति किस ग्राहक की है, और वह मान संसाधित करने के लिए अनुपयुक्त रहता है क्योंकि उसके बाकी अंक लुप्त हैं।\n\nसांकेतिकरण एक कदम आगे जाता है। असली मान को किसी टोकन से बदल दिया जाता है, और असली मान सुरक्षित किसी स्थान पर अलग रखा जाता है। यह वास्तुकला अच्छी है, पर उस शेष स्थान की सुरक्षा और भी कड़ी होनी चाहिए, क्योंकि अब सारा महत्व वहीं इकट्ठा हो गया है।

तीसरा रास्ता संश्लेषित डेटा है: ऐसे मान जो प्रारूप की दृष्टि से कार्ड जैसे दिखते हैं और किसी भी असली खाते से जुड़े नहीं होते। इस तरीके का लाभ यह है कि प्रणालियों को शक्ल बदलने की ज़रूरत ही नहीं पड़ती। परीक्षण प्रणालियाँ वही सत्यापन चलाती हैं, वही क्षेत्र-लंबाइयाँ माँगती हैं, और वही त्रुटि-पथ परखती हैं, पर उनके भीतर ऐसा डेटा होता है जिसका पता किसी ग्राहक तक नहीं जाता।

बनाया गया नंबर छिपाए हुए असली नंबर से बेहतर क्यों है?

छिपाया गया असली नंबर अभी भी असली नंबर है। उसमें ऐसी जानकारी बची रहती है जिससे किसी व्यक्ति तक पहुँचा जा सकता है, वह अति-संवेदनशील श्रेणी में आता है और इसलिए उसके साथ वही सुरक्षा उपाय, वही सीमाएँ और वही प्रलेखन चाहिए।

बनाया गया नंबर किसी की नहीं है। यदि वह लीक भी हो जाए, तो कोई ग्राहक प्रभावित नहीं होता, कोई सूचना देने की बाध्यता नहीं बनती, और कोई तुलनात्मक अध्ययन किसी व्यक्ति को पहचान नहीं पाता। यह ऐसी संपत्ति है जिसका मूल्य परीक्षण वातावरण में वही है और जोखिम शून्य है।

यही कारण है कि परीक्षण की प्राथमिक व्यवस्था बनाया गया डेटा होना चाहिए। असली डेटा की आवश्यकता तब पड़ती है जब किसी विशेष जारीकर्ता के व्यवहार की पुष्टि करनी हो, और वह कार्य किसी संकीर्ण, नियंत्रित, प्रलेखित प्रक्रिया में होना चाहिए, न कि विकास के दौरान सामान्य सुविधा की तरह।

डेवलपर के लिए: परीक्षण को उत्पादन से अलग रखना

अधिकांश टीमों में अलगाव पहले से होता है, पर वह पूरा नहीं होता। वही रास्ते जो आपकी सुविधा के लिए हैं, उत्पादन के डेटा के लिए भी रास्ते बन जाते हैं।

कुछ आदतें अंतर पैदा करती हैं। नए नाम अजनबी लगते हैं, इसलिए जाँच लें कि कर्षण-आधारित प्रतिलिपियाँ वाकई ऐसी प्रणालियों की ओर जाती हैं जिनमें वर्जित मान कभी प्रवेश न करें। और शुद्ध करने की प्रक्रिया उसी स्थान पर चलनी चाहिए जहाँ डेटा उत्पन्न होता है, न कि उपभोक्ता के पास, क्योंकि उपभोक्ता बदलते रहते हैं और हर बदलाव एक अवसर बन जाता है।

लॉग पर भी ध्यान दें। अनुरोध की निगरानी करने वाली प्रणालियाँ अक्सर पूरा अदायगी-अनुरोध दर्ज कर देती हैं, और वह प्रविष्टि कई सप्ताह तक किसी संग्रह में पड़ी रह सकती है। जो भी लॉग एकत्र होता है, उसे उसी दिन हटाया जाना चाहिए जिस दिन वह बने, और ऐसी सुविधा चालू रखनी चाहिए जो जानबूझकर गोपनीय क्षेत्रों को छिपा देती हो।

परीक्षण डेटा बनाते समय प्रारूप की नकल करें, किसी विशेष खाते की नहीं। कार्ड नंबर जनरेटर प्रीफ़िक्स, लंबाई और चेकसम की दृष्टि से सही मान बनाता है, इसलिए आपकी प्रणालियाँ उन्हें उसी तरह स्वीकार करती हैं जैसे असली मान को करतीं, बिना किसी ग्राहक को छूने के। प्रारूप गाइड बताती है कि किस नेटवर्क के लिए कौन सी लंबाई अपेक्षित है, और भुगतान फ़ॉर्म जाँच सूची उन प्रवाहों की सूची देती है जिनमें यह डेटा आना चाहिए।

अनुपालन संबंधी डेटा कहाँ से लें

आधिकारिक मार्गदर्शन और सार्वजनिक दस्तावेज़ PCI Security Standards Council की साइट पर उपलब्ध हैं। वही अद्यतन स्रोत मानें — किसी ब्लॉग पोस्ट को नहीं, अपने ही पुराने आंतरिक नोट को भी नहीं।

अपने संगठन के भीतर पहला कदम यह नहीं होना चाहिए कि कोई नई नीति लिखी जाए, बल्कि यह कि यह देखा जाए कि इस समय किस प्रणाली में क्या पड़ा है। वह जाँच अप्रिय निकल सकती है, पर वही आगे की समीक्षा का आधार बनती है।

आगे क्या करें

उन प्रणालियों की सूची बनाएं जहाँ अदायगी-संबंधी मान पहुँच सकता है, और हर एक के लिए यह दर्ज करें कि उसमें कौन सी श्रेणी का डेटा मौजूद है। जिनमें वर्जित श्रेणियाँ मिलें, उन्हें पहले ठीक करें, और उसके बाद उस प्रक्रिया का दस्तावेज़ बनाएं जिससे परीक्षण मान बनते और नवीनीकृत होते हैं।