प्रश्न और परिदृश्य
सॉफ़्टवेयर-सप्लाई-चेन एविडेंस के लिए एक ट्रांसपेरेंसी सर्विस डिज़ाइन करें। एक बिल्डर बिल्ड परिवेश और आर्टिफैक्ट डाइजेस्ट को प्रमाणित कर सकता है, एक पब्लिशर किसी रिलीज़ और उसके स्रोत को प्रमाणित कर सकता है, और एक इंटीग्रेटर टेस्ट या अनुपालन (compliance) परिणाम जोड़ सकता है। एक उपभोक्ता को यह सत्यापित करना होगा कि स्टेटमेंट पर किसने हस्ताक्षर किए, क्या रजिस्ट्रेशन पॉलिसी पास हुई, और क्या कोई सत्यापन योग्य इतिहास रसीद मौजूद है।
मुख्य सीमा सत्यापन योग्य रिकॉर्ड और एक व्यावसायिक डेटाबेस के बीच है: सर्विस यह साबित करती है कि एक स्टेटमेंट को एक निश्चित समय पर रजिस्टर और चेक किया गया था। यह ऑब्जेक्ट स्टोरेज, पैकेज रजिस्ट्री या पूर्ण डिपेंडेंसी रिज़ॉल्वर का स्थान नहीं लेती है।
इंटरव्यूअर क्या जांच रहा है
विश्वास की सीमाएं (Trust boundaries)
एक मजबूत उत्तर जारीकर्ताओं (issuers), ट्रांसपेरेंसी सर्विस, ऑडिटर्स और रिलाइंग पार्टीज़ (relying parties) को अलग करता है, और फिर बताता है कि प्रत्येक पक्ष क्या साबित कर सकता है और क्या नहीं।
क्रिप्टोग्राफ़िक सामग्री और इतिहास
बताएं कि हस्ताक्षरित स्टेटमेंट्स, पॉलिसी परिणाम, एक अपेंड-ओनली लॉग (append-only log), और रसीदें कैसे संबंधित हैं। डेटाबेस में केवल एक पंक्ति (row) लिखना छेड़छाड़-रोधी एविडेंस (tamper evidence) नहीं है।
संचालन योग्य गवर्नेंस (Operable governance)
केवल राइट पाथ (write path) का आरेख बनाने के बजाय की-रोटेशन, निरसन (revocation), डुप्लिकेट सबमिशन, पॉलिसी वर्ज़न, टेनेंट आइसोलेशन, प्राइवेसी और डिजास्टर रिकवरी को कवर करें।
विश्वसनीयता और स्केल
उच्च प्रकाशन मात्रा और बर्स्टी उपभोक्ताओं के लिए इडेम्पोटेंट (idempotent) रजिस्ट्रेशन, बैच वेरिफिकेशन, प्रूफ रीड्स, क्रॉस-रीजन रेप्लिकेशन और ऑडिट रिप्ले पर चर्चा करें।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या स्टेटमेंट्स केवल सॉफ़्टवेयर आर्टिफैक्ट्स तक सीमित हैं, या इनमें हार्डवेयर, मॉडल्स और डिप्लॉयमेंट परिवेश भी शामिल हैं?
- क्या सर्विस एक संगठन द्वारा चलाई जाती है, या उन टेनेंट्स द्वारा साझा की जाती है जिन्हें एक-दूसरे को सत्यापित करना आवश्यक है?
- क्या उपभोक्ताओं को स्ट्रॉन्गली कन्सिस्टेंट (strongly consistent) रीड्स की आवश्यकता है, या वे "रजिस्टर्ड लेकिन प्रूफ रेप्लिकेट नहीं हुआ" स्थिति देख सकते हैं?
- कौन से फ़ील्ड संवेदनशील हैं, और क्या सार्वजनिक दृश्य (public view) केवल डाइजेस्ट, समय और जारीकर्ता पहचानकर्ताओं को उजागर कर सकता है?
- क्या निरसन (revocation) किसी की (key), स्टेटमेंट, या केवल किसी पॉलिसी निर्णय को लक्षित करता है?
- लक्षित थ्रूपुट, एविडेंस रिटेंशन अवधि और क्रॉस-रीजन रिकवरी पॉइंट क्या हैं?
30-सेकंड का उत्तर ढांचा (Framework)
"मैं सिस्टम को एक स्टेटमेंट-रजिस्ट्रेशन API, पॉलिसी चेकर, ट्रांसपेरेंसी लॉग, रसीद सर्विस और वेरिफिकेशन SDK में विभाजित करूंगा। एक जारीकर्ता COSE-हस्ताक्षरित स्टेटमेंट सबमिट करता है; सर्विस एक वर्ज़न वाली पॉलिसी की जांच करती है और इसे एक अपेंड-ओनली लॉग में इडेम्पोटेंसी की (idempotency key) के तहत रजिस्टर करती है। लॉग इन्क्लूज़न प्रूफ (inclusion proof) के साथ एक रसीद लौटाता है। उपभोक्ता स्टेटमेंट, रसीद और ऑडिट पाथ का उपयोग करके ऑफ़लाइन सिग्नेचर, लॉग इन्क्लूज़न, पॉलिसी वर्ज़न और समय को सत्यापित करते हैं। संवेदनशील फ़ील्ड डाइजेस्ट या एन्क्रिप्टेड संदर्भ बने रहते हैं। की-रोटेशन और निरसन ट्रस्ट रूट्स और स्टेटस रिकॉर्ड्स का उपयोग करते हैं, जबकि क्रॉस-रीजन रेप्लिकेशन लॉग और पॉलिसी परिणाम कन्सिस्टेंट होने के बाद ही प्रकाशित होता है।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: स्टेटमेंट्स और भूमिकाएं परिभाषित करें
एक स्टेटमेंट में सब्जेक्ट आइडेंटिफ़ायर, जारीकर्ता, प्रकार, वैधता समय, पॉलिसी वर्ज़न और कंटेंट डाइजेस्ट शामिल होता है; जारीकर्ता इस पर COSE_Sign1 के साथ हस्ताक्षर करता है। ट्रांसपेरेंसी सर्विस केवल प्रमाणित जारीकर्ताओं को स्वीकार करती है और प्रत्येक स्टेटमेंट को एक टेनेंट, नेमस्पेस और स्रोत से जोड़ती है। उपभोक्ताओं, ऑडिटर्स और पॉलिसी एडमिनिस्ट्रेटर के पास अलग-अलग अनुमतियाँ होती हैं।
चरण 2: रजिस्ट्रेशन डिज़ाइन करें
क्लाइंट हस्ताक्षरित स्टेटमेंट, एक इडेम्पोटेंसी की और एक पॉलिसी संकेत के साथ POST /statements को कॉल करता है। सर्विस सिग्नेचर, समय सीमा (time window), स्कीमा और जारीकर्ता स्थिति को मान्य करती है, फिर पॉलिसी का मूल्यांकन करती है। पास होने वाले स्टेटमेंट को ट्रांसपेरेंसी लॉग में जोड़ दिया जाता है। समान कंटेंट और की मूल रसीद लौटाते हैं; कोई विरोध (conflict) होने पर इसे चुपचाप ओवरराइट करने के बजाय वर्तमान रजिस्ट्रेशन लौटा दिया जाता है।
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }चरण 3: एक सत्यापन योग्य रसीद जारी करें
सर्विस एक रसीद बनाती है जिसमें लॉग-ट्री वर्ज़न, लीफ़ डाइजेस्ट, प्रूफ पाथ और सर्विस सिग्नेचर शामिल होते हैं। एक रीडर सर्विस पब्लिक की के साथ रसीद को सत्यापित करता है, स्टेटमेंट डाइजेस्ट की पुनर्गणना करता है, और इन्क्लूज़न की जांच करता है। एक रसीद यह साबित करती है कि सर्विस ने एक निश्चित समय पर एक रिकॉर्ड को रजिस्टर और कमिट किया था; यह यह साबित नहीं करती कि आर्टिफैक्ट सुरक्षित है।
चरण 4: पॉलिसी, निरसन और समय संभालें
एक पॉलिसी वर्ज़न वाली होती है और प्रत्येक रजिस्ट्रेशन रिकॉर्ड पर तय (fixed) होती है। बाद की पॉलिसी पुराने परिणाम को फिर से नहीं लिखती है; यह एक नया मूल्यांकन स्टेटमेंट बनाती है। की-रोटेशन सक्रियण समय के साथ ऐतिहासिक पब्लिक कीज़ को बनाए रखता है। स्टेटस रिकॉर्ड किसी जारीकर्ता, की या स्टेटमेंट को निरस्त कर सकते हैं। सत्यापनकर्ता स्टेटमेंट समय, रसीद समय और ट्रस्ट-रूट वैधता सीमाओं की जांच करते हैं।
चरण 5: प्राइवेसी और टेनेंट्स को अलग करें
पब्लिक लॉग केवल डाइजेस्ट, प्रकार, जारीकर्ता पहचानकर्ता और आवश्यक टाइमस्टैम्प रखता है। सोर्स कोड, आंतरिक डोमेन और भेद्यता विवरण (vulnerability details) एन्क्रिप्टेड ऑब्जेक्ट स्टोरेज में रहते हैं और कंटेंट एड्रेस द्वारा संदर्भित होते हैं। टेनेंट पॉलिसी, कोटा और रीड ऑथराइजेशन को API पर लागू किया जाता है; प्रूफ फॉर्मेट्स को इंटरऑपरेबल रखते हुए लॉग इंडेक्स को टेनेंट-पार्टीशन किया जा सकता है।
चरण 6: स्केल, रिकवर और ऑपरेट करें
राइट पाथ पर लॉग्स को शार्ड करें और कमिट्स को बैच करें; रीड पाथ पर पब्लिक कीज़, स्कीमा और रसीदों को कैश करें। क्षेत्रों (regions) के बीच क्रमबद्ध लॉग्स और चेकपॉइंट्स को रेप्लिकेट करें। एक लक्षित क्षेत्र तब तक केवल-पढ़ने के लिए (read-only) रहता है जब तक कि लॉग स्थिति, पॉलिसी परिणाम और की-स्थिति कन्वर्ज न हो जाएं। रजिस्ट्रेशन सफलता, पॉलिसी अस्वीकृति, रसीद विलंबता (latency), रेप्लिकेशन लैग, वेरिफिकेशन विफलताओं और निरसन प्रसार समय को ट्रैक करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं एक स्टेटमेंट-रजिस्ट्रेशन API और एक ऑफ़लाइन वेरिफिकेशन SDK प्रदान करूंगा। एक बिल्ड सिस्टम COSE_Sign1 स्टेटमेंट सबमिट करता है जिसमें आर्टिफैक्ट डाइजेस्ट, जारीकर्ता, प्रकार, समय और पॉलिसी वर्ज़न शामिल होता है। सर्विस सिग्नेचर और स्कीमा को मान्य करती है, टेनेंट पॉलिसी का मूल्यांकन करती है, डाइजेस्ट को अपेंड-ओनली ट्रांसपेरेंसी लॉग में जोड़ती है, और एक इन्क्लूज़न-प्रूफ रसीद लौटाती है। रजिस्ट्रेशन इडेम्पोटेंट है, इसलिए पुनः प्रयासों (retries) पर वही रसीद मिलती है।
उपभोक्ता स्टेटमेंट, रसीद और ट्रस्ट रूट डाउनलोड करते हैं और स्थानीय रूप से सिग्नेचर, लॉग इन्क्लूज़न, जारीकर्ता स्थिति और पॉलिसी वर्ज़न को सत्यापित करते हैं। एक वेरिफिकेशन परिणाम एक अन्य हस्ताक्षरित स्टेटमेंट बन सकता है, जिससे एक ट्रेसेबल श्रृंखला बनती है। संवेदनशील सामग्री एन्क्रिप्टेड संदर्भों के पीछे रहती है। की-रोटेशन के बाद ऐतिहासिक ट्रस्ट रूट्स उपलब्ध रहते हैं, और निरसन स्टेटस स्टेटमेंट्स के माध्यम से फैलता है। स्ट्रॉन्ग वेरिफिकेशन रीड्स खुलने से पहले क्रॉस-रीजन रेप्लिकेशन क्रमबद्ध लॉग डेटा, चेकपॉइंट्स और पॉलिसी परिणामों को कॉपी करता है। सिस्टम रजिस्ट्रेशन और ट्रैसेबिलिटी को साबित करता है; यह मैलवेयर स्कैनिंग या रनटाइम सुरक्षा का स्थान नहीं लेता है।"
सामान्य गलतियाँ
- स्टेटमेंट्स को एक एडिट करने योग्य टेबल में स्टोर करना → एक एडमिनिस्ट्रेटर इतिहास को फिर से लिख सकता है → एक अपेंड-ओनली लॉग, हस्ताक्षरित रसीदों और एक स्वतंत्र सत्यापनकर्ता का उपयोग करें।
- ट्रांसपेरेंसी रसीद को सुरक्षा निर्णय मानना → रजिस्ट्रेशन का मतलब यह नहीं है कि आर्टिफैक्ट भेद्यता-मुक्त (vulnerability-free) है → प्रोवेनेंस (provenance), पॉलिसी परिणामों और रनटाइम जोखिम को अलग करें।
- पॉलिसी बदलने पर पुराने रिकॉर्ड्स को ओवरराइट करना → ऑडिट निर्णयों को पुनरुत्पादित नहीं कर सकते → पॉलिसी वर्ज़नों को पिन करें और नए मूल्यांकन जोड़ें।
- केवल वर्तमान की (key) को रोटेट करना → पुराने स्टेटमेंट्स को सत्यापित नहीं किया जा सकता → सक्रियण समय के साथ ऐतिहासिक कीज़ और ट्रस्ट रूट्स को बनाए रखें।
- प्रत्येक स्टेटमेंट फ़ील्ड प्रकाशित करना → स्रोत और भेद्यता मेटाडेटा लीक हो जाते हैं → डाइजेस्ट को उजागर करें और संवेदनशील संदर्भों को एन्क्रिप्ट करें।
- पुनः प्रयासों (retries) से डुप्लिकेट रजिस्ट्रेशन बनने देना → अस्थिर इतिहास और स्टोरेज की बर्बादी → टेनेंट और हस्ताक्षरित सामग्री के साथ एक इडेम्पोटेंसी की को बाइंड करें।
- प्रूफ्स कन्वर्ज होने से पहले एक रेप्लिका खोलना → अपूर्ण इन्क्लूज़न पाथ → रीड्स की सेवा करने से पहले लॉग, चेकपॉइंट्स और की-स्थिति को रेप्लिकेट करें।
- प्रत्येक वेरिफिकेशन के लिए एक केंद्रीय API की आवश्यकता होना → ऑफ़लाइन ऑडिट विफल होते हैं → स्टेटमेंट्स, रसीदें, ट्रस्ट रूट्स और एक ऑफ़लाइन सत्यापनकर्ता प्रदान करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: आप कैसे साबित करेंगे कि लॉग ने किसी मध्यवर्ती रिकॉर्ड को हटाया नहीं है?
ऑडिटर्स समय-समय पर हस्ताक्षरित चेकपॉइंट्स प्राप्त करते हैं और उनकी तुलना करते हैं। सत्यापनकर्ताओं को मोनोटोनिक ट्री साइज़, सुसंगत ऐतिहासिक रूट्स और मान्य इन्क्लूज़न प्रूफ्स की आवश्यकता होती है; कोई भी फ़ोर्क (fork) लॉग पर भरोसा करने से रोकता है।
फॉलो-अप 2: क्या दो ट्रांसपेरेंसी सर्विसेज़ की रसीदें एक-दूसरे को सत्यापित कर सकती हैं?
वे स्टेटमेंट डाइजेस्ट और एक मानकीकृत रसीद प्रारूप साझा कर सकती हैं, लेकिन प्रत्येक सर्विस अभी भी अपने स्वयं के ट्रस्ट रूट के साथ हस्ताक्षर करती है। क्रॉस-सर्विस समानता के लिए एक अतिरिक्त क्रॉस-स्टेटमेंट की आवश्यकता होती है; एक सर्विस की पब्लिक की अपने आप दूसरी के लिए विश्वास नहीं बन जाती।
फॉलो-अप 3: आप पहले से रजिस्टर्ड स्टेटमेंट को कैसे निरस्त (revoke) करते हैं?
मूल स्टेटमेंट और रसीद को बनाए रखें, फिर एक निरसन या जोखिम-स्थिति स्टेटमेंट जोड़ें। सत्यापनकर्ता वर्तमान स्वीकृति तय करने के लिए समय और पॉलिसी लागू करता है जबकि ऑडिटर्स मूल रजिस्ट्रेशन तथ्य को बनाए रखते हैं।
फॉलो-अप 4: क्या होता है जब किसी रिलीज़ के दौरान रजिस्ट्रेशन अनुपलब्ध होता है?
क्लाइंट हस्ताक्षरित स्टेटमेंट और डाइजेस्ट को स्थानीय रूप से संग्रहीत करता है और रिलीज़ को "नो ट्रांसपेरेंसी रिसीट येट" (no transparency receipt yet) के रूप में लेबल करता है। एक बार बहाल हो जाने पर, यह उसी इडेम्पोटेंसी की के साथ रजिस्टर होता है; अनुपलब्ध प्रूफ को कभी भी सत्यापित के रूप में प्रस्तुत नहीं किया जाता है।
फॉलो-अप 5: आप लॉग को प्राइवेसी लीक बनने से कैसे रोकते हैं?
न्यूनतम सार्वजनिक फ़ील्ड रजिस्टर करें, टेनेंट-स्तरीय एक्सेस पॉलिसी लागू करें, और एन्क्रिप्टेड संदर्भों का उपयोग करें। ऑडिट के लिए सत्यापन योग्य डाइजेस्ट को संरक्षित करते हुए आवश्यकतानुसार ही समय, जारीकर्ता और आर्टिफैक्ट प्रकार को एकत्रित करें।
स्रोत 1: RFC 9943 SCITT आर्किटेक्चर
RFC 9943 हस्ताक्षरित स्टेटमेंट्स, ट्रांसपेरेंसी सर्विसेज़, रसीदों और सत्यापन योग्य डेटा-संरचना प्रूफ्स को परिभाषित करता है। यह आर्टिफैक्ट स्टोरेज और डिपेंडेंसी रिज़ॉल्यूशन से रजिस्ट्रेशन एविडेंस को भी अलग करता है। वे सीमाएं यहां भूमिकाओं, रजिस्ट्रेशन प्रवाह और रसीद डिज़ाइन का आधार बनती हैं।
स्रोत 2: SCITT प्रोजेक्ट अवलोकन
SCITT प्रोजेक्ट सप्लाई-चेन स्टेटमेंट्स के लिए एक ऑडिट योग्य, ट्रेसेबल और सत्यापन योग्य इतिहास का वर्णन करता है। इस उत्तर में टेनेंट वेरिफिकेशन, पॉलिसी गवर्नेंस और रीजनल ऑपरेशन्स उस लक्ष्य को स्पष्ट डिज़ाइन ट्रेड-ऑफ में बदलते हैं।
स्रोत 3: सॉफ़्टवेयर-इंजीनियरिंग इंटरव्यू रिसर्च
सॉफ़्टवेयर-इंजीनियरिंग तकनीकी इंटरव्यू की तैयारी पर शोध संचार, बाधा स्पष्टीकरण और तकनीकी तर्क के संतुलन पर जोर देता है। स्पष्टीकरण प्रश्न, संक्षिप्त ढांचा और विफलता फॉलो-अप्स शब्दावली याद रखने के बजाय उन कौशलों को उजागर करने के लिए डिज़ाइन किए गए हैं।