सुरक्षित BYOD आणि 802.1X नेटवर्क ऑथेंटिकेशनसाठी SCEP कसे कॉन्फिगर करावे

नमस्कार, आणि Purple च्या या तांत्रिक ब्रीफिंगमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण SCEP - म्हणजेच सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल - आणि सुरक्षित BYOD आणि 802.1X नेटवर्क ऑथेंटिकेशनसाठी ते योग्यरित्या कसे कॉन्फिगर करावे याबद्दल सविस्तर माहिती घेणार आहोत. जर तुम्ही IT मॅनेजर, नेटवर्क आर्किटेक्ट किंवा हॉटेल ग्रुप, रिटेल इस्टेट, स्टेडियम किंवा सार्वजनिक क्षेत्रातील संस्थेमधील WiFi इन्फ्रास्ट्रक्चरसाठी जबाबदार असलेले CTO असाल, तर हे थेट तुमच्याशी संबंधित आहे. आज आपण केवळ सिद्धांतावर बोलणार नाही, तर आपण आर्किटेक्चर आणि निर्णयांबद्दल बोलणार आहोत. चला तर मग, सुरुवात करूया. [SECTION: Introduction and Context - approximately 1 minute] तुम्हाला कदाचित भेडसावणारी समस्या ही आहे: तुमच्याकडे स्टाफची डिव्हाइसेस, कंत्राटदारांचे लॅपटॉप आणि वैयक्तिक फोन्स आहेत ज्यांना नेटवर्क प्रवेशाची आवश्यकता आहे. तुमच्याकडे मॅनेज्ड आणि अनमॅनेज्ड डिव्हाइसेसचे मिश्रण असू शकते. आणि तुमच्या इन्फ्रास्ट्रक्चरमध्ये कुठेतरी अजूनही एक सामायिक केलेला WPA2 प्री-शेअर्ड की पासवर्ड आहे जो बारा लोकांना माहित आहे, ज्यापैकी तीन जणांनी गेल्या वर्षीच कंपनी सोडली आहे. हे सुरक्षिततेचे लक्षण नाही, तर ही एक मोठी जोखीम आहे. याचे उत्तर आहे 802.1X - पोर्ट-आधारित नेटवर्क ऍक्सेस कंट्रोलसाठीचे IEEE मानक. हे सुनिश्चित करते की जोपर्यंत कोणत्याही डिव्हाइसचे स्पष्टपणे ऑथेंटिकेशन होत नाही, तोपर्यंत ते ट्रॅफिक पाठवू शकत नाही. परंतु 802.1X हे केवळ एक फ्रेमवर्क आहे. खरा प्रश्न हा आहे की त्यामध्ये कोणती ऑथेंटिकेशन पद्धत वापरली जाते. आणि मोठ्या प्रमाणावर BYOD साठी, याचे उत्तर SCEP द्वारे प्रोव्हिजन केलेल्या सर्टिफिकेट्ससह EAP-TLS हे आहे. आज आपण याच विषयाचा सविस्तर आढावा घेणार आहोत. [SECTION: Technical Deep-Dive - approximately 5 minutes] चला तर मग, SCEP नेमके काय करते यापासून सुरुवात करूया. SCEP - सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल - मूळतः १९९९ मध्ये VeriSign द्वारे तयार करण्यात आला होता आणि IETF द्वारे इंटरनेट ड्राफ्ट म्हणून प्रकाशित करण्यात आला होता. याला RFC 8894 म्हणून औपचारिक रूप देण्यात आले. याचे काम अगदी सोपे आहे: मानवी हस्तक्षेपाशिवाय मोठ्या प्रमाणावर डिव्हाइसेसना X.509 डिजिटल सर्टिफिकेट्स जारी करण्याची आणि व्यवस्थापित करण्याची प्रक्रिया स्वयंचलित करणे. याचे चार टप्पे खालीलप्रमाणे आहेत. पहिला टप्पा: डिव्हाइस SCEP एंडपॉईंटशी कनेक्ट होते - ही एक URL असते जी एकतर NDES (नेटवर्क डिव्हाइस एनरोलमेंट सर्व्हिस) नावाच्या Windows Server रोलद्वारे ऑन-प्रिमाइसेस होस्ट केली जाते किंवा क्लाउड PKI प्रदात्याद्वारे होस्ट केली जाते. ही URL तुमच्या सर्टिफिकेट ऑथॉरिटीचे प्रवेशद्वार आहे. दुसरा टप्पा: डिव्हाइस एक SCEP चॅलेंज सादर करते - हा एक सामायिक गुप्त कोड (shared secret) असतो जो हे सिद्ध करतो की ते सर्टिफिकेटची विनंती करण्यासाठी अधिकृत आहे. Microsoft Intune सारख्या MDM-मॅनेज्ड वातावरणात, हे चॅलेंज प्रत्येक डिव्हाइससाठी डायनॅमिक आणि युनिक पद्धतीने दिले जाते, जे सर्व डिव्हाइसेसमध्ये सामायिक केलेल्या स्टॅटिक पासवर्डपेक्षा कितीतरी पतीने अधिक सुरक्षित आहे. तिसरा टप्पा: डिव्हाइस स्थानिक पातळीवर स्वतःची प्रायव्हेट आणि पब्लिक की पेअर तयार करते. ते पब्लिक की चा वापर करून सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR) तयार करते आणि ती SCEP सर्व्हरला पाठवते. येथे सर्वात महत्त्वाचा सुरक्षिततेचा मुद्दा असा आहे की: प्रायव्हेट की कधीही डिव्हाइस सोडत नाही. ती स्थानिक पातळीवर तयार केली जाते आणि डिव्हाइसच्या सुरक्षित एन्क्लेव्हमध्ये (जसे की Windows वरील TPM किंवा iOS वरील Secure Enclave) संग्रहित केली जाते आणि ती कधीही ट्रान्समिट केली जात नाही. म्हणूनच नेटवर्क ऑथेंटिकेशनसाठी SCEP हा योग्य पर्याय आहे, PKCS नाही, जिथे CA मध्यवर्ती ठिकाणी की तयार करतो आणि ती डिव्हाइसवर पुश करावी लागते. चौथा टप्पा: सर्टिफिकेट ऑथॉरिटी CSR ची पडताळणी करते, त्यावर CA च्या प्रायव्हेट की ने स्वाक्षरी करते आणि स्वाक्षरी केलेले X.509 सर्टिफिकेट डिव्हाइसला परत करते. आता डिव्हाइसकडे एक युनिक क्रिप्टोग्राफिक ओळख आहे. आता, या सर्टिफिकेटचा वापर 802.1X ऑथेंटिकेशनसाठी कसा केला जातो? जेव्हा डिव्हाइस तुमच्या WiFi SSID शी कनेक्ट होते, तेव्हा ऍक्सेस पॉईंट (मग तो Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist किंवा Ubiquiti UniFi असो) ऑथेंटिकेटर म्हणून काम करतो. तो स्वतः ऑथेंटिकेशनचा निर्णय घेत नाही. तो EAP एक्सचेंज तुमच्या RADIUS सर्व्हरकडे पाठवतो. तो सर्व्हर Microsoft NPS, Cisco ISE किंवा Aruba ClearPass असू शकतो. RADIUS सर्व्हर EAP-TLS हँडशेक सुरू करतो. डिव्हाइस त्याचे SCEP-प्रोव्हिजन केलेले क्लायंट सर्टिफिकेट सादर करते. RADIUS सर्व्हर तीन गोष्टींची पडताळणी करतो: विश्वसनीय रूट CA पर्यंतची सर्टिफिकेट चेन, सर्टिफिकेट संपण्याची तारीख (expiry date), आणि सर्टिफिकेट रद्द (revoke) केले गेले आहे की नाही - हे सर्टिफिकेट रिव्होकेशन लिस्ट (CRL) किंवा OCSP (ऑनलाइन सर्टिफिकेट स्टेटस प्रोटोकॉल) द्वारे तपासले जाते. जर या तिन्ही चाचण्या यशस्वी झाल्या, तर RADIUS सर्व्हर EAP-Success संदेश पाठवतो आणि ऍक्सेस पॉईंट पोर्ट उघडतो. डिव्हाइस नेटवर्कवर कनेक्ट होते. हे म्युच्युअल ऑथेंटिकेशन आहे. डिव्हाइस देखील RADIUS सर्व्हरच्या सर्टिफिकेटची पडताळणी करते. जर कोणी बनावट (rogue) ऍक्सेस पॉईंट सेट केला, तर डिव्हाइस ते नाकारेल कारण सर्व्हर सर्टिफिकेट विश्वसनीय CA शी जुळणार नाही. हे तुमचे इव्हिल ट्विन हल्ल्यांपासून संरक्षण करते. आता आपण Microsoft Intune मधील उपयोजन क्रमाबद्दल बोलूया, कारण एंटरप्राइझ वातावरणात आपल्याला आढळणारे हे सर्वात सामान्य MDM प्लॅटफॉर्म आहे. तुम्ही तीन Intune कॉन्फिगरेशन प्रोफाईल्स अत्यंत कठोर क्रमाने उपयोजित करता. पहिले, Trusted Root Certificate प्रोफाईल - हे तुमचे रूट CA सर्टिफिकेट प्रत्येक डिव्हाइसवर पुश करते जेणेकरून ते तुमच्या PKI वर विश्वास ठेवतील. दुसरे, SCEP Certificate प्रोफाईल - हे डिव्हाइसेसना SCEP URL, सब्जेक्ट नेम फॉरमॅट, की युसेज आणि क्लायंट ऑथेंटिकेशनसाठी एक्सटेंडेड की युसेज सांगते. क्लायंट ऑथेंटिकेशनसाठी OID 1.3.6.1.5.5.7.3.2 आहे. तिसरे, WiFi प्रोफाईल - हे SSID निर्दिष्ट करते, सुरक्षा प्रकार WPA2-Enterprise किंवा WPA3-Enterprise वर सेट करते, EAP प्रकार EAP-TLS वर सेट करते आणि SCEP सर्टिफिकेट प्रोफाईलशी लिंक करते. हा क्रम खूप महत्त्वाचा आहे. WiFi प्रोफाईल SCEP प्रोफाईलवर अवलंबून असते, जे Trusted Root प्रोफाईलवर अवलंबून असते. जर तुम्ही हे चुकीच्या क्रमाने उपयोजित केले तर तुम्हाला एरर्स येतील. तुम्हाला घ्यावा लागणारा एक आर्किटेक्चरल निर्णय म्हणजे NDES सर्व्हर कुठे होस्ट करायचा. तो इंटरनेटवरून पोहोचण्यायोग्य असणे आवश्यक आहे जेणेकरून डिव्हाइसेस ऑन-साइट येण्यापूर्वी नोंदणी करू शकतील. हे सुरक्षितपणे करण्याचा मार्ग म्हणजे Microsoft Entra ID Application Proxy द्वारे NDES URL प्रकाशित करणे. यामुळे इनबाउंड फायरवॉल पोर्ट्स उघडणे टाळता येते आणि तुम्हाला नोंदणी प्रवाहावर कंडिशनल ऍक्सेस पॉलिसी लागू करण्याची परवानगी मिळते. ज्या संस्थांना ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर पूर्णपणे काढून टाकायचे आहे, त्यांच्यासाठी क्लाउड PKI प्रदाते (Intune मधील Microsoft चे स्वतःचे Cloud PKI किंवा थर्ड-पार्टी पर्याय) NDES ची आवश्यकता पूर्णपणे काढून टाकतात. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] आता मी तुम्हाला तीन सर्वात सामान्य त्रुटी सांगतो ज्या आपल्याला वारंवार पाहायला मिळतात. पहिली त्रुटी: ग्रुप टार्गेटिंगमधील विसंगती (mismatch). Intune मध्ये WiFi प्रोफाईल उपयोजन अपयशी ठरण्याचे हे सर्वात वारंवार घडणारे कारण आहे. जर तुमचे Trusted Root प्रोफाईल User ग्रुपला, तुमचे SCEP प्रोफाईल Device ग्रुपला आणि तुमचे WiFi प्रोफाईल वेगळ्या User ग्रुपला नियुक्त केले असेल, तर Intune डिपेंडन्सी चेन सोडवू शकत नाही. तिन्ही प्रोफाईल्सनी तंतोतंत एकाच Azure AD ग्रुपला (एकतर सर्व युझर्स किंवा सर्व डिव्हाइसेस) लक्ष्य केले पाहिजे. एक निवडा आणि त्यावर ठाम राहा. दुसरी त्रुटी: CRL ची उपलब्धता. सर्टिफिकेट्स रद्द तर झालेली नाहीत ना हे तपासण्यासाठी तुमचा RADIUS सर्व्हर CRL तपासतो. जर CRL डिस्ट्रिब्युशन पॉईंट - म्हणजेच सर्टिफिकेटमध्ये एम्बेड केलेली CDP URL - पोहोचण्यायोग्य नसेल, तर प्रत्येक डिव्हाइससाठी ऑथेंटिकेशन अपयशी ठरते. नेटवर्क बदलांनंतर मोठ्या प्रमाणावर आउटेज होण्याचे हे एक सामान्य कारण आहे. तुमचे CDPs अत्यंत उपलब्ध असतील याची खात्री करा, आदर्शपणे ते अंतर्गत URL आणि रिमोट डिव्हाइसेससाठी बाह्य URL अशा दोन्हीवर प्रकाशित करा. CRL चेकिंगला अधिक लवचिक पर्याय म्हणून OCSP चा विचार करा. तिसरी त्रुटी: क्लायंटवर सर्व्हर सर्टिफिकेट व्हॅलिडेशन सक्तीचे न करणे. 802.1X उपयोजनांमधील ही सर्वात मोठी चुकीची कॉन्फिगरेशन आहे. जर तुमच्या MDM-उपयोजित WiFi प्रोफाईलमध्ये विश्वसनीय CA आणि अपेक्षित RADIUS सर्व्हरचे नाव निर्दिष्ट केलेले नसेल, तर डिव्हाइसेस कोणत्याही सर्टिफिकेट सादर करणाऱ्या कोणत्याही सर्व्हरशी कनेक्ट होतील. यामुळे EAP-TLS चा संपूर्ण उद्देशच नष्ट होतो. तुमच्या WiFi प्रोफाईलमध्ये नेहमी सर्व्हर व्हॅलिडेशन कॉन्फिगर करा. [SECTION: Rapid-Fire Q and A - approximately 1 minute] चला काही जलद प्रश्नोत्तरे घेऊया. प्रश्न: आम्हाला WPA3 ची गरज आहे का? होय. WPA3-Enterprise वर स्थलांतरित व्हा. हे प्रोटेक्टेड मॅनेजमेंट फ्रेम्स (PMF) अनिवार्य करते, जे डी-ऑथेंटिकेशन हल्ल्यांना प्रतिबंधित करते. Cisco Meraki, HPE Aruba, Ruckus आणि Juniper Mist मधील सर्व हार्डवेअर याला सपोर्ट करतात. प्रश्न: 802.1X ला सपोर्ट न करणाऱ्या डिव्हाइसेसचे (उदा. IoT सेन्सर्स किंवा जुने प्रिंटर) काय करायचे? बॅकअप म्हणून MAC Authentication Bypass चा वापर करा, परंतु त्या डिव्हाइसेसना अत्यंत मर्यादित VLAN वर ठेवा जिथून कॉर्पोरेट संसाधनांना कोणताही प्रवेश नसेल. प्रश्न: यामध्ये Purple कसे बसते? Purple चे Guest WiFi प्लॅटफॉर्म अभ्यागत आणि पाहुण्यांच्या प्रवेशाचा स्तर हाताळते - जसे की Captive Portal, डेटा कॅप्चर, ऍनालिटिक्स. तुमचे 802.1X आणि SCEP इन्फ्रास्ट्रक्चर स्टाफ आणि मॅनेज्ड डिव्हाइसचा प्रवेश हाताळते. ते वेगवेगळ्या SSIDs आणि वेगवेगळ्या VLANs वर चालतात. Purple हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सोबत समाकलित (integrate) होते - त्यामुळे तुमच्या हार्डवेअरमधील गुंतवणुकीचे संरक्षण होते. [SECTION: Summary and Next Steps - approximately 1 minute] थोडक्यात सांगायचे तर. SCEP मोठ्या प्रमाणावर सर्टिफिकेट जारी करण्याची प्रक्रिया स्वयंचलित करते. प्रायव्हेट की डिव्हाइसवरच राहते - हा PKCS पेक्षा मोठा सुरक्षा फायदा आहे. MDM द्वारे कठोर क्रमाने उपयोजित करा: आधी Trusted Root, नंतर SCEP प्रोफाईल, नंतर WiFi प्रोफाईल, सर्व एकाच ग्रुपला लक्ष्य करून. Application Proxy द्वारे NDES प्रकाशित करा किंवा क्लाउड PKI कडे वळा. तुमच्या RADIUS सर्व्हरवर CRL किंवा OCSP चेकिंग सक्तीचे करा. आणि नेहमी क्लायंट सप्लिकंट्सवर सर्व्हर सर्टिफिकेट व्हॅलिडेशन कॉन्फिगर करा. जर तुम्ही अजूनही स्टाफ WiFi साठी सामायिक केलेला पासवर्ड वापरत असाल, तर या तिमाहीत हा बदल नक्की करा. सर्टिफिकेट इन्फ्रास्ट्रक्चरसाठी सुरुवातीला जास्त काम करावे लागते, परंतु ते क्रेडेंशियल-आधारित हल्ल्यांचा संपूर्ण प्रकारच नष्ट करते आणि उपयोजनानंतर सामान्यतः WiFi-संबंधित हेल्पडेस्क तिकिटे ७० ते ८० टक्क्यांनी कमी करते. पूर्ण तांत्रिक मार्गदर्शक, आर्किटेक्चर डायग्राम्स आणि उदाहरणांसाठी, purple dot ai ला भेट द्या. ऐकल्याबद्दल धन्यवाद.