UK में, 98% संगठनों का कहना है कि वे zero trust को लागू करने की योजना बना रहे हैं या पहले ही लागू कर चुके हैं, फिर भी केवल 15% ही पूर्ण कार्यान्वयन की रिपोर्ट करते हैं। अंतर जागरूकता का नहीं है। यह निष्पादन का है। UK zero-trust शोध से पता चलता है कि कई टीमों ने उन नियंत्रणों को एक ऑपरेटिंग मॉडल में जोड़े बिना योजना बनाना, वर्गीकरण या पृथक पहचान परियोजनाएं शुरू कर दी हैं।
व्यावहारिक सवाल यह नहीं है कि ज़ीरो ट्रस्ट महत्वपूर्ण है या नहीं। सवाल यह है कि लाइव सेवाओं को बाधित किए बिना, उपयोगकर्ताओं को निराश किए बिना या असंबद्ध सुरक्षा उत्पादों का एक और संग्रह बनाए बिना ज़ीरो ट्रस्ट को कैसे लागू किया जाए। इसका उत्तर पहचान (identity), डिवाइस की स्थिति, डायरेक्टरी लाइफसाइकिल, सुरक्षित WiFi, सेगमेंटेशन और निरंतर सत्यापन के इर्द-गिर्द माइग्रेशन को व्यवस्थित करना है।
एंटरप्राइजेज में Zero Trust कार्यान्वयन क्यों रुक जाता है
51% संगठन अभी भी प्रारंभिक योजना के चरण में हैं, जबकि केवल 15% पूर्ण कार्यान्वयन का दावा करते हैं, और 80% को तकनीकी या परिचालन बाधाओं का सामना करना पड़ा है। यूके संगठनों की रिपोर्ट एक दिशा चुनने और आवश्यक नियंत्रणों को संचालित करने के बीच के अंतर को दर्शाती है। टीमें अक्सर अलग-थलग परियोजनाओं के साथ शुरुआत करती हैं, फिर पाती हैं कि पहचान, डिवाइस, डायरेक्टरी, एप्लिकेशन और नेटवर्क एक-दूसरे पर निर्भर हैं।
ज़ीरो ट्रस्ट सिस्टम, नेटवर्क और सेवाओं से अंतर्निहित विश्वास को हटा देता है। एक आंतरिक कनेक्शन को व्यापक पहुंच प्रदान नहीं करनी चाहिए। किसी व्यक्ति या आपूर्तिकर्ता को आवश्यकता समाप्त होने के बाद पुराने खाते की अनुमतियों को बरकरार नहीं रखना चाहिए। किसी सेवा पर अनिश्चित काल तक भरोसा नहीं किया जाना चाहिए क्योंकि उसने एक प्रमाणीकरण जांच पास कर ली है।
यूके नेशनल साइबर सिक्योरिटी सेंटर (NCSC) ज़ीरो ट्रस्ट को एक चरणबद्ध माइग्रेशन के रूप में परिभाषित करता है, न कि किसी प्रोडक्ट की खरीद के रूप में। इसका आर्किटेक्चर गाइडेंस आठ डिज़ाइन सिद्धांतों को परिभाषित करता है, जिसमें आइडेंटिटी-बेस्ड एक्सेस निर्णय और प्रोटेक्टेड कम्युनिकेशन्स शामिल हैं। NCSC ज़ीरो-ट्रस्ट कलेक्शन को 2021 में प्रकाशित किया गया था, जिसका इम्प्लीमेंटेशन गाइडेंस उस वर्ष सितंबर में विस्तारित किया गया था। NCSC आर्किटेक्चर डिज़ाइन सिद्धांत बेहद उपयोगी हैं क्योंकि वे टीमों को टेक्नोलॉजी चुनने से पहले आर्किटेक्चर और ट्रस्ट निर्णयों को तय करने के लिए प्रेरित करते हैं।
प्रोडक्ट-फर्स्ट विफलता मोड
विफलता का पैटर्न आमतौर पर प्लेटफ़ॉर्म की खरीदारी से शुरू होता है। एक टीम पहचान उत्पाद, सेगमेंटेशन टूल या ZTNA गेटवे तैनात करती है, और फिर पाती है कि सर्विस अकाउंट्स, बिना प्रबंधन वाले डिवाइसेस, लीगेसी एप्लिकेशन, वायरलेस प्रमाणीकरण और डायरेक्ट्री ऑफ़बोर्डिंग को कभी मैप ही नहीं किया गया था।
इसका परिणाम एक बढ़ती हुई अपवाद सूची (exception list) के रूप में होता है। यूज़र्स को वर्कअराउंड मिलते हैं, एडमिनिस्ट्रेटर शेयर्ड क्रेडेंशियल्स को सुरक्षित रखते हैं, और सिक्योरिटी टीमें यह नहीं बता पाती हैं कि पॉलिसी लगातार लागू की जा रही है या नहीं। WiFi इस कमज़ोरी को तुरंत उजागर कर देता है। नेटवर्क सेगमेंटेशन ट्रैफ़िक को अलग कर सकता है, लेकिन यदि यूज़र अभी भी शेयर्ड पासवर्ड के माध्यम से जुड़ते हैं या डिवाइस अज्ञात रहते हैं, तो यह आइडेंटिटी-बेस्ड एक्सेस नहीं बनाता है। सर्टिफिकेट-बेस्ड ऑथेंटिकेशन के साथ पासवर्डलेस WiFi, जो डिवाइस रिकॉर्ड और डायरेक्टरी स्टेटस से जुड़ा हो, पॉलिसी को एक विश्वसनीय आइडेंटिटी सिग्नल देता है। इसके बाद अकाउंट डिसेबल होने पर ऑटोमैटिक डायरेक्टरी रिवोकेशन द्वारा एक्सेस हटा दिया जाना चाहिए, न कि मैन्युअल क्लीनअप का इंतज़ार किया जाना चाहिए।
पारंपरिक पेरिमिटर नियंत्रणों की अभी भी एक भूमिका है, लेकिन वे हर पहुंच से जुड़े प्रश्न का उत्तर नहीं दे सकते। why traditional IT security fails बताता है कि कैसे क्लाउड सेवाएं, रिमोट एक्सेस और वितरित डिवाइस इस धारणा को कमजोर करते हैं कि एक आंतरिक नेटवर्क स्वचालित रूप से सुरक्षित है।
व्यावहारिक नियम: तब तक प्रवर्तन नीति न लिखें जब तक आप यह न जान लें कि वह नीति किस पहचान, डिवाइस, WiFi और सेवा निर्भरताओं को बाधित कर सकती है।
एक व्यावहारिक माइग्रेशन इस क्रम का पालन करता है:
- एस्टेट को डिस्कवर करें: यूज़र्स, डिवाइसेस, एप्लिकेशन्स, सर्विसेज़ और डेटा फ़्लो की पहचान करें।
- सीमाएं निर्धारित करें: तय करें कि किन रिसोर्सेज को आइसोलेशन की आवश्यकता है और कौन से एक्सेस पाथ वैध हैं।
- कंट्रोल प्लेन का निर्माण करें: आइडेंटिटी, MFA, सर्टिफिकेट-बेस्ड डिवाइस एक्सेस, पोश्चर चेक और डायरेक्टरी लाइफ़साइकिल को कनेक्ट करें।
- एज पर लागू करें: केवल VPN सेशन्स पर ही नहीं, बल्कि एप्लिकेशन्स, नेटवर्क्स और WiFi पर पॉलिसी लागू करें।
- ऑब्ज़र्व करें और विस्तार करें: कंट्रोल्ड वर्कलोड के साथ शुरुआत करें, एक्सेस निर्णयों की समीक्षा करें और धीरे-धीरे इस मॉडल का विस्तार करें।
यह अनुक्रम शून्य ट्रस्ट को केवल उपकरणों के संग्रह के बजाय एक ऑपरेटिंग मॉडल बनाता है। यह संचालन टीमों को उपलब्धता की सुरक्षा करने की अनुमति भी देता है, जबकि पहचान नियंत्रण, सुरक्षित WiFi और सेगमेंटेशन परिपक्व होते हैं।
डिस्कवरी और ट्रस्ट बाउंड्रीज के साथ आधार तैयार करना
एक ऐसी इन्वेंट्री के साथ शुरुआत करें जो यह दर्शाती हो कि संगठन कैसे काम करता है, न कि इस बात पर कि नेटवर्क आरेख क्या कहता है। NCSC उपयोगकर्ताओं, आवश्यक अनुमतियों, उपकरणों और सेवाओं की पहचान करने, फिर उन निष्कर्षों के आधार पर पहचान और पहुंच प्रबंधन को डिजाइन करने की सिफारिश करता है। NCSC माइग्रेशन गाइडेंस टीमों को रोलआउट से पहले लीगेसी निर्भरताओं को मैप करने और प्रस्तावित आर्किटेक्चर के थ्रेट-मॉडलिंग की ओर भी निर्देशित करता है।
आउटपुट एक सक्रिय कैटलॉग होना चाहिए, न कि एक स्थिर स्प्रेडशीट। प्रत्येक महत्वपूर्ण संसाधन के लिए स्वामी, व्यावसायिक उद्देश्य, प्रमाणीकरण विधि, निर्भरता, डेटा संवेदनशीलता, अपेक्षित उपयोगकर्ताओं और विफलता के प्रभाव को रिकॉर्ड करें।
चार इन्वेंटरी बनाएं
उपयोगकर्ता और पहचान सबसे पहले आते हैं। इसमें कर्मचारी, ठेकेदार, विशेषाधिकार प्राप्त एडमिनिस्ट्रेटर, सर्विस अकाउंट और ऑटोमेशन पहचान शामिल हैं। किसी व्यक्ति के रोजगार की स्थिति को उसकी पहुंच (access) की आवश्यकता से अलग रखें। एक ठेकेदार को एक निश्चित अवधि के लिए एक एप्लीकेशन तक पहुंच की आवश्यकता हो सकती है, जबकि एक सर्विस अकाउंट को मशीन ऑथेंटिकेशन की आवश्यकता हो सकती है लेकिन किसी इंटरैक्टिव लॉगिन की नहीं।
डिवाइस को अपने स्वयं के वर्गीकरण की आवश्यकता होती है। प्रबंधित लैपटॉप, मोबाइल डिवाइस, साझा टर्मिनल, प्रिंटर, कैमरे, बिल्डिंग सिस्टम और अन्य IoT उपकरणों को रिकॉर्ड करें। ध्यान दें कि कौन से डिवाइस प्रमाणपत्र, आधुनिक एन्क्रिप्शन और पोस्चर रिपोर्टिंग का समर्थन करते हैं। लीगेसी उपकरण अक्सर कर्मचारियों की प्रमाणीकरण आवश्यकताओं को पूरा नहीं कर सकते हैं, इसलिए इसे बिना ट्रैक किए गए अपवाद के बजाय एक स्पष्ट रोकथाम रणनीति की आवश्यकता होती है।
एप्लिकेशन्स और सेवाओं को उनकी पहचान और ट्रांसपोर्ट आवश्यकताओं के लिए मैप किया जाना चाहिए। दस्तावेज़ में लिखें कि क्या प्रत्येक एप्लिकेशन SSO, MFA, आधुनिक प्रोटोकॉल, सर्टिफिकेट, प्रॉक्सी एक्सेस या केवल एक लीगेसी उपयोगकर्ता नाम और पासवर्ड का समर्थन करता है। अपस्ट्रीम डायरेक्टरीज़, डेटाबेस, DNS सेवाओं, APIs और लॉगिंग निर्भरताओं की पहचान करें।
डेटा प्रवाह और व्यावसायिक यात्राएं विश्वास की सीमाओं को प्रकट करती हैं। यह मैप करें कि कोई स्टाफ सदस्य क्लिनिकल सिस्टम तक कैसे पहुंचता है, कोई ठेकेदार रखरखाव पोर्टल तक कैसे पहुंचता है, या पॉइंट-ऑफ-सेल डिवाइस स्वीकृत सेवाओं के साथ कैसे संचार करता है। एक सेगमेंट तब तक सार्थक नहीं है जब तक कि कोई बिना दस्तावेज़ वाली निर्भरता उस पर अप्रतिबंधित पहुंच को मजबूर न करे।
पॉलिसीज से पहले सीमाएं परिभाषित करें
एक ट्रस्ट बाउंड्री को तीन सवालों के जवाब देने चाहिए: किसकी सुरक्षा की जा रही है, किसे एक्सेस की आवश्यकता है, और किन परिस्थितियों में। परिस्थितियों में पहचान का आश्वासन, डिवाइस की स्थिति, नेटवर्क संदर्भ, एप्लिकेशन संवेदनशीलता और समय-सीमित स्वीकृति शामिल हो सकती है।
अतिथि WiFi, IoT और मल्टी-टेनेंट साइटों पर विशेष ध्यान देने की आवश्यकता है। अतिथियों को कभी भी कर्मचारियों के नेटवर्क क्रेडेंशियल पर निर्भर नहीं होना चाहिए। IoT उपकरणों को केवल उनके कार्य के लिए आवश्यक सेवाओं के साथ संचार करना चाहिए। टेनेंट तार्किक अलगाव और अलग पहचान प्रशासन को बनाए रखते हुए भौतिक बुनियादी ढांचे को साझा कर सकते हैं।
सुरक्षित ट्रांसपोर्ट हर सीमा पर महत्वपूर्ण है। यदि टीम को सर्टिफिकेट, एन्क्रिप्शन और ब्राउज़र ट्रस्ट पर सरल-भाषा में पुनश्चर्या की आवश्यकता है, तो Adwave Digital's guide to SSL एप्लिकेशन और WiFi ट्रांसपोर्ट मान्यताओं को दस्तावेज़ित करने से पहले एक उपयोगी संदर्भ है।
खोज प्रक्रिया को एक थ्रेट मॉडल के साथ समाप्त करें। परीक्षण करें कि क्या होता है यदि कोई डायरेक्टरी खाता हैक हो जाता है, कोई प्रबंधित डिवाइस अस्वस्थ हो जाता है, कोई सर्टिफिकेट निरस्त कर दिया जाता है, कोई वायरलेस कंट्रोलर अनुपलब्ध होता है या कोई लीगेसी सेवा नए पहचान प्रदाता के खिलाफ प्रमाणित नहीं हो पाती है। वे विफलता पथ रोलआउट क्रम को आकार देने वाले होने चाहिए।
अपनी पहचान और डिवाइस पोस्चर को अपने कंट्रोल प्लेन के रूप में बनाना
ज़ीरो ट्रस्ट निर्णयों के लिए सत्य के स्रोत (source of truth) की आवश्यकता होती है। अधिकांश संपत्तियों में, इसका अर्थ उस डायरेक्टरी का चयन करना है जो लोगों, समूहों और लाइफसाइकिल घटनाओं को नियंत्रित करती है, जैसे कि Microsoft Entra ID, Google Workspace या Okta। महत्वपूर्ण डिज़ाइन विकल्प केवल ब्रांड नहीं है। यह है कि क्या प्रत्येक एक्सेस सिस्टम एक ही पहचान स्थिति का उपभोग कर सकता है और उस स्थिति में बदलाव होने पर प्रतिक्रिया दे सकता है।
जो उपयोगकर्ता संगठन छोड़ देता है, उसकी पहुंच हर उस महत्वपूर्ण स्थान से समाप्त हो जानी चाहिए जहां आवश्यक हो। अनुबंध समाप्त होने वाले ठेकेदार को वायरलेस सिस्टम में सक्रिय नहीं रहना चाहिए क्योंकि कोई एडमिनिस्ट्रेटर एक अलग खाते को हटाना भूल गया था। ऑटोमैटिक प्रोविजनिंग और रिवोकेशन डायरेक्टरी परिवर्तनों को एडमिनिस्ट्रेटिव रिमाइंडर के बजाय ऑपरेशनल कंट्रोल बनाते हैं।
व्यक्ति और डिवाइस दोनों को प्रमाणित करें
वर्कफ़ोर्स एप्लिकेशन्स के लिए SSO और MFA के साथ शुरुआत करें। MFA आश्वासन को बढ़ाता है, जबकि SSO उन क्रेडेंशियल्स की संख्या को कम करता है जिन्हें उपयोगकर्ताओं और सर्विस डेस्क को प्रबंधित करना होता है। NCSC विशेष रूप से MFA के इर्द-गिर्द IAM को डिजाइन करने और जहां उपयुक्त हो वहां पासवर्ड रहित प्रमाणीकरण (passwordless authentication) पर विचार करने की सिफारिश करता है। पासवर्ड रहित तरीके सुरक्षा और उपयोगिता दोनों में सुधार कर सकते हैं, लेकिन उन्हें पुनर्प्राप्ति प्रक्रियाओं, डिवाइस नामांकन नियंत्रणों और उन उपयोगकर्ताओं के लिए सहायता की आवश्यकता होती है जो अपने प्राथमिक प्रमाणक तक पहुंच खो देते हैं।
कर्मचारियों के WiFi के लिए, प्रमाणपत्र-आधारित प्रमाणीकरण आमतौर पर साझा किए गए पासवर्ड की तुलना में परिचालन रूप से अधिक मजबूत होता है। WPA2 या WPA3-Enterprise और 802.1X के साथ, नेटवर्क किसी नामांकित पहचान या उपकरण प्रमाणपत्र के साथ एक्सेस को बाध्य कर सकता है। यह एक सामान्य कुंजी वितरित करने की आवश्यकता को समाप्त करता है और निरस्तीकरण को सटीक बनाता है।
उपकरण की स्थिति निर्णय का दूसरा भाग जोड़ती है। जांचें कि क्या उपकरण प्रबंधित, एन्क्रिप्टेड, पैच किया गया, अनुपालन करने वाला है और एक स्वीकृत प्रमाणपत्र का उपयोग कर रहा है। एक अप्रबंधित लैपटॉप पर एक मान्य उपयोगकर्ता को स्वचालित रूप से वही एक्सेस नहीं मिलना चाहिए जो उस उपयोगकर्ता को एक स्वस्थ कॉर्पोरेट उपकरण पर मिलता है।
पहचान यह साबित करती है कि एक्सेस का अनुरोध कौन कर रहा है। डिवाइस पोस्चर यह निर्धारित करता है कि क्या वह एक्सेस अनुरोध स्वीकृत करने के लिए पर्याप्त सुरक्षित है।
केवल लॉगिन ही नहीं, बल्कि लाइफसाइकल इवेंट्स को भी डिजाइन करें
ऑनबोर्डिंग को निर्देशिका पहचान बनानी चाहिए, सही समूह सौंपने चाहिए, उपकरण को नामांकित करना चाहिए और एक स्वचालित वर्कफ़्लो के माध्यम से आवश्यक प्रमाणपत्र जारी करना चाहिए। ऑफ़बोर्डिंग को किसी अलग WiFi व्यवस्थापक की प्रतीक्षा किए बिना पहचान को अक्षम करना चाहिए, सत्रों और प्रमाणपत्रों को रद्द करना चाहिए, और नेटवर्क एक्सेस को हटाना चाहिए।
ठेकेदारों को एक अलग पथ की आवश्यकता होती है। उन्हें सीमित दायरे वाली समूह सदस्यता, एक समाप्ति या अनुमोदन प्रक्रिया, और केवल उन एप्लिकेशन्स और नेटवर्क सेगमेंट तक पहुंच प्रदान करें जिनकी उनके काम के लिए आवश्यकता है। ठेकेदारों को एक व्यापक स्टाफ नेटवर्क पर रखकर उनकी सुविधा का समाधान न करें।
विरासत डिवाइसों को नियंत्रण में रखने की आवश्यकता होती है। जहाँ कोई प्रिंटर, सेंसर या विशेषज्ञ टर्मिनल प्रमाणपत्र-आधारित प्रमाणीकरण का उपयोग नहीं कर सकता है, वहाँ एक समर्पित सेगमेंट, कड़ाई से सीमित फ़ायरवॉल नियमों और व्यक्तिगत प्री-शेयर्ड की जैसे नियंत्रित पहचान तंत्र का उपयोग करें। इससे अपवाद दिखाई देता रहता है और इसका प्रभाव क्षेत्र सीमित रहता है।
पहचान-बद्ध नेटवर्क एक्सेस का मूल्यांकन करने वाली टीमें एक कार्यान्वयन पैटर्न के रूप में identity-based networking की समीक्षा कर सकती हैं। आर्किटेक्चरल सिद्धांत समान रहता है, चाहे कोई भी प्लेटफॉर्म हो: डायरेक्टरी स्थिति, ऑथेंटिकेशन की ताकत और डिवाइस की स्थिति को एक साथ एक्सेस के निर्णय को प्रभावित करना चाहिए।
सेगमेंटेशन और सुरक्षित WiFi जो पॉलिसी को लागू करता है
वर्गीकरण (Segmentation) आवश्यक है, लेकिन यह अपने आप में पहचान-आधारित पहुंच को लागू नहीं कर सकता है। सर्वेक्षण में शामिल 92% UK संगठनों का कहना है कि वे अपने नेटवर्क को कुछ हद तक वर्गीकृत करते हैं, जबकि 98% का कहना है कि वे zero trust को लागू करने की योजना बना रहे हैं या पहले ही लागू कर चुके हैं। UK के शोध से संकेत मिलता है कि नेटवर्क ज़ोनिंग व्यापक है, लेकिन पहचान आश्वासन, निरंतर सत्यापन और नीति प्रवर्तन पर अभी भी ध्यान देने की आवश्यकता है।
एक VLAN ट्रैफ़िक को अलग करता है। यह यह तय नहीं करता है कि किसी व्यक्ति, डिवाइस या सेशन को एक्सेस बनाए रखना चाहिए या नहीं। यदि कोई उपयोगकर्ता अनुपालन करने वाले लैपटॉप से किसी बिना प्रबंधन वाले डिवाइस पर जाता है, तो डिवाइस उसी सेगमेंट में रह सकता है जब तक कि एक्सेस सिस्टम पहचान और पोस्चर का दोबारा मूल्यांकन न करे।
परिपक्वता स्तरों की तुलना करें
| नियंत्रण क्षेत्र | आंशिक कार्यान्वयन | Zero Trust परिपक्वता |
|---|---|---|
| नेटवर्क डिज़ाइन | VLANs या व्यापक ज़ोन मेहमानों, कर्मचारियों और डिवाइसों को अलग करते हैं | बारीक नीतियां विशिष्ट संसाधनों और प्रवाहों तक पहुंच को प्रतिबंधित करती हैं |
| WiFi प्रमाणीकरण | साझा पासवर्ड, Captive Portal या स्थिर कुंजियाँ | WPA2 या WPA3-Enterprise, 802.1X और प्रमाणपत्र या पहचान-आधारित पहुंच |
| उपयोगकर्ता लाइफसाइकिल | प्रशासक मैन्युअल रूप से खाते बनाते और हटाते हैं | डायरेक्टरी परिवर्तन स्वचालित रूप से पहुंच को प्रोविज़न और निरस्त करते हैं |
| डिवाइस आश्वासन | यदि डिवाइस के पास सही नेटवर्क क्रेडेंशियल है तो वह कनेक्ट होता है | डिवाइस का स्वास्थ्य और प्रमाणपत्र की स्थिति हर पहुंच निर्णय को प्रभावित करती है |
| नीति प्रतिक्रिया | पहुंच तब तक सक्रिय रहती है जब तक कि सत्र या खाते को मैन्युअल रूप से नहीं बदला जाता | संदर्भ परिवर्तन पुनः मूल्यांकन, प्रतिबंध या निरसन को ट्रिगर करते हैं |
| दृश्यता | कंट्रोलर लॉग कनेक्शन इवेंट दिखाते हैं | समीक्षा के लिए पहचान, डिवाइस, नीति और संसाधन इवेंट सहसंबद्ध होते हैं |
WiFi को एक पहचान सीमा के रूप में मानें
WiFi अक्सर पहला एंटरप्राइज एक्सेस निर्णय होता है जिसका सामना किसी डिवाइस को करना पड़ता है। इसे प्रोग्राम में देर से लागू करने के लिए छोड़ने से डायरेक्टरी पॉलिसी और फिजिकल कनेक्टिविटी के बीच एक अंतर पैदा हो जाता है।
कर्मचारियों के लिए, 802.1X के साथ WPA2 या WPA3-Enterprise का उपयोग करें, जो प्रमाणपत्रों या अन्य मजबूत पहचान पद्धति द्वारा समर्थित हो। पासवर्ड रहित WiFi उपयोगकर्ता अनुभव से साझा रहस्यों को हटा देता है, जबकि प्रमाणपत्र-आधारित प्रमाणीकरण कनेक्टिविटी को एक नामांकित पहचान और डिवाइस से जोड़ता है। Passpoint और OpenRoaming बार-बार पासवर्ड दर्ज किए बिना एक नामांकित डिवाइस को प्रमाणित करने की अनुमति देकर सुरक्षित रोमिंग का समर्थन कर सकते हैं।
लक्ष्य पहले पैकेट से ही एन्क्रिप्टेड, पहचान-बद्ध कनेक्टिविटी प्रदान करना है। एक Captive Portal जो उपयोगकर्ता द्वारा शर्तों को स्वीकार करने के बाद व्यापक एक्सेस देता है, वह ऐसा नियंत्रण प्रदान नहीं करता है।
व्यवहारिक समीक्षा के लिए enterprise WiFi security, सर्टिफिकेट वितरण, पहचान प्रदाता एकीकरण, रिवोकेशन हैंडलिंग और कंट्रोलर अनुकूलता का आकलन करें। यह डिज़ाइन Meraki, Aruba, Ruckus, Mist या UniFi उपकरणों सहित पूरे एस्टेट में काम करना चाहिए।
अतिथियों के लिए एक अलग अनुभव और नीति की आवश्यकता होती है। कर्मचारियों के विशेषाधिकारों के बिना इंटरनेट एक्सेस प्रदान करें। IoT उपकरणों को प्रतिबंधित नीतियों की आवश्यकता होती है जो केवल संचालन के लिए आवश्यक गंतव्यों और सेवाओं की अनुमति देती हैं।
लगातार एक्सेस का पुनर्मूल्यांकन करें
NCSC स्पष्ट zero-trust आवश्यकताओं के रूप में निरंतर पुनर्मूल्यांकन, अवलोकन क्षमता और लचीलेपन पर प्रकाश डालता है। इसकी ZTNA कार्यान्वयन मार्गदर्शिका किसी सत्र की अवधि के लिए अनुमतियों को स्थिर रखने के बजाय संदर्भ बदलने पर पहुंच को बदलने का समर्थन करती है।
डायरेक्टरी एकीकरण को स्वचालित निरसन (automatic revocation) का समर्थन करना चाहिए। एक अक्षम अकाउंट, हटाई गई समूह सदस्यता या निरस्त किए गए सर्टिफिकेट को किसी अलग WiFi एडमिनिस्ट्रेटर के हस्तक्षेप की प्रतीक्षा किए बिना नीति अपडेट को ट्रिगर करना चाहिए। इसका परिणाम स्टेप-अप ऑथेंटिकेशन, सीमित नेटवर्क में ट्रांसफर, एप्लीकेशन ब्लॉकिंग या तत्काल एक्सेस निरसन हो सकता है।
सेगमेंटेशन घटना को सीमित करता है। आइडेंटिटी, डिवाइस पोश्चर और करंट टेलीमेट्री यह तय करते हैं कि एक्सेस जारी रहेगा या नहीं। यह कॉम्बिनेशन नेटवर्क सेपरेशन और वास्तविक आइडेंटिटी-बेस्ड कंट्रोल के बीच के अंतर को समाप्त करता है।
निगरानी शुरू करना और हर एक्सेस निर्णय को सत्यापित करना
एक सुरक्षित रोलआउट नियंत्रित, अवलोकन योग्य और प्रतिवर्ती होता है। प्रत्येक उपयोगकर्ता, साइट और उपकरण श्रेणी में एक नई नीति लागू करके शुरुआत न करें। एक कम जोखिम वाले समूह या स्थान का चयन करें जिसमें समस्याओं को उजागर करने के लिए अभी भी पर्याप्त वास्तविक जटिलता हो, फिर इसका विस्तार करने से पहले एक्सेस पथ को साबित करें।
जहाँ तकनीक इसका समर्थन करती है, वहां मॉनिटर मोड में शुरुआत करें। कैप्चर करें कि नीति क्या अनुमति देगी और क्या अस्वीकार करेगी, उन निर्णयों की व्यावसायिक आवश्यकताओं के साथ तुलना करें, और अज्ञात निर्भरताओं की जांच करें। मॉनिटर मोड प्रवर्तन का विकल्प नहीं है। यह प्रवर्तन द्वारा प्रोडक्शन को प्रभावित करने से पहले टालने योग्य आश्चर्यों को हटाने का एक तरीका है।
चरणबद्ध माइग्रेशन का उपयोग करें
एक व्यावहारिक अनुक्रम इस प्रकार दिखता है:
- एक सीमित पायलट चुनें: एक कम जोखिम वाले एप्लिकेशन, साइट या यूज़र ग्रुप का चयन करें जिसका एक ज्ञात ओनर और स्पष्ट सपोर्ट रूट हो।
- बेसलाइन रिकॉर्ड करें: सफल और असफल ऑथेंटिकेशन, डिवाइस पोश्चर, सर्टिफिकेट स्टेटस, नेटवर्क प्लेसमेंट, पॉलिसी रिज़ल्ट और एप्लिकेशन आउटकम को कैप्चर करें।
- डिनाई पाथ का परीक्षण करें: पुष्टि करें कि असफल MFA, रिवोक किए गए सर्टिफिकेट, डिसेबल की गई डायरेक्टरी आइडेंटिटी और नॉन-कंप्लायंट डिवाइस ब्लॉक किए जा रहे हैं।
- बारीकी से लागू करें: पायलट पर पॉलिसी लागू करें, जिसमें एक दस्तावेजी रोलबैक स्थिति और एक एडमिनिस्ट्रेटर हो जो बदलाव को वापस ले सके।
- डिपेंडेंसी के आधार पर विस्तार करें: पिछले चरण में स्थिर लॉग और एक सहमत सपोर्ट प्रोसेस होने के बाद ही ग्रुप, साइट या सर्विसेज़ को जोड़ें।
पायलट परीक्षण में विफलता का परीक्षण भी शामिल होना चाहिए। एक परीक्षण पहचान को अक्षम करें, उसकी समूह सदस्यता हटाएँ, एक डिवाइस को गैर-अनुपालन के रूप में चिह्नित करें और उसके सर्टिफिकेट को रद्द करें। पुष्टि करें कि नेटवर्क एक्सेस, एप्लिकेशन एक्सेस और सक्रिय सेशन्स योजना के अनुसार प्रतिक्रिया दे रहे हैं।
टेलीमेट्री को उपयोगी बनाएं
केवल कनेक्शन की पुष्टि करने वाले इवेंट्स ही नहीं, बल्कि उन इवेंट्स को भी इकट्ठा करें जो निर्णयों को समझाते हैं। कम से कम, अनुरोध करने वाली पहचान, डिवाइस पहचानकर्ता, प्रमाणीकरण परिणाम, सर्टिफिकेट की स्थिति, पोस्चर परिणाम, नेटवर्क सेगमेंट, गंतव्य संसाधन, पॉलिसी संस्करण और अंतिम निर्णय के बीच संबंध स्थापित करें।
उन पैटर्नों को देखें जिन्हें मानवीय समीक्षा की आवश्यकता है:
- पहचान का अनपेक्षित उपयोग: कोई उपयोगकर्ता अपनी सामान्य भूमिका या स्वीकृत समूह से बाहर के संसाधन तक पहुँचता है।
- स्थिति (posture) में बदलाव: पहले से अनुपालन करने वाला डिवाइस प्रबंधन, एन्क्रिप्शन या प्रमाणपत्र स्थिति खो देता है।
- बार-बार विफलताएं: कई खातों या स्थानों पर प्रमाणीकरण या स्थिति की विफलताएं होती हैं।
- नीति अपवाद (Policy exceptions): कोई लीगेसी डिवाइस या सेवा बार-बार एक व्यापक नियम पर निर्भर करती है।
- निरसन (Revocation) में देरी: एक निष्क्रिय की गई डायरेक्टरी पहचान को नेटवर्क या एप्लिकेशन एक्सेस मिलना जारी रहता है।
यह आकलन करते समय कि पहचान-आधारित WiFi प्लेटफॉर्म एक्सेस डेटा, सुरक्षा नियंत्रण और परिचालन दृश्यता को कैसे संभालता है, Purple का डेटा और सुरक्षा अवलोकन देखें। आप जो भी टूल चुनें, डैशबोर्ड को निर्णयों का समर्थन करना चाहिए। एक लॉग जिसकी कोई समीक्षा नहीं करता, वह प्रवर्तन में सुधार नहीं करेगा।
रोलबैक स्थिति: किसी नीति को तब उलट दें जब वह किसी महत्वपूर्ण व्यावसायिक यात्रा को बाधित करती है, कोई असुरक्षित निर्भरता बनाती है या अस्पष्टीकृत एक्सेस विफलताओं को उत्पन्न करती है। साक्ष्य सुरक्षित रखें, डिज़ाइन को ठीक करें और पुनः परीक्षण करें। किसी आपातकालीन अपवाद को स्थायी रूप से खुला न छोड़ें।
सुरक्षा के हिस्से के रूप में उपलब्धता की रक्षा करें
शून्य विश्वास (ज़ीरो ट्रस्ट) निर्देशिकाओं, प्रमाणपत्र सेवाओं, नीति इंजनों, नेटवर्क नियंत्रकों और कनेक्टिविटी पर निर्भर करता है। प्रत्येक निर्भरता में लचीलापन बनाएँ। यह परिभाषित करें कि क्या होता है यदि पहचान प्रदाता तक नहीं पहुँचा जा सकता है, प्रमाणपत्रों को मान्य नहीं किया जा सकता है, एक नियंत्रक विफल हो जाता है या कोई नीति सेवा अनुपलब्ध हो जाती है।
सुरक्षित-विफल सेवा डिज़ाइन का सावधानीपूर्वक उपयोग करें। कुछ परिवेशों को पहचान-सेवा आउटेज के दौरान मौजूदा सत्रों को संक्षेप में जारी रखने की आवश्यकता होती है। दूसरों को संवेदनशील संसाधनों के लिए तुरंत एक्सेस को प्रतिबंधित करना चाहिए। सही विकल्प संसाधन, खतरे के मॉडल और परिचालन परिणाम पर निर्भर करता है।
लागू करने से पहले संवाद करें। उपयोगकर्ताओं को बताएं कि क्या बदलेगा, वे किन साइन-इन विधियों का उपयोग करेंगे, डिवाइस नामांकन कैसे काम करता है और विफलताओं की रिपोर्ट कहां करनी है। प्रत्येक चरण के बाद हेल्पडेस्क थीम और एक्सेस एनालिटिक्स को ट्रैक करें। कम किया गया मैन्युअल अकाउंट एडमिनिस्ट्रेशन, कम साझा क्रेडेंशियल और तेज़ निरसन (revocation) व्यावहारिक संकेत हैं कि ऑपरेटिंग मॉडल में सुधार हो रहा है।
आपकी Zero Trust कार्यान्वयन चेकलिस्ट और अगले कदम
एक व्यावहारिक कार्यान्वयन योजना अगली आर्किटेक्चर बैठक के एजेंडे में फिट होनी चाहिए:
- खोजें: लोगों, सर्विस खातों, डिवाइसों, एप्लिकेशनों और सेवाओं की सूची बनाएं।
- निर्भरताओं का मिलान करें: डेटा प्रवाह, प्रमाणीकरण विधियों, विरासत की सीमाओं और परिचालन स्वामियों का दस्तावेजीकरण करें।
- सीमाएं निर्धारित करें: संसाधन की आवश्यकता के अनुसार कर्मचारियों, मेहमानों, IoT और किरायेदारों की पहुंच को अलग करें।
- पहचान को मजबूत करें: एक डायरेक्टरी सोर्स ऑफ ट्रुथ चुनें, MFA लागू करें और SSO पेश करें।
- मजबूत प्रमाणीकरण अपनाएं: उपयुक्त उपयोगकर्ताओं और डिवाइसों को पासवर्ड रहित और प्रमाणपत्र-आधारित पहुंच की ओर ले जाएं।
- लाइफसाइकिल को स्वचालित करें: डायरेक्टरी समूहों से प्रोविज़निंग करें और पहचान या प्रमाणपत्र बदलने पर पहुंच रद्द करें।
- स्थिति का आकलन करें: संवेदनशील पहुंच प्रदान करने से पहले प्रबंधन, स्वास्थ्य और अनुपालन की जांच करें।
- सुरक्षित WiFi: कर्मचारियों के साझा पासवर्ड के बजाय पहचान से जुड़े उद्यम प्रमाणीकरण का उपयोग करें।
- विरासत डिवाइसों को नियंत्रित करें: सीमित दायरे वाली नीतियों के साथ प्रतिबंधित सेगमेंट पर अपवाद रखें।
- पहले निगरानी करें: अवलोकन मोड में पायलट नीतियां चलाएं, फिर रोलबैक मानदंडों के साथ उन्हें लागू करें।
- लगातार सत्यापित करें: अस्वीकृत पहुंच, निरसन, स्थिति में बदलाव और सेवा विफलताओं का परीक्षण करें।
- सोच-समझकर विस्तार करें: केवल तभी साइटें और वर्कलोड जोड़ें जब लॉग, स्वामित्व और सहायता प्रक्रियाएं तैयार हों।
कार्यान्वयन का सबसे महत्वपूर्ण निर्णय अनुक्रमण (sequencing) है। सबसे अधिक दिखाई देने वाले उत्पाद या सबसे बड़े नेटवर्क सेगमेंट से शुरुआत न करें। ऐसी यात्रा से शुरुआत करें जिसे आप समझ सकें, माप सकें और वापस बदल सकें। हॉस्पिटैलिटी और रिटेल के लिए, इसका मतलब एक लाइव स्थान पर कर्मचारियों, मेहमानों और परिचालन उपकरणों को अलग करना हो सकता है। हेल्थकेयर के लिए, इसका मतलब किसी संवेदनशील एप्लिकेशन के आसपास पहचान और डिवाइस नियंत्रणों को प्राथमिकता देना हो सकता है। मल्टी-टेनेंट हाउसिंग के लिए, इसका मतलब किरायेदारों और बिल्डिंग सिस्टम के बीच अलगाव को बनाए रखते हुए सरल निवासी पहुंच प्रदान करना हो सकता है।
एक ऐसा प्लेटफ़ॉर्म चुनें जो वास्तविक माइग्रेशन बाधा को दूर करता हो। यदि आपके संगठन को पासवर्ड रहित WiFi, निर्देशिका-एकीकृत कर्मचारी पहुंच, स्वचालित निरस्तीकरण और ऑन-प्रिमाइसेस RADIUS पर कम निर्भरता की आवश्यकता है, तो मूल्यांकन करें कि क्या Purple जैसा प्लेटफ़ॉर्म मौजूदा पहचान और नेटवर्क आर्किटेक्चर के अनुकूल है। इस निर्णय को अपने नियंत्रण उद्देश्यों, एकीकरण आवश्यकताओं और परिचालन स्वामित्व से जोड़कर रखें।
प्रगति को साक्ष्यों के माध्यम से मापें, न कि परिनियोजन (deployment) की घोषणाओं के माध्यम से। आपको यह दिखाने में सक्षम होना चाहिए कि किन पहचानों के पास एक्सेस है, कौन से डिवाइस विश्वसनीय हैं, किन नीतियों ने अनुरोधों को अस्वीकार कर दिया, निरसन कितनी तेज़ी से प्रभावी हुआ और अपवाद कहाँ बचे हैं। इस तरह ज़ीरो ट्रस्ट एक अन्य रुके हुए सुरक्षा कार्यक्रम के बजाय एक परिचालन क्षमता बन जाता है।
Purple पहचान-आधारित WiFi और नेटवर्किंग प्रदान करता है जो कर्मचारियों और उपकरणों को मौजूदा निर्देशिकाओं से जोड़ता है, पासवर्ड रहित और प्रमाणपत्र-श्रेणी पहुंच का समर्थन करता है, और निर्देशिका स्थिति बदलने पर प्रोविजनिंग और निरस्तीकरण को स्वचालित कर सकता है। यह मूल्यांकन करने के लिए कि इसका WiFi प्रमाणीकरण, डिवाइस पोस्चर और नेटवर्क एकीकरण चरणबद्ध zero-trust रोलआउट का समर्थन कैसे कर सकता है, Purple पर जाएं।
