प्रॉम्प्ट और दायरा
एक मल्टी-टेनेंट Certificate Transparency (CT) लॉग मॉनिटर डिज़ाइन करें। एक उपयोगकर्ता एक या अधिक डोमेन सबमिट करता है; सेवा सार्वजनिक CT लॉग्स की लगातार जांच करती है, मेल खाने वाले प्रमाणपत्रों या प्री-सर्टिफिकेट्स पर अलर्ट देती है, और यह साबित करती है कि लॉग डेटा को गुप्त रूप से दोबारा नहीं लिखा गया था। इसे पुराने (stale) लॉग्स, प्रूफ विफलताओं और maximum merge delay उल्लंघनों का भी पता लगाना चाहिए।
प्लेटफ़ॉर्म सुरक्षा और प्रमाणपत्र-बुनियादी ढांचे (certificate-infrastructure) की भूमिकाओं के लिए यह एक बेहतरीन सिस्टम-डिज़ाइन प्रश्न है। महत्वपूर्ण हिस्सा एक सत्यापन योग्य डेटा पाइपलाइन और स्पष्ट विफलता सीमाएं हैं, न कि केवल लोकप्रिय सेवाओं की सूची।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप मॉनिटर को ब्राउज़र नीति और CA जारी करने (issuance) से अलग पहचानते हैं।
- क्या आप signed tree heads (STHs), Merkle inclusion proofs, consistency proofs और append-only सिमेंटिक्स को समझते हैं।
- क्या maximum merge delay (MMD) एक मापने योग्य शेड्यूलिंग और अलर्टिंग स्थिति बन पाता है।
- क्या आप कई लॉग्स, डुप्लिकेट रीड्स, स्प्लिट व्यूज, आउटेज और टेनेंट आइसोलेशन को कवर करते हैं।
- क्या स्टोरेज, आइडेम्पोटेंसी, अलर्ट नॉइज़ नियंत्रण और क्षमता से जुड़े अनुमान ठोस हैं।
पहले पूछे जाने वाले स्पष्टीकरण
चार सीमाओं की पुष्टि करें:
- क्या मिलान में सटीक नाम, एक पंजीकरण योग्य डोमेन, वाइल्डकार्ड या SAN में दिए गए नाम शामिल होने चाहिए?
- क्या निकट-वास्तविक समय (near-real-time) में पहचान आवश्यक है, या मिनट-स्तरीय विलंबता स्वीकार्य है? किन चैनलों और ऑन-कॉल एस्केलेशन की आवश्यकता है?
- क्या मॉनिटर को प्रत्येक सार्वजनिक लॉग का निरीक्षण करना चाहिए, या केवल चयनित विश्वसनीय सेट का? क्या मूल (raw) प्रमाणपत्रों और साक्ष्यों को बनाए रखा जाना चाहिए?
- टेनेंट की संख्या, डेटा प्रतिधारण (retention) अवधि, गोपनीयता आवश्यकताएं और बजट क्या हैं?
यदि कोई उत्तर नहीं दिया जाता है, तो मान लें कि 100 लॉग्स को प्रति मिनट एक बार पोल किया जाता है, पांच मिनट का एंड-टू-एंड खोज लक्ष्य है, और ऑडिट साक्ष्य सुरक्षित रखे जाते हैं।
तीस-सेकंड उत्तर का ढांचा
मैं सिस्टम को लॉग कलेक्शन, क्रिप्टोग्राफ़िक सत्यापन, प्रमाणपत्र मिलान, अलर्टिंग और ऑडिट स्टोरेज में विभाजित करूँगा। प्रत्येक लॉग एक सत्यापित ट्री आकार और नवीनतम STH रखता है। कलेक्टर्स STH हस्ताक्षर को सत्यापित करते हैं, वृद्धिशील रूप से प्रविष्टियां लाते हैं, और केवल-जोड़ने (append-only) वाले व्यवहार की जांच करने के लिए inclusion या consistency proofs का उपयोग करते हैं। मिलान परत SANs, वाइल्डकार्ड्स और पंजीकरण योग्य डोमेन को सामान्यीकृत (normalize) करती है; अलर्ट परत टेनेंट नीति के अनुसार डुप्लिकेट्स हटाती है और एस्केलेट करती है; ऑडिट परत मूल प्रविष्टियों, STHs, प्रूफ़्स और हैश को संग्रहीत करती है। मुख्य मेट्रिक्स STH ताजगी, लॉग अंतराल (lag), प्रूफ-विफलता दर, अलर्ट विलंबता और गलत-सकारात्मक (false-positive) दर हैं। एक स्प्लिट व्यू या MMD उल्लंघन उस लॉग की विश्वसनीय स्थिति को फ्रीज कर देता है और उसे एस्केलेट करता है।
चरण-दर-चरण विस्तृत विश्लेषण
1. कलेक्शन और स्टेट मशीन
प्रत्येक लॉग की पहचान, सार्वजनिक कुंजी, विश्वसनीय ट्री आकार, अंतिम सत्यापित STH, अंतिम पोल समय और स्थिति को संग्रहीत करें। एक शेड्यूलर स्थिति के आधार पर कार्य सौंपता है: सामान्य लॉग्स वृद्धिशील रीड्स का उपयोग करते हैं, क्षणिक विफलताएं घातीय बैकऑफ़ का उपयोग करती हैं, और बार-बार होने वाली विफलताएं क्वारंटाइन में चली जाती हैं। कार्य कुंजी के रूप में लॉग पहचान और लक्षित ट्री आकार का उपयोग करें ताकि पुनः प्रयास (retries) आइडेम्पोटेंट रहें।
2. STH और Merkle सत्यापन
पहले लॉग की सार्वजनिक कुंजी के साथ STH हस्ताक्षर और टाइमस्टैम्प को सत्यापित करें, फिर निरंतर गैर-घटते (monotonically nondecreasing) ट्री आकार की आवश्यकता रखें। एक प्रारंभिक सिंक एक पूर्ण स्नैपशॉट स्थापित कर सकता है; बाद के सिंक यह दिखाने के लिए consistency proof का उपयोग करते हैं कि नए ट्री में पुराना ट्री शामिल है। प्रत्येक मेल खाने वाली प्रविष्टि के लिए, यह दिखाने के लिए inclusion proof का उपयोग करें कि यह उस ट्री से संबंधित है। एक विफल प्रूफ, रोलबैक, या गलत हस्ताक्षर को पुरानी स्थिति को अधिलेखित (overwrite) नहीं करना चाहिए; साक्ष्य बनाए रखें और लॉग को संदिग्ध चिह्नित करें।
3. वृद्धिशील रीड्स और अखंडता
अंतिम पुष्टि किए गए ट्री आकार के बाद की सीमा का अनुरोध करें और मूल प्रमाणपत्र, प्री-सर्टिफिकेट्स, लॉग स्थिति और प्राप्ति समय लिखें। प्रविष्टि पहचान द्वारा डिडुप्लिकेट करें, बिना इस तथ्य को छोड़े कि एक प्रमाणपत्र कई लॉग्स में दिखाई दिया था। यदि MMD के भीतर कोई सत्यापन योग्य नया STH नहीं आता है, तो लॉग लैग रिकॉर्ड करें और प्लेटफ़ॉर्म अलर्ट उठाएं। "कोई मेल खाता प्रमाणपत्र नहीं मिला" का निष्कर्ष "कोई नई प्रविष्टि नहीं देखी गई" से नहीं निकाला जाना चाहिए।
4. प्रमाणपत्र मिलान और अलर्ट
SANs, वाइल्डकार्ड्स, जारीकर्ता, notBefore, notAfter और प्रमाणपत्र फिंगरप्रिंट्स को पार्स करें। सबस्ट्रिंग मिलान की तुलना में स्पष्ट-नाम और पंजीकरण योग्य-डोमेन नियमों को प्राथमिकता दें। एक अलर्ट में टेनेंट, नाम, लॉग, फिंगरप्रिंट, पहली बार देखे जाने का समय और साक्ष्य लिंक शामिल होने चाहिए। एक छोटी समय-सीमा के भीतर समान फिंगरप्रिंट को डिडुप्लिकेट करें; एक नया जारीकर्ता, असामान्य रूप से छोटी वैधता, या एक प्रोडक्शन डोमेन गंभीरता को बढ़ा सकता है।
5. स्टोरेज, टेनेंसी और रिकवरी
हॉट स्थिति को रिलेशनल या की-वैल्यू स्टोर में रखें; मूल प्रविष्टियों और प्रूफ़्स को लॉग और ट्री आकार द्वारा अनुक्रमित ऑब्जेक्ट स्टोरेज में रखें। रीप्ले के लिए घटनाओं को एक अपरिवर्तनीय ऑडिट स्ट्रीम में लिखें। टेनेंट क्वेरी केवल अधिकृत नाम लौटाती हैं। प्रति-लॉग दर सीमाएं और एक वैश्विक समवर्ती सीमा लागू करें ताकि मॉनिटर सार्वजनिक लॉग्स को ओवरलोड न करे। यदि स्थानीय स्थिति खो जाती है, तो असत्यापित कर्सर पर भरोसा करने के बजाय अंतिम विश्वसनीय STH से रिकवर करें और consistency proofs के साथ तालमेल बिठाएं।
6. ऑब्जर्वेबिलिटी और विफलता से निपटना
STH आयु, MMD लैग, पुष्टि किया गया ट्री आकार, फ़ेच थ्रूपुट, प्रूफ विफलताएं, लॉग उपलब्धता, मैच दर, अलर्ट विलंबता और डुप्लिकेट्स को मापें। आउटेज के दौरान, अंतिम विश्वसनीय स्थिति को बनाए रखें और पुनः प्रयास करें। स्प्लिट व्यू या कंसिस्टेंसी विफलता पर, उस लॉग के मिलानों का उपयोग करना बंद करें, अन्य लॉग्स का उपयोग करें, और एक सुरक्षा घटना बनाएं। यदि सूचनाएं विफल हो जाती हैं, तो घटनाओं को एक टिकाऊ कतार में बनाए रखें और रिकवरी के बाद ईवेंट आईडी द्वारा वितरित करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पहले विश्वसनीय प्रगति को परिभाषित करूँगा: एक लॉग कर्सर तभी आगे बढ़ता है जब एक सही ढंग से हस्ताक्षरित, निरंतर आकार वाला STH एक consistency proof पास कर लेता है। कलेक्टर उस कर्सर और अनुरोधित सीमा को एक पुनः प्रयास टोकन के साथ संग्रहीत करता है। पहला रन एक बेसलाइन स्थापित करता है; बाद के रन ट्री-आकार की सीमा के अनुसार पढ़ते हैं। प्रत्येक प्रविष्टि अपना फिंगरप्रिंट, SAN, लॉग स्थिति, मूल प्रतिक्रिया और सत्यापन प्रूफ बरकरार रखती है।
मैचर सटीक नामों, पंजीकरण योग्य डोमेन और स्पष्ट वाइल्डकार्ड के लिए टेनेंट नियमों के साथ तुलना करने से पहले SANs को सामान्यीकृत करता है। टेनेंट, फिंगरप्रिंट और लॉग द्वारा अनुक्रमित एक घटना कतार में प्रवेश करती है; अधिसूचना कार्यकर्ता डिडुप्लिकेट करते हैं, एस्केलेट करते हैं और डिलीवरी रिकॉर्ड करते हैं। ऑडिट स्टोरेज STH, प्रूफ, एंट्री हैश और सत्यापनकर्ता संस्करण को बनाए रखता है ताकि सुरक्षा इंजीनियर स्वतंत्र रूप से निर्णय को रीप्ले कर सकें।
मैं लॉग विसंगतियों को डेटा-ट्रस्ट विफलताओं के रूप में मानता हूँ: एक गलत हस्ताक्षर, रोलबैक, विफल consistency proof, या MMD टाइमआउट एक उच्च-प्राथमिकता वाला प्लेटफ़ॉर्म ईवेंट बनाता है। उस लॉग को क्वारंटाइन किया जाता है और उसकी पुरानी विश्वसनीय स्थिति को संरक्षित किया जाता है। लॉग द्वारा शार्डिंग, दर सीमित करना, बैच रीड्स और ऑब्जेक्ट स्टोरेज लागत को नियंत्रित करते हैं; अधिकृत क्वेरी और टेनेंट कोटा अलगाव लागू करते हैं। मैं STH ताजगी, प्रूफ विफलताओं, खोज विलंबता, अलर्ट गलत-सकारात्मक दर और रीप्ले सफलता दर का उपयोग करके इस डिज़ाइन को स्वीकार करूँगा।
सामान्य गलतियाँ
- केवल एक लॉग को पोल करना और इस बात को अनदेखा करना कि प्रमाणपत्र कई लॉग्स में दिखाई दे सकते हैं।
- STH हस्ताक्षर और Merkle proofs को सत्यापित किए बिना प्रमाणपत्र पाठ को पढ़ना।
- कर्सर को आगे बढ़ाना केवल इसलिए क्योंकि नवीनतम अनुरोध सफल रहा, भले ही डेटा सत्यापित न किया गया हो।
- MMD को प्रमाणपत्र वैधता मानना, या लॉग-ताजगी का कोई अलर्ट ही न होना।
- सबस्ट्रिंग खोज के साथ डोमेन का मिलान करना, जिससे समान नामों और असंबंधित SANs के लिए गलत सकारात्मक परिणाम उत्पन्न होते हैं।
- किसी फिंगरप्रिंट को वैश्विक रूप से डिडुप्लिकेट करना और सभी लॉग्स में उसके स्थानों की जानकारी खो देना।
- जब कोई लॉग असामान्य व्यवहार कर रहा हो, तब भी कम-विश्वसनीयता वाले "नहीं मिला" निष्कर्ष जारी रखना।
- केवल अंतिम अलर्ट रखना और कोई मूल प्रविष्टि, STH या प्रूफ न रखना, जिससे ऑडिट असंभव हो जाए।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि कोई लॉग छोटा ट्री लौटाता है?
कर्सर को आगे न बढ़ाएं। दोनों STHs और प्रतिक्रिया को सुरक्षित रखें, लॉग को क्वारंटाइन करें, और एक कंसिस्टेंसी अलर्ट उठाएं। केवल मानव समीक्षा या एक नई स्थापित विश्वसनीय बेसलाइन के बाद ही फिर से शुरू करें।
आप निकट-वास्तविक समय की पोलिंग लागत को कैसे कम करते हैं?
लॉग द्वारा शार्ड करें, नई सीमाओं को बैच करें, पोलिंग आवृत्ति को गतिशील रूप से ट्यून करें, और कोल्ड साक्ष्यों को ऑब्जेक्ट स्टोरेज में रखें। विलंबता लक्ष्य को पूरा करने के लिए सत्यापन से समझौता न करें।
आप डोमेन स्वामित्व को कैसे सत्यापित करते हैं?
मॉनिटर बनाए जाने पर DNS, HTTP, या संगठनात्मक प्राधिकरण की आवश्यकता रखें। केवल एक अधिकृत प्रिंसिपल ही मिलान नियमों को बदल सकता है, और प्रत्येक परिवर्तन का ऑडिट किया जाता है।
एक मॉनिटर ब्राउज़र CT नीति से किस प्रकार भिन्न है?
एक मॉनिटर सार्वजनिक लॉग्स में प्रविष्टियों को खोजता है और साबित करता है। ब्राउज़र नीति यह तय करती है कि क्या कोई प्रमाणपत्र कनेक्शन आवश्यकताओं को पूरा करता है। उनकी विफलता से निपटने के तरीके और विश्वास सीमाएं अलग हैं।
आप इसका परीक्षण कैसे करेंगे?
गलत हस्ताक्षर, अमान्य प्रूफ, रोलबैक, MMD टाइमआउट, डुप्लिकेट प्रविष्टियां और अधिसूचना पुनः प्रयासों को इंजेक्ट करने के लिए एक नियंत्रणीय लॉग या रिकॉर्ड की गई प्रतिक्रियाओं का उपयोग करें। सत्यापित करें कि कर्सर कभी भी गलत तरीके से आगे न बढ़ें, घटनाएं आइडेम्पोटेंट रहें, और ऑडिट सफलतापूर्वक रीप्ले हों।