प्रॉम्प्ट और संदर्भ
जब प्रोवाइडर सीक्रेट बदलता है, तो रिसीवर साइन किए गए वेबहुक अनुरोधों को सत्यापित करता है। रोटेशन को सीक्रेट को उजागर किए बिना या सत्यापन में कोई अंतराल पैदा किए बिना इन-फ़्लाइट पुनः प्रयासों (retries) और कई सेंडर रेप्लिकास को सहन करना चाहिए।
इंटरव्यूअर क्या जांचता है
- रॉ-बॉडी सिग्नेचर सत्यापन और कॉन्स्टेंट-टाइम तुलना को बनाए रखना।
- एक्टिव और रिटायर हो रहे सीक्रेट्स के बीच एक सीमित ओवरलैप डिज़ाइन करना।
- रोटेशन स्थिति, रीप्ले सुरक्षा, ऑब्जर्वेबिलिटी और रोलबैक को अलग करना।
उत्तर देने से पहले स्पष्टीकरण प्रश्न
- रोटेशन को कौन नियंत्रित करता है, और क्या सेंडर की (key) पहचानकर्ता या वर्ज़न प्रदर्शित कर सकता है?
- डिलीवरी पुनः प्रयास (retries) और क्लॉक स्क्यू कितने समय तक रह सकते हैं?
- क्या सेंडर डुअल-साइनिंग विंडो का समन्वय कर सकता है, या रिसीवर को दो सीक्रेट्स स्वीकार करने होंगे?
- रीप्ले जांच के लिए कौन सा इवेंट ID, टाइमस्टैम्प और रॉ पेलोड उपलब्ध है?
30-सेकंड उत्तर फ्रेमवर्क
मैं एक नया सीक्रेट प्रोविज़न करूँगा, इसे प्रत्येक रिसीवर को वितरित करूँगा और एक छोटी ओवरलैप विंडो में प्रवेश करूँगा। ओवरलैप के दौरान, की-ID-चयनित सिग्नेचर को सत्यापित करें या टाइमस्टैम्प सहनशीलता और इवेंट-ID डिडुप्लीकेशन लागू करते हुए, कॉन्स्टेंट-टाइम जांच के साथ वर्तमान और रिटायर हो रहे सीक्रेट को आज़माएँ। मेट्रिक्स को यह दिखाना चाहिए कि कौन सा वर्ज़न सत्यापित होता है, और रोटेशन केवल तभी पूरा होता है जब पुराने वर्ज़न का ट्रैफ़िक पुनः प्रयास (retry) अवधि के लिए शून्य पर बना रहे। रोलबैक विंडो बंद होने तक रिटायर हो रहे सीक्रेट को सुरक्षित रखता है।
चरण-दर-चरण विस्तृत विवरण
1. साइन किए गए बाइट्स को सुरक्षित रखें
JSON पार्सिंग से पहले अनुरोध के मुख्य भाग (body) को रॉ बाइट्स के रूप में एक बार पढ़ें। टाइमस्टैम्प और सीमांकक (delimiter) नियमों सहित, प्रोवाइडर के निर्देशानुसार सिग्नेचर इनपुट का सटीक निर्माण करें। कॉन्स्टेंट टाइम में MACs की तुलना करें और विकृत या अत्यधिक बड़े पेलोड को तुरंत रिजेक्ट करें।
2. सीक्रेट वर्जन्स को मॉडल करें
सक्रिय और रिटायर हो रहे वर्जन्स को निर्माण समय, समाप्ति, प्रोवाइडर स्कोप और PENDING, OVERLAP, या RETIRED जैसी स्थिति के साथ स्टोर करें। एक की (key) पहचानकर्ता बेहतर है क्योंकि यह ट्रायल सत्यापन से बचाता है; यदि अनुपलब्ध हो, तो दो-सीक्रेट फ़ॉलबैक को सीमित करें और रिकॉर्ड करें कि कौन सा सीक्रेट सफल रहा।
3. सुरक्षित रूप से रोल आउट करें
सीक्रेट मैनेजर के माध्यम से नए सीक्रेट को वितरित करें, रिसीवर्स को एटॉमिक रूप से पुनः लोड करें, और एक हस्ताक्षरित कैनरी चलाएँ। सेंडर से डुअल-साइन करने या तत्परता देखे जाने के बाद ही स्विच करने का अनुरोध करें। पुराने सीक्रेट को अधिकतम पुनः प्रयास (retry) अवधि और क्लॉक-स्क्यू मार्जिन तक उपलब्ध रखें।
4. रीप्ले को ब्लॉक करें
एक सीमित सहनशीलता के भीतर हस्ताक्षरित टाइमस्टैम्प की आवश्यकता होती है और पुनः प्रयासों को कवर करने वाली अवधारण अवधि (retention period) के साथ एक इवेंट ID या डाइजेस्ट स्टोर करें। कतार में लगाने (enqueueing) से पहले सत्यापन होना चाहिए; डुप्लिकेट वैध डिलीवरी व्यावसायिक प्रभावों को दोहराए बिना सफलता (ACK) स्वीकार कर सकती हैं।
5. निरीक्षण करें और रिटायर करें
सीक्रेट्स या पूर्ण संवेदनशील पेलोड को लॉग किए बिना की (key) वर्ज़न, पुराने टाइमस्टैम्प, डुप्लिकेट ID, विकृत सिग्नेचर और कतार परिणामों द्वारा सत्यापन सफलताओं की गणना करें। ओवरलैप और पुनः प्रयास (retry) की अवधि बीत जाने के बाद ही पुराने वर्ज़न को रिटायर करें; यदि नया वर्ज़न विफल हो जाता है, तो पुराने को पुनर्स्थापित करें और अलर्ट जारी करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं सीक्रेट मैनेजर में एक नया वर्ज़न स्टेज करूँगा, प्रत्येक रिसीवर को पुनः लोड करूँगा, और सेंडर को स्विच करने से पहले कैनरी को सत्यापित करूँगा। एक सीमित ओवरलैप के लिए, हस्ताक्षरित टाइमस्टैम्प की जांच करते हुए और इवेंट ID को डिडुप्लिकेट करते हुए, वर्तमान और रिटायर हो रहे वर्जन्स के हस्ताक्षरों को स्वीकार करें, जिसे प्राथमिकता के आधार पर की (key) ID द्वारा चुना गया हो। मैं वर्ज़न के अनुसार सत्यापन को ट्रैक करूँगा और रिटायरमेंट से पहले सेंडर के पुनः प्रयास क्षितिज (retry horizon) और क्लॉक स्क्यू तक प्रतीक्षा करूँगा। यदि नया वर्ज़न विफल हो जाता है, तो रोलबैक पुराने सीक्रेट को वैध रखता है; लॉग में केवल काउंटर्स और ID होते हैं, कभी भी सीक्रेट्स या रॉ पेलोड नहीं होते।"
सामान्य गलतियाँ
- सीक्रेट को हर जगह एक साथ बदलना → पुराने सिग्नेचर वाले पुनः प्रयास विफल हो जाते हैं → एक ओवरलैप विंडो का उपयोग करें।
- सत्यापन से पहले JSON पार्स करना → विहित बाइट्स बदल सकते हैं → पहले रॉ बॉडी को सत्यापित करें।
- हमेशा के लिए किसी भी सीक्रेट को स्वीकार करना → पुराने क्रेडेंशियल्स वैध बने रहते हैं → पुनः प्रयास और स्क्यू सीमाओं से बंधी समाप्ति निर्धारित करें।
- सिग्नेचर या सीक्रेट को लॉग करना → ऑब्जर्वेबिलिटी क्रेडेंशियल लीकेज बन जाती है → वर्जन्ड काउंटर्स और सुरक्षित पहचानकर्ताओं को लॉग करें।
अनुवर्ती प्रश्न और उत्तर
क्या होगा यदि सेंडर डुअल-साइन नहीं कर सकता है?
नए सीक्रेट को प्रीलोड करें और एक सीमित विंडो के लिए रिसीवर पर दोनों वर्जन्स को स्वीकार करें। सेंडर स्विच का समन्वय करें, वर्ज़न-विशिष्ट सत्यापन की निगरानी करें, और अधिकतम पुनः प्रयास अवधि तक पुराने वर्ज़न को बनाए रखें।
आप ओवरलैप अवधि कैसे चुनते हैं?
सेंडर की प्रलेखित पुनः प्रयास सीमा, कतार देरी, क्लॉक-स्क्यू सहनशीलता और घटना मार्जिन का उपयोग करें। समय सीमा को स्पष्ट करें और औसत विलंबता से अनुमान लगाने के बजाय समाप्ति के करीब पुराने वर्ज़न के ट्रैफ़िक पर अलर्ट करें।
क्या होगा यदि कोई हमलावर किसी पुराने वैध इवेंट को रीप्ले करता है?
सहनशीलता से बाहर के टाइमस्टैम्प को अस्वीकार करें और इवेंट ID या हस्ताक्षरित पेलोड डाइजेस्ट को डिडुप्लिकेट करें। रीप्ले रिकॉर्ड को कम से कम स्वीकृत टाइमस्टैम्प विंडो और व्यावसायिक पुनः प्रयास क्षितिज तक बनाए रखें।