सिस्टम डिज़ाइन साक्षात्कार: आप एक मल्टी-टेनेंट सीक्रेट्स रोटेशन सर्विस कैसे डिज़ाइन करेंगे?

प्रश्न

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

इंटरव्यूअर क्या जांच रहा है

• क्या आप रोटेशन को एक अनरिकवरेबल क्रॉन स्क्रिप्ट के बजाय एक पुनः प्रयास करने योग्य (retryable) स्टेट मशीन के रूप में मॉडल करते हैं।
• क्या आप डुप्लिकेट संदेशों, एक सीक्रेट के लिए समवर्ती जॉब्स और टेनेंट आइसोलेशन को संभालते हैं।
• क्या आप पूरे सिस्टम में तत्काल विफलता पैदा करने के बजाय दो वर्शन्स को स्टेज करके धीरे-धीरे रोल आउट कर सकते हैं।
• क्या आप रिटायरमेंट, कॉम्प्रोमाइज़ रिस्पॉन्स, ऑडिट साक्ष्य और न्यूनतम विशेषाधिकार (least privilege) की व्याख्या कर सकते हैं।

मॉडल उत्तर

मुख्य ऑब्जेक्ट्स Secret, इम्यूटेबल Version, RotationPolicy, Job और Lease हैं। एक शेड्यूलर अगले रोटेशन समय के लिए एक जॉब जारी करता है; एक कतार (queue) secret_id द्वारा विभाजित होती है, और एक वर्कर समाप्ति समय (expiry) के साथ एक लीज़ प्राप्त करता है। (secret_id, idempotency_key) पर एक डेटाबेस विशिष्टता बाधा (uniqueness constraint) पुनः प्रयासों को सुरक्षित बनाती है।

scheduled → generating → external_updated → staged → rolling_out → verified → retired जैसी स्टेट मशीन का उपयोग करें। हर चरण में बाहरी अनुरोध पहचानकर्ता, वर्शन और अगले पुनः प्रयास समय को बनाए रखें (persist करें)। पहले बाहरी प्रदाता में क्रेडेंशियल बनाएं, फिर एक पेंडिंग वर्शन स्टोर करें। वर्कलोड्स एक इम्यूटेबल वर्शन संदर्भ या रिफ्रेश तंत्र के माध्यम से धीरे-धीरे स्विच करते हैं। हेल्थ चेक, त्रुटि दर और ऑथराइजेशन परीक्षण पास होने के बाद ही वर्शन को current में प्रमोट करें।

नियंत्रण मेटाडेटा को एन्क्रिप्टेड सीक्रेट पेलोड से अलग रखें। ऍप्लिकेशन्स को कम समय के लिए पढ़ने की अनुमति मिलती है। प्रत्येक स्टेट ट्रांजिशन बिना सीक्रेट प्लेनटेक्स्ट के केवल अपेंड-ओनली ऑडिट लॉग में जाता है। रोलबैक एक ऐसे पुराने वर्शन का चयन करता है जो अभी भी मान्य है; रिकवरी पूरी होने से पहले इसे उस वर्शन को स्वचालित रूप से रद्द (revoke) नहीं करना चाहिए।

आर्किटेक्चर स्केच

Scheduler -> Durable Queue -> Rotation Workers
     |              |              |
 Policy DB     Lease/Idempotency  External Provider
     |                             |
 Version Store + KMS        Rollout Controller -> Workloads
     |
 Audit Log / Metrics / Alerts

वर्कर्स लीज़ को रिन्यू करते हैं; समाप्ति के बाद दूसरा वर्कर कार्यभार संभाल सकता है। कतार के संदेशों में केवल सीक्रेट और जॉब पहचानकर्ता होते हैं। एक वर्कर एक प्रतिबंधित वर्शन स्टोर से मान पढ़ता है, जिससे संदेशों, लॉग्स और मीट्रिक लेबल्स में प्लेनटेक्स्ट नहीं जाता है।

महत्वपूर्ण प्रवाह

1. शेड्यूलर एक इडेम्पोटेंट जॉब बनाता है और टेनेंट कोटा लागू करता है।
2. एक वर्कर लीज़ प्राप्त करता है और वर्तमान वर्शन और पॉलिसी को पढ़ता है; एक पूर्ण हो चुकी जॉब सुरक्षित रूप से वापस लौटती है।
3. यह एक मान जनरेट करता है और प्रदाता-पक्ष इडेम्पोटेंसी की के साथ प्रदाता को कॉल करता है।
4. यह एक पेंडिंग वर्शन लिखता है और अनुकूलता जांच (compatibility checks) और एक छोटा रोलआउट चलाता है।
5. यह त्रुटि दर, प्रमाणीकरण सफलता और स्वास्थ्य जांच का निरीक्षण करता है; केवल तभी current में प्रमोट करता है।
6. सभी उपभोक्ताओं द्वारा पुष्टि करने के बाद, यह पुराने वर्शन को अक्षम और नष्ट कर देता है; विफलताओं पर पुनः प्रयास होता है या रोलबैक किया जाता है।

हर चरण में स्टेट और बाहरी प्रतिक्रियाओं को बनाए रखें। पुनरारंभ (restart) पर, यह अनुमान लगाने के बजाय कि प्रदाता पहले ही बदल दिया गया था या नहीं, अंतिम स्टेट से जारी रखें।

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

• क्रॉन में केवल अगला समय स्टोर करना, जिससे रीस्टार्ट या डुप्लिकेट डिलीवरी के बाद कोई रिकवरी बिंदु नहीं बचता।
• कनेक्शन पूल्स, कैशे और लंबे समय तक चलने वाले कनेक्शन्स को अनदेखा करते हुए पुराने मान को तुरंत रद्द करना।
• कतारों, लॉग्स, ट्रेसिंग स्पैन्स या त्रुटि संदेशों में प्लेनटेक्स्ट डालना।
• सभी टेनेंट्स के लिए एक ग्लोबल लॉक का उपयोग करना, या टेनेंट कोटा छोड़ देना जिससे एक टेनेंट सभी वर्कर्स को समाप्त कर दे।
• रोलबैक को यह जांचे बिना कि पुराना मान अभी भी मान्य और सक्रिय है, उसे फिर से लिखने के रूप में मानना।

कंसिस्टेंसी और सुरक्षा ट्रेड-ऑफ़

स्टेट मशीन और विशिष्टता बाधाओं के लिए एक स्ट्रॉन्गली कंसिस्टेंट डेटाबेस का उपयोग करें। सूचनाएं और रोलआउट at-least-once हो सकते हैं, इसलिए उपभोक्ताओं को इडेम्पोटेंट होना चाहिए। वर्शन रीड्स को संक्षेप में कैश किया जा सकता है, लेकिन वर्तमान-वर्शन में बदलाव और निरस्तीकरण के लिए एक स्पष्ट अमान्यीकरण (invalidation) पथ की आवश्यकता होती है। टेनेंट ऑथराइजेशन अपने स्वयं के सीक्रेट्स, जॉब्स और ऑडिट रिकॉर्ड्स तक पहुंच को सीमित करता है; वर्कर्स को केवल वर्तमान चरण के लिए आवश्यक प्रदाता अनुमतियां मिलती हैं।

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

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

• AWS Secrets Manager का AWSPENDING/AWSCURRENT रोटेशन प्रवाह: स्टेजिंग लेबल्स और पूर्णता चरण।
• Google Cloud Secret Manager रोटेशन मार्गदर्शन: पुनः प्रयास, गैर-समवर्ती रोटेशन, क्रमिक रोलआउट, और पुराने वर्शन की सफाई।
• NIST SP 800-57 भाग 1: की का उद्देश्य, सुरक्षा, उपयोग अवधि और निरस्तीकरण सिद्धांत।

फॉलो-अप प्रश्न

आप दो वर्कर्स को एक ही समय में एक सीक्रेट को रोटेट करने से कैसे रोकते हैं?

डेटाबेस लीज़ या फ़ेंसिंग टोकन वाले डिस्ट्रीब्यूटेड लॉक का उपयोग करें, और प्रत्येक स्टेट अपडेट में टोकन लिखें। वर्तमान टोकन के बिना पुनर्प्राप्त (recovered) वर्कर नए स्टेट को अधिलेखित (overwrite) नहीं कर सकता; लीज़ को नवीनीकरण और स्पष्ट समाप्ति की आवश्यकता होती है।

क्या होगा यदि प्रदाता के पास कोई इडेम्पोटेंट API नहीं है?

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

प्रत्येक ऍप्लिकेशन को latest पढ़ने की अनुमति क्यों नहीं दी जानी चाहिए?

latest तुरंत पूरे बेड़े में एक असत्यापित मान भेज सकता है। इम्यूटेबल वर्शन्स, स्टेज्ड रोलआउट और हेल्थ चेक ब्लास्ट रेडियस को सीमित करते हैं और एक रोलबैक पॉइंट को बनाए रखते हैं।

जब रोटेशन जॉब्स जमा हो जाती हैं तो आप सेवा की सुरक्षा कैसे करते हैं?

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

सुरक्षा से समझौता (compromise) होने के बाद सेवा क्या करती है?

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