मुख्य सामग्री पर जाएं
हिन्दी

WiFi ऑथेंटिकेशन के लिए OCSP और सर्टिफिकेट निरसन

यह व्यापक गाइड एंटरप्राइज WiFi वातावरण में सर्टिफिकेट निरसन के महत्वपूर्ण तंत्रों की खोज करती है, जिसमें CRLs से OCSP में संक्रमण पर ध्यान केंद्रित किया गया है। यह बड़े पैमाने पर, हाई-डेंसिटी नेटवर्क का प्रबंधन करने वाली IT टीमों के लिए व्यावहारिक कार्यान्वयन रणनीतियाँ प्रदान करती है जहाँ रियल-टाइम सुरक्षा और कम लेटेंसी सर्वोपरि हैं।

📖 6 मिनट का पाठ📝 1,701 शब्द🔧 2 हल किए गए उदाहरण❓ 3 अभ्यास प्रश्न📚 8 मुख्य परिभाषाएं

इस गाइड को सुनें

पॉडकास्ट ट्रांसक्रिप्ट देखें
Purple Technical Briefing में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एंटरप्राइज WiFi नेटवर्क के लिए एक महत्वपूर्ण सुरक्षा तंत्र में गहराई से जा रहे हैं: OCSP और सर्टिफिकेट निरसन। यदि आप एक IT मैनेजर, नेटवर्क आर्किटेक्ट, या CTO हैं जो हॉस्पिटैलिटी, रिटेल, या सार्वजनिक क्षेत्र के वातावरण में बड़े पैमाने पर डिप्लॉयमेंट का प्रबंधन कर रहे हैं, तो आप जानते हैं कि सर्टिफिकेट-आधारित ऑथेंटिकेशन—विशेष रूप से 802.1X पर EAP-TLS—नेटवर्क एक्सेस को सुरक्षित करने के लिए गोल्ड स्टैंडर्ड है। लेकिन क्या होता है जब कोई डिवाइस हैक हो जाता है, खो जाता है, या कोई कर्मचारी छोड़ देता है? आप यह कैसे सुनिश्चित करते हैं कि आपके नेटवर्क द्वारा एक निरस्त सर्टिफिकेट को तुरंत अस्वीकार कर दिया जाए? आज हम बिल्कुल इसी विषय को कवर कर रहे हैं। हम CRL और OCSP के बीच के अंतर को स्पष्ट करेंगे, समझाएंगे कि कैसे एक RADIUS सर्वर निरसन स्थिति की जांच करता है, WiFi के संदर्भ में OCSP स्टेपलिंग की अवधारणा का पता लगाएंगे, और व्यावहारिक कार्यान्वयन रणनीतियाँ प्रदान करेंगे। आइए बुनियादी बातों से शुरू करें: CRL बनाम OCSP। जब कोई डिवाइस सर्टिफिकेट का उपयोग करके आपके WiFi से कनेक्ट होता है, तो RADIUS सर्वर को यह सत्यापित करने की आवश्यकता होती है कि सर्टिफिकेट न केवल गणितीय रूप से वैध और समाप्त न हुआ हो, बल्कि इसे Certificate Authority, या CA द्वारा स्पष्ट रूप से निरस्त भी न किया गया हो। ऐतिहासिक रूप से, यह Certificate Revocation List, या CRL का उपयोग करके किया जाता था। एक CRL बिल्कुल वैसा ही है जैसा इसका नाम है: एक बड़ी फ़ाइल जिसमें प्रत्येक निरस्त सर्टिफिकेट के सीरियल नंबर होते हैं। RADIUS सर्वर इस सूची को समय-समय पर डाउनलोड करता है—शायद दिन में एक बार, या हर कुछ घंटों में। आधुनिक, हाई-डेंसिटी वातावरण में CRLs के साथ समस्या दोहरी है: लेटेंसी और बैंडविड्थ। यदि आपके पास एक बड़ा PKI डिप्लॉयमेंट है, तो वह सूची बहुत बड़ी हो जाती है। इसे डाउनलोड करने में बैंडविड्थ लगती है, और इसे पार्स करने में आपके RADIUS सर्वर पर CPU साइकिल खर्च होते हैं। इससे भी बदतर, एक भेद्यता विंडो होती है। यदि कोई डिवाइस सुबह 9 बजे हैक हो जाता है, लेकिन आपका RADIUS सर्वर दोपहर तक नया CRL नहीं खींचता है, तो उस हैक किए गए डिवाइस के पास आपके नेटवर्क तक तीन घंटे की निर्बाध पहुंच होती है। यहाँ प्रवेश होता है OCSP का: Online Certificate Status Protocol। OCSP एक रियल-टाइम, लक्षित क्वेरी है। प्रत्येक निरस्त सर्टिफिकेट की एक विशाल सूची डाउनलोड करने के बजाय, RADIUS सर्वर केवल CA के OCSP रिस्पॉन्डर से पूछता है: "अरे, क्या यह विशिष्ट सर्टिफिकेट सीरियल नंबर अभी वैध है?" रिस्पॉन्डर एक हस्ताक्षरित संदेश के साथ उत्तर देता है: "Good," "Revoked," या "Unknown।" यह RADIUS सर्वर पर बैंडविड्थ और प्रोसेसिंग ओवरहेड को काफी कम कर देता है। इससे भी महत्वपूर्ण बात यह है कि यह भेद्यता विंडो को बंद कर देता है। निरसन तुरंत लागू किए जाते हैं। तो, यह WiFi ऑथेंटिकेशन फ्लो में कैसे काम करता है? जब कोई क्लाइंट डिवाइस—मान लीजिए एक कॉर्पोरेट लैपटॉप—WiFi से कनेक्ट करने का प्रयास करता है, तो यह वायरलेस एक्सेस पॉइंट के साथ संचार करता है। AP एक ऑथेंटिकेटर के रूप में कार्य करता है, जो EAP-TLS संदेशों को RADIUS सर्वर पर पास करता है। लैपटॉप अपना क्लाइंट सर्टिफिकेट प्रस्तुत करता है। RADIUS सर्वर अपने विश्वसनीय रूट CA के विरुद्ध क्रिप्टोग्राफिक हस्ताक्षर को मान्य करता है। फिर, RADIUS सर्वर ऑथेंटिकेशन प्रक्रिया को रोकता है। यह क्लाइंट के सर्टिफिकेट में एम्बेडेड OCSP रिस्पॉन्डर URI तक नेटवर्क पर पहुंचता है। यह प्रतिक्रिया की प्रतीक्षा करता है। यदि प्रतिक्रिया "Good" है, तो RADIUS सर्वर AP को वापस एक Access-Accept संदेश भेजता है, और लैपटॉप ऑनलाइन हो जाता है। यदि प्रतिक्रिया "Revoked" है, तो यह एक Access-Reject भेजता है। अब, आप सोच रहे होंगे, "क्या इससे कनेक्शन प्रक्रिया में लेटेंसी नहीं बढ़ती?" हाँ, बढ़ती है। प्रत्येक ऑथेंटिकेशन के लिए एक बाहरी DNS लुकअप और OCSP रिस्पॉन्डर को एक HTTP अनुरोध की आवश्यकता होती है। एक व्यस्त स्टेडियम या पीक चेक-इन के दौरान एक बड़े होटल में, यह ऑथेंटिकेशन टाइमआउट का कारण बन सकता है। यह हमें एक महत्वपूर्ण अवधारणा पर लाता है: OCSP स्टेपलिंग। वेब सर्वर की दुनिया में, OCSP स्टेपलिंग आम है। वेब सर्वर समय-समय पर अपनी खुद की सर्टिफिकेट स्थिति के लिए OCSP रिस्पॉन्डर से क्वेरी करता है, एक टाइम-स्टैम्प वाली, हस्ताक्षरित प्रतिक्रिया प्राप्त करता है, और उस प्रतिक्रिया को उस सर्टिफिकेट के साथ "स्टेपल" करता है जिसे वह TLS हैंडशेक के दौरान क्लाइंट को भेजता है। क्लाइंट को CA से क्वेरी करने की आवश्यकता नहीं होती है; यह केवल स्टेपल की गई प्रतिक्रिया पर CA के हस्ताक्षर को सत्यापित करता है। क्या हम इसे WiFi के लिए कर सकते हैं? हाँ, लेकिन यह जटिल है। EAP-TLS में, RADIUS सर्वर क्लाइंट को एक सर्वर सर्टिफिकेट भी प्रस्तुत करता है, ताकि क्लाइंट को पता चले कि वह वैध नेटवर्क से बात कर रहा है न कि किसी नकली AP से। RADIUS सर्वर यहाँ OCSP स्टेपलिंग का उपयोग कर सकता है। यह अपनी स्थिति के लिए CA से क्वेरी करता है और प्रतिक्रिया को EAP-TLS Server Hello में स्टेपल करता है। यह क्लाइंट डिवाइस को RADIUS सर्वर के सर्टिफिकेट पर OCSP लुकअप करने से बचाता है। हालांकि, *क्लाइंट* के सर्टिफिकेट की स्थिति को स्टेपल करना अलग है। क्लाइंट अपनी स्थिति को स्टेपल नहीं कर सकता क्योंकि नेटवर्क अभी तक क्लाइंट पर भरोसा नहीं करता है। इसलिए, क्लाइंट सर्टिफिकेट सत्यापन के लिए, RADIUS सर्वर को अभी भी पारंपरिक OCSP क्वेरी करनी होगी। इन क्वेरीज़ की लेटेंसी को कम करने के लिए, एंटरप्राइज RADIUS सर्वर कैशिंग का उपयोग करते हैं। वे एक कॉन्फ़िगर करने योग्य समय के लिए—मान लीजिए, 15 मिनट या एक घंटे के लिए—एक "Good" OCSP प्रतिक्रिया को कैश करेंगे। इसका मतलब है कि बाद के रोम इवेंट्स या रीकनेक्ट्स एक नई बाहरी क्वेरी को ट्रिगर नहीं करते हैं, जिससे प्रदर्शन के साथ सुरक्षा संतुलित रहती है। आइए एक वास्तविक दुनिया के कार्यान्वयन परिदृश्य को देखें। कल्पना कीजिए कि एक बड़ी रिटेल चेन है जिसमें हजारों पॉइंट-ऑफ-सेल डिवाइस और कॉर्पोरेट लैपटॉप EAP-TLS के माध्यम से कनेक्ट हो रहे हैं। वे Purple के WiFi प्लेटफॉर्म को रोल आउट कर रहे हैं। उन्हें सख्त सुरक्षा की आवश्यकता है, लेकिन वे ऑथेंटिकेशन के दौरान POS उपकरणों के टाइम आउट होने का जोखिम नहीं उठा सकते। यहाँ अनुशंसित दृष्टिकोण है: सबसे पहले, सुनिश्चित करें कि आपका CA इन्फ्रास्ट्रक्चर मजबूत है। आपके OCSP रिस्पॉन्डर्स अत्यधिक उपलब्ध होने चाहिए, आदर्श रूप से एक लोड बैलेंसर के पीछे, और भौगोलिक रूप से वितरित होने चाहिए। यदि आपका RADIUS सर्वर OCSP रिस्पॉन्डर तक नहीं पहुंच सकता है, तो उसे यह तय करना होगा कि "फेल ओपन" (कनेक्शन की अनुमति दें) करना है या "फेल क्लोज्ड" (कनेक्शन से इनकार करें) करना है। उच्च-सुरक्षा वातावरण में, आप फेल क्लोज्ड करते हैं। लेकिन यदि आपका OCSP रिस्पॉन्डर डाउन हो जाता है, तो कोई भी WiFi पर नहीं आ पाएगा। दूसरा, अपने RADIUS सर्वरों पर OCSP कैशिंग कॉन्फ़िगर करें। 30-minute का कैश एक अच्छा मध्यम मार्ग है। यह आपके CA पर लोड को काफी कम करता है और ऑथेंटिकेशन को गति देता है, जबकि निरसन विंडो को उचित रूप से छोटा रखता है। तीसरा, एक फ़ॉलबैक तंत्र लागू करें। अपने RADIUS सर्वर को पहले OCSP का प्रयास करने के लिए कॉन्फ़िगर करें। यदि OCSP रिस्पॉन्डर पहुंच से बाहर है, तो स्थानीय रूप से कैश किए गए CRL पर वापस आ जाएं। यह CA आउटेज के खिलाफ लचीलापन प्रदान करता है। अंत में, सर्टिफिकेट की समाप्ति (expiration) के प्रभाव पर विचार करें। समाप्ति निरसन नहीं है। एक सर्टिफिकेट केवल अपनी "Not After" तिथि तक पहुंचता है। आपका RADIUS सर्वर OCSP या CRL की जांच करने की आवश्यकता के बिना इसे स्वचालित रूप से अस्वीकार कर देगा। यहाँ परिचालन चुनौती लाइफसाइकिल प्रबंधन है—यह सुनिश्चित करना कि सर्टिफिकेट समाप्त होने से *पहले* नवीनीकृत किए जाएं और उपकरणों पर डिप्लॉय किए जाएं। आइए सामान्य क्लाइंट प्रश्नों के आधार पर एक त्वरित रैपिड-फायर Q&A पर चलते हैं। प्रश्न 1: "हम सर्टिफिकेट पुश करने के लिए क्लाउड-आधारित MDM का उपयोग करते हैं। क्या हमें अभी भी OCSP की आवश्यकता है?" उत्तर: बिल्कुल। आपका MDM सर्टिफिकेट जारी करता है, लेकिन RADIUS सर्वर नेटवर्क एक्सेस लागू करता है। यदि आप अपने MDM में किसी डिवाइस को वाइप करते हैं, तो MDM सर्टिफिकेट को निरस्त करने के लिए CA को बताता है। लेकिन जब तक RADIUS सर्वर OCSP के माध्यम से उस निरसन स्थिति की जांच नहीं करता, तब तक डिवाइस अभी भी WiFi से कनेक्ट हो सकता है। प्रश्न 2: "यदि हम किसी डिवाइस का सर्टिफिकेट निरस्त करते समय वह ऑफ़लाइन हो तो क्या होगा?" उत्तर: इससे कोई फर्क नहीं पड़ता कि डिवाइस ऑफ़लाइन है। निरसन CA स्तर पर होता है। अगली बार जब वह डिवाइस WiFi से कनेक्ट करने का प्रयास करेगा, तो RADIUS सर्वर OCSP की जांच करेगा, "Revoked" स्थिति देखेगा, और एक्सेस से इनकार कर देगा। प्रश्न 3: "Is OCSP traffic encrypted?" उत्तर: ऐतिहासिक रूप से, OCSP अनुरोधों को प्लेन HTTP पर भेजा जाता था। इसे स्वीकार्य माना जाता था क्योंकि प्रतिक्रिया स्वयं CA द्वारा क्रिप्टोग्राफिक रूप से हस्ताक्षरित होती है, जिससे छेड़छाड़ को रोका जा सकता है। हालांकि, आधुनिक कार्यान्वयन गोपनीयता की रक्षा करने के लिए तेजी से HTTPS का उपयोग कर रहे हैं, जिससे निरीक्षकों को यह देखने से रोका जा सके कि किन सर्टिफिकेट की जांच की जा रही है। संक्षेप में और अगले चरणों की रूपरेखा तैयार करने के लिए: सर्टिफिकेट निरसन एक सुरक्षित 802.1X डिप्लॉयमेंट का एक गैर-परक्राम्य (non-negotiable) घटक है। जबकि छोटे नेटवर्क के लिए CRLs स्वीकार्य हैं, एंटरप्राइज स्केल के लिए OCSP आवश्यक है, जो रियल-टाइम सुरक्षा और कम बैंडविड्थ ओवरहेड प्रदान करता है। आपके अगले चरणों के लिए: 1. अपने वर्तमान RADIUS कॉन्फ़िगरेशन का ऑडिट करें। क्या आप निरसन स्थिति की बिल्कुल भी जांच कर रहे हैं? 2. यदि आप CRLs का उपयोग कर रहे हैं, तो अपनी सूची के आकार और अपनी डाउनलोड आवृत्ति का मूल्यांकन करें। 3. OCSP पर माइग्रेशन की योजना बनाएं। सुनिश्चित करें कि आपका CA इन्फ्रास्ट्रक्चर क्वेरी लोड को संभाल सकता है, और प्रदर्शन को ऑप्टिमाइज़ करने के लिए अपने RADIUS सर्वरों पर समझदारी से कैशिंग कॉन्फ़िगर करें। मजबूत OCSP चेकिंग लागू करके, आप यह सुनिश्चित करते हैं कि आपका Purple WiFi डिप्लॉयमेंट सुरक्षित, अनुपालनशील और प्रदर्शनकारी बना रहे, जिससे आपको इस बात पर पूर्ण नियंत्रण मिलता है कि कौन—और क्या—आपके नेटवर्क तक पहुँच सकता है। इस Purple Technical Briefing को सुनने के लिए धन्यवाद।

📚 हमारी मुख्य श्रृंखला का हिस्सा: Enterprise WiFi Security Guide →

header_image.png

कार्यकारी सारांश

हाई-डेंसिटी WiFi नेटवर्क संचालित करने वाले एंटरप्राइज परिसरों के लिए—विस्तृत रिटेल चेन से लेकर आधुनिक कॉन्फ्रेंस सेंटरों तक—सर्टिफिकेट-आधारित ऑथेंटिकेशन (EAP-TLS) नेटवर्क एक्सेस को सुरक्षित करने का निश्चित मानक है। हालांकि, सर्टिफिकेट जारी करना लाइफसाइकिल का केवल आधा हिस्सा है। महत्वपूर्ण परिचालन चुनौती निरसन (revocation) में है: यह सुनिश्चित करना कि जब कोई डिवाइस हैक हो जाए, खो जाए, या सेवा से बाहर हो जाए, तो उसका नेटवर्क एक्सेस तुरंत समाप्त कर दिया जाए। यह गाइड सर्टिफिकेट निरसन के तकनीकी आर्किटेक्चर की खोज करती है, जिसमें पुराने Certificate Revocation Lists (CRLs) की तुलना Online Certificate Status Protocol (OCSP) से की गई है। हम विस्तार से बताते हैं कि कैसे RADIUS सर्वर रियल-टाइम निरसन को लागू करने के लिए Public Key Infrastructure (PKI) के साथ एकीकृत होते हैं, 802.1X के संदर्भ में OCSP स्टेपलिंग की जटिलताएं क्या हैं, और कड़ी सुरक्षा के साथ सहज उपयोगकर्ता अनुभव को संतुलित करने के लिए आवश्यक रणनीतिक डिप्लॉयमेंट मॉडल क्या हैं। मजबूत OCSP चेकिंग लागू करके, परिसर संचालक जोखिम को कम कर सकते हैं, अनुपालन सुनिश्चित कर सकते हैं, और Guest WiFi और एंटरप्राइज एक्सेस के लिए आवश्यक हाई थ्रूपुट बनाए रख सकते हैं।

इस विषय पर हमारा 10 मिनट का कार्यकारी विवरण सुनें:

तकनीकी गहन विश्लेषण

802.1X में निरसन की कार्यप्रणाली

एक 802.1X ऑथेंटिकेशन फ्लो में, वायरलेस एक्सेस पॉइंट (AP) एक ऑथेंटिकेटर के रूप में कार्य करता है, जो क्लाइंट डिवाइस (सप्लीकेंट) और RADIUS सर्वर के बीच Extensible Authentication Protocol (EAP) संदेशों को पास करता है। जब कोई क्लाइंट EAP-TLS हैंडशेक के दौरान सर्टिफिकेट प्रस्तुत करता है, तो RADIUS सर्वर को इसकी क्रिप्टोग्राफिक अखंडता को मान्य करना होगा, इसकी ट्रस्ट चेन को सत्यापित करना होगा, और इसकी वर्तमान निरसन स्थिति की पुष्टि करनी होगी।

ऐतिहासिक रूप से, इसे Certificate Revocation List (CRL) के माध्यम से प्राप्त किया जाता था। एक CRL एक डिजिटल रूप से हस्ताक्षरित फ़ाइल होती है जिसमें एक विशिष्ट Certificate Authority (CA) द्वारा जारी किए गए सभी निरस्त सर्टिफिकेट के सीरियल नंबर होते हैं। RADIUS सर्वर इस फ़ाइल को समय-समय पर डाउनलोड करता है और इसे स्थानीय रूप से कैश करता है। हालांकि लागू करना सरल है, CRLs महत्वपूर्ण स्केलेबिलिटी चुनौतियां पेश करते हैं। Retail क्षेत्र जैसे बड़े एंटरप्राइज वातावरणों में, CRLs का आकार मेगाबाइट तक बढ़ सकता है। इन सूचियों को डाउनलोड और पार्स करने में बैंडविड्थ और प्रोसेसिंग साइकिल की खपत होती है। इससे भी अधिक महत्वपूर्ण बात यह है कि CRLs एक भेद्यता विंडो (vulnerability window) पेश करते हैं: CA पर सर्टिफिकेट निरस्त होने और RADIUS सर्वर द्वारा अपडेट की गई सूची डाउनलोड करने के बीच का समय।

OCSP की ओर संक्रमण

CRLs की सीमाओं को दूर करने के लिए, Online Certificate Status Protocol (OCSP) विकसित किया गया था। OCSP बल्क डाउनलोड मॉडल को रियल-टाइम, लक्षित क्वेरी तंत्र से बदल देता है। जब कोई क्लाइंट सर्टिफिकेट प्रस्तुत करता है, तो RADIUS सर्वर सर्टिफिकेट के Authority Information Access (AIA) एक्सटेंशन से OCSP रिस्पॉन्डर URI निकालता है। इसके बाद यह रिस्पॉन्डर को एक लाइटवेट HTTP अनुरोध भेजता है, जिसमें उस विशिष्ट सर्टिफिकेट सीरियल नंबर की स्थिति के बारे में पूछा जाता है। रिस्पॉन्डर एक हस्ताक्षरित प्रतिक्रिया लौटाता है जो दर्शाती है कि सर्टिफिकेट 'Good' (अच्छा), 'Revoked' (निरस्त), या 'Unknown' (अज्ञात) है।

यह दृष्टिकोण CRLs से जुड़ी भेद्यता विंडो को समाप्त करता है, जिससे निरसन तुरंत लागू होते हैं। यह बैंडविड्थ की खपत को भी काफी कम करता है, क्योंकि RADIUS सर्वर केवल उन सर्टिफिकेट के लिए डेटा का अनुरोध करता है जो सक्रिय रूप से ऑथेंटिकेशन का प्रयास कर रहे हैं।

crl_vs_ocsp_comparison.png

WiFi वातावरण में OCSP स्टेपलिंग

OCSP स्टेपलिंग एक परफॉर्मेंस ऑप्टिमाइज़ेशन तकनीक है जिसका व्यापक रूप से वेब सर्वरों में उपयोग किया जाता है। क्लाइंट द्वारा OCSP रिस्पॉन्डर से क्वेरी करने के बजाय, सर्वर समय-समय पर अपनी खुद की सर्टिफिकेट स्थिति के लिए रिस्पॉन्डर से क्वेरी करता है। इसके बाद यह हस्ताक्षरित प्रतिक्रिया को उस सर्टिफिकेट के साथ 'स्टेपल' (नत्थी) कर देता है जिसे वह TLS हैंडशेक के दौरान क्लाइंट के सामने प्रस्तुत करता है। यह क्वेरी के बोझ को क्लाइंट से सर्वर पर स्थानांतरित करता है और आवश्यक बाहरी नेटवर्क कनेक्शनों की संख्या को कम करता है।

WiFi ऑथेंटिकेशन के संदर्भ में, OCSP स्टेपलिंग अत्यधिक प्रासंगिक लेकिन सूक्ष्म है। EAP-TLS के दौरान, RADIUS सर्वर अपनी पहचान साबित करने के लिए क्लाइंट को अपना सर्वर सर्टिफिकेट प्रस्तुत करता है। RADIUS सर्वर यहाँ OCSP स्टेपलिंग का उपयोग कर सकता है, और EAP-TLS Server Hello में OCSP प्रतिक्रिया जोड़ सकता है। यह क्लाइंट डिवाइस को अपने स्वयं के इंटरनेट कनेक्शन की आवश्यकता के बिना RADIUS सर्वर की निरसन स्थिति को सत्यापित करने की अनुमति देता है—यह उन उपकरणों के लिए एक महत्वपूर्ण विशेषता है जिन्हें अभी तक नेटवर्क एक्सेस नहीं दिया गया है।

हालांकि, क्लाइंट के सर्टिफिकेट की स्थिति को स्टेपल करना व्यावहारिक नहीं है। क्लाइंट अपनी स्थिति को स्टेपल नहीं कर सकता क्योंकि नेटवर्क अभी तक क्लाइंट पर भरोसा नहीं करता है। इसलिए, क्लाइंट सर्टिफिकेट सत्यापन के लिए, RADIUS सर्वर को CA को एक पारंपरिक OCSP क्वेरी करनी होगी।

ocsp_stapling_architecture.png

कार्यान्वयन गाइड

हाई-डेंसिटी एंटरप्राइज वातावरण में OCSP को डिप्लॉय करने के लिए सुरक्षा और उपलब्धता दोनों सुनिश्चित करने के लिए सावधानीपूर्वक आर्किटेक्चरल योजना की आवश्यकता होती है। निम्नलिखित चरण एक मजबूत डिप्लॉयमेंट रणनीति की रूपरेखा तैयार करते हैं।

1. हाई-अवेलेबिलिटी CA इन्फ्रास्ट्रक्चर

OCSP पर स्विच करने से CA के रिस्पॉन्डर इन्फ्रास्ट्रक्चर पर एक महत्वपूर्ण निर्भरता पैदा होती है। यदि RADIUS सर्वर OCSP रिस्पॉन्डर तक नहीं पहुंच पाता है, तो वह निश्चित रूप से सर्टिफिकेट की स्थिति को सत्यापित नहीं कर सकता है। इसलिए, किसी बड़े कॉन्फ्रेंस या खेल आयोजन के दौरान होने वाले ऑथेंटिकेशन स्पाइक्स को संभालने के लिए OCSP रिस्पॉन्डर अत्यधिक उपलब्ध, भौगोलिक रूप से वितरित और लोड बैलेंसर्स के पीछे होना चाहिए।

2. RADIUS सर्वर कॉन्फ़िगरेशन और कैशिंग

रियल-टाइम OCSP क्वेरीज़ द्वारा उत्पन्न लेटेंसी को कम करने के लिए, एंटरप्राइज RADIUS सर्वरों को इंटेलिजेंट कैशिंग तंत्र के साथ कॉन्फ़िगर किया जाना चाहिए। जब एक RADIUS सर्वर को OCSP रिस्पॉन्डर से 'Good' प्रतिक्रिया प्राप्त होती है, तो उसे उस प्रतिक्रिया को एक कॉन्फ़िगर करने योग्य अवधि के लिए कैश करना चाहिए—आमतौर पर 15 से 60 मिनट के बीच। उस विंडो के भीतर उसी क्लाइंट से आने वाले बाद के ऑथेंटिकेशन अनुरोधों को कैश के विरुद्ध सत्यापित किया जाएगा, जिससे बाहरी क्वेरी की आवश्यकता नहीं होगी। यह व्यस्त नेटवर्क की प्रदर्शन आवश्यकताओं के साथ रियल-टाइम सुरक्षा की आवश्यकता को संतुलित करता है।

3. फेलओवर और लचीलापन तंत्र

नेटवर्क आर्किटेक्ट्स को यह परिभाषित करना होगा कि OCSP रिस्पॉन्डर के पहुंच से बाहर होने की स्थिति में RADIUS सर्वर का व्यवहार कैसा होना चाहिए। इसे 'फेल ओपन' बनाम 'फेल क्लोज्ड' के रूप में जाना जाता है। 'फेल क्लोज्ड' कॉन्फ़िगरेशन में, यदि RADIUS सर्वर सर्टिफिकेट की स्थिति को सत्यापित नहीं कर सकता है, तो वह एक्सेस को अस्वीकार कर देगा। यह सबसे सुरक्षित स्थिति है लेकिन यदि CA इन्फ्रास्ट्रक्चर विफल हो जाता है तो व्यापक आउटेज का जोखिम रहता है। 'फेल ओपन' कॉन्फ़िगरेशन में, यदि रिस्पॉन्डर पहुंच से बाहर है, तो RADIUS सर्वर सख्त सुरक्षा पर उपलब्धता को प्राथमिकता देते हुए एक्सेस की अनुमति देगा।

एक अनुशंसित हाइब्रिड दृष्टिकोण में RADIUS सर्वर को पहले OCSP क्वेरी का प्रयास करने के लिए कॉन्फ़िगर करना शामिल है। यदि रिस्पॉन्डर पहुंच से बाहर है, तो सर्वर स्थानीय रूप से कैश किए गए CRL पर वापस आ जाता है। यह निरसन चेकिंग का एक बेसलाइन स्तर बनाए रखते हुए CA आउटेज के खिलाफ लचीलापन प्रदान करता है।

सर्वोत्तम प्रथाएं

  • सर्टिफिकेट लाइफस्पैन को कम करें: हालांकि निरसन समय से पहले अमान्य होने की स्थिति को संभालता है, लेकिन सबसे प्रभावी सुरक्षा नियंत्रण एक छोटा सर्टिफिकेट लाइफस्पैन है। वर्षों के बजाय दिनों या हफ्तों के लिए वैध सर्टिफिकेट जारी करने के लिए MDM के माध्यम से स्वचालित सर्टिफिकेट प्रोविजनिंग लागू करें। यह पूरी तरह से निरसन तंत्र पर निर्भरता को कम करता है। आधुनिक डिवाइस सुरक्षा पर आगे पढ़ने के लिए, हमारे गाइड 802.1X Authentication: Securing Network Access on Modern Devices को देखें।
  • OCSP लेटेंसी की निगरानी करें: अपने RADIUS सर्वरों से CA इन्फ्रास्ट्रक्चर तक OCSP क्वेरीज़ की लेटेंसी की लगातार निगरानी करें। उच्च लेटेंसी सीधे उपयोगकर्ता अनुभव को प्रभावित करेगी, जिससे ऑथेंटिकेशन टाइमआउट और कनेक्शन टूटने की समस्या होगी।
  • सख्त CA एक्सेस नियंत्रण लागू करें: आपके WiFi नेटवर्क की सुरक्षा आंतरिक रूप से आपके CA की सुरक्षा से जुड़ी हुई है। सुनिश्चित करें कि सभी CA प्रबंधन इंटरफेस के लिए सख्त एक्सेस नियंत्रण, मल्टी-फैक्टर ऑथेंटिकेशन और व्यापक ऑडिटिंग लागू हो।

समस्या निवारण और जोखिम न्यूनीकरण

OCSP को डिप्लॉय करते समय, IT टीमों को अक्सर कई सामान्य विफलता मोड का सामना करना पड़ता:

  • ऑथेंटिकेशन टाइमआउट: यदि OCSP रिस्पॉन्डर जवाब देने में धीमा है, तो EAP-TLS हैंडशेक टाइम आउट हो सकता है। यह अक्सर नेटवर्क कंजेशन या कम-प्रोविजन वाले CA इन्फ्रास्ट्रक्चर के कारण होता है। इसके समाधान में RADIUS सर्वर पर OCSP कैशिंग को ऑप्टिमाइज़ करना और रिस्पॉन्डर इन्फ्रास्ट्रक्चर को स्केल करना शामिल है।
  • क्लॉक स्क्यू (Clock Skew): OCSP प्रतिक्रियाएं टाइम-स्टैम्प और हस्ताक्षरित होती हैं। यदि RADIUS सर्वर पर घड़ी CA के साथ सिंक से बाहर है, तो सर्वर एक वैध OCSP प्रतिक्रिया को समाप्त (expired) मानकर अस्वीकार कर सकता है। सुनिश्चित करें कि सभी इन्फ्रास्ट्रक्चर घटक विश्वसनीय NTP सर्वरों के माध्यम से सिंक्रोनाइज़्ड हों।
  • फ़ायरवॉल ब्लॉकिंग: OCSP क्वेरीज़ आमतौर पर HTTP (पोर्ट 80) या HTTPS (पोर्ट 443) का उपयोग करती हैं। सुनिश्चित करें कि RADIUS सर्वर और CA इन्फ्रास्ट्रक्चर के बीच फ़ायरवॉल को इस ट्रैफ़िक की अनुमति देने के लिए कॉन्फ़िगर किया गया है। आधुनिक कार्यान्वयन गोपनीयता की रक्षा करने और नेटवर्क निरीक्षकों को सर्टिफिकेट क्वेरीज़ का विश्लेषण करने से रोकने के लिए तेजी से HTTPS का उपयोग कर रहे हैं।

ROI और व्यावसायिक प्रभाव

मजबूत सर्टिफिकेट निरसन तंत्र को लागू करना केवल सुरक्षा अनुपालन से परे मापने योग्य व्यावसायिक मूल्य प्रदान करता है।

  • जोखिम न्यूनीकरण: CRLs से जुड़ी भेद्यता विंडो को समाप्त करके, OCSP संवेदनशील कॉर्पोरेट संसाधनों तक पहुँचने वाले एक हैक किए गए डिवाइस के जोखिम को काफी कम कर देता है। यह बौद्धिक संपदा की रक्षा करता है और डेटा ब्रीच के वित्तीय और प्रतिष्ठित नुकसान को कम करता है।
  • परिचालन दक्षता: OCSP के माध्यम से निरसन जांच को स्वचालित करने से विशाल CRL फ़ाइलों के प्रबंधन से जुड़े प्रशासनिक ओवरहेड कम हो जाते हैं। IT टीमें CRL डाउनलोड विफलताओं के समस्या निवारण के बजाय रणनीतिक पहलों पर ध्यान केंद्रित कर सकती हैं।
  • अनुपालन सक्षमता: Healthcare या वित्त जैसे विनियमित उद्योगों में काम करने वाले परिसरों के लिए, सख्त एक्सेस नियंत्रण और रियल-टाइम निरसन अक्सर अनिवार्य अनुपालन आवश्यकताएं होती हैं (जैसे, HIPAA, PCI-DSS)। एक मजबूत OCSP डिप्लॉयमेंट निरंतर अनुपालन सुनिश्चित करता है और ऑडिट प्रक्रियाओं को सरल बनाता है।

मुख्य परिभाषाएं

OCSP (Online Certificate Status Protocol)

एक इंटरनेट प्रोटोकॉल जिसका उपयोग रियल-टाइम में X.509 डिजिटल सर्टिफिकेट की निरसन स्थिति प्राप्त करने के लिए किया जाता है।

RADIUS सर्वरों द्वारा तुरंत यह सत्यापित करने के लिए उपयोग किया जाता है कि क्या किसी डिवाइस का सर्टिफिकेट निरस्त कर दिया गया है, जिससे पुराने CRLs से जुड़ी भेद्यता विंडो बंद हो जाती है।

CRL (Certificate Revocation List)

सर्टिफिकेट सीरियल नंबरों की समय-समय पर अपडेट की जाने वाली, डिजिटल रूप से हस्ताक्षरित सूची जिन्हें जारीकर्ता Certificate Authority द्वारा निरस्त कर दिया गया है।

निरसन चेकिंग की पुरानी विधि। यह स्केलेबिलिटी की समस्याओं से ग्रस्त है और अपडेट के बीच एक भेद्यता विंडो पेश करती है।

OCSP Stapling

एक तंत्र जहाँ सर्टिफिकेट प्रस्तुतकर्ता (जैसे, एक RADIUS सर्वर) CA से एक टाइम-स्टैम्प वाली OCSP प्रतिक्रिया प्राप्त करता है और TLS हैंडशेक के दौरान इसे सर्टिफिकेट के साथ जोड़ता है।

क्लाइंट डिवाइस से OCSP क्वेरी के बोझ को कम करके प्रदर्शन और गोपनीयता में सुधार करने के लिए उपयोग किया जाता है।

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

एक अत्यधिक सुरक्षित 802.1X ऑथेंटिकेशन विधि जिसके लिए क्लाइंट और RADIUS सर्वर के बीच पारस्परिक सर्टिफिकेट-आधारित ऑथेंटिकेशन की आवश्यकता होती है।

एंटरप्राइज WiFi वातावरण में उपयोग किया जाने वाला मानक प्रोटोकॉल जिसके लिए मजबूत सर्टिफिकेट निरसन चेकिंग की आवश्यकता होती है।

Vulnerability Window

CA पर सर्टिफिकेट निरस्त होने और लागू करने वाले सिस्टम (जैसे, RADIUS सर्वर) को निरसन के बारे में पता चलने के बीच की समयावधि।

CRLs के बजाय OCSP को अपनाने का एक प्राथमिक कारण, क्योंकि OCSP प्रभावी रूप से इस विंडो को लगभग शून्य कर देता है।

Fail Open vs. Fail Closed

एक कॉन्फ़िगरेशन निर्णय जो सिस्टम के व्यवहार को निर्धारित करता है जब कोई निर्भरता (जैसे OCSP रिस्पॉन्डर) पहुंच से बाहर हो। 'Fail open' एक्सेस की अनुमति देता है; 'fail closed' एक्सेस से इनकार करता है।

सख्त सुरक्षा अनुपालन के खिलाफ नेटवर्क उपलब्धता को संतुलित करने वाली IT टीमों के लिए एक महत्वपूर्ण आर्किटेक्चरल निर्णय।

AIA (Authority Information Access)

एक X.509 सर्टिफिकेट के भीतर एक एक्सटेंशन जो यह दर्शाता है कि सर्टिफिकेट के जारीकर्ता के लिए जानकारी और सेवाओं तक कैसे पहुंचा जाए, जिसमें OCSP रिस्पॉन्डर URI भी शामिल है।

RADIUS सर्वर किसी विशिष्ट क्लाइंट सर्टिफिकेट के लिए OCSP क्वेरी को ठीक कहाँ भेजना है, यह निर्धारित करने के लिए इस एक्सटेंशन को पढ़ता है।

Supplicant

किसी डिवाइस (जैसे, लैपटॉप या स्मार्टफोन) पर सॉफ्टवेयर क्लाइंट जो नेटवर्क तक पहुंचने का प्रयास करता है और ऑथेंटिकेशन अनुरोधों का जवाब देता है।

क्लाइंट सर्टिफिकेट प्रस्तुत करने वाली इकाई जिसे RADIUS सर्वर को OCSP रिस्पॉन्डर के विरुद्ध सत्यापित करना होगा।

हल किए गए उदाहरण

[Hospitality](/industries/hospitality) क्षेत्र में एक 500 कमरों वाला लक्जरी होटल कर्मचारियों के उपकरणों के लिए EAP-TLS का उपयोग करने के लिए अपने बैक-ऑफ-हाउस WiFi नेटवर्क को अपग्रेड कर रहा है। वे वर्तमान में अपने कॉर्पोरेट डेटा सेंटर में एक केंद्रीकृत RADIUS सर्वर का उपयोग करते हैं, जो SD-WAN के माध्यम से जुड़ा हुआ है। वे चिंतित हैं कि उनके क्लाउड-आधारित CA के लिए रियल-टाइम OCSP क्वेरीज़ शिफ्ट परिवर्तन के दौरान ऑथेंटिकेशन टाइमआउट का कारण बनेंगी जब सैकड़ों कर्मचारी एक साथ कनेक्ट होते हैं।

कार्यान्वयन में सुरक्षा से समझौता किए बिना कम-लेटेंसी ऑथेंटिकेशन को प्राथमिकता दी जानी चाहिए। समाधान में तीन चरण शामिल हैं: 1) प्रारंभिक EAP टर्मिनेशन को संभालने के लिए होटल की संपत्ति पर एक स्थानीयकृत RADIUS प्रॉक्सी डिप्लॉय करें। 2) OCSP क्वेरीज़ करने और 'Good' प्रतिक्रियाओं को 60 मिनट के लिए कैश करने के लिए RADIUS प्रॉक्सी को कॉन्फ़िगर करें। 3) एक फ़ॉलबैक तंत्र लागू करें जहाँ क्लाउड CA के लिए SD-WAN लिंक विफल होने पर RADIUS प्रॉक्सी स्थानीय रूप से डाउनलोड किए गए, दैनिक CRL पर निर्भर करता है।

परीक्षक की टिप्पणी: यह दृष्टिकोण लेटेंसी के जोखिम को प्रभावी ढंग से कम करता है। एज पर स्थानीय रूप से OCSP प्रतिक्रियाओं को कैश करके, होटल शिफ्ट परिवर्तन के दौरान WAN पर एक साथ सैकड़ों क्वेरीज़ भेजने से बचता है। 60 मिनट की कैश विंडो एक व्यावहारिक समझौता है, जो उच्च उपलब्धता सुनिश्चित करते हुए भेद्यता विंडो को छोटा रखती है। CRL फ़ॉलबैक WAN आउटेज के खिलाफ महत्वपूर्ण लचीलापन प्रदान करता है, यह सुनिश्चित करता है कि क्लाउड CA अस्थायी रूप से पहुंच से बाहर होने पर भी कर्मचारी ऑथेंटिकेट कर सकें। यह आर्किटेक्चर हमारे लेख [The Core SD WAN Benefits for Modern Businesses](/blog/sd-wan-benefits) में चर्चा किए गए सिद्धांतों के अनुरूप है।

एक बड़ा सार्वजनिक क्षेत्र का संगठन कई नगरपालिका भवनों में [Sensors](/products/sensors) डिप्लॉय कर रहा है। ये IoT डिवाइस 5 साल के लाइफस्पैन वाले सर्टिफिकेट का उपयोग करके 802.1X के माध्यम से ऑथेंटिकेट करते हैं। IT सुरक्षा टीम को सेंसर चोरी होने की रिपोर्ट मिलने पर तुरंत नेटवर्क डिस्कनेक्शन की आवश्यकता होती है।

लंबे सर्टिफिकेट लाइफस्पैन को देखते हुए, मजबूत निरसन महत्वपूर्ण है। संगठन को सेंसर VLAN से प्रत्येक ऑथेंटिकेशन अनुरोध के लिए अनिवार्य OCSP क्वेरीज़ करने के लिए अपने RADIUS सर्वरों को कॉन्फ़िगर करना होगा। कैशिंग को अक्षम किया जाना चाहिए या बहुत कम अवधि (जैसे, 5 मिनट) पर सेट किया जाना चाहिए। RADIUS सर्वरों को 'फेल क्लोज्ड' के लिए कॉन्फ़िगर किया जाना चाहिए—यदि OCSP रिस्पॉन्डर पहुंच से बाहर है, तो सेंसर को एक्सेस से वंचित कर दिया जाता है।

परीक्षक की टिप्पणी: हालांकि लंबे समय तक चलने वाले सर्टिफिकेट को आम तौर पर हतोत्साहित किया जाता है, लेकिन स्वचालित नवीनीकरण की कठिनाई के कारण वे IoT डिप्लॉयमेंट में आम हैं। इस परिदृश्य में, OCSP एकमात्र प्रभावी सुरक्षा नियंत्रण है। कैशिंग को अक्षम करना यह सुनिश्चित करता है कि अगले ऑथेंटिकेशन प्रयास पर एक निरस्त सर्टिफिकेट को लगभग तुरंत अस्वीकार कर दिया जाए। 'फेल क्लोज्ड' कॉन्फ़िगरेशन उपलब्धता पर सुरक्षा को प्राथमिकता देता है, जो एक हैक किए गए भौतिक सेंसर द्वारा नगरपालिका नेटवर्क में सेंध लगाने के जोखिम को देखते हुए उपयुक्त है।

अभ्यास प्रश्न

Q1. आपका संगठन आपके कॉर्पोरेट WiFi के लिए दैनिक CRL डाउनलोड से रियल-टाइम OCSP चेकिंग पर माइग्रेट कर रहा है। पायलट चरण के दौरान, आप ऑथेंटिकेशन टाइमआउट में महत्वपूर्ण वृद्धि देखते हैं, विशेष रूप से इमारतों के बीच रोमिंग करने वाले उपयोगकर्ताओं के लिए। इसका सबसे संभावित कारण और अनुशंसित समाधान क्या है?

संकेत: EAP-TLS हैंडशेक के दौरान बाहरी नेटवर्क क्वेरीज़ द्वारा उत्पन्न लेटेंसी पर विचार करें।

मॉडल उत्तर देखें

टाइमआउट संभवतः रोमिंग के दौरान फास्ट रीकनेक्ट सहित प्रत्येक ऑथेंटिकेशन इवेंट के लिए OCSP रिस्पॉन्डर को बाहरी HTTP क्वेरी करने की लेटेंसी के कारण होते हैं। अनुशंसित समाधान RADIUS सर्वर पर OCSP कैशिंग को कॉन्फ़िगर करना है। एक अवधि (जैसे, 30 मिनट) के लिए 'Good' प्रतिक्रियाओं को कैश करके, बाद के रोम इवेंट्स को कैश के विरुद्ध स्थानीय रूप से सत्यापित किया जाएगा, जिससे बाहरी क्वेरी लेटेंसी समाप्त हो जाएगी और टाइमआउट को रोका जा सकेगा।

Q2. एक महत्वपूर्ण सुरक्षा ऑडिट के लिए आवश्यक है कि MDM प्लेटफॉर्म में सर्टिफिकेट निरस्त होने के बाद कोई भी हैक किया गया डिवाइस 5 मिनट से अधिक समय तक नेटवर्क तक नहीं पहुंच सके। आपका RADIUS सर्वर 60 मिनट के कैश के साथ OCSP का उपयोग करने के लिए कॉन्फ़िगर किया गया है। क्या यह कॉन्फ़िगरेशन ऑडिट आवश्यकता को पूरा करता है?

संकेत: कैश अवधि और भेद्यता विंडो के बीच संबंध का विश्लेषण करें।

मॉडल उत्तर देखें

नहीं, यह कॉन्फ़िगरेशन ऑडिट आवश्यकता को पूरा करने में विफल रहता है। 60 मिनट का कैश एक घंटे तक की भेद्यता विंडो बनाता है। यदि कोई डिवाइस ऑथेंटिकेट करता है और उसकी 'Good' स्थिति कैश हो जाती है, और सर्टिफिकेट 1 मिनट बाद निरस्त कर दिया जाता है, तो RADIUS सर्वर कैश की गई प्रतिक्रिया के आधार पर शेष 59 मिनट के लिए एक्सेस की अनुमति देना जारी रखेगा। 5 मिनट की आवश्यकता को पूरा करने के लिए, OCSP कैश अवधि को 5 मिनट या उससे कम किया जाना चाहिए, हालांकि इससे CA इन्फ्रास्ट्रक्चर पर क्वेरी लोड बढ़ जाएगा।

Q3. एक बड़े ISP आउटेज के दौरान, आपका क्लाउड-आधारित OCSP रिस्पॉन्डर पहुंच से बाहर हो जाता है। आपका RADIUS सर्वर 'फेल क्लोज्ड' नीति के साथ OCSP चेकिंग के लिए कॉन्फ़िगर किया गया है। नेटवर्क पर इसका क्या प्रभाव पड़ेगा, और लचीलेपन के लिए आर्किटेक्चर में कैसे सुधार किया जा सकता है?

संकेत: जब कोई महत्वपूर्ण निर्भरता अनुपलब्ध हो तो 'फेल क्लोज्ड' के निहितार्थों पर विचार करें।

मॉडल उत्तर देखें

इसका प्रभाव सभी नए WiFi ऑथेंटिकेशन के लिए पूर्ण आउटेज होगा। चूंकि RADIUS सर्वर रिस्पॉन्डर तक नहीं पहुंच सकता है और इसे 'फेल क्लोज्ड' के लिए कॉन्फ़िगर किया गया है, इसलिए यह सभी एक्सेस अनुरोधों को अस्वीकार कर देगा। लचीलेपन में सुधार करने के लिए, आर्किटेक्चर को एक फ़ॉलबैक तंत्र लागू करना चाहिए। RADIUS सर्वर को पहले OCSP का प्रयास करने के लिए कॉन्फ़िगर किया जाना चाहिए, और यदि पहुंच से बाहर हो, तो स्थानीय रूप से कैश किए गए CRL पर वापस आ जाना चाहिए। यह ISP आउटेज के दौरान अंतिम ज्ञात अच्छी निरसन स्थिति का उपयोग करके ऑथेंटिकेशन को आगे बढ़ने की अनुमति देता है।

इस श्रृंखला में आगे पढ़ें

स्टाफ और गेस्ट WiFi नेटवर्क को सुरक्षित रूप से कैसे अलग करें

यह आधिकारिक तकनीकी मार्गदर्शिका IT लीडर्स को VLANs और 802.1X का उपयोग करके स्टाफ, गेस्ट और IoT WiFi नेटवर्क को सुरक्षित रूप से अलग करने के लिए व्यावहारिक रणनीतियाँ प्रदान करती है। यह विवरण देती है कि एंटरप्राइज़ बुनियादी ढांचे को कैसे सुरक्षित किया जाए, PCI DSS अनुपालन कैसे बनाए रखा जाए, और फर्स्ट-पार्टी डेटा कैप्चर करने के लिए कैप्टिव पोर्टल्स का लाभ कैसे उठाया जाए.

गाइड पढ़ें →

सर्वश्रेष्ठ DNS फ़िल्टरिंग: व्यवसायों के लिए एक व्यापक गाइड

यह तकनीकी संदर्भ गाइड बताती है कि कैसे उद्यम DNS फ़िल्टरिंग रिज़ॉल्यूशन परत पर दुर्भावनापूर्ण डोमेन को ब्लॉक करके सार्वजनिक नेटवर्क को सुरक्षित करती है - इससे पहले कि कोई कनेक्शन स्थापित हो। यह IT निदेशकों, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशंस टीमों को परिनियोजन आर्किटेक्चर, फ़ायरवॉल कॉन्फ़िगरेशन और अनुपालन संदर्भ प्रदान करता है जिसकी उन्हें हॉस्पिटैलिटी, रिटेल और सार्वजनिक क्षेत्र के वातावरण में Guest WiFi की सुरक्षा के लिए आवश्यकता होती है। Purple Shield 80,000 से अधिक लाइव वेन्यू में DNS स्तर पर मैलवेयर, बॉटनेट और अनुपयुक्त सामग्री को ब्लॉक करता है।

गाइड पढ़ें →

Cisco SUDI को समझना: सुरक्षित नेटवर्क एक्सेस कंट्रोल में हार्डवेयर-एंकर वाली पहचान

यह गाइड बताती है कि Cisco SUDI एंटरप्राइज़ नेटवर्क इंफ्रास्ट्रक्चर के लिए हार्डवेयर-एंकर वाली, क्रिप्टोग्राफ़िक रूप से सुरक्षित पहचान कैसे प्रदान करता है। सीखें कि अपने स्थान के नेटवर्क एक्सेस कंट्रोल को सुरक्षित करने के लिए स्पूफ़ किए जा सकने वाले MAC पते को अपरिवर्तनीय 802.1AR प्रमाणपत्रों से कैसे बदलें।

गाइड पढ़ें →
WiFi ऑथेंटिकेशन के लिए OCSP और सर्टिफिकेट निरसन | तकनीकी गाइड्स | Purple