सिस्टम डिज़ाइन इंटरव्यू: एक केंद्रीकृत ऑथराइजेशन डिसीजन सर्विस का निर्माण करें

प्रॉम्प्ट और संदर्भ

कई व्यावसायिक सेवाओं को एक ही प्रश्न का उत्तर देने की आवश्यकता होती है: कौन किस रिसोर्स पर कौन सा एक्शन कर सकता है? एक शेयर्ड डिसीजन सर्विस डिज़ाइन करें जो सब्जेक्ट, एक्शन, रिसोर्स और कॉन्टेक्स्ट स्वीकार करती है, ALLOW या DENY लौटाती है, और यूज़र्स, सर्विस अकाउंट्स, पदानुक्रमित (hierarchical) रिसोर्सेस, टेनेंट सीमाओं और पॉलिसी परिवर्तनों का समर्थन करती है।

इन इंटरव्यू मान्यताओं का उपयोग करें: बेसलाइन पर प्रति सेकंड 100,000 ऑथराइजेशन चेक, औसत का 3 गुना पीक, 20 ms p99 लेटेंसी लक्ष्य, रीड्स की तुलना में पॉलिसी राइट्स बहुत कम, और कॉलर्स को स्पष्ट अस्वीकृति (denial) और ऑथराइजेशन सर्विस की अस्थायी अनुपलब्धता के बीच अंतर करने में सक्षम होना चाहिए। ये समस्या की धारणाएं हैं, उद्योग के बेंचमार्क नहीं। पेमेंट कैप्चर, की जारी करना और बिज़नेस डेटाबेस राइट्स इस सर्विस से बाहर रहते हैं।

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

मजबूत उत्तर केवल “RBAC सर्विस जोड़ें” कहने के बजाय ऑथराइजेशन को चार-टुपल (four-tuple) और एक कंसिस्टेंसी अनुबंध में बदल देते हैं:

• सब्जेक्ट, रिसोर्स, एक्शन, कॉन्टेक्स्ट, पदानुक्रम और क्रॉस-टेनेंट संदर्भों के लिए सीमाओं की मॉडलिंग करना;
• कब ACL, RBAC, ABAC, या संबंध-आधारित नीतियां उपयुक्त होती हैं, और सेवाओं के बीच पॉलिसी लॉजिक को अलग होने से कैसे रोका जाए;
• डिसीजन-रीड पाथ, पॉलिसी-राइट पाथ, कैश और इनवैलिडेशन इवेंट्स एक साथ कैसे काम करते हैं;
• पॉलिसी परिवर्तन कब दिखाई देता है और क्या पुराना कैश अभी भी एक्सेस की अनुमति दे सकता है;
• प्रत्येक जोखिम वर्ग के लिए आउटेज फेल-ओपन (fail-open) है या फेल-क्लोज़्ड (fail-closed);
• कैसे लॉग, स्पष्टीकरण, रीप्ले और फॉल्ट इंजेक्शन क्रॉस-टेनेंट लीकेज के बिना सही अस्वीकृति साबित करते हैं।

पूछने के लिए स्पष्टीकरण प्रश्न

ऐसे प्रतिबंध पूछें जो डिज़ाइन को बदलते हैं:

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

30-सेकंड का उत्तर ढांचा

इस संरचना से शुरुआत करें:

“मैं एक अनुरोध को (principal, action, resource, context) के रूप में मॉडल करता हूं। एक पॉलिसी इंजन अनुमति (allow), अस्वीकृति (deny), एक पॉलिसी वर्शन और नियंत्रित डिबगिंग की आवश्यकता होने पर एक आंतरिक रूल आईडी लौटाता है। एक कंट्रोल प्लेन टेनेंट-स्कोप वाली पॉलिसी और रिलेशन डेटा का प्रबंधन करता है; एक डेटा प्लेन स्थानीय रीड-ओनली कैश में अपरिवर्तनीय वर्शन वाले स्नैपशॉट का मूल्यांकन करता है। पब्लिशिंग रीप्ले करने योग्य इनवैलिडेशन इवेंट्स का उत्सर्जन करती है, और कॉलर्स न्यूनतम पॉलिसी वर्शन भेजते हैं ताकि पुराने स्नैपशॉट चुपचाप नए निर्णय को ओवरराइड न कर सकें। ऑथराइजेशन अनुपलब्ध होने पर संवेदनशील पाथ फेल-क्लोज़ होते हैं; कम जोखिम वाले रीड केवल एक स्पष्ट उत्पाद नीति के तहत डिग्रेड होते हैं। मैं फॉल्ट इंजेक्शन और रीप्ले के साथ रिवोकेशन प्रसार, क्रॉस-टेनेंट सीमाओं, कैश रेस और डिपेंडेंसी विफलताओं को मान्य करता हूं।”

यह फॉलो-अप द्वारा विस्तार के लिए एक क्षेत्र का चयन करने से पहले मॉडल, डेटा फ्लो, कंसिस्टेंसी और विफलता व्यवहार प्रदान करता है।

चरण-दर-चरण गहन विश्लेषण

पहले पॉलिसी सिमेंटिक्स को परिभाषित करें। एक सब्जेक्ट कोई यूज़र, सर्विस अकाउंट या ग्रुप हो सकता है। एक रिसोर्स पदानुक्रम में टेनेंट, प्रोजेक्ट या डॉक्यूमेंट हो सकता है। एक्शन्स एक सीमित शब्दावली होनी चाहिए जैसे read, write, और share। कॉन्टेक्स्ट में डिवाइस स्थिति, स्रोत या समय शामिल हो सकता है, लेकिन एक असत्यापित क्लाइंट फ़ील्ड एक विश्वसनीय तथ्य नहीं है। NIST का ABAC मार्गदर्शन सब्जेक्ट, ऑब्जेक्ट और पर्यावरण विशेषताओं को डिसीजन इनपुट के रूप में मानता है; संबंध नीतियां सदस्यता को ट्रैवर्स करने योग्य किनारों (traversable edges) के रूप में दर्शाती हैं।

कंट्रोल और डेटा प्लेन को अलग करें। कंट्रोल प्लेन नीतियों को संपादित, मान्य, स्वीकृत, वर्शन और रोलबैक करता है। डेटा प्लेन केवल प्रकाशित अपरिवर्तनीय स्नैपशॉट लोड करता है और चेक्स का उत्तर देता है। व्यावसायिक सेवाओं को अलग-अलग पॉलिसी पार्सर नहीं भेजना चाहिए। एक प्रकाशन एक मोनोटोनिक वर्शन और एक इनवैलिडेशन इवेंट बनाता है; डेटा प्लेन स्नैपशॉट को एटॉमिक रूप से स्वैप करता है ताकि आधा-प्रकाशित नियम सेट कभी दिखाई न दे।

चेक एपीआई डिज़ाइन करें। एक आंतरिक इंटरफ़ेस हो सकता है:

Check(principal, action, resource, context, min_policy_version)
  -> decision, policy_version, rule_id, expires_at
BatchCheck(principal, [(action, resource, context)...])
  -> decisions[]

rule_id नियंत्रित लॉग और डिबगिंग के लिए है। क्रॉस-टेनेंट कॉलर को त्रुटि विवरण के माध्यम से रिसोर्स के अस्तित्व का पता नहीं चलना चाहिए। बैच चेक्स राउंड ट्रिप को कम करते हैं लेकिन बैच के आकार और मूल्यांकन लागत पर सीमा की आवश्यकता होती है।

कंसिस्टेंसी और कैशिंग को संभालें। एक स्थानीय कैश 20 ms के लक्ष्य को पूरा कर सकता है, लेकिन रिवोकेशन केवल TTL पर निर्भर नहीं हो सकता है। एक कॉलर अपने द्वारा देखे गए अंतिम पॉलिसी वर्शन को भेज सकता है; यदि स्थानीय वर्शन पीछे है, तो सेवा एक शेयर्ड रेप्लिकेट पढ़ती है या “अस्थायी रूप से अनिर्णीत” लौटाती है। इनवैलिडेशन इवेंट्स को एक रीप्ले कर्सर और आवधिक समाधान (reconciliation) की आवश्यकता होती है ताकि खोई हुई अधिसूचना पुराने अनुमतियों को न छोड़े। अत्यधिक संवेदनशील रिसोर्सेस के लिए, एक रिसोर्स वर्शन या शॉर्ट लीज शामिल करें ताकि अनुमति और ऑब्जेक्ट वर्शन की एक साथ जांच की जा सके।

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

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

ऑडिट और सत्यापन करें। एक रिक्वेस्ट हैश, सब्जेक्ट, एक्शन, रिसोर्स प्रकार, निर्णय, पॉलिसी वर्शन, लेटेंसी और विफलता वर्ग रिकॉर्ड करें; संवेदनशील मानों को अपरिवर्तनीय पहचानकर्ताओं के रूप में रखें। रिवोकेशन के बाद पुराने कैश, ग्रुप-इनहेरिटेंस चक्र, टेनेंट्स में समान रिसोर्स आईडी, पब्लिशिंग के दौरान क्रैश, डुप्लिकेट या खोए हुए इनवैलिडेशन इवेंट्स, डेटा-प्लेन रीस्टार्ट और डिपेंडेंसी टाइमआउट का परीक्षण करें। स्वीकृति के लिए केवल DENY वापस करने के बजाय पॉलिसी वर्शन को रीप्ले करने और निर्णय की व्याख्या करने की आवश्यकता होती है।

अड़चनों (bottlenecks) का अनुमान लगाएं। बेसलाइन पर 100,000 चेक प्रति सेकंड और 300,000 पीक पर, 2 KB प्रति रिक्वेस्ट का अर्थ लगभग 600 MB/s पीक इनग्रेस है। प्रत्येक रिक्वेस्ट पर एक पूरी पॉलिसी भेजने से लेटेंसी और बैंडविड्थ बढ़ जाती है, इसलिए स्थानीय स्नैपशॉट, बैच चेक्स और रीड रेप्लिका को प्राथमिकता दें। यदि रिलेशन ट्रैवर्सल अड़चन बन जाता है, तो टेनेंट या रिसोर्स द्वारा शार्ड करें और गहराई और फैन-आउट को सीमित करें। बताएं कि लोड टेस्ट इन मान्यताओं को कैसे बदलेंगे।

उच्च गुणवत्ता वाला नमूना उत्तर

“मैं पहले रिवोकेशन लक्ष्य और विफलता के दौरान सुरक्षा सीमा की पुष्टि करूंगा। पीक पर 300,000 चेक प्रति सेकंड, 20 ms p99 लक्ष्य, और 5 सेकंड के भीतर रिवोकेशन प्रभावी होने की धारणा मान लें। मैं कंट्रोल और डेटा प्लेन को अलग करूंगा। कंट्रोल प्लेन टेनेंट-स्कोप वाले ACL, ग्रुप रिलेशन्स और ABAC स्थितियों को संग्रहीत करता है; पब्लिशिंग से पहले यह सिंटैक्स, चक्र और क्रॉस-टेनेंट संदर्भों की जांच करता है, फिर एक अपरिवर्तनीय स्नैपशॉट और मोनोटोनिक वर्शन बनाता है। प्रत्येक क्षेत्र का डेटा प्लेन स्थानीय रीड-ओनली कैश से (subject, action, resource, context) का मूल्यांकन करता है। इनवैलिडेशन इवेंट्स में एक कर्सर होता है और वे रीप्ले करने योग्य होते हैं; एक कॉलर min_policy_version भेज सकता है, ताकि पीछे चल रहा कैश एक शेयर्ड रेप्लिका पढ़ सके या UNAVAILABLE लौटा सके।

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

यह मान्यताओं, मॉडल, कंसिस्टेंसी, विफलता प्रबंधन और सत्यापन को जोड़ता है। इंटरव्यू में, जैसे-जैसे बाधाएं बदलती हैं, विवरण को ट्रिम करें; प्रति सेकंड 300,000 चेक और 5 सेकंड सार्वभौमिक उत्पादन तथ्य नहीं हैं।

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

• हर मामले को RBAC तक सीमित करना। रोल्स स्वाभाविक रूप से पदानुक्रम, इनहेरिटेड संबंधों या पर्यावरणीय स्थितियों को व्यक्त नहीं करते हैं। मॉडल चुनने से पहले अनुमति सिमेंटिक्स को परिभाषित करें।
• रिवोकेशन के रूप में एक निश्चित TTL का उपयोग करना। TTL एक पुरानेपन के मामले को बांधता है लेकिन खोई हुई सूचनाओं या वर्शन रेस को हल नहीं करता है। वर्शन्स, रीप्ले करने योग्य इनवैलिडेशन और समाधान जोड़ें।
• हमेशा फेल-ओपन या हमेशा फेल-क्लोज़ होना। रिसोर्स जोखिम अलग होता है। सुरक्षा स्तर, स्नैपशॉट की ताजगी और व्यावसायिक प्रतिवर्तीता से व्यवहार को परिभाषित करें।
• हर सेवा में पॉलिसी लॉजिक की नकल करना। एकाधिक पार्सर अलग हो जाते हैं और अलग-अलग अस्वीकृतियां उत्पन्न करते हैं। पॉलिसी का वर्शन बनाएं और एक निर्णय इंटरफ़ेस को कॉल करें।
• “रिसोर्स गायब है” या विस्तृत नियम लौटाना। यह क्रॉस-टेनेंट जानकारी को लीक करता है। स्थिर बाहरी त्रुटियों और नियंत्रित आंतरिक रूल आईडी का उपयोग करें।
• केवल सामान्य अनुमति पाथ का परीक्षण करना। रिवोकेशन, रीप्ले, चक्र और टेनेंट सीमाएं वे हैं जहां ऑथराइजेशन विफल होता है। फॉल्ट इंजेक्शन और वर्शन वाले रीप्ले का उपयोग करें।

फॉलो-अप प्रश्न और उत्तर

क्या रिवोकेशन तत्काल होने पर भी स्थानीय कैश बना रह सकता है?

हाँ, लेकिन कैश अकेले निर्णय नहीं ले सकता। रिवोकेशन को विश्व स्तर पर अवलोकनीय वर्शन या लीज इनवैलिडेशन बनाना चाहिए। संवेदनशील अनुरोध न्यूनतम पॉलिसी वर्शन ले जाते हैं; पीछे चल रहा कैश स्थानीय डेटा को बायपास करता है या पुष्टि की प्रतीक्षा करता है। यदि पुष्टि बजट में फिट नहीं हो सकती है, तो चुपचाप पुरानी अनुमति का उपयोग करने के बजाय UNAVAILABLE लौटाएं या अस्वीकार करें।

क्या होगा यदि रिलेशन ट्रैवर्सल पैरेंट ग्रुप्स के माध्यम से एक चक्र ढूंढता है?

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

आप कैसे साबित करते हैं कि कोई क्रॉस-टेनेंट ऑथराइजेशन नहीं है?

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

क्या आपको Zanzibar के बाहरी कंसिस्टेंसी मॉडल की नकल करनी चाहिए?

नहीं। रिवोकेशन लक्ष्य और व्यावसायिक जोखिम से वर्शन टोकन, लीज या मजबूत कंसिस्टेंसी चुनें। यदि कोई उत्पाद वादा करता है कि हाल ही में हटाया गया सदस्य किसी पुराने ऑब्जेक्ट को पढ़ना जारी नहीं रख सकता है, तो कारणात्मक क्रम (causal ordering) और ऑब्जेक्ट वर्शन उचित हैं। कम जोखिम वाली सार्वजनिक सामग्री के लिए, कमजोर कंसिस्टेंसी और लंबी कैशिंग सरल हो सकती है। वादे और उसकी लागत का उल्लेख करें।