Zero Trust network architecture and sizing advisor
Model identity-driven 802.1X authentication, dynamic VLAN segregation, and attack surface reduction for enterprise WiFi and campus switching networks.
Identity-driven 802.1X & Cloud RADIUS architecture
Eliminate shared network passwords across all corporate SSIDs. With 802.1X EAP-TLS, each device authenticates using a unique client certificate bound to the user identity in Microsoft Entra ID. Certificates are issued through Intune SCEP or PKCS profile against an NDES connector, and withdrawn through Conditional Access revocation plus CRL publication.
! Zero Trust 802.1X policy, Catalyst 9800 / IOS-XE ! Identity source: Microsoft Entra ID ! Credential: 802.1X EAP-TLS with per-device client certificates ! RADIUS endpoints shown as RFC 5737 documentation addresses radius server ZT-RADIUS-PRIMARY address ipv4 198.51.100.10 auth-port 1812 acct-port 1813 key 0 <RADIUS_SHARED_SECRET> radius server ZT-RADIUS-SECONDARY address ipv4 198.51.100.11 auth-port 1812 acct-port 1813 key 0 <RADIUS_SHARED_SECRET> aaa group server radius ZT-RADIUS-GROUP server name ZT-RADIUS-PRIMARY server name ZT-RADIUS-SECONDARY aaa authentication dot1x default group ZT-RADIUS-GROUP aaa authorization network default group ZT-RADIUS-GROUP aaa accounting identity default start-stop group ZT-RADIUS-GROUP aaa server radius dynamic-author client 198.51.100.10 server-key 0 <COA_SHARED_SECRET> client 198.51.100.11 server-key 0 <COA_SHARED_SECRET> auth-type all dot1x system-auth-control wlan ZT-CORP 1 ZT-CORP security wpa wpa2 wpa3 security dot1x authentication-list ZT-DOT1X no shutdown wireless profile policy ZT-CORP-POLICY aaa policy-override ! Honours RFC 2868 Tunnel-Private-Group-ID from the RADIUS reply aaa-override accounting-list default no shutdown ! key 0 is cleartext in the running config. Type 7 is reversible ! obfuscation, not encryption, so neither protects the secret at rest: ! hold it in a configuration manager and rotate it on exposure.
Ready to deploy Zero Trust across your wireless and wired campus?
Purple provides enterprise Cloud RADIUS, seamless 802.1X certificate provisioning, and dynamic VLAN segmentation for Cisco, Aruba, Ruckus, Extreme, and Meraki architectures.
UK मध्ये, ९८% संस्था सांगतात की त्यांनी zero trust लागू करण्याची योजना आखली आहे किंवा आधीच लागू केले आहे, तरीही केवळ १५% संस्था पूर्ण अंमलबजावणीचा अहवाल देतात. ही तफावत जागरूकतेची नाही. ती अंमलबजावणीची आहे. UK मधील zero-trust संशोधन दर्शवते की अनेक टीम्सनी ही नियंत्रणे एका ऑपरेटिंग मॉडेलमध्ये न जोडता नियोजन, विभाजन किंवा वेगळे ओळख प्रकल्प सुरू केले आहेत.
प्रत्यक्ष प्रश्न हा नाही की zero trust महत्त्वाचे आहे की नाही. प्रश्न हा आहे की लाइव्ह सर्व्हिसेस खंडित न करता, युजर्सना त्रास न देता किंवा डिस्कनेक्ट केलेल्या सुरक्षा उत्पादनांचा आणखी एक संग्रह तयार न करता zero trust कसे लागू करावे. याचे उत्तर म्हणजे आयडेंटिटी, डिव्हाइस पोश्चर, डिरेक्टरी लाइफसायकल, सुरक्षित WiFi, सेगमेंटेशन आणि सतत व्हेरिफिकेशन यांच्याभोवती मायग्रेशनचा क्रम ठरवणे हा आहे.
एंटरप्राइजेसमध्ये Zero Trust अंमलबजावणी का रखडते
५१% संस्था अजूनही सुरुवातीच्या नियोजन टप्प्यात आहेत, तर केवळ १५% पूर्ण अंमलबजावणीचा दावा करतात, आणि ८०% संस्थांना तांत्रिक किंवा ऑपरेशनल अडथळ्यांचा सामना करावा लागला आहे. यूके संस्थांचा अहवाल दिशा निवडणे आणि आवश्यक नियंत्रणे ऑपरेट करणे यामधील फरक दर्शवतो. टीम्स अनेकदा विलग प्रोजेक्ट्सपासून सुरुवात करतात, आणि नंतर त्यांना समजते की आयडेंटिटी, डिव्हाइसेस, डिरेक्टरीज, ॲप्लिकेशन्स आणि नेटवर्क हे एकमेकांवर अवलंबून आहेत.
झिरो ट्रस्ट हा प्रणाली, नेटवर्क्स आणि सेवांमधील मूळचा विश्वास (inherent trust) काढून टाकतो. अंतर्गत कनेक्शनने व्यापक प्रवेश प्रदान करू नये. एखाद्या व्यक्तीला किंवा पुरवठादाराला त्याची गरज नसताना जुन्या खात्याकडे परवानग्या राहू नयेत. एखादी सेवा एकदा ऑथेंटिकेशन चाचणी उत्तीर्ण झाली म्हणून ती अमर्याद काळासाठी विश्वासू राहू नये.
UK National Cyber Security Centre झिरो ट्रस्टला प्रोडक्ट खरेदी न मानता एक टप्प्याटप्प्याने केलेले स्थलांतर (staged migration) म्हणून परिभाषित करते. त्याचे आर्किटेक्चर मार्गदर्शन आठ डिझाइन तत्त्वे स्पष्ट करते, ज्यामध्ये आयडेंटिटी-आधारित ॲक्सेस निर्णय आणि प्रोटेक्टेड कम्युनिकेशन्स समाविष्ट आहेत. NCSC झिरो-ट्रस्ट संग्रह 2021 मध्ये प्रकाशित झाला होता, आणि अंमलबजावणीचे मार्गदर्शन त्याच वर्षाच्या सप्टेंबरमध्ये विस्तारित करण्यात आले. The NCSC architecture design principles हे उपयुक्त आहेत कारण ते तंत्रज्ञान निवडण्यापूर्वी टीम्सना आर्किटेक्चर आणि ट्रस्टचे निर्णय निश्चित करण्यास भाग पाडतात.
प्रॉडक्ट-फर्स्ट अपयशाची पद्धत
अपयशाचे पॅटर्न सहसा प्लॅटफॉर्म खरेदीपासून सुरू होते. एखादी टीम आयडेंटिटी प्रॉडक्ट, सेगमेंटेशन टूल किंवा ZTNA गेटवे तैनात करते, आणि नंतर त्यांच्या लक्षात येते की सर्व्हिस अकाऊंट्स, अनमॅनेज्ड डिव्हाइसेस, लेगसी ॲप्लिकेशन्स, वायरलेस ऑथेंटिकेशन आणि डिरेक्टरी ऑफबोर्डिंग हे कधी मॅपच केले गेले नव्हते.
याचा परिणाम म्हणजे अपवादांची एक वाढती यादी तयार होते. युझर्सना तात्पुरते मार्ग मिळतात, ॲडमिनिस्ट्रेटर्स शेअर्ड क्रेडेंशियल्स सुरक्षित ठेवतात आणि सिक्युरिटी टीम्सना पॉलिसी सातत्याने लागू केली जात आहे की नाही हे समजू शकत नाही. WiFi ही कमकुवतता त्वरीत उघड करते. नेटवर्क सेगमेंटेशन ट्रॅफिक वेगळे करू शकते, परंतु युझर्स अद्याप शेअर्ड पासवर्डद्वारे जॉइन करत असतील किंवा डिव्हाइसेस अज्ञात राहत असतील, तर ते आयडेंटिटी-आधारित ॲक्सेस तयार करत नाही. सर्टिफिकेट-आधारित ऑथेंटिकेशनसह पासवर्डलेस WiFi, जे डिव्हाइस रेकॉर्ड्स आणि डिरेक्टरी स्टेटसशी जोडलेले असते, ते पॉलिसीला एक विश्वासार्ह आयडेंटिटी सिग्नल देते. मॅन्युअल क्लीनअपची वाट पाहण्याऐवजी, अकाउंट डिसेबल केल्यावर ऑटोमॅटिक डिरेक्टरी रिव्होकेशनने ॲक्सेस काढून टाकला पाहिजे.
पारंपारिक पेरीमीटर नियंत्रणांची अजूनही भूमिका आहे, परंतु ते प्रत्येक प्रवेशाच्या प्रश्नाचे उत्तर देऊ शकत नाहीत. पारंपारिक आयटी सुरक्षा का अपयशी ठरते हे स्पष्ट करते की क्लाउड सेवा, रिमोट ॲक्सेस आणि वितरित डिव्हाइसेसमुळे अंतर्गत नेटवर्क स्वयंचलितपणे सुरक्षित आहे हा समज कसा कमकुवत होतो.
प्रॅक्टिकल नियम: पॉलिसीमुळे कोणती ओळख, डिव्हाइस, WiFi आणि सर्व्हिस अवलंबित्व विस्कळीत होऊ शकते हे जाणून घेतल्याशिवाय अंमलबजावणी पॉलिसी लिहू नका.
एक व्यवहार्य मायग्रेशन या क्रमाचे अनुसरण करते:
- इस्टेट शोधा: युझर्स, डिव्हाइसेस, ॲप्लिकेशन्स, सर्व्हिसेस आणि डेटा फ्लो ओळखा.
- सीमा निश्चित करा: कोणत्या रिसोर्सेसना आयसोलेशनची आवश्यकता आहे आणि कोणते ॲक्सेस पाथ्स वैध आहेत ते ठरवा.
- कंट्रोल प्लेन तयार करा: आयडेंटिटी, MFA, सर्टिफिकेट-आधारित डिव्हाइस ॲक्सेस, पोश्चर चेक्स आणि डिरेक्टरी लाइफसायकल कनेक्ट करा.
- एजवर लागू करा: केवळ VPN सेशन्सवरच नव्हे, तर ॲप्लिकेशन्स, नेटवर्क आणि WiFi वर देखील पॉलिसी लागू करा.
- निरीक्षण करा आणि विस्तार करा: नियंत्रित वर्कलोड्ससह सुरुवात करा, ॲक्सेस निर्णयांचे पुनरावलोकन करा आणि हळूहळू मॉडेलचा विस्तार करा.
हा क्रम झिरो ट्रस्टला साधनांच्या संग्रहाऐवजी एक ऑपरेटिंग मॉडेल बनवतो. तसेच यामुळे ऑपरेशन्स टीम्सना ओळख नियंत्रणे, सुरक्षित WiFi आणि सेगमेंटेशन परिपक्व होत असताना उपलब्धता सुरक्षित ठेवण्याची परवानगी मिळते.
डिस्कव्हरी आणि ट्रस्ट बाउंड्रीजसह पाया रचणे
अशा इन्व्हेंटरीपासून सुरुवात करा जी संस्था प्रत्यक्षात कशी काम करते हे दर्शवते, नेटवर्क डायग्राम काय सांगतो यावर नाही. NCSC वापरकर्ते, आवश्यक परवानग्या, डिव्हाइसेस आणि सेवा ओळखण्याची शिफारस करते, आणि नंतर त्या निष्कर्षांनुसार आयडेंटिटी आणि ॲक्सेस व्यवस्थापन डिझाइन करण्याची शिफारस करते. NCSC मायग्रेशन मार्गदर्शन रोलआउटपूर्वी जुन्या अवलंबित्वे मॅप करण्यासाठी आणि प्रस्तावित आर्किटेक्चरच्या थ्रेट - मॉडेलिंगसाठी देखील टीम्सना मार्गदर्शन करते.
आउटपुट हा एक कार्यरत कॅटलॉग असावा, स्थिर स्प्रेडशीट नाही. प्रत्येक महत्त्वाच्या रिसोर्ससाठी मालक, व्यावसायिक उद्देश, ऑथेंटिकेशन पद्धत, अवलंबित्व, डेटा संवेदनशीलता, अपेक्षित युझर्स आणि अपयशाचा प्रभाव नोंदवा.
चार इन्व्हेंटरीज तयार करा
युजर्स आणि आयडेंटिटी पहिल्या क्रमांकावर येतात. यामध्ये कर्मचारी, कंत्राटदार, प्रिव्हिलेज्ड अ‍ॅडमिनिस्ट्रेटर्स, सर्व्हिस अकाउंट्स आणि ऑटोमेशन आयडेंटिटीज यांचा समावेश होतो. व्यक्तीच्या नोकरीच्या स्थितीला त्यांच्या अ‍ॅक्सेसच्या गरजेपासून वेगळे ठेवा. कंत्राटदाराला एका ठराविक कालावधीसाठी एका अ‍ॅप्लिकेशनच्या अ‍ॅक्सेसची आवश्यकता असू शकते, तर सर्व्हिस अकाउंटला मशीन ऑथेंटिकेशनची आवश्यकता असू शकते परंतु कोणत्याही इंटरअ‍ॅक्टिव्ह लॉगिनची आवश्यकता नसते.
Devices चे स्वतःचे वर्गीकरण असणे आवश्यक आहे. व्यवस्थापित लॅपटॉप, मोबाईल उपकरणे, सामायिक टर्मिनल्स, प्रिंटर, कॅमेरे, बिल्डिंग सिस्टम आणि इतर IoT उपकरणांची नोंद ठेवा. कोणती उपकरणे प्रमाणपत्रे, आधुनिक एन्क्रिप्शन आणि पोश्चर रिपोर्टिंगला सपोर्ट करतात ते नोंदवून घ्या. जुनी उपकरणे बऱ्याचदा कर्मचाऱ्यांच्या प्रमाणीकरण आवश्यकता पूर्ण करू शकत नाहीत, म्हणून त्यांना विना-ट्रॅक अपवाद म्हणून ठेवण्याऐवजी स्पष्ट प्रतिबंध धोरणाची आवश्यकता असते.
ॲप्लिकेशन्स आणि सेवा त्यांच्या ओळख आणि ट्रान्सपोर्ट आवश्यकतांशी मॅप केल्या पाहिजेत. प्रत्येक ॲप्लिकेशन SSO, MFA, आधुनिक प्रोटोकॉल, प्रमाणपत्रे, प्रॉक्सी प्रवेश किंवा केवळ जुने युझरनेम आणि पासवर्डचे समर्थन करते का याचे दस्तऐवजीकरण करा. अपस्ट्रीम डिरेक्टरी, डेटाबेस, DNS सेवा, API आणि लॉगिंग अवलंबने ओळखा.
डेटा प्रवाह आणि व्यावसायिक प्रवास हे विश्वासाच्या सीमा स्पष्ट करतात. कर्मचारी क्लिनिकल सिस्टीमपर्यंत कसा पोहोचतो, कंत्राटदार मेंटेनन्स पोर्टलवर कसा प्रवेश मिळवतो, किंवा पॉइंट-ऑफ-सेल डिव्हाइस मंजूर सेवांशी कसा संवाद साधते याचा नकाशा तयार करा. जर एखाद्या दस्तऐवजीकरण नसलेल्या अवलंबनामुळे अनियंत्रित प्रवेश देणे भाग पडत असेल, तर त्या सेगमेंटला काही अर्थ राहत नाही.
पॉलिसी ठरवण्यापूर्वी बाउंड्रीज निश्चित करा
ट्रस्ट बाउंड्रीने तीन प्रश्नांची उत्तरे दिली पाहिजेत: कशाचे संरक्षण केले जात आहे, कोणाला ॲक्सेसची आवश्यकता आहे आणि कोणत्या अटींनुसार. अटींमध्ये ओळख पटवणे, डिव्हाइसचे आरोग्य, नेटवर्क संदर्भ, ॲप्लिकेशन संवेदनशीलता आणि वेळ - मर्यादित मंजुरी यांचा समावेश असू शकतो.
अतिथी WiFi, IoT आणि बहु-भाडेकरू (multi-tenant) साइट्सवर विशेष लक्ष देणे आवश्यक आहे. अतिथी कधीही कर्मचाऱ्यांच्या नेटवर्क क्रेडेंशियल्सवर अवलंबून नसावेत. IoT उपकरणांनी केवळ त्यांच्या कार्यासाठी आवश्यक असलेल्या सेवांशी संवाद साधला पाहिजे. भाडेकरू तार्किक अलगाव आणि स्वतंत्र ओळख प्रशासन राखून भौतिक पायाभूत सुविधा सामायिक करू शकतात.
प्रत्येक सीमेवर सुरक्षित ट्रान्सपोर्ट महत्त्वाचा आहे. जर टीमला प्रमाणपत्रे, एन्क्रिप्शन आणि ब्राउझर विश्वासाबाबत सोप्या भाषेतील उजळणी हवी असेल, तर ॲप्लिकेशन आणि WiFi ट्रान्सपोर्ट गृहीतकांचे दस्तऐवजीकरण करण्यापूर्वी Adwave Digital's guide to SSL हा एक उपयुक्त संदर्भ आहे.
थ्रेट मॉडेलसह शोध प्रक्रिया पूर्ण करा. जर एखादे डिरेक्टरी खाते तडजोड (compromised) झाले, एखादे व्यवस्थापित डिव्हाइस असुरक्षित झाले, एखादे प्रमाणपत्र रद्द केले गेले, एखादा वायरलेस कंट्रोलर अनुपलब्ध झाला किंवा एखादी जुनी सेवा नवीन ओळख प्रदात्याविरुद्ध ऑथेंटिकेट करू शकली नाही तर काय होते हे तपासा. त्या अपयशाच्या मार्गांनी रोलआउटच्या क्रमाला आकार दिला पाहिजे.
आयडेंटिटी आणि डिव्हाइस पोश्चरला तुमचे कंट्रोल प्लेन म्हणून तयार करणे
Zero trust निर्णयांना विश्वासाच्या एका स्रोताची (source of truth) आवश्यकता असते. बहुतांश मालमत्तांमध्ये, याचा अर्थ अशी डिरेक्टरी निवडणे आहे जी लोक, गट आणि लाइफसायकल इव्हेंट्स नियंत्रित करते, जसे की Microsoft Entra ID, Google Workspace किंवा Okta. महत्त्वाचा डिझाइन पर्याय केवळ ब्रँडचा नाही. तर प्रत्येक अ‍ॅक्सेस सिस्टम समान आयडेंटिटी स्थिती वापरू शकते का आणि ती स्थिती बदलल्यावर प्रतिक्रिया देऊ शकते का हा आहे.
संस्था सोडणाऱ्या वापरकर्त्याची प्रत्येक महत्त्वाच्या ठिकाणची प्रवेश परवानगी संपुष्टात आली पाहिजे. प्रशासक स्वतंत्र खाते काढून टाकण्यास विसरल्यामुळे, ज्या कंत्राटदाराचे काम संपले आहे तो वायरलेस प्रणालीमध्ये सक्रिय राहू नये. ऑटोमॅटिक प्रोव्हिजनिंग आणि रिव्होकेशनमुळे डिरेक्टरीमधील बदल हे प्रशासकीय स्मरणपत्रांऐवजी ऑपरेशनल नियंत्रणे बनतात.
व्यक्ती आणि डिव्हाइस दोन्ही ऑथेंटिकेट करा
वर्कफोर्स ॲप्लिकेशन्ससाठी SSO आणि MFA सह सुरुवात करा. MFA मुळे खात्री वाढते, तर SSO मुळे वापरकर्ते आणि सर्व्हिस डेस्कना व्यवस्थापित कराव्या लागणाऱ्या क्रेडेंशियल्सची संख्या कमी होते. NCSC विशेषतः MFA च्या आसपास IAM डिझाइन करण्याची आणि योग्य असेल तिथे पासवर्डलेस प्रमाणीकरणाचा (passwordless authentication) विचार करण्याची शिफारस करते. पासवर्डलेस पद्धती सुरक्षा आणि उपयोगिता दोन्ही सुधारू शकतात, परंतु त्यांना रिकव्हरी प्रक्रियेची, डिव्हाइस नोंदणी नियंत्रणाची आणि त्यांच्या प्राथमिक ऑथेंटिकेटरचा प्रवेश गमावलेल्या वापरकर्त्यांसाठी सपोर्टची आवश्यकता असते.
कर्मचार्‍यांच्या WiFi साठी, सामायिक केलेल्या पासवर्डपेक्षा प्रमाणपत्र-आधारित प्रमाणीकरण सहसा ऑपरेशनलदृष्ट्या अधिक मजबूत असते. WPA2 किंवा WPA3-Enterprise आणि 802.1X सह, नेटवर्क नोंदणीकृत ओळख किंवा डिव्हाइस प्रमाणपत्राशी प्रवेश बांधील ठेवू शकते. यामुळे सामान्य की वितरीत करण्याची आवश्यकता दूर होते आणि रद्द करण्याची प्रक्रिया अचूक होते.
डिव्हाइसची स्थिती निर्णयाचा दुसरा भाग जोडते. डिव्हाइस व्यवस्थापित, कूटबद्ध (encrypted), पॅच केलेले, अनुपालन करणारे आणि मंजूर प्रमाणपत्र वापरत आहे की नाही ते तपासा. व्यवस्थापित न केलेल्या लॅपटॉपवरील वैध वापरकर्त्याला निरोगी कॉर्पोरेट डिव्हाइसवरील वापरकर्त्याप्रमाणेच प्रवेश आपोआप मिळू नये.
ओळख हे सिद्ध करते की कोण ॲक्सेसची विनंती करत आहे. डिव्हाइस पोश्चर हे ठरवते की ती ॲक्सेस विनंती मंजूर करण्यासाठी पुरेशी सुरक्षित आहे की नाही.
केवळ लॉगिन नाही, तर लाइफसायकल इव्हेंट्स डिझाइन करा
ऑनबोर्डिंगने निर्देशिका ओळख तयार केली पाहिजे, योग्य गट नियुक्त केले पाहिजेत, डिव्हाइसची नोंदणी केली पाहिजे आणि स्वयंचलित वर्कफ्लोद्वारे आवश्यक प्रमाणपत्र जारी केले पाहिजे. ऑफबोर्डिंगने ओळख अक्षम केली पाहिजे, सत्रे आणि प्रमाणपत्रे रद्द केली पाहिजेत आणि स्वतंत्र WiFi प्रशासकाची वाट न पाहता नेटवर्क प्रवेश काढून टाकला पाहिजे.
कंत्राटदारांना वेगळ्या मार्गाची आवश्यकता असते. त्यांना संकुचित व्याप्तीचे गट सदस्यत्व, कालबाह्यता किंवा मंजुरी प्रक्रिया द्या आणि केवळ त्यांच्या कामासाठी आवश्यक असलेल्या ॲप्लिकेशन्स आणि नेटवर्क सेगमेंटमध्येच प्रवेश द्या. कंत्राटदारांच्या सुविधेसाठी त्यांना व्यापक कर्मचारी नेटवर्कवर ठेवून तो तोडगा काढू नका.
जुन्या उपकरणांना मर्यादित ठेवण्याची गरज आहे. जिथे प्रिंटर, सेन्सर किंवा तज्ञ टर्मिनल सर्टिफिकेट-आधारित ऑथेंटिकेशन वापरू शकत नाही, तिथे समर्पित विभाग, काटेकोर फायरवॉल नियम आणि वैयक्तिक प्री-शेअर्ड की सारखी नियंत्रित ओळख यंत्रणा वापरा. यामुळे अपवाद दृश्यमान राहतो आणि त्याचा संभाव्य प्रभाव मर्यादित होतो.
आयडेंटिटी-बाउंड नेटवर्क अ‍ॅक्सेसचे मूल्यमापन करणारे टिम्स अंमलबजावणीचा एक पॅटर्न म्हणून identity-based networking चे पुनरावलोकन करू शकतात. प्लॅटफॉर्म कोणताही असो, आर्किटेक्चरल तत्त्व समान राहते: डिरेक्टरीची स्थिती, ऑथेंटिकेशनची मजबूती आणि डिव्हाइसची स्थिती यांनी एकत्रितपणे अ‍ॅक्सेसच्या निर्णयावर परिणाम केला पाहिजे.
पॉलिसी लागू करणारे सेगमेंटेशन आणि सुरक्षित WiFi
नेटवर्कचे विभाजन (Segmentation) आवश्यक आहे, परंतु ते स्वतःहून ओळख-आधारित प्रवेश लागू करू शकत नाही. सर्वेक्षण केलेल्या UK मधील ९२% संस्था सांगतात की ते त्यांच्या नेटवर्कचे काही प्रमाणात विभाजन करतात, तर ९८% संस्था सांगतात की त्यांनी zero trust लागू करण्याची योजना आखली आहे किंवा आधीच लागू केले आहे. UK मधील संशोधन असे दर्शवते की नेटवर्क झोनिंग मोठ्या प्रमाणावर पसरले आहे, परंतु ओळख सुनिश्चित करणे, सतत पडताळणी आणि धोरण अंमलबजावणी यावर अद्याप लक्ष देण्याची गरज आहे.
एक VLAN ट्रॅफिक वेगळे करतो. एखादी व्यक्ती, डिव्हाइस किंवा सेशनने ॲक्सेस कायम ठेवावा की नाही हे तो ठरवत नाही. जर एखादा युझर सुसंगत लॅपटॉपवरून अनमॅनेज्ड डिव्हाइसवर गेला, तर जोपर्यंत ॲक्सेस सिस्टम ओळख आणि पोश्चरचे पुन्हा मूल्यांकन करत नाही, तोपर्यंत ते डिव्हाइस त्याच सेगमेंटमध्ये राहू शकते.
मॅच्युरिटी लेव्हल्सची तुलना करा
| नियंत्रण क्षेत्र | अंशतः अंमलबजावणी | Zero Trust परिपक्वता |
|---|---|---|
| नेटवर्क डिझाइन | VLANs किंवा विस्तृत झोन पाहुणे, कर्मचारी आणि उपकरणांना वेगळे करतात | सूक्ष्म धोरणे विशिष्ट संसाधनांना आणि प्रवाहांना ॲक्सेस मर्यादित करतात |
| WiFi ऑथेंटिकेशन | सामायिक पासवर्ड, captive portals किंवा स्टॅटिक कीज | WPA2 किंवा WPA3-Enterprise, 802.1X आणि सर्टिफिकेट किंवा ओळख-आधारित ॲक्सेस |
| वापरकर्ता जीवनचक्र | प्रशासक मॅन्युअली खाती तयार करतात आणि काढून टाकतात | निर्देशिका (directory) बदल स्वयंचलितपणे ॲक्सेसची तरतूद करतात आणि रद्द करतात |
| उपकरण खात्री | योग्य नेटवर्क क्रेडेंशियल असल्यास उपकरण कनेक्ट होते | उपकरणाचे आरोग्य आणि सर्टिफिकेटची स्थिती प्रत्येक ॲक्सेस निर्णयावर परिणाम करते |
| धोरण प्रतिसाद | सत्र किंवा खाते मॅन्युअली बदल होईपर्यंत ॲक्सेस सक्रिय राहतो | संदर्भ बदलल्यास पुनर्मूल्यांकन, निर्बंध किंवा रद्दीकरण ट्रिगर होते |
| दृश्यमानता | कंट्रोलर लॉग्स कनेक्शन इव्हेंट्स दाखवतात | पुनरावलोकनासाठी ओळख, उपकरण, धोरण आणि संसाधन इव्हेंट्स परस्परसंबंधित केले जातात |
WiFi ला एक आयडेंटिटी बाउंड्री समजा
एखाद्या डिव्हाइसला सामोरे जावे लागणारा WiFi हा सहसा पहिला एंटरप्राइझ ॲक्सेस निर्णय असतो. कार्यक्रमात याला उशीर केल्यास डिरेक्टरी पॉलिसी आणि प्रत्यक्ष कनेक्टिव्हिटीमध्ये अंतर निर्माण होते.
कर्मचाऱ्यांसाठी, प्रमाणपत्रे किंवा इतर मजबूत ओळख पद्धतीद्वारे समर्थित 802.1X सह WPA2 किंवा WPA3-Enterprise वापरा. पासवर्डशिवाय असलेले WiFi वापरकर्त्याच्या अनुभवातून सामायिक सिक्रेट्स काढून टाकते, तर प्रमाणपत्र-आधारित प्रमाणीकरण कनेक्टिव्हिटीला नोंदणीकृत ओळख आणि उपकरणाशी जोडते. Passpoint आणि OpenRoaming नोंदणीकृत उपकरणाला वारंवार पासवर्ड न टाकता प्रमाणीकृत करण्याची परवानगी देऊन सुरक्षित रोमिंगला सपोर्ट करू शकतात.
पहिल्या पॅकेटपासून एनक्रिप्टेड, आयडेंटिटी-बाउंड कनेक्टिव्हिटी मिळवणे हे ध्येय आहे. युझरने अटी मान्य केल्यानंतर विस्तृत ॲक्सेस देणारे Captive Portal ते नियंत्रण प्रदान करत नाही.
enterprise WiFi security च्या व्यावहारिक पुनरावलोकनासाठी, प्रमाणपत्र वितरण, ओळख प्रदाता (identity provider) एकत्रीकरण, रिव्होकेशन हाताळणी आणि कंट्रोलर सुसंगतता यांचे मूल्यांकन करा. ही रचना संपूर्ण मालमत्तेमध्ये काम करणारी असावी, ज्यामध्ये Meraki, Aruba, Ruckus, Mist किंवा UniFi उपकरणांचा समावेश आहे.
अतिथींना स्वतंत्र अनुभव आणि पॉलिसीची आवश्यकता असते. कर्मचारी विशेषाधिकारांशिवाय इंटरनेट प्रवेश प्रदान करा. IoT उपकरणांना प्रतिबंधित पॉलिसींची आवश्यकता असते ज्या केवळ ऑपरेशनसाठी आवश्यक असलेल्या गंतव्यस्थानांना आणि सेवांना अनुमती देतात.
ॲक्सेसचे सतत पुनर्मूल्यांकन करा
NCSC हे स्पष्ट zero-trust आवश्यकता म्हणून सतत पुनर्मूल्यांकन, निरीक्षणक्षमता आणि लवचिकतेवर भर देते. त्यांचे ZTNA अंमलबजावणी मार्गदर्शन सत्राच्या कालावधीसाठी परवानग्या स्थिर ठेवण्याऐवजी संदर्भ बदलल्यावर प्रवेश बदलण्यास समर्थन देते.
डिरेक्टरी इंटिग्रेशनने ऑटोमॅटिक रिव्होकेशनला सपोर्ट केला पाहिजे. डिसेबल केलेले अकाउंट, काढून टाकलेले ग्रुप मेंबरशिप किंवा रिव्होक केलेले सर्टिफिकेट यामुळे स्वतंत्र WiFi अ‍ॅडमिनिस्ट्रेटरने हस्तक्षेप करण्याची वाट न पाहता पॉलिसी अपडेट्स ट्रिगर झाले पाहिजेत. याचा परिणाम स्टेप-अप ऑथेंटिकेशन, प्रतिबंधित नेटवर्कवर पाठवणे, अ‍ॅप्लिकेशन ब्लॉक करणे किंवा त्वरित अ‍ॅक्सेस रिव्होकेशन यामध्ये होऊ शकतो.
सेगमेंटेशन घटनेला एका मर्यादेत रोखून ठेवते. आयडेंटिटी, डिव्हाइस पोश्चर आणि सद्य टेलिमेट्रीवरून ॲक्सेस सुरू ठेवायचा की नाही हे ठरवले जाते. हे कॉम्बिनेशन नेटवर्क सेपरेशन आणि वास्तविक आयडेंटिटी-आधारित कंट्रोलमधील दरी भरून काढते.
मॉनिटरिंग सुरू करणे आणि प्रत्येक ॲक्सेस निर्णयाची पडताळणी करणे
सुरक्षित रोलआउट नियंत्रित, निरीक्षण करण्यायोग्य आणि पूर्ववत करण्यायोग्य असते. प्रत्येक वापरकर्ता, साइट आणि डिव्हाइस श्रेणीमध्ये नवीन पॉलिसी लागू करून सुरुवात करू नका. कमी जोखमीचा गट किंवा स्थान निवडा ज्यामध्ये समस्या उघड करण्यासाठी पुरेशी वास्तविक गुंतागुंत असेल, नंतर त्याचा विस्तार करण्यापूर्वी प्रवेश मार्गाची पडताळणी करा.
तंत्रज्ञान जिथे समर्थन देते तिथे मॉनिटर मोडमध्ये सुरुवात करा. पॉलिसी काय मंजूर करेल आणि काय नाकारेल हे कॅप्चर करा, त्या निर्णयांची व्यावसायिक आवश्यकतांशी तुलना करा आणि अज्ञात अवलंबनांची चौकशी करा. मॉनिटर मोड हा सक्तीचा (enforcement) पर्याय नाही. सक्तीचा परिणाम उत्पादनावर होण्यापूर्वी टाळता येण्याजोगे अडथळे दूर करण्याचा हा एक मार्ग आहे.
टप्प्याटप्प्याने मायग्रेशन वापरा
एक व्यावहारिक क्रम खालीलप्रमाणे दिसतो:
- मर्यादित पायलट निवडा: कमी जोखीम असलेला ॲप्लिकेशन, साइट किंवा युझर ग्रुप निवडा ज्याचा मालक निश्चित आहे आणि ज्याचा सपोर्ट मार्ग स्पष्ट आहे.
- बेसलाईन रेकॉर्ड करा: यशस्वी आणि अयशस्वी ऑथेंटिकेशन, डिव्हाइस पोश्चर, सर्टिफिकेट स्टेटस, नेटवर्क प्लेसमेंट, पॉलिसीचे परिणाम आणि ॲप्लिकेशन आउटकम कॅप्चर करा.
- नाकारलेल्या पाथची चाचणी घ्या: अयशस्वी MFA, रद्द केलेले सर्टिफिकेट्स, डिसेबल केलेल्या डिरेक्टरी आयडेंटिटीज आणि नॉन-कंप्लायंट डिव्हाइसेस ब्लॉक केले जात असल्याची खात्री करा.
- मर्यादित स्वरूपात लागू करा: दस्तऐवजीकरण केलेल्या रोलबॅक अटी आणि बदल उलट करू शकणाऱ्या ॲडमिनिस्ट्रेटरच्या देखरेखीसह पायलटवर पॉलिसी लागू करा.
- अवलंबित्वानुसार विस्तार करा: आधीच्या टप्प्यात स्थिर लॉग्स आणि मान्य केलेली सपोर्ट प्रक्रिया मिळाल्यानंतरच ग्रुप्स, साइट्स किंवा सर्व्हिसेस जोडा.
पायलट टेस्टमध्ये अपयशाची चाचणी समाविष्ट असावी. चाचणीसाठीची ओळख निष्क्रिय करा, त्याचे ग्रुप मेंबरशिप काढून टाका, एखादे डिव्हाइस नॉन - कंप्लायंट म्हणून चिन्हांकित करा आणि त्याचे सर्टिफिकेट रद्द करा. नेटवर्क ॲक्सेस, ॲप्लिकेशन ॲक्सेस आणि ॲक्टिव्ह सेशन्स डिझाइननुसार प्रतिसाद देत असल्याची खात्री करा.
टेलेमेट्री उपयुक्त बनवा
केवळ कनेक्शन झाले आहे हे सिद्ध करणाऱ्या इव्हेंट्सऐवजी, निर्णयांचे स्पष्टीकरण देणारे इव्हेंट्स गोळा करा. किमान, विनंती करणारी ओळख, डिव्हाइस आयडेंटिफायर, ऑथेंटिकेशन रिझल्ट, सर्टिफिकेट स्टेट, पोश्चर रिझल्ट, नेटवर्क सेगमेंट, डेस्टिनेशन रिसोर्स, पॉलिसी व्हर्जन आणि अंतिम निर्णय यांच्याशी परस्परसंबंध प्रस्थापित करा.
मानवी पुनरावलोकनाची आवश्यकता असलेले पॅटर्न शोधा:
- Unexpected identity use: एखादा वापरकर्ता त्यांच्या सामान्य भूमिकेबाहेर किंवा मंजूर गटाबाहेर जाऊन संसाधनामध्ये प्रवेश करतो.
- Posture changes: आधी सुसंगत असलेल्या डिव्हाइसचे व्यवस्थापन, एन्क्रिप्शन किंवा प्रमाणपत्र स्थिती बदलते.
- Repeated failures: एकाधिक खात्यांमध्ये किंवा ठिकाणी प्रमाणीकरण (authentication) किंवा पोश्चर अयशस्वी होण्याच्या घटना घडतात.
- Policy exceptions: एखादे जुने डिव्हाइस किंवा सेवा वारंवार एका व्यापक नियमावर अवलंबून राहते.
- Revocation delays: अक्षम केलेल्या डिरेक्टरी आयडेंटिटीला नेटवर्क किंवा ॲप्लिकेशन प्रवेश मिळत राहतो.
आयडेंटिटी-आधारित WiFi प्लॅटफॉर्म अ‍ॅक्सेस डेटा, सुरक्षा नियंत्रणे आणि ऑपरेशनल व्हिज्युअलिटी कशा प्रकारे हाताळतो याचे मूल्यांकन करताना Purple's data and security overview वापरा. तुम्ही कोणतीही साधने निवडली तरी, डॅशबोर्ड्सनी निर्णयांना पाठबळ दिले पाहिजे. ज्या लॉगचे कोणीही पुनरावलोकन करत नाही, त्यामुळे अंमलबजावणीत कोणतीही सुधारणा होणार नाही.
रोलबॅक अट: जेव्हा एखादी पॉलिसी गंभीर व्यावसायिक प्रवासात अडथळा आणते, असुरक्षित अवलंबित्व निर्माण करते किंवा न समजणारे प्रवेश अपयश निर्माण करते तेव्हा ती पॉलिसी उलट करा. पुरावे जतन करा, डिझाइन सुधारा आणि पुन्हा चाचणी घ्या. आपत्कालीन अपवाद कायमचा उघडा ठेवू नका.
सुरक्षेचा एक भाग म्हणून उपलब्धतेचे रक्षण करा
Zero trust हे निर्देशिका, प्रमाणपत्र सेवा, पॉलिसी इंजिन, नेटवर्क नियंत्रक आणि कनेक्टिव्हिटीवर अवलंबून असते. प्रत्येक अवलंबनामध्ये लवचिकता निर्माण करा. ओळख प्रदाता (identity provider) पोहोचण्याबाहेर असल्यास, प्रमाणपत्रांचे प्रमाणीकरण केले जाऊ शकत नसल्यास, नियंत्रक अयशस्वी झाल्यास किंवा पॉलिसी सेवा अनुपलब्ध झाल्यास काय घडते हे परिभाषित करा.
फेल-सेफ सेवा डिझाइन काळजीपूर्वक वापरा. काही वातावरणात ओळख-सेवा खंडीत असताना विद्यमान सत्रे थोड्या काळासाठी सुरू राहणे आवश्यक असते. इतरांनी संवेदनशील संसाधनांसाठी त्वरित प्रवेश प्रतिबंधित केला पाहिजे. योग्य निवड संसाधन, धोक्याचे मॉडेल आणि ऑपरेशनल परिणामावर अवलंबून असते.
लागू करण्यापूर्वी संवाद साधा. युजर्सना काय बदलणार आहे, ते कोणत्या साइन-इन पद्धती वापरतील, डिव्हाइस एनरोलमेंट कसे काम करते आणि बिघाडांची तक्रार कुठे करायची हे सांगा. प्रत्येक टप्प्यानंतर हेल्पडेस्क थीम्स आणि अ‍ॅक्सेस अ‍ॅनालिटिक्सचा मागोवा घ्या. मॅन्युअल अकाउंट अ‍ॅडमिनिस्ट्रेशन कमी होणे, शेअर केलेले क्रेडेंशियल्स कमी होणे आणि जलद रिव्होकेशन हे ऑपरेटिंग मॉडेल सुधारत असल्याचे व्यावहारिक संकेत आहेत.
तुमची Zero Trust अंमलबजावणी चेकलिस्ट आणि पुढील पायऱ्या
एक व्यवहार्य अंमलबजावणी योजना पुढील आर्किटेक्चर बैठकीच्या अजेंड्यावर बसणारी असावी:
- शोध घ्या: लोक, सेवा खाती (service accounts), उपकरणे, ॲप्लिकेशन्स आणि सेवांची यादी तयार करा.
- अवलंबित्व निश्चित करा (Map dependencies): डेटा प्रवाह, ऑथेंटिकेशन पद्धती, जुने निर्बंध आणि ऑपरेशनल मालक यांचे दस्तऐवजीकरण करा.
- सीमा निश्चित करा: संसाधनांच्या गरजेनुसार कर्मचारी, पाहुणे, IoT आणि भाडेकरू यांच्या ॲक्सेसचे वर्गीकरण करा.
- ओळख अधिक सुरक्षित करा (Harden identity): निर्देशिकेचा (directory) मुख्य स्रोत निवडा, MFA लागू करा आणि SSO चा वापर सुरू करा.
- मजबूत ऑथेंटिकेशन वापरा: योग्य वापरकर्ते आणि उपकरणांना पासवर्डशिवाय आणि सर्टिफिकेट-आधारित ॲक्सेसकडे वळवा.
- जीवनचक्र स्वयंचलित करा (Automate lifecycle): निर्देशिका (directory) ग्रुप्समधून तरतूद (provision) करा आणि ओळख किंवा सर्टिफिकेट बदलल्यास ॲक्सेस रद्द करा.
- स्थितीचे मूल्यांकन करा: संवेदनशील ॲक्सेस देण्यापूर्वी व्यवस्थापन, आरोग्य आणि अनुपालनाची तपासणी करा.
- सुरक्षित WiFi: कर्मचाऱ्यांच्या सामायिक पासवर्डऐवजी ओळख-बद्ध एंटरप्राइझ ऑथेंटिकेशन वापरा.
- जुन्या उपकरणांना मर्यादित करा: मर्यादित धोरणांसह अपवादात्मक उपकरणांना प्रतिबंधित विभागांमध्ये ठेवा.
- प्रथम निरीक्षण करा: प्रायोगिक धोरणे निरीक्षण मोडमध्ये चालवा, नंतर रोलबॅक निकषांसह ती लागू करा.
- सतत पडताळणी करा: नकार दिलेला ॲक्सेस, रद्दीकरण, स्थितीतील बदल आणि सेवा अपयशांची चाचणी घ्या.
- जाणूनबुजून विस्तार करा: लॉग्स, मालकी आणि सहाय्य प्रक्रिया तयार असतानाच नवीन साइट्स आणि वर्कलोड्स जोडा.
अंमलबजावणीचा सर्वात महत्त्वाचा निर्णय म्हणजे क्रमवारी ठरवणे. सर्वात जास्त दिसणाऱ्या उत्पादनापासून किंवा सर्वात मोठ्या नेटवर्क विभागापासून सुरुवात करू नका. अशा प्रवासापासून सुरुवात करा जो तुम्ही समजून घेऊ शकता, मोजू शकता आणि बदलू शकता. आदरातिथ्य (hospitality) आणि किरकोळ विक्रीसाठी (retail), याचा अर्थ थेट ठिकाणी कर्मचारी, अतिथी आणि ऑपरेशनल डिव्हाइसेस वेगळे करणे असू शकतो. आरोग्यसेवेसाठी, याचा अर्थ संवेदनशील ॲप्लिकेशनभोवती आयडेंटिटी आणि डिव्हाइस नियंत्रणांना प्राधान्य देणे असू शकतो. मल्टि - टेनंट हाउसिंगसाठी, याचा अर्थ भाडेकरू आणि इमारतीची सिस्टीम यांच्यातील अलगाव राखत रहिवाशांना सोपा प्रवेश प्रदान करणे असू शकतो.
जेव्हा एखादा प्लॅटफॉर्म स्थलांतरातील वास्तविक अडथळा दूर करत असेल तेव्हाच त्याची निवड करा. जर तुमच्या संस्थेला पासवर्डशिवाय असलेले WiFi, डिरेक्टरी-इंटिग्रेटेड कर्मचारी प्रवेश, स्वयंचलित रिव्होकेशन आणि ऑन-प्रिमाइसेस RADIUS वरील कमी अवलंबित्व आवश्यक असेल, तर Purple सारखा प्लॅटफॉर्म सध्याच्या ओळख आणि नेटवर्क आर्किटेक्चरमध्ये योग्य बसतो का याचे मूल्यांकन करा. हा निर्णय तुमच्या नियंत्रण उद्दिष्टांशी, एकत्रीकरण (integration) आवश्यकतांशी आणि ऑपरेशनल मालकीशी संबंधित ठेवा.
प्रगतीचे मोजमाप पुराव्यांद्वारे करा, डिप्लॉयमेंटच्या घोषणांद्वारे नाही. तुम्हाला हे दाखवता आले पाहिजे की कोणत्या आयडेंटिटीजकडे अ‍ॅक्सेस आहे, कोणती डिव्हाइसेस विश्वसनीय आहेत, कोणत्या पॉलिसींनी विनंत्या नाकारल्या, रिव्होकेशन किती वेगाने लागू झाले आणि कुठे अपवाद शिल्लक आहेत. अशा प्रकारे zero trust हा आणखी एक रखडलेला सुरक्षा कार्यक्रम न ठरता एक ऑपरेटिंग क्षमता बनतो.
Purple ओळख-आधारित WiFi आणि नेटवर्किंग प्रदान करते जे कर्मचारी आणि उपकरणांना विद्यमान डिरेक्टरीशी जोडते, पासवर्डशिवाय आणि प्रमाणपत्र-दर्जाच्या प्रवेशाला सपोर्ट करते, आणि डिरेक्टरीची स्थिती बदलल्यास प्रोव्हिजनिंग आणि रिव्होकेशन स्वयंचलित करू शकते. Purple चे WiFi प्रमाणीकरण, डिव्हाइस पोश्चर आणि नेटवर्क इंटिग्रेशन टप्प्याटप्प्याने zero-trust अंमलबजावणीला कसे मदत करू शकतात याचे मूल्यांकन करण्यासाठी Purple ला भेट द्या.
