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

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

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

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

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

परिचय आणि संदर्भ - 0:00 ते 1:00

नमस्कार, आणि Purple च्या या तांत्रिक माहिती सत्रात (technical briefing) आपले स्वागत आहे. आज आपण SCEP, म्हणजेच Simple Certificate Enrollment Protocol, आणि स्वयंचलित WiFi प्रमाणपत्र नोंदणीसाठी (automated WiFi certificate enrollment) त्याची अंमलबजावणी कशी करावी, याबद्दल सविस्तर माहिती घेणार आहोत. जर तुम्ही नेटवर्क आर्किटेक्ट, IT संचालक असाल किंवा रिटेल चेन्स, हॉस्पिटल्स किंवा स्टेडियम्स सारख्या मोठ्या ठिकाणांसाठी इन्फ्रास्ट्रक्चर व्यवस्थापित करत असाल, तर हे सत्र तुमच्यासाठीच आहे. आम्ही थेट मुद्द्यावर बोलणार आहोत की मोठ्या प्रमाणावर EAP-TLS कसे तैनात करावे, डिव्हाइस ओळखीसाठी SCEP हाच योग्य पर्याय का आहे आणि तुम्ही तुमच्या वातावरणात ते व्यावहारिकरित्या कसे तैनात करू शकता. चला, थेट विषयाला सुरुवात करूया.

तांत्रिक सखोल विश्लेषण (TECHNICAL DEEP-DIVE) - 1:00 ते 6:00

तर, आपण येथे नेमकी कोणती समस्या सोडवत आहोत? एंटरप्राइझ WiFi सुरक्षेच्या जगात, EAP-TLS हे सर्वोत्तम मानक मानले जाते. PEAP किंवा EAP-TTLS सारख्या जुन्या पद्धती, ज्या वापरकर्त्याच्या पासवर्डवर अवलंबून असतात, त्यांच्यापेक्षा वेगळे म्हणजे EAP-TLS हे परस्पर प्रमाणपत्र-आधारित प्रमाणीकरण (mutual certificate-based authentication) अनिवार्य करते. याचा अर्थ असा की क्लायंट डिव्हाइसने सर्व्हर प्रमाणपत्राद्वारे नेटवर्कची ओळख सत्यापित केली पाहिजे आणि नेटवर्कने अनन्य (unique) क्लायंट प्रमाणपत्राद्वारे क्लायंटची ओळख सत्यापित केली पाहिजे.

पासवर्डच्या असुरक्षिततेचा विचार करा. ते शेअर केले जाऊ शकतात, फिशिंगद्वारे मिळवले जाऊ शकतात किंवा चोरीला जाऊ शकतात. एका विस्तीर्ण एंटरप्राइझ वातावरणात, तडजोड केलेला पासवर्ड एखाद्या चुकीच्या व्यक्तीला तुमच्या संपूर्ण अंतर्गत नेटवर्कमध्ये प्रवेश देऊ शकतो. EAP-TLS हा धोका पूर्णपणे काढून टाकतो. हे प्रमाणीकरण पब्लिक की इन्फ्रास्ट्रक्चर (PKI) द्वारे जारी केलेल्या X.509 प्रमाणपत्रांवर अवलंबून असते.

पण EAP-TLS मधील मुख्य आव्हान हे स्वतः प्रोटोकॉलचे नाही. तर हजारो डिव्हाइसेसवर - मग ते Windows लॅपटॉप असोत, iPads असोत किंवा पॉइंट-ऑफ-सेल टॅब्लेट्स असोत - अनन्य क्लायंट प्रमाणपत्रे पोहोचवण्याचे व्यवस्थापन (logistics) हे आहे. तुम्ही हजारो डिव्हाइसेसवर मॅन्युअली प्रमाणपत्रे स्थापित करू शकत नाही. इथेच Microsoft Intune किंवा Jamf सारखे मोबाईल डिव्हाइस मॅनेजमेंट (MDM) प्लॅटफॉर्म्स उपयोगात येतात. पण तुम्ही ती प्रमाणपत्रे सुरक्षितपणे कशी वितरित करता?

तुमच्याकडे साधारणपणे दोन पर्याय असतात: PKCS किंवा SCEP. मला यावर अगदी स्पष्टपणे सांगू द्या. WiFi प्रमाणीकरणासाठी, तुम्हाला SCEP हवे आहे. हे का महत्त्वाचे आहे ते येथे आहे. SCEP सह, MDM एंडपॉइंट डिव्हाइसला त्याची स्वतःची खाजगी की (private key) स्थानिक पातळीवर तयार करण्याचे निर्देश देते. ती की डिव्हाइसच्या सुरक्षित हार्डवेअरमध्ये लॉक राहते. ती कधीही नेटवर्कवर प्रवास करत नाही. डिव्हाइस फक्त गेटवेद्वारे (सहसा NDES सर्व्हर) तुमच्या सर्टिफिकेट ऑथॉरिटीला (Certificate Authority) सर्टिफिकेट साइनिंग रिक्वेस्ट (Certificate Signing Request) पाठवते.

याउलट PKCS मध्ये, सर्टिफिकेट ऑथॉरिटी मध्यवर्ती पातळीवर खाजगी की तयार करते आणि ती नेटवर्कवरून डिव्हाइसवर पाठवते. PKCS चे स्वतःचे स्थान असले तरी, समजा ईमेल एन्क्रिप्शनसाठी जिथे तुम्हाला की एस्क्रोची (key escrow) आवश्यकता असते, नेटवर्कवर खाजगी की पाठवणे हा एक असा धोका आहे जो तुम्हाला नेटवर्क प्रमाणीकरणासाठी घेण्याची गरज नाही. की डिव्हाइसवरच ठेवा. SCEP वापरा.

आता, अंमलबजावणीबद्दल बोलूया. जर तुम्ही या सत्रातून एक गोष्ट लक्षात ठेवणार असाल, तर ती म्हणजे हा मूलभूत नियम: प्रमाणीकरणापूर्वी विश्वास (Trust before Authentication). तुम्ही फक्त WiFi प्रोफाइल पाठवून ते कार्य करेल अशी अपेक्षा करू शकत नाही. येथे एक कठोर, तीन-चरणांचा उपयोजन क्रम (deployment sequence) आहे ज्याचे तुम्ही पालन केले पाहिजे.

पायरी १: Trusted Root Certificate तैनात करा. डिव्हाइसने क्लायंट प्रमाणपत्राची विनंती करण्यापूर्वी किंवा तुमच्या RADIUS सर्व्हरवर विश्वास ठेवण्यापूर्वी, त्याने जारी करणाऱ्या Certificate Authority वर विश्वास ठेवला पाहिजे. हे प्रोफाइल आधी पुश करा.

पायरी २: SCEP Certificate Profile कॉन्फिगर आणि पुश करा. हे डिव्हाइसला SCEP गेटवेशी कसे संवाद साधायचा, त्याच्या सब्जेक्ट नेमसाठी कोणते फॉरमॅट वापरायचे आणि प्रमाणपत्र प्रत्यक्षात कशासाठी आहे हे सांगते. या प्रकरणात, क्लायंट ऑथेंटिकेशन. तुम्ही हे प्रोफाइल पायरी १ मध्ये तैनात केलेल्या Trusted Root शी लिंक करणे आवश्यक आहे.

पायरी ३: 802.1X WiFi प्रोफाइल तैनात करा. येथे तुम्ही हे सर्व एकत्र जोडता. तुम्ही SSID निर्दिष्ट करता, WPA3-Enterprise निवडा, EAP प्रकार EAP-TLS वर सेट करा आणि क्लायंट ऑथेंटिकेशनसाठी SCEP प्रमाणपत्राकडे निर्देशित करा.

अंमलबजावणीच्या शिफारसी आणि त्रुटी - ६:०० ते ८:००

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

चला एका वास्तविक जगातील परिस्थितीकडे पाहूया. एका २०० खोल्यांच्या हॉटेलची कल्पना करा. त्यांच्याकडे हाऊसकीपिंग स्टाफसाठी १५० व्यवस्थापित iOS डिव्हाइसेस आहेत. सध्या, ते एक मानक पासवर्ड नेटवर्क वापरतात आणि कर्मचारी पाहुण्यांसोबत पासवर्ड शेअर करत राहतात. ही एक खरी ऑपरेशनल डोकेदुखी आहे. SCEP द्वारे EAP-TLS सह WPA2-Enterprise वर स्थलांतरित करून, IT संचालक पासवर्ड पूर्णपणे काढून टाकतात. iOS डिव्हाइसेस त्यांच्या प्रमाणपत्रांचा वापर करून बॅकग्राउंडमध्ये शांतपणे ऑथेंटिकेट होतात.

पण जर एखाद्या हाऊसकीपरने डिव्हाइस गमावले किंवा कंपनी सोडली तर काय होईल? त्यांचे Active Directory खाते निष्क्रिय करणे पुरेसे नाही, कारण त्या डिव्हाइसवरील प्रमाणपत्र अद्याप क्रिप्टोग्राफिकदृष्ट्या वैध आहे. हे आपल्याला एका महत्त्वपूर्ण सुरक्षा नियंत्रणाकडे आणते: कडक CRL चेकिंग. तुम्ही Certificate Revocation List तपासण्यासाठी तुमचा RADIUS सर्व्हर कॉन्फिगर करणे आवश्यक आहे. एखादे डिव्हाइस गहाळ झाल्यास, तुम्ही CA वर प्रमाणपत्र रद्द करता. RADIUS सर्व्हर CRL वर हे रद्द करणे पाहतो आणि त्वरित नेटवर्क प्रवेश ब्लॉक करतो. कडक CRL चेकिंगशिवाय, तुमची सुरक्षा स्थिती अपूर्ण आहे.

रॅपिड-फायर प्रश्नोत्तरे - ८:०० ते ९:००

चला CTOs कडून आम्ही वारंवार ऐकतो अशा काही रॅपिड-फायर प्रश्नांची उत्तरे शोधूया.

प्रश्न १: WPA3 Enterprise साठी EAP-TLS आवश्यक आहे का? जरी WPA3 Enterprise इतर पद्धतींना सपोर्ट करत असले, तरी EAP-TLS ची जोरदार शिफारस केली जाते आणि जर तुम्ही WPA3 Enterprise 192-bit सुरक्षा सूट (ज्याला सहसा Suite B म्हटले जाते) लागू करत असाल तर ते आवश्यक आहे.

प्रश्न २: आम्ही क्लायंटसाठी सार्वजनिक प्रमाणपत्रे वापरू शकतो का? नाही. तुम्ही क्लायंट प्रमाणपत्रांसाठी खाजगी अंतर्गत CA वापरणे आवश्यक आहे. सार्वजनिक CA हे सार्वजनिक-फेसिंग वेब सर्व्हरसाठी असतात. तुमच्या कॉर्पोरेट डिव्हाइसेसचे प्रमाणीकरण करण्यासाठी तुमच्या अंतर्गत RADIUS सर्व्हरने तुमच्या विशिष्ट अंतर्गत Root CA वर विश्वास ठेवणे आवश्यक आहे.

प्रश्न तिसरा: हे OpenRoaming सोबत कसे जुळते? OpenRoaming हे Passpoint आणि 802.1X वर अवलंबून असते. Purple हे Connect लायसन्स अंतर्गत OpenRoaming सारख्या सेवांसाठी विनामूल्य ओळख प्रदाता (identity provider) म्हणून काम करते, जे मूळ प्रमाणपत्र आणि ओळख फ्रेमवर्कचा वापर करून विविध ठिकाणांवर अखंड, सुरक्षित रोमिंग सुलभ करते.

सारांश आणि पुढील पावले - ९:०० ते १०:००

शेवटी सांगायचे तर, स्वयंचलित SCEP प्रमाणपत्र उपयोजनाकडे (deployment) स्थलांतरित केल्याने वास्तविक, मोजता येण्याजोगा परतावा मिळतो. तुम्हाला WiFi-संबंधित हेल्पडेस्क तिकिटांमध्ये ७० ते ८० टक्के घट दिसेल, कारण वापरकर्ते सिस्टीममधून बाहेर फेकले जात नाहीत किंवा चुकीचे पासवर्ड टाईप करत नाहीत. सर्वात महत्त्वाचे म्हणजे, तुम्ही क्रेडेंशियल हार्वेस्टिंगचा धोका काढून टाकता, ज्यामुळे तुम्ही PCI DSS आणि GDPR सारख्या अनुपालन फ्रेमवर्कची पूर्तता करत असल्याची खात्री होते.

एंटरप्राइझ WiFi सुरक्षा स्वयंचलित करणे म्हणजे केवळ गोष्टी लॉक करणे नव्हे. तर सुरक्षित मार्ग हा तुमच्या वापरकर्त्यांसाठी सर्वात सोपा मार्ग बनवणे आहे. तुमची पुढील पावले: तुमच्या सध्याच्या 802.1X उपयोजनाचे ऑडिट करा. जर तुम्ही अजूनही पासवर्डवर अवलंबून असाल, तर तुमच्या PKI ची रचना करा आणि SCEP सह EAP-TLS वर स्थलांतर करण्याचे नियोजन करा. तुमचा RADIUS सर्व्हर कठोर CRL किंवा OCSP तपासणी लागू करत आहे की नाही ते तपासा. आणि तुमचे तिन्ही उपयोजन प्रोफाइल्स एकाच ग्रुपला लक्ष्य करत असल्याची पडताळणी करा.

Purple कडून हे तांत्रिक ब्रीफिंग ऐकल्याबद्दल धन्यवाद. अधिक तपशीलवार उपयोजन मार्गदर्शकांसाठी आणि आमचे विश्लेषण आणि ओळख प्लॅटफॉर्म तुमच्या सुरक्षित नेटवर्कसह कसे समाकलित होऊ शकतात हे समजून घेण्यासाठी, purple dot ai ला भेट द्या.

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

✓SCEP (RFC 8894) व्यवस्थापित उपकरणांसाठी X.509 प्रमाणपत्र नोंदणी स्वयंचलित करते. खाजगी की (private key) स्थानिक पातळीवर उपकरणावरच तयार केली जाते आणि ती कधीही नेटवर्कवर प्रसारित केली जात नाही - PKCS च्या तुलनेत हाच मुख्य सुरक्षा फायदा आहे.
✓802.1X EAP-TLS WiFi प्रमाणीकरणासाठी (authentication), नेहमी SCEP वापरा. S/MIME ईमेल एन्क्रिप्शन सारख्या की एस्क्रो (key escrow) आवश्यक असणाऱ्या वापराच्या प्रकरणांसाठी PKCS राखून ठेवा.
✓उपयोजन (deployment) क्रम बदलता येणार नाही: प्रथम Trusted Root Certificate, नंतर SCEP Certificate Profile, आणि नंतर 802.1X WiFi Profile. हे तिन्ही प्रोफाईल अगदी एकाच Azure AD ग्रुपला लक्ष्य केलेले असावेत.
✓RADIUS सर्व्हरवर कठोर CRL किंवा OCSP तपासणी अनिवार्य आहे. AD खाते निष्क्रिय केल्याने प्रमाणपत्र रद्द होत नाही. CA वर ते रद्द करा आणि RADIUS सर्व्हर त्यानुसार कारवाई करत असल्याची खात्री करा.
✓EAP-TLS नेटवर्क लेयरवर मल्टी-फॅक्टर प्रमाणीकरणासाठी PCI DSS 4.0 आवश्यकता 8.6 पूर्ण करते आणि WPA3 Enterprise 192-bit (Suite B) उपयोजनांसाठी ते आवश्यक आहे.
✓पासवर्ड-आधारित WiFi वरून SCEP सह EAP-TLS वर स्थलांतरित होणाऱ्या संस्था सामान्यतः WiFi-संबंधित हेल्पडेस्क तिकिटांमध्ये ७०-८०% घट नोंदवतात (Purple अंतर्गत डेटा, २०२४).
✓वितरित मालमत्तेसाठी (हॉटेल गट, रिटेल साखळी, बहु-साइट सार्वजनिक-क्षेत्र), क्लाउड-होस्ट केलेले SCEP गेटवे आणि व्यवस्थापित PKI सेवा सुरक्षेशी तडजोड न करता ऑन-प्रिमाइसेस NDES पायाभूत सुविधांची आवश्यकता काढून टाकतात.

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

हॉटेल्स, रिटेल इस्टेट, स्टेडियम आणि कॉन्फरन्स सेंटर्समध्ये Guest WiFi चालवणाऱ्या व्हेन्यू ऑपरेटर्ससाठी, कर्मचाऱ्यांच्या नेटवर्क ॲक्सेससाठी प्री-शेअर्ड की किंवा बेसिक Captive Portals वर अवलंबून राहणे ही सुरक्षेच्या दृष्टीने एक जोखीम आहे. आधुनिक नेटवर्क आर्किटेक्चरसाठी EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) वापरून 802.1X ऑथेंटिकेशन आवश्यक आहे, ज्यामुळे प्रत्येक डिव्हाइस नेटवर्कला जोडण्यापूर्वी त्याचे क्रिप्टोग्राफिकली प्रमाणीकरण केले जाते. याचे मुख्य आव्हान वितरणाचे आहे: तुमच्या हेल्पडेस्कवर कामाचा ताण न वाढवता हजारो Windows, iOS आणि Android डिव्हाइसेसवर युनिक क्लायंट सर्टिफिकेट्स कशी तैनात करायची?

याचे उत्तर SCEP - Simple Certificate Enrollment Protocol हे आहे. 2020 मध्ये IETF द्वारे RFC 8894 म्हणून औपचारिक रूप दिलेले, SCEP व्यवस्थापित डिव्हाइस फ्लीट्समध्ये सर्टिफिकेट एनरोलमेंट स्वयंचलित करते. जेव्हा Microsoft Intune किंवा Jamf सारख्या MDM प्लॅटफॉर्मसह समाकलित (integrate) केले जाते, तेव्हा SCEP झिरो-टच सर्टिफिकेट प्रोव्हिजनिंग प्रदान करते: डिव्हाइसेस कोणत्याही IT हस्तक्षेपाशिवाय स्वतःच्या सर्टिफिकेट्सची विनंती करतात, ती प्राप्त करतात आणि नूतनीकरण करतात. प्रायव्हेट की स्थानिक पातळीवर डिव्हाइसवर जनरेट केली जाते आणि ती कधीही नेटवर्कवर ट्रान्समिट केली जात नाही - PKCS-आधारित वितरणापेक्षा हा एक मूलभूत सुरक्षा फायदा आहे.

हे मार्गदर्शक संपूर्ण SCEP अंमलबजावणी वर्कफ्लोचे मार्गदर्शन करते: PKI आर्किटेक्चर, NDES गेटवे कॉन्फिगरेशन, अनिवार्य तीन-चरण MDM डिप्लॉयमेंट सिक्वेन्स आणि ऑपरेशनल कंट्रोल्स - विशेषतः CRL चेकिंग आणि ग्रुप टार्गेटिंग - जे रोलआउट यशस्वी होईल की रखडेल हे ठरवतात. दोन वास्तविक-जगातील उदाहरणे हॉस्पिटॅलिटी आणि रिटेल वातावरणातील दृष्टिकोन स्पष्ट करतात. Purple हे 80,000+ पेक्षा जास्त लाइव्ह व्हेन्यू आणि 350 दशलक्ष युनिक युजर्सवर कार्यरत आहे; येथे वर्णन केलेले पॅटर्न त्या स्केलवर काय प्रभावी ठरते हे दर्शवतात.

तांत्रिक सखोल विश्लेषण (Technical deep-dive)

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

SCEP तुमच्या MDM प्लॅटफॉर्म आणि तुमच्या Certificate Authority (CA) च्या दरम्यान कार्य करते. हे डिव्हाइसेसना डोमेन-जॉइन्ड क्रेडेंशियल किंवा मॅन्युअल ॲडमिनिस्ट्रेटरच्या हस्तक्षेपाशिवाय X.509 सर्टिफिकेट्सची विनंती करण्यासाठी, ती प्राप्त करण्यासाठी आणि नूतनीकरण करण्यासाठी एक प्रमाणित HTTP-आधारित यंत्रणा प्रदान करते. हा प्रोटोकॉल मूळतः 2000 च्या दशकाच्या सुरुवातीला विकसित केला गेला होता आणि IETF ने औपचारिकपणे RFC 8894 म्हणून प्रकाशित करण्यापूर्वी एंटरप्राइझ MDM वातावरणात मोठ्या प्रमाणावर स्वीकारला गेला होता.

सहा-चरण नोंदणी प्रवाह खालीलप्रमाणे कार्य करतो. प्रथम, व्यवस्थापित डिव्हाइस त्याच्या MDM प्रोफाइलमध्ये पूर्व-कॉन्फिगर केलेल्या SCEP गेटवे URL शी कनेक्ट होते. दुसरे, डिव्हाइस स्थानिक पातळीवर एक खाजगी/सार्वजनिक की जोडी (private/public key pair) तयार करते आणि प्रमाणपत्र स्वाक्षरी विनंती (CSR) तयार करते. तिसरे, SCEP गेटवे MDM पॉलिसीमध्ये एम्बेड केलेल्या चॅलेंज पासवर्ड किंवा OTP चा वापर करून डिव्हाइसच्या अधिकृततेची पडताळणी करतो. चौथे, गेटवे पडताळणी केलेले CSR हे CA कडे फॉरवर्ड करतो. पाचवे, CA प्रमाणपत्रावर स्वाक्षरी करतो आणि ते गेटवेकडे परत करतो. सहावे, गेटवे स्वाक्षरी केलेले प्रमाणपत्र डिव्हाइसला वितरित करतो. भविष्यातील नूतनीकरणे याच स्वयंचलित मार्गाचा अवलंब करतात - डिव्हाइस कोणत्याही वापरकर्त्याच्या किंवा प्रशासकाच्या हस्तक्षेपाशिवाय कालबाह्य होण्यापूर्वी पुन्हा नोंदणी करते.

SCEP विरुद्ध PKCS: महत्त्वाचा निर्णय

Microsoft Intune आणि बहुतेक MDM प्लॅटफॉर्म दोन प्रमाणपत्र वितरण यंत्रणांना समर्थन देतात: SCEP आणि PKCS. यामधील फरक आर्किटेक्चरल आहे, केवळ वरवरचा नाही.

SCEP सह, खाजगी की डिव्हाइसवर तयार केली जाते आणि तिथेच राहते. CA ती कधीही पाहत नाही. डिव्हाइसचे TPM (Windows वर) किंवा Secure Enclave (iOS/macOS वर) हार्डवेअर पातळीवर की सुरक्षित ठेवते. PKCS सह, CA मध्यवर्ती ठिकाणी की जोडी तयार करतो आणि नेटवर्कद्वारे डिव्हाइसवर प्रसारित करतो. CA कडे एक प्रत राहते, ज्यामुळे की एस्क्रो (key escrow) सक्षम होते - जे S/MIME ईमेल एन्क्रिप्शनसाठी उपयुक्त आहे परंतु नेटवर्क प्रमाणीकरणासाठी अनावश्यक जोखीम निर्माण करते.

802.1X WiFi प्रमाणीकरणासाठी, SCEP वापरा. खाजगी की कधीही डिव्हाइस सोडत नाही. हा नियम आहे.

निकष	SCEP	PKCS
खाजगी की येथे तयार होते	डिव्हाइस	CA (मध्यवर्ती)
खाजगी की नेटवर्कवर प्रसारित होते	कधीही नाही	होय
TPM / Secure Enclave ला समर्थन देते	होय	नाही
WiFi प्रमाणीकरणासाठी शिफारस केलेले	होय	नाही
ईमेल एन्क्रिप्शनसाठी (S/MIME) शिफारस केलेले	नाही	होय
की एस्क्रो शक्य आहे	नाही	होय

802.1X आणि EAP-TLS: प्रमाणीकरण फ्रेमवर्क

IEEE 802.1X हे पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोल मानक आहे जे एंटरप्राइझ WiFi सुरक्षेचा पाया आहे. हे तीन भूमिका परिभाषित करते: सप्लिकंट (क्लायंट डिव्हाइस), ऑथेंटिकेटर (ॲक्सेस पॉइंट - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, किंवा Fortinet), आणि ऑथेंटिकेशन सर्व्हर (एक RADIUS सर्व्हर जसे की Microsoft NPS, FreeRADIUS, किंवा Cisco ISE).

802.1X साठी EAP-TLS ही सर्वात सुरक्षित EAP पद्धत आहे. दोन्ही बाजू प्रमाणपत्रे सादर करतात: RADIUS सर्व्हर क्लायंटला त्याचे प्रमाणपत्र सादर करतो आणि क्लायंट त्याचे SCEP-प्रोविझन्ड प्रमाणपत्र RADIUS सर्व्हरला सादर करतो. विश्वसनीय CA पदानुक्रमातील वैध, रद्द न केलेल्या प्रमाणपत्राशिवाय कोणतीही बाजू दुसऱ्याचे रूप धारण करू शकत नाही. हे परस्पर प्रमाणीकरण मॉडेल एकाच आर्किटेक्चरल निर्णयामध्ये क्रेडेंशियल चोरी, इव्हिल ट्विन (Evil Twin) हल्ले आणि रॉग ॲक्सेस पॉइंटचे धोके दूर करते.

EAP-TLS नेटवर्क लेयरवर मल्टी-फॅक्टर ऑथेंटिकेशनसाठी PCI DSS 4.0 ची आवश्यकता 8.6 पूर्ण करते. WPA3 Enterprise 192-bit (Suite B) उपयोजनांसाठी हे आवश्यक आहे. कार्डधारक डेटा प्रक्रियेच्या कक्षेत येणाऱ्या कोणत्याही वायरलेस नेटवर्कसाठी - रिटेल पॉइंट-ऑफ-सेल, हॉटेल फ्रंट डेस्क, स्टेडियम तिकीट - EAP-TLS हा योग्य पर्याय आहे.

secure WiFi आर्किटेक्चर आणि प्रमाणपत्र-आधारित प्रमाणीकरण व्यापक सुरक्षा स्थितीमध्ये कसे बसते याच्या सखोल माहितीसाठी, आमचे आवश्यक मार्गदर्शक पहा.

अंमलबजावणी मार्गदर्शक

उपयोजन क्रम बदलता येणार नाही. Intune आणि Jamf प्रोफाइल अवलंबित्व क्रमाने सोडवतात: WiFi प्रोफाइल SCEP प्रोफाइलवर अवलंबून असते, जे Trusted Root प्रोफाइलवर अवलंबून असते. ते चुकीच्या क्रमाने उपयोजित केल्यास WiFi प्रोफाइल लागू होण्यात अपयशी ठरेल.

पायरी १: तुमचे PKI डिझाइन करा

तुम्ही MDM कन्सोलला स्पर्श करण्यापूर्वी, तुमचे प्रमाणपत्र पदानुक्रम डिझाइन करा. टू-टियर PKI हे मानक आहे: एक ऑफलाइन रूट CA आणि एक ऑनलाइन जारी करणारे CA. रूट CA ची खाजगी की तुमच्या संपूर्ण प्रमाणपत्र पायाभूत सुविधांसाठी मुख्य ट्रस्ट अँकर आहे - ती एअर-गॅप्ड ठेवा. जारी करणारे CA दैनंदिन प्रमाणपत्र जारी करण्याचे काम हाताळते आणि प्रमाणपत्र रद्द करण्याची सूची (CRL) आणि OCSP रिस्पॉन्डर प्रकाशित करते.

बऱ्याच एंटरप्राइझ ठिकाणांच्या उपयोजनांसाठी, Windows Server वर चालणारी Microsoft Active Directory Certificate Services (AD CS) जारी करणारे CA प्रदान करते. SCEPman किंवा SecureW2 सारख्या प्रदात्यांकडून क्लाउड-होस्ट केलेल्या PKI सेवा ऑन-प्रिमाइसेस पायाभूत सुविधांची आवश्यकता पूर्णपणे काढून टाकतात आणि हॉटेल गट, रिटेल साखळी किंवा बहु-साइट सार्वजनिक-क्षेत्रातील संस्थांमध्ये वितरित मालमत्ता उपयोजनांसाठी त्यांचे मूल्यांकन करणे योग्य आहे.

पायरी २: NDES सर्व्हर (किंवा क्लाउड SCEP गेटवे) उपयोजित करा

NDES (Network Device Enrollment Service) ही Microsoft Windows Server ची भूमिका आहे जी तुमच्या MDM आणि तुमच्या CA दरम्यान SCEP गेटवे म्हणून काम करते. मुख्य कॉन्फिगरेशन आवश्यकता:

Azure AD Application Proxy (किंवा समतुल्य रिव्हर्स प्रॉक्सी) द्वारे NDES URL बाह्यरित्या प्रकाशित करा. हे रिमोट डिव्हाइसेसना इनबाउंड फायरवॉल पोर्ट न उघडता, साइटवर येण्यापूर्वी नोंदणी करण्याची परवानगी देते.
NDES सेवा खात्याला CA प्रमाणपत्र टेम्पलेटवर वाचण्याची (Read) आणि नोंदणी करण्याची (Enroll) परवानगी आवश्यक आहे.
की वापर (Key Usage) डिजिटल स्वाक्षरी (Digital Signature) आणि की एन्सायफरमेंट (Key Encipherment) वर सेट करून प्रमाणपत्र टेम्पलेट कॉन्फिगर करा आणि विस्तारित की वापर (Extended Key Usage) क्लायंट प्रमाणीकरण (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2) वर सेट करा.
योग्य प्रमाणपत्र वैधता कालावधी सेट करा. क्लायंट प्रमाणपत्रांसाठी एक वर्ष हे मानक आहे; स्थिर उपकरणांच्या ताफ्यातील डिव्हाइस प्रमाणपत्रांसाठी दोन वर्षे स्वीकार्य आहे. तुम्ही ऑन-प्रिमाइसेस NDES इन्फ्रास्ट्रक्चर टाळण्यास प्राधान्य देत असल्यास, क्लाउड SCEP गेटवे थेट API द्वारे Intune आणि तुमच्या CA सोबत समाकलित होतात, ज्यामुळे IIS वरील अवलंबित्व पूर्णपणे नाहीसे होते.

पायरी ३: Trusted Root Certificate प्रोफाइल उपयोजित (Deploy) करा

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

महत्त्वाचा नियम: तिन्ही संबंधित प्रोफाइल्समध्ये नेहमी एकाच Azure AD ग्रुपला (एकतर वापरकर्ते किंवा डिव्हाइसेस) लक्ष्य करा. येथील विसंगती हे WiFi प्रोफाइल उपयोजन अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.

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

तुमच्या MDM मध्ये SCEP प्रमाणपत्र कॉन्फिगरेशन प्रोफाइल तयार करा:

Subject name format: वापरकर्ता-चालित प्रमाणीकरणासाठी, CN={{UserPrincipalName}} वापरा. डिव्हाइस प्रमाणीकरणासाठी (सामायिक डिव्हाइसेस आणि IoT साठी शिफारस केलेले), 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).
SCEP server URL: बाह्यरित्या प्रकाशित केलेली NDES URL.
Root certificate: पायरी ३ मधील Trusted Root प्रोफाइलशी लिंक करा.
Certificate validity period: CA वर कॉन्फिगर केलेल्या टेम्पलेटशी जुळणारे ठेवा.

पायरी ५: 802.1X WiFi प्रोफाइल उपयोजित (Deploy) करा

एक WiFi कॉन्फिगरेशन प्रोफाइल तयार करा:

SSID: तुमच्या ॲक्सेस पॉइंट्सद्वारे ब्रॉडकास्ट केल्याप्रमाणे नेटवर्कचे नाव अचूक प्रविष्ट करा.
Security type: WPA2-Enterprise किंवा WPA3-Enterprise.
EAP type: EAP-TLS.
Client authentication certificate: पायरी ४ मधील SCEP प्रमाणपत्र प्रोफाइल निवडा.
Server validation: पायरी ३ मधील Trusted Root प्रमाणपत्र निर्दिष्ट करा आणि अपेक्षित RADIUS सर्व्हरचे नाव प्रविष्ट करा. हे डिव्हाइसेसना बनावट प्रमाणपत्रे सादर करणाऱ्या फसव्या ॲक्सेस पॉइंट्सशी कनेक्ट होण्यापासून रोखते.

सर्वोत्तम पद्धती

तुमच्या RADIUS सर्व्हरवर कठोर CRL तपासणी लागू करा

प्रमाणपत्र रद्द करणे (Certificate revocation) हे ते ऑपरेशनल नियंत्रण आहे जे खाते निष्क्रिय करणे आणि नेटवर्क प्रवेश अवरोधित करणे यामधील अंतर भरून काढते. जेव्हा एखादे डिव्हाइस हरवते, चोरीला जाते किंवा एखादा कर्मचारी नोकरी सोडतो, तेव्हा AD खाते निष्क्रिय करा आणि CA कडील प्रमाणपत्र रद्द करा. तुमचा RADIUS सर्व्हर प्रत्येक प्रमाणीकरण प्रयत्नावर CRL तपासण्यासाठी कॉन्फिगर केलेला असणे आवश्यक आहे. जर CRL अनुपलब्ध असेल - कारण CDP (CRL Distribution Point) पर्यंत पोहोचता येत नाही - तर बहुतेक RADIUS सर्व्हर डीफॉल्टनुसार प्रवेश खुला ठेवतात (fail open), जो एक सुरक्षा धोका आहे. तुमचे CDPs अत्यंत उपलब्ध आहेत आणि जर CRL मिळवता आले नाही तर तुमचा RADIUS सर्व्हर प्रवेश बंद करण्यासाठी (fail closed) कॉन्फिगर केला असल्याची खात्री करा.

रिअल-टाइम रद्दीकरणासाठी, CRL व्यतिरिक्त OCSP (Online Certificate Status Protocol) कॉन्फिगर करा. OCSP मुळे RADIUS सर्व्हरला संपूर्ण CRL डाउनलोड आणि पार्स न करता प्रत्येक प्रमाणपत्राची स्वतंत्र स्थिती समजते.

सामायिक आणि IoT उपकरणांसाठी डिव्हाइस प्रमाणपत्रे वापरा

सामायिक उपकरणांसाठी - हॉटेल हाउसकीपिंग टॅब्लेट, रिटेल POS टर्मिनल्स, स्टेडियम ॲक्सेस कंट्रोल रीडर्स - वापरकर्ता प्रमाणपत्रांऐवजी डिव्हाइस प्रमाणपत्रे वापरा. डिव्हाइस प्रमाणपत्रे मशीनच्या ओळखीशी जोडलेली असतात, वापरकर्ता खात्याशी नाही. याचा अर्थ असा की कोणता वापरकर्ता लॉग इन आहे याकडे दुर्लक्ष करून डिव्हाइस प्रमाणीकृत होते, आणि ते रद्द करणे कर्मचाऱ्याच्या जाण्याऐवजी डिव्हाइस रेकॉर्डशी जोडलेले असते.

retail उपयोजनांसाठी, POS हार्डवेअरवरील डिव्हाइस प्रमाणपत्रे विक्रीच्या ठिकाणी वापरकर्ता-प्रमाणपत्राची गुंतागुंत न आणता नेटवर्क-लेयर डिव्हाइस ओळखीसाठी PCI DSS आवश्यकता देखील पूर्ण करतात.

प्रमाणपत्र नूतनीकरण स्वयंचलित करा

SCEP स्वयंचलित नूतनीकरणास समर्थन देते: MDM प्रमाणपत्र कालबाह्य होण्यापूर्वी डिव्हाइसला पुन्हा नोंदणी करण्याचे निर्देश देते. प्रमाणपत्राच्या उर्वरित वैधता कालावधीच्या 20% वर नूतनीकरण सुरू करण्यासाठी तुमचे SCEP प्रोफाइल कॉन्फिगर करा. एक वर्षाच्या प्रमाणपत्रासाठी, नूतनीकरण कालबाह्य होण्याच्या अंदाजे 73 दिवस आधी सुरू होते. ही विंडो प्रमाणपत्र कालबाह्य होण्यापूर्वी आणि उपकरणांचे नेटवर्क ॲक्सेस गमावण्यापूर्वी कोणत्याही नूतनीकरण अपयशांचे निराकरण करण्यासाठी पुरेसा वेळ देते.

कालबाह्य झालेली प्रमाणपत्रे ज्यामुळे मोठ्या प्रमाणावर प्रमाणीकरण अपयश येते ही 802.1X उपयोजनांमधील सर्वात सामान्य कार्यात्मक घटना आहे. SCEP द्वारे स्वयंचलित नूतनीकरण हा धोका पूर्णपणे काढून टाकते.

प्रमाणपत्र गुणधर्माद्वारे नेटवर्कचे वर्गीकरण करा

RADIUS सर्व्हर प्रमाणपत्र गुणधर्म वाचू शकतात - Subject, SAN, किंवा सानुकूल OIDs - आणि उपकरणांना डायनॅमिकपणे VLANs मध्ये नियुक्त करण्यासाठी त्यांचा वापर करू शकतात. HousekeepingDevices टेम्पलेटमधून जारी केलेल्या प्रमाणपत्रासह हाउसकीपिंग टॅब्लेट हाउसकीपिंग VLAN वर पोहोचतो. RetailPOS टेम्पलेटमधील प्रमाणपत्रासह POS टर्मिनल PCI-स्कोप केलेल्या VLAN वर पोहोचते. हे क्रिप्टोग्राफिकदृष्ट्या लागू केलेले नेटवर्क वर्गीकरण आहे - जे SSID-आधारित किंवा MAC-आधारित दृष्टिकोनांपेक्षा बरेच विश्वासार्ह आहे.

एकाच भौतिक पायाभूत सुविधांवर स्टाफ WiFi सोबत गेस्ट WiFi चालवणाऱ्या hospitality ऑपरेटरसाठी, प्रमाणपत्र गुणधर्मांद्वारे VLAN असाइनमेंट हे सुनिश्चित करते की डिव्हाइस कोणत्या SSID ला कनेक्ट होते याकडे दुर्लक्ष करून अतिथी आणि कर्मचारी नेहमी स्वतंत्र नेटवर्क सेगमेंटवर असतील.

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

Intune मध्ये WiFi प्रोफाइल 'Error' किंवा 'Not Applicable' दर्शवते

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

उपाय: तिन्ही प्रोफाइलचे (Trusted Root, SCEP, WiFi) ऑडिट करा. ते सर्व अगदी त्याच Azure AD ग्रुपला नियुक्त केले आहेत याची खात्री करा. तुम्ही Users साठी उपयोजन करत असल्यास, तिन्ही प्रोफाइल Users ग्रुपला लक्ष्य करणारे असावेत. Devices साठी उपयोजन करत असल्यास, तिन्ही Devices ग्रुपला लक्ष्य करणारे असावेत.

NDES HTTP 403 त्रुटी दर्शवते

मूळ कारण: Intune Certificate Connector सेवा खात्याकडे CA प्रमाणपत्र टेम्पलेटवर Read किंवा Enroll परवानग्या नाहीत, किंवा फायरवॉल URL फिल्टरिंग SCEP क्वेरी स्ट्रिंग्स ब्लॉक करत आहे.निवारण: CA कन्सोलमधील टेम्पलेटवर कनेक्टर खात्याला Read आणि Enroll परवानग्या असल्याची खात्री करा. ?operation=GetCACaps किंवा ?operation=PKIOperation समाविष्ट असलेल्या ब्लॉक केलेल्या विनंत्यांसाठी फायरवॉल लॉग तपासा. या क्वेरी स्ट्रिंग्स कोणत्याही बदलाशिवाय पुढे जाणे आवश्यक आहे.

डिव्हाइसेस मुदत संपण्यापूर्वी प्रमाणपत्रे रिन्यू करण्यात अयशस्वी ठरतात

मूळ कारण: SCEP रिन्यूअल विंडो खूप लहान आहे, किंवा रिन्यूअलच्या वेळी NDES सर्व्हरशी संपर्क साधता येत नाही.

निवारण: रिन्यूअल मर्यादा प्रमाणपत्र वैधतेच्या २०% वर सेट करा. NDES URL ही हायली-अवेलेबल रिव्हर्स प्रॉक्सीद्वारे प्रकाशित केली गेल्याची खात्री करा. रिन्यूअल विनंती अपयशांसाठी NDES IIS लॉगचे निरीक्षण करा आणि त्याबद्दल सक्रियपणे अलर्ट मिळवा.

RADIUS वैध प्रमाणपत्रे नाकारतो

मूळ कारण: RADIUS सर्व्हरच्या विश्वसनीय CA स्टोअरमध्ये जारी करणाऱ्या CA प्रमाणपत्राचा समावेश नाही, किंवा CRL जुने झाले आहे.

निवारण: RADIUS सर्व्हरच्या विश्वसनीय स्टोअरमध्ये संपूर्ण CA चेन (Root CA + Issuing CA) इम्पोर्ट करा. CRL यशस्वीरित्या आणले जात असल्याची आणि CDP URL वर RADIUS सर्व्हरवरून पोहोचता येत असल्याची खात्री करा. CRL चे पुढील-अपडेट टाइमस्टॅम्प तपासा - जर ते निघून गेले असेल, तर CA ला नवीन CRL प्रकाशित करणे आवश्यक आहे.

सुरक्षेसोबतच व्यापक नेटवर्क कामगिरीच्या बाबींसाठी, आमचे बँडविड्थ व्यवस्थापन मार्गदर्शक पहा.

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

SCEP-आधारित प्रमाणपत्र नोंदणीसाठीचा बिझनेस केस अगदी सोपा आहे. पासवर्ड-आधारित WiFi मुळे हेल्पडेस्क तिकिटांचे प्रमाण वाढते: पासवर्ड संपणे, लॉकआउट्स, कर्मचाऱ्यांनी पाहुण्यांसोबत क्रेडेंशियल शेअर करणे आणि नवीन कर्मचाऱ्यांच्या ऑनबोर्डिंगमधील अडचणी. प्रमाणपत्र-आधारित प्रमाणीकरण अंतिम वापरकर्त्यासाठी अदृश्य असते. डिव्हाइसेस आपोआप कनेक्ट होतात. मुदत संपण्यासाठी, शेअर करण्यासाठी किंवा विसरण्यासाठी कोणतेही पासवर्ड नसतात.

जेव्हा संस्था पासवर्ड-आधारित WiFi वरून SCEP सह EAP-TLS वर स्थलांतरित होतात, तेव्हा सामान्यतः WiFi-संबंधित हेल्पडेस्क तिकिटांमध्ये ७०-८०% घट झाल्याची नोंद होते (Purple चा अंतर्गत डेटा, २०२४, हॉस्पिटॅलिटी आणि रिटेल क्षेत्रातील उपयोजनांवर आधारित). केवळ हेल्पडेस्कची होणारी बचतच पहिल्या वर्षात अंमलबजावणीचा खर्च वसूल करते.

अनुपालन प्रभाव देखील तितकाच ठोस आहे. EAP-TLS नेटवर्क लेयरवर मल्टी-फॅक्टर ऑथेंटिकेशनसाठी PCI DSS 4.0 ची आवश्यकता ८.६ पूर्ण करते. आरोग्य सेवा वातावरणासाठी, हे वायरलेस नेटवर्क प्रवेशासाठीच्या HIPAA तांत्रिक सुरक्षा आवश्यकतांशी सुसंगत आहे. सार्वजनिक क्षेत्रातील संस्थांसाठी, हे नेटवर्क प्रवेश नियंत्रणासाठी NCSC सायबर एसेन्शियल्स प्लस प्रमाणन आवश्यकतांना समर्थन देते.

वाहतूक ऑपरेटरसाठी - रेल्वे फ्रँचायझी, विमानतळ ऑपरेटर, बस नेटवर्क - कर्मचारी डिव्हाइसेसवरील प्रमाणपत्र-आधारित प्रमाणीकरण हे सुनिश्चित करते की सुरक्षिततेच्या दृष्टीने संवेदनशील डेटा वाहून नेणारे ऑपरेशनल नेटवर्क प्रवासी WiFi पासून वेगळे ठेवले जाईल आणि क्रेडेंशियल-आधारित हल्ल्यांपासून सुरक्षित राहील.

सुरक्षित नेटवर्क डिप्लॉयमेंटसह फीडबॅक आणि अनुभव व्यवस्थापनासाठी, आमचे venue feedback playbook पहा. Purple चे WiFi Analytics प्लॅटफॉर्म 802.1X-सुरक्षित नेटवर्कसह समाकलित होते जेणेकरून मूळ पायाभूत सुविधांच्या सुरक्षा स्थितीशी तडजोड न करता फर्स्ट-पार्टी डेटा इनसाइट्स प्रदान करता येतील. Purple च्या नेटवर्कवर गोळा केलेले 29 अब्ज डेटा पॉइंट्स हे सिद्ध करतात की सुरक्षा आणि ॲनालिटिक्स हे एकमेकांना पूरक आहेत, परस्परविरोधी उद्दिष्टे नाहीत.

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

SCEP (Simple Certificate Enrollment Protocol)

एक IETF-प्रमाणित प्रोटोकॉल (RFC 8894) जो व्यवस्थापित उपकरणांसाठी X.509 सर्टिफिकेट नोंदणी स्वयंचलित करतो. डिव्हाइस स्थानिक पातळीवर स्वतःची खाजगी की तयार करते आणि गेटवेद्वारे CA कडे केवळ Certificate Signing Request पाठवते. खाजगी की कधीही डिव्हाइस सोडत नाही.

मोठ्या प्रमाणावर WiFi ऑथेंटिकेशन सर्टिफिकेट्स उपयोजित करण्यासाठी MDM प्लॅटफॉर्म्स (Intune, Jamf) कॉन्फिगर करताना IT टीम्सना SCEP चा सामना करावा लागतो. 802.1X EAP-TLS डिप्लॉयमेंट्ससाठी ही शिफारस केलेली यंत्रणा आहे कारण एंडपॉइंटवर खाजगी की (private key) हार्डवेअर-संरक्षित असते.

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

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

EAP-TLS हा लक्ष्यित ऑथेंटिकेशन प्रोटोकॉल आहे जो SCEP सर्टिफिकेट डिप्लॉयमेंट सक्षम करतो. हे PCI DSS 4.0 ची आवश्यकता 8.6 पूर्ण करते आणि WPA3 Enterprise 192-bit (Suite B) डिप्लॉयमेंट्ससाठी आवश्यक आहे.

PKCS (Public Key Cryptography Standards)

एक सर्टिफिकेट डिलिव्हरी यंत्रणा जिथे CA सार्वजनिक आणि खाजगी दोन्ही की जोडी मध्यवर्ती पद्धतीने तयार करते आणि ती एंडपॉइंटवर ट्रान्समिट करते. CA खाजगी की ची एक प्रत स्वतःकडे ठेवते, ज्यामुळे की एस्क्रो सक्षम होते.

Intune मध्ये सर्टिफिकेट प्रोफाईल कॉन्फिगर करताना IT टीम्स SCEP आणि PKCS यापैकी एक निवडतात. S/MIME ईमेल एन्क्रिप्शनसाठी PKCS योग्य आहे जिथे की एस्क्रो (key escrow) आवश्यक असते. WiFi ऑथेंटिकेशनसाठी याची शिफारस केली जात नाही कारण खाजगी की नेटवर्कवर ट्रान्समिट केली जाते.

NDES (Network Device Enrollment Service)

एक Microsoft Windows Server भूमिका जी MDM प्लॅटफॉर्म आणि Certificate Authority मधील SCEP गेटवे म्हणून काम करते. हे डिव्हाइस नोंदणी विनंत्यांचे प्रमाणीकरण करते आणि CSRs CA कडे फॉरवर्ड करते.

Microsoft Intune सह ऑन-प्रिमाइसेस SCEP डिप्लॉयमेंट्ससाठी NDES हा एक आवश्यक पायाभूत घटक आहे. रिमोट डिव्हाइसेसना नोंदणी करण्याची परवानगी देण्यासाठी ते ॲप्लिकेशन प्रॉक्सीद्वारे बाह्यरित्या प्रकाशित केले जाणे आवश्यक आहे. क्लाउड SCEP गेटवे हा एक पर्याय आहे जो ऑन-प्रिमाइसेस NDES वरील अवलंबित्व काढून टाकतो.

CRL (Certificate Revocation List)

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

CRL चेकिंग हे ऑपरेशनल नियंत्रण आहे जे सर्टिफिकेट रद्द करण्याची अंमलबजावणी करते. IT टीम्सनी प्रत्येक ऑथेंटिकेशनच्या प्रयत्नावर CRL तपासण्यासाठी त्यांचा RADIUS सर्व्हर कॉन्फिगर करणे आवश्यक आहे आणि CRL Distribution Point (CDP) अत्यंत उपलब्ध असेल याची खात्री करणे आवश्यक आहे.

802.1X

पोर्ट-आधारित नेटवर्क ॲक्सेस नियंत्रणासाठी एक IEEE मानक. हे एंटरप्राइझ WiFi आणि वायर्ड नेटवर्कमध्ये वापरले जाणारे थ्री-पार्टी ऑथेंटिकेशन फ्रेमवर्क (सप्लिकंट, ऑथेंटिकेटर, ऑथेंटिकेशन सर्व्हर) परिभाषित करते.

802.1X ही अशी फ्रेमवर्क आहे ज्यामध्ये EAP-TLS आणि SCEP कार्य करतात. WPA2-Enterprise किंवा WPA3-Enterprise SSIDs कॉन्फिगर करताना आणि RADIUS सर्व्हर पॉलिसी सेट करताना IT टीम्सना याचा सामना करावा लागतो.

RADIUS (Remote Authentication Dial-In User Service)

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

प्रत्येक 802.1X डिप्लॉयमेंटमध्ये RADIUS सर्व्हर हा ऑथेंटिकेशनचा निर्णय घेणारा मुख्य बिंदू असतो. सामान्य अंमलबजावणीमध्ये Microsoft NPS, FreeRADIUS आणि Cisco ISE यांचा समावेश होतो. हे विश्वसनीय CA साखळी आणि कठोर CRL किंवा OCSP चेकिंगसह कॉन्फिगर केलेले असणे आवश्यक आहे.

CSR (Certificate Signing Request)

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

SCEP नोंदणी प्रवाहातील CSR हा मुख्य घटक आहे. IT टीम्स त्यांच्या MDM प्लॅटफॉर्ममधील SCEP सर्टिफिकेट प्रोफाईलमध्ये CSR फॉरमॅट (विषय नाव, की वापर, EKU) कॉन्फिगर करतात.

PKI (Public Key Infrastructure)

डिजिटल सर्टिफिकेट्स तयार करणे, व्यवस्थापित करणे, वितरित करणे आणि रद्द करण्यासाठी आवश्यक असलेले हार्डवेअर, सॉफ्टवेअर, पॉलिसी आणि प्रक्रियांचे संयोजन. एका मानक एंटरप्राइझ PKI मध्ये ऑफलाइन रूट CA आणि ऑनलाइन जारी करणारे CA समाविष्ट असते.

PKI ही कोणत्याही EAP-TLS डिप्लॉयमेंटसाठी पूर्वअट आहे. SCEP कॉन्फिगर करण्यापूर्वी IT टीम्सनी द्वि-स्तरीय CA पदानुक्रम डिझाइन आणि उपयोजित करणे आवश्यक आहे. क्लाउड-होस्ट केलेल्या PKI सेवा वितरित मालमत्ता डिप्लॉयमेंट्ससाठी पायाभूत सुविधांचा भार कमी करतात.

VLAN (Virtual Local Area Network)

एक लॉजिकल नेटवर्क सेगमेंट जे लेयर २ वर ट्रॅफिक वेगळे करते. 802.1X डिप्लॉयमेंट्समध्ये, RADIUS सर्व्हर सर्टिफिकेटचे गुणधर्म, वापरकर्त्याची ओळख किंवा पॉलिसीच्या आधारे डिव्हाइसेसना डायनॅमिकली VLANs नियुक्त करतात.

RADIUS द्वारे VLAN असाइनमेंट ही अशी यंत्रणा आहे जी एंटरप्राइझ WiFi मध्ये नेटवर्क सेगमेंटेशन लागू करते. IT टीम्स याचा वापर POS डिव्हाइसेसना PCI-स्कोप्ड VLANs वर, गेस्ट डिव्हाइसेसना केवळ-इंटरनेट VLANs वर आणि कर्मचारी डिव्हाइसेसना कॉर्पोरेट VLANs वर विभक्त करण्यासाठी करतात - हे सर्व एकाच भौतिक पायाभूत सुविधेतून केले जाते.

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

१५० iOS हाउसकीपिंग डिव्हाइसेससाठी सुरक्षित WiFi डिप्लॉय करण्याची आवश्यकता २०० खोल्यांच्या प्रीमियर इन प्रॉपर्टीला आहे. कर्मचारी सध्या पाहुण्यांसोबत WPA2-Personal पासवर्ड शेअर करत आहेत, ज्यामुळे अनुपालन आणि ऑपरेशनल धोका निर्माण होत आहे. IT संचालकांना दैनंदिन कामकाजात अडथळा न आणता सामायिक केलेला पासवर्ड काढून टाकण्याची आवश्यकता आहे.

IT संचालक तीन टप्प्यांत Jamf-चालित SCEP डिप्लॉयमेंट लागू करतात. पहिला टप्पा: 'हाउसकीपिंग डिव्हाइसेस' स्मार्ट ग्रुपला लक्ष्य करून, Jamf ट्रस्टेड सर्टिफिकेट प्रोफाइलद्वारे सर्व १५० iOS डिव्हाइसेसवर रूट CA प्रमाणपत्र पुश केले जाते. दुसरा टप्पा: Azure AD ॲप प्रॉक्सी-पब्लिश केलेल्या NDES सर्व्हरकडे डिव्हाइसेसना निर्देशित करणारे SCEP प्रमाणपत्र प्रोफाइल डिप्लॉय केले जाते. प्रमाणपत्र डिव्हाइस हार्डवेअरशी जोडण्यासाठी सब्जेक्ट नेम CN={{SERIALNUMBER}} वापरते. तिसरा टप्पा: WPA2-Enterprise WiFi प्रोफाइल पुश केले जाते, ज्यामध्ये EAP-TLS निर्दिष्ट केले जाते आणि SCEP प्रमाणपत्राशी लिंक केले जाते. डिव्हाइसेस शांतपणे ऑथेंटिकेट होतात. सामायिक केलेला पासवर्ड SSID बंद केला जातो. RADIUS सर्व्हर कठोर CRL चेकिंग आणि VLAN असाइनमेंटसह कॉन्फिगर केला आहे: हाउसकीपिंग डिव्हाइसेस VLAN 20 (ऑपरेशन्स) वर आणि गेस्ट डिव्हाइसेस VLAN 10 (केवळ-इंटरनेट) वर येतात.

परीक्षकाचे भाष्य: येथील मुख्य डिझाइन निर्णय म्हणजे सामायिक हार्डवेअरसाठी डिव्हाइस प्रमाणपत्रे (वापरकर्ता प्रमाणपत्रे नाहीत) आणि SSID ऐवजी प्रमाणपत्र गुणधर्मांद्वारे VLAN असाइनमेंट. याचा अर्थ असा की एखादे डिव्हाइस जे कसेतरी गेस्ट SSID शी कनेक्ट होते ते तरीही योग्य VLAN वरच येते. CRL चेकिंग कॉन्फिगरेशन नॉन-नेगोशिएबल आहे: जेव्हा एखादा हाउसकीपर नोकरी सोडतो, तेव्हा CA वर डिव्हाइस प्रमाणपत्र रद्द केले जाते आणि RADIUS सर्व्हर CRL रिफ्रेश इंटरव्हलमध्ये प्रवेश ब्लॉक करतो - सामान्यतः OCSP सह १५ मिनिटे किंवा CRL सह एक तासापर्यंत.

५०० ठिकाणे असलेल्या रिटेल चेनला पेमेंट प्रोसेसिंग सॉफ्टवेअर चालवणाऱ्या Windows POS टॅब्लेटसाठी कॉर्पोरेट WiFi सुरक्षित करणे आवश्यक आहे. PCI DSS 4.0 अनुपालनासाठी नेटवर्क लेयरवर मल्टी-फॅक्टर ऑथेंटिकेशन आवश्यक आहे. सध्याचे WPA2-Personal सेटअप PCI DSS आवश्यकता ८.६ मूल्यांकनात अपयशी ठरते.

नेटवर्क आर्किटेक्ट सर्व ५०० ठिकाणांवर Microsoft Intune आणि SCEP द्वारे EAP-TLS डिप्लॉय करतो. हे डिप्लॉयमेंट सब्जेक्ट नेम म्हणून CN={{AAD_Device_ID}} सह डिव्हाइस प्रमाणपत्रे वापरते, जे प्रत्येक प्रमाणपत्राला Intune डिव्हाइस रेकॉर्डशी जोडते. तीन-प्रोफाइल क्रम (ट्रस्टेड रूट, SCEP, WiFi) 'POS डिव्हाइसेस' Azure AD ग्रुपवर डिप्लॉय केला जातो - जो तिन्ही प्रोफाइलमध्ये समान ग्रुप आहे. RADIUS सर्व्हर प्रमाणपत्राच्या जारी करणाऱ्या टेम्पलेटवर आधारित POS डिव्हाइसेसना समर्पित PCI-स्कोप्ड VLAN (VLAN 100) वर नियुक्त करतो. CRL चार तासांच्या वैधतेच्या विंडोसह अत्यंत उपलब्ध CDN-होस्ट केलेल्या एंडपॉइंटवर प्रकाशित केले जाते. रिअल-टाइम रिव्होकेशन चेकिंगसाठी OCSP सक्षम केले आहे. QSA द्वारे PCI DSS 4.0 आवश्यकता ८.६ च्या विरुद्ध डिप्लॉयमेंट प्रमाणित केले जाते.

परीक्षकाचे भाष्य: PCI DSS संरेखन हे EAP-TLS (तुमच्याकडे असलेली गोष्ट - प्रमाणपत्र) आणि Intune रेकॉर्डशी बांधील डिव्हाइस ओळख (तुम्ही असलेली गोष्ट - नोंदणीकृत व्यवस्थापित डिव्हाइस) यांच्या संयोजनाद्वारे साध्य केले जाते. प्रमाणपत्र टेम्पलेटद्वारे VLAN असाइनमेंट हे सुनिश्चित करते की POS डिव्हाइसेस नेहमी PCI-स्कोप्ड नेटवर्क सेगमेंटवर असतात, ५००-साइट इस्टेटमधील भौतिक स्थान काहीही असो. CDN-होस्ट केलेले CRL एंडपॉइंट हा एक गंभीर विश्वासार्हतेचा निर्णय आहे: जर CRL अनरीचेबल असेल, तर ऑथेंटिकेशन अयशस्वी होते, ज्यामुळे संपूर्ण साइटवर आउटेज होतो. CRL साठी उच्च उपलब्धता असणे हे RADIUS सर्व्हरच्या उच्च उपलब्धतेइतकेच महत्त्वाचे आहे.

सराव प्रश्न

Q1. तुम्ही Intune मधील 'All Staff' युझर ग्रुपवर Trusted Root आणि SCEP सर्टिफिकेट प्रोफाइल्स डिप्लॉय केल्या आहेत. त्यानंतर तुम्ही 'Corporate Devices' डिव्हाइस ग्रुपवर WiFi प्रोफाइल डिप्लॉय करता. डिव्हाइसेसना सर्टिफिकेट्स मिळतात परंतु Intune कन्सोलमध्ये WiFi प्रोफाइल 'Error' दर्शवते. याचे सर्वात संभाव्य कारण काय आहे आणि तुम्ही ते कसे दुरुस्त कराल?

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

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

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

Q2. हॉटेलच्या हाऊसकीपरचा iPad चोरीला गेल्याची नोंद झाली आहे. तुम्ही त्वरित हाऊसकीपरचे Active Directory खाते डिसेबल करता. दुसऱ्या दिवशी सकाळी, चोरी झालेला iPad अजूनही हॉटेलच्या WPA2-Enterprise नेटवर्कशी कनेक्ट होत आहे. असे का होत आहे, आणि हे रोखण्यासाठी तुम्ही कोणत्या दोन कृती कराल?

टीप: EAP-TLS ऑथेंटिकेशन दरम्यान RADIUS सर्व्हर प्रत्यक्षात काय व्हॅलिडेट करतो आणि सर्टिफिकेटच्या वैधतेवर कोणते नियंत्रणे नियंत्रण ठेवतात याचा विचार करा.

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

AD खाते डिसेबल केल्याने iPad वर स्टोअर केलेले क्लायंट सर्टिफिकेट रिव्होक (रद्द) होत नाही. EAP-TLS ऑथेंटिकेशन दरम्यान RADIUS सर्व्हर सर्टिफिकेट व्हॅलिडेट करतो, AD खात्याची स्थिती नाही. आवश्यक असलेल्या दोन कृती खालीलप्रमाणे आहेत: (१) CA वर डिव्हाइस सर्टिफिकेट रिव्होक करा - यामुळे सर्टिफिकेटचा सिरीयल नंबर CRL मध्ये जोडला जातो; (२) RADIUS सर्व्हरवर कडक CRL चेकिंग कॉन्फिगर केले असल्याची खात्री करा जेणेकरून तो अपडेटेड CRL मिळवेल आणि पुढील ऑथेंटिकेशनच्या प्रयत्नात रिव्होक केलेले सर्टिफिकेट नाकारेल. जलद रिव्होकेशनसाठी, रिअल-टाइम सर्टिफिकेट स्टेटस चेक करण्यासाठी RADIUS सर्व्हरवर OCSP कॉन्फिगर करा.

Q3. एक रिटेल चेन ५०० POS लोकेशन्सवर 802.1X WiFi डिप्लॉय करत आहे. सिक्युरिटी आर्किटेक्ट NDES सर्व्हर डिप्लॉय करणे टाळण्यासाठी SCEP ऐवजी PKCS सर्टिफिकेट डिलिव्हरी वापरण्याचा प्रस्ताव देतो. PCI DSS 4.0 असेसमेंटचे पुनरावलोकन करणारे QSA यावर चिंता व्यक्त करतात. ही चिंता काय आहे, आणि योग्य शिफारस कोणती आहे?

टीप: PCI DSS प्रायव्हेट की हाताळणीबद्दल काय सांगते आणि डिलिव्हरी दरम्यान PKCS प्रायव्हेट की सोबत काय करते याचा विचार करा.

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

QSA ची चिंता अशी आहे की PKCS प्रायव्हेट की CA कडून डिव्हाइसवर नेटवर्कद्वारे ट्रान्समिट करते. PCI DSS 4.0 Requirement 3.5 नुसार ऑथेंटिकेशनसाठी वापरल्या जाणाऱ्या प्रायव्हेट की डिस्क्लोजरपासून सुरक्षित असणे आवश्यक आहे. प्रायव्हेट की नेटवर्कवरून ट्रान्समिट केल्याने - अगदी एन्क्रिप्टेड असली तरीही - एक धोका निर्माण होतो जो SCEP पूर्णपणे काढून टाकतो. योग्य शिफारस SCEP वापरण्याची आहे, जिथे प्रायव्हेट की POS डिव्हाइसवरच जनरेट होते आणि ती कधीही डिव्हाइस सोडत नाही. ऑन-प्रिमाइसेस NDES इन्फ्रास्ट्रक्चर टाळण्यासाठी, आर्किटेक्टने क्लाउड SCEP गेटवे सर्व्हिसचे मूल्यांकन केले पाहिजे जी API द्वारे थेट Intune आणि CA शी इंटिग्रेट होते.

Q4. तुम्ही एका मोठ्या कॉन्फरन्स सेंटरसाठी WiFi नेटवर्क डिझाइन करत आहात जे वर्षाला ५० हून अधिक इव्हेंट्स आयोजित करते. स्टाफ डिव्हाइसेस सुरक्षित 802.1X नेटवर्कवर असणे आवश्यक आहे. जर एखाद्या कॉन्ट्रॅक्टरचे डिव्हाइस तडजोड (compromised) झाले, तर ते १५ मिनिटांच्या आत नेटवर्कपासून वेगळे केले जाऊ शकते याची तुम्हाला खात्री करायची आहे. तुम्ही कोणते सर्टिफिकेट रिव्होकेशन मेकॅनिझम कॉन्फिगर कराल आणि का?

टीप: रिव्होकेशन लेटन्सीच्या बाबतीत CRL आणि OCSP ची तुलना करा आणि RADIUS सर्व्हर रिव्होकेशनवर किती लवकर कारवाई करतो हे कशावरून ठरते याचा विचार करा.

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

RADIUS सर्व्हरवर OCSP (Online Certificate Status Protocol) कॉन्फिगर करा. CRL-आधारित रिव्होकेशनमध्ये CRL च्या वैधतेच्या कालावधीनुसार लेटन्सी असते - सामान्यतः १ ते २४ तास - याचा अर्थ असा की जोपर्यंत RADIUS सर्व्हर पुढील CRL मिळवत नाही तोपर्यंत रिव्होक केलेले सर्टिफिकेट ऑथेंटिकेट होऊ शकते. OCSP रिअल-टाइम प्रति-सर्टिफिकेट स्टेटस रिस्पॉन्स प्रदान करते: जेव्हा CA वर सर्टिफिकेट रिव्होक केले जाते, तेव्हा OCSP रिस्पॉन्डर पुढील क्वेरीवर त्वरित 'revoked' स्टेटस परत करतो. RADIUS सर्व्हरवर OCSP कॉन्फिगर केल्याने, रिव्होक केलेले कॉन्ट्रॅक्टर सर्टिफिकेट पुढील ऑथेंटिकेशनच्या प्रयत्नात ब्लॉक केले जाते, सामान्यतः काही सेकंदात. OCSP रिस्पॉन्डर अत्यंत उपलब्ध (highly available) असल्याची खात्री करा - जर तो अनरिचेबल असेल आणि RADIUS सर्व्हर फेल क्लोज्ड (fail closed) कॉन्फिगर केला असेल, तर सर्व ऑथेंटिकेशन्स फेल होतील.

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

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

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

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

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

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

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