सोमवारच्या सकाळचा आउटेज क्वचितच एखाद्या नाट्यमय PKI बिघाडामुळे सुरू होतो. हे अशा सर्टिफिकेटमुळे सुरू होते ज्याचे अस्तित्व कोणालाच माहीत नसते. WiFi ऑथेंटिकेशन सर्व्हरवरील RADIUS सर्टिफिकेट वीकेंडला एक्स्पायर होते, पहिली शिफ्ट येते आणि शेकडो युजर्स कनेक्ट करू शकत नाहीत. ऑन-कॉल इंजिनिअर डॅशबोर्ड, व्हेंडर पोर्टल्स, जुने स्प्रेडशीट्स आणि सर्व्हर स्टोअर्स शोधतो आणि अखेर प्रत्यक्ष कारण समोर येते.
ती घटना प्रश्न बदलते. प्रमाणपत्रे कशी व्यवस्थापित करावीत हा प्रामुख्याने की जनरेट करण्याचा किंवा नूतनीकरणावर क्लिक करण्याचा प्रश्न नाही. हा नेटवर्क, ओळख, ॲप्लिकेशन आणि डिव्हाइस टीम्समधील दृश्यमानता, मालकी, अवलंबित्व आणि विश्वसनीय कृतीचा प्रश्न आहे. प्रमाणपत्राचे जीवनचक्र केवळ तेव्हाच कार्य करते जेव्हा कोणीतरी प्रत्येक प्रमाणपत्र ओळखू शकते, त्यावर काय अवलंबून आहे हे समजून घेऊ शकते आणि ते बदलण्यासाठी जबाबदार असलेल्या व्यक्ती किंवा ऑटोमेशनपर्यंत पोहोचू शकते.
सर्टिफिकेटचा अनिर्बंध विस्तार ही खरी समस्या का आहे
मिश्र पायाभूत सुविधा (mixed infrastructure) असलेल्या संस्थांमध्ये प्रमाणपत्रांचा पसारा नैसर्गिकरित्या वाढतो. नेटवर्क इंजिनिअर्स RADIUS आणि VPN प्रमाणपत्रे व्यवस्थापित करतात. सिक्युरिटी टीम्स SAML आणि OIDC सायनिंग प्रमाणपत्रांवर देखरेख ठेवतात. DevOps टीम्स क्लाउड प्लॅटफॉर्म्स किंवा CI/CD पाइपलाइन्सद्वारे ॲप्लिकेशन TLS प्रमाणपत्रे जारी करतात. IT ॲडमिनिस्ट्रेटर्स एंडपॉइंट मॅनेजमेंट सिस्टीम्सद्वारे डिव्हाइस एनरोलमेंट प्रमाणपत्रे प्रोव्हिजन करतात.
प्रत्येक टीम स्वतंत्रपणे समंजसपणे कार्य करू शकते आणि तरीही अशी मालमत्ता तयार करू शकते जी संपूर्णपणे कोणालाही दिसू शकत नाही.
व्यावहारिक नियम: प्रत्येक सर्टिफिकेटला प्रोडक्शन डिपेंडन्सी म्हणून हाताळा, सर्व्हरवर पडलेली केवळ एक फाईल म्हणून नाही.
स्प्रेडशीट्स अपयशी ठरतात कारण त्या केवळ एखाद्याला काय आठवते ते नोंदवतात, पर्यावरण प्रत्यक्षात काय वापरत आहे ते नाही. त्या क्वचितच प्रमाणपत्रे स्वयंचलितपणे शोधतात, त्या लीफ प्रमाणपत्रापासून ते इंटरमीडिएट आणि रूट CA पर्यंतच्या साखळीचे विश्वसनीयपणे प्रतिनिधित्व करत नाहीत, आणि एखादे प्रमाणपत्र दुसऱ्या लोड बॅलन्सर, उपकरणावर किंवा विक्रेता-व्यवस्थापित सेवेवर कॉपी केले गेले आहे की नाही हे त्या तुम्हाला सांगू शकत नाहीत. स्प्रेडशीट पुनरावलोकनाचे समर्थन करू शकते, परंतु ते तुम्हाला आउटेजबद्दल चेतावणी देणारी प्रणाली नसावी.
ऑपरेशनल जोखीम UK रिपोर्टिंगमध्ये चांगल्या प्रकारे दस्तऐवजीकरण केली आहे. केवळ ३४% सर्वेक्षण केलेल्या उत्तरदात्यांकडे त्यांच्या डिजिटल प्रमाणपत्रांचे संपूर्ण, अद्ययावत दृश्य होते, तर ७४% मुदत संपलेल्या प्रमाणपत्रांमुळे होणाऱ्या आउटेजबाबत अत्यंत किंवा कमालीचे चिंतेत होते. त्याच रिपोर्टिंगमध्ये असे आढळून आले की ५१% लोकांनी सायलोड टूल्स हे एक मोठे आव्हान असल्याचे नमूद केले, आणि ४७% सर्वेक्षण केलेले नेते अद्याप मॅन्युअल ट्रॅकिंगसाठी स्प्रेडशीटवर अवलंबून होते. हे आकडे UK certificate visibility and sprawl reporting वरून आले आहेत.
दीर्घ आणि अल्प लाइफटाईममधील तडजोड (trade-off)
दीर्घकाळ टिकणारे सर्टिफिकेट्स देखभालीचे काम कमी करतात. परंतु, यामुळे तडजोड झालेली प्रायव्हेट की उपयुक्त राहण्यासाठी अधिक मोठा कालावधी मिळतो, आणि एखादे विसरलेले सर्टिफिकेट इतर कोणताही संबंधित नसलेला सिस्टम बदल होईपर्यंत दुर्लक्षित राहू शकते.
कमी कालावधीची प्रमाणपत्रे तो धोका कमी करतात, परंतु त्यांना विश्वसनीय ऑटोमेशनची आवश्यकता असते. नूतनीकरणामध्ये नवीन की जनरेट करणे, बदली प्रमाणपत्र मिळवणे, संपूर्ण चेन वितरित करणे, योग्य एंडपॉइंट्सवर ते तैनात करणे आणि क्लायंट नवीन निकालावर विश्वास ठेवतात याची पडताळणी करणे आवश्यक आहे. UK DWP PKI standard रूट, पॉलिसी, सबऑर्डिनेट आणि एंड-एंटिटी की साठी भिन्न कमाल लाइफटाइम सेट करतो, ज्यावरून हे स्पष्ट होते की एकच सरसकट धोरण प्रत्येक प्रमाणपत्र वर्गामध्ये क्वचितच काम करते.
त्यामुळे पहिले व्यावहारिक पाऊल ऑटोमेशन नाही. ते एक एकत्रित इन्व्हेंटरी (unified inventory) आहे जे शोध, मालकी, अवलंबित्व, जोखीम वर्गीकरण आणि डिप्लॉयमेंटचे पुरावे एकत्र आणते. या पायाशिवाय, ऑटोमेशन केवळ अशाच सर्टिफिकेट्सचे नूतनीकरण करते जे एका टूलला दिसू शकतात, तर शॅडो सर्टिफिकेट्स इतर ठिकाणी जुने होत राहतात.
एक संपूर्ण सर्टिफिकेट इन्व्हेंटरी तयार करणे
प्रोडक्शन इन्व्हेंटरीची सुरुवात डिस्कव्हरीने होते, मॅन्युअल डेटा एंट्रीने नाही. तुमची संस्था ऑपरेट करत असलेल्या सेवांवर ऑथेंटिकेटेड स्कॅन्स रन करा, ज्यामध्ये TLS आणि डिरेक्टरी-सर्व्हिस एंडपॉईंट्स समाविष्ट आहेत, आणि नंतर सर्टिफिकेट्स इश्यू किंवा स्टोअर करणाऱ्या प्लॅटफॉर्म्सना क्वेरी करा. नेटवर्क स्कॅन्स ४४३, ६३६, ८४४३ आणि १८१२ सारख्या पोर्ट्सवर उघड झालेले सर्टिफिकेट्स शोधू शकतात. सर्व्हर-साइड कलेक्शनने Windows सर्टिफिकेट स्टोअर्स, Linux फाइलसिस्टम लोकेशन्स, Java कीस्टोअर्स, रिव्हर्स प्रॉक्सी, लोड बॅलन्सर्स, फायरवॉल्स, वायरलेस कंट्रोलर्स आणि मॅनेज्ड ॲप्लायन्सेसचे निरीक्षण केले पाहिजे.
डिरेक्टरी सर्व्हिसेसना एक स्वतंत्र डिस्कव्हरी सोर्स म्हणून हाताळा. Microsoft Entra ID, Active Directory, Google Workspace, Okta आणि एंडपॉईंट मॅनेजमेंट प्लॅटफॉर्म्समधील सर्टिफिकेट ऑब्जेक्ट्स आणि प्रोफाइल्स क्वेरी करा. एखादे सर्टिफिकेट कधीही लिसनिंग पोर्टवर दिसणार नाही परंतु तरीही डिव्हाइस ऑथेंटिकेशन किंवा WiFi ॲक्सेस नियंत्रित करत असेल. नेटवर्क व्हेंडर्स आणखी एक ब्लाइंड स्पॉट तयार करतात: वायरलेस कंट्रोलर्स, फायरवॉल्स, VPN गेटवे आणि RADIUS प्लॅटफॉर्म्स प्रत्येकाकडे स्वतंत्र रिन्युअल प्रक्रिया आणि मालकीसह त्यांची स्वतःची कॉपी असू शकते.
तुम्ही नियुक्त करण्यापूर्वी सामान्यीकरण करा
डिस्कव्हरी टूल्स विसंगत फॉरमॅट्स देतात. त्यांच्या परिणामांचे प्रत्येक सर्टिफिकेटसाठी एका रेकॉर्डमध्ये रूपांतर करा, नंतर आवश्यकतेनुसार सिरीयल नंबर, फिंगरप्रिंट आणि पब्लिक-की आयडेंटिटी वापरून डुप्लिकेट्स काढून टाका. न वापरलेली फाईल आणि सक्रिय प्रॉडक्शनवरील अवलंबित्व यामधील फरक ओळखण्यासाठी पुरेसा संदर्भ ठेवा. प्रोव्हाइडर आणि डिस्कव्हरी पद्धती देखील रेकॉर्ड करा, जेणेकरून एखादा गहाळ झालेला परिणाम शोधताना सोर्स सिस्टमचा माग काढता येईल.
| क्षेत्र | उदाहरण मूल्य | उद्देश्य |
|---|---|---|
| विषय | सेवा किंवा डिव्हाइस ओळख | प्रमाणपत्र विषय ओळखतो |
| जारीकर्ता | मध्यवर्ती CA नाव | कोणत्या प्राधिकरणाने स्वाक्षरी केली आहे ते दर्शवते |
| SANs | DNS, ईमेल, URI किंवा डिव्हाइस आयडेंटिफायर्स | क्लायंटद्वारे प्रमाणित केल्या जाणाऱ्या ओळखींची नोंद ठेवते |
| की वापर | सर्व्हर प्रमाणीकरण किंवा क्लायंट प्रमाणीकरण | चुकीच्या भूमिकेत वापर होण्यास प्रतिबंध करते |
| कालबाह्यता | वैधतेची अंतिम तारीख | नूतनीकरण नियोजनात मदत करते |
| अनुक्रमांक | CA-जारी आयडेंटिफायर | ऑडिट आणि रद्दीकरणास समर्थन देते |
| साठवण स्थान | सर्व्हर स्टोअर, अप्लायन्स, डिरेक्टरी प्रोफाइल किंवा व्हॉल्ट | बदली कोठे झाली पाहिजे ते दर्शवते |
| मालक आणि संपर्क | नियुक्त टीम आणि एस्केलेशन संपर्क | कारवाई करणे शक्य करते |
| अवलंबित्व साखळी | मध्यवर्ती आणि रूट संबंध | सामायिक बिघाड बिंदू उघड करते |
| स्थिती | सक्रिय, टप्प्याटप्प्याने केलेले, कालबाह्य, रद्द केलेले किंवा न वापरलेले | ऐतिहासिक गोंधळापासून जोखीम वेगळी करते |
मालकी हक्क ठरवतो की इन्व्हेंटरी प्रत्यक्ष कृती करण्यास सक्षम आहे की नाही. केवळ "नेटवर्क" किंवा "IT" लिहिल्याने बदल कोण मंजूर करतो, उपयोजन (deployment) कोण करतो किंवा बिघाड झाल्यास कोण प्रतिसाद देतो हे स्पष्ट होत नाही. यासाठी एक सर्व्हिस ओनर, ऑपरेशनल टीम, एस्केलेशन संपर्क आणि बिझनेस क्रिटिकॅलिटी नियुक्त करा. जर एखादे RADIUS प्रमाणपत्र कर्मचाऱ्यांच्या WiFi ला सपोर्ट करत असेल, तर नेटवर्क सर्व्हिस, बॅकअप ऑपरेटर, प्लॅटफॉर्म ओनर आणि उपयोजनास मंजुरी देणाऱ्या बदल प्रक्रियेच्या लेखकाची नोंद ठेवा.
चेन्स मॅप करा आणि जोखमीचे वर्गीकरण करा
एखादे लीफ प्रमाणपत्र अवैध ठरण्याचे कारण त्याची वैधता संपणे, सर्व्हरने इंटरमीडिएट वगळणे किंवा क्लायंटने रूटवरील विश्वास काढून घेणे हे असू शकते. प्रत्येक लीफचा त्याच्या इंटरमीडिएटशी आणि प्रत्येक इंटरमीडिएटचा त्याच्या रूटशी मॅप तयार करा. त्यानंतर सामायिक अवलंबित्वे (shared dependencies) चिन्हांकित करा. एकच इंटरमीडिएट CA असंबंधित सेवांना सपोर्ट करू शकतो, ज्यामुळे त्याच्या रिप्लेसमेंटचे काम डिरेक्टरी सर्व्हिसेस, सर्व्हर्स आणि नेटवर्क व्हेंडर्समधील एका समन्वित बदलामध्ये रूपांतरित होते.
ऑपरेशनल परिणामांचे प्रतिनिधित्व करणाऱ्या वर्गीकरणांचा वापर करा:
- प्रॉडक्शन-क्रिटिकल: WiFi ऑथेंटिकेशन, VPN ॲक्सेस, आयडेंटिटी गेटवे, पेमेंट सर्व्हिसेस आणि युजर्सवर तात्काळ प्रभाव पाडणाऱ्या सिस्टम्स.
- ॲप्लिकेशन-फेसिंग: पब्लिक वेब TLS, APIs, रिव्हर्स प्रॉक्सी, इनग्रेस कंट्रोलर्स आणि कस्टमर पोर्टल्स.
- इन्टर्नल: सर्व्हिस-टू-सर्व्हिस mTLS, मशीन आयडेंटिटीज, ॲडमिनिस्ट्रेटिव्ह इंटरफेस आणि डेव्हलपमेंट एन्व्हायरमेंट्स.
शॅडो सर्टिफिकेट्ससाठी स्वतंत्र पडताळणी प्रक्रियेची आवश्यकता असते. ॲप्लिकेशन टीम्स, मॅनेज्ड सर्व्हिस प्रदाते आणि नेटवर्क व्हेंडर्सना खाजगी की कुठे स्टोअर केल्या आहेत, प्रत्येक सर्टिफिकेट कोणत्या प्रदात्याने जारी केले आहे आणि रिन्यूअल कसे केले जाते याबद्दल विचारा. या उत्तरांची तुलना डिरेक्टरी सेवा रेकॉर्ड, अप्लायन्स एक्स्पोर्ट्स आणि स्कॅनिंग रिझल्ट्सशी करा.
एक संपूर्ण इन्व्हेंटरी हा एक राखलेला नियंत्रण रेकॉर्ड असतो, ती एक वेळची यादी नसते. ती सर्टिफिकेट्सना सिस्टम्स, लोक, प्रदाते, अवलंबित्व आणि उपयोजन पुराव्यांशी जोडते, ज्यामुळे प्रत्येक साधनाद्वारे फक्त त्यांना दिसणारी सर्टिफिकेट्स व्यवस्थापित करण्याची परवानगी देण्याऐवजी लाइफसायकल ऑटोमेशनला एक विश्वासार्ह स्रोत मिळतो.
डिरेक्टरी सर्व्हिसेससह प्रमाणपत्रे जारी करणे आणि प्रोव्हिजन करणे
सर्टिफिकेट-आधारित ॲक्सेस अयशस्वी होत असला, तरी एखादे डिव्हाइस मॅनेज्ड म्हणून दिसू शकते. प्रोडक्शनमध्ये, अडथळा सहसा आयडेंटिटी, की जनरेशन, ट्रस्ट इन्स्टॉलेशन आणि सर्व्हिस डिप्लोयमेंट यांच्या दरम्यान असतो. इश्यूअन्सला एका नियंत्रित वर्कफ्लोप्रमाणे हाताळा: की पेअर जनरेट करा, CSR तयार करा, आयडेंटिटी आणि पॉलिसी प्रमाणित करा, मान्यताप्राप्त CA द्वारे साईन करा, आणि नंतर सर्टिफिकेट त्याच्या चेनसह इन्स्टॉल करा. शक्य असेल तेव्हा प्रायव्हेट-की जनरेशन एंडपॉईंटवर किंवा त्याच्या जवळ ठेवा. CSR त्या की च्या मालकीचा पुरावा देतो, त्यामुळे ती की ईमेल, तिकिटिंग सिस्टम किंवा शेअर्ड ॲडमिनिस्ट्रेटर फोल्डर्समधून पास होऊ नये.
Microsoft Entra ID उपयोजन सामान्यतः SCEP किंवा PKCS12 सह Intune प्रमाणपत्र प्रोफाइल वापरतात. SCEP अशा व्यवस्थापित उपकरणांना अनुकूल आहे जे स्वतःच्या की जनरेट करतात आणि नियंत्रित कनेक्टरद्वारे प्रमाणपत्रांची विनंती करतात. जेव्हा प्रोव्हिजनिंग मॉडेलला आवश्यकता असते तेव्हा PKCS12 प्रमाणपत्र आणि खाजगी की पॅकेज करू शकते, परंतु त्या पॅकेजची वाहतूक किंवा स्टोरेज करण्यासाठी अधिक कडक नियंत्रणांची आवश्यकता असते. प्रत्येक प्रोफाइल उपकरणाशी किंवा वापरकर्त्याच्या ओळखीशी बांधा, की चा वापर परिभाषित करा आणि केंद्रीय इन्व्हेंटरीमध्ये जारी करणारे CA आणि ट्रस्ट चेन नोंदवून ठेवा. ती नोंदच एका प्रदात्याच्या प्रमाणपत्र दृश्याला सत्याचा एकमेव स्रोत बनण्यापासून रोखते.
Google Workspace वातावरणात ओळख आणि प्रमाणपत्र सामग्रीमध्ये अशाच वेगळेपणाची आवश्यकता असते. व्यवस्थापित-डिव्हाइस धोरणासाठी Google एंडपॉइंट व्यवस्थापन वापरा, त्यानंतर प्रत्येक प्रमाणपत्राला त्याच्या डिव्हाइस किंवा वापरकर्त्याशी आणि त्यावर नियंत्रण ठेवणाऱ्या धोरणाशी जोडण्यासाठी डिरेक्टरी API आणि संस्थात्मक-युनिट संदर्भाचा वापर करा. निर्यात केलेली प्रमाणपत्र फाइल यशस्वी प्रोव्हिजनिंग सिद्ध करत नाही. एंडपॉइंटला प्रोफाइल प्राप्त झाले आहे, विश्वसनीय रूट स्थापित केले आहे आणि त्यावर विसंबून असलेल्या सेवेला क्लायंट प्रमाणपत्र सादर करू शकते याची खात्री करा.
Okta प्रमाणपत्र-आधारित डिव्हाइस-विश्वास निर्णयांमध्ये योगदान देऊ शकते, परंतु केवळ प्रमाणपत्राची उपस्थिती प्रमाणीकरण पूर्ण करत नाही. लागू असलेल्या साइन-ऑन आणि मल्टी-फॅक्टर पॉलिसींसह प्रमाणपत्र प्रमाणीकरण आणि डिव्हाइस स्थिती एकत्र करा. एखादे डिव्हाइस व्यवस्थापित लोकसंख्येमधून बाहेर पडल्यास, डिरेक्टरी इव्हेंटला प्रमाणपत्र अक्षम किंवा रद्द करण्याच्या प्रक्रियेसह कनेक्ट करा. मॅन्युअल शोधामुळे अनाथ क्रेडेंशियल्स तसेच राहतात आणि डिरेक्टरी रेकॉर्ड, CA कन्सोल आणि नेटवर्क उपकरणांमध्ये अंतर निर्माण होते.
वापराच्या प्रकरणावर आधारित CA निवडा
इंटरनेट-फेसिंग नावे आणि सेवांसाठी सार्वजनिक CA वापरा ज्यांना व्यापक क्लायंट विश्वासाची आवश्यकता आहे. अंतर्गत डिव्हाइस ओळखी, mTLS आणि नियंत्रित एंटरप्राइझ विश्वासासाठी खाजगी CA वापरा. हायब्रिड मॉडेल सार्वजनिक वेब प्रमाणपत्रे अंतर्गत ओळख प्रमाणपत्रांपासून वेगळे ठेवते, तर प्रत्येक PKI योग्य जारी आणि रद्द करण्याच्या नियंत्रणांचे पालन करते. प्रत्येक प्रदात्यासाठी मालकी आणि उपयोजन इंटरफेस दस्तऐवजीकरण करा जेणेकरून नूतनीकरण ऑटोमेशन सर्व्हर्स, डिरेक्टरी सेवा आणि नेटवर्क व्हेंडर्सपर्यंत पोहोचू शकेल.
की (Key) स्टोरेजचा परिणाम रिकव्हरी आणि इन्सिडेंट रिस्पॉन्सवर देखील होतो. TPMs मधील हार्डवेअर बॅक्ड कीज त्यांचे एक्स्ट्रॅक्शन कठीण करतात आणि व्यवस्थापित लॅपटॉप्स तसेच ठराविक हेतूच्या उपकरणांसाठी योग्य ठरतात, जिथे प्लॅटफॉर्म एक स्थिर हार्डवेअर आयडेंटिटी प्रदान करतो. सॉफ्टवेअर की-स्टोअर्स हे विविध हार्डवेअर आणि रिकव्हरी वर्कफ्लोमध्ये वापरण्यास सोपे असतात, परंतु त्यासाठी अधिक मजबूत एंडपॉईंट प्रोटेक्शन आणि ॲक्सेस कंट्रोल्सची आवश्यकता असते.
WiFi मुळे एक व्यावहारिक तडजोड करावी लागते. डिव्हाइस सर्टिफिकेटने ॲक्सेसमध्ये व्यत्यय न आणता नेहमीच्या ऑपरेटिंग-सिस्टम देखभालीमध्ये टिकून राहणे आवश्यक आहे, तर संस्थेला तडजोड किंवा मालकी बदलल्यानंतर ते बदलण्याचा मार्ग देखील हवा असतो. Windows, macOS, iOS आणि Android वर रिन्युअलची चाचणी घ्या, ज्यामध्ये प्रोफाइल अपडेटनंतर सप्लिकंट कसा व्यवहार करतो याचा समावेश आहे. ऑन-प्रिमायसेस RADIUS ॲडमिनिस्ट्रेशन कमी करू पाहणारे संघ स्वतः मॅनेज केलेल्या डिप्लोयमेंटसह certificate-based WiFi साठी RADIUS-as-a-Service चे मूल्यांकन करू शकतात.
रोटेशन नूतनीकरण आणि रिव्होकेशन व्यवस्थापित करणे
पहाटे २ वाजता, CA कडे सर्टिफिकेट यशस्वीरित्या रिन्यू होऊ शकते आणि तरीही सर्व्हिस ऑफलाईन राहू शकते. ॲप्लायन्स चेन नाकारू शकते, प्रायव्हेट की मॅच होणार नाही किंवा ॲप्लिकेशनला मॅन्युअल रिस्टार्टची आवश्यकता असू शकते. त्यामुळे रोटेशन, रिन्युअल आणि रिव्होकेशन हे एकाच ऑपरेशनल वर्कफ्लोचे भाग आहेत, तीन वेगवेगळ्या तिकिटांचे नाही. रिन्युअल कालबाह्य होणारे सर्टिफिकेट बदलते. रोटेशनने सहसा नवीन की तयार केली पाहिजे, कारण जुनी प्रायव्हेट की कायम ठेवल्याने तिचा एक्सपोजर कायम राहतो. रिव्होकेशन हे तडजोड, डिकमिशनिंग किंवा मुदत संपण्यापूर्वी सर्टिफिकेट अवैध ठरवणाऱ्या पॉलिसी निर्णयाला हाताळते.
सर्टिफिकेटची मुदत संपण्यापूर्वीच डिप्लॉयमेंटमधील त्रुटींचे निदान करण्यासाठी रिन्यूअल विंडो पुरेशा वेळेआधी सेट करा. इन्स्टॉलेशन आणि सर्व्हिस रीलोड स्टेटसपेक्षा वेगळ्या पद्धतीने CA मंजुरीचा मागोवा घ्या. हाच तो फरक आहे जिथे सर्टिफिकेटचे विस्कळीत होणे (sprawl) स्पष्ट दिसते: विविध प्रदाते, डिरेक्टरी सेवा, अप्लायन्सेस आणि ॲप्लिकेशन मालक सहसा एकाच लाइफसायकलच्या वेगवेगळ्या भागांचा अहवाल देतात.
नूतनीकरणाची रचना उपयोजन वर्कफ्लो म्हणून करा
एक विश्वासार्ह वर्कफ्लोने हे केले पाहिजे:
- नूतनीकरणाचा कालावधी ओळखा: वैधता, सेवेची संवेदनशीलता, प्रदाता आणि उपयोजन जटिलतेचे मूल्यांकन करा.
- CSR आणि की पुन्हा जनरेट करा: नवीन खाजगी की तयार करा आणि UK DWP PKI जीवनचक्र आवश्यकतांचे पालन करा.
- मंजुरी गेट लागू करा: उच्च-प्रभाव प्रणालींसाठी सेवा-मालक पुष्टीकरण आवश्यक करा, तर धोरण-सुसंगत कमी-जोखीम नूतनीकरण स्वयंचलितपणे सुरू ठेवण्यास अनुमती द्या.
- बदलीची तयारी करा: दुय्यम एंडपॉइंट, नोड, लिसनर किंवा चाचणी प्रोफाइलवर प्रमाणपत्र आणि संपूर्ण साखळी स्थापित करा.
- कटओव्हरपूर्वी सत्यापित करा: नाव, की वापर, साखळी निर्मिती, क्लायंटचा विश्वास आणि ॲप्लिकेशनच्या वर्तनाची तपासणी करा.
- नियंत्रित स्विच करा: सेवा ऑफलाइन न घेता ट्रॅफिक किंवा प्रमाणीकरण नूतनीकरण केलेल्या एंडपॉइंटकडे वळवा.
- पुरावा नोंदवा: अनुक्रमांक, फिंगरप्रिंट, प्रदाता, साखळी साठवण स्थान, मालक, मंजुरी आणि उपयोजन परिणामासह सामायिक इन्व्हेंटरी अद्यतनित करा.
हाय-अॅव्हेलेबल सर्व्हिसेससाठी, एका वेळी एक नोड बदला. उर्वरित नोड्स बदलण्यापूर्वी प्रत्यक्ष क्लायंटच्या वर्तनाची पडताळणी करा. जेथे पॉलिसी परवानगी देते तिथेच रोलबॅकसाठी मागील सर्टिफिकेट ठेवा, नंतर ट्रान्झिशन पूर्ण झाल्यावर जुन्या प्रायव्हेट की काढून टाका. इन्व्हेंटरीमध्ये प्रत्येक व्हेंडर ऑटोमेटेड इन्स्टॉलेशन आणि रीलोड्सला सपोर्ट करतो की नाही हे देखील नोंदवले पाहिजे, कारण केवळ CA रिन्यूअलमुळे बदल पूर्ण होत नाही.
रिव्होकेशन निरीक्षण करण्यायोग्य बनवा
रिव्होकेशन केवळ तेव्हाच कार्य करते जेव्हा त्यावर अवलंबून असलेले क्लायंट्स स्टेटस मिळवू शकतात आणि लागू करू शकतात. उच्च उपलब्धतेसह (high availability) मध्यवर्ती ठिकाणी रिव्होकेशन माहिती होस्ट करा, आणि नंतर पर्यावरणास अनुकूल CRL डिस्ट्रिब्युशन, OCSP रिस्पॉन्डर्स किंवा दोन्ही व्यवस्थापित करा. फेल्युअर बिहेवियरची देखील चाचणी घ्या. स्टेटस सर्व्हिसेस अनुपलब्ध असताना जुने क्लायंट्स काम करत राहू शकतात, ज्यामुळे इन्सिडेंट रिस्पॉन्डर्सना नियंत्रणाचा चुकीचा आभास होऊ शकतो.
अनाथ (orphaned) प्रमाणपत्रांकडे केवळ एक साफसफाईचे काम म्हणून न बघता, एक तपासणी म्हणून पहा. प्रमाणपत्राला वापरातून बाद (decommissioned) घोषित करण्यापूर्वी, कोणतीही सेवा, डिव्हाइस, बॅकअप प्रक्रिया, डिरेक्टरी वर्कफ्लो किंवा व्हेंडर इंटिग्रेशन अजूनही त्यावर अवलंबून नाही याची खात्री करा. एखाद्या एंडपॉइंटवरून रिव्होक केलेले प्रमाणपत्र काढून टाकल्याने ही समस्या सुटत नाही, जर इतर सिस्टीम अजूनही त्यावर विश्वास ठेवत असेल किंवा त्याच ओळखीचे पर्यायी प्रमाणपत्र सक्रिय असेल.
UK डिजिटल ओळख प्रमाणन मॉडेल प्रमाणपत्र व्यवस्थापनाला पुरावे आणि पुनरावलोकन कालावधीशी देखील जोडते. UK डिजिटल ओळख आणि गुणधर्म ट्रस्ट फ्रेमवर्कमधील सेवांना मंजूर अनुरूपता मूल्यांकन संस्थेद्वारे प्रमाणित करणे आवश्यक आहे. प्रमाणपत्रे सामान्यत: तीन वर्षांसाठी वैध असतात, ज्यामध्ये दर १२ महिन्यांनी देखरेख अपेक्षित असते, सहसा प्रमाणपत्राच्या वर्धापन दिनाच्या दोन्ही बाजूंच्या ३० दिवसांच्या आत. UK प्रमाणन योजना आवश्यकतांनुसार असे नमूद केले आहे की प्रमाणपत्र संपण्यापूर्वी सेवांचे पुन:प्रमाणन करणे आवश्यक आहे. प्रमाणन हे केवळ मूल्यमापन केलेल्या सेवेला लागू होते, संपूर्ण संस्थेला आपोआप लागू होत नाही.
वास्तविक ठिकाणांमध्ये सर्टिफिकेट-आधारित WiFi प्रवेश उपयोजित करणे
प्रमाणपत्र-आधारित WiFi वेन्यूमध्ये उत्तम प्रकारे काम करते जेव्हा ओळख, ट्रस्ट चेन आणि सप्लिकंट कॉन्फिगरेशन एकत्र डिझाइन केलेले असते. EAP-TLS शेअर्ड-पासवर्डची समस्या दूर करते, परंतु ते एका सीक्रेटच्या जागी अशा लाइफसायकलचा वापर करते जी क्लायंट प्रमाणपत्रे प्रोव्हिजन करते, अचूक रूट CA इंस्टॉल करते, वायरलेस प्रोफाइल कॉन्फिगर करते आणि डिरेक्टरी ओळख किंवा डिव्हाइस संबंध बदलल्यावर प्रवेश रिव्होक करते.
कॉर्पोरेट कॅम्पसवर, सर्वात स्वच्छ नमुना म्हणजे सहसा कर्मचारी SSID जो डिरेक्टरी-समर्थित डिव्हाइस प्रमाणपत्रांसह EAP-TLS वापरतो आणि एक स्वतंत्र पाहुण्यांचा अनुभव देतो. Passpoint व्यवस्थापित डिव्हाइसेसना पुन्हा पुन्हा क्रेडेंशियल्स न टाकता योग्य नेटवर्क शोधण्याची आणि त्यात सामील होण्याची परवानगी देऊ शकते. आवश्यक प्रमाणपत्र फ्लो पूर्ण करू न शकणाऱ्या जुन्या उपकरणांसाठी, मुख्य कर्मचारी नेटवर्क मजबूत ओळख नियंत्रणे ठेवत असताना iPSK सेगमेंट डिव्हाइस-विशिष्ट की प्रदान करू शकतो.
रुग्णालयातील परिस्थिती अधिक गुंतागुंतीची असते. व्यवस्थापित क्लिनिकल वर्कस्टेशन्स EAP-TLS ला सपोर्ट करू शकतात, तर विशेषज्ञ उपकरणे, स्कॅनर्स, पंप आणि व्हेंडरद्वारे देखरेख केल्या जाणाऱ्या उपकरणांची सप्लीकंट क्षमता मर्यादित असू शकते. अशा उपकरणांना अत्यंत मर्यादित नेटवर्क सेगमेंट्समध्ये ठेवा, त्यांच्या विश्वासाचे मॉडेल दस्तऐवजीकरण करा आणि प्रत्येक क्लायंटसाठी स्टाफ SSID कमकुवत करण्याऐवजी एक नुकसानभरपाई देणारे नियंत्रण (compensating control) निश्चित करा.
रिटेल चेनमध्ये, केंद्रीय पॉलिसी स्थानिक स्विचिंग आणि वायरलेस बदलांसह सहअस्तित्वात असणे आवश्यक आहे. Meraki, Aruba, Ruckus आणि इतर व्हेंडर्स वेगवेगळे सर्टिफिकेट, RADIUS, Passpoint आणि ऑनबोर्डिंग कंट्रोल्स उघड करतात. सर्टिफिकेट पॉलिसी व्हेंडर-न्यूट्रल ठेवा, नंतर प्रत्येक हार्डवेअर फॅमिलीवर अचूक प्रोफाइलची चाचणी घ्या. त्या मल्टी-व्हेंडर डिझाइनचा भाग म्हणून Aruba-सहत्व असलेले WiFi हार्डवेअर पर्याय तपासले जाऊ शकतात.
| विक्रेता (Vendor) | EAP पद्धत | RADIUS एकत्रीकरण | Passpoint सपोर्ट | ऑनबोर्डिंगची क्लिष्टता |
|---|---|---|---|---|
| Cisco Meraki | EAP-TLS, प्लॅटफॉर्म कॉन्फिगरेशनच्या अधीन | बाह्य RADIUS पर्यायांसह क्लाउड-व्यवस्थापित वायरलेस | सपोर्टेड वायरलेस वैशिष्ट्यांद्वारे उपलब्ध | मध्यम |
| Aruba | EAP-TLS आणि इतर एंटरप्राइझ EAP पद्धती | कंट्रोलर किंवा क्लाउड-व्यवस्थापित RADIUS एकत्रीकरण | सपोर्टेड WLAN वैशिष्ट्यांद्वारे उपलब्ध | मध्यम |
| Ruckus | EAP-TLS आणि विक्रेता-सपोर्टेड एंटरप्राइझ पद्धती | WLAN व्यवस्थापनाद्वारे RADIUS एकत्रीकरण | सपोर्टेड उपयोजनांद्वारे (deployments) उपलब्ध | मध्यम |
| मिश्रित इस्टेट (Mixed estate) | जिथे क्लायंट सपोर्ट करतात तिथे EAP-TLS वर प्रमाणीकरण करा | पॉलिसी केंद्रीकृत करा, प्रत्येक विक्रेत्याच्या वैशिष्ट्यांची चाचणी घ्या | प्रत्येक प्लॅटफॉर्मनुसार रोमिंग आणि प्रोफाइल वर्तन सत्यापित करा | उच्च |
केवळ जोडणीचीच नाही, तर अपयशांची देखील चाचणी घ्या
पहिले यशस्वी कनेक्शन फार काही सिद्ध करत नाही. चुकीचा SAN, गहाळ इंटरमीडिएट, डिव्हाइस ट्रस्ट स्टोअरमधील एक्स्पायर झालेला रूट, रिव्होक केलेले क्लायंट सर्टिफिकेट, RADIUS टाईमआउट आणि ऑपरेटिंग सिस्टम अपडेटनंतर परत येणारे डिव्हाइस यासह सर्टिफिकेटची चाचणी घ्या. युझरला सतत चालणाऱ्या ऑथेंटिकेशन लूपऐवजी एक उपयुक्त रिकव्हरी पर्याय दिसत असल्याची खात्री करा.
EAP-TLS ला सपोर्ट न करू शकणाऱ्या उपकरणांसाठी एक फॉलबॅक पर्याय ठेवा, परंतु भूमिकेनुसार त्याचे विलगीकरण करा आणि बदली योजना लागू करा. ऑनबोर्डिंगची घाई असल्यामुळे अपवादात्मक नेटवर्क हेच डीफॉल्ट नेटवर्क बनू देणे ही उत्पादनातील एक सामान्य चूक आहे.
स्वयंचलित देखरेख आणि बहु-प्रदाता गव्हर्नन्सचे व्यवस्थापन करणे
एक सेंट्रल डॅशबोर्डने प्रत्येक प्रमाणपत्रासाठी चार प्रश्नांची उत्तरे दिली पाहिजेत: ते काय आहे, ते कुठे वापरले जाते, त्याचा मालक कोण आहे आणि पुढे काय होईल. यामध्ये पब्लिक CAs, प्रायव्हेट PKI, AWS ACM, Google Certificate Manager आणि Azure Key Vault यासारख्या क्लाउड-नेटिव्ह सर्व्हिसेस, तसेच डिरेक्टरी प्लॅटफॉर्म्स, नेटवर्क कंट्रोलर्स, लोड बॅलेन्सर्स आणि ॲप्लिकेशन स्टोअर्समधील डेटा समाविष्ट असावा.
मॉनिटरिंगसाठी केवळ एक्सपायरी डेट पुरेशी नाही. चेन कम्प्लिटनेस, की आणि सर्टिफिकेट मॅचिंग, SAN कव्हरेज, की युसेज, रिव्होकेशन रीचेबिलिटी, डिप्लोयमेंट कन्सिस्टन्सी आणि एंडपॉइंटवर दिसणारे सर्टिफिकेट इन्व्हेंटरीमध्ये रेकॉर्ड केलेल्या सर्टिफिकेटशी जुळते की नाही ते तपासा. मालकांना ते आधीपासून वापरत असलेल्या सिस्टमद्वारे अलर्ट करा, नंतर मालकाने प्रतिसाद न दिल्यास किंवा उर्वरित वेळ उच्च-जोखमीची मर्यादा ओलांडल्यास प्रकरणाची तीव्रता वाढवा.
UK प्रमाणन वर्कलोडमध्ये ऑटोमेशनचे ऑपरेशनल महत्त्व खूप जास्त आहे. Cyber Essentials मूल्यमापन डेटानुसार, योजना सुरू झाल्यापासून १३२,०९४ प्रमाणपत्रे देण्यात आली आहेत, मागील १२ महिन्यांत UK मधील २७,०२७ युनिक प्रमाणित संस्था आणि त्या कालावधीत एकूण ३५,४३४ प्रमाणपत्रे नोंदवली गेली आहेत. UK Cyber Essentials योजना प्रक्रिया मूल्यमापनानुसार, २०२२ मध्ये या योजनेने २४,३०० प्रमाणपत्रांची नोंद केली, ज्यामध्ये १६,५५४ पुन:प्रमाणपत्रे (recertifications) आणि ७,७४६ नवीन प्रमाणपत्रांचा समावेश आहे. हा वर्कलोड नूतनीकरणावर जास्त आधारित आहे, त्यामुळे कॅलेंडर, पुरावे संकलन, मूल्यांकनकर्त्याची कामे आणि स्मरणपत्रे ही एका वेळच्या जारी करण्याऐवजी पुन:प्रमाणपत्राच्या दृष्टीने डिझाइन केली पाहिजेत.
नवीन सायलो तयार न करता प्रदात्यांचे नियमन करा
एकाच CA वर एकत्र आल्याने पॉलिसी, कॉन्ट्रॅक्ट्स, टेम्पलेट्स आणि सपोर्ट सोपे होऊ शकतात. यामुळे कॉन्सन्ट्रेशन रिस्क देखील वाढू शकते आणि मायग्रेशन महाग होऊ शकते. मल्टी-प्रोव्हाइडर मॉडेल लवचिकता सुधारते आणि वेगवेगळ्या वापर प्रकरणांसाठी योग्य असू शकते, परंतु केवळ तेव्हाच जेव्हा संस्था इन्व्हेंटरी फील्ड्स, ओनरशिप रूल्स, अप्रूव्हल गेट्स, की-जनरेशन पॉलिसी आणि रिपोर्टिंगचे मानकीकरण करते.
एक व्यावहारिक परिपक्वता मार्ग असा दिसतो:
- प्रतिक्रियाशील: एखादी घटना घडल्यानंतर टीम्सना मुदत संपलेली प्रमाणपत्रे सापडतात.
- नोंदणीकृत: एक सामायिक इन्व्हेंटरी अस्तित्वात असते, परंतु शोध आणि अद्यतने मॅन्युअल राहतात.
- मॉनिटर केलेले: एंडपॉइंट स्कॅन आणि प्रदाता एकत्रीकरण बदल शोधतात आणि मालक-आधारित अलर्ट पाठवतात.
- ऑर्केस्ट्रेटेड: मंजूर ऑटोमेशन की जनरेट करते, प्रमाणपत्रांची विनंती करते, बदली तैनात करते, सेवांचे प्रमाणीकरण करते आणि नोंदी अद्यतनित करते.
- शासित: पॉलिसी-अॅझ-कोड, ऑडिट पुरावे, प्रदाता रिडंडन्सी, अपवाद हाताळणी आणि लाइफसायकल विश्लेषण संपूर्ण इस्टेटमध्ये कार्यरत असतात.
पहिल्याच दिवशी प्रत्येक नूतनीकरण स्वयंचलित करू नका. शोध आणि मालकीपासून सुरुवात करा, कमी जोखमीची प्रमाणपत्रे स्वयंचलित करा आणि प्रमाणीकरण पायाभूत सुविधा आणि सामायिक इंटरमीडिएट्ससाठी मंजुरीचे गेट्स ठेवा. वायरलेस एंडपॉइंट्स व्यवस्थापित करणाऱ्या टीम्ससाठी, WiFi SSL certificate checker लक्ष्यित प्रमाणीकरणाला समर्थन देऊ शकतो, परंतु त्याने अधिकृत इन्व्हेंटरीची जागा घेण्याऐवजी त्याला पूरक ठरले पाहिजे.
Purple मिश्रित नेटवर्क वातावरणात ओळख-आधारित WiFi प्रमाणीकरण, प्रमाणपत्र-दर्जाचा कर्मचारी ऍक्सेस, डिरेक्टरी इंटिग्रेशन्स, Passpoint आणि iPSK सपोर्ट प्रदान करते, ज्यामुळे टीम्सना प्रमाणपत्र तरतूद आणि रद्द करण्याची प्रक्रिया प्रत्यक्ष स्थळाच्या ऑपरेशन्सशी जोडण्यास मदत होते. आपल्या WiFi प्रमाणपत्र जीवनचक्राशी Purple कसे जुळते याचे पुनरावलोकन करा, त्यानंतर आपल्या डिरेक्टरी सेवा, नेटवर्क व्हेंडर्स आणि ऑनबोर्डिंग आवश्यकतांवर आधारित अंमलबजावणीवर चर्चा करण्यासाठी Purple ला भेट द्या.
