सुरक्षित Enterprise WiFi और BYOD प्रोविज़निंग के लिए SCEP को कैसे कॉन्फ़िगर करें

Purple के इस तकनीकी ब्रीफिंग में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम सुरक्षित एंटरप्राइज WiFi और BYOD प्रोविजर्निंग के लिए SCEP के कॉन्फ़िगरेशन का गहराई से विश्लेषण कर रहे हैं। हॉस्पिटैलिटी, रिटेल और सार्वजनिक क्षेत्रों में काम करने वाले IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और CTOs के लिए, नेटवर्क एक्सेस का प्रबंधन करना सुरक्षा और परिचालन दक्षता के बीच एक निरंतर संतुलन बनाने जैसा है। आप हर दिन अपने नेटवर्क से जुड़ने वाले सैकड़ों, कभी-कभी हजारों उपकरणों को संभाल रहे हैं। कर्मचारियों के स्मार्टफोन, ठेकेदारों के लैपटॉप, पॉइंट-ऑफ-सेल टैबलेट। और इसे संभालने के पुराने तरीके अब बिल्कुल भी पर्याप्त नहीं हैं। कर्मचारियों और BYOD WiFi के लिए प्री-शेयर्ड कीज़, या PSK पर निर्भर रहना एक सुरक्षा संबंधी संवेदनशीलता है जो किसी भी समय आपके लिए मुसीबत बन सकती है। एक शेयर्ड पासवर्ड, एक बार लीक होने के बाद, किसी को भी आपके नेटवर्क तक पहुंच प्रदान कर देता है। और MAC Authentication Bypass, या MAB, इससे बेहतर नहीं है। आधुनिक स्मार्टफोन डिफ़ॉल्ट रूप से रैंडमाइज्ड MAC एड्रेस का उपयोग करते हैं, जो MAB को पूरी तरह से निष्क्रिय कर देता है, और MAC एड्रेस को कुछ ही सेकंड में स्पूफ किया जा सकता है। आधुनिक नेटवर्क आर्किटेक्चर EAP-TLS का उपयोग करके 802.1X ऑथेंटिकेशन की मांग करता है। यह सुनिश्चित करता है कि नेटवर्क को छूने से पहले हर डिवाइस को क्रिप्टोग्राफिक रूप से सत्यापित किया जाए। लेकिन चुनौती यह है: आप अपने हेल्पडेस्क पर बोझ डाले बिना हजारों अनमैनेज्ड डिवाइसेस में अद्वितीय क्लाइंट सर्टिफिकेट कैसे वितरित करते हैं? इसका उत्तर Simple Certificate Enrolment Protocol, या SCEP है। आइए आर्किटेक्चर से शुरुआत करते हैं। SCEP एंटरप्राइज डिवाइस एनरोलमेंट के लिए इंडस्ट्री स्टैंडर्ड है, जिसे RFC 8894 में परिभाषित किया गया है। यह 1999 से अस्तित्व में है, जिसे मूल रूप से VeriSign द्वारा बनाया गया था, और यह समय की कसौटी पर खरा उतरा है क्योंकि यह एक वास्तव में कठिन समस्या को बेहतरीन तरीके से हल करता है। SCEP वर्कफ़्लो में, डिवाइस स्थानीय रूप से अपनी खुद की प्राइवेट और पब्लिक की पेयर जनरेट करता है। यह एक Certificate Signing Request, या CSR बनाता है, और इसे Network Device Enrolment Service, जिसे NDES के रूप में जाना जाता है, के माध्यम से आपके Certificate Authority, या CA को भेजता है। CA रिक्वेस्ट को सत्यापित करता है और हस्ताक्षरित पब्लिक सर्टिफिकेट को डिवाइस पर वापस भेज देता है। यहाँ महत्वपूर्ण सुरक्षा लाभ यह है कि प्राइवेट की कभी भी डिवाइस से बाहर नहीं जाती है। यह स्थानीय रूप से जनरेट होती है और डिवाइस के हार्डवेयर सिक्योर एन्क्लेव में स्टोर होती है। Windows लैपटॉप पर, यह Trusted Platform Module, या TPM है। iPhone पर, यह सिक्योर एन्क्लेव है। प्राइवेट की कभी भी नेटवर्क पर ट्रांसमिट नहीं की जाती है। यही कारण है कि SCEP नेटवर्क ऑथेंटिकेशन के लिए PKCS जैसे विकल्पों की तुलना में कहीं अधिक बेहतर है, जहाँ CA केंद्रीय रूप से की पेयर जनरेट करता है और इसे डिवाइस पर ट्रांसमिट करता है। अब, आइए BYOD के बारे में बात करते हैं। परिचालन के दृष्टिकोण से यह वह जगह है जहाँ चीजें वास्तव में दिलचस्प हो जाती हैं। आप चाहते हैं कि कर्मचारी अपने व्यक्तिगत उपकरणों का उपयोग करके आंतरिक टूल्स तक पहुंच सकें, लेकिन आप उन्हें अपने कॉर्पोरेट MDM में एनरोल करने के लिए मजबूर नहीं करना चाहते हैं। यह गोपनीयता से जुड़ी एक चिंता है, और इसका कर्मचारियों द्वारा कड़ा विरोध किया जाता है। समाधान एक सेल्फ-सर्विस ऑनबोर्डिंग पोर्टल है। यह इस प्रकार काम करता है। उपयोगकर्ता अपने व्यक्तिगत डिवाइस को एक समर्पित प्रोविजनिंग SSID से कनेक्ट करता है। यह नेटवर्क एक वॉलड गार्डन (walled garden) है, जो ऑनबोर्डिंग पोर्टल और आपके पहचान प्रदाता (identity provider) के अलावा हर चीज तक पहुंच को प्रतिबंधित करता है। उपयोगकर्ता अपने कॉर्पोरेट क्रेडेंशियल का उपयोग करके प्रमाणित करता है, आमतौर पर Microsoft Entra ID, Okta, या Google Workspace के साथ SAML एकीकरण के माध्यम से। सफल प्रमाणीकरण पर, सिस्टम SCEP के माध्यम से एक अद्वितीय, डिवाइस-विशिष्ट क्लाइंट प्रमाणपत्र जनरेट करता है। डिवाइस पर एक कॉन्फ़िगरेशन प्रोफ़ाइल भेजी जाती है जिसमें प्रमाणपत्र, रूट CA प्रमाणपत्र और नेटवर्क सेटिंग्स शामिल होती हैं। इसके बाद डिवाइस स्वचालित रूप से EAP-TLS का उपयोग करके सुरक्षित कॉर्पोरेट SSID से कनेक्ट हो जाता है। यह उपयोगकर्ता के लिए सहज और उद्यम के लिए सुरक्षित है। उन्हें प्रमाणपत्रों या 802.1X के बारे में कुछ भी जानने की आवश्यकता नहीं है। वे बस एक बार लॉग इन करते हैं और वे कनेक्ट हो जाते हैं। अब, आइए कार्यान्वयन को विस्तार से समझें। परिनियोजन (deployment) का क्रम महत्वपूर्ण है, और इसे गलत करना विफलता का सबसे आम कारण है। चरण एक: ट्रस्टेड रूट प्रमाणपत्र परिनियोजित करें। इससे पहले कि कोई भी डिवाइस क्लाइंट प्रमाणपत्र का अनुरोध कर सके या आपके RADIUS सर्वर पर भरोसा कर सके, उसे जारी करने वाले प्रमाणपत्र प्राधिकरण (Certificate Authority) पर भरोसा करना चाहिए। अपने रूट CA प्रमाणपत्र को .cer फ़ाइल के रूप में निर्यात करें और इसे अपने लक्षित डिवाइस समूहों में परिनियोजित करें। यह चरण गैर-परक्राम्य है। इसके बिना, पूरी श्रृंखला विफल हो जाती है। चरण दो: SCEP प्रमाणपत्र प्रोफ़ाइल को कॉन्फ़िगर करें। यह उपकरणों को निर्देश देता है कि वे अपना क्लाइंट प्रमाणपत्र कैसे प्राप्त करें। आपको विषय नाम प्रारूप (subject name format) को कॉन्फ़िगर करना होगा। उपयोगकर्ता-संचालित प्रमाणीकरण के लिए, मानक CN बराबर UserPrincipalName है। डिवाइस प्रमाणीकरण के लिए, CN बराबर Azure AD डिवाइस ID का उपयोग करें। कुंजी उपयोग (key usage) को डिजिटल हस्ताक्षर और कुंजी एन्सिफरमेंट पर सेट करें। विस्तारित कुंजी उपयोग के अंतर्गत, OID 1.3.6.1.5.5.7.3.2 के साथ क्लाइंट प्रमाणीकरण निर्दिष्ट करें। इस प्रोफ़ाइल को चरण एक से ट्रस्टेड रूट प्रमाणपत्र प्रोफ़ाइल से लिंक करें। और अपने NDES सर्वर का बाहरी URL प्रदान करें। चरण तीन: 802.1X WiFi प्रोफ़ाइल परिनियोजित करें। यह प्रमाणपत्रों को नेटवर्क SSID से जोड़ता है। नेटवर्क का नाम ठीक उसी तरह दर्ज करें जैसा वह आपके एक्सेस पॉइंट द्वारा प्रसारित किया जाता है। सुरक्षा प्रकार को WPA2-Enterprise या WPA3-Enterprise पर सेट करें। EAP प्रकार को EAP-TLS पर सेट करें। क्लाइंट प्रमाणीकरण प्रमाणपत्र के रूप में SCEP प्रमाणपत्र प्रोफ़ाइल का चयन करें। और सर्वर सत्यापन के लिए ट्रस्टेड रूट प्रमाणपत्र निर्दिष्ट करें। इस पूरे विवरण से याद रखने योग्य सबसे महत्वपूर्ण बात यह क्रम है। विश्वास, फिर प्रमाणपत्र, फिर WiFi। इसी क्रम में, हर बार। अब मैं आपको कुछ सर्वोत्तम प्रथाओं के बारे में बताता हूँ जो आपको उत्पादन में महत्वपूर्ण परेशानी से बचाएंगी। सबसे पहले, Azure AD एप्लिकेशन प्रॉक्सी के माध्यम से अपना NDES सर्वर प्रकाशित करें। दूरस्थ उपकरणों को ऑन-साइट आने से पहले प्रमाणपत्रों का प्रावधान करने की अनुमति देने के लिए NDES सर्वर इंटरनेट से सुलभ होना चाहिए। लेकिन किसी आंतरिक सर्वर को सीधे इंटरनेट पर उजागर करना एक महत्वपूर्ण सुरक्षा जोखिम है। एप्लिकेशन प्रॉक्सी आपको इनबाउंड फ़ायरवॉल पोर्ट खोले बिना सुरक्षित दूरस्थ पहुँच प्रदान करता है। दूसरा, BYOD डिवाइस के लिए कम अवधि वाले सर्टिफिकेट लागू करें। तीन साल के लिए वैध सर्टिफिकेट के बजाय, 90 दिनों के लिए वैध सर्टिफिकेट जारी करें। जब सर्टिफिकेट समाप्त हो जाता है, तो यूज़र को ऑनबोर्डिंग पोर्टल के माध्यम से फिर से प्रमाणित करना होगा। यह स्वाभाविक रूप से नेटवर्क से पुराने डिवाइस को हटा देता है। जो डिवाइस 90 दिनों में उपयोग नहीं किया गया है वह बस बाहर हो जाता है। किसी मैन्युअल सफ़ाई की आवश्यकता नहीं है। तीसरा, और यह बेहद महत्वपूर्ण है, अपने RADIUS सर्वर को सख्त सर्टिफिकेट निरसन सूची (CRL) जाँच लागू करने के लिए कॉन्फ़िगर करें। जब कोई कर्मचारी संगठन छोड़ता है, तो उनके Active Directory अकाउंट को अक्षम करने से उनका WiFi एक्सेस तुरंत निरस्त नहीं हो सकता है यदि उनका क्लाइंट सर्टिफिकेट वैध रहता है। एक्सेस प्रदान करने से पहले आपके RADIUS सर्वर को CRL की जाँच करनी चाहिए। सुनिश्चित करें कि आपके CRL वितरण बिंदु अत्यधिक उपलब्ध हैं। यदि RADIUS सर्वर CRL तक नहीं पहुँच पाता है, तो सभी के लिए प्रमाणीकरण विफल हो जाता है। यह एक व्यापक आउटेज है। आइए अब कुछ सामान्य विफलता मोड और उनसे बचने के तरीकों पर नज़र डालें। सबसे आम समस्या WiFi प्रोफाइल का लागू न हो पाना है। डिवाइस को ट्रस्टेड रूट और SCEP सर्टिफिकेट प्राप्त होते हैं, लेकिन MDM कंसोल में WiFi प्रोफाइल एरर के रूप में दिखाई देती है। दस में से नौ बार, यह एक ग्रुप टारगेटिंग मिसमैच होता है। यदि SCEP प्रोफाइल किसी यूज़र ग्रुप को असाइन किया गया है, लेकिन WiFi प्रोफाइल किसी डिवाइस ग्रुप को असाइन किया गया है, तो MDM निर्भरता को हल नहीं कर सकता है। अपने असाइनमेंट का ऑडिट करें। सुनिश्चित करें कि तीनों प्रोफाइल बिल्कुल एक ही ग्रुप को टारगेट करते हैं। दूसरी सामान्य समस्या NDES 403 Forbidden एरर है। डिवाइस SCEP सर्टिफिकेट प्राप्त करने में विफल रहते हैं, और NDES IIS लॉग HTTP 403 एरर दिखाते हैं। यह आमतौर पर कनेक्टर सर्विस अकाउंट में सर्टिफिकेट टेम्पलेट पर आवश्यक अनुमतियों की कमी, या SCEP द्वारा उपयोग किए जाने वाले विशिष्ट क्वेरी स्ट्रिंग पैरामीटर को ब्लॉक करने वाले फ़ायरवॉल के कारण होता है। सत्यापित करें कि कनेक्टर अकाउंट के पास CA टेम्पलेट पर Read और Enrol अनुमतियाँ हैं। यह सुनिश्चित करने के लिए अपने फ़ायरवॉल लॉग की जाँच करें कि operation equals GetCACaps पैरामीटर वाले URL ब्लॉक नहीं किए जा रहे हैं। व्यवहार में यह कैसे काम करता है, इसे समझाने के लिए मैं आपको दो वास्तविक दुनिया के परिदृश्य देता हूँ। परिदृश्य एक: 50 हाउसकीपिंग स्टाफ वाला एक 200 कमरों का होटल जो शेड्यूलिंग ऐप तक पहुँचने के लिए व्यक्तिगत स्मार्टफोन का उपयोग कर रहा है। IT मैनेजर स्टाफ की गोपनीयता का सम्मान करने के लिए पूर्ण MDM नामांकन से बचना चाहता है। इसका समाधान Microsoft Entra ID के साथ एकीकृत एक सेल्फ-सर्विस पोर्टल है। स्टाफ प्रोविज़निंग SSID से कनेक्ट करता है, अपने Entra ID क्रेडेंशियल के साथ लॉग इन करता है, और SCEP प्रोफाइल डाउनलोड करता है। SCEP सर्वर सीधे डिवाइस को 30-दिवसीय क्लाइंट सर्टिफिकेट जारी करता है। डिवाइस EAP-TLS का उपयोग करके स्टाफ WiFi SSID से कनेक्ट होता है। RADIUS सर्वर इन डिवाइस को एक प्रतिबंधित VLAN में असाइन करता है जो केवल शेड्यूलिंग ऐप तक पहुँच की अनुमति देता है। जब कोई स्टाफ सदस्य इस्तीफा देता है, तो उनका Entra ID अकाउंट अक्षम कर दिया जाता है, और RADIUS सर्वर तुरंत नेटवर्क एक्सेस को अस्वीकार कर देता है। परिदृश्य दो: 500 स्टोर्स वाली एक राष्ट्रीय रिटेल श्रृंखला, जो कॉर्पोरेट-स्वामित्व वाले पॉइंट-ऑफ-सेल टैबलेट के लिए सुरक्षित WiFi तैनात कर रही है। नेटवर्क आर्किटेक्ट को यह सुनिश्चित करने की आवश्यकता है कि यदि टैबलेट चोरी भी हो जाए, तो भी क्रेडेंशियल्स को निकाला न जा सके। इसका समाधान SCEP के माध्यम से प्रमाणपत्र तैनात करने वाला Microsoft Intune है। Intune ट्रस्टेड रूट प्रमाणपत्र को पुश करता है, जिसके बाद एक SCEP प्रोफाइल आता है जो टैबलेट को अपने हार्डवेयर सुरक्षित एन्क्लेव में अपनी निजी कुंजी उत्पन्न करने का निर्देश देता है। टैबलेट NDES सर्वर पर एक CSR सबमिट करता है, क्लाइंट प्रमाणपत्र प्राप्त करता है, और EAP-TLS का उपयोग करके Retail POS SSID से जुड़ता है। चूंकि निजी कुंजी स्थानीय रूप से उत्पन्न होती है और कभी प्रसारित नहीं होती है, इसलिए चोरी हुए टैबलेट के क्रेडेंशियल्स का उपयोग कहीं और नहीं किया जा सकता है। यह PCI-DSS अनुपालन आवश्यकताओं को पूरा करता है। अब, आइए व्यावसायिक मामले के बारे में बात करते हैं। SCEP 802.1X प्रमाणपत्र परिनियोजन पर संक्रमण सुरक्षा और संचालन में मापने योग्य रिटर्न प्रदान करता है। पासवर्ड-आधारित WiFi हेल्पडेस्क टिकटों की एक महत्वपूर्ण मात्रा उत्पन्न करता है। पासवर्ड की समाप्ति, लॉकआउट, टाइपिंग की गलतियाँ। प्रमाणपत्र-आधारित प्रमाणीकरण उपयोगकर्ता के लिए अदृश्य होता है। डिवाइस स्वतः कनेक्ट हो जाते हैं। यह आमतौर पर WiFi से संबंधित हेल्पडेस्क वॉल्यूम को 70% तक कम कर देता है। यह परिचालन लागत में एक वास्तविक कमी है। EAP-TLS क्रेडेंशियल हार्वेस्टिंग और मैन-इन-द-मिडल हमलों के जोखिम को समाप्त करता है। यह खुदरा वातावरण में PCI-DSS और सभी क्षेत्रों में GDPR के अनुपालन के लिए महत्वपूर्ण है। डेटा ब्रीच की लागत एक उचित PKI बुनियादी ढांचे को तैनात करने की लागत से कहीं अधिक है। और जो संगठन पहले से ही Purple का Guest WiFi और एनालिटिक्स प्लेटफ़ॉर्म चला रहे हैं, उनके लिए कर्मचारियों के BYOD उपकरणों के लिए सुरक्षित ऑनबोर्डिंग का विस्तार करना एक एकीकृत नेटवर्क प्रबंधन रणनीति प्रदान करता है। Purple का हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks, और Fortinet के साथ एकीकृत होता है, इसलिए आप किसी एक हार्डवेयर विक्रेता से बंधे नहीं हैं। Purple 80,000 लाइव स्थानों पर काम करता है और उसने 2024 में 440 मिलियन लॉगिन संसाधित किए हैं, जिसके पास ISO 27001, GDPR, CCPA, और Cyber Essentials प्रमाणपत्र हैं। आइए मैं आपके द्वारा लिए जाने वाले मुख्य निर्णयों के त्वरित सारांश के साथ समाप्त करूँ। क्या आपको SCEP या PKCS का उपयोग करना चाहिए? WiFi प्रमाणीकरण के लिए SCEP का उपयोग करें। निजी कुंजी डिवाइस पर ही रहती है। PKCS का उपयोग केवल ईमेल एन्क्रिप्शन के लिए करें जहाँ कुंजी एस्क्रो की आवश्यकता होती है। प्रमाणपत्र कितने समय के लिए वैध होने चाहिए? BYOD के लिए 90 दिन। कॉर्पोरेट-प्रबंधित उपकरणों के लिए एक से दो वर्ष। क्या आपको अपने MDM में उपयोगकर्ता या डिवाइस को लक्षित करना चाहिए? कॉर्पोरेट उपकरणों के लिए डिवाइस लक्ष्यीकरण का उपयोग करें जिन्हें उपयोगकर्ता लॉगिन से पहले कनेक्ट करने की आवश्यकता होती है। BYOD के लिए उपयोगकर्ता लक्ष्यीकरण का उपयोग करें जहाँ प्रमाणपत्र को व्यक्ति से जोड़ा जाना चाहिए। आप Android विखंडन को कैसे संभालते हैं? जहाँ संभव हो Passpoint का उपयोग करें, जिसे हॉटस्पॉट 2.0 के रूप में भी जाना जाता है। यह Android निर्माताओं में एक सुसंगत कनेक्शन अनुभव प्रदान करता है। और अंत में, सबसे महत्वपूर्ण बात कौन सी है जिसे सही करना आवश्यक है? आपके RADIUS सर्वर पर CRL जाँच। इसके बिना, एक निरस्त प्रमाणपत्र अभी भी नेटवर्क एक्सेस प्रदान कर सकता है। आज की ब्रीफिंग यहीं समाप्त होती है। यदि आप इनमें से किसी भी विषय पर अधिक विस्तार से जानना चाहते हैं, तो एंटरप्राइज WiFi सुरक्षा और EAP-TLS प्रमाणपत्र प्रमाणीकरण पर Purple के तकनीकी गाइड Purple की वेबसाइट purple.ai पर उपलब्ध हैं। सुनने के लिए धन्यवाद।