ट्रेन में एक कंपनी का लैपटॉप चोरी हो जाता है। हेल्पडेस्क कर्मचारी के Active Directory अकाउंट को अक्षम कर देता है, डिवाइस एसेट रजिस्टर से गायब हो जाता है, और हर कोई मान लेता है कि जोखिम हटा दिया गया है। दो दिन बाद, लैपटॉप अभी भी कॉर्पोरेट SSID पर दिखाई देता है क्योंकि इसका 802.1X सप्लिकेंट एक क्लाइंट सर्टिफिकेट रखता है जो समाप्त नहीं हुआ है और किसी ने इसे निरस्त नहीं किया है।
यही वह अंतर है जिसे पाटने के लिए एक रद्दीकरण सूची प्रमाणपत्र (revocation list certificate) प्रक्रिया को डिज़ाइन किया गया है। प्रमाणपत्र की समाप्ति (expiry) विश्वास की अंतिम सीमा तय करती है, जबकि रद्दीकरण (revocation) विश्वास को पहले ही समाप्त कर देता है जब कोई कुंजी (key) से समझौता हो जाता है, कोई डिवाइस खो जाता है, या कोई उपयोगकर्ता छोड़ देता है। एक एंटरप्राइज WiFi एडमिनिस्ट्रेटर के लिए, महत्वपूर्ण सवाल यह नहीं है कि प्रमाणपत्र मौजूद हैं या नहीं। बल्कि यह है कि क्या RADIUS और संबंधित नेटवर्क नियंत्रण एक रद्द किए गए प्रमाणपत्र के बारे में जल्दी से जान पाते हैं और सुरक्षित रूप से विफल (fail safely) होते हैं।
वह WiFi एक्सेस जो कभी समाप्त नहीं होता
एक प्रमाणपत्र-आधारित WiFi परिनियोजन अक्सर बाहर से सुरक्षित दिखता है। क्लाइंट EAP-TLS का उपयोग करता है, RADIUS सेवा प्रमाणपत्र श्रृंखला को मान्य करती है, और साझा पासवर्ड कर्मचारियों के बीच साझा नहीं किए जाते हैं। लेकिन वह डिज़ाइन अभी भी एक कार्यशील लाइफसाइकिल पर निर्भर करता है। प्रमाणपत्र जारी करना केवल शुरुआत है। आपको यह भी पता होना चाहिए कि इसका मालिक कौन है, यह कब समाप्त होता है, और यदि डिवाइस या निजी कुंजी अब विश्वसनीय नहीं है तो क्या होता है।
चोरी हुए लैपटॉप के उदाहरण में, Active Directory से अकाउंट हटाने से भविष्य का डायरेक्टरी ऑथेंटिकेशन रुक सकता है, लेकिन यह आवश्यक रूप से डिवाइस पर पहले से इंस्टॉल किए गए सर्टिफिकेट को अमान्य नहीं करता है। यदि WiFi सेवा केवल उसकी चेन और वैधता तिथियों के आधार पर सर्टिफिकेट पर भरोसा करती है, तो लैपटॉप स्पष्ट रूप से वैध क्रेडेंशियल पेश करना जारी रख सकता है। सर्टिफिकेट की notAfter date बताती है कि यह अपने निर्धारित जीवनकाल के भीतर है। यह यह नहीं बताती है कि जारी करने वाला संगठन अभी भी इस पर भरोसा करना चाहता है।
व्यावहारिक नियम: सर्टिफिकेट की समाप्ति (एक्सपायरी) और सर्टिफिकेट रिवोकेशन को अलग-अलग नियंत्रणों के रूप में मानें। समाप्ति एक नियोजित लाइफसाइकल मैनेजमेंट है। रिवोकेशन आपातकालीन ब्रेक है।
यूके सार्वजनिक-क्षेत्र का PKI मॉडल उस अंतर को स्पष्ट करता है। एक सर्टिफिकेट रिवोकेशन लिस्ट, या CRL, समाप्ति से पहले रिवोक किए गए सर्टिफिकेट सीरियल नंबरों की एक हस्ताक्षरित सूची है, जो भरोसा करने वाले पक्षों को बताती है कि उन सर्टिफिकेट पर अब भरोसा नहीं किया जाना चाहिए। यूके पब्लिक-की इन्फ्रास्ट्रक्चर मार्गदर्शन भी CRL को सामान्य रिवोकेशन विधियों में से एक के रूप में पहचानता है और उम्मीद करता है कि क्लाइंट यह जांचें कि प्रस्तुत किया गया सर्टिफिकेट जारी करने वाले CA की सूची में दिखाई देता है या नहीं।
यह WiFi पर महत्वपूर्ण है क्योंकि प्रमाणीकरण के निर्णय नेटवर्क के किनारे पर होते हैं, अक्सर कई नियंत्रकों, एक्सेस पॉइंट्स, RADIUS सर्वरों और कैश्ड सत्यापन स्टोरों में। एक मैन्युअल CRL अपडेट सुरक्षा में अंतर छोड़ सकता है, जबकि एक खराब रूप से डिज़ाइन की गई फ़ेल-क्लोज़्ड नीति आउटेज का कारण बन सकती है यदि CRL वितरण बिंदु अनुपलब्ध हो जाता है।
काम करने का मानसिक मॉडल सीधा है: CA स्थिति की जानकारी जारी करता है और उस पर हस्ताक्षर करता है, निर्भर रहने वाला पक्ष इसकी जांच करता है, और नेटवर्क उस प्रमाणपत्र को अस्वीकार कर देता है जिसे निरस्त कर दिया गया है। इस गाइड का शेष भाग यह जांच करता है कि वह प्रक्रिया कैसे काम करती है, CRL और OCSP में क्या अंतर है, और निर्देशिका-संचालित एक्सेस नियंत्रण मैन्युअल निरस्तीकरण की बाधा को काफी हद तक कैसे दूर कर सकते हैं।
वास्तव में निरस्तीकरण सूची (Revocation List) सर्टिफिकेट क्या है
सरल भाषा में, एक सर्टिफिकेट रिवोकेशन लिस्ट एक सर्टिफिकेट अथॉरिटी से एक आधिकारिक "अब इन सर्टिफिकेट पर भरोसा न करें" नोटिस है। यह सर्टिफिकेट की पहचान उनके सीरियल नंबरों से करता है, न कि किसी आसान डिवाइस नाम या कर्मचारी के ईमेल पते से। एक क्लाइंट जो संबंधित सूची में प्रस्तुत सर्टिफिकेट का सीरियल नंबर पाता है, उसे इसे अस्वीकार करना होगा, भले ही सर्टिफिकेट की समाप्ति तिथि अभी भी भविष्य में हो।
UK की परिभाषा औपचारिक है। यह एक CRL को समाप्ति से पहले निरस्त (revoke) किए गए सर्टिफिकेट सीरियल नंबरों की एक हस्ताक्षरित (signed) सूची के रूप में वर्णित करता है, इसलिए भरोसा करने वाले पक्षों को अब उन सर्टिफिकेट्स पर भरोसा नहीं करना चाहिए। सिग्नेचर महत्वपूर्ण है क्योंकि एक RADIUS सर्वर या अन्य वैलिडेटर को यह पुष्टि करनी होगी कि सूची अपेक्षित जारीकर्ता से आई है और पारगमन (transit) में इसमें कोई बदलाव नहीं किया गया है। एक एडमिनिस्ट्रेटर द्वारा बनाए रखी गई प्लेन टेक्स्ट ब्लॉकलिस्ट वह क्रिप्टोग्राफिक आश्वासन प्रदान नहीं करती है।
तीन पक्ष इस प्रक्रिया को उपयोगी बनाते हैं:
- सर्टिफिकेट अथॉरिटी: CA, या एक अधिकृत CRL जारीकर्ता, सूची बनाता है और जारी करने वाले ट्रस्ट पदानुक्रम से जुड़ी एक प्राइवेट की (private key) का उपयोग करके इस पर हस्ताक्षर करता है।
- भरोसा करने वाला पक्ष (Relying party): एक RADIUS सर्वर, सप्लीकेंट, कंट्रोलर, ऑपरेटिंग सिस्टम, या एडमिनिस्ट्रेटिव टूल सूची को डाउनलोड करता है, उसके सिग्नेचर और वैलिडिटी की जानकारी को वैलिडेट करता है, और फिर सर्टिफिकेट सीरियल नंबर को खोजता है।
- सर्टिफिकेट धारक: वह व्यक्ति, डिवाइस, या सेवा जिसका सर्टिफिकेट निरस्त (revoke) कर दिया गया है। इसका सीरियल नंबर सूची में बना रहता है ताकि वैलिडेटर्स इसे अविश्वसनीय के रूप में पहचान सकें।
एक CRL सामान्यतः उस अर्थ में प्रमाणपत्र नहीं होता है जिस अर्थ में उपयोगकर्ता या डिवाइस प्रमाणपत्र होता है। यह एक हस्ताक्षरित PKI आर्टिफैक्ट है जिसमें जारीकर्ता, वैधता और प्रकाशन की जानकारी होती है। लोग कभी-कभी प्रमाणपत्र-निरस्तीकरण तंत्र के लिए संक्षेप में "निरस्तीकरण सूची प्रमाणपत्र" का उपयोग करते हैं, लेकिन जिस परिचालन ऑब्जेक्ट की जांच की जा रही है वह हस्ताक्षरित CRL है।
रिलाइंग पार्टी (relying party) आमतौर पर CA से यह बताने के लिए नहीं कहती है कि किसी यूजर को क्यों अस्वीकार किया जाना चाहिए। यह सर्टिफिकेट की निरस्तीकरण (revocation) जानकारी का पालन करता है, जारीकर्ता का वर्तमान CRL प्राप्त करता है, CRL को सत्यापित करता है, और सीरियल नंबर की जांच करता है। यदि कोई मिलान होता है, तो सर्टिफिकेट को निरस्त मान लिया जाता है। यदि ऐसा नहीं होता है, तो परिणाम अभी भी CRL की नवीनता और रिलाइंग पार्टी के अपने कैश से सीमित रहता है।
वह अंतिम बिंदु कई घटनाओं का कारण बनता है। कोई सर्टिफिकेट पुरानी कैश्ड सूची से अनुपस्थित हो सकता है और नई सूची में मौजूद हो सकता है। इसलिए नेटवर्क का निर्णय इस बात पर निर्भर करता है कि CA ने क्या प्रकाशित किया और प्रमाणक (authenticator) ने इसे आखिरी बार कब प्राप्त किया।
पर्दे के पीछे एक CRL कैसे काम करता है
एक CRL लाइफसाइकिल घटनाओं की एक अनुमानित श्रृंखला का पालन करती है। सबसे पहले, CA अपनी प्रमाणपत्र नीति के अनुसार एक आधार सूची तैयार करता है। यह सूची पर हस्ताक्षर करता है, प्रकाशन और वैधता फ़ील्ड जोड़ता है, और इसे एक वितरण बिंदु के माध्यम से उपलब्ध कराता है। जारी किए गए प्रमाणपत्र आमतौर पर CRL वितरण बिंदु एक्सटेंशन के माध्यम से उन स्थानों का संदर्भ देते हैं, जिससे एक सत्यापनकर्ता को यह पता लगाने की अनुमति मिलती है कि स्थिति की जानकारी कहाँ से संबंधित है।
जब कोई एडमिनिस्ट्रेटर किसी डिवाइस सर्टिफिकेट को निरस्त करता है, तो CA उसका सीरियल नंबर और कारण की जानकारी दर्ज करता है। यह आवश्यक नहीं है कि सर्टिफिकेट तुरंत प्रत्येक रिलाइंग पार्टी के कैश में दिखाई दे। अगले प्रकाशित CRL में वह प्रविष्टि होनी चाहिए, और प्रत्येक RADIUS सर्वर या कंट्रोलर को सही निर्णय लेने से पहले एक वर्तमान प्रति प्राप्त करनी होगी।
कुछ PKI परिवेश डेल्टा CRL का भी उपयोग करते हैं। एक डेल्टा में बेस CRL के बाद से हुए परिवर्तन शामिल होते हैं, जो पूरी सूची बड़ी होने पर ट्रांसफर और प्रोसेसिंग के काम को कम कर सकते हैं। वह दक्षता बेस सूची को प्रबंधित करने, हस्ताक्षरों को मान्य करने, नवीनता को ट्रैक करने, या यह सुनिश्चित करने की आवश्यकता को समाप्त नहीं करती है कि प्रत्येक नेटवर्क घटक चुने गए प्रकाशन मॉडल को समझता है।
फ्रेशनेस विंडो (Freshness window)
यूके की नीतियां प्रसार के बारे में सोचने के लिए उपयोगी संदर्भ बिंदु प्रदान करती हैं। यूके सरकार का CVCA अभ्यास विवरण आवश्यक बनाता है कि CRL अधिकतम हर 90 दिनों में जारी किए जाएं, और रिवोक किए गए सर्टिफिकेट को रिवोकेशन के 72 घंटों के भीतर प्रासंगिक CRL में दिखाई देना चाहिए। उन सीमाओं को यूके राष्ट्रीय सर्टिफिकेट नीति में वर्णित किया गया है।
अन्य UK पॉलिसियां अलग-अलग सेवा अपेक्षाओं का उपयोग करती हैं। HM Land Registry का कहना है कि निरस्त और सस्पेंड किए गए सर्टिफिकेट के लिए उसकी रिवोकेशन सूची को कम से कम दिन में एक बार अपडेट किया जाना चाहिए, जबकि University of York का सर्टिफिकेट प्रैक्टिस स्टेटमेंट रिवोकेशन और CRL जारी करने के बीच अधिकतम 10 दिनों की देरी की अनुमति देता है। ये उदाहरण, जिसमें HMPO Country Signing Certificate Authority पब्लिकेशन पॉइंट भी शामिल है, यह दर्शाते हैं कि एक एडमिनिस्ट्रेटर को यह मानने के बजाय कि हर CRL एक जैसा व्यवहार करता है, जारी करने वाले CA की वास्तविक पॉलिसी को क्यों पढ़ना चाहिए।
प्रमाणीकरण के समय, RADIUS सर्वर अपने स्थानीय रूप से उपलब्ध CRL के विरुद्ध प्रमाणपत्र सीरियल की जाँच करता है। यह यह भी जाँचता है कि क्या CRL अपनी वैधता अवधि के भीतर है, क्या हस्ताक्षर अपेक्षित जारीकर्ता की श्रृंखला से जुड़े हैं, और क्या रीफ्रेश होने पर वितरण बिंदु तक पहुँचा जा सकता है। सर्वर फिर अपने कार्यान्वयन और CRL के nextUpdate मान के अनुसार परिणाम को कैश करता है।
यह बिना किसी जटिल गणित के एक व्यावहारिक जोखिम समीकरण तैयार करता है: निरस्तीकरण विलंबता (revocation latency) में CA प्रकाशन समय, वितरण विलंब, कैश अवधि और ऑथेंटिकेशन आवृत्ति शामिल है। एक पॉलिसी जल्दी प्रकाशित हो सकती है, लेकिन एक डिस्कनेक्ट या पुराना RADIUS कैश अभी भी लागू करने में देरी कर सकता है।
CRL बनाम OCSP और WiFi पर इसका महत्व क्यों है
CRL और OCSP एक ही मूल समस्या को अलग-अलग तरीकों से हल करते हैं। एक CRL वैलिडेटर को रिवोक किए गए सीरियल नंबरों का एक हस्ताक्षरित बैच देता है। OCSP जांच के समय एक अधिकृत रेस्पोंडर से किसी एक सर्टिफिकेट की स्थिति के बारे में पूछता है।
एक एंटरप्राइज WiFi एडमिनिस्ट्रेटर के लिए, यह विकल्प केवल PKI की सुंदरता से कहीं अधिक प्रभावित करता है। यह बदलता है कि एक व्यस्त WAN पर एक कंट्रोलर कैसे व्यवहार करता है, CA इन्फ्रास्ट्रक्चर को क्या संभालना चाहिए, और क्या एक रेस्पोंडर या डिस्ट्रीब्यूशन पॉइंट के अनुपलब्ध होने पर ऑथेंटिकेशन का प्रयास पूरा हो सकता है।
| मापदंड | CRL | OCSP |
|---|---|---|
| नवीनता (Freshness) | आवधिक। एक नया रद्द किया गया प्रमाणपत्र प्रकाशन और क्लाइंट रीफ्रेश होने की प्रतीक्षा करता है। | प्रति-प्रमाणपत्र क्वेरी अधिक वर्तमान स्थिति प्रदान कर सकती है जब रिस्पॉन्डर सुलभ हो। | क्लाइंट एक सूची डाउनलोड और प्रोसेस करते हैं, जो एक प्रबंधित एस्टेट के खिलाफ बार-बार की जाने वाली जांच के लिए कुशल हो सकती है लेकिन वितरण ट्रैफ़िक बढ़ा सकती है। | रिस्पॉन्डर व्यक्तिगत स्थिति अनुरोधों को संभालता है, जो पूरी सूची डाउनलोड करने से बचाता है लेकिन अनुरोधों की मात्रा बढ़ाता है। |
| गोपनीयता (Privacy) | सत्यापन करने वाला पक्ष (relying party) एक सूची प्राप्त करता है और उसे CA को प्रत्येक प्रमाणपत्र जांच का खुलासा करने की आवश्यकता नहीं होती है। | एक सीधी क्वेरी रिस्पॉन्डर को यह बता सकती है कि किस प्रमाणपत्र की जांच की जा रही है। |
| विफलता मोड (Failure mode) | एक अनुपलब्ध या समाप्त हो चुका CRL विश्वसनीय स्थिति सत्यापन को रोक सकता है। स्थानीय कैश अपनी नवीनता सीमा तक काम करना जारी रख सकते हैं। | एक अनुपलब्ध रिस्पॉन्डर व्यक्तिगत स्थिति क्वेरी को प्रभावित करता है, और कॉन्फ़िगर किया गया सॉफ्ट-फेल या हार्ड-फेल व्यवहार WiFi के परिणाम को निर्धारित करता है। |
एक बड़े परिसर में सेवा देने वाला कंट्रोलर स्थानीय रूप से कैश्ड CRL को प्राथमिकता दे सकता है क्योंकि यह प्रत्येक ऑथेंटिकेशन के लिए एक अलग अनुरोध भेजे बिना कई सर्टिफिकेट सीरियल नंबरों की जांच कर सकता है। यह मॉडल तब अच्छी तरह से काम करता है जब डिस्ट्रिब्यूशन पॉइंट तक पहुँचा जा सकता है, अपडेट की निगरानी की जाती है, और RADIUS पॉलिसी जानबूझकर समाप्त हो चुकी लिस्ट को संभालती है।
OCSP उस डिज़ाइन के लिए उपयुक्त हो सकता है जहाँ ऑपरेटर को प्रति-सर्टिफिकेट प्रतिक्रिया की आवश्यकता होती है और वह रिस्पॉन्डर पर निर्भरता स्वीकार करता है। यह पूरी सूची को ट्रांसफर करने की आवश्यकता को कम कर सकता है, लेकिन यह प्रमाणीकरण के दौरान एक लाइव नेटवर्क निर्भरता पैदा करता है। स्टेपलिंग कुछ प्रोटोकॉल में रिस्पॉन्डर इंटरैक्शन को कहीं और स्थानांतरित कर सकता है, फिर भी WiFi डिज़ाइन को अनुपलब्ध या पुराने स्टेटस डेटा के लिए एक स्पष्ट उत्तर की आवश्यकता होती है।
यूके (UK) का मार्गदर्शन यहाँ उपयोगी है क्योंकि यह CRL को एकमात्र विधि के रूप में प्रस्तुत नहीं करता है। यूके (UK) की नीति CRL को सामान्य निरसन तंत्रों में से एक के रूप में वर्णित करती है, जबकि न्याय-क्षेत्र का मार्गदर्शन उन्हें एक प्राथमिक ऑफ़लाइन तंत्र के रूप में मानता है और PKI प्रकटीकरण विवरण में निरसन सेवाओं के लिए उपलब्धता आवश्यकताओं पर प्रकाश डालता है।
प्रबंधित 802.1X उपकरणों के लिए, नियमित बैच सत्यापन के लिए आमतौर पर CRL व्यावहारिक है, विशेष रूप से तब जब संपदा में विश्वसनीय आंतरिक वितरण हो। OCSP वहाँ बेहतर है जहाँ सख्त स्थिति नवीनता आवश्यक है और रिस्पॉन्डर की उपलब्धता के अनुसार इंजीनियरिंग की गई है। उच्च-आश्वासन वाले नेटवर्क दोनों चला सकते हैं, लेकिन केवल तभी जब फ़ॉलबैक व्यवहार को मान लेने के बजाय प्रलेखित और परीक्षण किया गया हो।
एक Purple WiFi नेटवर्क पर व्यवहार में निरस्तीकरण (Revocation)
परिचालन अंतर तब दिखाई देता है जब WiFi एक्सेस मैन्युअल रूप से प्रबंधित सर्टिफिकेट सूची के बजाय एक लाइव पहचान डायरेक्टरी से जुड़ा होता है। एक डायरेक्टरी एकीकरण यूजर के वर्तमान अकाउंट की स्थिति को प्रमाणीकरण निर्णय का हिस्सा बना सकता है, जिससे अकाउंट को अक्षम करना एक एक्सेस-कंट्रोल इवेंट बन जाता है, न कि कोई ऐसा टिकट जिसे बाद में किसी को CA निरस्तीकरण में अनुवादित करना पड़े।
एक सामान्य फ्लो इस प्रकार दिखाई देता है:
- डायरेक्ट्री पहचान की स्थिति को रिकॉर्ड करती है। Active Directory, Entra ID, या Google Workspace में एक अकाउंट बनाया जाता है, बदला जाता है, सस्पेंड किया जाता है, या डिसेबल किया जाता है।
- WiFi पहचान सेवा बदलाव को प्राप्त करती है। यह सेवा डायरेक्ट्री की स्थिति को संगठन के ऑथेंटिकेशन पॉलिसी से मैप करती है।
- अगले ऑथेंटिकेशन का मूल्यांकन उस स्थिति के आधार पर किया जाता है। एक डिसेबल की गई पहचान अब एक्सेस नियम को पूरा नहीं करती है, भले ही पहले से जारी किया गया क्रेडेंशियल अपने सर्टिफिकेट लाइफटाइम के भीतर ही क्यों न हो।
- नेटवर्क एक्सेस से इनकार करता है। RADIUS का निर्णय निष्क्रिय पहचान के तहत एक नए 802.1X सेशन को अधिकृत होने से रोकता है।
यह मॉडल केवल-CRL ऑपरेशन्स की कमजोरी को दूर करता है। एक CRL, CA प्रकाशन, वितरण बिंदुओं, कैश रिफ्रेश, और रिलाइंग-पार्टी जांच पर निर्भर करता है। डायरेक्टरी-संचालित प्रवर्तन पहचान प्रणाली को अकाउंट स्थिति के लिए परिचालन स्रोत बनाता है, जिससे किसी एडमिनिस्ट्रेटर को जाने वाले यूजर से जुड़े प्रत्येक सर्टिफिकेट सीरियल को खोजने की आवश्यकता कम हो जाती है।
परिचालन अंतर: एक CRL यह उत्तर देता है कि क्या कोई सर्टिफिकेट रिवोक किया गया है। डायरेक्टरी-संचालित ऑथेंटिकेशन यह उत्तर दे सकता है कि क्या पहचान वर्तमान में नेटवर्क का उपयोग करने के लिए अधिकृत है।
Purple, Microsoft Entra ID और Google Workspace जैसे डायरेक्टरी एकीकरण के साथ प्रबंधित RADIUS और प्रमाणपत्र-आधारित एंटरप्राइज़ WiFi नियंत्रण प्रदान करता है। इसकी RADIUS-as-a-Service पेशकश वहाँ प्रासंगिक है जहाँ एक संगठन प्रत्येक ऑन-प्रिमाइसेस RADIUS और निरसन घटक को स्वयं बनाए रखे बिना पहचान की स्थिति को 802.1X प्रमाणीकरण से जोड़ना चाहता है।
इससे PKI लाइफसाइकिल का काम खत्म नहीं हो जाता। प्रमाणपत्रों को अभी भी जारी करने, नवीनीकरण, ट्रस्ट-चेन प्रबंधन और निरसन जांच की आवश्यकता होती है जहाँ आर्किटेक्चर को इसकी आवश्यकता होती है। हालाँकि, यह ऑफबोर्डिंग पथ से एक मैन्युअल बाधा को हटा देता है। सर्विस डेस्क स्थापित डायरेक्टरी वर्कफ़्लो के माध्यम से पहचान को अक्षम कर सकता है, जबकि नेटवर्क प्रमाणीकरण परत अगले एक्सेस निर्णय पर उस स्थिति को लागू करती है।
एंटरप्राइज WiFi के लिए सर्वोत्तम परिचालन अभ्यास
एक विश्वसनीय रिवोकेशन डिज़ाइन सामान्य परिचालन अनुशासन के साथ क्रिप्टोग्राफिक नियंत्रणों को जोड़ता है। सर्टिफिकेट के जीवनकाल से शुरुआत करें। प्रबंधित WiFi डिवाइसों के लिए, प्रदान किए गए परिनियोजन मार्गदर्शन में 12 से 24 महीने का सर्टिफिकेट जीवनकाल एक सामान्य परिचालन संदर्भ है, लेकिन सही विकल्प डिवाइस के स्वामित्व, रिन्यूअल क्षमता और एक उजागर हुई प्राइवेट की (private key) के कारण होने वाले नुकसान पर निर्भर करता है। गेस्ट स्पॉन्सर सर्टिफिकेट का जीवनकाल आम तौर पर छोटा होना चाहिए क्योंकि उनके एक्सेस का संदर्भ अधिक बार बदलता है।
डिवाइस लाइफसाइकल में रिन्यूअल को शामिल करें
प्रमाणपत्रों की समाप्ति से पहले उन्हें नवीनीकृत करने के लिए SCEP, एक MDM प्लेटफ़ॉर्म, या अन्य स्वचालित नामांकन मार्ग का उपयोग करें। मैन्युअल नवीनीकरण एक पायलट के दौरान काम करता है लेकिन एक वितरित संपदा में कमजोर हो जाता है। स्लीपिंग लैपटॉप, रिमोट डिवाइस, रीबिल्ट डिवाइस और उन डिवाइसों पर नवीनीकरण का परीक्षण करें जो हाल ही में कॉर्पोरेट नेटवर्क से नहीं जुड़े हैं।
RADIUS और कंट्रोलर द्वारा उपयोग किए जाने वाले समान नेटवर्क पथों से CRL डिस्ट्रिब्यूशन पॉइंट की निगरानी करें। पहुँच योग्यता, सिग्नेचर वैधता, जारीकर्ता की पहचान और nextUpdate की जाँच करें, केवल यह नहीं कि कोई वेब अनुरोध कंटेंट वापस करता है या नहीं। एक सुलभ लेकिन समाप्त हो चुका CRL अभी भी एक विफल निरस्तीकरण नियंत्रण है।
RADIUS पक्ष को साफ रखें
RADIUS सर्वर सर्टिफिकेट को वर्तमान वैधता, एक विश्वसनीय जारी करने वाली चेन और एक रिन्यूअल प्रक्रिया की आवश्यकता होती है जो आखिरी समय के रखरखाव विंडो पर निर्भर न हो। सर्वर, कंट्रोलर और प्रबंधित क्लाइंट पर ट्रस्ट स्टोर की समीक्षा करें ताकि एक पुराना CA सर्टिफिकेट सभी साइटों पर असंगत निर्णयों का कारण न बने।
रिवोकेशन रनबुक को उस भाषा में दस्तावेजित करें जिसका ऑन-कॉल इंजीनियर पालन कर सके:
- क्रेडेंशियल की पहचान करें: यूजर, डिवाइस, सर्टिफिकेट सीरियल, और जारी करने वाले CA को रिकॉर्ड करें।
- पहचान को डिसेबल करें: स्वीकृत डायरेक्ट्री या HR ऑफबोर्डिंग प्रक्रिया को लागू करें।
- आवश्यकता होने पर निरस्त (revoke) करें: CA स्थिति को अपडेट करें और पब्लिकेशन की पुष्टि करें।
- भरोसा करने वाले पक्षों को रिफ्रेश करें: जहां भी समर्थित हो, वहां CRL पुनःप्राप्ति (retrieval) को बाध्य या शेड्यूल करें।
- अस्वीकृति का परीक्षण करें: प्रभावित क्रेडेंशियल के साथ ऑथेंटिकेशन का प्रयास करें और परिणाम को सुरक्षित रखें।
HR ट्रिगर्स को निर्देशिका परिवर्तनों के साथ संरेखित करें। यदि सर्विस डेस्क को एक अलग PKI टिकट की प्रतीक्षा करनी पड़ती है, तो नेटवर्क उस पहचान पर भरोसा करना जारी रख सकता है जिसे संगठन ने पहले ही निष्क्रिय चिह्नित कर दिया है। स्वचालित प्रावधान और नवीनीकरण उस बेमेल को कम करते हैं, जबकि चोरी हुए उपकरणों और संदिग्ध कुंजी सुरक्षा से समझौते के मामलों के लिए एक प्रलेखित मैन्युअल मार्ग महत्वपूर्ण बना रहता है।
पासवर्ड रहित कर्मचारियों की पहुंच के लिए, समीक्षा करें कि ये नियंत्रण WPA-Enterprise deployment के साथ कैसे फिट होते हैं, जिसमें सर्टिफिकेट एनरोलमेंट, RADIUS वैलिडेशन और ऑफबोर्डिंग ओनरशिप शामिल हैं।
सामान्य रिवोकेशन समस्याओं का समाधान करना
अधिकांश CRL घटनाएं तीन श्रेणियों में आती हैं: वैलिडेटर के पास पुरानी जानकारी है, वह सही पब्लिकेशन पॉइंट नहीं ढूंढ पा रहा है, या रिवोकेशन स्टोर को संचालित करना कठिन हो गया है। सर्टिफिकेट को दोबारा जारी करने से शुरू करने के बजाय निर्णय पथ का निदान करें।
एक पुराना स्थानीय कैश (local cache)
एक RADIUS सर्वर या नियंत्रक अभी भी एक ऐसा CRL रख सकता है जो निरस्तीकरण से पहले का है। CRL के thisUpdate और nextUpdate फ़ील्ड की पुष्टि करें, जारीकर्ता CA के विरुद्ध इसके हस्ताक्षर को मान्य करें, और प्रमाणक पर कैश्ड कॉपी का निरीक्षण करें। क्लाइंट द्वारा प्रस्तुत सीरियल नंबर की तुलना नए प्रकाशित CRL में मौजूद प्रविष्टियों से करें।
इसका तात्कालिक समाधान यह है कि यदि प्लेटफॉर्म इसका समर्थन करता है तो CRL रीफ्रेश को बाध्य करें, फिर प्रभावित सर्टिफिकेट के साथ ऑथेंटिकेशन टेस्ट को दोहराएं। यदि कैश पुराना डेटा ही दिखाता रहता है, तो प्रॉक्सी व्यवहार, डिस्ट्रीब्यूशन-पॉइंट कैशिंग और वैलिडेटर की रीफ्रेश पॉलिसी की जांच करें।
एक अनुपलब्ध वितरण बिंदु (distribution point)
जारी किए गए सर्टिफिकेट के CDP और AIA एक्सटेंशन पढ़ें। CDP रिलाइंग पार्टी को बताता है कि निरस्तीकरण (revocation) की जानकारी कहाँ मिलेगी, जबकि AIA उसे चेन वैलिडेशन के लिए आवश्यक जारीकर्ता (issuer) की जानकारी की पहचान करने में मदद कर सकता है। पुष्टि करें कि URL सही है, RADIUS नेटवर्क से पहुँचा जा सकता है, और अपेक्षित जारीकर्ता द्वारा हस्ताक्षरित CRL की सेवा कर रहा है।
यदि CA टेम्पलेट में गलत स्थान है, तो टेम्पलेट को ठीक करें और रिप्लेसमेंट सर्टिफिकेट जारी करें। केवल एंडपॉइंट को अपडेट करने से वे सर्टिफिकेट ठीक नहीं होंगे जिनमें पहले से ही अनुपयोगी डिस्ट्रीब्यूशन पॉइंट शामिल है।
एक कठिन रिवोकेशन स्टोर (revocation store)
पुरानी प्रविष्टियाँ प्रशासन को जटिल बना सकती हैं और प्रोसेसिंग कार्य को बढ़ा सकती हैं। प्रविष्टियों को केवल CA की रिटेंशन पॉलिसी के तहत और प्रासंगिक सर्टिफिकेट लाइफटाइम और ऑडिट आवश्यकताओं पर विचार करने के बाद ही हटाएं। किसी सीरियल नंबर को केवल इसलिए न हटाएँ क्योंकि इंसिडेंट टिकट बंद हो गया है।
UK पॉलिसी के उदाहरण बताते हैं कि क्यों "ताज़ा" को स्थानीय रूप से परिभाषित किया जाना चाहिए। कुछ UK अधिकारियों को दैनिक अपडेट की आवश्यकता होती है, जबकि राष्ट्रीय CVCA पॉलिसी को निरस्त सर्टिफिकेट के लिए 72 घंटों के भीतर प्रकाशन की आवश्यकता होती है और 90 दिनों की अधिकतम जारी करने की अवधि निर्धारित की जाती है। इन्हें पॉलिसी बेसलाइन के रूप में मानें, न कि पुराने एंटरप्राइज़ डेटा को स्वीकार करने की अनुमति के रूप में।
एक प्रमाणपत्र विश्लेषण टूल जारीकर्ता, वैधता, CDP और चेन विवरणों का निरीक्षण करने में मदद कर सकता है। Purple का SSL प्रमाणपत्र चेकर प्रमाणपत्र की स्थिति की जांच करने के लिए एक विकल्प है, जबकि निर्देशिका-संचालित प्रवर्तन उपयोगकर्ता को ऑफबोर्ड करने के लिए केवल विलंबित CRL रीफ्रेश पर निर्भर रहने से बचा सकता है।
इस सप्ताह सब कुछ एक साथ संरेखित करना
निरस्तीकरण को नीति के एक पैराग्राफ के बजाय सौंपे गए काम में बदलें। इन कार्यों को अगले बदलाव विंडो में डालें और प्रत्येक को एक नामित स्वामी सौंपें।
- PKI टीम, प्रमाणपत्र पथों का ऑडिट करें: प्रत्येक WiFi क्लाइंट प्रमाणपत्र टेम्पलेट, जारीकर्ता CA, CDP, और RADIUS ट्रस्ट संबंध का इन्वेंटरी तैयार करें। पुष्टि करें कि प्रत्येक वितरण बिंदु (distribution point) हर प्रमाणीकरण साइट से सुलभ है।
- PKI और एंडपॉइंट टीम, एक सुरक्षित लाइफटाइम सेट करें: WiFi क्लाइंट प्रमाणपत्रों को 12 महीने या उससे कम की अवधि पर ले जाएं, बशर्ते डिवाइस रिन्यूअल प्रक्रिया इसका समर्थन कर सके। छोटा लाइफटाइम आपातकालीन रद्दीकरण (revocation) पर निर्भरता को कम करता है, लेकिन केवल तभी जब रिन्यूअल स्वचालित और परीक्षित हो।
- एंडपॉइंट टीम, रिन्यूअल को स्वचालित करें: बिना किसी उपयोगकर्ता हस्तक्षेप के प्रमाणपत्रों को एनरोल और रिन्यू करने के लिए MDM या SCEP का उपयोग करें। डिवाइस के दोबारा रीबिल्ड होने, लंबे समय तक ऑफलाइन रहने और उपयोगकर्ता के बदलने के बाद इस प्रक्रिया का परीक्षण करें।
- सर्विस डेस्क और आइडेंटिटी टीम, ऑफबोर्डिंग को एक्सेस अस्वीकृति से जोड़ें: HR या सर्विस-डेस्क की निष्क्रिय स्थिति (inactive state) को सीधे WiFi प्रमाणीकरण द्वारा उपयोग किए जाने वाले डायरेक्टरी कंट्रोल में प्रवाहित करें। सत्यापित करें कि एक अक्षम (disabled) पहचान एक नया 802.1X सत्र स्थापित नहीं कर सकती है।
- नेटवर्क टीम, रद्दीकरण (revocation) निर्भरता की निगरानी करें: अनुपलब्ध वितरण बिंदुओं, समाप्त हो चुके CRLs, अमान्य हस्ताक्षरों और विफल स्थिति जांचों पर अलर्ट प्राप्त करें। CA परिवर्तन सूचनाओं की सदस्यता लें ताकि कोई प्रकाशन परिवर्तन बिना ध्यान दिए प्रमाणीकरण को प्रभावित न कर सके।
निम्नलिखित समीक्षा अवधि के दौरान दो परिणामों को मापें। पहला, डायरेक्टरी डिसेबल इवेंट और एक नए WiFi सेशन की समाप्ति या अस्वीकृति के बीच की लेटेंसी को रिकॉर्ड करें। दूसरा, मापें कि कितने RADIUS ऑथेंटिकेशन ने सॉफ्ट-फेल पाथ के माध्यम से जारी रहने के बजाय एक सफल CRL जांच पूरी की। वे उपाय आपको बताते हैं कि क्या डिज़ाइन दबाव में काम करता है, न कि केवल यह कि क्या सर्टिफिकेट स्प्रेडशीट में सही दिखते हैं।
यदि आपकी टीम पहचान-आधारित एंटरप्राइज WiFi को बनाए रखते हुए मैन्युअल PKI प्रशासन को कम करना चाहती है, तो Purple प्रबंधित सर्टिफिकेट-ग्रेड प्रमाणीकरण, डायरेक्टरी से जुड़े एक्सेस निर्णय, और RADIUS सेवाएं प्रदान कर सकता है जो निरस्तीकरण जांच का समर्थन करती हैं। यह आकलन करने के लिए कि इसका दृष्टिकोण आपके WiFi ऑफबोर्डिंग और सर्टिफिकेट लाइफसाइकल वर्कफ़्लो में कैसे फिट हो सकता है, Purple पर जाएं।
