एंटरप्राइज SCEP सेटअप गाइड: उच्च शिक्षा और बड़े नेटवर्क के लिए सर्टिफिकेट-आधारित WiFi ऑथेंटिकेशन

एंटरप्राइज SCEP सेटअप गाइड: उच्च शिक्षा और बड़े नेटवर्क के लिए सर्टिफिकेट-आधारित WiFi ऑथेंटिकेशन एक Purple तकनीकी ब्रीफिंग - पॉडकास्ट स्क्रिप्ट (लगभग 10 मिनट) --- परिचय और संदर्भ - लगभग 1 मिनट Purple टेक्निकल ब्रीफिंग सीरीज़ में आपका स्वागत है। आज मैं एक ऐसी चीज़ के बारे में बात कर रहा हूँ जो कई IT इनबॉक्स में आती है लेकिन शायद ही कभी उसका सीधा जवाब मिलता है: आप वास्तव में बड़े पैमाने पर, SCEP का उपयोग करके, एक बड़े नेटवर्क पर सर्टिफिकेट-आधारित WiFi ऑथेंटिकेशन कैसे तैनात करते हैं - चाहे वह एक विश्वविद्यालय परिसर हो, एक मल्टी-साइट होटल समूह हो, या एक बड़ा सार्वजनिक क्षेत्र का एस्टेट हो? हम पूरी तस्वीर को कवर करने जा रहे हैं। SCEP वास्तव में क्या करता है, यह 802.1X आर्किटेक्चर में कैसे फिट बैठता है, परिनियोजन अनुक्रम (deployment sequence) जिसे अधिकांश टीमें गलत समझती हैं, दो वास्तविक दुनिया के कार्यान्वयन परिदृश्य, और वे कमियां जो आपकी जिंदगी का एक सप्ताहांत (weekend) बर्बाद कर देंगी यदि आप उनके लिए योजना नहीं बनाते हैं। यह एक सलाहकार ब्रीफिंग है, कोई ट्यूटोरियल नहीं। मैं मान रहा हूँ कि आप जानते हैं कि RADIUS सर्वर क्या है और आपने शायद पहले ही तय कर लिया है कि आपको प्री-शेयर्ड कीज़ से दूर जाने की आवश्यकता है। अब आपको कार्यान्वयन मानचित्र (implementation map) की आवश्यकता है। आइए शुरू करते हैं। --- तकनीकी गहन विश्लेषण - लगभग 5 मिनट तो, बुनियादी सिद्धांत। SCEP का अर्थ Simple Certificate Enrollment Protocol है। इसे 2020 में IETF द्वारा RFC 8894 के रूप में औपचारिक रूप दिया गया था, हालांकि इससे पहले एक दशक से अधिक समय से यह व्यापक रूप से एंटरप्राइज उपयोग में था। इसका काम सीधा है: प्रत्येक मशीन को किसी व्यक्ति द्वारा छुए बिना एक प्रबंधित डिवाइस पर डिजिटल सर्टिफिकेट प्राप्त करने की प्रक्रिया को स्वचालित करना। WiFi ऑथेंटिकेशन के संदर्भ में, SCEP वितरण तंत्र (delivery mechanism) है। वास्तविक ऑथेंटिकेशन प्रोटोकॉल जिसे आप लक्षित कर रहे हैं वह EAP-TLS है - Extensible Authentication Protocol with Transport Layer Security - जो 802.1X फ्रेमवर्क के अंदर काम करता है। EAP-TLS को व्यापक रूप से एंटरप्राइज वायरलेस नेटवर्क के लिए सबसे सुरक्षित ऑथेंटिकेशन विधि माना जाता है क्योंकि इसके लिए क्लाइंट डिवाइस और RADIUS सर्वर दोनों को वैध सर्टिफिकेट प्रस्तुत करने की आवश्यकता होती है। कोई भी पक्ष क्रिप्टोग्राफिक प्रमाण के बिना दूसरे पर भरोसा नहीं करता है। यही म्यूचुअल ऑथेंटिकेशन आपको ईविल ट्विन (evil twin) हमलों से बचाता है - जहां एक हमलावर क्रेडेंशियल चोरी करने के लिए एक अनधिकृत एक्सेस पॉइंट (rogue access point) स्थापित करता है। यहाँ बताया गया है कि पूरी श्रृंखला कैसे काम करती है। एक प्रबंधित डिवाइस - एक छात्र का लैपटॉप, स्टाफ का फोन, होटल का पॉइंट-ऑफ-सेल टर्मिनल - को कॉर्पोरेट वायरलेस नेटवर्क से जुड़ने की आवश्यकता होती है। आपका MDM प्लेटफॉर्म, जो Microsoft Intune या Jamf हो सकता है, उस डिवाइस पर SCEP पेलोड भेजता है। पेलोड में दो चीजें होती हैं: SCEP URL, जो आपके NDES सर्वर या क्लाउड SCEP गेटवे को इंगित करता है, और एक चैलेंज पासवर्ड या साझा रहस्य (shared secret)। डिवाइस स्थानीय रूप से अपनी स्वयं की पब्लिक और प्राइवेट की (key) जोड़ी उत्पन्न करता है। यह महत्वपूर्ण है। प्राइवेट की कभी भी डिवाइस से बाहर नहीं जाती है। यह डिवाइस पर उत्पन्न होती है, सुरक्षित एन्क्लेव या TPM में संग्रहीत होती है, और इसे कभी भी नेटवर्क पर प्रसारित नहीं किया जाता है। डिवाइस फिर एक Certificate Signing Request - एक CSR - बनाता है और इसे SCEP गेटवे पर भेजता है। गेटवे चैलेंज को सत्यापित करता है, CSR को आपके Certificate Authority को अग्रेषित करता है, और CA इस पर हस्ताक्षर करता है और डिवाइस को पब्लिक सर्टिफिकेट वापस कर देता है। उस बिंदु से, जब डिवाइस आपके WiFi SSID से कनेक्ट होता, तो यह उस सर्टिफिकेट को RADIUS सर्वर के सामने प्रस्तुत करता है। RADIUS सर्वर आपके CA की ट्रस्ट चेन के खिलाफ सर्टिफिकेट को सत्यापित करता है, यह पुष्टि करने के लिए Certificate Revocation List की जांच करता है कि सर्टिफिकेट रद्द तो नहीं किया गया है, और यदि सब कुछ ठीक रहता है, तो एक्सेस पॉइंट को एक स्वीकृति संदेश भेजता है। डिवाइस नेटवर्क पर आ जाता है। पूरी प्रक्रिया उपयोगकर्ता के लिए अदृश्य होती है। अब, बात करते हैं कि SCEP विकल्प की तुलना में कहां खड़ा है, जो कि PKCS है। PKCS - Public Key Cryptography Standards - दूसरा सर्टिफिकेट वितरण तरीका है जो Intune जैसे प्लेटफॉर्म द्वारा समर्थित है। PKCS के साथ, CA केंद्रीय रूप से पब्लिक और प्राइवेट दोनों की (key) उत्पन्न करता है, और सर्टिफिकेट कनेक्टर की (key) जोड़ी को डिवाइस पर भेजता है। इसका मतलब है कि प्राइवेट की नेटवर्क पर यात्रा करती है, जो एक सैद्धांतिक हमला क्षेत्र (attack surface) पेश करती है। PKCS उन उपयोग के मामलों के लिए ठीक है जैसे S/MIME ईमेल एन्क्रिप्शन जहां की एस्क्रो (key escrow) वास्तव में वांछनीय है। 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 मिलता है - आंतरिक अनुसंधान प्रणालियों तक पहुंच। एक सुविधा प्रबंधन (facilities management) डिवाइस को VLAN 30 मिलता है - भवन प्रबंधन प्रणालियों तक पहुंच। यह सब सर्टिफिकेट विशेषताओं और RADIUS नीति द्वारा संचालित होता है, जिसमें प्रति डिवाइस कोई मैन्युअल हस्तक्षेप नहीं होता है। पहचान प्रदाता (identity provider) एकीकरण के लिए, SCEP सर्टिफिकेट विशेषताएं - विशेष रूप से Subject Alternative Name - Microsoft Entra ID, Okta, या Google Workspace से उपयोगकर्ता का मुख्य नाम ले जा सकती हैं। यह सर्टिफिकेट को एक विशिष्ट पहचान से जोड़ता है, जिसका अर्थ है कि जब आप Entra ID में किसी खाते को अक्षम करते हैं और MDM डिवाइस को अनएनरोल करता है, तो सर्टिफिकेट रद्द कर दिया जाता है और WiFi एक्सेस स्वचालित रूप से कट जाती है। यह निरसन (revocation) की वह कहानी है जो प्री-शेयर्ड कीज़ बस नहीं बता सकतीं। --- कार्यान्वयन सिफारिशें और कमियां - लगभग 2 मिनट ठीक है, आइए परिनियोजन अनुक्रम (deployment sequence) के बारे में बात करते हैं, क्योंकि यहीं पर अधिकांश टीमें गलती करती हैं। अनुक्रम गैर-परक्राम्य (non-negotiable) है: पहले Trusted Root सर्टिफिकेट, दूसरा SCEP सर्टिफिकेट प्रोफ़ाइल, तीसरा WiFi प्रोफ़ाइल। Intune और Jamf दोनों प्रोफ़ाइल निर्भरताओं को लागू करते हैं। यदि आपकी WiFi प्रोफ़ाइल किसी ऐसे SCEP सर्टिफिकेट को संदर्भित करती है जो अभी तक डिवाइस पर तैनात नहीं किया गया है, तो WiFi प्रोफ़ाइल एक रहस्यमयी त्रुटि के साथ विफल हो जाएगी जो एक गलत कॉन्फ़िगरेशन की तरह दिखती है लेकिन वास्तव में केवल एक समय (timing) की समस्या है। दूसरी कमी समूह लक्ष्यीकरण (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 वितरण बिंदु (Distribution Point) अनुपलब्ध है - क्योंकि सर्वर डाउन है, या URL बदल गया है - तो नेटवर्क पर प्रत्येक डिवाइस के लिए ऑथेंटिकेशन एक साथ विफल हो जाता है। यह पूरे परिसर में आउटेज है। अपने CRL एंडपॉइंट्स को अत्यधिक उपलब्ध बनाएं, और लाइव होने से पहले निरसन (revocation) का परीक्षण करें। बड़े नेटवर्क के लिए - 500 से अधिक उपकरणों के लिए - ऑन-प्रिमाइसेस NDES के बजाय क्लाउड SCEP गेटवे पर विचार करें। क्लाउड गेटवे NDES के सिंगल पॉइंट ऑफ़ फेल्योर को समाप्त करते हैं, क्षैतिज रूप से स्केल करते हैं, और आमतौर पर क्लाउड RADIUS सेवाओं के साथ सीधे एकीकृत होते हैं, जिससे एक और बुनियादी ढांचा निर्भरता समाप्त हो जाती है। --- रैपिड-फायर प्रश्न और उत्तर - लगभग 1 मिनट क्या SCEP उन BYOD उपकरणों को संभाल सकता है जो MDM-नामांकित नहीं हैं? सीधे तौर पर नहीं। सर्टिफिकेट पेलोड को पुश करने के लिए SCEP को MDM नामांकन की आवश्यकता होती है। अप्रबंधित BYOD के लिए, आपको एक अलग दृष्टिकोण की आवश्यकता है - या तो एक स्व-सेवा (self-service) ऑनबोर्डिंग पोर्टल, या पहचान सत्यापन के साथ कैप्टिव पोर्टल का उपयोग करने वाला एक अलग SSID। Purple का प्लेटफॉर्म उस गेस्ट और BYOD लेयर को सफाई से संभालता है, जो आपके सर्टिफिकेट-ऑथेंटिकेटेड स्टाफ नेटवर्क के साथ काम करता है। iOS और Android के बारे में क्या? दोनों प्लेटफॉर्म मूल रूप से SCEP का समर्थन करते हैं। iOS ने iOS 4 से SCEP का समर्थन किया है। Android Enterprise, Intune और अन्य MDMs के माध्यम से SCEP का समर्थन करता है। कॉन्फ़िगरेशन प्रति प्लेटफॉर्म थोड़ा अलग है लेकिन अंतर्निहित प्रोटोकॉल समान है। क्या EAP-TLS, WPA3 के साथ काम करता है? हाँ। WPA3-Enterprise संवेदनशील वातावरण के लिए 192-बिट सुरक्षा मोड को अनिवार्य करता है, और EAP-TLS पूरी तरह से संगत है। वास्तव में, EAP-TLS के साथ WPA3-Enterprise सरकारी और वित्तीय नेटवर्क के लिए WiFi Alliance द्वारा अनुशंसित संयोजन है। --- सारांश और अगले कदम - लगभग 1 मिनट इसे एक साथ लाने के लिए। SCEP सर्टिफिकेट WiFi ऑथेंटिकेशन 50 से अधिक प्रबंधित उपकरणों वाले किसी भी नेटवर्क के लिए सही आर्किटेक्चर है। यह साझा क्रेडेंशियल को समाप्त करता है, आपको प्रति-डिवाइस पहचान देता है, डायनेमिक VLAN सेगमेंटेशन को सक्षम बनाता है, और स्वचालित निरसन (revocation) के लिए आपके पहचान प्रदाता के साथ सीधे एकीकृत होता है। परिनियोजन अनुक्रम - Trusted Root, फिर SCEP प्रोफ़ाइल, फिर WiFi प्रोफ़ाइल - निश्चित है। समूह लक्ष्यीकरण सुसंगत होना चाहिए। CRL की उपलब्धता वैकल्पिक नहीं है। विशेष रूप से उच्च शिक्षा के लिए, स्टाफ और फैकल्टी उपकरणों के लिए SCEP का संयोजन, व्यक्तिगत उपकरणों पर छात्रों के लिए एक अलग गेस्ट WiFi लेयर के साथ, आपको बिना किसी समझौते के सुरक्षा और एक बेहतरीन उपयोगकर्ता अनुभव दोनों देता है। यदि आप और गहराई से जानना चाहते हैं, तो Active Directory या ऑन-प्रिमाइसेस सर्वर के बिना एंटरप्राइज WiFi ऑथेंटिकेशन पर Purple की गाइड क्लाउड-नेटिव पथ को कवर करती है। और यदि आप सोच रहे हैं कि जब कोई कर्मचारी छोड़ता है तो क्या होता है, तो WiFi एक्सेस रद्द करने पर हमारी गाइड पूर्ण निरसन (revocation) वर्कफ़्लो के माध्यम से मार्गदर्शन करती है। सुनने के लिए धन्यवाद। मैं Purple तकनीकी टीम से हूँ, और हम आपसे अगली ब्रीफिंग में मिलेंगे। --- स्क्रिप्ट का अंत