रिव्होकेशन लिस्ट सर्टिफिकेट: एक प्रॅक्टिकल WiFi मार्गदर्शक

ट्रेनमध्ये एका कंपनीचा लॅपटॉप चोरीला जातो. हेल्पडेस्क कर्मचाऱ्याचे Active Directory खाते निष्क्रिय करते, डिव्हाइस मालमत्ता नोंदवहीतून गायब होते आणि प्रत्येकजण असे गृहीत धरतो की धोका टळला आहे. दोन दिवसांनंतरही, तो लॅपटॉप कॉर्पोरेट SSID वर दिसतो कारण त्याचे 802.1X सप्लिकंट एक क्लायंट प्रमाणपत्र धरून आहे ज्याची मुदत संपलेली नाही आणि ते कोणीही रद्द केलेले नाही.

हाच तो फरक आहे जो मिटवण्यासाठी revocation list certificate प्रक्रिया तयार केली गेली आहे. प्रमाणपत्र समाप्ती ट्रस्टची बाह्य मर्यादा सेट करते, तर जेव्हा एखादी की तडजोड केली जाते, एखादे डिव्हाइस हरवले जाते किंवा वापरकर्ता सोडून जातो तेव्हा रिव्होकेशन ट्रस्ट लवकर थांबवते. एंटरप्राइझ WiFi प्रशासकासाठी, महत्त्वाचा प्रश्न हा नाही की प्रमाणपत्रे अस्तित्वात आहेत की नाही. तर हा आहे की RADIUS आणि संबंधित नेटवर्क कंट्रोल्सना रिव्होक केलेल्या प्रमाणपत्राबद्दल द्रुतपणे माहिती मिळते की नाही आणि ते सुरक्षितपणे फेल होते की नाही.

कधीही संपू न शकणारा WiFi ॲक्सेस

प्रमाणपत्र-आधारित WiFi डेप्लॉयमेंट अनेकदा बाहेरून सुरक्षित दिसते. क्लायंट EAP-TLS वापरतो, RADIUS सेवा प्रमाणपत्र साखळी सत्यापित करते आणि कर्मचाऱ्यांमध्ये सामायिक केलेले पासवर्ड दिले जात नाहीत. परंतु ते डिझाइन अद्याप एका कार्यरत लाइफसायकलवर अवलंबून असते. प्रमाणपत्र जारी करणे हा केवळ प्रारंभ आहे. ते कोणाच्या मालकीचे आहे, ते कधी कालबाह्य होते आणि डिव्हाइस किंवा प्रायव्हेट की यापुढे विश्वसनीय नसतील तर काय होते, हे देखील तुम्हाला माहित असणे आवश्यक आहे.

चोरी झालेल्या लॅपटॉपच्या उदाहरणात, Active Directory मधून खाते काढून टाकल्याने पुढील डिरेक्टरी ऑथेंटिकेशन कदाचित थांबेल, परंतु यामुळे डिव्हाइसवर आधीपासून इन्स्टॉल केलेले सर्टिफिकेट अमान्य होईलच असे नाही. जर WiFi सेवा केवळ त्याच्या साखळी आणि वैधतेच्या तारखांवर आधारित सर्टिफिकेटवर विश्वास ठेवत असेल, तर लॅपटॉप वरवर वैध वाटणारी क्रेडेंशियल्स सादर करणे सुरू ठेवू शकतो. सर्टिफिकेटची notAfter date दर्शवते की ते त्याच्या नियोजित कालावधीमध्ये आहे. जारी करणारी संस्था अजूनही त्यावर विश्वास ठेवू इच्छिते की नाही हे ते सांगत नाही.

व्यावहारिक नियम: सर्टिफिकेट एक्स्पायरी आणि सर्टिफिकेट रिव्होकेशन या दोन वेगवेगळ्या गोष्टी समजा. एक्स्पायरी हे नियोजित लाइफसायकल मॅनेजमेंट आहे. रिव्होकेशन हा आपत्कालीन ब्रेक आहे.

यूके पब्लिक-सेक्टर PKI मॉडेल हा फरक स्पष्ट करते. सर्टिफिकेट रिव्होकेशन लिस्ट, किंवा CRL, ही एक्स्पायरीपूर्वी रिव्होक केलेल्या सर्टिफिकेटच्या सिरियल नंबरची स्वाक्षरी केलेली लिस्ट असते, जी अवलंबून असलेल्या पक्षांना सांगते की त्या सर्टिफिकेट्सवर आता विश्वास ठेवला जाऊ नये. यूके पब्लिक-की इन्फ्रास्ट्रक्चर मार्गदर्शक तत्त्वे देखील CRL ला सामान्य रिव्होकेशन पद्धतींपैकी एक म्हणून ओळखतात आणि क्लायंटने सादर केलेले सर्टिफिकेट जारी करणाऱ्या CA च्या लिस्टमध्ये दिसते की नाही हे तपासावे अशी अपेक्षा ठेवतात.

हे WiFi वर महत्त्वाचे आहे कारण ऑथेंटिकेशनचे निर्णय नेटवर्कच्या अगदी टोकावर होतात, जे बऱ्याचदा अनेक कंट्रोलर्स, ॲक्सेस पॉइंट्स, RADIUS सर्व्हर्स आणि कॅश केलेल्या व्हॅलिडेशन स्टोअर्समध्ये विभागलेले असतात. मॅन्युअल CRL अपडेटमुळे सुरक्षेमध्ये त्रुटी राहू शकते, तर खराब डिझाइन केलेले फेल-क्लोज्ड धोरण CRL वितरण पॉइंट अनुपलब्ध झाल्यास आउटेज तयार करू शकते.

काम करणारे मानसिक मॉडेल सरळ आहे: CA स्टेटस माहिती जारी करतो आणि त्यावर स्वाक्षरी करतो, संबंधित पक्ष त्याची पडताळणी करतो आणि नेटवर्क रद्द केलेले प्रमाणपत्र नाकारते. हे मार्गदर्शक पुढील भागात ही प्रक्रिया कशी कार्य करते, CRL आणि OCSP कुठे भिन्न आहेत आणि डायरेक्टरी-चालित प्रवेश नियंत्रणे मॅन्युअल रिव्होकेशनची अडचण कशी दूर करू शकतात याचे परीक्षण करते.

रिव्होकेशन लिस्ट सर्टिफिकेट प्रत्यक्षात काय आहे

सोप्या भाषेत सांगायचे तर, Certificate Revocation List ही सर्टिफिकेट ऑथॉरिटीकडून जारी केलेली अधिकृत "या सर्टिफिकेट्सवर यापुढे विश्वास ठेवू नका" अशी नोटीस असते. हे सर्टिफिकेट्स त्यांच्या सिरियल नंबरद्वारे ओळखते, कोणत्याही सोयीस्कर डिव्हाइसच्या नावाने किंवा कर्मचाऱ्याच्या ईमेल पत्त्याने नाही. संबंधित लिस्टमध्ये सादर केलेल्या सर्टिफिकेटचा सिरियल नंबर आढळल्यास क्लायंटने ते नाकारले पाहिजे, जरी सर्टिफिकेटची एक्स्पायरी डेट अजूनही भविष्यातील असली तरीही.

UK ची व्याख्या औपचारिक आहे. हे CRL ला मुदत संपण्यापूर्वी रद्द केलेल्या प्रमाणपत्र अनुक्रमांकांची स्वाक्षरी केलेली यादी म्हणून वर्णन करते, जेणेकरून विसंबून राहणाऱ्या पक्षांनी यापुढे त्या प्रमाणपत्रांवर विश्वास ठेवू नये. स्वाक्षरी महत्त्वाची आहे कारण RADIUS सर्व्हर किंवा इतर मूल्यमापनकर्त्याने हे स्पष्ट करणे आवश्यक आहे की ही यादी अपेक्षित जारीकर्त्याकडून आली आहे आणि ट्रान्झिट दरम्यान त्यात कोणताही बदल केला गेला नाही. प्रशासकाद्वारे व्यवस्थापित केलेली साधी मजकूर ब्लॉकलिस्ट अशी क्रिप्टोग्राफिक हमी देत नाही.

तीन घटक ही प्रक्रिया उपयुक्त बनवतात:

• प्रमाणपत्र प्राधिकरण (CA): CA, किंवा अधिकृत CRL जारीकर्ता, ही यादी तयार करतो आणि जारी करणाऱ्या ट्रस्ट पदानुक्रमाशी संबंधित खाजगी की वापरून त्यावर स्वाक्षरी करतो.
• विसंबून राहणारा पक्ष (Relying party): एखादा RADIUS सर्व्हर, सप्लिकंट, कंट्रोलर, ऑपरेटिंग सिस्टम किंवा प्रशासकीय साधन ही यादी डाउनलोड करते, तिची स्वाक्षरी आणि वैधता माहिती सत्यापित करते, आणि नंतर प्रमाणपत्र अनुक्रमांक शोधते.
• प्रमाणपत्र धारक: ती व्यक्ती, डिव्हाइस किंवा सेवा ज्यांचे प्रमाणपत्र रद्द केले गेले आहे. त्याचा अनुक्रमांक यादीमध्ये राहतो जेणेकरून मूल्यमापनकर्ते त्यास अविश्वासू म्हणून ओळखू शकतील.

CRL सामान्यतः वापरकर्ता किंवा डिव्हाइस प्रमाणपत्रासारखे प्रमाणपत्र नसते. ती एक स्वाक्षरी केलेली PKI कलाकृती आहे ज्यामध्ये जारीकर्ता, वैधता आणि प्रकाशन माहिती असते. लोक कधीकधी प्रमाणपत्र-रद्दीकरण यंत्रणेसाठी "रिव्होकेशन लिस्ट प्रमाणपत्र" चा संक्षिप्त रूप म्हणून वापर करतात, परंतु तपासली जाणारी मुख्य गोष्ट म्हणजे स्वाक्षरी केलेली CRL.

विश्वास ठेवणारा पक्ष (relying party) सहसा CA कडे वापरकर्त्याला का नकार दिला जावा याचे स्पष्टीकरण मागत नाही. तो प्रमाणपत्राच्या रद्दीकरण (revocation) माहितीचे अनुसरण करतो, जारीकर्त्याची वर्तमान CRL मिळवतो, CRL सत्यापित करतो आणि अनुक्रमांक तपासतो. जर जुळणी झाली, तर प्रमाणपत्र रद्द केले जाते. जर जुळणी झाली नाही, तरीही परिणाम CRL च्या ताजेपणावर आणि विश्वास ठेवणाऱ्या पक्षाच्या स्वतःच्या कॅश (cache) वर अवलंबून असतो.

तो शेवटचा मुद्दा अनेक घटनांना कारणीभूत ठरतो. एखादे प्रमाणपत्र जुन्या कॅश केलेल्या सूचीमध्ये नसून नवीन सूचीमध्ये असू शकते. त्यामुळे, नेटवर्कचा निर्णय हा CA ने काय प्रकाशित केले आणि प्रमाणीकरणकर्त्याने (authenticator) ते शेवटचे कधी मिळवले या दोन्ही गोष्टींवर अवलंबून असतो.

पडद्यामागे CRL कसे कार्य करते

CRL लाइफसायकल घटनांच्या एका अंदाजित साखळीचे अनुसरण करते. प्रथम, CA त्याच्या प्रमाणपत्र धोरणानुसार एक बेस लिस्ट तयार करते. ते या लिस्टवर स्वाक्षरी करते, प्रकाशन आणि वैधता फील्ड जोडते आणि वितरण बिंदूद्वारे ती उपलब्ध करून देते. जारी केलेली प्रमाणपत्रे सामान्यत: CRL Distribution Points विस्ताराद्वारे त्या स्थानांचा संदर्भ घेतात, ज्यामुळे व्हॅलिडेटरला स्थितीची माहिती कोठे आहे हे शोधणे शक्य होते.

जेव्हा एखादा प्रशासक डिव्हाइस प्रमाणपत्र रद्द करतो, तेव्हा CA त्याचा अनुक्रमांक आणि कारणाची माहिती नोंदवून घेतो. ते प्रमाणपत्र प्रत्येक विश्वास ठेवणाऱ्या पक्षाच्या कॅशमध्ये त्वरित दिसेलच असे नाही. पुढील प्रकाशित CRL मध्ये ती नोंद असणे आवश्यक आहे, आणि प्रत्येक RADIUS सर्व्हर किंवा कंट्रोलरने योग्य निर्णय घेण्यापूर्वी वर्तमान प्रत मिळवणे आवश्यक आहे.

काही PKI वातावरण डेल्टा CRLs देखील वापरतात. डेल्टा मध्ये बेस CRL नंतरचे बदल असतात, ज्यामुळे संपूर्ण सूची मोठी असताना ट्रान्सफर आणि प्रोसेसिंगचे काम कमी होऊ शकते. ही कार्यक्षमता बेस लिस्ट व्यवस्थापित करणे, स्वाक्षऱ्यांची पडताळणी करणे, ताजेपणाचा मागोवा घेणे किंवा प्रत्येक नेटवर्क घटकाला निवडलेले प्रकाशन मॉडेल समजले आहे याची खात्री करण्याची आवश्यकता दूर करत नाही.

ताजेपणाची मर्यादा (Freshness window)

प्रसारणाचा (propagation) विचार करण्यासाठी यूकेची धोरणे उपयुक्त संदर्भ बिंदू प्रदान करतात. यूके सरकारच्या CVCA प्रॅक्टिस स्टेटमेंटनुसार CRL जास्तीत जास्त दर 90 दिवसांनी जारी करणे आवश्यक आहे, आणि रिव्होक केलेले सर्टिफिकेट रिव्होकेशनच्या 72 तासांच्या आत संबंधित CRL मध्ये दिसणे आवश्यक आहे. या मर्यादा UK national certificate policy मध्ये वर्णन केल्या आहेत.

इतर UK धोरणे वेगवेगळ्या सेवा अपेक्षांचा वापर करतात. HM Land Registry चे म्हणणे आहे की रद्द केलेल्या आणि निलंबित केलेल्या प्रमाणपत्रांसाठी त्यांची निरसन यादी दिवसातून किमान एकदा तरी अपडेट केली पाहिजे, तर University of York चे प्रमाणपत्र सराव विधान निरसन आणि CRL जारी करण्यामध्ये जास्तीत जास्त १० दिवसांचे अंतर देते. ही उदाहरणे, ज्यामध्ये HMPO Country Signing Certificate Authority प्रकाशन बिंदूचा समावेश आहे, हे दर्शवतात की प्रशासकाने प्रत्येक CRL सारखेच कार्य करते असे गृहीत धरण्याऐवजी जारी करणाऱ्या CA चे मूळ धोरण वाचले पाहिजे.

ऑथेंटिकेशनच्या वेळी, RADIUS सर्व्हर त्याच्या स्थानिक पातळीवर उपलब्ध असलेल्या CRL शी प्रमाणपत्राच्या सिरीयल नंबरची तपासणी करतो. तो CRL त्याच्या वैधता कालावधीत आहे की नाही, सिग्नेचर साखळी अपेक्षित जारीकर्त्याशी जोडलेली आहे की नाही आणि रिफ्रेश करण्याची वेळ आल्यावर वितरण बिंदू (distribution point) पर्यंत पोहोचता येते की नाही हे देखील तपासतो. त्यानंतर सर्व्हर त्याच्या अंमलबजावणीनुसार आणि CRL च्या nextUpdate मूल्यानुसार निकाल कॅशे करतो.

हे गुंतागुंतीच्या गणिताशिवाय एक व्यावहारिक जोखीम समीकरण तयार करते: रिव्होकेशन लेटन्सीमध्ये CA प्रकाशन वेळ, डिस्ट्रिब्युशन विलंब, कॅश कालावधी आणि ऑथेंटिकेशन वारंवारता समाविष्ट असते. पॉलिसी जलद गतीने प्रकाशित होऊ शकते, परंतु डिस्कनेक्ट झालेली किंवा जुनी RADIUS कॅश तरीही अंमलबजावणीला विलंब करू शकते.

CRL विरुद्ध OCSP आणि WiFi वर हे का महत्त्वाचे आहे

CRL आणि OCSP एकाच मूलभूत समस्येचे वेगवेगळ्या प्रकारे निराकरण करतात. CRL व्हॅलिडेटरला रिव्होक केलेल्या सिरियल नंबर्सची स्वाक्षरी केलेली बॅच प्रदान करते. OCSP तपासणीच्या वेळी एका विशिष्ट सर्टिफिकेटच्या स्थितीबद्दल अधिकृत रिस्पॉन्डरकडे चौकशी करते.

एका enterprise WiFi प्रशासकासाठी, हा पर्याय केवळ PKI सुलभतेपेक्षा अधिक गोष्टींवर परिणाम करतो. तो गर्दीच्या WAN वर कंट्रोलर कसा वर्तन करतो, CA इन्फ्रास्ट्रक्चरने काय हाताळले पाहिजे आणि रिस्पॉन्डर किंवा डिस्ट्रिब्युशन पॉईंट पोहोचण्यायोग्य नसताना ऑथेंटिकेशनचा प्रयत्न पूर्ण होऊ शकतो की नाही हे बदलतो.

निकष	CRL	OCSP
ताजेपणा (Freshness)	नियतकालिक. नवीन रिव्होक केलेले प्रमाणपत्र पब्लिकेशन आणि क्लायंट रिफ्रेशची वाट पाहते.	जेव्हा रिस्पॉन्डर पोहोचण्यायोग्य असतो, तेव्हा प्रति-प्रमाणपत्र क्वेरी अधिक सद्य स्थिती प्रदान करू शकते.
इन्फ्रास्ट्रक्चर लोड	क्लायंट एक सूची डाउनलोड करतात आणि त्यावर प्रक्रिया करतात, जी व्यवस्थापित इस्टेट विरुद्ध वारंवार तपासणीसाठी कार्यक्षम असू शकते परंतु वितरण ट्रॅफिक निर्माण करू शकते.	रिस्पॉन्डर वैयक्तिक स्टेटस विनंत्या हाताळतो, ज्यामुळे पूर्ण-सूची डाउनलोड टाळले जाते परंतु विनंतीचे प्रमाण वाढते.
गोपनीयता	विश्वास ठेवणारा पक्ष (relying party) एक सूची प्राप्त करतो आणि त्याला CA कडे प्रत्येक प्रमाणपत्र तपासणी उघड करण्याची आवश्यकता नसते.	थेट क्वेरी रिस्पॉन्डरला कोणत्या प्रमाणपत्राची तपासणी केली जात आहे हे उघड करू शकते.
अयशस्वी मोड (Failure mode)	अनुपलब्ध किंवा कालबाह्य झालेली CRL विश्वसनीय स्टेटस व्हॅलिडेशन रोखू शकते. स्थानिक कॅशे त्यांच्या ताजेपणाच्या मर्यादेपर्यंत काम करणे सुरू ठेवू शकतात.	अनुपलब्ध रिस्पॉन्डर वैयक्तिक स्टेटस क्वेरीवर परिणाम करतो आणि कॉन्फिगर केलेले सॉफ्ट-फेल किंवा हार्ड-फेल वर्तन WiFi परिणाम ठरवते.

मोठ्या कॅम्पसला सेवा देणारा कंट्रोलर स्थानिक पातळीवर कॅश केलेल्या CRL ला प्राधान्य देऊ शकतो कारण तो प्रत्येक ऑथेंटिकेशनसाठी स्वतंत्र विनंती न पाठवता अनेक सर्टिफिकेट सिरीयल नंबर्स तपासू शकतो. जेव्हा डिस्ट्रिब्युशन पॉईंट्स पोहोचण्यायोग्य असतात, अपडेट्स मॉनिटर केले जातात आणि RADIUS पॉलिसी मुदत संपलेल्या लिस्टला काळजीपूर्वक हाताळते तेव्हा हे मॉडेल चांगले काम करते.

OCSP अशा रचनेसाठी योग्य ठरू शकते जेथे ऑपरेटरला प्रति-प्रमाणपत्र प्रतिसाद आवश्यक असतो आणि तो रिस्पॉन्डरवरील अवलंबित्व स्वीकारतो. हे संपूर्ण सूची ट्रान्सफर करण्याची आवश्यकता कमी करू शकते, परंतु हे प्रमाणीकरणादरम्यान थेट नेटवर्क अवलंबित्व निर्माण करते. स्टेपलिंग (stapling) काही प्रोटोकॉलमध्ये रिस्पॉन्डर परस्परसंवाद इतरत्र हलवू शकते, तरीही WiFi रचनेमध्ये अनुपलब्ध किंवा शिळ्या स्टेटस डेटासाठी स्पष्ट उत्तराची आवश्यकता असते.

येथे UK चे मार्गदर्शन उपयुक्त ठरते कारण ते CRL हा एकमेव मार्ग म्हणून सादर करत नाही. UK चे धोरण CRL ला सामान्य रिव्होकेशन यंत्रणांपैकी एक म्हणून वर्णन करते, तर न्याय-क्षेत्राचे मार्गदर्शन त्यांना प्राथमिक ऑफलाइन यंत्रणा मानते आणि PKI प्रकटीकरण पत्रकामध्ये रिव्होकेशन सेवांसाठीच्या उपलब्धतेच्या आवश्यकतांवर प्रकाश टाकते.

व्यवस्थापित 802.1X डिव्हाइसेससाठी, नियतकालिक बॅच प्रमाणीकरणासाठी सहसा CRL व्यावहारिक ठरते, विशेषत: जेव्हा अंतर्गत वितरण विश्वसनीय असते. जेथे तात्काळ स्थितीची अचूकता आवश्यक असते तिथे OCSP ला प्राधान्य दिले जाते आणि त्यानुसार रिस्पॉन्सर्सची उपलब्धता सुनिश्चित केली जाते. उच्च-सुरक्षा नेटवर्क्स दोन्ही चालवू शकतात, परंतु केवळ तेव्हाच जेव्हा फॉलबॅक वर्तन गृहीत धरण्याऐवजी दस्तऐवजीकरण आणि चाचणी केलेले असेल.

Purple WiFi नेटवर्कवर प्रत्यक्षात रिव्होकेशन

मॅन्युअली व्यवस्थापित केलेल्या प्रमाणपत्र सूचीऐवजी जेव्हा WiFi प्रवेश थेट ओळख डिरेक्टरीशी जोडला जातो, तेव्हा कार्यात्मक फरक दिसून येतो. डिरेक्टरी एकत्रीकरण वापरकर्त्याच्या वर्तमान खाते स्थितीला प्रमाणीकरण निर्णयाचा भाग बनवू शकते, ज्यामुळे खाते निष्क्रिय करणे हा एक प्रवेश-नियंत्रण इव्हेंट बनतो, केवळ एक तिकीट नाही जे नंतर कोणालातरी CA रद्दीकरणामध्ये रूपांतरित करावे लागेल.

एक सामान्य फ्लो याप्रमाणे दिसतो:

1. डिरेक्टरी ओळख स्थितीची नोंद ठेवते. ऍक्टिव्ह डिरेक्टरी, Entra ID, किंवा Google Workspace मध्ये एखादे खाते तयार केले जाते, बदलले जाते, निलंबित केले जाते किंवा निष्क्रिय केले जाते.
2. WiFi ओळख सेवेला बदल प्राप्त होतो. ही सेवा डिरेक्टरी स्थितीला संस्थेच्या प्रमाणीकरण धोरणाशी मॅप करते.
3. पुढील प्रमाणीकरणाचे मूल्यमापन त्या स्थितीनुसार केले जाते. पूर्वी जारी केलेल्या प्रमाणपत्राची वैधता शिल्लक असली तरीही, निष्क्रिय केलेली ओळख यापुढे प्रवेश नियमाची पूर्तता करत नाही.
4. नेटवर्क प्रवेश नाकारते. RADIUS चा निर्णय निष्क्रिय ओळखीच्या अंतर्गत नवीन 802.1X सत्राला अधिकृत होण्यापासून रोखतो.

हे मॉडेल केवळ CRL-आधारित ऑपरेशन्समधील त्रुटी दूर करते. CRL हे CA प्रकाशन, वितरण बिंदू, कॅश रिफ्रेश आणि विश्वास ठेवणाऱ्या पक्षाच्या तपासणीवर अवलंबून असते. डिरेक्टरी-चालित अंमलबजावणी खाते स्थितीसाठी ओळख प्रणालीला कार्यक्षम मुख्य स्रोत (source of truth) बनवते, ज्यामुळे प्रशासकाला बाहेर पडणाऱ्या वापरकर्त्याशी संबंधित प्रत्येक प्रमाणपत्र अनुक्रमांक शोधण्याची आवश्यकता कमी होते.

कार्यरत फरक: CRL सर्टिफिकेट रिव्होक केले आहे की नाही याचे उत्तर देते. डिरेक्टरी - ड्रिव्हन ऑथेंटिकेशन हे उत्तर देऊ शकते की ती ओळख सध्या नेटवर्क वापरण्यास अधिकृत आहे की नाही.

Purple हे Entra ID आणि Google Workspace सारख्या डिरेक्टरी इंटिग्रेशन्ससह व्यवस्थापित RADIUS आणि प्रमाणपत्र-आधारित एंटरप्राइझ WiFi नियंत्रणे प्रदान करते. जेव्हा एखाद्या संस्थेला प्रत्येक ऑन-प्रिमाइसेस RADIUS आणि रिव्होकेशन घटक स्वतः न सांभाळता ओळख स्थितीला 802.1X ऑथेंटिकेशनशी जोडायचे असते, तेव्हा त्यांची RADIUS as a Service ऑफरिंग उपयुक्त ठरते.

यामुळे PKI लाइफसायकलचे काम पूर्णपणे संपत नाही. आर्किटेक्चरला आवश्यक असलेल्या ठिकाणी प्रमाणपत्रांचे वितरण, नूतनीकरण, ट्रस्ट-चेन व्यवस्थापन आणि रिव्होकेशन तपासणी करणे अद्याप गरजेचे असते. मात्र, यामुळे ऑफबोर्डिंग प्रक्रियेतील मॅन्युअल अडथळा दूर होतो. सर्व्हिस डेस्क प्रस्थापित डिरेक्टरी वर्कफ्लोद्वारे ओळख (identity) निष्क्रिय करू शकते, तर नेटवर्क ऑथेंटिकेशन लेअर पुढील ॲक्सेस निर्णयाच्या वेळी ती स्थिती लागू करते.

Enterprise WiFi साठी सर्वोत्तम कार्यरत पद्धती

एक विश्वासार्ह रिव्होकेशन डिझाईन सामान्य ऑपरेशनल शिस्तीसह क्रिप्टोग्राफिक नियंत्रणे एकत्र करते. सर्टिफिकेटच्या लाइफटाइमपासून सुरुवात करा. मॅनेज्ड WiFi डिव्हाइसेससाठी, पुरवलेल्या डिप्लोयमेंट मार्गदर्शनामध्ये 12 ते 24 महिने सर्टिफिकेट लाइफटाइम हा एक सामान्य ऑपरेशनल संदर्भ आहे, परंतु योग्य निवड डिव्हाइस मालकी, रिन्यूअल क्षमता आणि एक्सपोज झालेल्या प्रायव्हेट कीमुळे होऊ शकणारे नुकसान यावर अवलंबून असते. गेस्ट स्पॉन्सर सर्टिफिकेट्सचा लाइफटाइम सामान्यत: कमी असावा कारण त्यांच्या ॲक्सेसचा संदर्भ वारंवार बदलतो.

डिव्हाइस लाइफसायकलमध्येच नूतनीकरण समाविष्ट करा

प्रमाणपत्रे कालबाह्य होण्यापूर्वी त्यांचे नूतनीकरण करण्यासाठी SCEP, MDM प्लॅटफॉर्म किंवा इतर स्वयंचलित नोंदणी मार्ग वापरा. मॅन्युअल नूतनीकरण प्रायोगिक तत्त्वावर कार्य करते परंतु विस्तृत मालमत्तेमध्ये ते कमकुवत ठरते. स्लीपिंग लॅपटॉप, रिमोट डिव्हाइसेस, रीबिल्ट डिव्हाइसेस आणि बऱ्याच काळापासून कॉर्पोरेट नेटवर्कशी कनेक्ट नसलेल्या डिव्हाइसेसवर नूतनीकरणाची चाचणी घ्या.

RADIUS आणि कंट्रोलर्सद्वारे वापरल्या जाणाऱ्या नेटवर्क पाथ्सवरून CRL डिस्ट्रिब्युशन पॉईंट्स मॉनिटर करा. केवळ वेब विनंती डेटा परत करते की नाही हे न पाहता पोहोचण्याची क्षमता, स्वाक्षरीची वैधता, इश्यूअरची ओळख आणि nextUpdate तपासा. पोहोचण्यायोग्य परंतु मुदत संपलेले CRL हे अजूनही अयशस्वी रिव्होकेशन कंट्रोल आहे.

RADIUS बाजू स्वच्छ ठेवा

RADIUS सर्व्हर सर्टिफिकेट्ससाठी सद्य वैधता, विश्वासू इश्यूइंग चेन आणि अशा नूतनीकरण प्रक्रियेची आवश्यकता असते जी शेवटच्या क्षणाच्या मेंटेनन्स विंडोवर अवलंबून नसेल. सर्व्हर्स, कंट्रोलर्स आणि व्यवस्थापित क्लायंटवरील ट्रस्ट स्टोअर्सचे पुनरावलोकन करा जेणेकरून जुने CA सर्टिफिकेट वेगवेगळ्या साईट्सवर विसंगत निर्णय घेण्यास कारणीभूत ठरणार नाही.

रिव्होकेशन रनबुक अशा भाषेत डॉक्युमेंट करा जी ऑन-कॉल इंजिनिअर सहज समजून घेऊ शकेल:

• क्रेडेन्शियल ओळखा: युझर, डिव्हाइस, प्रमाणपत्र अनुक्रमांक आणि जारी करणाऱ्या CA ची नोंद करा.
• ओळख निष्क्रिय करा: मंजूर केलेली डिरेक्टरी किंवा HR ऑफबोर्डिंग क्रिया लागू करा.
• आवश्यकतेनुसार रद्द करा: CA स्थिती अपडेट करा आणि प्रकाशनाची पुष्टी करा.
• विसंबून राहणाऱ्या पक्षांना रिफ्रेश करा: जिथे समर्थित असेल तिथे CRL मिळवणे सक्तीचे करा किंवा त्याचे वेळापत्रक निश्चित करा.
• नकार चाचणी घ्या: संबंधित क्रेडेन्शियलसह प्रमाणीकरणाचा प्रयत्न करा आणि निकाल सुरक्षित ठेवा.

HR ट्रिगर्सना डायरेक्टरी बदलांशी सुसंगत करा. जर सर्व्हिस डेस्कला स्वतंत्र PKI तिकीट मिळण्याची वाट पाहावी लागली, तर नेटवर्क अशा ओळखीवर विश्वास ठेवणे सुरू ठेवू शकते जी संस्थेने आधीच निष्क्रिय म्हणून चिन्हांकित केली आहे. स्वयंचलित प्रोव्हिजनिंग आणि नूतनीकरण ही तफावत कमी करते, तर चोरीला गेलेल्या उपकरणांसाठी आणि संशयित की तडजोडीसाठी दस्तऐवजीकरण केलेला मॅन्युअल मार्ग महत्त्वाचा राहतो.

पासवर्डशिवाय स्टाफ ॲक्सेससाठी, हे नियंत्रणे सर्टिफिकेट एनरोलमेंट, RADIUS व्हॅलिडेशन आणि ऑफबोर्डिंग ओनरशिपसह WPA-Enterprise deployment शी कसे जुळतात याचे पुनरावलोकन करा.

सामान्य रिव्होकेशन समस्यांचे निवारण करणे

बहुतेक CRL च्या घटना तीन श्रेणींमध्ये मोडतात: व्हॅलिडेटरकडे जुनी माहिती असणे, त्याला योग्य पब्लिकेशन पॉईंट शोधता न येणे, किंवा रिव्होकेशन स्टोअर ऑपरेट करणे कठीण जाणे. थेट नवीन सर्टिफिकेट जारी करण्याऐवजी निर्णय मार्गाचे निदान करा.

एक जुनी स्थानिक कॅश (local cache)

RADIUS सर्व्हर किंवा कंट्रोलरकडे अद्याप रिव्होकेशनच्या आधीची CRL असू शकते. CRL चे thisUpdate आणि nextUpdate फील्ड तपासा, जारी करणाऱ्या CA विरुद्ध त्याच्या स्वाक्षरीची पडताळणी करा आणि ऑथेंटिकेटरवरील कॅश केलेल्या कॉपीची तपासणी करा. क्लायंटने सादर केलेल्या सिरीयल नंबरची तुलना नवीन प्रकाशित CRL मधील नोंदींशी करा.

प्लॅटफॉर्म सपोर्ट करत असल्यास CRL रिफ्रेश सक्तीने करणे हा तात्काळ उपाय आहे, त्यानंतर बाधित सर्टिफिकेटसह ऑथेंटिकेशनची पुन्हा चाचणी घ्या. कॅशे सतत जुना डेटा परत पाठवत असल्यास, प्रॉक्सी वर्तन, डिस्ट्रिब्युशन - पॉईंट कॅशिंग आणि व्हॅलिडेटरच्या रिफ्रेश पॉलिसीची तपासणी करा.

एक गहाळ वितरण बिंदू (distribution point)

जारी केलेल्या सर्टिफिकेटचे CDP आणि AIA एक्सटेंशन्स वाचा. CDP रिलाइंग पार्टीला रिव्होकेशन माहिती कुठे शोधावी हे सांगते, तर AIA त्यांना चेन व्हॅलिडेशनसाठी आवश्यक असलेली इश्यूअर माहिती ओळखण्यास मदत करू शकते. URL अचूक आहे, RADIUS नेटवर्कवरून पोहोचण्यायोग्य आहे आणि अपेक्षित इश्यूअरद्वारे स्वाक्षरित CRL दाखवत आहे याची खात्री करा.

CA टेम्पलेटमध्ये चुकीचे लोकेशन असल्यास, टेम्पलेट दुरुस्त करा आणि नवीन रिप्लेसमेंट सर्टिफिकेट्स जारी करा. केवळ एंडपॉईंट अपडेट केल्याने आधीपासूनच निरुपयोगी डिस्ट्रिब्युशन पॉईंट असलेले सर्टिफिकेट्स दुरुस्त होणार नाहीत.

एक न सांभाळता येणारा रिव्होकेशन स्टोअर (revocation store)

जुने नोंदी व्यवस्थापन गुंतागुंतीचे करू शकतात आणि प्रक्रियेचे काम वाढवू शकतात. केवळ CA च्या रिटेंशन पॉलिसी अंतर्गत आणि संबंधित सर्टिफिकेटचे आयुष्यमान आणि ऑडिट आवश्यकतांचा विचार केल्यानंतरच नोंदी काढून टाका. केवळ इन्सिडंट तिकीट बंद झाले आहे म्हणून सिरीयल नंबर कधीही काढू नका.

UK पॉलिसी उदाहरणे दर्शवतात की "ताजे" हे स्थानिक पातळीवर का परिभाषित केले पाहिजे. काही UK ऑथॉरिटीजसाठी दररोज अपडेट्स आवश्यक असतात, तर नॅशनल CVCA पॉलिसीनुसार रिव्होक केलेल्या सर्टिफिकेटसाठी ७२ तासांच्या आत प्रकाशन आवश्यक आहे आणि कमाल ९० दिवसांचा जारी करण्याचा कालावधी निश्चित केला आहे. याकडे पॉलिसी बेसलाइन्स म्हणून पहा, जुना एंटरप्राइझ डेटा स्वीकारण्याची परवानगी म्हणून नाही.

प्रमाणपत्र विश्लेषण साधन जारीकर्ता, वैधता, CDP आणि चेन तपशील तपासण्यास मदत करू शकते. प्रमाणपत्राच्या आरोग्याची तपासणी करण्यासाठी Purple चा SSL प्रमाणपत्र तपासक हा एक पर्याय आहे, तर डायरेक्टरी-चालित अंमलबजावणी वापरकर्त्याला ऑफबोर्ड करण्यासाठी केवळ विलंबित CRL रीफ्रेशवर अवलंबून राहणे टाळू शकते.

या आठवड्यात या सर्व गोष्टी एकत्र आणणे

रद्दीकरणाला केवळ पॉलिसी परिच्छेद न ठेवता सोपवलेल्या कामात रूपांतरित करा. या क्रियांना पुढील चेंज विंडोमध्ये ठेवा आणि प्रत्येकासाठी एका नियुक्त व्यक्तीची जबाबदारी निश्चित करा.

• PKI टीम, प्रमाणपत्र मार्गांचे ऑडिट करा: प्रत्येक WiFi क्लायंट प्रमाणपत्र टेम्पलेट, इश्यूइंग CA, CDP आणि RADIUS ट्रस्ट संबंधांची सूची तयार करा. प्रत्येक वितरण बिंदू (distribution point) प्रत्येक ऑथेंटिकेशन साईटवरून पोहोचण्यायोग्य असल्याची खात्री करा.
• PKI आणि एंडपॉइंट टीम, एक सुरक्षित लाइफटाइम सेट करा: जिथे डिव्हाइस नूतनीकरण प्रक्रिया सपोर्ट करू शकते तिथे WiFi क्लायंट प्रमाणपत्रांचा कालावधी 12 महिने किंवा त्यापेक्षा कमी वर आणा. कमी लाइफटाइममुळे आपत्कालीन रिव्होकेशनवरील अवलंबित्व कमी होते, परंतु केवळ तेव्हाच जेव्हा नूतनीकरण स्वयंचलित आणि तपासलेले असते.
• एंडपॉइंट टीम, नूतनीकरण स्वयंचलित करा: वापरकर्त्याच्या हस्तक्षेपाशिवाय प्रमाणपत्रे नोंदणीकृत आणि नूतनीकरण करण्यासाठी MDM किंवा SCEP वापरा. डिव्हाइस रीबिल्ड, दीर्घकाळ ऑफलाइन राहिल्यानंतर आणि वापरकर्ता बदलल्यानंतर या प्रक्रियेची चाचणी घ्या.
• सर्व्हिस डेस्क आणि आयडेंटिटी टीम, ऑफबोर्डिंगला ऍक्सेस नाकारण्याशी जोडा: HR किंवा सर्व्हिस-डेस्कची निष्क्रिय स्थिती थेट WiFi ऑथेंटिकेशनद्वारे वापरल्या जाणाऱ्या डिरेक्टरी कंट्रोलमध्ये प्रवाहित करा. अक्षम केलेली ओळख नवीन 802.1X सत्र स्थापित करू शकत नाही याची पडताळणी करा.
• नेटवर्क टीम, रिव्होकेशन अवलंबित्वांचे निरीक्षण करा: अनुपलब्ध वितरण बिंदू, कालबाह्य झालेले CRLs, अवैध स्वाक्षऱ्या आणि अयशस्वी स्टेटस चेक्सवर अलर्ट पाठवा. CA मधील बदलांच्या सूचनांसाठी सबस्क्राइब करा जेणेकरून एखादा पब्लिकेशन बदल ऑथेंटिकेशनला नकळत खराब करणार नाही.

पुढील पुनरावलोकन कालावधीत दोन परिणाम मोजा. पहिले, डिरेक्टरी डिसेबल इव्हेंट आणि नवीन WiFi सेशन संपवणे किंवा नकार देणे यामधील लेटन्सी रेकॉर्ड करा. दुसरे, सॉफ्ट-फेल पाथद्वारे पुढे जाण्याऐवजी किती RADIUS ऑथेंटिकेशन्सनी यशस्वी CRL तपासणी पूर्ण केली ते मोजा. हे उपाय तुम्हाला सांगतात की डिझाइन दबावाखाली काम करते की नाही, केवळ स्प्रेडशीटमध्ये सर्टिफिकेट्स योग्य दिसतात की नाही एवढेच नाही.

तुमच्या टीमला ओळख-आधारित एंटरप्राइझ WiFi कायम ठेवून मॅन्युअल PKI प्रशासन कमी करायचे असल्यास, Purple व्यवस्थापित प्रमाणपत्र-दर्जाचे प्रमाणीकरण (authentication), डिरेक्टरी-कनेक्टेड प्रवेश निर्णय आणि रद्दीकरण तपासणीला समर्थन देणाऱ्या RADIUS सेवा प्रदान करू शकते. Purple चे धोरण तुमच्या WiFi ऑफबोर्डिंग आणि प्रमाणपत्र जीवनचक्र वर्कफ्लोशी कसे सुसंगत ठरू शकते याचे मूल्यांकन करण्यासाठी Purple ला भेट द्या.