स्वयंचलित Enterprise WiFi प्रमाणपत्र नावनोंदणीसाठी SCEP कसे कॉन्फिगर करावे

हे मार्गदर्शक स्वयंचलित enterprise WiFi प्रमाणपत्र नावनोंदणीसाठी SCEP (Simple Certificate Enrollment Protocol) कसे कॉन्फिगर करावे हे स्पष्ट करते, ज्यामध्ये PKI आणि NDES पासून ते MDM प्रोफाइल उपयोजन आणि RADIUS प्रमाणीकरणापर्यंतच्या संपूर्ण आर्किटेक्चरचा समावेश आहे. हे हॉटेल्स, रिटेल चेन्स, स्टेडियम, कॉन्फरन्स सेंटर्स आणि सार्वजनिक क्षेत्रातील संस्थांमधील आयटी व्यवस्थापक, नेटवर्क आर्किटेक्ट्स आणि CTOs ना उद्देशून आहे ज्यांना प्री-शेअर्ड कीजच्या पलीकडे जाऊन स्केलेबल, ओळख-आधारित 802.1X EAP-TLS प्रमाणीकरण लागू करायचे आहे. Purple चे हार्डवेअर-अज्ञेयवादी, क्लाउड ओव्हरले प्लॅटफॉर्म थेट या आर्किटेक्चरसह समाकलित होते, जे तुमच्या प्रमाणपत्र-प्रमाणित कर्मचारी नेटवर्कसह गेस्ट आणि BYOD WiFi स्तर प्रदान करते.

📖 10 मिनिट वाचन📝 2,282 शब्द🔧 2 सोडवलेली उदाहरणे❓ 3 सराव प्रश्न📚 9 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा

Purple Technical Briefing सिरीजमध्ये आपले स्वागत आहे. आज मी अशा विषयावर बोलत आहे जो अनेक IT इनबॉक्सेसमध्ये येतो परंतु त्यावर क्वचितच थेट उत्तर मिळते: SCEP चा वापर करून, मोठ्या नेटवर्कवर प्रत्यक्षात सर्टिफिकेट-आधारित WiFi ऑथेंटिकेशन मोठ्या प्रमाणावर कसे तैनात (deploy) करावे. मग ते विद्यापीठाचे कॅम्पस असो, मल्टि-साइट हॉटेल ग्रुप असो किंवा मोठे सार्वजनिक क्षेत्रातील इस्टेट असो, आव्हाने अगदी सारखीच असतात.

आम्ही संपूर्ण चित्र कव्हर करणार आहोत. SCEP प्रत्यक्षात काय करते, ते 802.1X आर्किटेक्चरमध्ये कसे बसते, डिप्लॉयमेंटचा असा क्रम जो बहुतेक टीम्स चुकवतात, दोन वास्तविक-जगातील अंमलबजावणीची उदाहरणे आणि अशा त्रुटी ज्यांचे नियोजन न केल्यास तुमचे वीकेंडचे नियोजन बिघडू शकते.

हे एक कन्सल्टंट ब्रीफिंग आहे, ट्युटोरियल नाही. मी असे गृहीत धरत आहे की तुम्हाला RADIUS सर्व्हर काय आहे हे माहित आहे आणि तुम्ही कदाचित आधीच प्री-शेअर्ड कीजपासून दूर जाण्याचा निर्णय घेतला आहे. तुम्हाला आता गरज आहे ती अंमलबजावणीच्या नकाशाची (implementation map).

चला सुरुवात करूया.

पहिले तत्व. SCEP म्हणजे Simple Certificate Enrollment Protocol. २०२० मध्ये IETF द्वारे RFC 8894 म्हणून याला औपचारिक रूप देण्यात आले होते, जरी त्यापूर्वी एक दशकाहून अधिक काळ एंटरप्राइझमध्ये याचा मोठ्या प्रमाणावर वापर केला जात होता. याचे काम अगदी सोपे आहे: कोणत्याही व्यक्तीने प्रत्येक मशीनला स्पर्श न करता, मॅनेज्ड डिव्हाइसवर डिजिटल सर्टिफिकेट मिळवण्याची प्रक्रिया स्वयंचलित (automate) करणे.

WiFi ऑथेंटिकेशनच्या संदर्भात, SCEP हे डिलिव्हरी मेकॅनिझम आहे. तुम्ही ज्या वास्तविक ऑथेंटिकेशन प्रोटोकॉलला लक्ष्य करत आहात तो EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) आहे, जो 802.1X फ्रेमवर्कमध्ये समाविष्ट असतो. EAP-TLS ला एंटरप्राइझ वायरलेस नेटवर्कसाठी सर्वात सुरक्षित ऑथेंटिकेशन पद्धत मानले जाते कारण यासाठी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोघांनाही वैध सर्टिफिकेट्स सादर करणे आवश्यक असते. क्रिप्टोग्राफिक पुराव्याशिवाय दोन्हीपैकी कोणतीही बाजू दुसऱ्यावर विश्वास ठेवत नाही. हे परस्पर ऑथेंटिकेशन (mutual authentication) तुमचे 'इव्हिल ट्विन' हल्ल्यांपासून संरक्षण करते, जिथे एखादा हॅकर क्रेडेंशियल्स चोरण्यासाठी बनावट ॲक्सेस पॉइंट तयार करतो.

ही संपूर्ण साखळी कशी कार्य करते ते येथे आहे. एका मॅनेज्ड डिव्हाइसला, जसे की विद्यार्थ्याचा लॅपटॉप, कर्मचाऱ्याचा फोन किंवा हॉटेलचा पॉइंट-ऑफ-सेल टर्मिनल, कॉर्पोरेट वायरलेस नेटवर्कमध्ये सामील व्हायचे आहे. तुमचे MDM प्लॅटफॉर्म, जे Microsoft Intune किंवा Jamf असू शकते, त्या डिव्हाइसवर SCEP पेलोड पाठवते. या पेलोडमध्ये दोन गोष्टी असतात: SCEP URL, जी तुमच्या NDES सर्व्हर किंवा क्लाउड SCEP गेटवेकडे निर्देश करते, आणि एक चॅलेंज पासवर्ड किंवा शेअर्ड सिक्रेट.

डिव्हाइस स्थानिक पातळीवर स्वतःची पब्लिक आणि प्रायव्हेट की जोडी (key pair) तयार करते. हे अत्यंत महत्त्वाचे आहे. प्रायव्हेट की कधीही डिव्हाइस सोडत नाही. ती डिव्हाइसवरच तयार केली जाते, सिक्युर एन्क्लेव्ह किंवा TPM मध्ये सुरक्षित ठेवली जाते आणि नेटवर्कवर कधीही ट्रान्समिट केली जात नाही. त्यानंतर डिव्हाइस सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR) तयार करते आणि SCEP गेटवेकडे पाठवते. गेटवे चॅलेंज प्रमाणित करतो, CSR तुमच्या सर्टिफिकेट ऑथॉरिटीकडे (CA) पाठवतो आणि CA त्यावर स्वाक्षरी करून पब्लिक सर्टिफिकेट डिव्हाइसला परत करतो.
त्या क्षणापासून, जेव्हा डिव्हाइस तुमच्या WiFi SSID शी कनेक्ट होते, तेव्हा ते RADIUS सर्व्हरला ते प्रमाणपत्र सादर करते. RADIUS सर्व्हर तुमच्या CA ट्रस्ट चेनच्या विरूद्ध प्रमाणपत्राची पडताळणी करतो, प्रमाणपत्र रद्द केले गेले नाही याची खात्री करण्यासाठी Certificate Revocation List तपासतो आणि सर्व काही व्यवस्थित असल्यास, ॲक्सेस पॉईंटला स्वीकृती संदेश पाठवतो. डिव्हाइस नेटवर्कवर येते. ही संपूर्ण प्रक्रिया वापरकर्त्यासाठी अदृश्य असते.

आता, आपण SCEP पर्यायी असलेल्या PKCS च्या तुलनेत कुठे उभे आहे याबद्दल बोलूया. PKCS, म्हणजेच Public Key Cryptography Standards, ही Intune सारख्या प्लॅटफॉर्मद्वारे समर्थित असलेली दुसरी प्रमाणपत्र वितरण पद्धत आहे. PKCS सह, CA केंद्रीय पद्धतीने पब्लिक आणि प्रायव्हेट दोन्ही की जनरेट करतो आणि प्रमाणपत्र कनेक्टर की पेअर डिव्हाइसवर पुश करतो. याचा अर्थ प्रायव्हेट की नेटवर्कवरून प्रवास करते, ज्यामुळे सैद्धांतिकदृष्ट्या सायबर हल्ल्याची शक्यता निर्माण होते. 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 ॲक्सेस आपोआप बंद होतो. ही अशी रिव्होकेशन स्टोरी आहे जी प्री-शेअर्ड की कधीही देऊ शकत नाहीत.

चला, आता डिप्लॉयमेंटच्या क्रमाबद्दल बोलूया, कारण इथेच बहुतांश टीम्सची गल्लत होते.

हा क्रम बदलता येणारा नाही: आधी Trusted Root प्रमाणपत्र, दुसरे SCEP प्रमाणपत्र प्रोफाइल, तिसरे WiFi प्रोफाइल. Intune आणि Jamf दोन्ही प्रोफाइलच्या परस्परावलंबित्वाची सक्ती करतात. जर तुमचे WiFi प्रोफाइल अशा SCEP प्रमाणपत्राचा संदर्भ देत असेल जे अद्याप डिव्हाइसवर डिप्लॉय केलेले नाही, तर WiFi प्रोफाइल एका अनाकलनीय एररसह अयशस्वी होईल जी चुकीच्या कॉन्फिगरेशनसारखी दिसते परंतु प्रत्यक्षात ती केवळ वेळेची समस्या असते.

दुसरी चूक म्हणजे ग्रुप टार्गेटिंग (group targeting). 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 डिस्ट्रिब्युशन पॉईंट अनुपलब्ध असेल, तर नेटवर्कवरील प्रत्येक डिव्हाइसचे ऑथेंटिकेशन एकाच वेळी अयशस्वी होते. हा संपूर्ण कॅम्पस-व्यापी आउटेज (outage) ठरू शकतो. तुमचे CRL एंडपॉइंट्स हायली-अवेलेबल (highly available) बनवा आणि लाइव्ह जाण्यापूर्वी रिव्होकेशनची (revocation) चाचणी घ्या.

५०० पेक्षा जास्त डिव्हाइसेस असलेल्या मोठ्या नेटवर्कसाठी, ऑन-प्रिमाइसेस NDES ऐवजी क्लाउड SCEP गेटवेचा विचार करा. क्लाउड गेटवे NDES चा सिंगल पॉइंट ऑफ फेल्युअर (single point of failure) दूर करतात, हॉरिझॉन्टली स्केल होतात आणि सामान्यतः थेट क्लाउड RADIUS सेवांशी इंटिग्रेट होतात, ज्यामुळे आणखी एक इन्फ्रास्ट्रक्चर डिपेंडन्सी कमी होते.

चला, CTOs कडून आम्हाला वारंवार विचारल्या जाणाऱ्या काही जलद प्रश्नांची उत्तरे शोधूया.

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 या कॉम्बिनेशनची शिफारस केली जाते.

थोडक्यात सांगायचे तर. ५० पेक्षा जास्त मॅनेज्ड डिव्हाइसेस असलेल्या कोणत्याही नेटवर्कसाठी SCEP सर्टिफिकेट WiFi ऑथेंटिकेशन हेच योग्य आर्किटेक्चर आहे. हे शेअर्ड क्रेडेंशियल्स काढून टाकते, तुम्हाला प्रति-डिव्हाइस आयडेंटिटी देते, डायनॅमिक VLAN सेगमेंटेशन सक्षम करते आणि ऑटोमेटेड रिव्होकेशनसाठी थेट तुमच्या आयडेंटिटी प्रोव्हाइडरशी इंटिग्रेट होते. डिप्लॉयमेंटचा क्रम - आधी Trusted Root, नंतर SCEP प्रोफाइल, आणि मग WiFi प्रोफाइल - हा निश्चित आहे. ग्रुप टार्गेटिंग सुसंगत असणे आवश्यक आहे. CRL उपलब्धता पर्यायी नाही.

विशेषतः उच्च शिक्षणासाठी, कर्मचारी आणि प्राध्यापकांच्या उपकरणांसाठी SCEP चे संयोजन, आणि वैयक्तिक उपकरणांवरील विद्यार्थ्यांसाठी स्वतंत्र अतिथी WiFi स्तर, तुम्हाला सुरक्षितता आणि तडजोड न करता एक उत्तम वापरकर्ता अनुभव दोन्ही प्रदान करते.

तुम्हाला अधिक सखोल माहिती हवी असल्यास, एंटरप्राइझ WiFi ऑथेंटिकेशनवरील Purple चे मार्गदर्शक क्लाउड-नेटिव्ह मार्गाचा समावेश करते. आणि जेव्हा एखादा कर्मचारी नोकरी सोडतो तेव्हा काय होते याबद्दल तुम्ही विचार करत असाल, तर WiFi प्रवेश रद्द करण्यावरील आमचे मार्गदर्शक संपूर्ण रिव्होकेशन वर्कफ्लो स्पष्ट करते.

ऐकल्याबद्दल धन्यवाद. मी Purple तांत्रिक टीममधून आहे, आणि आम्ही तुम्हाला पुढील ब्रीफिंगमध्ये भेटू.

महत्वाचे मुद्दे

✓SCEP (RFC 8894) व्यवस्थापित डिव्हाइसेससाठी प्रमाणपत्र नोंदणी स्वयंचलित करते - खाजगी की डिव्हाइसवरच तयार केली जाते आणि कधीही प्रसारित केली जात नाही, ज्यामुळे ते PKCS ऐवजी WiFi प्रमाणीकरणासाठी योग्य पर्याय बनते.
✓उपयोजन (deployment) क्रम बदलता येणार नाही: प्रथम Trusted Root प्रमाणपत्र, दुसरे SCEP प्रमाणपत्र प्रोफाइल, तिसरे WiFi प्रोफाइल. या क्रमाचे उल्लंघन केल्यास प्रोफाइल अवलंबित्व (dependency) त्रुटी उद्भवतात.
✓तिन्ही MDM प्रोफाइल (Trusted Root, SCEP, WiFi) एकाच डिरेक्टरी ग्रुपला लक्ष्य करणे आवश्यक आहे. क्रॉस-ग्रुप लक्ष्यीकरण हे उपयोजन अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.
✓NDES हे Azure AD Application Proxy द्वारे प्रकाशित केले जावे, थेट इंटरनेटवर उघडे ठेवू नये. ५०० पेक्षा जास्त डिव्हाइसेस असलेल्या नेटवर्कसाठी, क्लाउड SCEP गेटवे NDES चा सिंगल पॉइंट ऑफ फेल्युअर दूर करतो.
✓CRL Distribution Point उपलब्धता ही नेटवर्क-गंभीर अवलंबित्व आहे. जर RADIUS सर्व्हर CRL पर्यंत पोहोचू शकला नाही, तर तो बंद होतो आणि एकाच वेळी सर्व प्रमाणीकरण नाकारतो.
✓SCEP-तरतूद केलेल्या प्रमाणपत्रांसह EAP-TLS कार्डधारक डेटा वातावरणातील वायरलेस नेटवर्कसाठी PCI DSS 4.0 आवश्यकता 8.6 पूर्ण करते आणि WPA3-Enterprise 192-bit (Suite B) साठी आवश्यक आहे.
✓SCEP केवळ व्यवस्थापित डिव्हाइसेस कव्हर करते. व्यवस्थापित नसलेल्या BYOD आणि अतिथी डिव्हाइसेससाठी Captive Portal आणि ओळख पडताळणीसह स्वतंत्र SSID आवश्यक आहे - Purple चे प्लॅटफॉर्म तुमच्या प्रमाणपत्र-प्रमाणित कर्मचारी नेटवर्कसह या स्तराचे व्यवस्थापन करते.

कार्यकारी सारांश (Executive summary)

एंटरप्राइझ ठिकाणांसाठी - मग ते २०० खोल्यांचे हॉटेल असो, ५० आउटलेट्सची रिटेल साखळी असो किंवा एखादे मोठे कॉन्फरन्स सेंटर असो - कर्मचाऱ्यांच्या WiFi साठी प्री-शेअर्ड की (pre-shared keys) वर अवलंबून राहणे ही सुरक्षेची जोखीम आणि ऑपरेशनल अडथळा आहे. एकच पासवर्ड लीक झाल्यास संपूर्ण नेटवर्क धोक्यात येते. IEEE 802.1X आणि EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) द्वारे सर्टिफिकेट-आधारित ऑथेंटिकेशन हा धोका पूर्णपणे काढून टाकते. ॲक्सेस पॉईंटने नेटवर्क ॲक्सेस देण्यापूर्वी प्रत्येक डिव्हाइस त्याची ओळख क्रिप्टोग्राफिक पद्धतीने सिद्ध करते.

यामधील आव्हान वितरणाचे आहे. हजारो Windows, iOS, आणि Android डिव्हाइसेसवर मॅन्युअली युनिक क्लायंट सर्टिफिकेट्स तैनात करणे व्यवहार्य नाही. SCEP (Simple Certificate Enrollment Protocol), ज्याला २०२० मध्ये IETF द्वारे RFC 8894 म्हणून औपचारिक रूप दिले गेले, हे यावर उपाय शोधते. हे तुमच्या MDM प्लॅटफॉर्मद्वारे व्यवस्थापित डिव्हाइसेसवर डिजिटल सर्टिफिकेट्सची विनंती करणे, जारी करणे आणि स्थापित करणे या प्रक्रियेला स्वयंचलित करते - कोणत्याही युझर हस्तक्षेपाशिवाय.

या मार्गदर्शकामध्ये संपूर्ण आर्किटेक्चर समाविष्ट आहे: SCEP काय करते, ते Microsoft Intune, Jamf आणि इतर MDM प्लॅटफॉर्मसह कसे समाकलित होते, अचूक डिप्लॉयमेंट क्रम जो बऱ्याच टीम्स चुकवतात आणि आउटेजला कारणीभूत ठरणारे ऑपरेशनल धोके. आम्ही हॉस्पिटॅलिटी आणि रिटेलमधील दोन वास्तविक-जगातील अंमलबजावणीचे प्रसंग देखील कव्हर करतो आणि तुमच्या सर्टिफिकेट-ऑथेंटिकेटेड स्टाफ नेटवर्कसह Purple चे Guest WiFi प्लॅटफॉर्म कुठे फिट बसते हे स्पष्ट करतो.

सोबतचे पॉडकास्ट ब्रीफिंग ऐका:

तांत्रिक सखोल विश्लेषण: SCEP, PKI, आणि 802.1X

SCEP प्रत्यक्षात काय करते

SCEP हे तुमच्या पब्लिक की इन्फ्रास्ट्रक्चर (PKI) ला पर्याय नाही. हा स्वयंचलित नावनोंदणी (enrollment) स्तर आहे जो त्यावर कार्य करतो. तुमचे PKI - सामान्यत: ऑफलाइन रूट CA आणि ऑनलाइन इश्यूइंग CA सह द्वि-स्तरीय श्रेणी - हे विश्वासाचे मुख्य केंद्र राहते. SCEP त्या CA कडून डिव्हाइसने सर्टिफिकेटची विनंती करण्याची पायरी स्वयंचलित करते, ज्यामुळे मॅन्युअल CSR जनरेशन आणि सर्टिफिकेट इन्स्टॉलेशनची आवश्यकता दूर होते.

WiFi ऑथेंटिकेशनच्या संदर्भात, लक्ष्य प्रोटोकॉल EAP-TLS आहे. ही 802.1X ऑथेंटिकेशन पद्धत आहे ज्यासाठी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोघांनाही वैध X.509 सर्टिफिकेट्स सादर करणे आवश्यक आहे. क्रिप्टोग्राफिक पुराव्याशिवाय कोणतीही बाजू दुसऱ्यावर विश्वास ठेवत नाही. हे परस्पर ऑथेंटिकेशन मॉडेल क्रेडेंशियल चोरीचे प्रमाण काढून टाकते आणि इव्हिल ट्विन (evil twin) हल्ल्यांपासून संरक्षण करते, जिथे एखादा हल्लेखोर युझरनेम आणि पासवर्ड चोरण्यासाठी बनावट ॲक्सेस पॉईंट तयार करतो.

EAP-TLS हँडशेकच्या तपशीलवार विश्लेषणासाठी, आमचे WiFi Certificate Authentication: Secure Network Access हे मार्गदर्शक पहा.

SCEP एनरोलमेंट प्रवाह, टप्प्याटप्प्याने

संपूर्ण एनरोलमेंट साखळी खालीलप्रमाणे काम करते. तुमचे MDM प्लॅटफॉर्म - Microsoft Intune, Jamf किंवा इतर MDM - व्यवस्थापित डिव्हाइसवर SCEP पेलोड पुश करते. त्या पेलोडमध्ये दोन गोष्टी असतात: तुमच्या NDES (Network Device Enrollment Service) सर्व्हर किंवा क्लाउड SCEP गेटवेकडे निर्देशित करणारा SCEP URL आणि चॅलेंज पासवर्ड किंवा शेअर केलेला सिक्रेट.

डिव्हाइस स्थानिक पातळीवर स्वतःची पब्लिक आणि प्रायव्हेट की जोडी तयार करते. हे SCEP चे महत्त्वपूर्ण सुरक्षा वैशिष्ट्य आहे: प्रायव्हेट की डिव्हाइसवरच तयार केली जाते, सिक्युर एन्क्लेव्ह किंवा TPM चिपमध्ये सुरक्षित ठेवली जाते आणि नेटवर्कवर कधीही पाठवली जात नाही. त्यानंतर डिव्हाइस सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR) तयार करते आणि SCEP गेटवेकडे पाठवते. गेटवे चॅलेंज पासवर्ड प्रमाणित करतो, CSR तुमच्या सर्टिफिकेट ऑथॉरिटीकडे (CA) पाठवतो आणि CA त्यावर स्वाक्षरी करून पब्लिक सर्टिफिकेट डिव्हाइसला परत करतो.

त्यानंतर, जेव्हा डिव्हाइस तुमच्या WiFi SSID शी कनेक्ट होते, तेव्हा ते RADIUS सर्व्हरला ते सर्टिफिकेट सादर करते. RADIUS सर्व्हर तुमच्या CA ट्रस्ट चेनच्या विरूद्ध सर्टिफिकेट प्रमाणित करतो, सर्टिफिकेट रद्द केले गेले नाही याची खात्री करण्यासाठी सर्टिफिकेट रिव्होकेशन लिस्ट (CRL) तपासतो आणि सर्व काही व्यवस्थित असल्यास, ॲक्सेस पॉईंटला Access-Accept संदेश पाठवतो. डिव्हाइस नेटवर्कवर कनेक्ट होते. ही संपूर्ण प्रक्रिया वापरकर्त्यासाठी अदृश्य असते.

SCEP विरुद्ध PKCS: WiFi साठी कोणते वापरावे

Intune सारखे MDM प्लॅटफॉर्म्स दोन सर्टिफिकेट डिलिव्हरी मेकॅनिझमला सपोर्ट करतात: SCEP आणि PKCS (Public Key Cryptography Standards). यामधील आर्किटेक्चरल फरक महत्त्वपूर्ण आहे.

SCEP सह, प्रायव्हेट की डिव्हाइसवर तयार केली जाते आणि ती कधीही डिव्हाइस सोडत नाही. PKCS सह, सर्टिफिकेट ऑथॉरिटी पब्लिक आणि प्रायव्हेट की दोन्ही मध्यवर्ती ठिकाणी तयार करते आणि सर्टिफिकेट कनेक्टर नेटवर्कद्वारे की जोडी डिव्हाइसवर पुश करतो. याचा अर्थ प्रायव्हेट की ट्रान्समिट केली जाते, ज्यामुळे सैद्धांतिक सुरक्षा धोका निर्माण होऊ शकतो.

PKCS अशा वापरांसाठी योग्य आहे जिथे की एस्क्रो आवश्यक असते, जसे की S/MIME ईमेल एन्क्रिप्शन. WiFi ऑथेंटिकेशनसाठी, SCEP हा योग्य पर्याय आहे. प्रायव्हेट की डिव्हाइसवरच राहते.

वैशिष्ट्य	SCEP	PKCS
प्रायव्हेट की निर्मिती	डिव्हाइसवर (TPM/Secure Enclave)	मध्यवर्ती (CA)
प्रायव्हेट की ट्रान्समिशन	कधीही नाही	नेटवर्कवर
NDES सर्व्हर आवश्यक	होय (किंवा क्लाउड गेटवे)	नाही
WiFi साठी शिफारस केलेले	होय	नाही
S/MIME साठी शिफारस केलेले	नाही	होय

हार्डवेअर सुसंगतता

SCEP आणि EAP-TLS हे वेंडर-न्यूट्रल (vendor-neutral) मानक आहेत. ते Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet ॲक्सेस पॉइंट्सवर काम करतात. तुमचे RADIUS कॉन्फिगरेशन - मग ते Windows NPS असो, FreeRADIUS असो किंवा क्लाउड RADIUS सेवा असो - तिथेच तुम्ही प्रमाणपत्र प्रमाणीकरण (certificate validation) पॉलिसी आणि डायनॅमिक VLAN असाइनमेंट परिभाषित करता.

डायनॅमिक VLAN असाइनमेंटद्वारे तुम्ही डिव्हाइसच्या ओळखीनुसार नेटवर्कचे वर्गीकरण करता. कर्मचाऱ्याच्या डिव्हाइसला अंतर्गत सिस्टम्सच्या ॲक्सेससह VLAN 10 मिळतो. कंत्राटदाराच्या डिव्हाइसला केवळ इंटरनेट ॲक्सेससह VLAN 20 मिळतो. पॉइंट-ऑफ-सेल (POS) टर्मिनलला केवळ पेमेंट प्रोसेसिंग सिस्टम्सच्या ॲक्सेससह VLAN 30 मिळतो. हे सर्व प्रमाणपत्राचे गुणधर्म आणि RADIUS पॉलिसीद्वारे चालवले जाते, ज्यामध्ये प्रति डिव्हाइस कोणत्याही मॅन्युअल हस्तक्षेपाची आवश्यकता नसते.

ओळख-आधारित नेटवर्क वर्गीकरणासह WiFi Analytics कसे समाकलित होते याबद्दल अधिक माहितीसाठी, आमचे ॲनालिटिक्स प्लॅटफॉर्म विहंगावलोकन पहा.

अंमलबजावणी मार्गदर्शक: उपयोजन (deployment) क्रम

एंटरप्राइझ WiFi साठी SCEP यशस्वीरित्या कॉन्फिगर करण्यासाठी विशिष्ट उपयोजन क्रमाचे काटेकोरपणे पालन करणे आवश्यक आहे. MDM प्लॅटफॉर्म प्रोफाइल अवलंबित्व लागू करतात: SCEP प्रमाणपत्राचा संदर्भ देणारे WiFi प्रोफाइल जोपर्यंत ते प्रमाणपत्र डिव्हाइसवर अस्तित्वात येत नाही तोपर्यंत लागू होऊ शकत नाही. या क्रमाचे उल्लंघन करणे हे उपयोजन अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.

क्रम असा आहे: आधी Trusted Root, दुसरे SCEP प्रोफाइल, तिसरे WiFi प्रोफाइल. या क्रमामध्ये कोणतीही तडजोड केली जाऊ शकत नाही.

पायरी १: Trusted Root Certificate प्रोफाइल उपयोजित करा

कोणतेही डिव्हाइस क्लायंट प्रमाणपत्राची विनंती करण्यापूर्वी किंवा तुमच्या RADIUS सर्व्हरवर विश्वास ठेवण्यापूर्वी, त्याने जारी करणाऱ्या प्रमाणपत्र प्राधिकरणावर (Certificate Authority) विश्वास ठेवला पाहिजे. तुमचे Root CA प्रमाणपत्र - आणि कोणतेही Intermediate CA प्रमाणपत्रे - .cer फाइल्स म्हणून एक्सपोर्ट करा. तुमच्या MDM ॲडमिन सेंटरमध्ये, एक Trusted Certificate प्रोफाइल तयार करा, .cer फाइल अपलोड करा आणि ती तुमच्या लक्ष्यित डिव्हाइस ग्रुपवर उपयोजित करा.

तुमच्याकडे टू-टियर PKI पदानुक्रम (शिफारस केलेले) असल्यास, तुम्हाला तुमच्या MDM प्लॅटफॉर्मवर अवलंबून, Root CA आणि जारी करणारे CA प्रमाणपत्रे दोन्ही स्वतंत्र Trusted Certificate प्रोफाइल म्हणून किंवा एकाच प्रोफाइलमधील साखळी म्हणून उपयोजित करावे लागतील.

पायरी २: SCEP Certificate प्रोफाइल कॉन्फिगर करा

एकदा विश्वास स्थापित झाल्यानंतर, डिव्हाइसेसना त्यांचे क्लायंट प्रमाणपत्र कसे मिळवायचे याचे निर्देश देण्यासाठी SCEP प्रोफाइल कॉन्फिगर करा.

एक नवीन कॉन्फिगरेशन प्रोफाइल तयार करा आणि SCEP प्रमाणपत्र प्रोफाइल प्रकार निवडा. Subject नाव स्वरूप कॉन्फिगर करा. वापरकर्ता-चालित प्रमाणीकरणासाठी, CN={{UserPrincipalName}} हे मानक आहे. डिव्हाइस प्रमाणीकरणासाठी (शेअर केलेले डिव्हाइसेस, IoT, POS टर्मिनल्स), CN={{AAD_Device_ID}} वापरा. Key usage हे Digital signature आणि Key encipherment वर सेट करा. Extended Key Usage हे Client Authentication (OID: 1.3.6.1.5.5.7.3.2) वर सेट करा. हे प्रोफाइल पायरी १ मध्ये तयार केलेल्या Trusted Root प्रमाणपत्र प्रोफाइलशी लिंक करा. तुमच्या NDES सर्व्हरची बाह्य URL प्रदान करा. विशेषतः Microsoft Intune साठी, रिमोट डिव्हाइसेसना ऑन-साइट येण्यापूर्वी नोंदणी करण्याची परवानगी देण्यासाठी NDES सर्व्हर Azure AD Application Proxy द्वारे प्रकाशित करणे आवश्यक आहे. NDES थेट इंटरनेटवर उघडू नका.

पायरी ३: 802.1X WiFi प्रोफाइल तैनात करा

शेवटची पायरी म्हणजे WiFi कॉन्फिगरेशन पुश करणे जे प्रमाणपत्रांना नेटवर्क SSID शी जोडते. एक Wi-Fi कॉन्फिगरेशन प्रोफाइल तयार करा. नेटवर्कचे नाव (SSID) जसे तुमच्या ॲक्सेस पॉईंट्सद्वारे ब्रॉडकास्ट केले जाते तसेच अचूक प्रविष्ट करा. सुरक्षा प्रकार म्हणून WPA2-Enterprise किंवा WPA3-Enterprise निवडा. EAP प्रकार EAP-TLS वर सेट करा. ऑथेंटिकेशन सेटिंग्जमध्ये, क्लायंट ऑथेंटिकेशन प्रमाणपत्र म्हणून पायरी २ मध्ये तयार केलेले SCEP प्रमाणपत्र प्रोफाइल निवडा. सर्व्हर व्हॅलिडेशनसाठी Trusted Root प्रमाणपत्र निर्दिष्ट करा - हे सुनिश्चित करते की डिव्हाइस केवळ तुमच्या कायदेशीर RADIUS सर्व्हरशी कनेक्ट होईल आणि कोणत्याही बनावट ॲक्सेस पॉईंटशी नाही.

आयडेंटिटी प्रोव्हाइडर इंटिग्रेशन

SCEP प्रमाणपत्र विशेषता - विशेषतः Subject Alternative Name (SAN) - Microsoft Entra ID, Okta किंवा Google Workspace वरून वापरकर्त्याचे मुख्य नाव वाहून नेऊ शकतात. हे प्रमाणपत्र एका विशिष्ट ओळखीशी जोडते. जेव्हा तुम्ही Entra ID मधील खाते निष्क्रिय करता आणि MDM डिव्हाइसची नोंदणी रद्द करते, तेव्हा प्रमाणपत्र रद्द केले जाते आणि WiFi ॲक्सेस आपोआप बंद केला जातो. ते स्वयंचलित रद्दीकरण ही अशी सुरक्षा कथा आहे ज्याची तुलना प्री-शेअर्ड की (pre-shared keys) करू शकत नाहीत.

PEAP-MSCHAPv2 मायग्रेशन पाथसह EAP Method WiFi: A Guide to Secure Network Access बद्दल अधिक माहितीसाठी, आमचे समर्पित मार्गदर्शक पहा.

सर्वोत्तम पद्धती आणि उद्योग मानके

NDES सर्व्हर प्लेसमेंट

NDES सर्व्हर इंटरनेटवरून ॲक्सेस करण्यायोग्य असणे आवश्यक आहे जेणेकरून डिव्हाइसेस ऑन-साइट येण्यापूर्वी नोंदणी करू शकतील. Azure AD Application Proxy द्वारे NDES URL प्रकाशित करा. हे इनबाउंड फायरवॉल पोर्ट्स न उघडता सुरक्षित रिमोट ॲक्सेस प्रदान करते आणि तुम्हाला नोंदणी प्रवाहावर कंडिशनल ॲक्सेस पॉलिसी लागू करण्याची परवानगी देते. NDES थेट इंटरनेटवर कधीही उघडू नका.

५०० पेक्षा जास्त व्यवस्थापित डिव्हाइसेस असलेल्या नेटवर्कसाठी, ऑन-प्रिमाइसेस NDES ऐवजी क्लाउड SCEP गेटवेचा विचार करा. क्लाउड गेटवे NDES चे सिंगल पॉईंट ऑफ फेल्युअर दूर करतात, क्षैतिजरित्या स्केल होतात आणि सामान्यतः थेट क्लाउड RADIUS सेवांशी समाकलित होतात.

CRL उपलब्धता

जेव्हा जेव्हा एखादे डिव्हाइस ऑथेंटिकेट होते तेव्हा तुमचा RADIUS सर्व्हर Certificate Revocation List (CRL) तपासतो. जर तुमचा CRL Distribution Point (CDP) अनुपलब्ध असेल - सर्व्हर डाउन असल्यामुळे किंवा URL बदलल्यामुळे - तर नेटवर्कवरील प्रत्येक डिव्हाइससाठी ऑथेंटिकेशन एकाच वेळी अयशस्वी होते. कडक CRL चेकिंग लागू करण्यासाठी तुमचा NPS किंवा RADIUS सर्व्हर कॉन्फिगर करा आणि तुमचे CRL एंडपॉइंट्स अत्यंत उपलब्ध ठेवा. लाइव्ह जाण्यापूर्वी रद्दीकरणाची चाचणी घ्या.

PCI DSS 4.0 ची आवश्यकता 8.6 कार्डधारक डेटा वातावरणासाठी नेटवर्क लेयरवर मल्टी-फॅक्टर ऑथेंटिकेशन अनिवार्य करते. SCEP-प्रोविझन्ड प्रमाणपत्रांसह EAP-TLS Retail आणि Hospitality वातावरणातील वायरलेस नेटवर्कसाठी ही आवश्यकता पूर्ण करते.

WPA3 सुसंगतता

EAP-TLS हे WPA3-Enterprise सोबत पूर्णपणे सुसंगत आहे. 192-बिट सुरक्षा सुट (Suite B) असलेले WPA3-Enterprise हे EAP-TLS अनिवार्य करते आणि सरकारी, वित्तीय आणि आरोग्य सेवा नेटवर्कसाठी Wi-Fi Alliance द्वारे शिफारस केलेले हे संयोजन आहे. जर तुम्ही कडक अनुपालन आवश्यकता असलेल्या Healthcare किंवा Transport वातावरणात तैनात करत असाल, तर EAP-TLS सह WPA3-Enterprise हे योग्य लक्ष्य आर्किटेक्चर आहे.

BYOD आणि अतिथी WiFi

प्रमाणपत्र पेलोड पुश करण्यासाठी SCEP ला MDM नोंदणी आवश्यक आहे. यामध्ये व्यवस्थापित नसलेली BYOD उपकरणे किंवा अतिथी समाविष्ट नाहीत. त्या वापराच्या प्रकरणांसाठी, तुम्हाला Captive Portal आणि ओळख पडताळणीसह स्वतंत्र SSID ची आवश्यकता आहे. Purple चे प्लॅटफॉर्म तो स्तर सुलभतेने हाताळते, जे तुमच्या प्रमाणपत्र-प्रमाणित कर्मचारी नेटवर्कच्या सोबतीने कार्य करते. आमचे Guest WiFi प्लॅटफॉर्म जाणीवपूर्वक निवडलेले पर्याय (opt-ins), फर्स्ट-पार्टी डेटा कॅप्चर आणि ओळख पडताळणीसाठी Microsoft Entra ID, Okta आणि Google Workspace सह एकत्रीकरणास समर्थन देते.

त्रुटी निवारण आणि जोखीम कमी करणे

WiFi प्रोफाइल लागू होण्यास अपयशी ठरते

लक्षण: उपकरणाला Trusted Root आणि SCEP प्रमाणपत्रे मिळतात, परंतु MDM मध्ये WiFi प्रोफाइल Error किंवा Not Applicable म्हणून दिसते.

मूळ कारण: ग्रुप टार्गेटिंगमधील विसंगती. जर SCEP प्रोफाइल User ग्रुपला लक्ष्य करत असेल आणि WiFi प्रोफाइल Device ग्रुपला लक्ष्य करत असेल, तर MDM या अवलंबित्वाची सोडवणूक करू शकत नाही.

उपाय: तुमच्या असाइनमेंट्सचे ऑडिट करा. Trusted Root, SCEP आणि WiFi प्रोफाइल हे सर्व एकाच डिरेक्टरी ग्रुपला लक्ष्य करत असल्याची खात्री करा.

NDES 403 Forbidden त्रुटी

लक्षण: उपकरणे SCEP प्रमाणपत्र मिळवण्यात अपयशी ठरतात. NDES IIS लॉग्स HTTP 403 त्रुटी दर्शवतात.

मूळ कारण: MDM Certificate Connector सर्व्हिस अकाउंटकडे प्रमाणपत्र टेम्पलेटवर Read आणि Enroll परवानग्या नाहीत, किंवा फायरवॉल URL फिल्टरिंग SCEP क्वेरी स्ट्रिंग पॅरामीटर्स ब्लॉक करत आहे.

उपाय: कनेक्टर अकाउंटकडे CA टेम्पलेटवर Read आणि Enroll परवानग्या असल्याची पडताळणी करा. ?operation=GetCACaps समाविष्ट असलेल्या URL ब्लॉक केल्या जात नाहीत याची खात्री करण्यासाठी फायरवॉल लॉग्स तपासा.

CRL समाप्तीनंतर मोठ्या प्रमाणावर प्रमाणीकरण अपयश

लक्षण: नेटवर्कवरील सर्व उपकरणे एकाच वेळी प्रमाणित होण्यास अपयशी ठरतात.

मूळ कारण: CRL ची मुदत संपली आहे किंवा CDP URL पर्यंत पोहोचता येत नाही. RADIUS सर्व्हर प्रमाणपत्रे वैध असल्याची पुष्टी करू शकत नाही आणि सुरक्षिततेसाठी कनेक्शन बंद करतो.

उपाय: CRL मॉनिटरिंग आणि अलर्टिंग कॉन्फिगर करा. प्रकाशन अंतरापेक्षा लक्षणीयरीत्या जास्त वैधता कालावधी असलेले CRLs प्रकाशित करा. गो-लाइव्ह करण्यापूर्वी RADIUS सर्व्हरवरून CDP पोहोचक्षमतेची चाचणी घ्या.

प्रमाणपत्र समाप्तीमुळे छुपे अपयश येणे

लक्षण: वैयक्तिक उपकरणे मधूनमधून कनेक्ट होण्यास अपयशी ठरतात, ज्याचा कोणताही स्पष्ट पॅटर्न नसतो.

मूळ कारण: क्लायंट प्रमाणपत्रांची मुदत संपली आहे आणि MDM ने त्यांचे यशस्वीरित्या नूतनीकरण केलेले नाही.

उपाय: प्रमाणपत्राच्या ८०% आयुष्यावर नूतनीकरण सुरू होईल असे कॉन्फिगर करा. प्रमाणपत्र त्रुटी असलेल्या उपकरणांसाठी MDM नोंदणी स्थिती अहवालांचे निरीक्षण करा. तुमच्या डिव्हाइस रिफ्रेश सायकलसाठी योग्य प्रमाणपत्र वैधता कालावधी सेट करा - सामान्यतः व्यवस्थापित एंडपॉइंट्ससाठी एक ते दोन वर्षे.

ROI आणि व्यावसायिक प्रभाव

SCEP-आधारित 802.1X प्रमाणपत्र प्रमाणीकरणावर (certificate authentication) स्थलांतरित केल्याने सुरक्षा, ऑपरेशन्स आणि अनुपालनामध्ये (compliance) मोजता येण्याजोगा परतावा मिळतो.

हेल्पडेस्क तिकीट कपात: पासवर्ड-आधारित WiFi मोठ्या प्रमाणात सपोर्ट तिकिटे तयार करते - पासवर्डची मुदत संपणे, लॉकआउट्स आणि टायपिंगच्या चुका. प्रमाणपत्र-आधारित प्रमाणीकरण वापरकर्त्यासाठी अदृश्य असते. संस्था सहसा स्थलांतरणानंतर WiFi-संबंधित हेल्पडेस्क तिकिटांच्या संख्येत ७०-८०% कपात पाहतात.

सुरक्षा स्थिती: EAP-TLS क्रेडेंशियल हार्वेस्टिंग आणि मॅन-इन-द-मिडल (Man-in-the-Middle) हल्ले पूर्णपणे काढून टाकते. हे थेट रिटेल आणि हॉस्पिटॅलिटी नेटवर्कसाठी PCI DSS 4.0 अनुपालनाला आणि योग्य तांत्रिक सुरक्षा उपायांसाठी GDPR कलम ३२ च्या आवश्यकतांना थेट समर्थन देते.

स्वयंचलित निरसन (Automated revocation): जेव्हा एखादा कर्मचारी नोकरी सोडतो, तेव्हा Microsoft Entra ID मधील त्यांचे खाते निष्क्रिय केल्याने स्वयंचलित प्रमाणपत्र निरसन आणि MDM अनएनरोलमेंट ट्रिगर होते. नेटवर्क टीमच्या कोणत्याही मॅन्युअल हस्तक्षेपाशिवाय WiFi प्रवेश त्वरित बंद केला जातो.

नेटवर्क विभाजन (Network segmentation): RADIUS प्रमाणपत्र गुणधर्मांद्वारे डायनॅमिक VLAN असाइनमेंट तुम्हाला क्रिप्टोग्राफिकली लागू केलेले नेटवर्क विभाजन देते. डिव्हाइसेस SSID निवड किंवा MAC ॲड्रेस फिल्टरिंगवर आधारित नसून, प्रमाणपत्र गुणधर्मांच्या आधारे योग्य नेटवर्क सेगमेंटवर पोहोचतात - ज्या दोन्ही गोष्टी सहजपणे बायपास केल्या जाऊ शकतात.

Purple हे ९९.९९९% अपटाइमसह ८०,०००+ पेक्षा जास्त लाइव्ह ठिकाणी कार्यरत आहे आणि आमचे प्लॅटफॉर्म ISO 27001, GDPR, CCPA आणि Cyber Essentials प्रमाणित आहे. आमचे हार्डवेअर-अज्ञेयवादी (hardware-agnostic) क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सोबत समाकलित होते - जेणेकरून तुमचे प्रमाणपत्र-प्रमाणित कर्मचारी नेटवर्क आणि आमचे गेस्ट WiFi लेयर एकाच इन्फ्रास्ट्रक्चरवरून काम करू शकतील.

तुमच्या सुरक्षित नेटवर्क उपयोजनाला Behavioral Analytics: Insights for WiFi Networks कशा प्रकारे पूरक ठरू शकते याबद्दल अधिक माहितीसाठी, आमचे विश्लेषण मार्गदर्शक पहा.

संदर्भ

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

महत्वाच्या व्याख्या

SCEP (Simple Certificate Enrollment Protocol)

RFC 8894 मध्ये औपचारिक केलेला एक प्रोटोकॉल जो व्यवस्थापित उपकरणांना HTTP द्वारे सर्टिफिकेट ऑथॉरिटीकडून स्वयंचलितपणे X.509 डिजिटल प्रमाणपत्रांची विनंती करण्यास आणि प्राप्त करण्यास अनुमती देतो, ज्यासाठी सुरुवातीच्या ऑथेंटिकेशनसाठी सामायिक चॅलेंज पासवर्ड वापरला जातो. प्रायव्हेट की डिव्हाइसवरच तयार केली जाते आणि ती कधीही ट्रान्समिट केली जात नाही.

Microsoft Intune आणि Jamf सारख्या MDM प्लॅटफॉर्मद्वारे व्यवस्थापित एंडपॉइंट्सवर मोठ्या प्रमाणावर WiFi ऑथेंटिकेशन प्रमाणपत्रे तैनात करण्यासाठी वापरली जाणारी मानक प्रणाली.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

सर्वात सुरक्षित 802.1X ऑथेंटिकेशन पद्धत, ज्यामध्ये क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोघांनाही वैध X.509 प्रमाणपत्रे सादर करणे आवश्यक असते. परस्पर ऑथेंटिकेशनचा अर्थ असा आहे की कोणतीही बाजू क्रिप्टोग्राफिक पुराव्याशिवाय दुसऱ्या बाजूवर विश्वास ठेवत नाही.

एंटरप्राइझ WiFi साठी लक्ष्य ऑथेंटिकेशन प्रोटोकॉल. संवेदनशील डेटा हाताळणाऱ्या वायरलेस नेटवर्कसाठी PCI DSS 4.0, WPA3-Enterprise 192-bit (Suite B), आणि HIPAA द्वारे अनिवार्य किंवा अत्यंत शिफारस केलेले.

NDES (Network Device Enrollment Service)

एक Microsoft Windows Server भूमिका जी SCEP-सक्षम डिव्हाइसेस आणि सर्टिफिकेट ऑथॉरिटी दरम्यान रजिस्ट्रेशन ऑथॉरिटी (RA) म्हणून काम करते. हे चॅलेंज पासवर्ड प्रमाणित करते आणि डोमेन क्रेडेंशियल नसलेल्या उपकरणांच्या वतीने सर्टिफिकेट ऑथॉरिटीकडे CSR फॉरवर्ड करते.

Microsoft Intune सह SCEP तैनातीसाठी आवश्यक पायाभूत सुविधा. थेट इंटरनेटवर उघड करण्याऐवजी Azure AD Application Proxy द्वारे प्रकाशित केले जावे.

PKI (Public Key Infrastructure)

डिजिटल प्रमाणपत्रे जारी करण्यासाठी, व्यवस्थापित करण्यासाठी आणि रद्द करण्यासाठी वापरल्या जाणाऱ्या सर्टिफिकेट ऑथॉरिटीज, पॉलिसी आणि प्रक्रियांची श्रेणीबद्ध रचना. द्वि-स्तरीय PKI मध्ये ऑफलाइन रूट CA (मुख्य विश्वास अँकर) आणि ऑनलाइन जारी करणारे CA (जे दैनंदिन प्रमाणपत्र जारी करण्याचे काम हाताळते) यांचा समावेश होतो.

EAP-TLS आणि SCEP तैनातीसाठी आवश्यक असलेली पूर्वअट. रूट CA एअर-गॅप्ड (सुरक्षितपणे वेगळे) ठेवले पाहिजे; त्याची प्रायव्हेट की तुमच्या संपूर्ण प्रमाणपत्र विश्वास साखळीचा पाया आहे.

CSR (Certificate Signing Request)

डिव्हाइसद्वारे तयार केलेला एक संदेश ज्यामध्ये त्याची पब्लिक की आणि ओळख माहिती असते, जी स्वाक्षरी केलेले डिजिटल प्रमाणपत्र मिळवण्यासाठी सर्टिफिकेट ऑथॉरिटीकडे पाठवली जाते. SCEP मध्ये, CSR डिव्हाइसवरच तयार केला जातो आणि ट्रान्समिशनपूर्वी PKCS एन्वेलोपमध्ये गुंडाळला जातो.

SCEP नोंदणी प्रक्रियेदरम्यान डिव्हाइसद्वारे स्वयंचलितपणे तयार केले जाते. CSR वर स्वाक्षरी करण्यासाठी वापरली जाणारी प्रायव्हेट की डिव्हाइस कधीही सोडत नाही.

CRL (Certificate Revocation List)

सर्टिफिकेट ऑथॉरिटीद्वारे प्रकाशित केलेली एक सूची ज्यामध्ये अशा प्रमाणपत्रांचे अनुक्रमांक असतात जे त्यांच्या समाप्ती तारखेपूर्वी रद्द केले गेले आहेत. रद्द केलेली प्रमाणपत्रे नेटवर्कमध्ये प्रवेश करू शकत नाहीत याची खात्री करण्यासाठी RADIUS सर्व्हर प्रत्येक ऑथेंटिकेशनच्या प्रयत्नावर CRL तपासतात.

CRL डिस्ट्रिब्युशन पॉईंट (CDP) ची उपलब्धता अत्यंत महत्त्वाची आहे. जर RADIUS सर्व्हर CRL पर्यंत पोहोचू शकला नाही, तर तो बंद पडतो आणि सर्व ऑथेंटिकेशन नाकारतो - ज्यामुळे संपूर्ण नेटवर्क ठप्प होऊ शकते.

RADIUS (Remote Authentication Dial-In User Service)

एक नेटवर्किंग प्रोटोकॉल जो नेटवर्क प्रवेशासाठी केंद्रीकृत ऑथेंटिकेशन, ऑथरायझेशन आणि अकाउंटिंग (AAA) प्रदान करतो. 802.1X WiFi मध्ये, RADIUS सर्व्हर क्लायंट प्रमाणपत्रांची पडताळणी करतो, CRL तपासतो आणि ॲक्सेस पॉईंटला ॲक्सेस-स्वीकार किंवा ॲक्सेस-अस्वीकार संदेश पाठवतो.

802.1X सप्लिकंट-ऑथेंटिकेटर-सर्व्हर मॉडेलमधील ऑथेंटिकेशन सर्व्हर. सामान्य अंमलबजावणीमध्ये Windows NPS, FreeRADIUS आणि क्लाउड RADIUS सेवांचा समावेश होतो.

Dynamic VLAN assignment

एक RADIUS वैशिष्ट्य जे SSID निवड किंवा MAC ॲड्रेस फिल्टरिंगवर अवलंबून राहण्याऐवजी प्रमाणपत्र गुणधर्म किंवा डिरेक्टरी गट सदस्यत्वाच्या आधारे ऑथेंटिकेट केलेल्या डिव्हाइसला विशिष्ट VLAN वर ठेवते. डिव्हाइसच्या ओळखीद्वारे नेटवर्कचे विभाजन लागू करते.

विविध नेटवर्क प्रवेश स्तरांसह एकाधिक डिव्हाइस प्रकारांना सेवा देण्यासाठी एकाच SSID ला सक्षम करते. कर्मचारी डिव्हाइसला VLAN 10 (अंतर्गत प्रवेश) मिळतो; कंत्राटदार डिव्हाइसला VLAN 20 (केवळ इंटरनेट) मिळतो; POS टर्मिनलला VLAN 30 (केवळ पेमेंट सिस्टम) मिळतो.

MDM (Mobile Device Management)

स्मार्टफोन, टॅब्लेट आणि लॅपटॉपची नोंदणी, कॉन्फिगरेशन, सुरक्षितता आणि व्यवस्थापन करण्यासाठी IT टीम्सद्वारे वापरले जाणारे सॉफ्टवेअर. Microsoft Intune आणि Jamf सारखे MDM प्लॅटफॉर्म वापरकर्त्याच्या हस्तक्षेपाशिवाय व्यवस्थापित उपकरणांवर प्रमाणपत्र नोंदणी सूचना पाठवण्यासाठी SCEP प्रोफाइल वापरतात.

SCEP-आधारित प्रमाणपत्र तैनातीसाठी पूर्वअट. डिव्हाइसेसना SCEP आणि WiFi प्रोफाइल प्राप्त होण्यापूर्वी ते MDM-नोंदणीकृत असणे आवश्यक आहे. अव्यवस्थित BYOD उपकरणांसाठी स्वतंत्र ऑनबोर्डिंग दृष्टिकोन आवश्यक आहे.

सोडवलेली उदाहरणे

२०० खोल्यांच्या एका Premier Inn प्रॉपर्टीला त्यांच्या पॉईंट-ऑफ-सेल टॅब्लेट्स आणि हाउसकीपिंग स्मार्टफोन्ससाठी स्टाफ WiFi सुरक्षित करायचे आहे. ते सध्या एक प्री-शेअर्ड की वापरत आहेत जी कंत्राटदारांकडे लीक झाली आहे. ते Microsoft Intune द्वारे डिव्हाइसेस व्यवस्थापित करतात आणि त्यांच्याकडे iOS आणि Android डिव्हाइसेसचे मिश्रण आहे. ही प्रॉपर्टी HPE Aruba ॲक्सेस पॉईंट्स वापरते.

१. अंतर्गत Microsoft AD CS टू-टियर PKI तैनात करा. समर्पित Windows Server वर NDES कॉन्फिगर करा आणि Azure AD Application Proxy द्वारे ते प्रकाशित करा. २. Intune मध्ये, Root CA आणि Issuing CA प्रमाणपत्रे असलेले Trusted Root Certificate प्रोफाइल तयार करा. 'Property Staff Devices' या Azure AD ग्रुपवर ते तैनात करा. ३. Intune मध्ये NDES च्या बाह्य URL कडे निर्देशित करणारे SCEP Certificate प्रोफाइल तयार करा. हे शेअर्ड डिव्हाइसेस असल्याने Subject Name फॉरमॅट CN={{AAD_Device_ID}} वर सेट करा. Key Usage हे Digital Signature आणि Key Encipherment वर, तर Extended Key Usage हे Client Authentication वर सेट करा. 'Property Staff Devices' वर तैनात करा. ४. स्टाफ SSID साठी Wi-Fi प्रोफाइल तयार करा, ज्यामध्ये WPA2-Enterprise आणि EAP-TLS कॉन्फिगर करा. क्लायंट ऑथेंटिकेशनसाठी SCEP प्रोफाइल आणि सर्व्हर व्हॅलिडेशनसाठी Root CA निवडा. 'Property Staff Devices' वर तैनात करा. ५. Windows NPS कडे निर्देशित करण्यासाठी HPE Aruba RADIUS सेटिंग्ज कॉन्फिगर करा. NPS वर, EAP-TLS ची आवश्यकता असणारी आणि स्टाफ डिव्हाइसेससाठी VLAN 10 नियुक्त करणारी Network Policy कॉन्फिगर करा. ६. एकदा डिव्हाइसेसना प्रोफाइल मिळाले आणि ते यशस्वीरित्या कनेक्ट झाले की, जुन्या SSID वरील PSK बदला आणि ते बंद करण्याचे शेड्यूल करा.

परीक्षकाचे भाष्य: हा दृष्टिकोन योग्यरित्या ओळखतो की शेअर्ड डिव्हाइसेसना (POS, हाउसकीपिंग) युझर-बेस्ड ऑथेंटिकेशनऐवजी डिव्हाइस-बेस्ड ऑथेंटिकेशन (CN={{AAD_Device_ID}}) आवश्यक आहे, कारण एकाच डिव्हाइसचा वापर अनेक कर्मचारी करतात. हे अनिवार्य प्रोफाइल डिप्लॉयमेंटच्या क्रमाचे पालन करते आणि तिन्ही प्रोफाइल एकाच Azure AD ग्रुपला लक्ष्य करत असल्याची खात्री करते. थेट इंटरनेट एक्सपोजरऐवजी App Proxy द्वारे NDES प्रकाशित करणे ही हॉस्पिटॅलिटी वातावरणासाठी योग्य सुरक्षा पद्धत आहे.

५० ठिकाणे असलेल्या एका रिटेल चेनला सर्व साइट्सवरील कॉर्पोरेट लॅपटॉप्ससाठी 802.1X तैनात करायचे आहे. ते Cisco Meraki ॲक्सेस पॉईंट्स आणि Microsoft Intune वापरतात. त्यांना प्रत्येक ठिकाणी किंवा त्यांच्या डेटा सेंटरमध्ये ऑन-प्रिमाइसेस NDES सर्व्हर्स किंवा AD CS इन्फ्रास्ट्रक्चर तैनात आणि व्यवस्थापित करायचे नाही.

१. क्लाउड-बेस्ड PKI आणि SCEP गेटवे सर्व्हिस लागू करा जी SCEP प्रोटोकॉलद्वारे Intune सोबत इंटिग्रेट होते. क्लाउड CA प्रमाणपत्रे जारी करते; क्लाउड SCEP गेटवे CSR व्हॅलिडेशन हाताळतो. २. कॉर्पोरेट SSID साठी Cisco Meraki डॅशबोर्डमध्ये Wireless > Access Control अंतर्गत क्लाउड RADIUS सर्व्हिस (PKI व्हेंडरद्वारे प्रदान केलेली) कॉन्फिगर करा. सिक्युरिटी WPA2-Enterprise वर सेट करा आणि RADIUS ला क्लाउड सर्व्हिसकडे निर्देशित करा. ३. Intune मध्ये, क्लाउड CA रूट प्रमाणपत्र असलेले Trusted Root Certificate प्रोफाइल तयार करा. 'Corporate Laptops' डिव्हाइस ग्रुपवर तैनात करा. ४. क्लाउड SCEP गेटवे URL कडे निर्देशित करणारे SCEP Certificate प्रोफाइल तयार करा. युझर-बेस्ड ऑथेंटिकेशनसाठी Subject Name हे CN={{UserPrincipalName}} वर सेट करा. 'Corporate Laptops' वर तैनात करा. ५. SCEP प्रोफाइल आणि क्लाउड CA रूटचा संदर्भ देऊन कॉर्पोरेट SSID साठी EAP-TLS सह Wi-Fi प्रोफाइल तयार करा. 'Corporate Laptops' वर तैनात करा. ६. जेव्हा लॅपटॉप्स Intune मध्ये एनरोल होतील, तेव्हा ते क्लाउड SCEP गेटवेद्वारे क्लाउड CA कडून आपोआप प्रमाणपत्रांची विनंती करतील. ५० पैकी कोणत्याही ठिकाणी ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चरची आवश्यकता नाही.

परीक्षकाचे भाष्य: वितरित रिटेल वातावरणासाठी हे सर्वात इष्टतम आधुनिक आर्किटेक्चर आहे. क्लाउड PKI आणि क्लाउड RADIUS चा वापर करून, संस्थेला प्रत्येक साइटवर क्लिष्ट ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर (NDES, AD CS, NPS) राखण्याची आवश्यकता उरत नाही. क्लाउड SCEP गेटवे क्षैतिजरित्या स्केल होतो आणि मूळतः अत्यंत उपलब्ध असतो, ज्यामुळे ऑन-प्रिमाइसेस NDES मुळे उद्भवणारा सिंगल पॉईंट ऑफ फेल्युअर दूर होतो. Cisco Meraki चे क्लाउड-मॅनेज्ड आर्किटेक्चर या दृष्टिकोनाशी सुसंगत आहे.

सराव प्रश्न

Q1. तुमची संस्था PEAP-MSCHAPv2 वरून EAP-TLS वर स्थलांतरित होत आहे. तुम्ही Intune मधील तुमच्या 'Corporate Users' Azure AD ग्रुपमध्ये Trusted Root आणि SCEP प्रोफाइल यशस्वीरित्या तैनात केले आहेत. तुम्ही 'All Corporate Devices' वर WiFi प्रोफाइल तैनात करता. युजर्स तक्रार करत आहेत की ते कनेक्ट करू शकत नाहीत आणि WiFi प्रोफाइल Not Applicable म्हणून दिसत आहे.

टीप: प्रोफाइल डिपेंडेंसी आणि ग्रुप टार्गेटिंग नियम तपासा. Intune नियुक्त केलेल्या ग्रुपच्या आधारे प्रोफाइल डिपेंडेंसी सोडवते.

नमुना उत्तर पहा

ही समस्या ग्रुप टार्गेटिंग विसंगतीमुळे (mismatch) आहे. WiFi प्रोफाइल SCEP प्रोफाइलवर अवलंबून असते, जे युजर ग्रुपला ('Corporate Users') टार्गेट केले गेले होते. तर WiFi प्रोफाइल डिव्हाइस ग्रुपला ('All Corporate Devices') टार्गेट केले गेले होते. Intune वेगवेगळ्या ग्रुप प्रकारांमधील डिपेंडेंसी सोडवू शकत नाही. यावरील उपाय म्हणजे Trusted Root, SCEP आणि WiFi या तिन्ही प्रोफाइल असाइनमेंट बदलून एकाच ग्रुपला टार्गेट करणे हा आहे. तुमच्या ऑथेंटिकेशन मॉडेलच्या आधारे (युजर-आधारित विरुद्ध डिव्हाइस-आधारित) युजर ग्रुप वापरायचा की डिव्हाइस ग्रुप हे ठरवा आणि तिन्ही प्रोफाइलवर ते सुसंगतपणे लागू करा.

Q2. सुरक्षा ऑडिटमध्ये असे दिसून आले आहे की जेव्हा एखाद्या कर्मचाऱ्याला कामावरून काढून टाकले जाते आणि त्याचे Microsoft Entra ID अकाउंट निष्क्रिय केले जाते, तेव्हा त्याचा कॉर्पोरेट स्मार्टफोन कामावरून काढल्यानंतरही एक आठवड्यापर्यंत स्टाफ WiFi नेटवर्कशी कनेक्ट होऊ शकतो.

टीप: अकाउंट निष्क्रिय केल्यानंतर सर्टिफिकेट अजूनही वैध आहे की नाही हे RADIUS सर्व्हर कसे ठरवतो याचा विचार करा. रिव्होकेशन (रद्द करण्याची) स्थिती कळवण्याची यंत्रणा काय आहे?

नमुना उत्तर पहा

RADIUS सर्व्हर कठोर Certificate Revocation List (CRL) तपासणी करत नाही किंवा CRL वारंवार प्रकाशित केले जात नाही. जेव्हा एखाद्या कर्मचाऱ्याला कामावरून काढले जाते, तेव्हा MDM ने डिव्हाइस अनएनरोल केले पाहिजे आणि CA ने सर्टिफिकेट रद्द केले पाहिजे. तथापि, जर RADIUS सर्व्हर प्रत्येक ऑथेंटिकेशनच्या वेळी CRL तपासत नसेल - किंवा CRL फक्त साप्ताहिक प्रकाशित केले जात असेल - तर रद्द केलेले सर्टिफिकेट स्वीकारले जाणे सुरूच राहते. यावरील उपायामध्ये तीन पायऱ्या समाविष्ट आहेत: प्रत्येक ऑथेंटिकेशनवर कठोर CRL तपासणी सक्तीची करण्यासाठी RADIUS सर्व्हर कॉन्फिगर करा; कमी अंतराने (दररोज किंवा अधिक वारंवार) CRL प्रकाशित करण्यासाठी CA कॉन्फिगर करा; आणि डिव्हाइस अनएनरोल झाल्यावर सर्टिफिकेट रद्द करण्यासाठी MDM कॉन्फिगर केले असल्याची खात्री करा.

Q3. तुम्हाला हेडलेस IoT डिव्हाइसेससाठी (स्मार्ट थर्मोस्टॅट्स, डिजिटल साइनेज प्लेयर्स) सुरक्षित WiFi ॲक्सेस प्रदान करायचा आहे जे MDM एजंट चालवू शकत नाहीत आणि Captive Portal दाखवू शकत नाहीत. तुम्ही या डिव्हाइसेससाठी SCEP वापरू शकता का, आणि नसल्यास, शिफारस केलेला पर्याय कोणता आहे?

टीप: SCEP एनरोलमेंटसाठी आवश्यक गोष्टींचा विचार करा आणि जे डिव्हाइसेस MDM-एनरोल होऊ शकत नाहीत किंवा ब्राउझरशी संवाद साधू शकत नाहीत त्यांच्यासाठी काय पर्याय उपलब्ध आहेत ते पहा.

नमुना उत्तर पहा

या डिव्हाइसेससाठी SCEP वापरता येणार नाही. SCEP ला एनरोलमेंट URL आणि चॅलेंज पासवर्ड प्राप्त करण्यासाठी, की पेअर तयार करण्यासाठी आणि परिणामी सर्टिफिकेट इंस्टॉल करण्यासाठी MDM एजंटची आवश्यकता असते. MDM एजंट चालवू न शकणारे हेडलेस IoT डिव्हाइसेस SCEP एनरोलमेंट प्रक्रियेत भाग घेऊ शकत नाहीत. शिफारस केलेले पर्याय खालीलप्रमाणे आहेत: (१) कठोर VLAN सेगमेंटेशनसह एकत्रित केलेले MAC Authentication Bypass (MAB) - RADIUS सर्व्हर डिव्हाइसला त्याच्या MAC ॲड्रेसच्या आधारे परवानगी देतो आणि कॉर्पोरेट सिस्टम्सचा ॲक्सेस नसलेल्या एका वेगळ्या IoT VLAN वर ठेवतो; (२) जर डिव्हाइस सपोर्ट करत असेल, तर EST (Enrollment over Secure Transport, RFC 7030) अशा डिव्हाइसेसना सर्टिफिकेट्स प्रदान करू शकते जे HTTPS ला सपोर्ट करतात पण MDM ला नाही; (३) मॅनेजमेंट इंटरफेस असलेल्या डिव्हाइसेससाठी, काही विक्रेते MDM एजंटची आवश्यकता नसताना थेट डिव्हाइस फर्मवेअरद्वारे SCEP एनरोलमेंटला सपोर्ट करतात. सर्व प्रकरणांमध्ये, वापरलेल्या ऑथेंटिकेशन पद्धतीचा विचार न करता IoT डिव्हाइसेस एका समर्पित VLAN वर वेगळे ठेवले पाहिजेत.

या मालिकेमध्ये पुढे वाचा

SCEP साठी एंटरप्राइझ मार्गदर्शक: स्वयंचलित कॅम्पस WiFi सुरक्षेसाठी सिम्पल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल तैनात करणे

हे तांत्रिक संदर्भ मार्गदर्शक SCEP चा वापर करून एंटरप्राइझ WiFi प्रमाणपत्र तैनातीसाठी एक निश्चित आर्किटेक्चरल ब्ल्यूप्रिंट आणि टप्प्याटप्प्याने अंमलबजावणीची रणनीती प्रदान करते. यामध्ये SCEP आणि PKCS मधील महत्त्वपूर्ण फरक, यशस्वीतेसाठी आवश्यक असलेला अचूक तैनातीचा क्रम आणि IT नेत्यांसाठी प्रत्यक्ष जगातील जोखीम कमी करण्याच्या धोरणांचा समावेश आहे.

स्वयंचलित WiFi प्रमाणपत्र नोंदणीसाठी SCEP कसे लागू करावे

हे मार्गदर्शक एंटरप्राइझ ठिकाणांवर स्वयंचलित WiFi प्रमाणपत्र नोंदणीसाठी SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल) कसे लागू करावे हे स्पष्ट करते. यामध्ये PKI डिझाइन आणि MDM इंटिग्रेशनपासून ते अनिवार्य तीन-चरण डिप्लॉयमेंट क्रमापर्यंतच्या संपूर्ण आर्किटेक्चरल ब्ल्यूप्रिंटचा समावेश आहे - आणि IT व्यवस्थापक आणि नेटवर्क आर्किटेक्ट्सना सामायिक क्रेडेंशियल्स कसे काढून टाकावे, प्रमाणपत्र लाइफसायकल व्यवस्थापन स्वयंचलित कसे करावे आणि मोठ्या प्रमाणावर PCI DSS आणि GDPR आवश्यकता कशा पूर्ण कराव्यात हे दाखवते.

Cisco SUDI समजून घेणे: नेटवर्क ॲक्सेस कंट्रोलमधील हार्डवेअर-आधारित डिव्हाइस ओळख

हे मार्गदर्शक Cisco SUDI च्या तांत्रिक आर्किटेक्चरचे सविस्तर वर्णन करते, ज्यामध्ये हार्डवेअर-अँकर्ड ओळख नेटवर्क ॲक्सेस कंट्रोलला कशी सुरक्षित करते हे स्पष्ट केले आहे. हे IT लीडर्सना एंटरप्राइझ ठिकाणी 802.1X EAP-TLS ऑथेंटिकेशन तैनात करण्यासाठी आणि Zero Touch Provisioning स्वयंचलित करण्यासाठी व्यावहारिक अंमलबजावणीच्या पायऱ्या प्रदान करते.