4.7 पहचान और पहुँच प्रबंधन

अवलोकन और प्रेरणा

आपके सिस्टम पर आने वाला हर अनुरोध एक अंतर्निहित दावा लेकर आता है: मुझे यह करने की अनुमति है। पहचान और पहुँच प्रबंधन (identity and access management, IAM) यह तय करने का अनुशासन है कि वह दावा सच है या नहीं। यह दो अलग-अलग प्रश्नों का उत्तर देता है जिन्हें लोग लगातार गड्डमड्ड कर देते हैं। ऑथेंटिकेशन यह साबित करता है कि आप कौन हैं। ऑथराइज़ेशन यह तय करता है कि इसे साबित करने के बाद आप क्या कर सकते हैं। इन दोनों विचारों को अपने दिमाग में अलग रखें और इस क्षेत्र का आधा भ्रम समाप्त हो जाता है।

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

एंटरप्राइज़ और सरकारी सेटिंग्स में दांव बढ़ जाते हैं। एक वैश्विक एंटरप्राइज़ दर्जनों ओवरलैपिंग डायरेक्टरियों, हर महीने हज़ारों जॉइनर्स और लीवर्स, और ऐसे पार्टनर्स को संभालता है जिन्हें आपके सिस्टम के एक हिस्से तक सीमित पहुँच चाहिए। एक सरकारी एजेंसी इसके ऊपर स्मार्ट-कार्ड क्रेडेंशियल, अनिवार्य पहचान आश्वासन स्तर, और ऑडिटर्स जोड़ती है जो लिखित में यह पूछेंगे कि किसी दिए गए दिन किसी दिए गए रिकॉर्ड को ठीक-ठीक कौन छू सकता था। यह अध्याय इस बारे में स्पष्ट राय रखता है कि पहचान की एक ऐसी परत कैसे बनाई जाए जो आपके लोगों को रोके बिना इन प्रश्नों का अच्छी तरह उत्तर दे।

मुख्य सिद्धांत

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

सिफ़ारिशें

ऑथेंटिकेशन को ऑथराइज़ेशन से अलग करें, और दोनों को केंद्रीकृत करें

एक आइडेंटिटी प्रोवाइडर (IdP) के माध्यम से ऑथेंटिकेट करें, यह एक ऐसा सिस्टम है जो पहचान सत्यापित करता है और टोकन जारी करता है जिन पर अन्य सिस्टम भरोसा करते हैं। फिर हर एप्लिकेशन को उस टोकन में मौजूद पहचान और एट्रिब्यूट से अपने स्वयं के ऑथराइज़ेशन निर्णय लेने दें। यह विभाजन आपको ऑथेंटिकेशन को एक बार, सबके लिए मज़बूत बनाने देता है, जबकि सूक्ष्म-दानेदार अनुमति तर्क को उस डेटा के करीब रखता है जिसकी वह रक्षा करता है। सिंगल साइन-ऑन (SSO) अपनाएँ, जहाँ एक ऑथेंटिकेशन कई एप्लिकेशनों तक पहुँच देता है, ताकि आपके लोगों के पास चालीस कमज़ोर लॉगिन की बजाय एक मज़बूत लॉगिन हो। फ़ेडरेशन उसी भरोसे को संगठनात्मक सीमाओं के पार बढ़ाता है, जिससे किसी पार्टनर की पहचान आपके पासवर्ड प्रबंधित किए बिना आपके सिस्टम तक पहुँच सके।

आधुनिक प्रोटोकॉल का उपयोग उसी के लिए करें जिसके लिए वे वास्तव में बने हैं

तीन मानक अधिकांश काम करते हैं, और हर एक का एक काम है। OpenID Connect (OIDC) OAuth 2.0 पर निर्मित एक पहचान परत है; इसे वेब और मोबाइल साइन-इन के लिए यह उपयोगकर्ता कौन है का उत्तर देने के लिए उपयोग करें। OAuth 2.0 प्रत्यायोजित पहुँच के लिए एक ऑथराइज़ेशन फ़्रेमवर्क है; इसका उपयोग किसी एप्लिकेशन को किसी उपयोगकर्ता की ओर से API कॉल करने देने के लिए करें, बिना उनका पासवर्ड कभी देखे (अध्याय 2.3)। Security Assertion Markup Language (SAML) पुराना XML-आधारित फ़ेडरेशन मानक है; यह स्थापित बिज़नेस एप्लिकेशनों में एंटरप्राइज़ SSO के लिए कार्यभार बना हुआ है। एक आम गलती है ऑथेंटिकेशन सीधे करने के लिए OAuth का सहारा लेना। OAuth संसाधनों तक पहुँच देता है; OIDC पहचान स्थापित करने के लिए इसके ऊपर बैठता है। नए उपयोगकर्ता-सामने वाले साइन-इन के लिए OIDC चुनें, जहाँ आपकी एंटरप्राइज़ कैटलॉग की माँग हो वहाँ SAML रखें, और अपना खुद का टोकन प्रारूप न बनाएँ।

ऑथेंटिकेशन को फ़िशिंग-प्रतिरोधी बनाएँ

केवल पासवर्ड स्केल पर अरक्षणीय हैं। बिना किसी अपवाद के हर मानव अकाउंट के लिए मल्टी-फ़ैक्टर ऑथेंटिकेशन (MFA) अपेक्षित करें, जो कुछ जो आप जानते हैं, कुछ जो आपके पास है, और कुछ जो आप हैं, को जोड़ता है। फिर कमज़ोर कारकों से आगे बढ़ें: SMS के ज़रिए वन-टाइम कोड फ़िशेबल और SIM-स्वैपेबल हैं। मज़बूत मंज़िल है पासकी और अंतर्निहित WebAuthn मानक (सार्वजनिक-कुंजी ऑथेंटिकेशन के लिए एक ब्राउज़र API), जो लॉगिन को एक हार्डवेयर-धारित निजी कुंजी और वास्तविक साइट के ऑरिजिन से बाँधती है, ताकि एक नकली पेज ऐसा कुछ न ले सके जिसकी चोरी करने लायक हो। पासकी पासवर्ड-रहित भी हैं, जिसके लिए आपके उपयोगकर्ता आपको धन्यवाद देंगे। अकाउंट रिकवरी और पासवर्ड रीसेट को ऑथेंटिकेशन सतह का हिस्सा मानें, क्योंकि जो हमलावर आपके MFA को नहीं हरा सकता वह इसके बजाय बस रीसेट फ़्लो पर हमला कर देगा।

जॉइनर-मूवर-लीवर जीवनचक्र प्रबंधित करें, और तेज़ी से डीप्रोविज़न करें

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

एक ऑथराइज़ेशन मॉडल चुनें और इसे पॉलिसी-एज़-कोड के रूप में व्यक्त करें

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

जस्ट-इन-टाइम पहुँच और PAM से न्यूनतम विशेषाधिकार लागू करें

न्यूनतम विशेषाधिकार के सिद्धांत को लागू करें: हर पहचान को उतनी न्यूनतम पहुँच मिलती है जितनी उसे चाहिए और उससे अधिक नहीं। स्थायी विशेषाधिकार दुश्मन है, क्योंकि स्थायी रूप से दी गई अनुमति किसी भी हमलावर के लिए उपलब्ध अनुमति है जो उस अकाउंट पर कभी भी उतर जाए। जस्ट-इन-टाइम (JIT) पहुँच को प्राथमिकता दें, जहाँ कोई व्यक्ति एक सीमित विंडो के लिए उन्नत अधिकार माँगता है, स्वीकृति के बाद उन्हें पाता है, और विंडो बंद होने पर उन्हें स्वतः खो देता है। अपने सबसे खतरनाक अकाउंट के लिए, प्रिविलेज्ड एक्सेस मैनेजमेंट (PAM) अपनाएँ: एक ऐसा सिस्टम जो प्रशासनिक क्रेडेंशियल को वॉल्ट करता है, विशेषाधिकार प्राप्त सत्रों को ब्रोकर और रिकॉर्ड करता है, और मांग पर उन्नयन जारी करता है। लक्ष्य है शून्य स्थायी एडमिन पहुँच, ताकि एक पूरी तरह से समझौता किया गया लैपटॉप भी कुछ भी टिकाऊ न दे।

मशीनों और वर्कलोड को वास्तविक पहचान दें

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

पहचान को कंट्रोल प्लेन बनाएँ, और पहुँच की निरंतर समीक्षा करें

ज़ीरो ट्रस्ट आर्किटेक्चर (अध्याय 4.1) में, पहचान वह जगह है जहाँ नीति तय और लागू की जाती है, इसलिए वहाँ तदनुसार निवेश करें। फिर एक्सेस रिव्यू के साथ लूप को बंद करें, जिसे रीसर्टिफ़िकेशन भी कहा जाता है: एक समय-सारिणी पर, हर सिस्टम का स्वामी पुष्टि करता है कि पहुँच रखने वाले हर व्यक्ति और मशीन को अभी भी इसकी आवश्यकता है, और जो वे उचित नहीं ठहरा सकते उसे निरस्त कर देता है। हर ऑथेंटिकेशन और ऑथराइज़ेशन घटना को एक ऑडिट ट्रेल में फ़ीड करें जो किसने क्या, कब, और किस नीति के तहत पहुँचा का उत्तर देता है (अध्याय 4.6)। एक्सेस रिव्यू वह तरीका है जिससे आप विशेषाधिकार रेंगन (privilege creep) से लड़ते हैं, अनुमतियों का धीमा संचय जिसमें कोई एक अनुदान कभी अनुचित नहीं लगा लेकिन जो मिलकर किसी अकाउंट को बहुत अधिक शक्तिशाली बना देते हैं।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

निर्णय	फ़ायदे	नुकसान
SSO के साथ केंद्रीकृत IdP	एक मज़बूत लॉगिन, संगत नीति, आसान ऑडिट	एकल विफलता बिंदु; आउटेज सबको बाहर कर देता है
RBAC	सरल, ऑडिट करने योग्य, परिचित	रोल विस्फोट; संदर्भ-संवेदनशील आवश्यकताओं के लिए मोटा
ABAC	सूक्ष्म-दानेदार, संदर्भ-जागरूक, एट्रिब्यूट के साथ स्केल होता है	डिज़ाइन, टेस्ट, और तर्क करना कठिन
पासकी / WebAuthn	फ़िशिंग-प्रतिरोधी, पासवर्ड-रहित, मज़बूत	रिकवरी और डिवाइस-हानि फ़्लो को सावधान डिज़ाइन चाहिए
जस्ट-इन-टाइम पहुँच	लगभग-शून्य स्थायी विशेषाधिकार	घर्षण; तेज़, विश्वसनीय स्वीकृति पथ चाहिए
पार्टनर्स के साथ फ़ेडरेशन	कोई बाहरी पासवर्ड प्रबंधन नहीं; सीमित भरोसा	भरोसा पार्टनर की अपनी स्वच्छता पर निर्भर करता है
दीर्घजीवी सर्विस कुंजियाँ	सेट अप करना तुच्छ रूप से आसान	लीक-प्रवण; क्रेडेंशियल ब्रीच का शीर्ष कारण

केंद्रीय तनाव सुरक्षा बनाम घर्षण है। हर नियंत्रण जो हमला सतह को सिकोड़ता है (हर चीज़ पर MFA, JIT उन्नयन, छोटी क्रेडेंशियल आयु) किसी के दिन में एक कदम भी जोड़ता है, और लोग उन नियंत्रणों के आसपास से रास्ता बना लेते हैं जो बहुत अधिक तकलीफ़ देते हैं। इसे सुरक्षित रास्ते को आसान रास्ता बनाकर हल करें: SSO ताकि मज़बूत ऑथेंटिकेशन एक टैप हो, पासकी ताकि टाइप करने के लिए कोई पासवर्ड न हो, और स्वचालित प्रोविज़निंग ताकि सही पहुँच बस दिखाई दे। अपना घर्षण बजट वहाँ खर्च करें जहाँ ब्लास्ट रेडियस सबसे बड़ा है, विशेषाधिकार प्राप्त और प्रोडक्शन पहुँच पर, और रोज़मर्रा की पहुँच को लगभग घर्षण-रहित रखें।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आज छोड़ने वाले किसी व्यक्ति के लिए आप वास्तव में कितनी तेज़ी से सारी पहुँच निरस्त कर सकते हैं, और आपको कैसे पता चलता है कि यह काम कर गया? डीप्रोविज़निंग गति आपकी पहचान परिपक्वता का सीधा माप है, क्योंकि एक लीवर जिसकी पहुँच बनी रहती है वह वास्तविक अनुमतियों वाला एक अनिगरानी अकाउंट है। दर्जनों असंबद्ध सिस्टम वाले एक बड़े संगठन में, ईमानदार जवाब अक्सर “हमें पक्का नहीं है” होता है, और अंतर आमतौर पर वे एप्लिकेशन होते हैं जो कभी केंद्रीय आइडेंटिटी प्रोवाइडर में नहीं जोड़े गए। एक हालिया वास्तविक प्रस्थान लाएँ और हर उस सिस्टम का पता लगाएँ जिसे वे छू सकते थे, यह जाँचते हुए कि प्रत्येक पहुँच वास्तव में कब समाप्त हुई। एक लक्ष्य तय करें, जैसे मानव-संसाधन स्थिति परिवर्तन के एक घंटे के भीतर पूर्ण निरस्तीकरण, और इसे इंस्ट्रूमेंट करें ताकि आप उम्मीद करने के बजाय इसे साबित कर सकें। यदि कोई सिस्टम किसी के एक मैनुअल कदम याद रखने पर निर्भर करता है, तो वही अकाउंट है जिसका भविष्य में कोई ब्रीच उपयोग करेगा।

2. आपके पास अभी भी कहाँ-कहाँ स्थायी विशेषाधिकार प्राप्त पहुँच और दीर्घजीवी स्थिर क्रेडेंशियल मौजूद हैं, और उन्हें समाप्त करने में क्या लगेगा? स्थायी एडमिन अधिकार और स्थायी सर्विस कुंजियाँ वे दो संपत्तियाँ हैं जिन्हें हमलावर सबसे ज़्यादा चाहते हैं, क्योंकि वे टिकाऊ और शक्तिशाली हैं। हमेशा-चालू प्रोडक्शन या प्रशासनिक पहुँच वाले हर इंसान और स्थिर कुंजी से ऑथेंटिकेट करने वाली हर सेवा की सूची बनाएँ, फिर ईमानदारी से पूछें कि इनमें से कौन जस्ट-इन-टाइम उन्नयन या अल्पजीवी वर्कलोड पहचान पर जा सकता है। प्रतिस्पर्धी विचार परिचालन भय है: टीमें स्थायी पहुँच बनाए रखती हैं क्योंकि ब्रेक-ग्लास पल इसके साथ अधिक सुरक्षित महसूस होते हैं, इसलिए स्थायी अधिकार हटाने से पहले आपको आपातकालीन उन्नयन को तेज़ और विश्वसनीय बनाना होगा। चर्चा में सूची लाएँ और वस्तुओं को ब्लास्ट रेडियस से रैंक करें, पहले प्रोडक्शन और प्रशासनिक पहुँच को लक्ष्य बनाते हुए। जिस अंतिम स्थिति का लक्ष्य रखना है वह है शून्य स्थायी एडमिन पहुँच और कोई ऐसी स्थिर कुंजी नहीं जो एक ही डिप्लॉय से आगे टिके।

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

4. क्या आपके सबसे मज़बूत ऑथेंटिकेशन कारक वास्तव में फ़िशिंग-प्रतिरोधी हैं, और आपको हमेशा के लिए पासवर्ड रिटायर करने से क्या रोक रहा है? वह कारक जिसे हमलावर फ़िश नहीं कर सकता, वही है जो क्रेडेंशियल चोरी को आपके प्रमुख ब्रीच पथ के रूप में समाप्त कर देता है, और WebAuthn से बंधी पासकी ही एकमात्र व्यापक रूप से तैनात करने योग्य विकल्प है जो उस मानदंड को पूरा करता है। एक बड़े संगठन में ईमानदार तस्वीर आमतौर पर मिश्रित होती है: कुछ के लिए पासकी, कुछ के लिए SMS पर वन-टाइम कोड, और लेगेसी एप्लिकेशनों की एक लंबी पूँछ जो अभी भी केवल पासवर्ड स्वीकार करती है। प्रतिस्पर्धी विचार वास्तविक है, क्योंकि पासकी कठिन समस्या को रिकवरी और डिवाइस हानि की ओर स्थानांतरित करती हैं, और एक अनाड़ी रिकवरी फ़्लो नया नरम लक्ष्य बन जाता है जिस पर एक हमलावर बस पिवट कर देता है। कारक प्रकार के अनुसार कवरेज संख्याएँ, उन एप्लिकेशनों की सूची जो अभी भी पासवर्ड पर वापस गिरते हैं, और एक डिज़ाइन किया गया अकाउंट-रिकवरी पथ लाएँ जिस पर आप किसी दृढ़ सोशल-इंजीनियरिंग प्रयास के विरुद्ध भरोसा करेंगे। एंटरप्राइज़ और सरकारी सेटिंग्स में, लक्ष्य को किसी भी अनिवार्य आश्वासन स्तर से जोड़ें, क्योंकि एक उच्च-आश्वासन सिस्टम जो अभी भी एक फ़िशेबल कारक की अनुमति देता है, उसमें सुरक्षा के साथ-साथ अनुपालन का भी अंतराल है।

5. आप यह कैसे तय करते हैं कि हर पहचान को कौन-सी पहुँच मिलती है, और क्या आप उस निर्णय को शिप होने से पहले डिफ़ करने, टेस्ट करने, और साबित करने में सक्षम हैं? “किसी ने कंसोल में अनुमतियाँ क्लिक कीं” और “एक समीक्षित, वर्ज़न-नियंत्रित नीति” के बीच का अंतर, एक ऐसे एक्सेस मॉडल के बीच का अंतर है जिसका आप ऑडिट कर सकते हैं और एक ऐसे मॉडल के बीच जिसके लिए आप केवल माफ़ी माँग सकते हैं। एक बड़ी टीम के लिए दबाव यह होता है कि हर एप्लिकेशन को अपने स्वयं के विशेष नियम बढ़ाने दिए जाएँ, जो चुपचाप RBAC पक्ष पर रोल विस्फोट और ABAC पक्ष पर बिना टेस्ट की शर्तें पैदा करता है, जब तक कोई यह नहीं बता सकता कि कोई दिया गया अनुदान वास्तव में क्या अनुमति देता है। प्रतिस्पर्धी विचार डिलीवरी गति है, क्योंकि ऑथराइज़ेशन को पॉलिसी-एज़-कोड के रूप में व्यक्त करना एक समीक्षा चरण जोड़ता है जो कंसोल क्लिक नहीं जोड़ता, और समय-सीमा के दबाव में टीमें इस घर्षण से तब तक नाराज़ रहती हैं जब तक पहली विफल ऑडिट या अत्यधिक-व्यापक अनुदान उनके लिए मामला नहीं बना देता। एक वास्तविक अनुमति परिवर्तन लाएँ और पता लगाएँ कि इसे कैसे प्रस्तावित, टेस्ट, समीक्षित, और रोलबैक किया जाएगा, साथ ही यह गिनती भी कि आपके पास कितने रोल हैं और कितनों को कोई समझा नहीं सकता। एंटरप्राइज़ और सरकारी सेटिंग्स में, एक ऑडिटर आपसे यह दिखाने के लिए कहेगा कि किसी दिए गए दिन किसी रिकॉर्ड तक ठीक-ठीक कौन पहुँच सकता था और किस नियम के तहत, और केवल एक डिफ़ करने योग्य, टेस्ट करने योग्य नीति ही बिना किसी हड़बड़ी के इसका उत्तर देती है।

6. आखिरी बार किसी एक्सेस रिव्यू ने वास्तव में कुछ कब निरस्त किया, और जब विशेषाधिकार रेंगन बेरोकटोक चलता है तो कौन जवाबदेह है? एक्सेस रिव्यू वह नियंत्रण है जो अनुमतियों के धीमे संचय से लड़ता है जिसमें कोई एक अनुदान कभी अनुचित नहीं लगा, और एक ऐसा रिव्यू जो कभी कुछ भी निरस्त नहीं करता वह सुरक्षा के बजाय कागज़ी कार्रवाई पैदा करने वाला रिव्यू-नाटक है। एक बड़े संगठन में विफलता विधा रबर स्टैंप है: सिस्टम स्वामी एक बैठक में सैकड़ों प्रविष्टियों को रीसर्टिफ़ाई करते हैं, उन सबको स्वीकृत करते हुए क्योंकि हर एक का वास्तव में मूल्यांकन करना थकाऊ है और पहुँच को बहता रखने की प्रेरणा इसे काटने की प्रेरणा से मज़बूत है। प्रतिस्पर्धी विचार यह है कि सार्थक रिव्यू स्वामी का समय लेते हैं और कभी-कभी किसी का वर्कफ़्लो तोड़ देते हैं जब वह पहुँच जिस पर वे चुपचाप निर्भर थे गायब हो जाती है, इसलिए आपको रिव्यू को एक अविभेदित सूची के बजाय लक्षित और जोखिम-संचालित बनाना होगा। अपने पिछले चक्र से निरस्तीकरण दर, प्रति व्यक्ति अधिकारों की औसत संख्या, और हर सिस्टम के रीसर्टिफ़िकेशन का स्वामी कौन है इसका प्रमाण लाएँ। एंटरप्राइज़ और सरकारी सेटिंग्स में, हर रिव्यू के लिए जवाबदेह अधिकारी और जिस समय-सारिणी के प्रति वे उत्तरदायी हैं उसे नाम दें, क्योंकि विशेषाधिकार रेंगन जिसे पकड़ने के लिए कोई ज़िम्मेदार नहीं है, वह ठीक वही स्थिति है जिसका ऑडिटर और हमलावर दोनों फ़ायदा उठाते हैं।

क्षेत्र लेंस

स्टार्टअप। पहचान खरीदें, इसे बनाएँ नहीं। SSO, अनिवार्य पासकी, और वन-क्लिक ऑफ़बोर्डिंग वाला एक एकल होस्टेड आइडेंटिटी प्रोवाइडर मुट्ठी भर इंजीनियरों को प्रति-सीट शुल्क के लिए एंटरप्राइज़-ग्रेड स्थिति देता है। प्रोवाइडर की अंतर्निहित वर्कलोड पहचान पर निर्भर रहें ताकि आपकी पाइपलाइन में एक भी दीर्घजीवी क्लाउड कुंजी न हो, और अपनी खुद की टोकन हैंडलिंग बनाने के बजाय OIDC और OAuth 2.0 का ऑफ़-द-शेल्फ़ उपयोग करें जिसे बनाए रखने का आप खर्च नहीं उठा सकते।

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

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

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही डिज़ाइन को चलाते हैं। ऑथेंटिकेशन को PIV या CAC स्मार्ट कार्ड जैसे हार्डवेयर क्रेडेंशियल से बाँधें, NIST SP 800-63 के अनुसार पहचान आश्वासन स्तर तय करें ताकि उच्च-जोखिम वाले सिस्टम उच्च-आश्वासन कारकों की माँग करें, और अपरिवर्तनीय ऑडिट लॉग रखें जो ठीक-ठीक बताते हैं कि किसने क्या और कब एक्सेस किया। नागरिक-सामने वाली पहचान की सादी-भाषा हैंडलिंग प्रकाशित करें, ग्राहक और कार्यबल पहचान स्टैक को अलग रखें, और सुनिश्चित करें कि किसी संवेदनशील सिस्टम पर हर विशेषाधिकार प्राप्त कार्रवाई ऑडिटर्स के लिए ब्रोकर और रिकॉर्ड की जाए जो पूछेंगे।

उदाहरण

स्टार्टअप। एक बीस-सदस्यीय स्टार्टअप एक पहचान टीम को स्टाफ़ नहीं दे सकता, इसलिए वह एक खरीद लेता है। हर कर्मचारी ईमेल, कोड होस्टिंग, क्लाउड कंसोल, और आंतरिक ऐप में SSO वाले एक एकल होस्टेड आइडेंटिटी प्रोवाइडर के माध्यम से साइन इन करता है, और पासकी अनिवार्य हैं ताकि फ़िश करने के लिए कोई पासवर्ड न हो। ऑफ़बोर्डिंग एक क्लिक की है: आइडेंटिटी प्रोवाइडर में व्यक्ति को अक्षम करने से हर जगह एक साथ पहुँच कट जाती है। अपने खुद के उत्पाद के लिए, वे उपयोगकर्ता साइन-इन के लिए OIDC और स्कोप्ड टोकन के साथ इंटीग्रेशन को उनके API को कॉल करने देने के लिए OAuth 2.0 का उपयोग करते हैं। सर्विस-टू-क्लाउड ऑथेंटिकेशन प्रोवाइडर की अंतर्निहित वर्कलोड पहचान का उपयोग करती है, इसलिए उनकी पाइपलाइन में कहीं भी एक भी दीर्घजीवी क्लाउड कुंजी नहीं है। इसकी लागत एक मामूली प्रति-सीट शुल्क है और यह उन्हें कई एंटरप्राइज़ से अधिक मज़बूत पहचान स्थिति देता है।

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

सरकार। एक संघीय एजेंसी अपने कार्यबल को पर्सनल आइडेंटिटी वेरिफ़िकेशन (PIV) स्मार्ट कार्ड, और सैन्य समकक्ष, कॉमन एक्सेस कार्ड (CAC), जारी करती है, ताकि ऑथेंटिकेशन पासवर्ड के बजाय एक हार्डवेयर क्रेडेंशियल से बंधा हो। इसका पहचान कार्यक्रम फ़ेडरल आइडेंटिटी, क्रेडेंशियल, एंड एक्सेस मैनेजमेंट (FICAM) दृष्टिकोण का पालन करता है और National Institute of Standards and Technology दिशानिर्देश NIST SP 800-63 के अनुसार पहचान आश्वासन स्तर तय करता है, ताकि उच्च-जोखिम वाले सिस्टम उच्च-आश्वासन क्रेडेंशियल की माँग करें। नागरिक-सामने वाली सेवाएँ मज़बूत MFA के साथ एक निचले आश्वासन स्तर पर एक अलग ग्राहक पहचान स्टैक का उपयोग करती हैं। एक्सेस रिव्यू और अपरिवर्तनीय ऑडिट लॉग सीधे एजेंसी के निरंतर प्राधिकरण साक्ष्य (अध्याय 4.6) में फ़ीड होते हैं, और किसी वर्गीकृत सिस्टम पर हर विशेषाधिकार प्राप्त कार्रवाई ब्रोकर और रिकॉर्ड की जाती है।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

पहचान निवेश पर रिटर्न आपके प्रमुख ब्रीच वेक्टर को खतरे के क्षेत्र से बाहर ले जाने से आता है। चुराए गए क्रेडेंशियल और अत्यधिक-अनुमति प्राप्त अकाउंट वास्तविक घटनाओं के एक बड़े हिस्से को चलाते हैं, और हर एक की एक भारी पूँछ होती है: घटना प्रतिक्रिया, नियामक जुर्माने, ब्रीच सूचना, और स्थायी प्रतिष्ठा क्षति। अकेले फ़िशिंग-प्रतिरोधी MFA सबसे सामान्य घुसपैठ पथ को खत्म कर देता है, और स्वचालित डीप्रोविज़निंग उस अनाथ-अकाउंट गैप को बंद कर देती है जो एक नियमित प्रस्थान को एक एक्सपोज़र में बदल देता है। ये खर्च किए गए प्रति डॉलर उपलब्ध सबसे सस्ती जोखिम कटौतियों में से हैं।

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

एंटी-पैटर्न और नुकसान

• अनाथ अकाउंट। ऐसी पहुँच जो व्यक्ति या उद्देश्य से आगे टिकी रहे, खासकर अनिगरानी सर्विस अकाउंट और भुला दिए गए ठेकेदार।
• हर जगह स्थायी एडमिन। जस्ट-इन-टाइम उन्नयन के बजाय हमेशा-चालू विशेषाधिकार प्राप्त पहुँच, जो किसी भी समझौता किए गए एडमिन अकाउंट को टिकाऊ शक्ति देती है।
• दीर्घजीवी स्थिर कुंजियाँ। कॉन्फ़िग या CI में चिपकाई गई सर्विस क्रेडेंशियल जो कभी समाप्त नहीं होतीं और अंततः लीक हो जाती हैं।
• डायरेक्टरी स्प्रॉल। वही व्यक्ति कई अशासित अकाउंट के रूप में, इसलिए कोई परिवर्तन कभी पूरी तरह से नहीं फैलता।
• साझा अकाउंट। कई लोगों द्वारा उपयोग किए जाने वाले क्रेडेंशियल, जो जवाबदेही को नष्ट करते हैं और निरस्तीकरण को असंभव बनाते हैं।
• आपके मज़बूत कारक के रूप में SMS। फ़िशेबल, SIM-स्वैपेबल वन-टाइम कोड को पर्याप्त MFA मानना।
• रोल विस्फोट। इतने सारे संकीर्ण RBAC रोल कि मॉडल गैर-ऑडिट करने योग्य हो जाता है और कोई नहीं जानता कि कोई रोल क्या अनुमति देता है।
• मैनुअल चेकलिस्ट के रूप में डीप्रोविज़निंग। मानव ऑफ़बोर्डिंग चरण जो अनिवार्य रूप से वह एक अकाउंट छोड़ देते हैं जो मायने रखता है।
• ऑथेंटिकेशन के लिए उपयोग किया गया OAuth। OIDC उपयोग करने के बजाय एक्सेस टोकन को पहचान के प्रमाण के रूप में मानना।
• रिव्यू-नाटक। बिना किसी के वास्तव में आवश्यकता का मूल्यांकन किए रबर-स्टैंप किए गए एक्सेस रीसर्टिफ़िकेशन।

परिपक्वता मॉडल

• स्तर 1, आरंभ करें (Initiate): हर एप्लिकेशन का अपना लॉगिन है। बिना किसी संगत MFA के पासवर्ड। प्रोविज़निंग और ऑफ़बोर्डिंग मैनुअल, प्रतिक्रियात्मक, और धीमी हैं; अनाथ अकाउंट जमा होते हैं। सर्विस क्रेडेंशियल दीर्घजीवी स्थिर कुंजियाँ हैं। कोई एक्सेस रिव्यू नहीं; अनुमतियाँ दी जाती हैं और कभी दोबारा नहीं देखी जातीं।
• स्तर 2, विकसित करें (Develop): SSO एक केंद्रीय आइडेंटिटी प्रोवाइडर के माध्यम से प्रमुख एप्लिकेशनों को कवर करता है, लेकिन कवरेज टीमों में असमान है। अधिकांश मानव पहुँच के लिए MFA अपेक्षित है। बुनियादी RBAC मौजूद है। जॉइनर-मूवर-लीवर मानव-संसाधन सिस्टम से आंशिक रूप से स्वचालित है। कुछ विशेषाधिकार प्राप्त अकाउंट वॉल्ट किए गए हैं। एक्सेस रिव्यू कभी-कभी और असंगत रूप से होते हैं।
• स्तर 3, मानकीकृत करें (Standardize): एक समेकित आइडेंटिटी प्रोवाइडर कार्यबल के लिए प्रामाणिक है, जिसमें स्वचालित प्रोविज़निंग और पूरे संगठन में लागू तुरंत डीप्रोविज़निंग है। फ़िशिंग-प्रतिरोधी MFA मानक है और दस्तावेज़ीकृत है। RBAC प्लस ABAC को पॉलिसी-एज़-कोड के रूप में व्यक्त किया जाता है। सत्र रिकॉर्डिंग के साथ प्रिविलेज्ड एक्सेस मैनेजमेंट मौजूद है। वर्कलोड पहचान अधिकांश स्थिर कुंजियों की जगह लेती है। शेड्यूल्ड एक्सेस रिव्यू लागू और उस लिखित नीति के विरुद्ध ऑडिट किए जाते हैं जिसका हर टीम पालन करती है।
• स्तर 4, प्रबंधित करें (Manage): पहचान कार्यक्रम को आधार रेखाओं के विरुद्ध मापा जाता है और डेटा से नियंत्रित किया जाता है। आप मानव-संसाधन स्थिति परिवर्तन से पूर्ण निरस्तीकरण तक डीप्रोविज़निंग समय, जनसमुदाय के अनुसार MFA और पासकी कवरेज, स्थायी विशेषाधिकार प्राप्त पहुँच वाले अकाउंट की गिनती, अभी भी उपयोग में दीर्घजीवी स्थिर कुंजियों की संख्या, अनाथ-अकाउंट गिनती, और एक्सेस-रिव्यू निरस्तीकरण दरों को ट्रैक करते हैं। मीट्रिक लक्ष्य रखते हैं, जैसे एक घंटे के भीतर पूर्ण निरस्तीकरण और शून्य शुद्ध नए स्थायी एडमिन अनुदान, और किसी सीमा का उल्लंघन कंधे उचकाने के बजाय जाँच को ट्रिगर करता है। ऑथराइज़ेशन परिवर्तन पाइपलाइन में टेस्ट किए जाते हैं और किसी एक्सेस अनुदान पर हर गो या नो-गो साक्ष्य द्वारा संचालित होता है, आदत द्वारा नहीं।
• स्तर 5, ऑर्केस्ट्रेट करें (Orchestrate): पहचान ज़ीरो ट्रस्ट के लिए निरंतर सुधारा गया कंट्रोल प्लेन है, जो पूरे संगठन में सुरक्षा, जोखिम, और जॉइनर-मूवर-लीवर योजना के साथ एकीकृत है। पासकी डिफ़ॉल्ट हैं और पासवर्ड रिटायर किए जा रहे हैं। जस्ट-इन-टाइम उन्नयन के माध्यम से शून्य स्थायी विशेषाधिकार प्राप्त किया जाता है, और सभी वर्कलोड अल्पजीवी, स्वचालित रूप से रोटेट होने वाले क्रेडेंशियल और mTLS का उपयोग करते हैं। ऑथराइज़ेशन पूरी तरह से पॉलिसी-एज़-कोड है। एक्सेस रिव्यू निरंतर और जोखिम-संचालित हैं, डीप्रोविज़निंग लगभग-तत्काल है, और हर निर्णय स्वचालित रूप से ऑडिट साक्ष्य पैदा करता है। जोखिम संकेतों के बदलने पर मॉडल अनुकूलित होता है, एक निश्चित समय-सारिणी के बजाय गतिशील रूप से पहुँच को कसता या ढीला करता है।

चर्चा के लिए विचार

1. शून्य स्थायी प्रशासनिक पहुँच तक पहुँचने में क्या लगेगा, और कौन-सा ब्रेक-ग्लास पथ इसे सुरक्षित बनाएगा?
2. आपके वातावरण में ABAC कहाँ अपनी जटिलता के लायक है बनाम साधारण RBAC के साथ बने रहना?
3. आपको पासकी के पक्ष में पासवर्ड को कितनी आक्रामकता से रिटायर करना चाहिए, और उनकी जगह कौन-सा रिकवरी फ़्लो लेगा?
4. कौन-से एप्लिकेशन अभी भी आपके केंद्रीय आइडेंटिटी प्रोवाइडर के बाहर हैं, और उन्हें वहाँ क्या रोके है?
5. आप पार्टनर्स और ग्राहकों को उनकी सुरक्षा स्वच्छता विरासत में लिए बिना सीमित पहुँच कैसे देते हैं?
6. कौन-सा एकल मीट्रिक आपकी डीप्रोविज़निंग गति को सबसे अच्छी तरह पकड़ता है, और क्या आप आज इसे माप रहे हैं?

मुख्य निष्कर्ष

• ऑथेंटिकेशन साबित करता है कि आप कौन हैं; ऑथराइज़ेशन तय करता है कि आप क्या कर सकते हैं। इन्हें अलग-अलग डिज़ाइन और समीक्षा करें।
• SSO के साथ एक प्रामाणिक आइडेंटिटी प्रोवाइडर में समेकित करें; डायरेक्टरी स्प्रॉल एक सुविधा नहीं, एक सुरक्षा दोष है।
• जॉइनर-मूवर-लीवर जीवनचक्र को स्वचालित करें और डीप्रोविज़निंग को तेज़ और साबित करने योग्य बनाएँ।
• उपयोगकर्ता साइन-इन के लिए OIDC, प्रत्यायोजित API पहुँच के लिए OAuth 2.0, और जहाँ एंटरप्राइज़ कैटलॉग को चाहिए वहाँ SAML का उपयोग करें; OAuth को ऑथेंटिकेशन के रूप में उपयोग न करें।
• ऑथेंटिकेशन को फ़िशिंग-प्रतिरोधी पासकी और WebAuthn की ओर ले जाएँ; हर जगह MFA अपेक्षित करें और कमज़ोर कारकों को अस्थायी समाधान मानें।
• जस्ट-इन-टाइम पहुँच और प्रिविलेज्ड एक्सेस मैनेजमेंट से न्यूनतम विशेषाधिकार लागू करें; शून्य स्थायी एडमिन अधिकारों का लक्ष्य रखें।
• मशीनों को अल्पजीवी वर्कलोड क्रेडेंशियल और mTLS के साथ वास्तविक पहचान दें; दीर्घजीवी स्थिर कुंजियों को समाप्त करें।
• पहचान को ज़ीरो ट्रस्ट के लिए कंट्रोल प्लेन बनाएँ (अध्याय 4.1), और निरंतर एक्सेस रिव्यू और ऑडिट साक्ष्य (अध्याय 4.6) के साथ लूप बंद करें।

संदर्भ और आगे पढ़ने के लिए

• National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
• National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
• National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
• The OAuth 2.0 Authorization Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
• OpenID Connect Core 1.0 specification, OpenID Foundation
• Security Assertion Markup Language (SAML) 2.0 specification, OASIS
• Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
• Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
• FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
• Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorization)