एंटरप्राइझ SCEP सेटअप मार्गदर्शिका: उच्च शिक्षण आणि मोठ्या नेटवर्कसाठी प्रमाणपत्र-आधारित Wi-Fi ऑथेंटिकेशन

एंटरप्राइझ SCEP सेटअप मार्गदर्शिका: उच्च शिक्षण आणि मोठ्या नेटवर्कसाठी प्रमाणपत्र-आधारित WiFi प्रमाणीकरण एक Purple तांत्रिक माहिती - पॉडकास्ट स्क्रिप्ट (अंदाजे १० मिनिटे) --- प्रस्तावना आणि संदर्भ - अंदाजे १ मिनिट Purple तांत्रिक माहिती मालिकेमध्ये आपले स्वागत आहे. आज मी अशा एका विषयाबद्दल बोलत आहे जो बऱ्याच IT इनबॉक्समध्ये येतो पण त्यावर क्वचितच थेट उत्तर मिळते: मोठ्या प्रमाणावर प्रमाणपत्र-आधारित WiFi प्रमाणीकरण प्रत्यक्षात कसे तैनात करावे, SCEP चा वापर करून, एका मोठ्या नेटवर्कवर - मग ते विद्यापीठ कॅम्पस असो, मल्टी-साइट हॉटेल ग्रुप असो, किंवा मोठे सार्वजनिक क्षेत्रातील स्टेट असो? आम्ही संपूर्ण चित्र कव्हर करणार आहोत. SCEP प्रत्यक्षात काय करते, ते 802.1X आर्किटेक्चरमध्ये कसे बसते, बहुतांश टीम्स चुकीचा ठरणारा तैनात करण्याचा क्रम, दोन वास्तविक-जगातील अंमलबजावणीचे प्रसंग आणि अशा त्रुटी ज्यांचे नियोजन न केल्यास तुमच्या आयुष्यातील वीकेंड वाया जाऊ शकतो. ही एक सल्लागार माहिती आहे, ट्यूटोरियल नाही. मी असे गृहीत धरत आहे की तुम्हाला RADIUS सर्व्हर काय आहे हे माहित आहे आणि तुम्ही कदाचित प्री-शेअर्ड कीज वापरणे बंद करण्याचा निर्णय घेतला असेल. तुम्हाला आता गरज आहे ती अंमलबजावणीच्या नकाशाची. चला सुरुवात करूया. --- तांत्रिक सखोल माहिती - अंदाजे ५ मिनिटे तर, मूलभूत तत्त्वे. SCEP चा अर्थ Simple Certificate Enrollment Protocol असा आहे. २०२० मध्ये IETF द्वारे RFC 8894 म्हणून याला औपचारिक स्वरूप दिले गेले, जरी त्यापूर्वी एक दशकाहून अधिक काळ हे मोठ्या प्रमाणावर एंटरप्राइझमध्ये वापरात होते. याचे काम सरळ आहे: प्रत्येक मशीनला मानवी स्पर्शाची आवश्यकता न पडता व्यवस्थापित उपकरणावर डिजिटल प्रमाणपत्र मिळविण्याची प्रक्रिया स्वयंचलित करणे. WiFi प्रमाणीकरणाच्या संदर्भात, SCEP हे वितरण यंत्रणा आहे. तुम्ही लक्ष्य करत असलेला वास्तविक प्रमाणीकरण प्रोटोकॉल EAP-TLS आहे - Extensible Authentication Protocol with Transport Layer Security - जो 802.1X फ्रेमवर्कमध्ये समाविष्ट असतो. EAP-TLS ला एंटरप्राइझ वायरलेस नेटवर्कसाठी सर्वात सुरक्षित प्रमाणीकरण पद्धत मानले जाते कारण यासाठी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोघांनाही वैध प्रमाणपत्रे सादर करणे आवश्यक असते. कोणत्याही बाजूला क्रिप्टोग्राफिक पुराव्याशिवाय दुसऱ्यावर विश्वास नसतो. हे परस्पर प्रमाणीकरण तुम्हाला इव्हिल ट्विन हल्ल्यांपासून वाचवते - जेथे एखादा आक्रमणकर्ता क्रेडेन्शियल्स मिळवण्यासाठी नकली ॲक्सेस पॉइंट तयार करतो. संपूर्ण साखळी कशी काम करते ते येथे दिले आहे. एक व्यवस्थापित डिव्हाइस (managed device) - विद्यार्थ्याचा लॅपटॉप, कर्मचाऱ्याचा फोन, हॉटेलचे पॉईंट-ऑफ-सेल टर्मिनल - याला कॉर्पोरेट वायरलेस नेटवर्कमध्ये सामील होणे आवश्यक असते. तुमचे MDM प्लॅटफॉर्म, जे Microsoft Intune किंवा Jamf असू शकते, ते त्या डिव्हाइसवर SCEP पेलोड पुश करते. पेलोडमध्ये दोन गोष्टी असतात: SCEP URL, जे तुमच्या NDES सर्व्हर किंवा क्लाउड SCEP गेटवेकडे निर्देश करते, आणि एक चॅलेंज पासवर्ड किंवा शेअर केलेले गुपिते (shared secret). डिव्हाइस स्थानिक पातळीवर स्वतःची पब्लिक आणि प्रायव्हेट की पेअर (key pair) तयार करते. हे अत्यंत महत्त्वाचे आहे. प्रायव्हेट की कधीही डिव्हाइस सोडत नाही. ती ऑन-डिव्हाइस तयार केली जाते, सिक्युर एन्क्लेव्ह किंवा TPM मध्ये साठवली जाते आणि नेटवर्कवर कधीही ट्रान्समिट केली जात नाही. त्यानंतर डिव्हाइस सर्टिफिकेट साइनिंग रिक्वेस्ट - CSR - तयार करते आणि SCEP गेटवेकडे पाठवते. गेटवे चॅलेंज व्हॅलिडेट करतो, CSR तुमच्या सर्टिफिकेट ऑथॉरिटीकडे (CA) फॉरवर्ड करतो आणि CA त्यावर स्वाक्षरी करून पब्लिक सर्टिफिकेट डिव्हाइसला परत करतो. त्या क्षणापासून, जेव्हा डिव्हाइस तुमच्या WiFi SSID शी कनेक्ट होते, तेव्हा ते RADIUS सर्व्हरला ते सर्टिफिकेट सादर करते. RADIUS सर्व्हर तुमच्या CA च्या ट्रस्ट चेनच्या विरुद्ध सर्टिफिकेटचे प्रमाणीकरण करतो, सर्टिफिकेट रद्द केले गेले नाही याची खात्री करण्यासाठी सर्टिफिकेट रिव्होकेशन लिस्ट (Certificate Revocation List) तपासतो आणि सर्व काही व्यवस्थित असल्यास, ॲक्सेस पॉइंटला एक्सेप्ट मेसेज पाठवतो. डिव्हाइस नेटवर्कवर येते. ही संपूर्ण प्रक्रिया वापरकर्त्यासाठी अदृश्य असते. आता, पर्यायी पर्याय असलेल्या PKCS च्या तुलनेत SCEP कुठे बसते याबद्दल बोलूया. PKCS - पब्लिक की क्रिप्टोग्राफी स्टँडर्ड्स - ही Intune सारख्या प्लॅटफॉर्मद्वारे समर्थित असलेली इतर सर्टिफिकेट डिलिव्हरी पद्धत आहे. PKCS सह, CA मध्यवर्ती पातळीवर पब्लिक आणि प्रायव्हेट दोन्ही की तयार करतो आणि सर्टिफिकेट कनेक्टर की पेअर डिव्हाइसवर पुश करतो. याचा अर्थ प्रायव्हेट की नेटवर्कवरून प्रवास करते, ज्यामुळे एक सैद्धांतिक हल्ला क्षेत्र (attack surface) निर्माण होते. S/MIME ईमेल एन्क्रिप्शन सारख्या वापर प्रकरणांसाठी PKCS ठीक आहे जिथे की एस्क्रो प्रत्यक्षात इष्ट असते. WiFi ऑथेंटिकेशनसाठी, SCEP हाच योग्य पर्याय आहे. प्रायव्हेट की डिव्हाइसवरच राहते, विषय संपला. आता, हार्डवेअर लेयर. SCEP आणि EAP-TLS हे वेंडर-न्यूट्रल स्टँडर्ड्स आहेत, ज्याचा अर्थ ते Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet ॲक्सेस पॉइंट्सवर काम करतात. तुमचे RADIUS कॉन्फिगरेशन - मग ते Windows NPS असो, FreeRADIUS असो किंवा क्लाउड RADIUS सर्व्हिस असो - तिथेच तुम्ही सर्टिफिकेट व्हॅलिडेशन पॉलिसी परिभाषित करता आणि महत्त्वाचे म्हणजे, तिथेच तुम्ही डायनॅमिक VLAN असाइनमेंट कॉन्फिगर करता. डायनॅमिक VLAN हे ओळखीनुरूप तुम्ही नेटवर्कचे विभाजन कसे करता यावर आधारित असते. विद्यार्थ्याच्या डिव्हाइसला VLAN 20 मिळते - फक्त इंटरनेट ॲक्सेस. प्राध्यापकांच्या डिव्हाइसला VLAN 10 मिळते - अंतर्गत संशोधन प्रणालींमध्ये ॲक्सेस. फॅसिलिटीज मॅनेजमेंट डिव्हाइसला VLAN 30 मिळते - बिल्डिंग मॅनेजमेंट सिस्टम्समध्ये ॲक्सेस. हे सर्व सर्टिफिकेटच्या वैशिष्ट्यांद्वारे आणि RADIUS पॉलिसीद्वारे चालवले जाते, ज्यामध्ये प्रति डिव्हाइस कोणत्याही मॅन्युअल हस्तक्षेपाची आवश्यकता नसते. आयडेंटिटी प्रोव्हाइडर इंटिग्रेशनसाठी, SCEP सर्टिफिकेट ॲट्रिब्युट्स - विशेषतः Subject Alternative Name - Microsoft Entra ID, Okta किंवा Google Workspace कडून युझरचे प्रिन्सिपल नाव घेऊन जाऊ शकतात. यामुळे सर्टिफिकेट विशिष्ट आयडेंटिटीशी जोडले जाते, ज्याचा अर्थ असा होतो की जेव्हा तुम्ही Entra ID मधील एखादे खाते बंद करता आणि MDM डिव्हाइस अन-एनरोल करते, तेव्हा सर्टिफिकेट रद्द केले जाते आणि WiFi ऍक्सेस आपोआप बंद होतो. हा असा रिव्होकेशन (रद्द करण्याची) इतिहास आहे जो प्री-शेअर्ड की (pre-shared keys) कधीच देऊ शकत नाहीत. --- अमलबजावणीच्या शिफारसी आणि धोके (IMPLEMENTATION RECOMMENDATIONS AND PITFALLS) - साधारण २ मिनिटे चला, आता डिप्लॉयमेंटच्या क्रमाबद्दल बोलूया, कारण येथेच बहुतेक टीम्सची गल्लत होते. हा क्रम बदलता येणारा नाही: आधी Trusted Root सर्टिफिकेट, नंतर SCEP सर्टिफिकेट प्रोफाईल आणि तिसरे WiFi प्रोफाईल. Intune आणि Jamf दोन्ही प्रोफाईलच्या परस्परावलंबित्वाची अंमलबजावणी करतात. जर तुमचे WiFi प्रोफाईल अशा SCEP सर्टिफिकेटचा संदर्भ देत असेल जे डिव्हाइसवर अद्याप डिप्लॉय केलेले नाही, तर WiFi प्रोफाईल एका अस्पष्ट एररसह अयशस्वी होईल जी चुकीच्या कॉन्फिगरेशनसारखी दिसते, परंतु प्रत्यक्षात ती केवळ वेळेची (timing) समस्या असते. दुसरा धोका म्हणजे ग्रुप टारगेटिंग. Trusted Root, SCEP आणि WiFi हे तिन्ही प्रोफाईल्स अगदी एकाच Azure AD किंवा Jamf ग्रुपवर डिप्लॉय केले जाणे आवश्यक आहे. SCEP प्रोफाईल युझर ग्रुपला टार्गेट करत असेल आणि WiFi प्रोफाईल डिव्हाइस ग्रुपला टार्गेट करत असेल, तर Intune हे परस्परावलंबित्व सोडवू शकत नाही आणि WiFi प्रोफाईल "Not Applicable" म्हणून दर्शवले जाईल. यामुळे टीम्स सतत अडचणीत येतात. तिसरे: NDES सर्व्हर उपलब्धता. तुमचा NDES सर्व्हर इंटरनेटवरून ऍक्सेस करता येण्याजोगा असणे आवश्यक आहे जेणेकरून डिव्हाइसेस ऑन-साइट येण्यापूर्वी एनरोल होऊ शकतील. हे करण्याचा योग्य मार्ग Azure AD Application Proxy द्वारे आहे, तुमच्या फायरवॉलमध्ये छिद्र पाडून नाही. App Proxy तुम्हाला इनबाउंड पोर्ट्सशिवाय सुरक्षित रिमोट ऍक्सेस देते आणि एनरोलमेंट फ्लोवर कंडीशनल ऍक्सेस पॉलिसी लागू करण्याची परवानगी देते. चौथे: CRL उपलब्धता. तुमचा RADIUS सर्व्हर प्रत्येक वेळी डिव्हाइस ऑथेंटिकेट करताना Certificate Revocation List तपासतो. जर तुमचा CRL डिस्ट्रिब्युशन पॉईंट अनुपलब्ध असेल - सर्व्हर डाउन असल्यामुळे किंवा URL बदलल्यामुळे - तर नेटवर्कवरील प्रत्येक डिव्हाइससाठी ऑथेंटिकेशन एकाच वेळी अयशस्वी होते. हा संपूर्ण कॅम्पसचा आउटेज ठरू शकतो. तुमचे CRL एंडपॉईंट्स अत्यंत उपलब्ध (highly available) ठेवा आणि लाइव्ह जाण्यापूर्वी रिव्होकेशनची चाचणी घ्या. मोठ्या नेटवर्कसाठी - ५०० पेक्षा जास्त डिव्हाइसेससाठी - ऑन-प्रिमाइसेस NDES ऐवजी क्लाउड SCEP गेटवेचा विचार करा. क्लाउड गेटवे NDES च्या सिंगल पॉईंट ऑफ फेल्युअरची शक्यता दूर करतात, हॉरिझॉन्टली स्केल होतात आणि सामान्यतः थेट क्लाउड RADIUS सेवांशी जोडले जातात, ज्यामुळे आणखी एक इन्फ्रास्ट्रक्चर वरील अवलंबित्व कमी होते. --- रॅपिड-फायर प्रश्नोत्तरे (RAPID-FIRE Q AND A) - साधारण १ मिनिट SCEP अशा BYOD डिव्हाइसेस हाताळू शकते का जे MDM-एनरोल केलेले नाहीत? थेट नाही. SCEP ला सर्टिफिकेट पेलोड पुश करण्यासाठी MDM एनरोलमेंटची आवश्यकता असते. अनमॅनेज्ड BYOD साठी, तुम्हाला वेगळा दृष्टिकोन हवा आहे - एकतर सेल्फ-सर्व्हिस ऑनबोर्डिंग पोर्टल, किंवा आयडेंटिटी व्हेरिफिकेशनसह Captive Portal वापरणारा स्वतंत्र SSID. Purple चे प्लॅटफॉर्म तुमच्या सर्टिफिकेट-ऑथेंटिकेटेड स्टाफ नेटवर्कसह राहून तो गेस्ट आणि BYOD लेयर अगदी सुलभपणे हाताळते. iOS आणि Android बद्दल काय? दोन्ही प्लॅटफॉर्म्स मूळतः SCEP ला सपोर्ट करतात. iOS ने iOS 4 पासून SCEP ला सपोर्ट केला आहे. Android Enterprise हे Intune आणि इतर MDMs द्वारे SCEP ला सपोर्ट करते. कॉन्फिगरेशन प्रत्येक प्लॅटफॉर्मनुसार थोडे वेगळे असते परंतु त्यामागील प्रोटोकॉल समान असतो. EAP-TLS हे WPA3 सोबत काम करते का? होय. WPA3-Enterprise संवेदनशील वातावरणासाठी १९२-बिट सुरक्षा मोड अनिवार्य करते आणि EAP-TLS पूर्णपणे सुसंगत आहे. खरं तर, सरकारी आणि वित्तीय नेटवर्कसाठी Wi-Fi Alliance द्वारे EAP-TLS सह WPA3-Enterprise च्या कॉम्बिनेशनची शिफारस केली जाते. --- सारांश आणि पुढील पायऱ्या - अंदाजे १ मिनिट थोडक्यात सांगायचे तर. ५० पेक्षा जास्त व्यवस्थापित (managed) उपकरणे असलेल्या कोणत्याही नेटवर्कसाठी SCEP प्रमाणपत्र WiFi प्रमाणीकरण (authentication) हे योग्य आर्किटेक्चर आहे. हे शेअर्ड क्रेडेंशियलची आवश्यकता दूर करते, तुम्हाला प्रत्येक उपकरणाची ओळख (per-device identity) देते, डायनॅमिक VLAN सेगमेंटेशन सक्षम करते आणि स्वयंचलित रिव्होकेशनसाठी थेट तुमच्या ओळख प्रदात्याशी (identity provider) समाकलित होते. डिप्लॉयमेंटचा क्रम - Trusted Root, नंतर SCEP प्रोफाइल, आणि नंतर WiFi प्रोफाइल - निश्चित आहे. ग्रुप टार्गेटिंग सुसंगत असणे आवश्यक आहे. CRL उपलब्धता पर्यायी नाही. विशेषतः उच्च शिक्षणासाठी, कर्मचारी आणि फॅकल्टी उपकरणांसाठी SCEP चे कॉम्बिनेशन, आणि वैयक्तिक उपकरणांवरील विद्यार्थ्यांसाठी वेगळ्या गेस्ट WiFi लेयरसह, तुम्हाला कोणतीही तडजोड न करता सुरक्षा आणि उत्तम वापरकर्ता अनुभव (user experience) दोन्ही प्रदान करते. जर तुम्हाला अधिक सखोल माहिती हवी असेल, तर Active Directory किंवा ऑन-प्रिमायसेस सर्व्हरशिवाय असणाऱ्या एंटरप्राइझ WiFi प्रमाणीकरणावरील Purple चे मार्गदर्शक क्लाउड-नेटिव्ह पाथ कव्हर करते. आणि जेव्हा एखादा कर्मचारी नोकरी सोडतो तेव्हा काय होते याचा विचार तुम्ही करत असाल, तर WiFi ऍक्सेस रद्द करण्यावरील (revoking) आमचे मार्गदर्शक संपूर्ण रिव्होकेशन वर्कफ्लो स्पष्ट करते. ऐकल्याबद्दल धन्यवाद. मी Purple च्या तांत्रिक टीममधून आहे, आणि आपण पुढील ब्रीफिंगमध्ये भेटू. --- स्क्रिप्ट समाप्त