सिस्टम डिज़ाइन इंटरव्यू: एक मल्टी-टेनेंट ऑथराइजेशन पॉलिसी सर्विस डिज़ाइन करना

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

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

मुख्य फोकस ऑथराइजेशन डिसीजन पाथ और इसकी कंसिस्टेंसी बाउंड्री है। केवल एक पॉलिसी डेटाबेस न बनाएं; रिक्वेस्ट कॉन्टेक्स्ट, पॉलिसी पब्लिकेशन, कैश इनवैलिडेशन और कॉलर्स पर डिनाई या टाइमआउट के प्रभाव की व्याख्या करें।

इंटरव्यूअर क्या टेस्ट कर रहा है

वे चाहते हैं कि आप बिज़नेस सर्विस में पॉलिसी डिसीजन पॉइंट (PDP) को पॉलिसी एन्फोर्समेंट पॉइंट (PEP) से अलग करें, और टेनेंट आइसोलेशन, वर्ज़न प्रोपेगेशन और एक्सप्लेनेबल ऑडिट डिज़ाइन करें। OPA पॉलिसी निर्णयों को एन्फोर्समेंट से अलग करने का दस्तावेज़ीकरण करता है; Zanzibar पेपर ग्लोबल ऑथराइजेशन स्केल पर कॉज़ल ऑर्डरिंग और लो लेटेंसी के ट्रेड-ऑफ़ को दिखाता है।

पहले स्पष्ट करने योग्य प्रश्न

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

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

मैं ऑथराइजेशन मॉडल और "नो क्रॉस-टेनेंट एक्सेस" इनवेरिएंट को परिभाषित करूंगा, फिर PEP, PDP, पॉलिसी स्टोरेज, डिस्ट्रीब्यूशन और ऑडिट का आरेख बनाऊंगा। पॉलिसियों को प्रति टेनेंट वर्ज़न किया जाता है; PDPs स्वीकृत वर्ज़न्स को स्थानीय रूप से या इन-ज़ोन कैश करते हैं। रिक्वेस्ट्स में सब्जेक्ट, एक्शन, रिसोर्स और आवश्यक कॉन्टेक्स्ट शामिल होते हैं। हाई-रिस्क रिवोकेशन्स के लिए वर्ज़न कन्फर्मेशन की आवश्यकता होती है; यदि PDP अनुपलब्ध है, तो सेंसिटिव एक्शन्स डिनाई हो जाते हैं। p99 लेटेंसी, प्रोपेगेशन डिले, गलत डिनाई और ऑडिट इंटीग्रिटी को मापें।

स्टेप-बाय-स्टेप विश्लेषण

स्टेप 1: ऑथराइजेशन ऑब्जेक्ट्स और पॉलिसी इनपुट को परिभाषित करें

एक कंसिस्टेंट रिक्वेस्ट शेप का उपयोग करें: सब्जेक्ट, एक्शन, रिसोर्स और कॉन्टेक्स्ट, जिसमें स्पष्ट टेनेंट और रिसोर्स नेमस्पेस हों। RBAC रोल ग्रांट्स को संभालता है, ABAC डिपार्टमेंट, डिवाइस या टाइम जैसे एट्रिब्यूट्स को संभालता है, और रिलेशनशिप-आधारित ऑथराइजेशन "यह यूज़र एक डॉक्यूमेंट कोलैबोरेटर है" को संभालता है। पॉलिसी लैंग्वेज को हर सर्विस द्वारा अपने नियम बनाए बिना अनुमति (allow), अस्वीकृति (deny), प्राथमिकता (precedence) और कंडीशन्स को व्यक्त करना चाहिए।

स्टेप 2: PEP, PDP और पॉलिसी मैनेजमेंट को अलग करें

PEP एक API गेटवे या बिज़नेस सर्विस में रहता है, ट्रस्टेड आइडेंटिटी इकट्ठा करता है, और allow या deny को लागू करता है। PDP मूल्यांकन करता है और एक निर्णय, पॉलिसी वर्ज़न और वैकल्पिक कारण लौटाता है। मैनेजमेंट प्लेन पॉलिसियों को एडिट, वैलिडेट, अप्रूव, पब्लिश और रोलबैक करता है। OPA निर्णयों को एन्फोर्समेंट से अलग करता है और स्थानीय या नेटवर्क डिप्लॉयमेंट का समर्थन करता है; लेटेंसी और उपलब्धता के आधार पर चुनें।

स्टेप 3: टेनेंट स्टोरेज और वर्ज़न्ड पब्लिकेशन डिज़ाइन करें

पॉलिसी, रिसोर्स रिलेशनशिप्स और एट्रिब्यूट्स में tenant_id होता है, जिसे हर रीड पर चेक किया जाता है। पब्लिकेशन एक इम्यूटेबल वर्ज़न और डाइजेस्ट बनाता है, इसे सैंडबॉक्स में इवैल्यूएट करता है, फिर इसे PDPs को बैचों में डिस्ट्रीब्यूट करता है। ऑथर, अप्रूवर, समय और स्कोप रिकॉर्ड करें। रिवोकेशन या सिक्योरिटी पॉलिसियां प्राथमिकता ले सकती हैं और पुराने वर्ज़न्स को एक सीमित विंडो के भीतर समाप्त (expire) होने की आवश्यकता होती है।

स्टेप 4: कंसिस्टेंसी, कैशिंग और रिवोकेशन को संभालें

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

स्टेप 5: फेलियर मोड्स और सुरक्षित डिफॉल्ट्स डिज़ाइन करें

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

स्टेप 6: ऑडिट, एक्सप्लेनेबिलिटी और ऑब्जर्वेबिलिटी

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

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

मैं सिस्टम को बिज़नेस सर्विसेज़ में PEPs, इन-ज़ोन PDP क्लस्टर्स और एक स्वतंत्र मैनेजमेंट प्लेन में विभाजित करूंगा। रिक्वेस्ट्स में सब्जेक्ट, एक्शन, रिसोर्स और ट्रस्टेड कॉन्टेक्स्ट शामिल होते हैं। PDP टेनेंट-आइसोलेटेड RBAC, रिलेशनशिप और एट्रिब्यूट पॉलिसियों का मूल्यांकन करता है और allow या deny, एक decisionid, और policyversion लौटाता है। पॉलिसी संपादन वैलिडेट और टेस्ट किए जाते हैं, इम्यूटेबल वर्ज़न बनते हैं, टेनेंट और रीजन द्वारा डिस्ट्रीब्यूट होते हैं, और रोलबैक का समर्थन करते हैं।

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

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

सामान्य गलतियां और सुधार

• केवल एक "ऑथराइजेशन माइक्रोसर्विस" बनाना: PEP, PDP, मैनेजमेंट और डिस्ट्रीब्यूशन पाथ्स जोड़ें।
• केवल RBAC का उल्लेख करना: बताएं कि एट्रिब्यूट्स और रिलेशनशिप्स निर्णय में कैसे प्रवेश करते हैं।
• केवल यूज़र द्वारा कैश करना: टेनेंट, रिसोर्स, एक्शन और पॉलिसी वर्ज़न शामिल करें।
• टाइमआउट पर अनुमति देना: सेंसिटिव ऑपरेशन्स फेल क्लोज़ होते हैं और लो-रिस्क कैश का उपयोग स्पष्ट होता है।
• पूरी रिक्वेस्ट को लॉग करना: एक ट्रेसेबल decision_id और वर्ज़न बनाए रखते हुए इनपुट को रिडैक्ट करें।

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

एक रिवोकेशन कितनी जल्दी प्रभावी होना चाहिए?

जोखिम के आधार पर रिवोकेशन्स को वर्गीकृत करें। एडमिनिस्ट्रेटर, एक्सपोर्ट और सेंसिटिव-डेटा एक्शन्स के लिए, एक फ्रेश पॉलिसी वर्ज़न या एक शॉर्ट बाउंडेड प्रोपेगेशन विंडो की आवश्यकता होती है; कम जोखिम वाले रीड्स एक मापे गए TTL का उपयोग कर सकते हैं। टारगेट बताएं और इसे मॉनिटर करें।

क्या PDP को स्थानीय रूप से या एक शेयर्ड सर्विस के रूप में चलना चाहिए?

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

आप एक टेनेंट को दूसरे टेनेंट की पॉलिसी पढ़ने से कैसे रोकते हैं?

ऑथेंटिकेटेड रिक्वेस्ट में टेनेंट आइडेंटिटी रखें, इसे स्टोरेज और कैश कीज़ में लागू करें, और रिलीज़ गेट के रूप में क्रॉस-टेनेंट क्वेरीज़ का परीक्षण करें। कॉलर पेलोड द्वारा प्रदान किए गए टेनेंट आइडेंटिफ़ायर पर कभी भी भरोसा न करें।

आप एक अनपेक्षित डिनाई को कैसे डीबग करते हैं?

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