EAP-TLS WiFi ऑथेंटिकेशनसाठी डिजिटल सर्टिफिकेट्स व्यवस्थापित करणे

आत्मविश्वासू, अधिकारयुक्त आणि संभाषणात्मक सुरात ब्रिटिश इंग्रजीमध्ये बोला - जसे की एखादे ज्येष्ठ सल्लागार क्लायंटला माहिती देत आहेत. मोजलेला वेग, स्पष्ट शब्दोच्चार, उबदार पण थेट. जोड देण्यासाठी आवश्यकतेनुसार नैसर्गिक थांबे: Purple च्या तांत्रिक माहिती पत्रक मालिकेत आपले स्वागत आहे. आज आपण EAP-TLS प्रमाणपत्र व्यवस्थापनाबद्दल बोलत आहोत - विशेषतः, प्रमाणपत्र-आधारित WiFi प्रमाणीकरण कार्यक्रम मोठ्या प्रमाणावर कसा चालवायचा जेणेकरून तो एक पूर्णवेळचा परिचालन भार बनणार नाही. [medium pause] जर तुम्ही मल्टिपल साईट्सवर कॉर्पोरेट किंवा स्टाफ WiFi साठी जबाबदार असाल - मग ते हॉटेल ग्रुप असो, रिटेल इस्टेट असो, युनिव्हर्सिटी कॅम्पस असो किंवा पब्लिक-सेक्टर इस्टेट असो - हे माहिती पत्रक तुमच्यासाठी आहे. आम्ही प्रमाणपत्राच्या संपूर्ण जीवनचक्राचा समावेश करणार आहोत: तुमच्या CA हायरार्की सेट अप करण्यापासून ते SCEP आणि MDM द्वारे स्वयंचलित उपयोजनापर्यंत, आणि नूतनीकरण व निरसनापर्यंत (revocation). आणि गोष्टी कुठे चुकतात याबद्दलही आम्ही बोलू, कारण त्या नक्कीच चुकतात, आणि सर्वात सामान्य चुका कशा टाळायच्या याबद्दल जाणून घेऊ. [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 म्हटले जाते - तो प्रत्यक्षात दैनंदिन प्रमाणपत्रांवर स्वाक्षरी करतो. तो ऑनलाइन असतो, पण त्याची खाजगी की (private key) सुरक्षित ठेवली जाते. त्याखाली, तुम्ही दोन प्रकारची प्रमाणपत्रे जारी करता: तुमच्या RADIUS इन्फ्रास्ट्रक्चरसाठी सर्व्हर प्रमाणपत्रे, आणि तुमच्या डिव्हाइसेस व युझर्ससाठी क्लायंट प्रमाणपत्रे. [medium pause] हे का महत्त्वाचे आहे? कारण जर तुमच्या रूट CA शी तडजोड झाली, तर तुम्हाला तुमचे संपूर्ण PKI सुरुवातीपासून पुन्हा तयार करावे लागेल आणि प्रत्येक डिव्हाइस पुन्हा नोंदवावे लागेल. ते ऑफलाइन ठेवल्याने हा धोका टळतो. रूटला स्पर्श न करता इंटरमीडिएट CA बदलला जाऊ शकतो. थ्री-टियर मॉडेलसाठी हाच ऑपरेशनल लवचिकतेचा तर्क आहे. [medium pause] चला सर्टिफिकेटच्या वैधतेच्या कालावधीबद्दल बोलूया. येथे उद्योगात एक लक्षणीय बदल झाला आहे. Apple, Google आणि Mozilla या सर्वांनी कमीत कमी कमाल सर्टिफिकेट आयुष्यमान लागू करण्यास सुरुवात केली आहे. TLS सर्व्हर सर्टिफिकेट्ससाठी, कमाल मर्यादा आता ३९८ दिवस आहे. एंटरप्राइझ WiFi मधील क्लायंट सर्टिफिकेट्ससाठी, तुमच्याकडे अधिक लवचिकता आहे - एक ते दोन वर्षे असणे सामान्य आहे - परंतु मॅन्युअली व्यवस्थापित केलेल्या दीर्घायुष्यी सर्टिफिकेट्सऐवजी कमी कालावधीचे आयुष्य आणि ऑटोमेटेड रिन्यूअलकडे कल वाढत आहे. याचे कारण सोपे आहे: सर्टिफिकेट धोक्यात आल्यास कमी कालावधीचे आयुष्य एक्सपोजरची विंडो मर्यादित करते. [medium pause] यामुळे आपण ऑटोमेशनकडे वळतो. मॅन्युअल सर्टिफिकेट व्यवस्थापन स्केल होत नाही. तुमच्याकडे ५०० डिव्हाइसेस असल्यास, तुम्ही रिन्यूअल्स हाताने व्यवस्थापित करू शकता. तुमच्याकडे ५० साइट्सवर ५,००० डिव्हाइसेस असल्यास, तुम्ही ते करू शकत नाही. तुम्हाला SCEP - Simple Certificate Enrolment Protocol - किंवा त्याचे आधुनिक उत्तराधिकारी, EST ची आवश्यकता आहे. SCEP थेट Microsoft Intune, Jamf Pro, आणि VMware Workspace ONE सह MDM प्लॅटफॉर्मसह इंटिग्रेट होते. MDM डिव्हाइसवर SCEP कॉन्फिगरेशन प्रोफाइल पाठवते. डिव्हाइस एक की पेअर जनरेट करते, तुमच्या SCEP सर्व्हरला सर्टिफिकेट साइनिंग रिक्वेस्ट पाठवते आणि स्वाक्षरी केलेले सर्टिफिकेट परत मिळवते - हे सर्व कोणत्याही युझर परस्परसंवादाशिवाय होते. [medium pause] Active Directory वातावरणातील Windows डिव्हाइसेससाठी, तुमच्याकडे एक पर्याय आहे: Active Directory Certificate Services द्वारे ग्रुप पॉलिसी-चालित ऑटो-एन्रोलमेंट. डिव्हाइस डोमेनवर ऑथेंटिकेट होते, CA स्वयंचलितपणे सर्टिफिकेट जारी करते, आणि कोणत्याही मॅन्युअल हस्तक्षेपाशिवाय कालबाह्य होण्यापूर्वी सर्टिफिकेट रिन्यू केले जाते. Windows-heavy इस्टेट्ससाठी हा सर्वात अखंड मार्ग आहे. [medium pause] आता, रेव्होकेशन (रद्द करणे). हा असा भाग आहे ज्यामध्ये संस्था बऱ्याचदा कमी गुंतवणूक करतात, आणि जेव्हा काहीतरी चुकीचे घडते तेव्हा हा भाग सर्वात महत्त्वाचा ठरतो. जर एखादे डिव्हाइस हरवले, चोरीला गेले किंवा एखादा कर्मचारी सोडून गेला, तर तुम्हाला त्यांचे सर्टिफिकेट त्वरित रद्द करावे लागेल. यासाठी दोन यंत्रणा आहेत: CRL - Certificate Revocation Lists - आणि OCSP - Online Certificate Status Protocol. [medium pause] CRL ही जुनी यंत्रणा आहे. तुमचे CA एका ज्ञात URL वर रद्द केलेल्या सर्टिफिकेट सिरीयल नंबरची यादी प्रकाशित करते. RADIUS सर्व्हर ही यादी ठराविक कालावधीने डाउनलोड करतो आणि त्याविरुद्ध तपासणी करतो. CRL मधील समस्या म्हणजे लेटन्सी (विलंब) - जर तुमच्या CRL चा वैधतेचा कालावधी २४ तासांचा असेल, तर रद्द केलेले सर्टिफिकेट रद्द केल्यानंतरही २४ तासांपर्यंत ऑथेंटिकेट होऊ शकते. [medium pause] OCSP हा रिअल-टाइम पर्याय आहे. RADIUS सर्व्हर प्रत्येक ऑथेंटिकेशनच्या प्रयत्नासाठी OCSP रिस्पॉन्डरला क्वेरी पाठवतो, आणि थेट लाइव्ह चांगले किंवा रद्द केलेले उत्तर मिळवतो. तडजोड अशी आहे की तुमचा OCSP रिस्पॉन्डर एक महत्त्वपूर्ण अवलंबित्व बनतो - जर तो अनुपलब्ध असेल, तर तुम्हाला फेल ओपन करायचे की फेल क्लोज करायचे हे ठरवावे लागेल. उच्च-सुरक्षा वातावरणासाठी, फेल क्लोज हे योग्य उत्तर आहे. उपलब्धता महत्त्वाची असलेल्या ऑपरेशनल वातावरणासाठी, तुम्ही लहान OCSP ग्रेस पिरियड कॉन्फिगर करू शकता. [medium pause] हे वास्तववादी करण्यासाठी मी तुम्हाला दोन ठोस उदाहरणे देतो. [medium pause] पहिला: १५०-प्रॉपर्टीचा हॉटेल समूह. ते कर्मचारी WiFi साठी शेअर केलेल्या पासवर्डसह PEAP चालवत होते. पासवर्ड रोटेशन त्रैमासिक होते, ज्याचा अर्थ प्रत्येक तिमाहीत दोन आठवड्यांचा असा कालावधी असायचा जिथे कर्मचारी लॉक आउट व्हायचे किंवा जुना पासवर्ड वापरायचे. ते सर्टिफिकेट डिप्लॉयमेंटसाठी Microsoft Intune वापरून EAP-TLS वर स्थलांतरित झाले. SCEP प्रोफाइल्स सर्व Windows आणि iOS डिव्हाइसेसवर पुश केले गेले. CA म्हणून Active Directory Certificate Services वापरले गेले. परिणाम: शून्य पासवर्ड रोटेशन इव्हेंट्स, कालबाह्य होण्याच्या ३० दिवस आधी सर्टिफिकेट रिन्यूअल स्वयंचलितपणे हाताळले गेले, आणि जेव्हा एखादा कर्मचारी नोकरी सोडून गेला, तेव्हा त्याचे सर्टिफिकेट Microsoft Entra ID मध्ये खाते निष्क्रिय केल्याच्या काही मिनिटांतच MDM मध्ये रद्द करण्यात आले. IT टीमच्या अंदाजानुसार त्यांनी पासवर्ड रिसेट आणि हेल्पडेस्क तिकिटांमध्ये प्रति तिमाही साधारणपणे ४० तास वाचवले. [medium pause] दुसरा: २०० स्टोअर्समध्ये ३,००० कर्मचारी डिव्हाइसेस असणारी एक मल्टी-साइट रिटेल साखळी. येथील आव्हान डिव्हाइसेसची विविधता हे होते - Windows लॅपटॉप, Android हँडहेल्ड आणि iOS डिव्हाइसेसचे मिश्रण. त्यांनी Apple डिव्हाइसेससाठी Jamf Pro आणि Windows व Android साठी Microsoft Intune वापरले, दोन्ही एकाच Microsoft ADCS इंटरमीडिएट CA द्वारे समर्थित SCEP सर्व्हरकडे निर्देश करत होते. WiFi इन्फ्रास्ट्रक्चर Cisco Meraki होते, ज्यामध्ये RADIUS ऑथेंटिकेशन Purple सोबत इंटिग्रेट केलेल्या क्लाउड-होस्टेड RADIUS सेवेद्वारे हाताळले जात होते. १२-महिन्यांच्या वैधतेसह सर्टिफिकेट जारी करणे आणि कालबाह्य होण्याच्या ६० दिवस आधी स्वयंचलित रिन्यूअल कॉन्फिगर करणे हा महत्त्वाचा डिझाइन निर्णय होता. यामुळे ऑपरेशनल ओव्हरहेड न वाढवता एक सुलभ रिन्यूअल विंडो मिळाली. [medium pause] आता, धोके. मला सातत्याने दिसणारे चार धोके आहेत. [medium pause] पहिला: रिव्होकेशन (रद्द करणे) ची चाचणी न घेणे. संस्था त्यांचे PKI सेट अप करतात, सर्टिफिकेट्स डिप्लॉय करतात, आणि रिव्होकेशन एंड-टू-एंड काम करते की नाही याची कधीही प्रत्यक्ष चाचणी घेत नाहीत. याची चाचणी घ्या. एक चाचणी सर्टिफिकेट रद्द करा, तुमच्या अपेक्षित वेळेत RADIUS सर्व्हर ते रिव्होकेशन स्वीकारतो की नाही याची खात्री करा, आणि डिव्हाइसला प्रवेश नाकारला गेल्याची पुष्टी करा. [medium pause] दुसरा: एक्स्पायरी क्लिफ एजेस (एकाच वेळी कालबाह्य होणे). जर तुम्ही तुमची सर्व सर्टिफिकेट्स एकाच वेळी समान वैधतेसह जारी केली, तर ती सर्व एकाच वेळी कालबाह्य होतील. तुमचे इश्यूअन्स वेगवेगळ्या टप्प्यांत करा, किंवा किमान तुमचे रिन्यूअल ट्रिगर्स टप्प्याटप्प्याने सेट करा. ५,००० डिव्हाइसेसवर एकाच वेळी १०% रिन्यूअल अपयशाचा दर ही एक मोठी समस्या बनू शकते. [medium pause] तिसरा: EAP-TLS डिप्लॉय करण्यापूर्वी सर्व डिव्हाइसेसवर Root CA सर्टिफिकेट वितरित न करणे. जर डिव्हाइस तुमच्या Root CA वर विश्वास ठेवत नसेल, तर ते RADIUS सर्व्हरचे सर्टिफिकेट नाकारेल आणि ऑथेंटिकेशन अयशस्वी होईल. हे स्पष्ट वाटते, परंतु जेव्हा संस्थांकडे MDM मध्ये नोंदणीकृत नसलेले BYOD डिव्हाइसेस किंवा कंत्राटदारांचे लॅपटॉप असतात तेव्हा त्यांच्याकडून ही चूक होते. [medium pause] चौथा: OCSP रिस्पॉन्डर उपलब्धता. जर तुमचा OCSP रिस्पॉन्डर बंद पडला आणि तुमचा RADIUS सर्व्हर OCSP त्रुटींवर बंद (fail closed) होण्यासाठी कॉन्फिगर केला असेल, तर तुमचे संपूर्ण 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 संवेदनशील वातावरणासाठी १९२-बिट सुरक्षा मोड अनिवार्य करते, ज्यासाठी विशिष्ट सायफर सूट आवश्यक असतात. 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] पुढील पायऱ्या: तुमच्या सध्याच्या प्रमाणपत्रांच्या यादीचे ऑडिट करा. तुमच्याकडे किती प्रमाणपत्रे आहेत, ती कधी कालबाह्य होतात आणि ती कोणी जारी केली आहेत हे तुम्हाला माहीत नसल्यास, सर्वप्रथम ती गोष्ट दुरुस्त करणे आवश्यक आहे. तिथून, पूर्ण ऑटोमेशनचा मार्ग स्पष्ट आहे. ऐकल्याबद्दल धन्यवाद.