1. समस्या और संदर्भ
एक सेवा किसी संसाधन को पढ़ने या लिखने का अनुरोध स्वीकार करती है। सेवा के पास स्वयं व्यापक अनुमतियाँ होती हैं, जबकि कॉलर को केवल सीमित प्राधिकार प्राप्त होना चाहिए। यदि सेवा कॉलर द्वारा नियंत्रित पथ या संसाधन आईडी का उपयोग करती है और फिर अपने स्वयं के विशेषाधिकारों के साथ कार्य करती है, तो एक हमलावर उससे ऐसा कार्य करवा सकता है जो कॉलर सीधे नहीं कर सकता था। AWS इसे कन्फ्यूज्ड डिप्टी समस्या (confused deputy problem) कहता है।
क्षमता-आधारित सुरक्षा इसे एक ऐसे संदर्भ (reference) या टोकन में प्राधिकार को स्पष्ट बनाकर हल करती है जो संसाधन की पहचान भी करता है और उसका उपयोग करने का अधिकार भी रखता है। क्षमता अपरिवर्तनीय (unforgeable), सीमित दायरे (scoped) वाली, और केवल उसी कोड को दी जानी चाहिए जिसे इसकी आवश्यकता है। यह प्रश्न एक सामान्य सुरक्षा-मॉडल चर्चा है; यह किसी एक क्लाउड प्रदाता या प्रोग्रामिंग भाषा तक सीमित नहीं है।
2. साक्षात्कारकर्ता क्या मूल्यांकन करता है
- प्राधिकार तर्क (Authority reasoning): क्या आप प्रमाणीकरण (authentication), प्राधिकरण (authorization), और प्रत्यायोजित प्राधिकार के अधिकार में अंतर कर सकते हैं?
- थ्रेट मॉडलिंग (Threat modeling): क्या आप डिप्टी, भ्रमित इनपुट, विशेषाधिकार प्राप्त कार्रवाई, और हमलावर-नियंत्रित सीमा को दिखा सकते हैं?
- न्यूनतम विशेषाधिकार (Least privilege): क्या आप किसी क्षमता को किसी एक ऑपरेशन, ऑब्जेक्ट, किरायेदार (tenant), या समय सीमा तक क्षीण (attenuate) करते हैं?
- जीवनचक्र निर्णय (Lifecycle judgment): क्या आप यह दावा किए बिना कि क्षमताएं सब कुछ हल करती हैं, निरसन (revocation), समाप्ति (expiry), ऑडिटेबिलिटी और रिसाव की व्याख्या कर सकते हैं?
- ट्रेड-ऑफ स्पष्टता: क्या आप वास्तविक परिचालन बाधाओं के तहत परिवेशी पहचान (ambient identity) और नीति जांचों के साथ क्षमताओं की तुलना कर सकते हैं?
एक कमजोर उत्तर कहता है "टोकन का उपयोग करें।" एक मजबूत उत्तर बताता है कि टोकन क्या अधिकृत करता है, यह कैसे सीमित है, और जब यह लीक हो जाता है या इसे रद्द किया जाना चाहिए तो क्या होता है।
3. पहले स्पष्ट करने योग्य प्रश्न
क्या डिप्टी स्थानीय कोड, कोई सेवा, या कोई क्लाउड भूमिका है?
पैटर्न वही रहता है, लेकिन सीमा बदल जाती है। एक लाइब्रेरी गलती से फ़ाइल हैंडल इनहेरिट कर सकती है; एक सेवा अपनी वर्कलोड पहचान का उपयोग कर सकती है; किसी क्लाउड भूमिका को क्रॉस-अकाउंट संसाधन पर कार्य करने के लिए धोखा दिया जा सकता है। उस प्रिंसिपल का नाम बताएं जिसके पास व्यापक प्राधिकार है।
किस संसाधन और ऑपरेशन को प्रत्यायोजित किया जा रहा है?
स्पष्ट करें कि प्राधिकार पढ़ना, लिखना, जोड़ना, हटाना, इनवोक करना, या कोई संयुक्त ऑपरेशन है या नहीं। वाइल्डकार्ड संसाधन नाम की तुलना में एक ऑब्जेक्ट और एक मेथड के लिए क्षमता का ऑडिट और निरसन करना आसान है।
निरसन और रिसाव संबंधी आवश्यकताएं क्या हैं?
पूछें कि क्या तत्काल निरसन, ऑफ़लाइन उपयोग, मल्टी-टेनेंट अलगाव, या गैर-अस्वीकार्य (non-repudiable) ऑडिट की आवश्यकता है। ये बाधाएं निर्धारित करती हैं कि इन-मेमोरी संदर्भ, हस्ताक्षरित टोकन, लीज, ब्रोकर, या केंद्रीय नीति जांच का उपयोग करना है या नहीं।
4. 30-सेकंड का उत्तर ढांचा
"एक कन्फ्यूज्ड डिप्टी तब प्रकट होता है जब एक कम-विशेषाधिकार प्राप्त कॉलर अधिक-विशेषाधिकार प्राप्त सेवा को एक संसाधन का नाम प्रदान करता है, और सेवा कॉलर के इच्छित दायरे में अनुरोध को बाइंड किए बिना अपने स्वयं के प्राधिकार का उपयोग करती है। क्षमता सुरक्षा प्राधिकार को स्पष्ट बनाती है: एक अपरिवर्तनीय संदर्भ या टोकन पास करें जो एक संसाधन और अनुमत ऑपरेशन का नाम देता है, और डिप्टी को केवल उसी संदर्भ का उपयोग करने की आवश्यकता होती है। मैं प्रत्यायोजन पर क्षमताओं को क्षीण करूँगा, उन्हें किरायेदार और ऑडियंस से बाइंड करूँगा, जोखिम के अनुसार उन्हें समाप्त या निरस्त करूँगा, और जारी करने तथा उपयोग को लॉग करूँगा। क्षमताएं परिवेशी प्राधिकार और कन्फ्यूज्ड-डिप्टी जोखिम को कम करती हैं, लेकिन रिसाव, रीप्ले, रिकवरी और ऑडिट अभी भी डिजाइन समस्याएं बनी रहती हैं।"
5. चरण-दर-चरण व्याख्या
चरण 1: पहचान को प्राधिकार से अलग करें
प्रमाणीकरण इस बात का उत्तर देता है कि कौन कॉल कर रहा है। प्राधिकरण इस बात का उत्तर देता है कि वह पहचान किसी नीति के तहत क्या कर सकती है। एक क्षमता एक ठोस प्राधिकार-युक्त संदर्भ है: इसका आधिपत्य और संदर्भ की अपरिवर्तनीय अखंडता एक विशिष्ट कार्रवाई की अनुमति देती है। यह मॉडल पहचान के साथ सह-अस्तित्व में रह सकता है, लेकिन यह प्रत्येक आंतरिक कॉल पर वैश्विक परिवेशी पहचान जांच पर निर्भर नहीं करता है।
चरण 2: कन्फ्यूज्ड-डिप्टी प्रवाह को चित्रित करें
मान लें कि एक रिपोर्ट सेवा अपनी वर्कलोड पहचान के तहत किसी भी फ़ाइल को पढ़ सकती है। एक उपयोगकर्ता file=/reports/other-tenant.csv भेजता है। यदि सेवा केवल यह सत्यापित करती है कि अनुरोध प्रमाणीकृत है, तो यह एक डिप्टी बन जाती है: उपयोगकर्ता एक नाम प्रदान करता है, और सेवा अपने व्यापक विशेषाधिकार का उपयोग करती है। गायब बाइंडिंग यह है कि "इस कॉलर को स्पष्ट रूप से इस ऑब्जेक्ट के लिए प्राधिकार दिया गया था।"
चरण 3: नामों को सीमित प्राधिकार से बदलें
इसके बजाय, एक अधिकृत स्वामी किसी विशिष्ट रिपोर्ट और ऑपरेशन के लिए एक क्षमता बनाता है, जैसे कि एक निश्चित समय सीमा तक किरायेदार A के लिए केवल-पढ़ने की पहुँच। कॉलर उस क्षमता को सेवा को देता है। सेवा क्षमता को डीरेफरेंस करती है या इसे ब्रोकर के समक्ष प्रस्तुत करती है; यह किसी मनमाने पथ को प्राधिकार में नहीं बदलती है। ऑब्जेक्ट-कैपेबिलिटी अनुसंधान इस पैटर्न को व्यक्तिगत ऑब्जेक्ट्स में एक्सेस अधिकारों को एन्कोड करने और उनकी बातचीत को प्रतिबंधित करने के रूप में वर्णित करता है।
चरण 4: प्रत्यायोजन पर क्षीण (Attenuate) करें
जब कोई घटक प्रत्यायोजित करता है, तो उसे एक कमजोर क्षमता उत्पन्न करनी चाहिए: कम मेथड्स, एक चाइल्ड ऑब्जेक्ट, एक छोटा जीवनकाल, किरायेदार की बाधा, या एक दर सीमा (rate limit)। डाउनस्ट्रीम घटक की सुविधा के लिए कभी भी क्षमता का दायरा न बढ़ाएं। एक रैपर जो केवल readMetadata() को उजागर करता है, लिखने और हटाने के अधिकारों वाले फ़ाइल-सिस्टम हैंडल को पास करने की तुलना में अधिक सुरक्षित है।
चरण 5: टोकन और रीप्ले को संभालें
यदि क्षमता किसी प्रक्रिया सीमा को पार करती है, तो एक संरक्षित संदर्भ का उपयोग करें जैसे कि एक हस्ताक्षरित, ऑडियंस-बाउंड टोकन या ब्रोकर द्वारा जारी किया गया हैंडल। इसमें संसाधन, क्रिया, किरायेदार, जारीकर्ता, ऑडियंस, समाप्ति और एक अद्वितीय आईडी शामिल करें जहाँ रीप्ले का महत्व हो। उपयोग से पहले अखंडता और संदर्भ को सत्यापित करें। एन्क्रिप्शन सामग्री को छिपा सकता है, लेकिन यह अपने आप में दायरे को लागू नहीं करता है या रीप्ले को नहीं रोकता है।
चरण 6: निरसन और रिकवरी की योजना बनाएं
विशुद्ध इन-मेमोरी क्षमताओं को पास करना आसान है लेकिन वैश्विक स्तर पर निरस्त करना कठिन है। लीज, छोटी समाप्ति, निरसन स्टोर के माध्यम से अप्रत्यक्षता (indirection), या की रोटेशन उपलब्धता और लेटेंसी के मुकाबले तत्काल नियंत्रण का समझौता करते हैं। यदि कोई टोकन लीक हो जाता है, तो हैंडल या बाइंडिंग को निरस्त करें, यदि आवश्यक हो तो प्रासंगिक की (key) को रोटेट करें, और उपयोग लॉग का निरीक्षण करें; केवल एक उपयोगकर्ता रिकॉर्ड को हटाने से पहले से जारी की गई क्षमता अमान्य नहीं हो सकती है।
चरण 7: ऑडिट और नीति सीमाओं को सुरक्षित रखें
रिकॉर्ड करें कि क्षमता किसने जारी की, इसका दायरा क्या था, किस डिप्टी ने इसका उपयोग किया, और परिणाम क्या था। जवाबदेही के लिए पहचान संदर्भ बनाए रखें, भले ही क्षमता ही प्राधिकरण का मूल तत्व हो। उच्च-जोखिम वाली कार्रवाइयों के लिए, क्षमता जांचों को किरायेदार की स्थिति, कानूनी रोक (legal hold), या स्टेप-अप प्रमाणीकरण जैसी नीति जांचों के साथ संयोजित करें।
6. उच्च-गुणवत्ता वाला नमूना उत्तर
"कन्फ्यूज्ड डिप्टी एक विशेषाधिकार बेमेल (privilege mismatch) है। एक कॉलर संसाधन का नाम प्रदान करता है, लेकिन व्यापक अधिकारों वाली एक सेवा ऑपरेशन निष्पादित करती है। सेवा भ्रमित हो जाती है क्योंकि नाम को प्राधिकार के रूप में माना जाता है। AWS क्रॉस-अकाउंट और क्रॉस-सर्विस एक्सेस के लिए इस पैटर्न का दस्तावेजीकरण करता है।
मैं इसके बजाय एक स्पष्ट क्षमता पास करूँगा: एक अपरिवर्तनीय संदर्भ या संरक्षित टोकन जो एक किरायेदार, ऑब्जेक्ट, ऑपरेशन, ऑडियंस और समाप्ति तक सीमित हो। डिप्टी केवल उस क्षमता का उपयोग कर सकता है, और प्रत्यायोजन एक क्षीण चाइल्ड बनाता है। रिमोट टोकन के लिए मैं अखंडता, संदर्भ और रीप्ले बाधाओं को सत्यापित करूँगा, फिर जारी करने और उपयोग को लॉग करूँगा।
निरसन एक ट्रेड-ऑफ है। मैं लुकअप लागत को स्वीकार करते हुए, संवेदनशील कार्यों के लिए अल्पकालिक लीज या एक निरस्त करने योग्य हैंडल का उपयोग कर सकता हूँ। क्षमताएं परिवेशी प्राधिकार को कम करती हैं और डेटा प्रवाह का निरीक्षण करना आसान बनाती हैं, लेकिन वे रिसाव, रिकवरी, ऑडिट या नीति आवश्यकताओं को समाप्त नहीं करती हैं। मैं क्रॉस-टेनेंट प्रयासों, टोकन रीप्ले, भ्रमित नामों और निरसन रेस कंडीशंस का परीक्षण करूँगा।"
7. सामान्य गलतियाँ
- "प्रमाणीकरण ही काफी है" → यह एक व्यापक सेवा पहचान को दायरा तय करने की अनुमति देता है → ऑपरेशन को एक स्पष्ट, सीमित प्राधिकार से बाइंड करें।
- "एक हस्ताक्षरित टोकन स्वचालित रूप से एक क्षमता है" → ऑडियंस, ऑपरेशन, समाप्ति और रीप्ले की अनदेखी करता है → अखंडता को एक गुण के रूप में मानें और दायरे को अलग से लागू करें।
- "लॉगिन जांचने के बाद कॉलर के पथ का उपयोग करना" → कन्फ्यूज्ड-डिप्टी प्रवाह को फिर से बनाता है → किसी मनमाने नाम के बजाय एक क्षमता या ब्रोकर हैंडल पास करें।
- "क्षमताएं प्राधिकरण नीति को समाप्त कर देती हैं" → किरायेदार की स्थिति और प्रासंगिक नियमों को नजरअंदाज करता है → क्षमता जांच को उच्च-जोखिम नीति जांच के साथ संयोजित करें।
- "निरसन मुफ़्त है" → वितरित प्रतियों और ऑफ़लाइन उपयोग की अनदेखी करता है → निरसन आवश्यकता के आधार पर लीज, अप्रत्यक्षता या समाप्ति चुनें।
- "सभी पहचान संदर्भ छुपाएं" → घटना की जांच को असंभव बनाता है → ऑडिट के लिए जारीकर्ता, विषय, दायरा और उपयोग की घटनाओं को सुरक्षित रखें।
8. अनुवर्ती प्रश्न
क्षमता ACL लुकअप से किस प्रकार भिन्न है?
एक ACL लुकअप पहचान और संसाधन नाम से शुरू होता है, फिर उपयोग के समय नीति से परामर्श करता है। एक क्षमता डेटा प्रवाह के माध्यम से एक प्रत्यायोजित प्राधिकार संदर्भ ले जाती है। ACLs नीति और निरसन को केंद्रीकृत करते हैं; क्षमताएं प्राधिकार को स्पष्ट बनाती हैं और परिवेशी प्राधिकार को कम कर सकती हैं, लेकिन उन्हें जीवनचक्र और रिसाव नियंत्रण की आवश्यकता होती है।
क्या किसी क्षमता की प्रतिलिपि (copy) बनाई जा सकती है?
एक इन-प्रोसेस संदर्भ को अक्सर उस कोड द्वारा कॉपी किया जा सकता है जिसके पास यह पहले से है। सुरक्षा सीमा यह है कि इसे कौन प्राप्त कर सकता है और क्या यह क्षीण है। एक रिमोट टोकन को तब तक रीप्ले किया जा सकता है जब तक कि यह किसी चैनल, नॉनस (nonce), ऑडियंस या छोटी लीज से बंधा न हो। कॉपी करने की योग्यता मॉडल करने योग्य एक जोखिम है, न कि यह मानने का कारण कि टोकन हानिरहित है।
आप क्षमता URL को कैसे सुरक्षित करेंगे?
इसे एक वाहक क्रेडेंशियल (bearer credential) के रूप में मानें: HTTPS, संकीर्ण दायरा, छोटी समाप्ति, गैर-अनुमान लगाने योग्य एन्ट्रापी, ऑडियंस बाइंडिंग, दर सीमाएं, और लॉग तथा रेफरर्स से रिडैक्शन का उपयोग करें। संवेदनशील या पुन: प्रयोज्य कार्रवाइयों के लिए, एक निरस्त करने योग्य हैंडल के लिए एक बार के विनिमय को प्राथमिकता दें।
क्लाउड सिस्टम में कन्फ्यूज्ड डिप्टी अभी भी कहाँ दिखाई देता है?
यह तब प्रकट होता है जब कोई सर्विस रोल, बिल्ड रनर, या स्टोरेज प्रॉक्सी उपयोगकर्ता-नियंत्रित संसाधन पहचानकर्ता को स्वीकार करता है और अपनी स्वयं की व्यापक भूमिका का उपयोग करता है। अनुरोध को संसाधन नीति, किरायेदार और इच्छित कार्रवाई से बाइंड करें; AWS का क्रॉस-अकाउंट मार्गदर्शन इस सीमा का एक ठोस उदाहरण है।