EAP-TLS WiFi प्रमाणीकरण के लिए डिजिटल प्रमाणपत्रों का प्रबंधन

एक आत्मविश्वासी, आधिकारिक और संवादात्मक लहजे में बोलें - जैसे कोई वरिष्ठ सलाहकार किसी क्लाइंट को जानकारी दे रहा हो। मापी गई गति, स्पष्ट उच्चारण, गर्मजोशी से भरा लेकिन सीधा। जोर देने के लिए बीच-बीच में स्वाभाविक ठहराव: Purple तकनीकी ब्रीफिंग श्रृंखला में आपका स्वागत है। आज हम EAP-TLS प्रमाणपत्र प्रबंधन के बारे में बात कर रहे हैं - विशेष रूप से, बिना पूर्णकालिक परिचालन बोझ बने बड़े पैमाने पर प्रमाणपत्र-आधारित WiFi प्रमाणीकरण कार्यक्रम कैसे चलाया जाए। [medium pause] यदि आप कई स्थानों पर कॉर्पोरेट या कर्मचारियों के WiFi के लिए जिम्मेदार हैं - चाहे वह होटल समूह हो, रिटेल एस्टेट हो, विश्वविद्यालय परिसर हो, या सार्वजनिक क्षेत्र का एस्टेट हो - तो यह ब्रीफिंग आपके लिए है। हम संपूर्ण प्रमाणपत्र जीवनचक्र को कवर करने जा रहे हैं: आपके CA पदानुक्रम को स्थापित करने से लेकर, SCEP और MDM के माध्यम से स्वचालित परिनियोजन, और नवीनीकरण तथा निरस्तीकरण तक। और हम इस बारे में बात करेंगे कि चीजें कहां गलत होती हैं, क्योंकि वे गलत होती हैं, और सबसे आम नुकसानों से कैसे बचा जाए। [medium pause] आइए बुनियादी बातों से शुरू करें। EAP-TLS - यानी ट्रांसपोर्ट लेयर सिक्योरिटी के साथ एक्सटेंसिबल ऑथेंटिकेशन प्रोटोकॉल - 802.1X WiFi प्रमाणीकरण के लिए स्वर्ण मानक (gold standard) है। PEAP के विपरीत, जो उपयोगकर्ता नाम और पासवर्ड पर निर्भर करता है, EAP-TLS पारस्परिक प्रमाणपत्र-आधारित प्रमाणीकरण का उपयोग करता है। डिवाइस क्लाइंट प्रमाणपत्र के साथ अपनी पहचान साबित करता है। RADIUS सर्वर सर्वर प्रमाणपत्र के साथ अपनी पहचान साबित करता है। दोनों पक्ष एक-दूसरे को सत्यापित करते हैं। फ़िशिंग के लिए कोई पासवर्ड नहीं। चोरी करने के लिए कोई क्रेडेंशियल नहीं। यही कारण है कि PCI-DSS 4.0 और NCSC का ज़ीरो-ट्रस्ट मार्गदर्शन दोनों कर्मचारियों के नेटवर्क के लिए प्रमाणपत्र-आधारित प्रमाणीकरण की ओर इशारा करते हैं। [medium pause] अब, आर्किटेक्चर। EAP-TLS को काम करने के लिए आपको तीन चीजों की आवश्यकता है। पहला, एक पब्लिक की इन्फ्रास्ट्रक्चर - आपका CA पदानुक्रम। दूसरा, डिवाइसों पर प्रमाणपत्र प्राप्त करने का एक तंत्र - यानी SCEP या आपका MDM प्लेटफॉर्म। तीसरा, एक RADIUS सर्वर जो आपके CA पर भरोसा करता है और रीयल-टाइम में क्लाइंट प्रमाणपत्रों को मान्य कर सकता है। [medium pause] CA पदानुक्रम वह जगह है जहां अधिकांश संगठन शुरुआत में ही परेशानी में पड़ जाते हैं। सही पैटर्न तीन-स्तरीय मॉडल है। आपके पास शीर्ष पर एक Root CA होता है - इसे ऑफ़लाइन, एयर-गैप्ड होना चाहिए, और केवल आपके इंटरमीडिएट CA प्रमाणपत्र पर हस्ताक्षर करने के लिए ऑनलाइन लाया जाना चाहिए। इंटरमीडिएट CA - जिसे कभी-कभी जारीकर्ता CA भी कहा जाता है - वह है जो वास्तव में दैनिक प्रमाणपत्रों पर हस्ताक्षर करता है। यह ऑनलाइन है, लेकिन इसकी निजी कुंजी अच्छी तरह से सुरक्षित है। उसके नीचे, आप दो प्रकार के प्रमाणपत्र जारी करते हैं: आपके RADIUS इन्फ्रास्ट्रक्चर के लिए सर्वर प्रमाणपत्र, और आपके डिवाइसों और उपयोगकर्ताओं के लिए क्लाइंट प्रमाणपत्र। [medium pause] यह क्यों मायने रखता है? क्योंकि यदि आपके Root CA के साथ समझौता हो जाता है, तो आपको अपना पूरा PKI नए सिरे से बनाना होगा और हर डिवाइस को फिर से नामांकित करना होगा। इसे ऑफ़ライン रखने से वह जोखिम समाप्त हो जाता है। Root को छुए बिना इंटरमीडिएट CA को बदला जा सकता है। तीन-स्तरीय मॉडल के लिए यह परिचालन लचीलेपन का तर्क है। [medium pause] आइए प्रमाणपत्र वैधता अवधि के बारे में बात करते हैं। यहाँ उद्योग में एक महत्वपूर्ण बदलाव आया है। Apple, Google और Mozilla सभी ने कम से कम अधिकतम प्रमाणपत्र जीवनकाल लागू करने की दिशा में कदम बढ़ाया है। TLS सर्वर प्रमाणपत्रों के लिए, अधिकतम सीमा अब 398 दिन है। उद्यम WiFi में क्लाइंट प्रमाणपत्रों के लिए, आपके पास अधिक लचीलापन है - एक से दो वर्ष सामान्य है - लेकिन रुझान मैन्युअल रूप से प्रबंधित दीर्घकालिक प्रमाणपत्रों के बजाय छोटे जीवनकाल और स्वचालित नवीनीकरण की ओर है। इसका कारण सरल है: छोटा जीवनकाल प्रमाणपत्र के साथ समझौता होने की स्थिति में जोखिम की अवधि को सीमित करता है। [medium pause] यह हमें स्वचालन (automation) पर लाता है। मैन्युअल प्रमाणपत्र प्रबंधन बड़े पैमाने पर काम नहीं करता है। यदि आपके पास 500 डिवाइस हैं, तो आप मैन्युअल रूप से नवीनीकरण प्रबंधित कर सकते हैं। यदि आपके पास 50 स्थानों पर 5,000 डिवाइस हैं, तो आप ऐसा नहीं कर सकते। आपको SCEP - सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल - या इसके आधुनिक उत्तराधिकारी, EST की आवश्यकता है। SCEP सीधे Microsoft Intune, Jamf Pro और VMware Workspace ONE सहित MDM प्लेटफॉर्म के साथ एकीकृत होता है। MDM डिवाइस पर एक SCEP कॉन्फ़िगरेशन प्रोफ़ाइल पुश करता है। डिवाइस एक कुंजी जोड़ी (key pair) जनरेट करता है, आपके SCEP सर्वर पर एक प्रमाणपत्र हस्ताक्षर अनुरोध भेजता है, और एक हस्ताक्षरित प्रमाणपत्र वापस प्राप्त करता है - यह सब बिना किसी उपयोगकर्ता हस्तक्षेप के होता है। [medium pause] Active Directory परिवेश में Windows डिवाइसों के लिए, आपके पास एक विकल्प है: Active Directory प्रमाणपत्र सेवाओं के माध्यम से समूह नीति-संचालित (Group Policy-driven) स्वचालित नामांकन। डिवाइस डोमेन को प्रमाणित करता है, CA स्वचालित रूप से एक प्रमाणपत्र जारी करता है, और प्रमाणपत्र बिना किसी मैन्युअल हस्तक्षेप के समाप्त होने से पहले नवीनीकृत हो जाता है। Windows-प्रधान संपत्तियों के लिए यह सबसे सहज मार्ग है। [medium pause] अब, निरस्तीकरण। यह वह हिस्सा है जिसमें संगठन अक्सर सबसे कम निवेश करते हैं, और यह वह हिस्सा है जो कुछ गलत होने पर सबसे अधिक मायने रखता है। यदि कोई डिवाइस खो जाता है, चोरी हो जाता है, या कोई कर्मचारी नौकरी छोड़ देता है, तो आपको तुरंत उनका प्रमाणपत्र निरस्त करना होगा। इसके दो तंत्र हैं: CRL - प्रमाणपत्र निरस्तीकरण सूचियाँ - और OCSP - ऑनलाइन प्रमाणपत्र स्थिति प्रोटोकॉल। [medium pause] CRL पुराना तंत्र है। आपका CA एक ज्ञात URL पर निरस्त प्रमाणपत्र सीरियल नंबरों की एक सूची प्रकाशित करता. RADIUS सर्वर समय-समय पर इस सूची को डाउनलोड करता है और इसके विरुद्ध जांच करता है। CRL के साथ समस्या विलंबता (latency) की है - यदि आपके CRL की वैधता अवधि 24 घंटे है, तो निरस्त प्रमाणपत्र अभी भी निरस्तीकरण के 24 घंटे बाद तक प्रमाणित हो सकता है। [medium pause] OCSP रीयल-टाइम विकल्प है। RADIUS सर्वर प्रत्येक प्रमाणीकरण प्रयास के लिए OCSP रिस्पॉन्डर को एक क्वेरी भेजता है, और एक लाइव 'अच्छा' या 'निरस्त' प्रतिक्रिया प्राप्त करता है। समझौता यह है कि आपका OCSP रिस्पॉन्डर एक महत्वपूर्ण निर्भरता बन जाता है - यदि यह अनुपलब्ध है, तो आपको यह तय करना होगा कि फेल ओपन (fail open) करना है या फेल क्लोज्ड (fail closed) करना है। उच्च-सुरक्षा परिवेशों के लिए, फेल क्लोज्ड सही उत्तर है। परिचालन परिवेशों के लिए जहां उपलब्धता मायने रखती है, आप एक छोटी OCSP छूट अवधि (grace period) कॉन्फ़िगर कर सकते हैं। [medium pause] इसे वास्तविक बनाने के लिए मुझे आपको दो ठोस परिदृश्य देने दें। [medium pause] पहला: एक 150-संपत्ति वाला होटल समूह। वे कर्मचारियों के WiFi के लिए एक साझा पासवर्ड के साथ PEAP चला रहे थे। पासवर्ड रोटेशन त्रैमासिक था, जिसका अर्थ था कि हर तिमाही में दो सप्ताह की अवधि होती थी जहाँ कर्मचारियों को बाहर कर दिया जाता था या वे पुराने पासवर्ड का उपयोग कर रहे होते थे। वे प्रमाणपत्र परिनियोजन के लिए Microsoft Intune का उपयोग करके EAP-TLS पर चले गए। SCEP प्रोफ़ाइल सभी Windows and iOS डिवाइसों पर पुश की गईं। CA के रूप में Active Directory प्रमाणपत्र सेवाएँ। परिणाम: शून्य पासवर्ड रोटेशन घटनाएं, समाप्ति से 30 दिन पहले स्वचालित रूप से संभाला गया प्रमाणपत्र नवीनीकरण, और जब स्टाफ के किसी सदस्य ने नौकरी छोड़ी, तो Microsoft Entra ID में उनका खाता अक्षम होने के कुछ ही मिनटों के भीतर MDM में उनका प्रमाणपत्र निरस्त कर दिया गया। IT टीम का अनुमान है कि उन्होंने पासवर्ड रीसेट और हेल्पडेस्क टिकटों में प्रति तिमाही लगभग 40 घंटे बचाए। [medium pause] दूसरा: 200 स्टोरों में 3,000 स्टाफ डिवाइसों के साथ एक बहु-स्थान रिटेल चेन। यहाँ चुनौती डिवाइस विविधता थी - Windows लैपटॉप, Android हैंडहेल्ड और iOS डिवाइसों का मिश्रण। उन्होंने Apple डिवाइसों के लिए Jamf Pro और Windows तथा Android के लिए Microsoft Intune का उपयोग किया, दोनों एक ही SCEP सर्वर की ओर इशारा करते थे जो Microsoft ADCS इंटरमीडिएट CA द्वारा समर्थित था। WiFi इन्फ्रास्ट्रक्चर Cisco Meraki था, जिसमें RADIUS प्रमाणीकरण Purple के साथ एकीकृत क्लाउड-होस्टेड RADIUS सेवा द्वारा संभाला जाता था। मुख्य डिज़ाइन निर्णय 12 महीने की वैधता के साथ प्रमाणपत्र जारी करना और समाप्ति से 60 दिन पहले स्वचालित नवीनीकरण कॉन्फ़िगर करना था। इसने परिचालन ओवरहेड पैदा किए बिना एक आरामदायक नवीनीकरण विंडो प्रदान की। [medium pause] अब, कमियाँ। ऐसी चार कमियाँ हैं जिन्हें मैं लगातार देखता हूँ। [medium pause] पहला: निरस्तीकरण का परीक्षण न करना। संगठन अपना PKI स्थापित करते हैं, प्रमाणपत्र तैनात करते हैं, और वास्तव में कभी परीक्षण नहीं करते हैं कि निरस्तीकरण शुरू से अंत तक काम करता है या नहीं। इसका परीक्षण करें। एक परीक्षण प्रमाणपत्र को निरस्त करें, पुष्टि करें कि RADIUS सर्वर आपकी अपेक्षित अवधि के भीतर निरस्तीकरण को पकड़ लेता है, और पुष्टि करें कि डिवाइस को पहुंच से वंचित कर दिया गया है। [medium pause] दूसरा: समाप्ति का कगार (expiry cliff edges)। यदि आप अपने सभी प्रमाणपत्र एक ही समय में समान वैधता अवधि के साथ जारी करते हैं, तो वे सभी एक ही समय में समाप्त हो जाते हैं। अपने जारी करने की प्रक्रिया को चरणबद्ध करें, या कम से कम अपने नवीनीकरण ट्रिगर्स को चरणबद्ध करें। एक साथ 5,000 डिवाइसों में 10% नवीनीकरण विफलता दर एक महत्वपूर्ण घटना है। [medium pause] तीसरा: EAP-TLS तैनात करने से पहले सभी डिवाइसों में Root CA प्रमाणपत्र वितरित न करना। यदि डिवाइस आपके Root CA पर भरोसा नहीं करता है, तो वह RADIUS सर्वर के प्रमाणपत्र को अस्वीकार कर देगा और प्रमाणीकरण विफल हो जाएगा। यह स्पष्ट लगता है, लेकिन यह संगठनों को तब संकट में डालता है जब उनके पास BYOD डिवाइस या ठेकेदार (contractor) के लैपटॉप होते हैं जो MDM में नामांकित नहीं होते हैं। [medium pause] चौथा: OCSP रिस्पॉन्डर की उपलब्धता। यदि आपका OCSP रिस्पॉन्डर डाउन हो जाता है और आपका RADIUS सर्वर OCSP त्रुटियों पर फेल क्लोज्ड (fail closed) होने के लिए कॉन्फ़िगर किया गया है, तो आपका पूरा WiFi एस्टेट काम करना बंद कर देता है। अपने OCSP इन्फ्रास्ट्रक्चर में अतिरेक (redundancy) का निर्माण करें, या उचित निगरानी के साथ एक छोटी छूट अवधि (grace period) कॉन्फ़िगर करें। [medium pause] ठीक है, रैपिड-फायर प्रश्न। [medium pause] क्या मैं EAP-TLS क्लाइंट प्रमाणपत्रों के लिए सार्वजनिक CA का उपयोग कर सकता हूँ? तकनीकी रूप से हाँ, लेकिन व्यावहारिक रूप से नहीं। सार्वजनिक CA मनमाने डिवाइसों के लिए क्लाइंट प्रमाणपत्र जारी नहीं करेंगे। क्लाइंट प्रमाणपत्रों के लिए आपको अपने स्वयं के CA की आवश्यकता है। RADIUS सर्वर प्रमाणपत्र के लिए, एक सार्वजनिक CA ठीक है और विश्वास वितरण को सरल बनाता है। [medium pause] BYOD के बारे में क्या? BYOD एक कठिन मामला है। आप MDM के माध्यम से गैर-प्रबंधित डिवाइसों पर प्रमाणपत्र पुश नहीं कर सकते। विकल्पों में एक नेटवर्क एक्सेस कंट्रोल पोर्टल शामिल है जो उपयोगकर्ता प्रमाणीकरण के बाद अल्पकालिक प्रमाणपत्र जारी करता है, या केवल BYOD को एक अलग प्रमाणीकरण विधि के साथ एक अलग SSID पर रखना शामिल है। [medium pause] यह WPA3 के साथ कैसे इंटरैक्ट करता है? WPA3-Enterprise संवेदनशील परिवेशों के लिए 192-बिट सुरक्षा मोड को अनिवार्य करता है, जिसके लिए विशिष्ट सिफर सुइट्स की आवश्यकता होती है। EAP-TLS, WPA3-Enterprise के साथ पूरी तरह से संगत है और वास्तव में अनुशंसित प्रमाणीकरण विधि है। [medium pause] संक्षेप में। EAP-TLS प्रमाणपत्र प्रबंधन सरल नहीं है, लेकिन यदि आप शुरू से ही आर्किटेक्चर को सही पाते हैं तो यह प्रबंधनीय है। तीन-स्तरीय CA पदानुक्रम। SCEP या MDM के माध्यम से स्वचालित नामांकन। स्वचालित नवीनीकरण के साथ लघु प्रमाणपत्र जीवनकाल। OCSP के माध्यम से रीयल-टाइम निरस्तीकरण। सब कुछ का परीक्षण करें, विशेष रूप से निरस्तीकरण का। और अपने प्रमाणपत्र जीवनचक्र को अपने पहचान प्रदाता - Microsoft Entra ID, Okta, या Google Workspace - के साथ एकीकृत करें ताकि खाता बंद होने पर प्रमाणपत्र निरस्तीकरण स्वचालित रूप से ट्रिगर हो जाए। [medium pause] यदि आप Purple-लिंक्ड RADIUS सर्वर चला रहे हैं, तो एकीकरण बिंदु आपके SCEP सर्वर URL, आपके RADIUS सर्वर प्रमाणपत्र और आपके CRL या OCSP एंडपॉइंट हैं। Purple का हार्डवेयर-अज्ञेयवादी (hardware-agnostic) आर्किटेक्चर का अर्थ है कि यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist और बाकी प्रामाणिक हार्डवेयर सूची में काम करता है - आप किसी एकल विक्रेता के PKI टूलिंग में बंधे नहीं हैं। [medium pause] अगले कदम: अपनी वर्तमान प्रमाणपत्र सूची का ऑडिट करें। यदि आप नहीं जानते कि आपके पास कितने प्रमाणपत्र हैं, वे कब समाप्त होते हैं, और उन्हें किसने जारी किया है, तो सबसे पहले इसे ठीक करना होगा। वहां से, पूर्ण स्वचालन का मार्ग अच्छी तरह से परिभाषित है। सुनने के लिए धन्यवाद।