सुरक्षित BYOD और 802.1X नेटवर्क ऑथेंटिकेशन के लिए SCEP को कैसे कॉन्फ़िगर करें

नमस्कार, और Purple के इस तकनीकी ब्रीफिंग में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम SCEP - Simple Certificate Enrollment Protocol - के विवरण में जा रहे हैं और सुरक्षित BYOD और 802.1X नेटवर्क ऑथेंटिकेशन के लिए इसे सही ढंग से कैसे कॉन्फ़िगर किया जाए, इस पर चर्चा कर रहे हैं। यदि आप एक IT प्रबंधक, नेटवर्क आर्किटेक्ट, या CTO हैं जो किसी होटल समूह, रिटेल एस्टेट, स्टेडियम या सार्वजनिक क्षेत्र के संगठन में WiFi इन्फ्रास्ट्रक्चर के लिए जिम्मेदार हैं, तो यह सीधे आपके लिए प्रासंगिक है। आज हम थ्योरी की बात नहीं कर रहे हैं। हम आर्किटेक्चर और निर्णयों की बात कर रहे हैं। आइए शुरू करते हैं। [अनुभाग: परिचय और संदर्भ - लगभग 1 मिनट] यहाँ वह समस्या है जिसका आप संभवतः सामना कर रहे हैं। आपके पास कर्मचारियों के डिवाइस, ठेकेदारों के लैपटॉप और व्यक्तिगत फोन हैं जिन्हें नेटवर्क एक्सेस की आवश्यकता है। आपके पास शायद प्रबंधित (managed) और अप्रबंधित (unmanaged) डिवाइसों का मिश्रण है। और आपके इन्फ्रास्ट्रक्चर में कहीं न कहीं, अभी भी एक साझा WPA2 प्री-शेयर्ड की (pre-shared key) है जिसे बारह लोग जानते हैं, जिनमें से तीन पिछले साल कंपनी छोड़ चुके हैं। यह कोई सुरक्षा स्थिति नहीं है। यह एक दायित्व (liability) है। इसका उत्तर 802.1X है - पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए IEEE मानक। यह सुनिश्चित करता है कि कोई भी डिवाइस तब तक ट्रैफ़िक पास न करे जब तक कि उसे स्पष्ट रूप से ऑथेंटिकेट न किया गया हो। लेकिन 802.1X केवल एक ढांचा है। असली सवाल यह है कि इसके अंदर कौन सी ऑथेंटिकेशन विधि काम करती है। और बड़े पैमाने पर BYOD के लिए, उत्तर SCEP के माध्यम से प्रोविज़न किए गए सर्टिफिकेट्स के साथ EAP-TLS है। आज हम इसी पर विस्तार से चर्चा कर रहे हैं। [अनुभाग: तकनीकी गहन विश्लेषण - लगभग 5 मिनट] आइए शुरू करते हैं कि SCEP वास्तव में क्या करता है। SCEP - Simple Certificate Enrollment Protocol - मूल रूप से 1999 में IETF द्वारा एक इंटरनेट ड्राफ्ट के रूप में प्रकाशित किया गया था, जिसे VeriSign द्वारा बनाया गया था। इसे RFC 8894 के रूप में औपचारिक रूप दिया गया था। इसका काम सीधा है: प्रत्येक सर्टिफिकेट को मैन्युअल रूप से उत्पन्न और इंस्टॉल करने के लिए किसी व्यक्ति की आवश्यकता के बिना, बड़े पैमाने पर डिवाइसों को X.509 डिजिटल सर्टिफिकेट जारी करने की प्रक्रिया को स्वचालित करना। यहाँ चार चरणों वाला प्रवाह है। चरण एक: डिवाइस एक SCEP एंडपॉइंट से जुड़ता है - एक URL जो या तो NDES (Network Device Enrollment Service) नामक Windows सर्वर रोल के माध्यम से ऑन-प्रिमाइसेस होस्ट किया जाता है, या क्लाउड PKI प्रदाता के माध्यम से। यह URL आपके सर्टिफिकेट अथॉरिटी का प्रवेश द्वार है। चरण दो: डिवाइस एक SCEP चैलेंज प्रस्तुत करता है - एक साझा रहस्य (shared secret) जो यह साबित करता है कि वह सर्टिफिकेट का अनुरोध करने के लिए अधिकृत है। Microsoft Intune जैसे MDM-प्रबंधित परिवेश में, यह चैलेंज प्रत्येक डिवाइस के लिए गतिशील और विशिष्ट रूप से वितरित किया जाता है, जो सभी डिवाइसों में साझा किए जाने वाले स्थिर पासवर्ड की तुलना में कहीं अधिक सुरक्षित है। चरण तीन: डिवाइस स्थानीय रूप से अपनी खुद की प्राइवेट और पब्लिक की (key) जोड़ी बनाता है। यह पब्लिक की का उपयोग करके एक सर्टिफिकेट साइनिंग रिक्वेस्ट - एक CSR - बनाता है और उसे SCEP सर्वर पर भेजता है। यहाँ महत्वपूर्ण सुरक्षा बिंदु है: प्राइवेट की कभी भी डिवाइस से बाहर नहीं जाती है। यह स्थानीय रूप से उत्पन्न होती है, डिवाइस के सुरक्षित एन्क्लेव में संग्रहीत होती है - जो कि Windows पर TPM या iOS पर Secure Enclave है - और इसे कभी भी प्रसारित नहीं किया जाता है। यही कारण है कि नेटवर्क ऑथेंटिकेशन के लिए SCEP सही विकल्प है, न कि PKCS, जहां CA केंद्रीय रूप से की (key) उत्पन्न करता है और उसे डिवाइस पर पुश करना पड़ता है। चरण चार: सर्टिफिकेट अथॉरिटी CSR को सत्यापित करता है, CA की प्राइवेट की के साथ इस पर हस्ताक्षर करता है, और हस्ताक्षरित X.509 सर्टिफिकेट डिवाइस को वापस कर देता है। डिवाइस के पास अब एक अद्वितीय क्रिप्टोग्राफिक पहचान है। अब, उस सर्टिफिकेट का उपयोग 802.1X ऑथेंटिकेशन के लिए कैसे किया जाता है? जब डिवाइस आपके WiFi SSID से कनेक्ट होता है, तो एक्सेस पॉइंट - चाहे वह Cisco Meraki हो, HPE Aruba, Ruckus, Juniper Mist, या Ubiquiti UniFi - ऑथेंटिकेटर के रूप में कार्य करता है। यह स्वयं ऑथेंटिकेशन का निर्णय नहीं लेता है। यह EAP एक्सचेंज को आपके RADIUS सर्वर पर फॉरवर्ड करता है। वह Microsoft NPS, Cisco ISE, या Aruba ClearPass हो सकता है। RADIUS सर्वर एक EAP-TLS हैंडशेक शुरू करता है। डिवाइस अपना SCEP-प्रोविज़न किया गया क्लाइंट सर्टिफिकेट प्रस्तुत करता है। RADIUS सर्वर तीन चीजों को सत्यापित करता है: विश्वसनीय रूट CA तक सर्टिफिकेट श्रृंखला, सर्टिफिकेट की समाप्ति तिथि, और क्या सर्टिफिकेट रद्द कर दिया गया है - जिसकी जांच सर्टिफिकेट रिवोकेशन लिस्ट (CRL) या OCSP (Online Certificate Status Protocol) के माध्यम से की जाती है। यदि तीनों जांचें सफल हो जाती हैं, तो RADIUS सर्वर एक EAP-Success संदेश भेजता है, और एक्सेस पॉइंट पोर्ट खोल देता है। डिवाइस नेटवर्क पर आ जाता है। यह म्यूचुअल ऑथेंटिकेशन है। डिवाइस RADIUS सर्वर के सर्टिफिकेट को भी सत्यापित करता है। यदि कोई नकली (rogue) एक्सेस पॉइंट स्थापित करता है, तो डिवाइस इसे अस्वीकार कर देगा क्योंकि सर्वर सर्टिफिकेट विश्वसनीय CA के खिलाफ सत्यापित नहीं होगा। यह इविल ट्विन (evil twin) हमलों के खिलाफ आपकी सुरक्षा है। अब आइए Microsoft Intune में डिप्लॉयमेंट अनुक्रम के बारे में बात करते हैं, क्योंकि यह एंटरप्राइज परिवेशों में सबसे आम MDM प्लेटफॉर्म है जिसे हम देखते हैं। आप सख्त क्रम में तीन Intune कॉन्फ़िगरेशन प्रोफाइल तैनात करते हैं। पहला, ट्रस्टेड रूट सर्टिफिकेट प्रोफाइल - यह आपके रूट CA सर्टिफिकेट को हर डिवाइस पर पुश करता है ताकि वे आपके PKI पर भरोसा कर सकें। दूसरा, SCEP सर्टिफिकेट प्रोफाइल - यह डिवाइसों को SCEP URL, सब्जेक्ट नाम प्रारूप, की (key) उपयोग और क्लाइंट ऑथेंटिकेशन के लिए विस्तारित की उपयोग (extended key usage) बताता है। क्लाइंट ऑथेंटिकेशन के लिए OID 1.3.6.1.5.5.7.3.2 है। तीसरा, WiFi प्रोफाइल - यह SSID निर्दिष्ट करता है, सुरक्षा प्रकार को WPA2-Enterprise या WPA3-Enterprise पर सेट करता है, EAP प्रकार को EAP-TLS पर सेट करता है, और SCEP सर्टिफिकेट प्रोफाइल से लिंक करता है। क्रम महत्वपूर्ण है। WiFi प्रोफाइल की SCEP प्रोफाइल पर निर्भरता है, जिसकी ट्रस्टेड रूट प्रोफाइल पर निर्भरता है। इन्हें बिना क्रम के तैनात करने पर आपको त्रुटियां (errors) मिलेंगी। एक आर्किटेक्चरल निर्णय जो आपको लेना है वह यह है कि NDES सर्वर को कहाँ होस्ट किया जाए। इसे इंटरनेट से सुलभ होना चाहिए ताकि डिवाइस ऑन-साइट आने से पहले एनरोल कर सकें। ऐसा करने का सुरक्षित तरीका Microsoft Entra ID Application Proxy के माध्यम से NDES URL को प्रकाशित करना है। यह इनबाउंड फ़ायरवॉल पोर्ट खोलने से बचाता है और आपको एनरोलमेंट फ़्लो पर कंडीशनल एक्सेस नीतियां लागू करने की अनुमति देता है। उन संगठनों के लिए जो ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर को पूरी तरह से समाप्त करना चाहते हैं, क्लाउड PKI प्रदाता - Intune में Microsoft का अपना Cloud PKI, या तीसरे पक्ष के विकल्प - NDES निर्भरता को पूरी तरह से हटा देते हैं। [अनुभाग: कार्यान्वयन सिफारिशें और कमियां - लगभग 2 मिनट] आइए हम तीन सबसे आम विफलता मोड (failure modes) को देखें जो हम देखते हैं। पहला विफलता मोड: ग्रुप टारगेटिंग मिसमैच। यह Intune में WiFi प्रोफाइल डिप्लॉयमेंट विफलताओं का सबसे आम कारण है। यदि आपका ट्रस्टेड रूट प्रोफाइल किसी यूजर ग्रुप को असाइन किया गया है, आपका SCEP प्रोफाइल किसी डिवाइस ग्रुप को, और आपका WiFi प्रोफाइल किसी अन्य यूजर ग्रुप को, तो Intune निर्भरता श्रृंखला को हल नहीं कर सकता है। तीनों प्रोफाइल को बिल्कुल एक ही Azure AD ग्रुप को लक्षित करना चाहिए - या तो सभी Users या सभी Devices। किसी एक को चुनें और सुसंगत रहें। दूसरा विफलता मोड: CRL उपलब्धता। आपका RADIUS सर्वर यह सत्यापित करने के लिए CRL की जांच करता है कि सर्टिफिकेट रद्द तो नहीं किए गए हैं। यदि CRL डिस्ट्रीब्यूशन पॉइंट - सर्टिफिकेट में एम्बेडेड CDP URL - पहुंच योग्य नहीं है, तो प्रत्येक डिवाइस के लिए ऑथेंटिकेशन विफल हो जाता है। नेटवर्क परिवर्तनों के बाद बड़े पैमाने पर आउटेज का यह एक आम कारण है। सुनिश्चित करें कि आपके CDPs अत्यधिक उपलब्ध हों, आदर्श रूप से रिमोट डिवाइसों के लिए आंतरिक URL और बाहरी URL दोनों पर प्रकाशित हों। CRL चेकिंग के अधिक लचीले विकल्प के रूप में OCSP पर विचार करें। तीसरा विफलता मोड: क्लाइंट्स पर सर्वर सर्टिफिकेट वैलिडेशन लागू न करना। यह 802.1X डिप्लॉयमेंट में सबसे प्रभावशाली गलत कॉन्फ़िगरेशन है। यदि आपका MDM-तैनात WiFi प्रोफाइल विश्वसनीय CA और अपेक्षित RADIUS सर्वर नाम निर्दिष्ट नहीं करता है, तो डिवाइस किसी भी सर्टिफिकेट को प्रस्तुत करने वाले किसी भी सर्वर से कनेक्ट हो जाएंगे। यह EAP-TLS के पूरे उद्देश्य को विफल कर देता है। अपने WiFi प्रोफाइल में हमेशा सर्वर वैलिडेशन कॉन्फ़िगर करें। [अनुभाग: रैपिड-फायर प्रश्न और उत्तर - लगभग 1 मिनट] आइए कुछ त्वरित प्रश्न लें। प्रश्न: क्या हमें WPA3 की आवश्यकता है? हाँ। WPA3-Enterprise पर माइग्रेट करें। इट मैंडेट्स प्रोटेक्टेड मैनेजमेंट फ्रेम्स (PMF), जो डी-ऑथेंटिकेशन हमलों को रोकता है। Cisco Meraki, HPE Aruba, Ruckus, और Juniper Mist के सभी हार्डवेयर इसका समर्थन करते हैं। प्रश्न: उन डिवाइसों का क्या जो 802.1X का समर्थन नहीं कर सकते - जैसे IoT सेंसर या पुराने प्रिंटर? फ़ॉलबैक के रूप में MAC Authentication Bypass का उपयोग करें, लेकिन उन डिवाइसों को अत्यधिक प्रतिबंधित VLAN पर रखें, जिनकी कॉर्पोरेट संसाधनों तक कोई पहुंच न हो। प्रश्न: Purple इसमें कैसे फिट बैठता है? Purple का गेस्ट WiFi प्लेटफॉर्म विज़िटर और गेस्ट एक्सेस लेयर को संभालता है - कैप्टिव पोर्टल, डेटा कैप्चर, एनालिटिक्स। आपका 802.1X और SCEP इन्फ्रास्ट्रक्चर कर्मचारियों और प्रबंधित डिवाइस एक्सेस को संभालता है। वे अलग-अलग SSIDs और अलग-अलग VLANs पर चलते हैं। Purple, Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, और Fortinet के साथ एकीकृत होता है - जिससे आपका हार्डवेयर निवेश सुरक्षित रहता है। [अनुभाग: सारांश और अगले कदम - लगभग 1 मिनट] समापन के लिए। SCEP बड़े पैमाने पर सर्टिफिकेट जारी करने को स्वचालित करता है। प्राइवेट की डिवाइस पर ही रहती है - PKCS की तुलना में यह इसका सुरक्षा लाभ है। MDM के माध्यम से सख्त अनुक्रम में तैनात करें: पहले ट्रस्टेड रूट, फिर SCEP प्रोफाइल, फिर WiFi प्रोफाइल, सभी एक ही ग्रुप को लक्षित करते हुए। Application Proxy के माध्यम से NDES प्रकाशित करें या क्लाउड PKI पर जाएं। अपने RADIUS सर्वर पर CRL या OCSP चेकिंग लागू करें। और हमेशा क्लाइंट सप्लीकेंट्स पर सर्वर सर्टिफिकेट वैलिडेशन कॉन्फ़िगर करें। यदि आप अभी भी कर्मचारियों के WiFi के लिए एक साझा प्री-शेयर्ड की (pre-shared key) चला रहे हैं, तो इस तिमाही में यही बदलाव किया जाना चाहिए। सर्टिफिकेट इन्फ्रास्ट्रक्चर में शुरुआत में अधिक काम होता है, लेकिन यह क्रेडेंशियल-आधारित हमलों के एक पूरे वर्ग को समाप्त कर देता है और तैनात होने के बाद आमतौर पर WiFi से जुड़े हेल्पडेस्क टिकटों को 70 से 80 प्रतिशत तक कम कर देता है। पूर्ण तकनीकी गाइड, आर्किटेक्चर आरेख और व्यावहारिक उदाहरणों के लिए, purple.ai पर जाएं। सुनने के लिए धन्यवाद।