GDPR टेस्ट डेटा यह वाक्यांश आम तौर पर एक असहज एहसास के साथ आता है: जिस स्टेजिंग डेटाबेस से सब लोग बेधड़क क्वेरी चला रहे थे, उसमें असली नाम, असली पते और असली पहचान संख्याएं पड़ी हैं, और किसी ने कभी फ़ैसला नहीं किया कि ऐसा होना चाहिए। वह बस सुविधाजनक था।
यह लेख बताता है कि टेस्ट रिकॉर्ड में व्यक्तिगत डेटा किसे गिना जाता है, डेवलपमेंट एनवायरनमेंट प्रोडक्शन की प्रतिलिपियों के लिए गलत जगह क्यों हैं, डेटा को छिपाने और हटाने में क्या फ़र्क़ है, और एक कामचलाऊ विकल्प कैसा दिखता है।
यहां व्यक्तिगत डेटा किसे माना जाता है?
उससे कहीं ज़्यादा को, जितना लोग सोचते हैं, और सूची तकनीकी नहीं बल्कि व्यवहार की है। नाम, पहचान संख्या, जन्म तिथि, घर का पता, टेलीफ़ोन नंबर और ईमेल पता इसके साफ़ सदस्य हैं। कम साफ़ वाले भी इनमें जुड़ जाते हैं: कोई तस्वीर, किसी डिवाइस का पहचानकर्ता, स्थान का रिकॉर्ड, किसी अकाउंट का उपनाम, और सपोर्ट सिस्टम में लिखी कोई भी ऐसी टिप्पणी जो संयोग से किसी का वर्णन कर दे।
- साफ़ सदस्य: नाम, पहचान संख्या, जन्म तिथि, घर का पता, टेलीफ़ोन नंबर और ईमेल पता
- कम साफ़ वाले: कोई तस्वीर, किसी डिवाइस का पहचानकर्ता, स्थान का रिकॉर्ड, किसी अकाउंट का उपनाम
- यह भी व्यक्तिगत है: सपोर्ट सिस्टम में लिखी कोई भी टिप्पणी जो संयोग से किसी का वर्णन करती हो
यह अवधारणा फ़ील्ड के नहीं, व्यक्ति के संदर्भ में परिभाषित होती है। डेटा तब व्यक्तिगत होता है जब वह सीधे या परोक्ष रूप से किसी पहचाने जा सकने वाले व्यक्ति से जुड़ता है, यानी व्यक्तिगत होने के लिए फ़ील्ड में नाम होना ज़रूरी नहीं। जन्म तिथि, पोस्टल कोड और पद का नाम रखने वाला रिकॉर्ड भी व्यक्तिगत हो सकता है, अगर ये तीनों मिलकर उस आबादी में एक ही व्यक्ति को चुन लें जिसका यह डेटा है।
यही परिभाषा टेस्ट एनवायरनमेंट के सवाल को औपचारिकता से ज़िंदा मुद्दा बना देती है। अगर स्टेजिंग डेटाबेस में इसमें से कुछ भी है, तो स्टेजिंग व्यक्तिगत डेटा प्रोसेस कर रही है, और रखरखाव, पहुंच और सुरक्षा पर हर बहस अब ऐसे सिस्टम पर लागू होती है जो बिना इनके बनाया गया था।
टेस्ट सिस्टम में प्रोडक्शन डेटा क्यों न रखें?
क्योंकि जो नियंत्रण प्रोडक्शन की रक्षा करते हैं, ठीक वही नियंत्रण निचले एनवायरनमेंट में नहीं होते। प्रोडक्शन में आम तौर पर सीमित पहुंच, एन्क्रिप्टेड स्टोरेज, ऑडिट लॉगिंग और बदलाव की प्रक्रिया होती है। स्टेजिंग में आम तौर पर इनमें से कुछ भी नहीं होता, क्योंकि वह सुविधा के लिए बनी होती है। इसलिए किसी डेटासेट को उसमें कॉपी करना संस्था के पास रखे सबसे संवेदनशील रिकॉर्ड पर सुरक्षा घटा देना है।
इससे तीन नतीजे निकलते हैं, और हर एक अपने ढंग से महंगा है। पहुंच बढ़ जाती है: हर ठेकेदार, हर ऑटोमेटेड टेस्ट अकाउंट और हर वह लैपटॉप जिस पर कोई डंप रिस्टोर हुआ, अब व्यक्तिगत डेटा रखता है। रखरखाव धीरे-धीरे दुर्घटनावश बन जाता है: प्रतिलिपि रीफ़्रेश होती है, भुला दी जाती है, बैकअप में चली जाती है और ऐसी जगह पड़ी रह जाती है जिसका कोई मालिक नहीं। और घटना का दायरा बढ़ जाता है: जब कहीं सामान्य स्तर का लीक होता है, तो सवाल यह नहीं रहता कि कौन से सिस्टम खुले थे बल्कि यह कि प्रतिलिपियां कितनी हैं।
नियामकीय पहलू इंजीनियरिंग वाले से संकरा है पर उसी दिशा में इशारा करता है। व्यक्तिगत डेटा तय किए गए उद्देश्यों के लिए ही इकट्ठा किया जाना चाहिए और उसे उनसे असंगत कामों में इस्तेमाल नहीं किया जाना चाहिए, इसलिए प्रोडक्शन के रिकॉर्ड चुपचाप माइग्रेशन जांचने में लगा देना एक नया उद्देश्य है जिस पर किसी ने सहमति नहीं दी। यह किसी एक कानूनी ढांचे की बात नहीं है; यही तर्क ज़्यादातर गोपनीयता व्यवस्थाओं में दिखता है, इसीलिए व्यावहारिक सलाह एक ही जगह पहुंचती है।
अनामीकरण और स्यूडोनिमाइज़ेशन में क्या फ़र्क़ है?
इन दोनों को लगातार एक ही मान लिया जाता है और ये एक नहीं हैं। स्यूडोनिमाइज़ किए गए डेटा में सीधे पहचानकर्ता किसी कोड से बदल दिए जाते हैं, और वह जोड़ कहीं सहेजा रहता है। उस जोड़ के बिना रिकॉर्ड किसी को नहीं थमाया जा सकता, पर वह कड़ी मौजूद रहती है और जोड़ लीक होने पर उसका पीछा किया जा सकता है। अनामीकृत डेटा पर ऐसी प्रक्रिया चुकी होती है कि व्यक्ति को अब कोई नहीं पहचान सकता, उसे रखने वाली संस्था भी नहीं, और वह बदलाव वापस नहीं पलटा जा सकता।
यही फ़र्क़ तय करता है कि डेटा अब भी व्यक्तिगत है या नहीं। स्यूडोनिमाइज़ किए गए रिकॉर्ड ज़्यादातर मकसदों के लिए व्यक्तिगत बने रहते हैं, क्योंकि कुंजी मौजूद है। ठीक तरीक़े से अनामीकृत रिकॉर्ड नहीं रहते — पर ठीक अनामीकरण सिद्ध करना वाकई कठिन है, और यही कठिनाई टेस्टिंग के लिए प्रोडक्शन डेटा इस्तेमाल करने को इतना घाटे का सौदा बनाती है।
सीधे पहचानकर्ताओं के अलावा एक और जाल है। किसी तालिका से नाम हटा देना उसे अनामीकृत नहीं करता, क्योंकि बचे हुए फ़ील्डों के जोड़े लोगों को पहचान लेते हैं। किसी छोटे कस्बे में एक दुर्लभ पदनाम अकेला ही काफ़ी हो जाता है। कानूनी कसौटी पर सही सवाल यह नहीं कि नाम मौजूद है या नहीं, बल्कि यह कि जो बचा है उससे कोई भी व्यक्ति को, अपनी उपलब्ध या हासिल की जा सकने वाली जानकारी का उपयोग करके, तर्कसंगत ढंग से पहचान सकता है या नहीं।
क्या मास्किंग और मिटाना समस्या सुलझा देते हैं?
मास्किंग संवेदनशील अक्षरों को एक तय पैटर्न से बदल देती है, और दिखाने के लिए यह बढ़िया है: सपोर्ट एजेंट को संख्या के आख़िरी चार अंक दिखें और बाकी छिपा रहे। यह अनामीकरण नहीं है, क्योंकि मूल मान आम तौर पर अब भी सहेजा रहता है, और असली रिकॉर्ड के आगे लगी मास्किंग परत उस असली रिकॉर्ड के बारे में कुछ नहीं करती।
अलग-अलग फ़ील्ड मिटाने में भी वही कमज़ोरी दूसरे रूप में है। नाम हटा दीजिए, रिकॉर्ड में अभी भी पता, जन्म तिथि और टेलीफ़ोन नंबर हैं। पता भी बदल दीजिए, तो बचे फ़ील्ड अब भी उस आबादी में किसी एक व्यक्ति को अलग कर सकते हैं। हर हटाव जोखिम घटाता है, उसे बंद नहीं करता, और ऐसा कोई साफ़ मुक़ाम शायद ही मिलता है जहां कोई सिद्ध कर सके कि जोखिम शून्य हो गया।
एक दस्तावेज़ीकरण की दिक्कत भी है। व्यवहार में टीमें यह नहीं दिखा पातीं कि कौन से रिकॉर्ड ठीक से अनामीकृत हुए और कौन से बस छिपाए गए, क्योंकि बदलाव मौक़े-मौक़े पर हुआ और उसका कोई निशान नहीं छोड़ा। जिस डेटासेट का स्रोत कोई दोबारा न बना सके, उसका बाद में बचाव नहीं किया जा सकता।
प्रोडक्शन की प्रतिलिपियों की जगह क्या आए?
वे रिकॉर्ड जो कभी किसी के थे ही नहीं। यही डेटा इकट्ठा करने के बजाय बनाने के पक्ष में दलील है, और इसीलिए काल्पनिक रिकॉर्ड एक साथ गोपनीयता का सवाल और गुणवत्ता का सवाल हल कर देते हैं। बचाने के लिए कुछ नहीं है, रखने के लिए कुछ नहीं है, लीक करने के लिए कुछ नहीं है, और उद्देश्य की सीमा पर बहस करने की ज़रूरत नहीं, क्योंकि यह डेटा शुरू से किसी व्यक्ति का था ही नहीं।
बनाए गए रिकॉर्ड टेस्ट में भी बेहतर चलते हैं। पहचान और टेस्ट डेटा जनरेटर से बने मान आंतरिक रूप से सुसंगत होते हैं — पता, पोस्टल कोड और टेलीफ़ोन प्रीफ़िक्स एक ही देश के होते हैं, और पहचानकर्ता के प्रारूप उस देश की परंपरा मानते हैं — यानी टेस्ट डेटासेट को हाथ से ठीक करने की ज़रूरत नहीं पड़ती। ये केवल सॉफ़्टवेयर टेस्टिंग के लिए काल्पनिक रिकॉर्ड हैं, और ये किसी असली व्यक्ति का रूप धारण करने या कोई असली पहचान, आयु या पात्रता जांच पास करने के लिए उपयोगी नहीं हैं।
ईमानदार चेतावनी यह है कि काल्पनिक डेटा अपने आप असली दुनिया का हर सहसंबंध दोबारा नहीं बनाता। अगर किसी टेस्ट को वाकई असली डेटा के सांख्यिकीय आकार पर निर्भर होना है, तो वह आकार जानबूझकर मॉडल करना पड़ेगा, और काल्पनिक और अनामीकृत दृष्टिकोणों की तुलना बताती है कि मॉडलिंग में क्या लगता है और वह कहां कम पड़ती है।
व्यक्तिगत डेटा को लॉग और स्क्रीनशॉट से बाहर कैसे रखें?
लीक आम तौर पर डेटाबेस से नहीं होता। वह क्वेरी लॉग से होता है जिसने पूरा रिकॉर्ड उठा लिया, उस एरर रिपोर्ट से जिसमें अनुरोध का पूरा मुख्य भाग चिपक गया, बग टिकट के साथ लगे स्क्रीनशॉट से, विश्लेषण के लिए निकाली गई और साझा ड्राइव में छूटी स्प्रेडशीट से, और उस लोकल डंप से जो किसी ने हवाई जहाज़ पर कोई खामी दोबारा बनाने के लिए ले लिया।
तीन नियंत्रण इसमें से ज़्यादातर हिस्सा घटा देते हैं। पहला, असली रिकॉर्ड उन एनवायरनमेंट से बाहर रखिए जहां लॉग बहुत विस्तृत होते हैं, और यह सीधे इस बात की दलील है कि स्टेजिंग में काल्पनिक डेटा इस्तेमाल हो। दूसरा, किसी स्क्रीनशॉट या एक्सपोर्ट को वही मानिए जो स्क्रीन पर था, और मांग कीजिए कि टेस्ट के सबूत ऐसे एनवायरनमेंट से आएं जिनमें कोई असली रिकॉर्ड न हो। तीसरा, रखरखाव की अवधि साफ़ कीजिए: किसी उद्देश्य के लिए बनी प्रतिलिपि की एक अंतिम तारीख़ होनी चाहिए, और जिस प्रतिलिपि की कोई अंतिम तारीख़ नहीं, वह प्रतिलिपि नहीं, दूसरा प्रोडक्शन डेटाबेस है।
पहुंच की समीक्षा भी यहीं आती है। यह जानना कि डेटासेट तक कौन पहुंच सकता है, तभी काम का है जब यह जवाब हाल ही में जांचा गया हो, और जिस पल कोई प्रतिलिपि चारों तरफ़ बंट जाती है, उसी पल से यह समीक्षा अर्थहीन हो जाती है।
डेवलपर्स के लिए: अलगाव, स्रोत और प्रमाण
डेटा की एक धारा को दूसरे में छानने के बजाय एनवायरनमेंट अलग रखिए। डेवलपमेंट एनवायरनमेंट में डेटा बनाने वाला चरण भरना चाहिए, कभी प्रोडक्शन से रिस्टोर नहीं, और डेवलपमेंट से प्रोडक्शन तक का कनेक्शन होना ही नहीं चाहिए — केवल इस्तेमाल न होना काफ़ी नहीं।
डेटा का स्रोत डेटासेट में ही चिह्नित कीजिए। ऐसा निशान जो कहता है कि ये पंक्तियां काल्पनिक हैं और केवल टेस्टिंग के लिए हैं, एक्सपोर्ट, स्क्रीनशॉट और सपोर्ट टिकट सब के पार जीवित रहता है, और बाद में पढ़ने वाले को यह बता देता है कि उसके सामने क्या है। यह सबसे सस्ती सुरक्षा है और सबसे ज़्यादा छोड़ी जाने वाली।
आख़िर में उस सवाल का जवाब तैयार रखिए जो कोई ऑडिटर पूछेगा: आपको कैसे पता कि इस डेटासेट में कोई असली रिकॉर्ड नहीं है? जो बनाने वाला चरण एक सीड से चलता है और कभी प्रोडक्शन स्रोत नहीं पढ़ता, वह ऐसा जवाब है जिसे सिद्ध किया जा सकता है। जो पाइपलाइन प्रोडक्शन के निर्यात को बदलकर बनी हो, वह नहीं, चाहे समीक्षा में वह बदलाव कितना भी पूरा दिखे। सत्यापन योग्य अनुपस्थिति हर बार सिद्ध करने लायक छिपाव से बेहतर है।
अगले कदम
पता कीजिए कि आपका स्टेजिंग डेटाबेस प्रोडक्शन डंप से रिस्टोर हुआ था या नहीं, और अगर हुआ था तो अगली तिमाही समीक्षा से पहले उसे बनाए गए रिकॉर्ड से बदलने का मामला रखिए। फिर पिछले महीने की कोई बग रिपोर्ट उठाइए और गिनिए कि उसके भीतर किसी असली व्यक्ति के विवरण कितनी जगह गए — लॉग, अटैचमेंट, स्क्रीनशॉट — क्योंकि वही गिनती है जिससे विकल्प को मुकाबला करना है। जब बदलाव करें, तो पहला बैच पहचान जनरेटर में बनाइए और आयात से पहले हर पंक्ति को काल्पनिक चिह्नित कीजिए; सुसंगतता के नियमों की जांच पहचान फ़ील्ड सुसंगतता में समझाई गई है।