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 को काम में लाने के लिए आपको तीन चीज़ों की आवश्यकता है। पहला, एक पब्लिक की इंफ्रास्ट्रक्चर - आपका CA पदानुक्रम। दूसरा, डिवाइसों पर सर्टिफिकेट प्राप्त करने का एक तंत्र - यानी SCEP या आपका MDM प्लेटफॉर्म। तीसरा, एक RADIUS सर्वर जो आपके CA पर भरोसा करता है और वास्तविक समय में क्लाइंट सर्टिफिकेट को सत्यापित कर सकता है। [medium pause] CA पदानुक्रम वह जगह है जहाँ अधिकांश संगठन शुरुआत में ही मुश्किल में पड़ जाते हैं। सही पैटर्न तीन-स्तरीय मॉडल है। आपके पास शीर्ष पर एक रूट CA होता है - यह ऑफ़लाइन, एयर-गैप्ड होना चाहिए, और केवल आपके इंटरमीडिएट CA सर्टिफिकेट पर हस्ताक्षर करने के लिए ऑनलाइन लाया जाना चाहिए। इंटरमीडिएट CA - जिसे कभी-कभी जारी करने वाला CA भी कहा जाता है - वह है जो वास्तव में दैनिक सर्टिफिकेट पर हस्ताक्षर करता है। यह ऑनलाइन है, लेकिन इसकी निजी कुंजी अच्छी तरह से सुरक्षित है। उसके नीचे, आप दो प्रकार के सर्टिफिकेट जारी करते हैं: आपके RADIUS बुनियादी ढांचे के लिए सर्वर सर्टिफिकेट, और आपके डिवाइसों और उपयोगकर्ताओं के लिए क्लाइंट सर्टिफिकेट। [medium pause] यह क्यों मायने रखता है? क्योंकि यदि आपका रूट CA समझौता हो जाता है, तो आपको शुरुआत से अपना पूरा PKI फिर से बनाना होगा और हर डिवाइस को फिर से नामांकित करना होगा। इसे ऑफ़लाइन रखने से यह जोखिम समाप्त हो जाता है। रूट को छुए बिना इंटरमीडिएट CA को बदला जा सकता है। यह तीन-स्तरीय मॉडल के लिए परिचालन लचीलेपन का तर्क है। [medium pause] आइए सर्टिफिकेट की वैधता अवधि (validity periods) के बारे में बात करते हैं। यहाँ इंडस्ट्री में एक बड़ा बदलाव आया है। Apple, Google, और Mozilla सभी ने अधिकतम सर्टिफिकेट लाइफटाइम को छोटा करने की नीति लागू की है। TLS सर्वर सर्टिफिकेट के लिए, अब अधिकतम सीमा 398 दिन है। एंटरप्राइज़ WiFi में क्लाइंट सर्टिफिकेट के लिए, आपके पास अधिक लचीलापन है - एक से दो वर्ष होना आम बात है - लेकिन रुझान मैन्युअल रूप से प्रबंधित किए जाने वाले लंबे समय तक चलने वाले सर्टिफिकेट के बजाय छोटे लाइफटाइम और स्वचालित नवीनीकरण की ओर है। इसका कारण सरल है: एक छोटा लाइफटाइम सर्टिफिकेट के साथ छेड़छाड़ होने पर जोखिम की अवधि को सीमित करता है। [medium pause] यह हमें ऑटोमेशन की ओर ले जाता है। मैन्युअल सर्टिफिकेट मैनेजमेंट को बड़े पैमाने पर बढ़ाना संभव नहीं है। यदि आपके पास 500 डिवाइस हैं, तो आप नवीनीकरण को किसी तरह मैन्युअल रूप से संभाल सकते हैं। लेकिन यदि आपके पास 50 साइटों पर 5,000 डिवाइस हैं, तो आप ऐसा नहीं कर सकते। आपको SCEP - Simple Certificate Enrolment Protocol - या इसके आधुनिक उत्तराधिकारी, EST की आवश्यकता होती है। SCEP सीधे Microsoft Intune, Jamf Pro, और VMware Workspace ONE सहित MDM प्लेटफॉर्म के साथ एकीकृत हो जाता है। MDM डिवाइस पर एक SCEP कॉन्फ़िगरेशन प्रोफाइल भेजता है। डिवाइस एक की-पेयर (key pair) बनाता है, आपके SCEP सर्वर को एक सर्टिफिकेट साइनिंग अनुरोध भेजता है, और एक हस्ताक्षरित सर्टिफिकेट वापस प्राप्त करता है - वह भी बिना किसी यूजर इंटरैक्शन के। [medium pause] Active Directory परिवेश में Windows डिवाइस के लिए, आपके पास एक विकल्प है: Active Directory Certificate Services के माध्यम से ग्रुप पॉलिसी-संचालित ऑटो-एनरोलमेंट। डिवाइस डोमेन पर प्रमाणित होता है, CA स्वचालित रूप से एक सर्टिफिकेट जारी करता है, और बिना किसी मैन्युअल हस्तक्षेप के समाप्त होने से पहले सर्टिफिकेट का नवीनीकरण हो जाता है। अत्यधिक Windows वाले इंफ्रास्ट्रक्चर के लिए यह सबसे सुगम मार्ग है। [medium pause] अब बात करते हैं निरसन (revocation) की। यह वह हिस्सा है जिसमें संगठन अक्सर सबसे कम निवेश करते हैं, और कुछ गलत होने पर यही हिस्सा सबसे अधिक मायने रखता है। यदि कोई डिवाइस खो जाता है, चोरी हो जाता है, या कोई कर्मचारी नौकरी छोड़ देता है, तो आपको उनके सर्टिफिकेट को तुरंत रद्द करने की आवश्यकता होती है। इसके लिए दो तंत्र हैं: CRL - Certificate Revocation Lists - और OCSP - Online Certificate Status Protocol। [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] इसे वास्तविक रूप में समझाने के लिए मुझे आपको दो ठोस परिदृश्य (scenarios) बताने दें। [medium pause] पहला: एक 150-प्रॉपर्टी वाला होटल ग्रुप। वे स्टाफ WiFi के लिए एक साझा पासवर्ड के साथ PEAP चला रहे थे। पासवर्ड रोटेशन त्रैमासिक था, जिसका अर्थ था कि हर तिमाही में दो-सप्ताह का एक ऐसा समय आता था जब स्टाफ लॉक आउट हो जाता था या पुराने पासवर्ड का उपयोग कर रहा होता था। वे सर्टिफिकेट डिप्लॉयमेंट के लिए Microsoft Intune का उपयोग करके EAP-TLS पर चले गए। SCEP प्रोफाइल सभी Windows और iOS डिवाइस पर पुश किए गए। 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 का उपयोग किया, दोनों एक Microsoft ADCS Intermediate CA द्वारा समर्थित एक ही SCEP सर्वर की ओर इशारा करते थे। 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 के हार्डवेयर-अज्ञेयवादी आर्किटेक्चर का अर्थ है कि यह Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist और बाकी सभी हार्डवेयर सूची में काम करता है - आप किसी एक वेंडर के PKI टूलिंग में बंधे नहीं हैं। [medium pause] अगले कदम: अपनी वर्तमान सर्टिफिकेट सूची का ऑडिट करें। यदि आप नहीं जानते कि आपके पास कितने सर्टिफिकेट हैं, वे कब समाप्त होते हैं, और उन्हें किसने जारी किया है, तो यह पहली चीज़ है जिसे ठीक किया जाना चाहिए। वहां से, पूर्ण स्वचालन का मार्ग अच्छी तरह से परिभाषित है। सुनने के लिए धन्यवाद।