प्रॉम्प्ट और दायरा
एक मल्टी-टेनेंट ऑडिट लॉग सर्विस डिज़ाइन करें जो सुरक्षा- और अनुपालन-संबंधित कार्यों को रिकॉर्ड करती है: साइन-इन, अनुमति परिवर्तन, डेटा एक्सेस और कॉन्फ़िगरेशन अपडेट। जांचकर्ताओं को खोजने योग्य (searchable) इतिहास और सत्यापन योग्य एक्सपोर्ट की आवश्यकता होती है, जबकि लॉगिंग आउटेज के दौरान भी एप्लिकेशन ट्रैफ़िक उपलब्ध रहना चाहिए।
इंटीग्रिटी के वादे को सटीकता से परिभाषित करें। AWS CloudTrail एक अपरिवर्तनीय (immutable), खोजने योग्य इवेंट इतिहास का वर्णन करता है, जबकि OpenTelemetry एक सामान्य स्ट्रक्चर्ड लॉग मॉडल प्रदान करता है; इनमें से कोई भी यह दावा नहीं करता है कि कोई इवेंट उत्सर्जित होने से पहले सही था। आपके डिज़ाइन में यह स्पष्ट होना चाहिए कि सर्विस क्या साबित कर सकती है।
इंटरव्यूअर क्या जांच रहा है
वे ड्यूरेबल इनजेशन, अपेंड-ओनली स्टोरेज, इंटीग्रिटी वेरिफिकेशन, टेनेंट आइसोलेशन, रिटेंशन पॉलिसी और ऑपरेशनल ट्रेड-ऑफ की जांच कर रहे हैं। एक अच्छा उत्तर ऑडिट साक्ष्य को सामान्य डिबग लॉग से अलग करता है और बताता है कि ओवरलोड के दौरान सुरक्षा इवेंट्स को खोने या बदलने से कैसे बचाया जाए।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- कौन से कार्य अनिवार्य हैं, और अपेक्षित इवेंट्स-प्रति-सेकंड और बर्स्ट आकार क्या है?
- क्या आवश्यकता टैम्पर-एविडेंट, टैम्पर-रेसिस्टेंट या बाहरी रूप से प्रमाणित करने योग्य (externally attestable) है?
- यदि कोई ऑडिट इवेंट स्वीकार नहीं किया जा सकता है, तो क्या एप्लिकेशन अनुरोध विफल होना चाहिए?
- प्रत्येक टेनेंट को कितने समय तक इवेंट्स बनाए रखने चाहिए, और क्या लीगल होल्ड (legal holds) विलोपन को ओवरराइड करते हैं?
- किसी अन्य टेनेंट के डेटा को कौन खोज, एक्सपोर्ट या सत्यापित कर सकता है?
- जांचकर्ताओं को किन क्वेरी आयामों और एक्सपोर्ट फ़ॉर्मैट की आवश्यकता है?
30-सेकंड का उत्तर ढांचा
“मैं एक रीजनल इनजेशन API और एक स्थानीय ड्यूरेबल बफ़र प्रस्तुत करूँगा ताकि एप्लिकेशन कॉल सर्च इंडेक्स पर निर्भर न हों। प्रत्येक इवेंट में टेनेंट, एक्टर, एक्शन, टारगेट, रिक्वेस्ट कोरिलेशन, इवेंट का समय, इनजेस्ट का समय, स्कीमा संस्करण और स्रोत शामिल होता है। एक अपेंड-ओनली लॉग को टेनेंट और समय के अनुसार पार्टिशन करें, इसे रेप्लिकेट करें, और एक हैश चेन या हस्ताक्षरित सेगमेंट मेनिफेस्ट बनाएं ताकि बाद के संपादन पकड़ में आ सकें। हॉट सर्च करने योग्य इंडेक्स को अपरिवर्तनीय रिटेंशन स्टोरेज से अलग रखें। टेनेंट-स्कोप वाले ऑथराइजेशन, रिटेंशन और लीगल होल्ड लागू करें, और वेरिफिकेशन मेटाडेटा के साथ एक एक्सपोर्ट प्रदान करें। स्वीकृत बनाम ड्रॉप किए गए इवेंट्स, इनजेशन लैग, इंटीग्रिटी जांच और एक्सपोर्ट पूर्णता की निगरानी करें।”
चरण-दर-चरण गहन विश्लेषण
चरण 1: इवेंट अनुबंध परिभाषित करें
एक इवेंट ID, टेनेंट ID, एक्टर और प्रमाणीकरण संदर्भ, एक्शन, टारगेट, परिणाम, स्रोत सर्विस, रिक्वेस्ट ID, इवेंट का समय, इनजेस्ट का समय, स्कीमा संस्करण और चयनित विशेषताओं की आवश्यकता रखें। सीक्रेट्स और अनावश्यक पेलोड को रिकॉर्ड से बाहर रखें; इसके बजाय एक संदर्भ या एक संक्षिप्त सारांश (redacted summary) रिकॉर्ड करें।
चरण 2: स्वीकृति को इंडेक्सिंग से अलग करें
सफलता तभी लौटाएं जब इवेंट किसी ड्यूरेबल बफ़र या रेप्लिकेटेड लॉग तक पहुँच जाए। इसके बाद कंज्यूमर एसिंक्रोनस रूप से सर्च इंडेक्स और एक्सपोर्ट का निर्माण करते हैं। यह सर्च-क्लस्टर की किसी घटना को साक्ष्य को चुपचाप हटाने या हर एप्लिकेशन अनुरोध को इंडेक्सिंग की प्रतीक्षा करने से रोकता है।
चरण 3: इंटीग्रिटी को सत्यापन योग्य बनाएं
प्रत्येक इवेंट को कैनोनिकलाइज़ करें, इसे पूर्व इवेंट या सेगमेंट रूट के साथ हैश करें, और समय-समय पर एक अलग ट्रस्ट डोमेन में मेनिफेस्ट पर हस्ताक्षर करें या एंकर करें। सीक्वेंस गैप और वेरिफिकेशन परिणामों को स्टोर करें। एक हैश चेन इनजेशन के बाद के परिवर्तनों का पता लगाती है; यह यह साबित नहीं करती है कि अपस्ट्रीम सर्विस ने एक सच्चा इवेंट उत्सर्जित किया था।
append(event):
canonical = canonicalize(event)
record.hash = H(previous_hash || canonical)
durable_log.append(record)
return accepted(record.event_id, record.hash)चरण 4: पार्टिशन और रेप्लिकेट करें
हॉट टेनेंट्स को वितरित करने के लिए हैश या टेनेंट की (key) के साथ, टेनेंट और समय के अनुसार पार्टिशन करें। ड्यूरेबिलिटी लक्ष्य के अनुसार पावती (acknowledgment) देने से पहले विफलता डोमेन के पार रेप्लिकेट करें। प्रति टेनेंट या समुच्चय के अनुसार क्रम बनाए रखें, लेकिन जब तक लागत उचित न हो, ग्लोबल ऑर्डरिंग का वादा न करें।
चरण 5: हॉट सर्च और कोल्ड रिटेंशन का निर्माण करें
जांचकर्ता प्रश्नों के लिए हाल के इवेंट्स को इंडेक्स करें और पुराने सेगमेंट्स को अपरिवर्तनीय ऑब्जेक्ट स्टोरेज में कॉम्पैक्ट करें। लॉग से इंडेक्स को पुनर्निर्माण योग्य रखें। रिटेंशन जॉब्स को प्रति-टेनेंट नीति और लीगल होल्ड का सम्मान करना चाहिए; विलोपन द्वारा संरक्षित पेलोड को बनाए रखे बिना एक ऑडिट योग्य नीति रिकॉर्ड छोड़ा जाना चाहिए।
चरण 6: एक्सेस और एक्सपोर्ट नियंत्रण लागू करें
प्रत्येक क्वेरी को टेनेंट, भूमिका, उद्देश्य और समय सीमा के आधार पर अधिकृत करें। रीड्स और एक्सपोर्ट्स को भी ऑडिट इवेंट्स के रूप में लॉग करें। एक हस्ताक्षरित मेनिफेस्ट तैयार करें जिसमें फ़िल्टर, इवेंट काउंट, सेगमेंट हैश और टाइमस्टैम्प शामिल हों ताकि प्राप्तकर्ता पूर्णता को सत्यापित कर सके और परिवर्तनों का पता लगा सके।
चरण 7: आउटेज और ओवरलोड व्यवहार को परिभाषित करें
एक सीमित स्थानीय बफ़र, बैकप्रेशर और अनिवार्य इवेंट्स के लिए एक स्पष्ट नीति चुनें। गैर-महत्वपूर्ण टेलीमेट्री के लिए, सैंपलिंग या विलंबित डिलीवरी स्वीकार्य हो सकती है; सुरक्षा इवेंट्स के लिए, मूल म्यूटेशन को अस्वीकार करें या एक अलग आपातकालीन चैनल पर रूट करें। कभी भी स्वीकार किए जाने की रिपोर्ट न करें जब इवेंट केवल वोलेटाइल मेमोरी में रखा गया हो।
चरण 8: ट्रस्ट बाउंड्री का संचालन करें
इनजेशन लैग, ड्यूरेबल-एक्सेप्ट लेटेंसी, कंज्यूमर लैग, अस्वीकृत इवेंट्स, सीक्वेंस गैप, हैश वेरिफिकेशन विफलताएं, इंडेक्स फ्रेशनेस, एक्सपोर्ट अवधि और रिटेंशन-जॉब त्रुटियों को मापें। की (key) एक्सेस को प्रतिबंधित करें, साइनिंग कीज़ को रोटेट करें, रीस्टोर और वेरिफिकेशन का परीक्षण करें, और ऑडिट ट्रेल के स्वयं के ऑडिट ट्रेल पर अलर्ट करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
“मैं ऑडिट लॉग को एक स्वतंत्र साक्ष्य प्रणाली के रूप में मानूंगा। एक व्यावसायिक सर्विस एक इवेंट ID, टेनेंट, एक्टर, प्रमाणीकरण संदर्भ, एक्शन, टारगेट, परिणाम, रिक्वेस्ट ID और स्कीमा संस्करण के साथ एक कैनोनिकल इवेंट उत्सर्जित करती है। सर्विस केवल तभी प्राप्ति की पावती देती है जब इवेंट एक रेप्लिकेटेड ड्यूरेबल लॉग तक पहुँच जाता है। एसिंक्रोनस कंज्यूमर सर्च इंडेक्स और एक्सपोर्ट बनाते हैं, ताकि खोए हुए इंडेक्स को साक्ष्य से फिर से बनाया जा सके।
साक्ष्य लॉग को टेनेंट और समय के अनुसार विभाजित किया जाता है, रिकॉर्ड को हैश से जोड़ा जाता है, और समय-समय पर सेगमेंट हेड्स को हस्ताक्षरित या एंकर किया जाता है। क्वेरीज़ को टेनेंट, भूमिका, उद्देश्य और समय सीमा द्वारा अधिकृत किया जाता है; क्वेरीज़ और एक्सपोर्ट्स का स्वयं ऑडिट किया जाता है। एक एक्सपोर्ट में उसके फ़िल्टर, इवेंट काउंट, सेगमेंट हैश और एक हस्ताक्षरित मेनिफेस्ट शामिल होते हैं। इनजेशन विफलता के दौरान, सुरक्षा इवेंट एक सीमित ड्यूरेबल आपातकालीन पथ में प्रवेश करते हैं या मूल उच्च-जोखिम वाली कार्रवाई को अस्वीकार कर दिया जाता है; इन-मेमोरी बफ़र को स्वीकृत इवेंट नहीं माना जाता है। ऑपरेशंस इनजेशन लेटेंसी, सीक्वेंस गैप, हैश विफलताएं, इंडेक्स फ्रेशनेस, अस्वीकृत इवेंट्स और रिटेंशन त्रुटियों की निगरानी करते हैं, और नियमित रूप से इंडेक्स पुनर्निर्माण, की रोटेशन और हॉट-टेनेंट आइसोलेशन का अभ्यास करते हैं। यह सर्विस प्राप्ति के बाद इंटीग्रिटी साबित करती है; पहचान, प्राधिकरण और व्यावसायिक लेनदेन अभी भी यह स्थापित करते हैं कि अपस्ट्रीम इवेंट सच्चा था या नहीं।”
सामान्य गलतियाँ
- किसी इवेंट को ड्यूरेबल स्टोरेज से पहले स्वीकार करना, जिससे प्रोसेस क्रैश के बाद साइलेंट गैप बन जाते हैं।
- एक परिवर्तनशील (mutable) डेटाबेस टेबल या सामान्य डिबग लॉग को ऑडिट साक्ष्य के रूप में मानना।
- सर्च इंडेक्स को एकमात्र प्रति बनाना, जिससे खराबी आने पर इसे फिर से नहीं बनाया जा सकता।
- यह भूल जाना कि क्वेरीज़, एक्सपोर्ट्स, रिटेंशन परिवर्तन और की रोटेशन के लिए भी ऑडिटिंग की आवश्यकता होती है।
- यह दावा करना कि एक हैश चेन यह साबित करती है कि एक अपस्ट्रीम इवेंट सच्चा था।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि पूरा सर्च इंडेक्स खो जाए?
साक्ष्य इनजेशन को उपलब्ध रखें, अपरिवर्तनीय सेगमेंट्स से इंडेक्स का पुनर्निर्माण करें, और इवेंट काउंट, सीक्वेंस और हस्ताक्षरित मेनिफेस्ट के साथ पुनर्निर्मित सीमा को सत्यापित करें।
क्या इनजेशन आउटेज के दौरान व्यावसायिक ट्रैफ़िक जारी रहना चाहिए?
इवेंट की गंभीरता के आधार पर निर्णय लें। कम जोखिम वाले कार्य एक सीमित ड्यूरेबल बफ़र में प्रवेश कर सकते हैं। एक उच्च-जोखिम वाली सुरक्षा कार्रवाई जिसे मज़बूती से रिकॉर्ड नहीं किया जा सकता है, उसे अस्वीकार कर दिया जाना चाहिए या एक अलग आपातकालीन पथ के माध्यम से रूट किया जाना चाहिए, इसे कभी भी चुपचाप अनुमति नहीं दी जानी चाहिए।
आप एक हॉट टेनेंट को दूसरों को नुकसान पहुँचाने से कैसे रोकते हैं?
टेनेंट और समय के अनुसार पार्टिशन करें, इनजेशन, क्वेरी और एक्सपोर्ट कोटा लागू करें, और कंज्यूमर संसाधनों को अलग करें। लोड परीक्षणों को अप्रभावित टेनेंट्स के लिए ड्यूरेबिलिटी और क्वेरी सर्विस-लेवल ऑब्जेक्टिव्स (SLO) को सत्यापित करना चाहिए।
प्राइवेसी डिलीशन और ऑडिट रिटेंशन एक साथ कैसे मौजूद रहते हैं?
लीगल होल्ड और टेनेंट नीति द्वारा फ़ील्ड्स को वर्गीकृत करें, संक्षिप्त सारांश (redacted digests) या नियंत्रित संदर्भों को प्राथमिकता दें, इंडेक्स, ऑब्जेक्ट सेगमेंट्स और बैकअप पर समान रूप से विलोपन लागू करें, और नीति कार्रवाई का एक सत्यापन योग्य रिकॉर्ड बनाए रखें।