EAP-TLS WiFi प्रमाणीकरणासाठी डिजिटल प्रमाणपत्रे व्यवस्थापित करणे

एका वरिष्ठ सल्लागाराने क्लायंटला माहिती दिल्याप्रमाणे - आत्मविश्वासाने, अधिकृत आणि संभाषणात्मक टोनमध्ये ब्रिटीश इंग्रजीत बोला. मोजलेला वेग, स्पष्ट उच्चार, उबदार पण थेट. आवश्यकतेनुसार नैसर्गिक विराम: Purple तांत्रिक ब्रीफिंग मालिकेमध्ये आपले स्वागत आहे. आज आपण EAP-TLS प्रमाणपत्र व्यवस्थापनाबद्दल बोलत आहोत - विशेषतः, पूर्णवेळ ऑपरेशनल ओझे न बनता मोठ्या प्रमाणावर प्रमाणपत्र-आधारित WiFi प्रमाणीकरण प्रोग्राम कसा चालवायचा याबद्दल। [medium pause] जर तुम्ही अनेक साइट्सवर कॉर्पोरेट किंवा कर्मचारी WiFi साठी जबाबदार असाल - मग ते हॉटेल ग्रुप असो, रिटेल इस्टेट असो, युनिव्हर्सिटी कॅम्पस असो किंवा सार्वजनिक-क्षेत्रातील इस्टेट असो - हे ब्रीफिंग तुमच्यासाठी आहे. आम्ही प्रमाणपत्राचा संपूर्ण लाइफसायकल कव्हर करणार आहोत: तुमच्या CA हायरार्कीची रचना करण्यापासून, SCEP आणि MDM द्वारे स्वयंचलित उपयोजन (automated deployment), ते नूतनीकरण आणि रद्दीकरणापर्यंत. आणि गोष्टी कुठे चुकतात याबद्दल देखील आम्ही बोलणार आहोत, कारण त्या चुकतातच, आणि सर्वात सामान्य चुका कशा टाळायच्या याबद्दल बोलू। [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 असतो - हा ऑफलाइन, एअर-गॅप्ड असावा आणि तुमच्या Intermediate CA प्रमाणपत्रावर स्वाक्षरी करण्यासाठीच केवळ ऑनलाइन आणला जावा. Intermediate CA - ज्याला काहीवेळा Issuing CA म्हटले जाते - हा असा आहे जो प्रत्यक्षात दैनंदिन प्रमाणपत्रांवर स्वाक्षरी करतो. तो ऑनलाइन असतो, परंतु त्याची खाजगी की (private key) सुरक्षित असते. त्याखाली, तुम्ही दोन प्रकारचे प्रमाणपत्र जारी करता: तुमच्या RADIUS इन्फ्रास्ट्रक्चरसाठी सर्व्हर प्रमाणपत्रे आणि तुमच्या डिव्हाइसेस आणि वापरकर्त्यांसाठी क्लायंट प्रमाणपत्रे। [medium pause] हे का महत्त्वाचे आहे? कारण जर तुमचा Root CA धोक्यात आला (compromised), तर तुम्हाला तुमचे संपूर्ण PKI सुरुवातीपासून पुन्हा तयार करावे लागेल आणि प्रत्येक डिव्हाइस पुन्हा नोंदवावे लागेल. ते ऑफलाइन ठेवल्याने तो धोका टळतो. Root ला स्पर्श न करता Intermediate CA बदलला जाऊ शकतो. थ्री-टियर मॉडेलसाठी हाच ऑपरेशनल लवचिकतेचा (operational resilience) युक्तिवाद आहे। [medium pause] चला प्रमाणपत्राच्या वैधता कालावधीबद्दल बोलूया. या क्षेत्रात उद्योगात एक मोठा बदल झाला आहे. Apple, Google आणि Mozilla या सर्वांनी प्रमाणपत्राचा कमाल कालावधी कमी करण्यासाठी पावले उचलली आहेत. TLS सर्व्हर प्रमाणपत्रांसाठी, कमाल कालावधी आता ३९८ दिवस आहे. एंटरप्राइझ WiFi मधील क्लायंट प्रमाणपत्रांसाठी, आपल्याकडे अधिक लवचिकता आहे - एक ते दोन वर्षे असणे सामान्य आहे - परंतु सध्याचा कल मॅन्युअली व्यवस्थापित केलेल्या दीर्घकालीन प्रमाणपत्रांऐवजी कमी कालावधी आणि स्वयंचलित नूतनीकरणाकडे आहे. याचे कारण सोपे आहे: प्रमाणपत्र तडजोड झाल्यास कमी कालावधीमुळे सुरक्षिततेला असलेला धोका मर्यादित होतो. [medium pause] हे आपल्याला ऑटोमेशनकडे घेऊन जाते. मॅन्युअल प्रमाणपत्र व्यवस्थापन मोठ्या प्रमाणावर उपयुक्त ठरत नाही. तुमच्याकडे ५०० डिव्हाइसेस असल्यास, तुम्ही नूतनीकरण मॅन्युअली कसेबसे व्यवस्थापित करू शकता. तुमच्याकडे ५० साइट्सवर ५,००० डिव्हाइसेस असल्यास, तुम्ही ते करू शकत नाही. तुम्हाला SCEP - सिम्पल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल - किंवा त्याचा आधुनिक उत्तराधिकारी, EST ची आवश्यकता आहे. SCEP हे Microsoft Intune, Jamf Pro आणि VMware Workspace ONE सह MDM प्लॅटफॉर्मशी थेट जोडले जाते. MDM डिव्हाइसवर SCEP कॉन्फिगरेशन प्रोफाइल पाठवते. डिव्हाइस की पेअर तयार करते, तुमच्या SCEP सर्व्हरला प्रमाणपत्र स्वाक्षरी विनंती पाठवते आणि स्वाक्षरी केलेले प्रमाणपत्र परत मिळवते - हे सर्व कोणत्याही वापरकर्त्याच्या हस्तक्षेपाशिवाय होते. [medium pause] Active Directory वातावरणातील Windows डिव्हाइसेससाठी, तुमच्याकडे एक पर्याय आहे: Active Directory Certificate Services द्वारे ग्रुप पॉलिसी-चालित ऑटो-एनरोलमेंट. डिव्हाइस डोमेनचे प्रमाणीकरण करते, CA स्वयंचलितपणे प्रमाणपत्र जारी करते आणि प्रमाणपत्र संपण्यापूर्वी कोणत्याही मॅन्युअल हस्तक्षेपाशिवाय त्याचे नूतनीकरण केले जाते. Windows चा मोठ्या प्रमाणावर वापर करणाऱ्या कंपन्यांसाठी हा सर्वात सोपा मार्ग आहे. [medium pause] आता, रिव्होकेशन (रद्दीकरण). हा असा भाग आहे ज्यामध्ये संस्था बहुदा कमी गुंतवणूक करतात आणि जेव्हा काहीतरी बिघडते तेव्हा हाच भाग सर्वात महत्त्वाचा ठरतो. जर डिव्हाइस हरवले, चोरीला गेले किंवा एखादा कर्मचारी सोडून गेला, तर तुम्हाला त्यांचे प्रमाणपत्र त्वरित रद्द करावे लागेल. याच्या दोन यंत्रणा आहेत: CRL - सर्टिफिकेट रिव्होकेशन लिस्ट्स - आणि OCSP - ऑनलाइन सर्टिफिकेट स्टेटस प्रोटोकॉल. [medium pause] CRL ही जुनी यंत्रणा आहे. तुमचा CA रद्द केलेल्या प्रमाणपत्रांच्या अनुक्रमांकांची यादी एका विशिष्ट URL वर प्रसिद्ध करतो. RADIUS सर्व्हर वेळोवेळी ही यादी डाउनलोड करतो आणि त्याशी पडताळणी करतो. CRL मधील समस्या म्हणजे लेटनसी (विलंब) - जर तुमच्या CRL चा वैधता कालावधी २४ तासांचा असेल, तर एखादे प्रमाणपत्र रद्द केल्यानंतरही २४ तासांपर्यंत प्रमाणीकरण होऊ शकते. [medium pause] OCSP हा रिअल-टाइम पर्याय आहे. प्रत्येक प्रमाणीकरण प्रयत्नासाठी RADIUS सर्व्हर OCSP रिस्पॉन्डरला एक क्वेरी पाठवतो आणि त्यावर लाइव्ह वैध किंवा रद्द असा प्रतिसाद मिळवतो. याची तडजोड अशी आहे की तुमचा OCSP रिस्पॉन्डर एक महत्त्वपूर्ण अवलंबित्व बनतो - जर तो अनुपलब्ध असेल, तर तुम्हाला 'fail open' की 'fail closed' करायचे हे ठरवावे लागेल. उच्च-सुरक्षा वातावरणासाठी, 'fail closed' हा योग्य पर्याय आहे. कार्यरत वातावरणात जेथे उपलब्धता महत्त्वाची असते, तेथे तुम्ही लहान 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 वापरले, दोन्ही एकाच SCEP सर्व्हरकडे निर्देश करत होते ज्याला Microsoft ADCS Intermediate CA चे पाठबळ होते. WiFi इन्फ्रास्ट्रक्चर Cisco Meraki होते, ज्यामध्ये Purple सोबत एकत्रित केलेल्या क्लाउड-होस्टेड RADIUS सेवेद्वारे RADIUS ऑथेंटिकेशन हाताळले जात होते. १२ महिन्यांच्या वैधतेसह सर्टिफिकेट्स जारी करणे आणि कालबाह्य होण्याच्या ६० दिवस आधी स्वयंचलित रिन्यूअल कॉन्फिगर करणे हा मुख्य डिझाइन निर्णय होता. यामुळे ऑपरेशनल ओव्हरहेड न वाढवता रिन्यूअलसाठी सोयीस्कर वेळ मिळाला. [medium pause] आता, त्रुटींविषयी. मला अशा चार गोष्टी वारंवार दिसतात. [medium pause] पहिली: रिव्होकेशन (रद्द करण्याची प्रक्रिया) न तपासणे. संस्था त्यांचे PKI सेटअप करतात, सर्टिफिकेट्स डिप्लॉय करतात आणि रिव्होकेशन प्रत्यक्षात एंड-टू-एंड काम करते की नाही हे कधीच तपासत नाहीत. ते तपासा. एखादे चाचणी सर्टिफिकेट रद्द करा, RADIUS सर्व्हर तुमच्या अपेक्षित वेळेत ते रद्द केल्याचे शोधून काढतो की नाही याची खात्री करा, आणि उपकरणाला प्रवेश नाकारला गेल्याची पुष्टी करा. [medium pause] दुसरी: एक्स्पायरी क्लिफ एडजेस (एकत्रित कालबाह्यता). तुम्ही तुमची सर्व सर्टिफिकेट्स एकाच वेळी समान वैधतेसह जारी केल्यास, ती सर्व एकाच वेळी कालबाह्य होतात. तुमची सर्टिफिकेट्स जारी करण्याची प्रक्रिया वेगवेगळ्या टप्प्यांत करा, किंवा कमीत कमी रिन्यूअल ट्रिगर्स वेगवेगळ्या टप्प्यांत करा. ५,००० उपकरणांवर एकाच वेळी १०% रिन्यूअल अयशस्वी होण्याचे प्रमाण ही एक मोठी समस्या ठरू शकते. [medium pause] तिसरी: EAP-TLS डिप्लॉय करण्यापूर्वी सर्व उपकरणांवर Root CA सर्टिफिकेट वितरीत न करणे. जर उपकरण तुमच्या Root CA वर विश्वास ठेवत नसेल, तर ते RADIUS सर्व्हरचे सर्टिफिकेट नाकारेल आणि ऑथेंटिकेशन अयशस्वी होईल. हे अगदी उघड वाटते, पण जेव्हा संस्थांकडे BYOD उपकरणे किंवा कंत्राटदारांचे लॅपटॉप असतात जे MDM मध्ये नोंदणीकृत नसतात, तेव्हा त्यांची अडचण होते. [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 हायराॅर्की (hierarchy). SCEP किंवा MDM द्वारे स्वयंचलित नोंदणी. स्वयंचलित नूतनीकरणासह लहान प्रमाणपत्र लाइफटाइम. OCSP द्वारे रिअल-टाइम रिव्होकेशन (रद्दीकरण). प्रत्येक गोष्टीची चाचणी घ्या, विशेषतः रिव्होकेशनची. आणि तुमच्या प्रमाणपत्राचे लाइफसायकल तुमच्या ओळख प्रदात्याशी (identity provider) - Microsoft Entra ID, Okta, किंवा Google Workspace - समाकलित (integrate) करा, जेणेकरून एखादे खाते बंद केल्यावर प्रमाणपत्र रिव्होकेशन स्वयंचलितपणे ट्रिगर होईल. [medium pause] तुम्ही Purple-लिंक केलेले RADIUS सर्व्हर चालवत असल्यास, इंटिग्रेशन पॉइंट्स तुमचे SCEP सर्व्हर URL, तुमचे RADIUS सर्व्हर प्रमाणपत्र आणि तुमचे CRL किंवा OCSP एंडपॉइंट आहेत. Purple चे हार्डवेअर-अज्ञेयवादी आर्किटेक्चर म्हणजे हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist आणि उर्वरित कॅनोनिकल हार्डवेअर सूचीमध्ये कार्य करते - तुम्ही एकाच विक्रेत्याच्या PKI टूलींगमध्ये अडकलेले नाही. [medium pause] पुढील पायऱ्या: तुमच्या सध्याच्या प्रमाणपत्र इन्व्हेंटरीचे ऑडिट करा. तुमच्याकडे किती प्रमाणपत्रे आहेत, ती कधी कालबाह्य होतात आणि ती कोणी जारी केली आहेत हे तुम्हाला माहीत नसेल, तर सर्वप्रथम ती गोष्ट दुरुस्त करणे आवश्यक आहे. तेथून, पूर्ण ऑटोमेशनचा मार्ग स्पष्टपणे परिभाषित आहे. ऐकल्याबद्दल धन्यवाद.