सामान्य साक्षात्कार: आप Policy as Code, PDP, और PEP को कैसे समझाते हैं?

प्रश्न और उपयुक्त परिदृश्य

एक प्लेटफ़ॉर्म टीम चाहती है कि “डेटाबेस सार्वजनिक नहीं हो सकते,” “केवल हस्ताक्षरित (signed) इमेज ही चल सकती हैं,” और “एक रोल केवल अपने टेनेंट को पढ़ सकता है” जैसे नियम परीक्षण योग्य, समीक्षा योग्य और स्वचालित रूप से लागू करने योग्य बनें। साक्षात्कारकर्ता आपसे Policy as Code को समझाने और पॉलिसी निर्णयों तथा व्यावसायिक निष्पादन (business execution) के बीच सीमा तय करने के लिए कहता है।

मान लें कि अनुरोध किसी API, CI/CD, या इंफ्रास्ट्रक्चर परिवर्तन से आते हैं; पॉलिसी इनपुट संरचित JSON है; और पॉलिसियों के लिए वर्ज़निंग, रोलबैक, और ऑडिटेबिलिटी आवश्यक है। यह प्रश्न OPA, Rego, या किसी एक वेंडर के प्रति प्रतिबद्धता के बारे में नहीं, बल्कि सीमाओं और तार्किक दृष्टिकोण के बारे में है।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

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

एक कमज़ोर उत्तर कहता है "ऑथराइजेशन के लिए OPA का उपयोग करें।" एक मजबूत उत्तर अनुरोध सीमा पर एक Policy Enforcement Point रखता है, Policy Decision Point को केवल गणना पर केंद्रित रखता है, और प्रत्येक निर्णय को व्याख्या योग्य, पुनरावृत्ति योग्य (replayable), और ट्रेस करने योग्य बनाता है।

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

क्या निर्णय रनटाइम एक्सेस के लिए है या डिप्लॉयमेंट से पहले के अनुपालन के लिए? रनटाइम निर्णय लेटेंसी और उपलब्धता पर ज़ोर देते हैं; डिप्लॉयमेंट जांच फ़ीडबैक और ब्लॉकिंग पर ज़ोर देती है।
पहचान (identity), टेनेंट, रिसोर्स लेबल और परिवेश की स्थिति कौन प्रदान करता है, और क्या उन फ़ील्ड पर भरोसा किया जा सकता है? छूटे हुए इनपुट को चुपचाप allow में नहीं बदला जाना चाहिए।
विफलता पर, क्या सिस्टम को डिफ़ॉल्ट रूप से deny करना चाहिए, allow में डिग्रेड होना चाहिए, या मानवीय मंज़ूरी का अनुरोध करना चाहिए? उत्तर कार्रवाई के प्रभाव और उपलब्धता के लक्ष्यों पर निर्भर करता है।
क्या पॉलिसी का प्रकाशन एप्लिकेशन रिलीज़ से स्वतंत्र हो सकता है? स्वतंत्र रिलीज़ के लिए वर्ज़न बाइंडिंग, कम्पैटिबिलिटी जांच और तेज़ रोलबैक की आवश्यकता होती है।
एक ऑडिट रिकॉर्ड में क्या होना चाहिए? यदि इनपुट में व्यक्तिगत या गोपनीय डेटा शामिल है, तो स्टोरेज या अपलोड से पहले लॉग्स से संवेदनशील डेटा को हटाना (redaction) आवश्यक है।

30-सेकंड उत्तर फ्रेमवर्क

"Policy as Code निष्पादन योग्य नियमों को वर्ज़न कंट्रोल, समीक्षा और परीक्षण में रखता है। एक अनुरोध PEP तक पहुंचता है, जो सब्जेक्ट, एक्शन, रिसोर्स और संदर्भ को एकत्र और सामान्यीकृत (normalize) करता है, फिर सामान्यीकृत इनपुट और पॉलिसी वर्ज़न के साथ PDP को कॉल करता है। PDP एक संरचित निर्णय लौटाता है जैसे allow, deny, कारण और दायित्व (obligations); PEP वास्तव में कार्रवाई को रोकता है या जारी रखता है। मैं डिफ़ॉल्ट deny, सीमित व वर्जन्ड कैशिंग, और रेडैक्टेड निर्णय लॉग का उपयोग करूँगा। रिलीज़ से पहले मैं रीप्ले और कैनरी जांच चलाऊंगा, और आपातकालीन अपवादों को समयबद्ध, अनुमोदित और ऑडिट योग्य बनाऊंगा।"

चरण-दर-चरण विस्तृत उत्तर

1. पॉलिसी ऑब्जेक्ट और सीमा को परिभाषित करें

प्राकृतिक भाषा के नियम को सब्जेक्ट, एक्शन, रिसोर्स, शर्तों और परिणाम में अनुवादित करें। "एक सेवा को एक अनएन्क्रिप्टेड सार्वजनिक पोर्ट उजागर नहीं करना चाहिए" का अर्थ हो सकता है: सब्जेक्ट एक डिप्लॉयमेंट पाइपलाइन है, एक्शन सेवा बनाना है, रिसोर्स सेवा कॉन्फ़िगरेशन है, शर्तें पोर्ट और नेटवर्क विशेषताएँ हैं, और परिणाम सुधार संदेश के साथ deny है।

PDP सामान्यीकृत इनपुट और पॉलिसी को पढ़ता है और allow, deny, warn, या अधिक समृद्ध संरचित डेटा लौटाता है। PEP एक API, एडमिशन कंट्रोलर, CI जॉब, या सर्विस-कॉल सीमा पर बैठता है और परिणाम को ब्लॉक, जारी रखने, म्यूटेट करने या मानवीय एस्केलेशन में बदल देता है।

text

caller -> PEP: subject, action, resource, context
PEP -> PDP: normalized input + policy version
PDP -> PEP: decision, reasons, obligations, decision_id
PEP -> target: enforce decision or stop request
PEP -> audit: redacted decision record

OPA का दस्तावेज़ीकरण निर्णय लेने को प्रवर्तन से स्पष्ट रूप से अलग करता है, और AWS मार्गदर्शन API पर PEP के साथ PDP का वर्णन करता है। वह सीमा एक नियम सेट को कई प्रवेश बिंदुओं की सेवा करने की अनुमति देती है बिना यह दिखावा किए कि पॉलिसी इंजन व्यावसायिक लेनदेन करता है।

2. इनपुट को सामान्यीकृत करें और छूटे हुए फ़ील्ड को संभालें

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

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

json

{
  "subject": {"id": "u-17", "tenant": "t-3", "roles": ["reader"]},
  "action": "read",
  "resource": {"type": "invoice", "id": "inv-9", "tenant": "t-3"},
  "context": {"environment": "prod", "authn_level": "mfa"},
  "policy_version": "2026-06-18.4"
}

3. पॉलिसी को परीक्षण योग्य सॉफ़्टवेयर के रूप में मानें

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

rego

package invoices

default allow := false

allow if {
  input.action == "read"
  input.subject.tenant == input.resource.tenant
  "reader" in input.subject.roles
}

परीक्षणों में पॉलिसी वर्ज़न और डेटा स्नैपशॉट को स्थिर करें। यदि कोई नियम किसी लाइव डायरेक्टरी या नेटवर्क कॉल पर निर्भर करता है, तो स्थानीय कैशिंग स्वीकार्य है या नहीं यह तय करने से पहले टाइमआउट और पुराना होने (staleness) की सीमाओं को परिभाषित करें।

4. प्रकाशन, कैशिंग और रोलबैक डिज़ाइन करें

पॉलिसी रिलीज़ के लिए सर्विस रिलीज़ की तरह ही वर्ज़न, कम्पैटिबिलिटी जांच और रोलबैक की आवश्यकता होती है। एक PDP स्थानीय साइडकार, एक लाइब्रेरी, या एक केंद्रीकृत सेवा के रूप में चल सकता है: स्थानीय निष्पादन नेटवर्क लेटेंसी को कम करता है, जबकि केंद्रीकरण प्रबंधन को सरल बनाता है। चुनाव अपडेट की गति, विफलता के दायरे (blast radius), और निरंतरता की आवश्यकताओं पर निर्भर करता है।

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

5. व्याख्या योग्य, रेडैक्टेड निर्णयों को रिकॉर्ड करें

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

एक allow दायित्वों (obligations) को भी साथ ले जा सकता है, जैसे कि ऑडिट इवेंट लिखना, फ़ील्ड को सीमित करना, या स्टेप-अप पुष्टि की आवश्यकता होना। PDP दायित्व लौटाता है; PEP इसे निष्पादित करता है और यदि ऐसा नहीं कर पाता है तो deny या एस्केलेट करता है।

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

मैं Policy as Code को सुरक्षा, अनुपालन और परिचालन संबंधी सीमाओं को वर्जन्ड, परीक्षण योग्य, मशीन-पठनीय नियमों के रूप में व्यक्त करने के रूप में परिभाषित करूँगा। एक अनुरोध PEP तक पहुँचता है, जो सब्जेक्ट को प्रमाणित करता है और पॉलिसी वर्ज़न के साथ PDP को भेजने से पहले सब्जेक्ट, एक्शन, रिसोर्स और संदर्भ को सामान्यीकृत करता है। PDP निर्णय की गणना करता है और allow, deny, कारण, दायित्व और एक निर्णय आईडी लौटाता है। PEP, न कि PDP, अनुरोध को रोकता है, व्यावसायिक कार्रवाई जारी रखता है, या मानवीय अनुमोदन शुरू करता है।

मैं पॉलिसी और इनपुट डेटा का वर्ज़न बनाऊंगा, Git में पॉलिसियों की समीक्षा करूँगा, और रीप्ले करने योग्य स्नैपशॉट के साथ उनका परीक्षण करूँगा। रनटाइम व्यवहार डिफ़ॉल्ट रूप से deny होता है, और कैश पॉलिसी व ऑथराइजेशन-डेटा वर्ज़न से बंधे होते हैं; निरस्तीकरण उच्च जोखिम वाले निर्णयों को तुरंत अमान्य कर देते हैं। एक PDP आउटेज को स्वचालित रूप से allow नहीं बनना चाहिए, इसलिए मैं कार्रवाई के जोखिम के आधार पर विफलता मोड का चयन करूँगा। अंत में, मैं ऑडिट और रोलबैक के लिए रेडैक्टेड निर्णय लॉग लिखूंगा। इसके बाद वही नियम API, CI और इंफ्रास्ट्रक्चर प्रवेश बिंदुओं की सेवा कर सकते हैं जबकि प्रत्येक प्रवेश बिंदु प्रवर्तन की ज़िम्मेदारी बनाए रखता है।

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

गलती → PDP को डेटाबेस अपडेट करने या इंफ्रास्ट्रक्चर डिप्लॉय करने की अनुमति देना → यह क्यों विफल होता है → निर्णय और साइड इफेक्ट्स अविभाज्य हो जाते हैं और पुनः प्रयास या ऑडिट करना कठिन हो जाता है → सुधार → PDP से केवल निर्णय और दायित्व लौटाएं; PEP या व्यावसायिक सेवा को प्रभाव निष्पादित करने दें।
गलती → PDP टाइमआउट होने पर डिफ़ॉल्ट रूप से allow करना → यह क्यों विफल होता है → नेटवर्क की खराबी अनुमति को बायपास करने का कारण बन जाती है → सुधार → कार्रवाई के जोखिम के आधार पर deny, अनुमोदन या एक छोटा पूर्व-अनुमोदित पथ चुनें।
गलती → केवल allow या deny लॉग करना → यह क्यों विफल होता है → कोई यह नहीं बता सकता कि किस नियम और इनपुट ने परिणाम उत्पन्न किया → सुधार → पॉलिसी वर्ज़न, कारण, निर्णय आईडी और एक रेडैक्टेड इनपुट सारांश रिकॉर्ड करें।
गलती → पॉलिसी कैश को स्थायी सत्य मानना → यह क्यों विफल होता है → निरस्तीकरण और टेनेंट परिवर्तन तुरंत प्रभावी नहीं हो सकते → सुधार → वर्ज़न और समाप्ति समय को बांधें, और महत्वपूर्ण घटनाओं पर अमान्य करें।

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

यदि केंद्रीकृत PDP अनुपलब्ध है, तो क्या प्रत्येक रीड विफल होनी चाहिए?

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

क्या होगा यदि पॉलिसी और पहचान डायरेक्टरी एक ही समय में अपडेट हों?

निर्णय में पॉलिसी और पहचान-डेटा वर्ज़न शामिल करें, और PEP से प्रवर्तन से पहले वर्ज़न या लीज़ की जांच करवाएं। निरस्तीकरण की घटनाएं कैश को अमान्य कर देती हैं; यदि वर्ज़न की पुष्टि नहीं की जा सकती है, तो deny करें या पुनर्मूल्यांकन करें। समवर्ती अपडेट और विलंबित संदेशों का परीक्षण करें ताकि कोई पुराना निर्णय वापस न लिखा जा सके।

यदि एक नियम अनुमति देता है और दूसरा अस्वीकार करता है, तो कौन जीतेगा?

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

आप ऑडिटेबिलिटी को नष्ट किए बिना आपातकालीन अनुमति का समर्थन कैसे करते हैं?

इसे अनुमोदक, कार्यक्षेत्र (scope), कारण, प्रारंभ समय और समाप्ति के साथ एक अस्थायी पॉलिसी या दायित्व के रूप में मॉडल करें। PEP प्रत्येक उपयोग को रिकॉर्ड करता है, स्वचालित समाप्ति इसे रद्द कर देती है, और रीप्ले अपवाद को सामान्य नियमों से अलग करता है। डेटाबेस को मैन्युअल रूप से संपादित करके पॉलिसी वर्ज़न को कभी भी बायपास न करें।