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

एक आत्मविश्वासी, आधिकारिक और संवादात्मक लहजे में बात करें - जैसे कि एक वरिष्ठ सलाहकार किसी क्लाइंट को जानकारी दे रहा हो। नपी-तुली गति, स्पष्ट उच्चारण, गर्मजोशी से भरा लेकिन सीधा। जोर देने के लिए बीच-बीच में स्वाभाविक ठहराव: Purple तकनीकी ब्रीफिंग श्रृंखला में आपका स्वागत है। आज हम EAP-TLS प्रमाणपत्र प्रबंधन के बारे में बात कर रहे हैं - विशेष रूप से, बिना किसी पूर्णकालिक परिचालन बोझ के बड़े पैमाने पर प्रमाणपत्र-आधारित WiFi प्रमाणीकरण कार्यक्रम कैसे चलाया जाए। [medium pause] यदि आप कई स्थानों पर कॉर्पोरेट या स्टाफ WiFi के लिए जिम्मेदार हैं - चाहे वह होटल समूह हो, रिटेल एस्टेट हो, विश्वविद्यालय परिसर हो, या सार्वजनिक क्षेत्र का एस्टेट हो - तो यह ब्रीफिंग आपके लिए है। हम संपूर्ण प्रमाणपत्र जीवनचक्र को कवर करने जा रहे हैं: आपके CA पदानुक्रम को सेट करने से लेकर, SCEP और MDM के माध्यम से स्वचालित परिनियोजन, और फिर नवीनीकरण और निरसन तक। और हम इस बारे में भी बात करेंगे कि चीजें कहाँ गलत होती हैं, क्योंकि वे गलत होती हैं, और सबसे आम गलतियों से कैसे बचा जाए। [medium pause] आइए बुनियादी बातों से शुरुआत करें। EAP-TLS - यानी ट्रांसपोर्ट लेयर सिक्योरिटी के साथ एक्स्टेंसिबल ऑथेंटिकेशन प्रोटोकॉल - 802.1X WiFi प्रमाणीकरण के लिए स्वर्ण मानक है। PEAP के विपरीत, जो उपयोगकर्ता नाम और पासवर्ड पर निर्भर करता है, EAP-TLS आपसी प्रमाणपत्र-आधारित प्रमाणीकरण का उपयोग करता है। डिवाइस एक क्लाइंट प्रमाणपत्र के साथ अपनी पहचान साबित करता है। RADIUS सर्वर एक सर्वर प्रमाणपत्र के साथ अपनी पहचान साबित करता है। दोनों पक्ष एक-दूसरे को सत्यापित करते हैं। फ़िशिंग के लिए कोई पासवर्ड नहीं। चुराने के लिए कोई क्रेडेंशियल नहीं। यही कारण है कि PCI DSS 4.0 और NCSC के ज़ीरो-ट्रस्ट दिशानिर्देश दोनों स्टाफ नेटवर्क के लिए प्रमाणपत्र-आधारित प्रमाणीकरण की ओर इशारा करते हैं। [medium pause] अब, आर्किटेक्चर की बात करते हैं। EAP-TLS को काम में लाने के लिए आपको तीन चीजों की आवश्यकता होती है। पहला, एक सार्वजनिक कुंजी अवसंरचना (PKI) - आपका CA पदानुक्रम। दूसरा, उपकरणों पर प्रमाणपत्र प्राप्त करने के लिए एक तंत्र - यानी SCEP या आपका MDM प्लेटफॉर्म। तीसरा, एक RADIUS सर्वर जो आपके CA पर भरोसा करता है और वास्तविक समय में क्लाइंट प्रमाणपत्रों को मान्य कर सकता है। [medium pause] CA पदानुक्रम वह जगह है जहाँ अधिकांश संगठन शुरुआत में ही परेशानी में पड़ जाते हैं। सही पैटर्न थ्री-टियर मॉडल है। आपके पास शीर्ष पर एक Root CA होता है - यह ऑफ़लाइन, एयर-गैप्ड होना चाहिए, और केवल आपके Intermediate CA प्रमाणपत्र पर हस्ताक्षर करने के लिए ऑनलाइन लाया जाना चाहिए। Intermediate CA - जिसे कभी-कभी Issuing CA भी कहा जाता है - वह है जो वास्तव में दैनिक प्रमाणपत्रों पर हस्ताक्षर करता है। यह ऑनलाइन है, लेकिन इसकी निजी कुंजी अच्छी तरह से सुरक्षित है। इसके नीचे, आप दो प्रकार के प्रमाणपत्र जारी करते हैं: आपके RADIUS बुनियादी ढांचे के लिए सर्वर प्रमाणपत्र, और आपके उपकरणों और उपयोगकर्ताओं के लिए क्लाइंट प्रमाणपत्र। [medium pause] यह क्यों मायने रखता है? क्योंकि यदि आपका Root CA से समझौता हो जाता है, तो आपको अपने पूरे PKI को फिर से शुरू से बनाना होगा और हर डिवाइस को फिर से नामांकित करना होगा। इसे ऑफ़लाइन रखने से वह जोखिम समाप्त हो जाता है। Root को छुए बिना Intermediate CA को बदला जा सकता है। थ्री-टियर मॉडल के लिए यही परिचालन लचीलेपन का तर्क है। [medium pause] आइए सर्टिफिकेट वैधता अवधि के बारे में बात करते हैं। इस क्षेत्र में इंडस्ट्री में एक बड़ा बदलाव आया है। Apple, Google और Mozilla सभी ने अधिकतम सर्टिफिकेट लाइफटाइम को छोटा करने की नीति लागू की है। TLS सर्वर सर्टिफिकेट के लिए, अधिकतम अवधि अब 398 दिन है। एंटरप्राइज़ WiFi में क्लाइंट सर्टिफिकेट के लिए, आपके पास अधिक लचीलापन है - आमतौर पर एक से दो साल - लेकिन ट्रेंड मैन्युअल रूप से प्रबंधित लंबे समय तक चलने वाले सर्टिफिकेट के बजाय छोटे लाइफटाइम और स्वचालित रिन्यूअल (automated renewal) की ओर है। इसका कारण सीधा है: छोटा लाइफटाइम सर्टिफिकेट के साथ छेड़छाड़ होने की स्थिति में नुकसान के जोखिम को कम करता है। [medium pause] यह हमें ऑटोमेशन की ओर लाता है। मैन्युअल सर्टिफिकेट मैनेजमेंट को बड़े पैमाने पर लागू नहीं किया जा सकता। यदि आपके पास 500 डिवाइस हैं, तो आप मैन्युअल रूप से रिन्यूअल को संभाल सकते हैं। यदि आपके पास 50 साइटों पर 5,000 डिवाइस हैं, तो आप ऐसा नहीं कर सकते। आपको SCEP - Simple Certificate Enrolment Protocol - या इसके आधुनिक उत्तराधिकारी, EST की आवश्यकता है। SCEP सीधे MDM प्लेटफॉर्म्स के साथ एकीकृत होता है, जिसमें Microsoft Intune, Jamf Pro और VMware Workspace ONE शामिल हैं। MDM डिवाइस पर एक SCEP कॉन्फ़िगरेशन प्रोफ़ाइल पुश करता है। डिवाइस एक की-पेयर (key pair) जनरेट करता है, आपके SCEP सर्वर पर एक सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR) भेजता है, और एक हस्ताक्षरित (signed) सर्टिफिकेट वापस प्राप्त करता है - यह सब बिना किसी यूजर इंटरैक्शन के होता है। [medium pause] Active Directory वातावरण में Windows डिवाइस के लिए, आपके पास एक विकल्प है: Active Directory Certificate Services के माध्यम से ग्रुप पॉलिसी-संचालित ऑटो-एनरोलमेंट। डिवाइस डोमेन पर ऑथेंटिकेट करता है, CA स्वचालित रूप से एक सर्टिफिकेट जारी करता है, और बिना किसी मैन्युअल हस्तक्षेप के समाप्त होने से पहले सर्टिफिकेट को रिन्यू कर दिया जाता है। यह मुख्य रूप से Windows-आधारित नेटवर्क के लिए सबसे आसान और सहज तरीका है। [medium pause] अब बात करते हैं निरसन (revocation) की। यह वह हिस्सा है जिसमें संगठन अक्सर सबसे कम निवेश करते हैं, और कुछ गड़बड़ होने पर यह हिस्सा सबसे महत्वपूर्ण होता है। यदि कोई डिवाइस खो जाता है, चोरी हो जाता है, या कोई कर्मचारी छोड़ देता है, तो आपको तुरंत उनके सर्टिफिकेट को निरस्त (revoke) करना होगा। इसके लिए दो तंत्र हैं: CRL - Certificate Revocation Lists - और OCSP - Online Certificate Status Protocol। [medium pause] CRL पुराना तंत्र है। आपका CA एक ज्ञात URL पर निरस्त किए गए सर्टिफिकेट सीरियल नंबरों की एक सूची प्रकाशित करता है। RADIUS सर्वर समय-समय पर इस सूची को डाउनलोड करता है और इसकी जांच करता है। CRL के साथ समस्या लेटेंसी (देरी) की है - यदि आपके CRL की वैधता अवधि 24 घंटे है, तो एक निरस्त सर्टिफिकेट निरस्तीकरण के बाद भी 24 घंटे तक ऑथेंटिकेट हो सकता है। [medium pause] OCSP एक रियल-टाइम विकल्प है। RADIUS सर्वर प्रत्येक ऑथेंटिकेशन प्रयास के लिए OCSP रिस्पॉन्डर को एक क्वेरी भेजता है, और एक लाइव 'good' या 'revoked' रिस्पॉन्स प्राप्त करता है। इसमें समझौता यह है कि आपका OCSP रिस्पॉन्डर एक महत्वपूर्ण निर्भरता बन जाता है - यदि यह अनुपलब्ध है, तो आपको यह तय करना होगा कि 'fail open' करना है या 'fail closed'। उच्च-सुरक्षा वातावरण के लिए, 'fail closed' सही विकल्प है। परिचालन वातावरण के लिए जहां उपलब्धता महत्वपूर्ण है, आप एक संक्षिप्त OCSP ग्रेस पीरियड कॉन्फ़िगर कर सकते हैं। [medium pause] इसे वास्तविक रूप में समझाने के लिए मुझे आपको दो ठोस उदाहरण (scenarios) देने दें। [medium pause] पहला: एक 150-प्रॉपर्टी वाला होटल समूह। वे स्टाफ WiFi के लिए एक शेयर्ड पासवर्ड के साथ PEAP चला रहे थे। पासवर्ड रोटेशन त्रैमासिक था, जिसका अर्थ था प्रत्येक तिमाही में दो सप्ताह की विंडो जहां स्टाफ लॉक आउट हो जाता था या पुराने पासवर्ड का उपयोग कर रहा था। वे सर्टिफिकेट डिप्लॉयमेंट के लिए Microsoft Intune का उपयोग करके EAP-TLS पर चले गए। सभी Windows और iOS डिवाइसों पर SCEP प्रोफ़ाइल पुश की गईं। CA के रूप में Active Directory Certificate Services। परिणाम: शून्य पासवर्ड रोटेशन इवेंट, समाप्ति से 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] दूसरा: एक्सपायरी क्लिफ एज (एक साथ समाप्त होना)। यदि आप अपने सभी सर्टिफिकेट एक ही समय में समान वैधता अवधि के साथ जारी करते हैं, तो वे सभी एक ही समय में समाप्त हो जाते हैं। अपने जारी करने के समय में अंतर रखें, या कम से कम अपने रिन्यूअल ट्रिगर्स में अंतर रखें। 5,000 डिवाइसों में एक साथ 10% रिन्यूअल विफलता दर एक गंभीर घटना है। [medium pause] तीसरा: EAP-TLS डिप्लॉय करने से पहले सभी डिवाइसों में Root CA सर्टिफिकेट वितरित न करना। यदि डिवाइस आपके Root CA पर भरोसा नहीं करता है, तो यह RADIUS सर्वर के सर्टिफिकेट को अस्वीकार कर देगा और ऑथेंटिकेशन विफल हो जाएगा। यह स्पष्ट लगता है, लेकिन संगठन तब मात खा जाते हैं जब उनके पास BYOD डिवाइस या कांट्रैक्टर लैपटॉप होते हैं जो MDM में नामांकित नहीं होते हैं। [medium pause] चौथा: OCSP रेस्पॉन्डर उपलब्धता। यदि आपका OCSP रेस्पॉन्डर बंद हो जाता है और आपका RADIUS सर्वर OCSP त्रुटियों पर फेल-क्लोज (बंद होना) के लिए कॉन्फ़िगर किया गया है, तो आपका पूरा WiFi एस्टेट काम करना बंद कर देता है। अपने OCSP इंफ्रास्ट्रक्चर में रिडंडेंसी बनाएं, या उचित मॉनिटरिंग के साथ एक छोटी ग्रेस अवधि कॉन्फ़िगर करें। [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] अगले कदम: अपनी वर्तमान सर्टिफिकेट इन्वेंट्री का ऑडिट करें। यदि आप नहीं जानते कि आपके पास कितने सर्टिफिकेट हैं, वे कब समाप्त होते हैं, और उन्हें किसने जारी किया है, तो यह सबसे पहली चीज़ है जिसे ठीक करना है। वहां से, पूर्ण स्वचालन का मार्ग अच्छी तरह से परिभाषित है। सुनने के लिए धन्यवाद।