डेटा इंजीनियरिंग इंटरव्यू: आप एक ऑडिट करने योग्य डेटा-एक्सेस गवर्नेंस लेयर कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

व्यावसायिक डेटा ऑब्जेक्ट स्टोरेज, लेकहाउस टेबल और वेयरहाउस में रहता है; विश्लेषक SQL, Spark और BI टूल्स का उपयोग करते हैं। एक्सेस को मैन्युअल टिकटों और स्थानीय इंजन खातों के माध्यम से प्रबंधित किया जाता है। ऑफ़बोर्डिंग धीमी है, और ऑडिट क्रॉस-अकाउंट क्वेरीज़ का पुनर्निर्माण नहीं कर सकता है। लक्ष्य हैं: सेल्फ़-सर्विस अनुरोध, न्यूनतम विशेषाधिकार (least privilege), पंक्ति और कॉलम सुरक्षा, आपातकालीन पहुंच (emergency access), और एक एकीकृत ऑडिट ट्रेल।

गवर्नेंस लेयर को डिज़ाइन करें: वर्गीकरण, अनुमोदनकर्ता, नीति निर्णय और प्रवर्तन बिंदु (policy decision and enforcement points), मल्टी-इंजन कवरेज, ब्रेक-ग्लास, निरसन (revocation), कैश, निर्यात, और यह प्रमाण कि प्राधिकरण (authorization) और वास्तविक पठन (actual reads) दोनों ऑडिट योग्य हैं। मुख्य कौशल डेटा-प्लेटफ़ॉर्म गवर्नेंस और संचालन है, इसलिए यह एक डेटा प्रश्न है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता केवल "RBAC जोड़ें" के बजाय कैटलॉग, नीति, प्रवर्तन, साक्ष्य और संचालन के एक लूप की तलाश करता है। मजबूत उत्तर पहचान (identity), उद्देश्य, संसाधन लेबल, पंक्ति/कॉलम फ़िल्टर और मास्किंग में अंतर स्पष्ट करते हैं, और निर्णय व प्रवर्तन के बीच की सीमा की व्याख्या करते हैं।

वे क्रॉस-सर्विस निरंतरता को भी संबोधित करते हैं। एक ही उपयोगकर्ता जो Athena, Spark, BI, या किसी निर्यात कार्य (export job) तक पहुंच रहा है, उसका प्राधिकरण संदर्भ या ऑडिट फ़ील्ड समाप्त नहीं होने चाहिए। लॉग छेड़छाड़-रोधी (tamper-evident), खोजने योग्य, जानबूझकर बनाए रखे गए (retained) होने चाहिए, और उनमें केवल सफल क्वेरी ही नहीं, बल्कि अस्वीकृतियां (denials), प्रशासनिक परिवर्तन और आपातकालीन पहुंच भी शामिल होनी चाहिए।

पहले स्पष्ट करने योग्य प्रश्न

• कौन से डेटा स्रोत, इंजन, पहचान प्रदाता (identity provider), और क्रॉस-अकाउंट सीमाएं मौजूद हैं?
• कौन से कॉलम व्यक्तिगत, वित्तीय, या अनुबंध-प्रतिबंधित हैं, और वर्गीकरण का प्रबंधन कौन करता है?
• क्या एक्सेस का निर्णय भूमिकाओं, विशेषताओं (attributes), उद्देश्य, किरायेदार (tenant), पंक्ति/कॉलम फ़िल्टर, या इनके संयोजन द्वारा किया जाता है?
• क्या अनुमोदन एकमुश्त हैं, नवीकरणीय हैं, या प्रति क्वेरी आवश्यक हैं?
• आपातकालीन पहुंच के लिए अधिकतम अवधि, अनुमोदनकर्ता और समीक्षा प्रक्रिया क्या है?
• क्या सिस्टम स्कैन किए गए दायरे, लौटाए गए पंक्तियों, निर्यात गंतव्य और सेवा पहचान को रिकॉर्ड कर सकता है?

एक 30-सेकंड का उत्तर

"मैं एक स्वामित्व वाला कैटलॉग और संवेदनशीलता लेबल बनाऊंगा, फिर पहचान, टीम, उद्देश्य, क्षेत्र और संसाधन लेबल को एक नीति निर्णय बिंदु पर भेजूंगा। प्रत्येक इंजन या डेटा प्रॉक्सी पर प्रवर्तन समय-बद्ध अनुदानों के साथ पंक्ति/कॉलम फ़िल्टर और मास्किंग लागू करेगा। अनुमति, अस्वीकृति, नीति संस्करण, क्वेरी संसाधन, सेवा पहचान और निर्यात ईवेंट एक केंद्रीकृत छेड़छाड़-रोधी स्ट्रीम में दर्ज होंगे। ब्रेक-ग्लास एक्सेस समाप्त हो जाएगा और समीक्षा शुरू करेगा। मैं निरसन, क्रॉस-अकाउंट संदर्भ, कैश और नीति विचलन (policy drift) का परीक्षण करूंगा ताकि यह साबित हो सके कि वास्तविक पठन ऑडिट ट्रेल से मेल खाते हैं।"

चरण-दर-चरण समाधान

टेबल्स, कॉलम, पाथ्स, टॉपिक्स, किरायेदारों और व्युत्पन्न डेटा (derived data) के लिए एक एसेट इन्वेंट्री बनाएं। प्रत्येक एसेट को एक स्वामी, वर्गीकरण, स्रोत, प्रतिधारण (retention) और स्वीकृत उद्देश्यों की आवश्यकता होती है। वर्गीकरण एक बार का स्कैन नहीं हो सकता: स्कीमा परिवर्तन, नए कॉलम और व्यावसायिक नियमों के परिवर्तन समीक्षा को ट्रिगर करते हैं। अनिश्चित संवेदनशील फ़ील्ड्स को समीक्षा होने तक रूढ़िवादी (conservative) लेबल मिलने चाहिए।

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

सेल्फ़-सर्विस अनुरोध उद्देश्य, फ़ील्ड, अवधि और स्वामी दिखाते हैं। कम जोखिम वाले पूर्व-स्वीकृत उपयोग स्वचालित रूप से अल्पकालिक भूमिकाएं प्राप्त कर सकते हैं; संवेदनशील पहुंच के लिए डेटा स्वामी या अनुपालन (compliance) अनुमोदन की आवश्यकता होती है। अनुदान जल्दी समाप्त हो जाते हैं और जानबूझकर नवीनीकृत किए जाते हैं। ऑफ़बोर्डिंग, टीम परिवर्तन और प्रोजेक्ट पूरा होने पर निरसन ट्रिगर होता है। अनुमोदन साक्ष्य को उस नीति संस्करण से जोड़ें जो वास्तव में लाइव हुआ था।

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

एक ऑडिट ईवेंट में विषय, पहचान श्रृंखला, उद्देश्य, संसाधन, पंक्ति/कॉलम निर्णय, नीति संस्करण, इंजन, क्वेरी या जॉब आईडी, समय, स्रोत खाता, स्कैन या लौटाया गया आकार, निर्यात गंतव्य, और अनुमति या अस्वीकृति शामिल होनी चाहिए। अपरिवर्तनीय (immutable) स्टोरेज में कम-विशेषाधिकार प्राप्त अपेंड पाथ्स और नियंत्रित पाठकों पर लिखें; विलोपन और छेड़छाड़ का पता लगाने के लिए चेकसम या संस्करण श्रृंखला का उपयोग करें। अस्वीकृतियां और नीति संपादन सफल क्वेरीज़ जितने ही महत्वपूर्ण हैं।

सभी इंजनों और खातों में मूल उपयोगकर्ता और सेवा पहचान को सुरक्षित रखें। उपयोगकर्ता की ओर से कार्य करने वाली सेवा अपनी प्रतिनिधिमंडल श्रृंखला (delegation chain) रखती है; क्रॉस-अकाउंट ईवेंट संसाधन स्वामी को कॉपी किए जाते हैं। एक पुराना इंजन जो संदर्भ नहीं ले जा सकता है, उसे अलग किया जाता है, प्री-फ़िल्टर किए गए दृश्यों तक सीमित किया जाता है, या अनुपालन घोषित करने के बजाय ऑडिट अंतर (audit gap) के रूप में चिह्नित किया जाता है।

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

मॉडल उत्तर

"मैं एक स्वामित्व वाला कैटलॉग और संवेदनशीलता लेबल बनाऊंगा जो स्रोत, व्युत्पन्न, ऑब्जेक्ट पाथ और निर्यात को कवर करता है। एक नीति निर्णय बिंदु पहचान, टीम, उद्देश्य, क्षेत्र और संसाधन लेबल प्राप्त करेगा और अनुमति, अस्वीकृति, पंक्ति/कॉलम फ़िल्टर, मास्किंग, नीति संस्करण और समाप्ति लौटाएगा। प्रवर्तन एक प्रॉक्सी या इंजन प्लगइन में स्थित होगा, जबकि कच्चे ऑब्जेक्ट पाथ दुर्गम बने रहेंगे।

अनुरोध उद्देश्य, दायरा, अवधि और स्वामी बताएंगे; संवेदनशील पहुंच के लिए अनुमोदन की आवश्यकता होगी, और ऑफ़बोर्डिंग या प्रोजेक्ट पूरा होने पर अनुदान समाप्त हो जाएंगे। वही पंक्ति/कॉलम नीति अस्थायी टेबल, कैश और निर्यात पर लागू होगी ताकि उपयोगकर्ता किसी प्रतिलिपि के माध्यम से मानों का पुनर्निर्माण न कर सकें।

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

सामान्य गलतियाँ

• केवल RBAC डिज़ाइन करना → उद्देश्य, क्षेत्र और कॉलम सीमाएं गायब हो जाती हैं → पहचान, विशेषताओं, लेबल और फ़िल्टर को संयोजित करें।
• केवल क्वेरी इंजन की सुरक्षा करना → उपयोगकर्ता ऑब्जेक्ट स्टोरेज के माध्यम से इसे बायपास करते हैं → कच्चे पाथ को सुरक्षित करें और एक एक्सेस सीमा लागू करें।
• केवल एक साझा ETL खाते को लॉग करना → उपयोगकर्ता जवाबदेही गायब हो जाती है → प्रतिनिधिमंडल श्रृंखला को बनाए रखें।
• केवल सफल प्रश्नों को रिकॉर्ड करना → अस्वीकृतियां और विचलन गायब हो जाते हैं → अस्वीकृतियों, नीति संपादनों और आपातकालीन उपयोग को रिकॉर्ड करें।
• स्थायी अनुदान → प्रोजेक्ट एक्सेस हमेशा के लिए जीवित रहता है → संक्षिप्त समाप्ति, नवीनीकरण और निरसन लागू करें।
• केवल स्रोत तालिकाओं की सुरक्षा करना → कैश, निर्यात और भौतिकीकरण लीक होते हैं → प्रत्येक व्युत्पन्न पाथ पर नीति लागू करें।
• ब्रेक-ग्लास द्वारा ऑडिट को बायपास करना → आपातकालीन पाथ एक बैकडोर बन जाता है → मजबूत प्रमाणीकरण, कारण, समाप्ति, अलर्ट, समीक्षा।
• केवल नीति आउटपुट का परीक्षण करना → फ़िल्टर बायपास किए जा सकते हैं → वास्तविक पठन, निर्यात, सिंथेटिक पहचान और हनी कॉलम का परीक्षण करें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: RBAC या ABAC?

स्थिर टीम सीमाओं के लिए भूमिकाओं (roles) का और गतिशील उद्देश्य, क्षेत्र, लेबल और समय के लिए विशेषताओं (attributes) का उपयोग करें। अधिकांश वास्तविक प्रणालियां नीति जटिलता को सीमित करते हुए दोनों को जोड़ती हैं।

अनुवर्ती 2: आप एग्रीगेट्स के माध्यम से पुनर्निर्माण को कैसे रोकते हैं?

छोटे समूहों (small cohorts), जॉइन, अंतर प्रश्नों (differencing queries) और निर्यात आवृत्ति को सीमित करें; जहां उपयुक्त हो वहां थ्रेशोल्ड या नॉइज़ का उपयोग करें। संवेदनशीलता और सटीकता आवश्यकताओं के विरुद्ध नियमों को मान्य करें।

अनुवर्ती 3: आप कैश पठन का ऑडिट कैसे करते हैं?

कैश कुंजियों को विषय और नीति संस्करण से बांधें, फ़िल और रीड पहचान श्रृंखलाओं को रिकॉर्ड करें, और निरसन या नीति परिवर्तन पर अमान्य (invalidate) करें। उपयोगकर्ता संदर्भ के बिना साझा किए गए कैश में संवेदनशील परिणाम नहीं होने चाहिए।

अनुवर्ती 4: क्या होगा यदि ऑडिट लॉग में संवेदनशील SQL शामिल है?

पूर्ण SQL, पैरामीटर या कच्चे डेटा के बजाय संरचित संसाधन पहचानकर्ता और सुरक्षित सारांश संग्रहीत करें। ऑडिट फ़ील्ड्स को जानबूझकर एन्क्रिप्ट करें, प्रतिबंधित करें और बनाए रखें।

अनुवर्ती 5: क्या होगा यदि कोई लीगेसी इंजन पंक्ति या कॉलम नीति लागू नहीं कर सकता है?

इसे अलग करें, केवल प्री-फ़िल्टर किए गए दृश्य उजागर करें, या इसे प्रॉक्सी के पीछे माइग्रेट करें, और शेष ऑडिट अंतर को चिह्नित करें। टीम का रिवाज कोई प्रवर्तन नहीं है।

अनुवर्ती 6: आप कैसे साबित करते हैं कि गवर्नेंस विश्लेषण को धीमा नहीं करता है?

निर्णय विलंबता, क्वेरी p95, गलत अस्वीकृतियां (false denials), कैश हिट दर और अनुमोदन समय को ट्रैक करें। पहचान या नीति-संस्करण परिवर्तनों पर कैश्ड निर्णयों को तुरंत अमान्य करें।

अनुवर्ती 7: नीति संस्करणों को क्यों रिकॉर्ड करें?

एक ही क्वेरी नीति अपडेट से पहले और बाद में अलग-अलग परिणाम दे सकती है। एक संस्करण यह बताता है कि पहुंच की अनुमति क्यों दी गई, अस्वीकार किया गया, या फ़िल्टर किया गया और यह रोलबैक और घटना समीक्षा का समर्थन करता है।