प्रॉम्प्ट और संदर्भ
यह सिस्टम-डिज़ाइन प्रश्न अस्थायी क्रेडेंशियल्स के जीवनचक्र और प्राधिकरण सीमा (authorization boundary) का परीक्षण करता है। चुनौती केवल ऑब्जेक्ट-स्टोरेज साइनिंग API को रैप करना नहीं है; बल्कि लीकेज, निरस्तीकरण, कुंजी रोटेशन और मल्टी-रीजन एक्सेस के दौरान भी लिंक को सीमित रूप से सक्षम और नियंत्रणीय बनाए रखना है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या हस्ताक्षरित URL टेनेंट, ऑब्जेक्ट, मेथड, संस्करण, रेंज और समाप्ति से बंधा (bound) है।
- क्या साइनिंग, लाइव प्राधिकरण, निरस्तीकरण और स्टोरेज अनुमतियों में अंतर किया गया है।
- क्या कुंजी रोटेशन, शॉर्ट कैशिंग, CDN डिलीवरी, रेट लिमिट्स और ऑडिट फ़्लो को डिज़ाइन किया गया है।
- क्या लीकेज, रीप्ले, क्लॉक स्क्यू, क्षेत्रीय विफलता और निरस्तीकरण में देरी के ट्रेड-ऑफ़ को समझाया गया है।
पूछने के लिए स्पष्टीकरण प्रश्न
डाउनलोड बनाम अपलोड, एकल ऑब्जेक्ट बनाम बैच, Range और मल्टीपार्ट की ज़रूरतें, अधिकतम लाइफटाइम, सेकंड-स्तरीय निरस्तीकरण और CDN की भागीदारी की पुष्टि करें। टेनेंट आइसोलेशन, ऑडिट प्रतिधारण (retention), कुंजी प्रबंधन, मल्टी-रीजन रिकवरी और ऑब्जेक्ट-वर्जन सेमेंटिक्स के बारे में पूछें।
30-सेकंड का उत्तर ढाँचा
एक प्राधिकरण सेवा पहले कॉलर को मान्य करती है, फिर टेनेंट, ऑब्जेक्ट संस्करण, ऑपरेशन, शर्तों और एक छोटी समाप्ति अवधि से बंधे URL पर हस्ताक्षर करती है। हस्ताक्षर एक सामान्यीकृत (normalized) अनुरोध और कुंजी संस्करण को कवर करता है; स्टोरेज या एज इसे सत्यापित करता है। उच्च-जोखिम वाले निरस्तीकरण के लिए छोटे TTL, डिनाई-लिस्ट (deny-list) या संस्करण-निरस्त मार्कर का उपयोग किया जाता है। URL केवल आवश्यक क्षमताएं प्रदान करता है, जबकि अपरिवर्तनीय ऑडिट इवेंट, रीप्ले डिटेक्शन, रेट लिमिट्स और कुंजी रोटेशन जोखिम को नियंत्रित रखते हैं।
चरण-दर-चरण गहन विश्लेषण
1. क्रेडेंशियल और अनुमति मॉडल को परिभाषित करें
टेनेंट, एक ऑब्जेक्ट कुंजी या अनुमान न लगाया जा सकने वाला ID, संस्करण, अनुमत मेथड, बाइट रेंज, content-type बाधाएं, जारीकर्ता, समाप्ति और कुंजी संस्करण शामिल करें। एक अपलोड URL आकार, चेकसम और गंतव्य उपसर्ग को भी सीमित करता है। सर्वर हस्ताक्षर करने से पहले लाइव ऑब्जेक्ट प्राधिकरण करता है; क्लाइंट अनुमति बढ़ाने के लिए पैरामीटर संपादित नहीं कर सकते।
2. साइनिंग और सत्यापन पथ चुनें
स्टोरेज-अनुकूल HMAC या असममित (asymmetric) हस्ताक्षर का उपयोग करें जो मेथड, पाथ, क्वेरी पैरामीटर, महत्वपूर्ण हेडर और समाप्ति को कवर करता है। व्हाइटस्पेस, एन्कोडिंग और पैरामीटर क्रम को कैनोनिकलाइज़ (canonicalize) करें। सत्यापनकर्ता समय विंडो, कुंजी संस्करण, हस्ताक्षर और शर्तों की जाँच करता है। संवेदनशील ऑपरेशन अभी भी हर प्राधिकरण निर्णय को एक स्व-निहित URL में डालने के बजाय लाइव चेक का उपयोग करते हैं।
3. निरस्तीकरण, रोटेशन और रीप्ले सुरक्षा डिज़ाइन करें
छोटी समाप्ति अवधि लीकेज के प्रभाव को सीमित करती है। उच्च-मूल्य वाले लिंक के लिए, Redis या एज नियम टोकन ID, ऑब्जेक्ट-वर्जन निरस्तीकरण, या टेनेंट डिनाई-लिस्ट रख सकते हैं। कुंजी रोटेशन के दौरान, सबसे लंबे URL का लाइफटाइम समाप्त होने तक पुराने संस्करण को बनाए रखें, फिर उसे हटा दें। एक बार के अपलोड के लिए एक नॉन्स (nonce), ऑब्जेक्ट स्थिति और पूर्णता मार्कर की आवश्यकता हो सकती है; बार-बार डाउनलोड एक स्पष्ट व्यावसायिक नीति का पालन करते हैं।
4. स्टोरेज, CDN और विफलताओं को स्केल करें
मेटाडेटा और निरस्तीकरण को उच्च उपलब्धता वाले स्टोरेज में रखते हुए, जारी करने (issuance) की प्रक्रिया को स्टेटलेस रखें। एप्लिकेशन सर्वर के बजाय स्टोरेज या CDN के माध्यम से सीधे ऑब्जेक्ट बाइट्स भेजें। CDN नीति में हस्ताक्षर और अनुमति सीमाएं शामिल होनी चाहिए ताकि एक टेनेंट की निजी प्रतिक्रिया का दूसरे द्वारा पुन: उपयोग न किया जा सके। यदि कुंजी प्रबंधन या निरस्तीकरण स्टोरेज अनुपलब्ध है, तो नए जारी करने और उच्च-जोखिम एक्सेस के लिए फ़ेल क्लोज़्ड (fail closed) करें; पहले से जारी कम-जोखिम वाले लिंक को उनके प्रलेखित TTL के अनुसार संभालें।
5. निरीक्षण करें, रेट-लिमिट करें और सुरक्षा सत्यापित करें
पूर्ण URL क्वेरी को लॉग किए बिना जारीकर्ता, टेनेंट, ऑब्जेक्ट, मेथड, परिणाम, क्षेत्र, क्लाइंट-फ़िंगरप्रिंट सारांश और निरस्तीकरण कारण का ऑडिट करें। टेनेंट, उपयोगकर्ता, ऑब्जेक्ट और IP द्वारा जारी करने की दर, कुल बाइट्स और समवर्तीता (concurrency) को सीमित करें; असामान्य पुन: उपयोग का पता लगाएं। पैरामीटर छेड़छाड़, समाप्ति, क्लॉक स्क्यू, रोटेशन, निरस्तीकरण विलंब, क्रॉस-टेनेंट एक्सेस, CDN हिट्स और क्षेत्रीय विफलता का परीक्षण करें।
मजबूत नमूना उत्तर
कॉलर को मान्य करने के बाद, प्राधिकरण सेवा टेनेंट, अपरिवर्तनीय ऑब्जेक्ट संस्करण, मेथड, शर्तों और छोटी समाप्ति अवधि से बंधा URL जारी करती है। हस्ताक्षर कैनोनिकल पाथ, क्वेरी और महत्वपूर्ण हेडर को कवर करता है; स्टोरेज या CDN इसे सत्यापित करता है, इसलिए ऐप बड़ी फ़ाइलों को प्रॉक्सी नहीं करता है। उच्च-जोखिम वाले लिंक छोटे TTL, डिनाई-लिस्ट या संस्करण मार्कर के माध्यम से निरस्तीकरण का समर्थन करते हैं। सबसे लंबे लिंक की अवधि समाप्त होने तक पुरानी कुंजियों को बनाए रखें। पूर्ण URL के बिना जारी करने और एक्सेस परिणामों का ऑडिट करें, टेनेंट और ऑब्जेक्ट द्वारा रेट-लिमिट करें, और छेड़छाड़, रीप्ले, स्क्यू, रोटेशन, निरस्तीकरण, क्रॉस-टेनेंट एक्सेस और CDN आइसोलेशन का परीक्षण करें।
सामान्य गलतियाँ
- टेनेंट, मेथड, संस्करण या अपलोड शर्तों के बिना केवल एक ऑब्जेक्ट पाथ पर हस्ताक्षर करना।
- स्थायी URL को निरस्तीकरण तंत्र के रूप में मानना और लीकेज रोकथाम की कोई व्यवस्था न होना।
- रोटेशन के दौरान पुरानी कुंजी को तुरंत हटा देना और मान्य लिंक को तोड़ना।
- CDN पर केवल पाथ द्वारा निजी सामग्री को कैश करना और हस्ताक्षर या टेनेंट की उपेक्षा करना।
- लॉग, एनालिटिक्स या त्रुटि संदेशों में पूर्ण हस्ताक्षरित URL लिखना।
- केवल हस्ताक्षर वैधता का परीक्षण करना और छेड़छाड़, रीप्ले, क्लॉक स्क्यू और निरस्तीकरण विलंब को छोड़ देना।
फॉलो-अप प्रश्न और उत्तर
सभी प्राधिकरणों को JWT में क्यों न रखा जाए?
एक हस्ताक्षरित URL शर्तों को एक संसाधन अनुरोध से बांधता है जिसे स्टोरेज बड़ी बाइट्स को प्रॉक्सी किए बिना सत्यापित कर सकता है, लेकिन यह रीयल-टाइम निरस्तीकरण प्रणाली नहीं है। उच्च-जोखिम वाले विशेषाधिकारों के लिए अभी भी छोटे TTL, संस्करण निरस्तीकरण या लाइव चेक की आवश्यकता होती है।
निरस्तीकरण सेकंडों के भीतर कैसे प्रभावी हो सकता है?
एज या सत्यापनकर्ता से बहुत कम कैश TTL के साथ उच्च-प्राथमिकता वाली डिनाई-लिस्ट, ऑब्जेक्ट-वर्जन मार्कर या टेनेंट स्थिति की जाँच करवाएं। इससे रीड्स और निरंतरता (consistency) का दबाव बढ़ता है, इसलिए इसे जोखिम स्तर के अनुसार लागू करें।
एक अपलोड URL किसी अन्य ऑब्जेक्ट को ओवरराइट करने से कैसे रोकता है?
इसे एक अपरिवर्तनीय कुंजी या एक बार के अपलोड ID, If-None-Match, आकार और चेकसम से बाइंड करें। पूरा होने पर, टेनेंट और ऑब्जेक्ट स्थिति की पुन: जाँच करें और पाथ प्रतिस्थापन या डुप्लिकेट पूर्णता को अस्वीकार करें।
क्या CDN को हस्ताक्षरित URL कैश करने चाहिए?
यह केवल तभी बाइट्स को कैश कर सकता है जब कुंजी, हेडर और TTL निजी प्रतिक्रियाओं को अनुमति सीमाओं को पार करने से रोकते हैं। उच्च-जोखिम या बहुत कम समय तक रहने वाले संसाधन शेयर्ड कैश को बायपास कर सकते हैं, जिससे आइसोलेशन और नियंत्रणीय निरस्तीकरण के लिए हिट दर से समझौता किया जा सकता है।