मुख्य मजकुराकडे जा

EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते प्रमाणपत्र-आधारित WiFi प्रोटोकॉल निवडले पाहिजे?

हे मार्गदर्शक IEEE 802.1X अंतर्गत एंटरप्राइझ WiFi प्रमाणीकरणासाठी EAP-TLS आणि EAP-TTLS ची थेट तुलना प्रदान करते. हे परस्पर प्रमाणपत्र प्रमाणीकरण आणि केवळ-सर्व्हर प्रमाणपत्र टनेलिंगमधील आर्किटेक्चरल फरक स्पष्ट करते, आणि आयटी व्यवस्थापक, नेटवर्क आर्किटेक्ट आणि CISOs यांना डिव्हाइस व्यवस्थापन क्षमता आणि अनुपालन आवश्यकतांवर आधारित स्पष्ट निर्णय फ्रेमवर्क देते. Purple हे Staff WiFi साठी EAP-TLS आणि EAP-TTLS या दोन्ही प्रमाणीकरण मार्गांना समर्थन देते, आणि हे मार्गदर्शक संस्थांना कोणत्याही दृष्टिकोनावर काम सुरू करण्यापूर्वी पायाभूत सुविधांमधील तडजोड समजून घेण्यास मदत करते.

Iain Jewitt द्वारेप्रकाशित
📖 9 मिनिट वाचन2,015 शब्द2 सोडवलेली उदाहरणे4 सराव प्रश्न10 महत्वाच्या व्याख्या

Video overview

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा
प्रस्तावना आणि संदर्भ (0:00 - 2:00) नमस्कार, आणि Purple च्या या तांत्रिक ब्रीफिंगमध्ये आपले स्वागत आहे. मी तुमचा होस्ट आहे, आणि आज आपण एंटरप्राइझ WiFi ऑथेंटिकेशनसाठी EAP-TLS आणि EAP-TTLS मधील महत्त्वपूर्ण फरक समजून घेणार आहोत. जर तुम्ही नेटवर्क आर्किटेक्ट, IT संचालक असाल किंवा रिटेल चेन्स, हॉस्पिटल्स किंवा स्टेडियम्स सारख्या मोठ्या ठिकाणांसाठी इन्फ्रास्ट्रक्चर व्यवस्थापित करत असाल, तर हे ब्रीफिंग विशेषतः तुमच्यासाठी डिझाइन केले आहे. आपण विषयाला थेट हात घालणार आहोत आणि सिक्युरिटी आर्किटेक्चर, इम्प्लीमेंटेशन तडजोडी आणि तुमच्या वातावरणासाठी योग्य प्रोटोकॉल कसा निवडावा यावर चर्चा करणार आहोत. चला थेट विषयाकडे वळूया. आपण प्रोटोकॉल्सचा सखोल अभ्यास करण्यापूर्वी, पार्श्वभूमी समजून घेऊया. आज बहुतांश एंटरप्राइझ WiFi डिप्लॉयमेंट्स अजूनही एकाच सामायिक पासवर्डवर - म्हणजेच Pre-Shared Key, किंवा PSK वर अवलंबून आहेत. नेटवर्कवरील प्रत्येक डिव्हाइस एकच क्रेडेंशियल वापरते. जेव्हा एखादा कर्मचारी नोकरी सोडतो, किंवा एखादे डिव्हाइस गहाळ होते, तेव्हा तुमच्याकडे दोन पर्याय असतात: एकतर सर्वांसाठी पासवर्ड बदला, किंवा माजी कर्मचारी किंवा चोराकडे अजूनही वैध क्रेडेंशियल्स असण्याचा धोका पत्करा. गंभीर एंटरप्राइझसाठी यापैकी कोणताही पर्याय स्वीकारार्ह नाही. याचे उत्तर आहे 802.1X, जे पोर्ट-आधारित नेटवर्क ऍक्सेस कंट्रोलसाठी IEEE मानक आहे. 802.1X प्रत्येक डिव्हाइसला स्वतःचे वैयक्तिक ऑथेंटिकेशन क्रेडेंशियल देते. जेव्हा एखादे डिव्हाइस कनेक्ट होते, तेव्हा ऍक्सेस पॉईंट थेट ऍक्सेस मंजूर करत नाही. ते ऑथेंटिकेशन रिक्वेस्ट एका केंद्रीकृत RADIUS सर्व्हरकडे फॉरवर्ड करते, जो क्रेडेंशियलची पडताळणी करतो आणि पोर्ट उघडायचा की नाही हे ऍक्सेस पॉईंटला सांगतो. याचा परिणाम ऑडिट करण्यायोग्य, रद्द करण्यायोग्य, प्रति-डिव्हाइस ऍक्सेस कंट्रोलमध्ये होतो. हाच तो पाया आहे ज्यावर EAP-TLS आणि EAP-TTLS दोन्ही तयार केले गेले आहेत. दोन्ही प्रोटोकॉल हे Extensible Authentication Protocol पद्धती, किंवा EAP पद्धती आहेत, ज्या या 802.1X फ्रेमवर्क अंतर्गत काम करतात. प्रश्न 802.1X वापरायचा की नाही हा नाही. प्रश्न हा आहे की त्यामध्ये कोणती EAP पद्धत वापरायची. आणि आज आपण याच प्रश्नाचे उत्तर शोधण्यासाठी येथे आलो आहोत. EAP-TLS तांत्रिक सखोल विश्लेषण (2:00 - 5:30) चला EAP-TLS पासून सुरुवात करूया, ज्याचा अर्थ Transport Layer Security असा आहे. EAP-TLS हे RFC 5216 मध्ये परिभाषित केले आहे आणि वायरलेस ऑथेंटिकेशनसाठी हे गोल्ड स्टँडर्ड मानले जाते. याचा मुख्य सिद्धांत म्हणजे म्युच्युअल ऑथेंटिकेशन. नेटवर्क ऍक्सेस मंजूर होण्यापूर्वी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर या दोघांनीही त्यांची ओळख सिद्ध करण्यासाठी वैध X.509 डिजिटल सर्टिफिकेट्स सादर करणे आवश्यक आहे. या प्रक्रियेत कोणत्याही टप्प्यावर पासवर्डचा समावेश नसतो. अगदी शून्य. सुरक्षेच्या दृष्टिकोनातून हे अत्यंत महत्त्वाचे आहे. पासवर्ड फिशिंगद्वारे मिळवले जाऊ शकतात. ब्रूट फोर्सद्वारे त्यांचा अंदाज लावला जाऊ शकतो. थर्ड-पार्टी सर्व्हिसमधील डेटा ब्रीचमधून ते चोरीला जाऊ शकतात जिथे तुमच्या कर्मचाऱ्याने तोच पासवर्ड पुन्हा वापरला असेल. सर्टिफिकेट्स फिशिंगद्वारे मिळवता येत नाहीत, त्यांचा अंदाज लावला जाऊ शकत नाही आणि ती एका विशिष्ट डिव्हाइसशी जोडलेली असतात. जर एखाद्या चुकीच्या व्यक्तीला तुमच्या नेटवर्कवर प्रवेश मिळवायचा असेल, तर त्यांना प्रत्यक्ष डिव्हाइस आणि त्याची एम्बेड केलेली क्रिप्टोग्राफिक प्रायव्हेट की आवश्यक असेल. हे पूर्णपणे वेगळे थ्रेट मॉडेल आहे. मी तुम्हाला EAP-TLS हँडशेक सविस्तरपणे समजावून सांगतो, कारण ते समजून घेतल्याने हा प्रोटोकॉल इतका सुरक्षित का आहे हे स्पष्ट होते. जेव्हा एखादे डिव्हाइस WiFi नेटवर्कशी कनेक्ट करण्याचा प्रयत्न करते, तेव्हा ॲक्सेस पॉइंट डिव्हाइसच्या ओळखीसाठी EAP-Request पाठवतो. डिव्हाइस त्याला प्रतिसाद देते. ॲक्सेस पॉइंट हा प्रतिसाद RADIUS सर्व्हरकडे फॉरवर्ड करतो. RADIUS सर्व्हर त्याच्या X.509 प्रमाणपत्रासह Server Hello मेसेज पाठवून TLS हँडशेक सुरू करतो. क्लायंट या सर्व्हर प्रमाणपत्राची त्याच्या विश्वसनीय रूट सर्टिफिकेट ऑथॉरिटी स्टोअरशी पडताळणी करतो. पडताळणी अयशस्वी झाल्यास, हँडशेक लगेच थांबवला जातो. डिव्हाइस कनेक्ट करण्यास नकार देते. हेच Evil Twin हल्ल्यांपासून संरक्षण करते, जिथे हॅकर तुमच्या नेटवर्कचे सोंग घेण्यासाठी बनावट ॲक्सेस पॉइंट सेट करतो. सर्व्हर प्रमाणपत्र वैध असल्यास, क्लायंट त्याचे स्वतःचे X.509 प्रमाणपत्र RADIUS सर्व्हरला सादर करतो. RADIUS सर्व्हर क्लायंट प्रमाणपत्राची पडताळणी करतो: तो विश्वसनीय रूट CA कडील स्वाक्षरी साखळी तपासतो, प्रमाणपत्र कालबाह्य झाले नसल्याची खात्री करतो आणि प्रमाणपत्र रद्द केले गेले नाही याची खात्री करण्यासाठी सर्टिफिकेट रिव्होकेशन लिस्ट तपासतो. जेव्हा दोन्ही बाजूंचे समाधान होते, तेव्हाच TLS टनेल स्थापित होते आणि नेटवर्क प्रवेश मंजूर करून EAP-Success मेसेज पाठवला जातो. ही संपूर्ण देवाणघेवाण TLS 1.2 किंवा 1.3 चा वापर करते, ज्यामुळे परिपूर्ण फॉरवर्ड सिक्रेसी मिळते. आता, या पातळीच्या सुरक्षेसाठी एक ऑपरेशनल आवश्यकता असते: तुम्हाला पब्लिक की इन्फ्रास्ट्रक्चर म्हणजेच PKI ची आवश्यकता असते. किमान, तुम्हाला ऑफलाइन रूट सर्टिफिकेट ऑथॉरिटी आणि ऑनलाइन इश्यूइंग सर्टिफिकेट ऑथॉरिटीची आवश्यकता आहे. रूट CA एअर-गॅप असावा, कारण त्याची प्रायव्हेट की ही तुमच्या संपूर्ण प्रमाणपत्र पदानुक्रमासाठी मुख्य ट्रस्ट अँकर असते. इश्यूइंग CA दैनंदिन प्रमाणपत्र जारी करण्याचे काम पाहतो आणि सर्टिफिकेट रिव्होकेशन लिस्ट प्रकाशित करतो. आणि सर्वात महत्त्वाचे म्हणजे, नेटवर्कवरील प्रत्येक डिव्हाइसवर क्लायंट प्रमाणपत्रे तैनात करण्यासाठी तुमच्याकडे एक यंत्रणा असणे आवश्यक आहे. हजारो डिव्हाइसेसच्या ताफ्यासाठी, याचा अर्थ SCEP - सिम्पल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल वापरून तुमच्या PKI चे मोबाईल डिव्हाइस मॅनेजमेंट प्लॅटफॉर्मसह एकत्रीकरण करणे होय. जेव्हा एखादे कॉर्पोरेट डिव्हाइस तुमच्या MDM मध्ये नोंदणीकृत होते, तेव्हा ते कोणत्याही वापरकर्त्याच्या हस्तक्षेपाशिवाय स्वयंचलितपणे त्याचे प्रमाणपत्र विनंती करून प्राप्त करते. अमलबजावणीचे पर्याय (5:30 - 8:00) तर, तुम्ही कोणता प्रोटोकॉल तैनात केला पाहिजे? हा निर्णय पूर्णपणे तुमच्या डिव्हाइस व्यवस्थापन क्षमतांवर आणि तुमच्या अनुपालन आवश्यकतांवर अवलंबून असतो. मी तुम्हाला एक व्यावहारिक निर्णय आराखडा देतो. स्वतःला तीन प्रश्न विचारा. पहिला: या नेटवर्कशी कनेक्ट होणारी सर्व डिव्हाइसेस Microsoft Intune किंवा Jamf सारख्या MDM प्लॅटफॉर्मद्वारे कॉर्पोरेट-व्यवस्थापित आहेत का? उत्तर होय असल्यास, तुमच्याकडे क्लायंट प्रमाणपत्रे तैनात करण्यासाठी पायाभूत सुविधा आहेत आणि EAP-TLS हा योग्य पर्याय आहे. दुसरा: या नेटवर्कला PCI-DSS 4.0, HIPAA, किंवा WPA3 Enterprise 192-bit आवश्यकता पूर्ण करणे आवश्यक आहे का? उत्तर होय असल्यास, EAP-TLS हा आवश्यक पर्याय आहे. तिसरा: तुमच्याकडे व्यवस्थापित न केलेल्या किंवा BYOD डिव्हाइसेसचे प्रमाण लक्षणीय आहे का? उत्तर होय असल्यास, तुमच्या नेटवर्कच्या त्या विभागासाठी EAP-TTLS हा व्यावहारिक पर्याय आहे. मी तुम्हाला दोन प्रत्यक्ष व्यावहारिक परिस्थिती सांगतो. पहिली परिस्थिती: चारशे स्टोअर्स असलेली एक राष्ट्रीय रिटेल साखळी. प्रत्येक पॉईंट-ऑफ-सेल टर्मिनल आणि कर्मचाऱ्यांचे हँडहेल्ड स्कॅनर Microsoft Intune मध्ये नोंदणीकृत आहेत. हे नेटवर्क PCI-DSS 4.0 च्या कक्षेमध्ये येते. या वातावरणात, आपण EAP-TLS उपयोजित करता. आपण एक खाजगी PKI स्थापित करता, SCEP द्वारे प्रत्येक डिव्हाइसवर युनिक क्लायंट प्रमाणपत्रे पाठवण्यासाठी Intune चा वापर करता आणि प्रमाणपत्र मागे घेण्याची सूची तपासण्यासाठी आपले RADIUS सर्व्हर कॉन्फिगर करता. एखादे डिव्हाइस चोरीला गेल्यास, आपण त्याचे प्रमाणपत्र रद्द करता आणि काही मिनिटांतच ते नेटवर्कवरून बाहेर पडते. रिसेट करण्यासाठी कोणताही पासवर्ड नाही. चारशे साइट्सवर रोटेट करण्यासाठी कोणतीही सामायिक गुप्त की नाही. दुसरी परिस्थिती: वैयक्तिक लॅपटॉप, स्मार्टफोन आणि टॅब्लेट वापरणारे वीस हजार विद्यार्थी असलेले एक मोठे विद्यापीठ कॅम्पस. IT टीम वैयक्तिक डिव्हाइसवर प्रमाणपत्रे स्थापित करू शकत नाही. या वातावरणात, EAP-TTLS हा व्यावहारिक पर्याय आहे. आपण आपल्या RADIUS सर्व्हर्सवर एक विश्वसनीय प्रमाणपत्र स्थापित करता, आपल्या विद्यापीठ डिरेक्टरी सेवेशी समाकलित करता आणि विद्यार्थी सुरक्षित टनेलमध्ये त्यांच्या विद्यमान क्रेडेंशियलचा वापर करून प्रमाणीकरण करतात. हे क्लायंटच्या बाजूने कोणत्याही अतिरिक्त सॉफ्टवेअरशिवाय Windows, macOS, Linux, Android आणि iOS ला सपोर्ट करते. अनेक मोठ्या उपक्रमांमध्ये, याचे उत्तर प्रत्यक्षात दोन्हीही असे आहे. आपण आपल्या व्यवस्थापित कॉर्पोरेट डिव्हाइससाठी EAP-TLS उपयोजित करता आणि कंत्राटदार, अभ्यागत आणि BYOD साठी EAP-TTLS किंवा स्वतंत्र सुरक्षित नेटवर्क उपयोजित करता. हॉस्पिटॅलिटी ग्रुप्समध्ये हा एक सामान्य पॅटर्न आहे, जिथे कर्मचाऱ्यांची डिव्हाइसेस व्यवस्थापित केली जातात आणि त्यांना प्रमाणपत्रे दिली जातात, तर गेस्टसाठी असलेल्या पायाभूत सुविधा पूर्णपणे भिन्न प्रमाणीकरण मार्ग वापरतात. रॅपिड-फायर प्रश्नोत्तरे (8:00 - 9:00) CTO आणि नेटवर्क आर्किटेक्ट्सकडून आम्हाला वारंवार ऐकायला मिळणाऱ्या प्रश्नांची काही झटपट उत्तरे मी तुम्हाला देतो. प्रश्न पहिला: WPA3 Enterprise साठी EAP-TLS आवश्यक आहे का? आपण WPA3 Enterprise 192-बिट सुरक्षा सूट लागू करत असल्यास, होय, EAP-TLS ही एकमेव अनुमत पद्धत आहे. Wi-Fi Alliance च्या WPA3-Enterprise 192-बिट आवश्यकता पूर्ण करणारी ही एकमेव EAP पद्धत आहे. प्रश्न दुसरा: आम्ही IoT डिव्हाइसेससाठी EAP-TTLS वापरू शकतो का? सामान्यतः, नाही. इन्फ्युजन पंप किंवा पर्यावरणीय सेन्सर्ससारख्या हेडलेस IoT डिव्हाइसेसमध्ये सहसा जटिल अंतर्गत प्रमाणीकरण पद्धती हाताळण्यासाठी इंटरफेस नसतो. IoT साठी EAP-TLS प्रत्यक्षात अधिक योग्य आहे, कारण आपण डिव्हाइस स्टेजिंग दरम्यान प्रमाणपत्र प्रदान करू शकता. कोणत्याही वापरकर्त्याच्या परस्परसंवादाशिवाय, डिव्हाइस स्वयंचलितपणे प्रमाणीकृत होते. प्रश्न तिसरा: EAP-TLS नेटवर्कवरील BYOD बद्दल काय? अव्यवस्थित वैयक्तिक डिव्हाइसेससाठी, EAP-TLS चालवणे कठीण असते. तात्पुरते प्रमाणपत्र प्रदान करण्यासाठी आपण ऑनबोर्डिंग पोर्टल्स वापरू शकता, परंतु यामुळे अडथळा वाढतो. BYOD साठी, EAP-TTLS किंवा योग्य विभाजनासह समर्पित गेस्ट WiFi नेटवर्क हे सहसा योग्य उत्तर असते. प्रश्न चौथा: याचा हार्डवेअर विक्रेत्यांशी कसा संबंध आहे? EAP-TLS आणि EAP-TTLS या दोन्ही पद्धतींना सर्व प्रमुख एंटरप्राइझ WiFi हार्डवेअर प्लॅटफॉर्मवर सपोर्ट आहे - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist आणि Ubiquiti UniFi. कॉन्फिगरेशनचे तपशील प्लॅटफॉर्मनुसार भिन्न असतात, परंतु मूळ मानके विक्रेत्याच्या बंधनापासून मुक्त आहेत. सारांश आणि पुढील पायऱ्या (9:00 - 10:00) शेवट करताना, आपल्यासाठी महत्त्वाचे मुद्दे येथे आहेत. EAP-TLS परस्पर प्रमाणपत्र प्रमाणीकरणाद्वारे सर्वोच्च सुरक्षा प्रदान करते. हे पासवर्डचा धोका पूर्णपणे काढून टाकते आणि व्यवस्थापित डिव्हाइस ताफ्यांसाठी तसेच नियंत्रित वातावरणासाठी योग्य पर्याय आहे. EAP-TTLS सर्व्हर-साइड प्रमाणपत्रे आणि एनक्रिप्टेड क्रेडेंशियल टनेलिंगद्वारे मजबूत सुरक्षा प्रदान करते. मिश्रित किंवा BYOD वातावरणासाठी हा योग्य पर्याय आहे. दोन्ही प्रोटोकॉल्ससाठी आपण प्रत्येक क्लायंटवर सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करणे आवश्यक आहे. त्याशिवाय, कोणताही प्रोटोकॉल आपले हॅकर किंवा अनधिकृत ऍक्सेस पॉईंट्सपासून संरक्षण करत नाही. आणि प्रमाणपत्र लाइफसायकल व्यवस्थापन हे EAP-TLS मधील मुख्य ऑपरेशनल आव्हान आहे - पहिल्या दिवसापासूनच MDM आणि SCEP द्वारे ते स्वयंचलित करा. आपल्या पुढील पायऱ्या? आपल्या सध्याच्या 802.1X उपयोजनाचे ऑडिट करा. जर आपण अजूनही शेअर्ड पासवर्डवर अवलंबून असाल, तर आपल्या मायग्रेशनचे नियोजन करा. आपले क्लायंट सप्लिकेंट्स सर्व्हर प्रमाणपत्राची पडताळणी करत आहेत की नाही ते तपासा. आणि जर आपण एकापेक्षा जास्त ठिकाणी किंवा विखुरलेल्या मालमत्तेवर हे तैनात करत असाल, तर ऑपरेशनल ओझे कमी करण्यासाठी क्लाउड-होस्ट केलेल्या RADIUS सेवेचा विचार करा. Purple कडून हे तांत्रिक ब्रीफिंग ऐकल्याबद्दल धन्यवाद. आमच्या 80,000 पेक्षा जास्त लाईव्ह ठिकाणी कर्मचारी WiFi साठी Purple दोन्ही EAP-TLS आणि EAP-TTLS प्रमाणीकरण मार्गांना समर्थन देते. अधिक तपशीलवार उपयोजन मार्गदर्शकांसाठी आणि आमचे ॲनालिटिक्स आणि ओळख प्लॅटफॉर्म आपल्या सुरक्षित नेटवर्कशी कसे समाकलित होतात हे समजून घेण्यासाठी, purple dot ai ला भेट द्या.

आमच्या मुख्य मालिकेचा भाग: एंटरप्राइझ WiFi सुरक्षा मार्गदर्शक

EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते प्रमाणपत्र-आधारित WiFi प्रोटोकॉल निवडले पाहिजे?

कार्यकारी सारांश (Executive Summary)

तुमच्या 802.1X उपयोजनासाठी (deployment) योग्य EAP पद्धत निवडणे हे ठरवते की तुमचे एंटरप्राइझ WiFi खरोखर सुरक्षित आहे की केवळ कागदावर नियमांचे पालन करणारे आहे. RFC 5216 मध्ये परिभाषित केलेले EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), परस्पर प्रमाणपत्र प्रमाणीकरण (mutual certificate authentication) आवश्यक करते: नेटवर्क प्रवेश मंजूर होण्यापूर्वी क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोन्ही वैध X.509 प्रमाणपत्रे सादर करतात. कोणत्याही टप्प्यावर पासवर्डची देवाणघेवाण केली जात नाही. RFC 5281 मध्ये परिभाषित केलेल्या EAP-TTLS (Tunneled Transport Layer Security) ला एनक्रिप्टेड TLS टनेल स्थापित करण्यासाठी केवळ सर्व्हर-साइड प्रमाणपत्र आवश्यक असते, ज्याच्या आत क्लायंट विद्यमान निर्देशिका क्रेडेंशियल (directory credentials) वापरून प्रमाणित करतो.

किरकोळ विक्री साखळी (retail chains), आदरातिथ्य ठिकाणे (hospitality venues) आणि सार्वजनिक क्षेत्रातील संस्थांमधील पायाभूत सुविधांचे व्यवस्थापन करणाऱ्या CTO आणि नेटवर्क आर्किटेक्टसाठी, हा निर्णय एका प्रश्नावर येऊन थांबतो: तुम्ही डिव्हाइस व्यवस्थापित करता का? जर तुम्ही MDM द्वारे डिव्हाइस फ्लीट नियंत्रित करत असाल, तर EAP-TLS हा निश्चित पर्याय आहे. तुम्ही वैविध्यपूर्ण BYOD वातावरणाचे समर्थन करत असल्यास किंवा तुमच्याकडे मजबूत पब्लिक की इन्फ्रास्ट्रक्चर (PKI) नसल्यास, EAP-TTLS एक व्यावहारिक, अत्यंत सुरक्षित पर्याय प्रदान करतो. Purple ८०,००० पेक्षा जास्त थेट ठिकाणांवर Staff WiFi साठी या दोन्ही प्रमाणीकरण मार्गांना समर्थन देते.

EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते प्रमाणपत्र-आधारित WiFi प्रोटोकॉल निवडले पाहिजे? - comparison chart


तांत्रिक सखोल विश्लेषण (Technical Deep-Dive)

EAP-TLS ची आर्किटेक्चर

EAP-TLS हे IEEE 802.1X पोर्ट-आधारित प्रवेश नियंत्रण फ्रेमवर्कमध्ये परस्पर प्रमाणीकरण मॉडेलवर कार्य करते. प्रत्येक प्रमाणीकरण देवाणघेवाणीमध्ये तीन मुख्य घटक समाविष्ट असतात: सप्लिकंट (क्लायंट डिव्हाइस), प्रमाणकर्ता (वायरलेस ऍक्सेस पॉईंट) आणि प्रमाणीकरण सर्व्हर (RADIUS सर्व्हर). ऍक्सेस पॉईंट स्वतः प्रमाणीकरणाचा निर्णय घेत नाही. हे एक पारदर्शक रिले म्हणून काम करते, EAP संदेशांना RADIUS पॅकेटमध्ये एन्कॅप्स्युलेट करते आणि त्यांना प्रमाणीकरण सर्व्हरकडे फॉरवर्ड करते. EAP-TLS हँडशेक खालीलप्रमाणे कार्य करतो. ऍक्सेस पॉईंट कनेक्ट होणाऱ्या डिव्हाइसला EAP-Request/Identity पाठवतो. डिव्हाइस त्याच्या ओळखीसह प्रतिसाद देते. RADIUS सर्व्हर EAP-TLS/Start मेसेजसह TLS हँडशेक सुरू करतो. क्लायंट ClientHello पाठवतो, ज्यामध्ये त्याच्या समर्थित TLS सायफर सूटची जाहिरात असते. RADIUS सर्व्हर ServerHello, त्याचे X.509 सर्व्हर सर्टिफिकेट आणि सर्टिफिकेट विनंतीसह प्रतिसाद देतो. क्लायंट त्याच्या विश्वसनीय रूट CA स्टोअरच्या तुलनेत सर्व्हर सर्टिफिकेट प्रमाणित करतो. व्हॅलिडेशन अयशस्वी झाल्यास, हँडशेक समाप्त होतो - ज्यामुळे फसव्या ऍक्सेस पॉईंट्सपासून संरक्षण मिळते. क्लायंट नंतर स्वतःचे X.509 सर्टिफिकेट सादर करतो. RADIUS सर्व्हर क्लायंट सर्टिफिकेट प्रमाणित करतो, विश्वसनीय रूट CA पर्यंतची स्वाक्षरी साखळी तपासतो, सर्टिफिकेट कालबाह्य झाले नसल्याची पडताळणी करतो आणि सर्टिफिकेट रिव्होकेशन लिस्ट (CRL) तपासतो किंवा OCSP ला क्वेरी करतो. जेव्हा दोन्ही पक्षांचे समाधान होते, तेव्हाच TLS टनेल स्थापित केले जाते आणि नेटवर्क ऍक्सेस मंजूर केला जातो.

कोणतेही पासवर्ड देवाणघेवाण केले जात नसल्यामुळे, EAP-TLS ऑफलाइन डिक्शनरी हल्ले, क्रेडेंशियल स्टफिंग आणि फिशिंगपासून सुरक्षित आहे. WPA3-Enterprise १९२-बिट (Suite B) आवश्यकता पूर्ण करणारी ही एकमेव EAP पद्धत आहे, आणि कार्डधारक डेटा वातावरणासाठी PCI-DSS 4.0 द्वारे आणि उच्च सुरक्षिततेच्या वायरलेस उपयोजनांसाठी NIST SP 800-120 द्वारे हे अनिवार्य किंवा अत्यंत शिफारसीय आहे.

EAP-TLS साठी PKI आवश्यक आहे. तुम्हाला किमान एक ऑफलाइन रूट CA आणि एक ऑनलाइन जारी करणारे CA आवश्यक आहे. रूट CA एअर-गॅप असले पाहिजे, कारण त्याची प्रायव्हेट की तुमच्या संपूर्ण सर्टिफिकेट पदानुक्रमासाठी मास्टर ट्रस्ट अँकर असते. जारी करणारे CA दररोज सर्टिफिकेट जारी करण्याचे काम सांभाळते आणि CRLs प्रकाशित करते. क्लायंट सर्टिफिकेट वैयक्तिक डिव्हाइसेसना जारी केली जातात, वापरकर्त्यांना नाही - हे एक डिव्हाइस-आयडेंटिटी मॉडेल आहे. IoT डिव्हाइसेस, सामायिक टर्मिनल्स आणि हेडलेस सिस्टम्ससाठी हा फरक अत्यंत महत्त्वाचा आहे.

EAP-TTLS ची रचना

EAP-TTLS ची रचना प्रत्येक क्लायंट डिव्हाइसवर सर्टिफिकेट्स तैनात करण्याच्या ऑपरेशनल ओझ्याशिवाय मजबूत 802.1X सुरक्षा प्रदान करण्यासाठी केली गेली आहे. हे दोन टप्प्यांत कार्य करते. पहिल्या टप्प्यात, RADIUS सर्व्हर आपले सर्टिफिकेट सादर करतो आणि एक सुरक्षित TLS टनेल स्थापित करतो. केवळ सर्व्हरला सर्टिफिकेटची आवश्यकता असते. दुसऱ्या टप्प्यात, क्लायंटला त्या कूटबद्ध टनेलमध्ये अंतर्गत ऑथेंटिकेशन पद्धतीचा वापर करून अधिकृत केले जाते. सामान्य अंतर्गत पद्धतींमध्ये PAP (Password Authentication Protocol), CHAP आणि MS-CHAPv2 चा समावेश होतो. क्लायंट त्याचा युझरनेम आणि पासवर्ड पाठवतो, परंतु ही देवाणघेवाण TLS टनेलच्या आत होत असल्याने, क्रेडेंशियल्स ट्रान्झिटमध्ये कूटबद्ध (encrypted) केली जातात आणि हवेत कधीही उघड होत नाहीत.

EAP-TTLS हे macOS, Linux, Android, आणि iOS वर उत्कृष्ट क्रॉस-प्लॅटफॉर्म समर्थन प्रदान करते. Windows च्या बाबतीत एक अडचण आहे: अंगभूत Windows सप्लिकंट वायरलेस 802.1X साठी मूळतः EAP-TTLS ला थेट समर्थन देत नाही. मोठ्या प्रमाणात Windows डिव्हाइसेस असलेल्या वातावरणात थर्ड-पार्टी सप्लिकंटची आवश्यकता असू शकते, ज्यामुळे ऑपरेशनल गुंतागुंत वाढते. Windows-केंद्रित वातावरणासाठी, MS-CHAPv2 सह PEAP हा बहुधा अधिक व्यावहारिक पर्याय ठरतो.

EAP-TTLS ची सर्वात मोठी मर्यादा ही आहे की ते पासवर्डच्या अंगभूत जोखमींना दूर करत नाही. जर वापरकर्त्याने कमकुवत पासवर्ड निवडला, तर तो ऑफलाइन ब्रूट-फोर्स हल्ल्यांसाठी असुरक्षित राहतो. जर अंतर्गत प्रमाणीकरणामध्ये PAP वापरले जात असेल, तर पासवर्ड टनेलमध्ये प्लेनटेक्स्ट स्वरूपात पाठवला जातो - जे तुम्ही तुमच्या RADIUS इन्फ्रास्ट्रक्चरवर विश्वास ठेवत असल्यास स्वीकार्य आहे, परंतु हे समजून घेणे एक आवश्यक ट्रस्ट मॉडेल आहे.

समोरासमोर तुलना

वैशिष्ट्य EAP-TLS EAP-TTLS
RFC मानक RFC 5216 RFC 5281
क्लायंट प्रमाणपत्र आवश्यक आहे होय नाही
सर्व्हर प्रमाणपत्र आवश्यक आहे होय होय
प्रमाणीकरण मॉडेल परस्पर (दोन्ही बाजू) केवळ-सर्व्हर
पासवर्डची जोखीम काहीही नाही - पासवर्डलेस एन्क्रिप्टेड टनेलमध्ये पासवर्ड
PKI आवश्यकता पूर्ण PKI (Root CA + Issuing CA + MDM) केवळ सर्व्हर प्रमाणपत्र
WPA3-Enterprise 192-bit आवश्यक पद्धत समर्थित नाही
PCI-DSS 4.0 सुसंगतता अत्यंत शिफारसीय मजबूत अंतर्गत प्रमाणीकरणासह स्वीकार्य
BYOD साठी सुसंगतता कमी (क्लायंट प्रमाणपत्राची आवश्यकता आहे) जास्त (केवळ क्रेडेंशियल्स)
IoT डिव्हाइस सुसंगतता जास्त (स्टेजिंगवर प्रमाणपत्र प्रोव्हिजन केलेले असते) कमी (क्रेडेंशियल इनपुटसाठी कोणतेही UI नसते)
Windows मूळ सपोर्ट होय आंशिक (बऱ्याचदा थर्ड-पार्टी सप्लिकंटची आवश्यकता असते)
macOS/Linux/Android सपोर्ट होय होय
उपयोजन जटिलता जास्त मध्यम

अंमलबजावणी मार्गदर्शक

व्यवस्थापित फ्लीट्ससाठी EAP-TLS उपयोजित करणे

EAP-TLS उपयोजित करण्यासाठी कार्यरत PKI आणि MDM प्लॅटफॉर्म आवश्यक आहे. एंटरप्राइझ स्तरावर मॅन्युअल प्रमाणपत्र स्थापना व्यावहारिक नाही. तुम्ही SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल) किंवा EST (एनरोलमेंट ओव्हर सिक्युर ट्रान्सपोर्ट) वापरून तुमच्या PKI ला तुमच्या MDM सोबत एकत्रित केले पाहिजे. जेव्हा एखादे कॉर्पोरेट डिव्हाइस नोंदणीकृत केले जाते, तेव्हा ते वापरकर्त्याच्या हस्तक्षेपाशिवाय स्वयंचलितपणे त्याच्या प्रमाणपत्राची विनंती करते आणि ते प्राप्त करते.

ओळख व्यवस्थापनासाठी, Purple Connect परवान्यांतर्गत OpenRoaming सारख्या सेवांसाठी एक विनामूल्य ओळख प्रदाता म्हणून काम करते, जे अंतर्निहित प्रमाणपत्र आणि ओळख फ्रेमवर्क वापरून विविध ठिकाणी सुरक्षित रोमिंग सुलभ करते.

RADIUS च्या बाजूने, तुमच्या अंतर्गत CA च्या विरूद्ध क्लायंट प्रमाणपत्रांचे प्रमाणीकरण करण्यासाठी आणि CRL तपासण्यासाठी किंवा रिअल-टाइम रिव्होकेशन तपासणीसाठी OCSP वापरण्यासाठी तुमचा सर्व्हर कॉन्फिगर करा. समर्थित RADIUS प्लॅटफॉर्ममध्ये FreeRADIUS, Microsoft NPS आणि Cisco ISE समाविष्ट आहेत. Purple चे क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हार्डवेअरसह एकत्रित होते.

मिश्र वातावरणासाठी EAP-TTLS उपयोजित करणे

अव्यवस्थित डिव्हाइसेस असलेल्या वातावरणासाठी EAP-TTLS हा सर्वोत्तम पर्याय आहे. तुम्हाला तुमच्या RADIUS सर्व्हरवर फक्त एका विश्वसनीय प्रमाणपत्राची आवश्यकता आहे. अंतर्गत प्रमाणीकरण क्रेडेंशियल्स सत्यापित करण्यासाठी तुमचा RADIUS सर्व्हर थेट तुमच्या डिरेक्टरी सेवेशी - Microsoft Entra ID, Okta किंवा Google Workspace - एकत्रित असल्याची खात्री करा. तुमच्या विशिष्ट विश्वसनीय CA च्या विरूद्ध सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करण्यासाठी तुमचे MDM-उपयोजित WiFi प्रोफाइल कॉन्फिगर करा. या चरणाशिवाय, TLS टनेल रॉग ॲक्सेस पॉईंट्सपासून कोणतेही संरक्षण प्रदान करत नाही.

EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते प्रमाणपत्र-आधारित WiFi प्रोटोकॉल निवडले पाहिजे? - decision framework


तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.

सर्वोत्कृष्ट पद्धती

प्रत्येक क्लायंटवर सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करा

EAP-TLS आणि EAP-TTLS या दोन्हीसाठी सर्वात महत्त्वाचे कॉन्फिगरेशन पाऊल म्हणजे क्लायंट डिव्हाइसवर सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करणे. जर एखादे डिव्हाइस विशिष्ट विश्वसनीय CA च्या विरूद्ध RADIUS सर्व्हरचे प्रमाणपत्र प्रमाणित करत नसेल, तर ते कोणत्याही प्रमाणपत्रासह सादर होणाऱ्या कोणत्याही सर्व्हरशी कनेक्ट होईल - ज्यामध्ये फसव्या ॲक्सेस पॉइंटचाही समावेश आहे. तुमच्या MDM-नियोजित WiFi प्रोफाइलमध्ये नेहमी विश्वसनीय CA आणि अपेक्षित सर्व्हरचे नाव निर्दिष्ट करा. ही एकच कॉन्फिगरेशन तपासणी आज तुम्ही अंमलात आणू शकत असलेली सर्वात प्रभावी सुरक्षा सुधारणा आहे.

प्रमाणपत्र लाइफसायकल व्यवस्थापन स्वयंचलित करा

प्रमाणपत्रांची मुदत संपते. जर तुमच्याकडे स्वयंचलित नूतनीकरण प्रक्रिया नसेल, तर एकाच वेळी प्रमाणपत्रांची मुदत संपल्यावर तुम्हाला मोठ्या प्रमाणावर प्रमाणीकरण अपयशाचा सामना करावा लागेल. नूतनीकरण स्वयंचलित करण्यासाठी SCEP किंवा EST वापरा आणि मुदत संपण्याच्या तारखेच्या खूप आधी देखरेख सतर्कता (मॉनिटरिंग अलर्ट) कॉन्फिगर करा. एखादे डिव्हाइस हरवल्यास किंवा कर्मचाऱ्याने नोकरी सोडल्यास, प्रमाणपत्र त्वरित रद्द करा. रिअल-टाइम प्रमाणीकरणासाठी CRLs तपासण्यासाठी किंवा OCSP वापरण्यासाठी तुमचा RADIUS सर्व्हर कॉन्फिगर करा.

प्रमाणीकरण पद्धतीनुसार तुमच्या नेटवर्कचे विभाजन करा

मोठ्या किंवा वितरित वातावरणात, स्वतंत्र SSIDs वर दोन्ही प्रोटोकॉल चालवण्याचा विचार करा. कॉर्पोरेट व्यवस्थापित डिव्हाइसेस समर्पित स्टाफ WiFi SSID वर EAP-TLS द्वारे प्रमाणित होतात. कंत्राटदार आणि BYOD डिव्हाइसेस योग्य VLAN विभाजनासह स्वतंत्र SSID वर EAP-TTLS द्वारे प्रमाणित होतात. हा पॅटर्न प्रिमियर इन आणि व्हिटब्रेड सारख्या आदरातिथ्य समूहांमध्ये सामान्य आहे, जेथे कर्मचाऱ्यांच्या डिव्हाइसेसचे व्यवस्थापन केले जाते आणि प्रमाणपत्रे दिली जातात, तर अतिथी पायाभूत सुविधा स्वतंत्र प्रमाणीकरण मार्ग वापरतात. SSID आर्किटेक्चरवरील अधिक तपशीलांसाठी, आमचे मार्गदर्शक पहा थ्री SSIDs टू रूल देम ऑल: द WiFi डिझाइन फॉर गेस्ट, स्टाफ अँड IoT.

सर्व पायाभूत सुविधांमध्ये वेळ समक्रमित करा

प्रमाणपत्र प्रमाणीकरण अचूक सिस्टम वेळेवर अवलंबून असते. क्लायंट डिव्हाइसेस किंवा RADIUS सर्व्हरवरील घड्याळाच्या वेळेतील फरकामुळे 'अद्याप वैध नाही' किंवा 'मुदत संपली आहे' अशा प्रमाणपत्राच्या त्रुटी उद्भवतात ज्यांचे निदान करणे कठीण असते. सर्व पायाभूत सुविधांचे घटक विश्वसनीय NTP सर्व्हरसह समक्रमित असल्याचे सुनिश्चित करा.


समस्यानिवारण आणि जोखीम कमी करणे

अज्ञात CA त्रुटी

जर RADIUS लॉग्ज 'unknown CA' दर्शवत असतील, तर क्लायंट डिव्हाइस RADIUS सर्व्हरचे प्रमाणपत्र जारी करणाऱ्या CA वर विश्वास ठेवत नाही. तुमच्या MDM प्रोफाइलमध्ये रूट CA प्रमाणपत्र समाविष्ट असल्याचे आणि अर्जदार त्यावर विश्वास ठेवण्यासाठी कॉन्फिगर केलेला असल्याचे सत्यापित करा. CA रोटेशन किंवा प्रमाणपत्र नूतनीकरणानंतर, अपडेट केलेले CA बंडल सर्व डिव्हाइसेसवर पुन्हा पुश करा.

EAP पद्धतीचा बेबनाव

जर डिव्हाइसेस ॲक्सेस पॉइंटशी कनेक्ट होत असतील परंतु प्रमाणीकरण अयशस्वी होत असेल, तर क्लायंटवर कॉन्फिगर केलेली EAP पद्धत RADIUS सर्व्हरद्वारे स्वीकारलेल्या पद्धतीशी जुळत असल्याची तपासणी करा. केवळ PEAP साठी कॉन्फिगर केलेल्या RADIUS सर्व्हरवर EAP-TLS साठी सेट केलेले डिव्हाइस प्रोफाइल अयशस्वी होईल.

कालबाह्य झालेल्या प्रमाणपत्रांमुळे मोठ्या प्रमाणावर होणारे अपयश

जर मोठ्या संख्येने उपकरणे एकाच वेळी ऑथेंटिकेट होण्यास अपयशी ठरली, तर सर्वात आधी प्रमाणपत्र संपण्याची तारीख (certificate expiry dates) तपासा. EAP-TLS उपयोजनांमध्ये मोठ्या प्रमाणावर 802.1X अयशस्वी होण्याचे हे सर्वात सामान्य कारण आहे. अशी मॉनिटरिंग सिस्टम लागू करा जी प्रमाणपत्र संपण्याच्या ६० दिवस, ३० दिवस आणि सात दिवस आधी अलर्ट पाठवेल.

RADIUS क्लायंटची चुकीची कॉन्फिगरेशन

प्रत्येक ॲक्सेस पॉइंट किंवा वायरलेस कंट्रोलर योग्य IP ॲड्रेस आणि शेअर्ड सीक्रेटसह RADIUS क्लायंट म्हणून परिभाषित केलेला असणे आवश्यक आहे. यामधील विसंगतीमुळे ऑथेंटिकेशन टाईमआउट्स होतात, जे सहसा चुकीच्या पद्धतीने EAP पद्धतीमुळे झाल्याचे समजले जाते. पहिल्या दिवसापासूनच तपशीलवार RADIUS लॉगिंग सक्षम करा. अधिक WiFi ट्रबलशूटिंग मार्गदर्शनासाठी, आमचे Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures हे मार्गदर्शन पहा.


अनुपालन आणि नियामक संरेखन (Compliance and Regulatory Alignment)

CISO आणि नेटवर्क आर्किटेक्ट्ससाठी, EAP-TLS आणि EAP-TTLS मधील निवड करताना नियामक लँडस्केप समजून घेणे आवश्यक आहे. EAP पद्धतीची निवड थेट तुमच्या अनेक प्रमुख फ्रेमवर्कमधील अनुपालन स्थितीवर परिणाम करते.

PCI DSS 4.0 (पेमेंट कार्ड इंडस्ट्री डेटा सिक्युरिटी स्टँडर्ड) ला कार्डधारक डेटा वातावरणातील वायरलेस नेटवर्कसाठी मजबूत क्रिप्टोग्राफिक ऑथेंटिकेशन आवश्यक आहे. आवश्यकता ८.३ CDE च्या सर्व प्रवेशासाठी मल्टी-फॅक्टर ऑथेंटिकेशन अनिवार्य करते, आणि व्याप्तीमधील वायरलेस नेटवर्कने मजबूत ऑथेंटिकेशन यंत्रणा वापरली पाहिजे. EAP-TLS, प्रमाणपत्र-आधारित परस्पर ऑथेंटिकेशनसह, ही आवश्यकता निश्चितपणे पूर्ण करते. जर अंतर्गत ऑथेंटिकेशन योग्यरित्या सुरक्षित केले असेल आणि सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू केले असेल तर MS-CHAPv2 सह EAP-TTLS स्वीकार्य आहे, परंतु EAP-TLS हा अधिक मजबूत आणि ऑडिटरसाठी सोयीस्कर पर्याय आहे. HIPAA (हेल्थ इन्शुरन्स पोर्टेबिलिटी अँड अकाउंटेबिलिटी ॲक्ट) ला कव्हर केलेल्या संस्थांनी तांत्रिक सुरक्षा उपाय लागू करणे आवश्यक आहे जे इलेक्ट्रॉनिक कम्युनिकेशन नेटवर्कवर प्रसारित होणाऱ्या इलेक्ट्रॉनिक संरक्षित आरोग्य माहितीचे (ePHI) संरक्षण करतात. HIPAA सुरक्षा नियम विशिष्ट प्रोटोकॉल अनिवार्य करत नाही, परंतु ePHI वाहून नेणाऱ्या वायरलेस नेटवर्कसाठी एन्क्रिप्शन आणि ॲक्सेस कंट्रोलची अपेक्षा व्यवस्थापित वैद्यकीय उपकरणांच्या ताफ्यासाठी EAP-TLS च्या आणि कर्मचारी उपकरणांसाठी लागू केलेल्या सर्व्हर प्रमाणपत्र प्रमाणीकरणासह EAP-TTLS च्या बाजूने मोठ्या प्रमाणावर झुकते.

WPA3-Enterprise 192-bit (ज्याला Suite B किंवा CNSA मोड देखील म्हणतात) हा Wi-Fi Alliance च्या WPA3 प्रमाणपत्राचा सर्वोच्च सुरक्षा स्तर आहे. हे EAP-TLS ला एकमेव अनुमत ऑथेंटिकेशन पद्धत म्हणून अनिवार्य करते, विशिष्ट सायफर सूटसह (ECDHE with P-384, AES-256-GCM) TLS १.२ किंवा त्याहून अधिक आवश्यक आहे, आणि ECDSA किंवा RSA-3072 प्रमाणपत्रांची आवश्यकता असते. सरकारी, संरक्षण किंवा गंभीर पायाभूत सुविधांच्या ॲप्लिकेशनसाठी WPA3-Enterprise 192-bit तैनात करणाऱ्या संस्थांनी EAP-TLS वापरणे आवश्यक आहे.ISO/IEC 27001 विशिष्ट प्रोटोकॉल्स अनिवार्य करत नाही, परंतु नेटवर्क संसाधनांसाठी संस्थांनी योग्य प्रवेश नियंत्रणे लागू करणे आवश्यक आहे. EAP-TLS किंवा EAP-TTLS (सक्तीच्या सर्व्हर प्रमाणपत्र प्रमाणीकरणासह) यांपैकी एकासह 802.1X उपयोजन, Annex A.9.1 आणि A.13.1 च्या नेटवर्क प्रवेश नियंत्रण आवश्यकता पूर्ण करते.


ROI आणि व्यावसायिक प्रभाव

EAP-TLS वर स्थलांतरित होण्यासाठी PKI आणि MDM एकत्रीकरणामध्ये सुरुवातीची गुंतवणूक आवश्यक आहे, परंतु यामुळे पासवर्ड रीसेटचा कार्यात्मक खर्च आणि तडजोड केलेल्या क्रेडेंशियल्समुळे नेटवर्क उल्लंघनाचा आर्थिक धोका दूर होतो. ४०० स्टोअर्स असलेल्या रिटेल साखळीसाठी, सामायिक केलेल्या PSK नेटवर्कवरील एका तडजोड केलेल्या पासवर्डमुळे संपूर्ण मालमत्ता धोक्यात येऊ शकते. EAP-TLS हा हल्ला करण्याचा मार्ग पूर्णपणे काढून टाकतो.

बहु-भाडेकरू (multi-tenant) पर्यावरण आणि प्रवासी हबसाठी, सुरक्षित प्रमाणीकरण केवळ अधिकृत वापरकर्तेच नेटवर्क बँडविड्थचा वापर करत असल्याची खात्री करते, ज्यामुळे पायाभूत सुविधांचा वापर इष्टतम होतो. RADIUS प्रमाणपत्र गुणधर्मांद्वारे डायनॅमिक VLAN असाइनमेंट क्रिप्टोग्राफिक पद्धतीने लागू केलेल्या नेटवर्क विभाजनास सक्षम करते, ज्यामुळे डिव्हाइसेस केवळ SSID निवडीवर किंवा MAC पत्ता फिल्टरिंगवर अवलंबून न राहता प्रमाणपत्र गुणधर्मांवर आधारित योग्य नेटवर्क विभागावर ठेवले जातील याची खात्री होते.

Purple चे WiFi Analytics प्लॅटफॉर्म दोन्ही प्रमाणीकरण मार्गांशी समाकलित होते, जे तुमच्या संपूर्ण मालमत्तेवर डिव्हाइस संख्या, सत्र कालावधी आणि नेटवर्क वापराविषयी दृश्यमानता प्रदान करते. क्षेत्र-विशिष्ट उपयोजन मार्गदर्शनासाठी, आमच्या Hospitality, Retail, Healthcare आणि Transport च्या संसाधनांचा शोध घ्या.

महत्वाच्या व्याख्या

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

RFC 5216 मध्ये परिभाषित केलेली एक 802.1X प्रमाणीकरण पद्धत ज्यामध्ये क्लायंट डिव्हाइस आणि RADIUS सर्व्हर दोन्हीकडे वैध X.509 सर्टिफिकेट्स असणे आवश्यक आहे. कोणतेही पासवर्ड बदलले जात नाहीत. प्रमाणीकरण परस्पर आणि क्रिप्टोग्राफिक पद्धतीने जोडलेले असते.

एंटरप्राइझ वायरलेस सुरक्षेसाठी सर्वोत्तम मानक. WPA3-Enterprise १९२-बिट साठी आवश्यक आणि PCI DSS 4.0 कार्डधारक डेटा वातावरणासाठी अत्यंत शिफारसीय.

EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security)

RFC 5281 मध्ये परिभाषित केलेली एक 802.1X प्रमाणीकरण पद्धत ज्यामध्ये एन्क्रिप्टेड TLS टनेल स्थापित करण्यासाठी फक्त सर्व्हर-साइड सर्टिफिकेट आवश्यक असते. क्लायंट टनेलच्या आत दुय्यम अंतर्गत प्रमाणीकरण पद्धत वापरून प्रमाणीकरण करतो, सहसा युझरनेम आणि पासवर्डद्वारे.

BYOD वातावरण आणि मिश्र-OS नेटवर्क्ससाठी पसंतीचा पर्याय जेथे क्लायंट सर्टिफिकेट्स तैनात करणे व्यावहारिकदृष्ट्या अशक्य आहे.

802.1X

पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोलसाठी एक IEEE मानक जे LAN किंवा WLAN ला कनेक्ट होणाऱ्या डिव्हाइसेससाठी प्रमाणीकरण यंत्रणा प्रदान करते. हे सप्लिकंट, ऑथेंटिकेटर आणि ऑथेंटिकेशन सर्व्हरच्या भूमिका परिभाषित करते.

पायाभूत फ्रेमवर्क जे एंटरप्राइझ नेटवर्क्सना एका सामायिक पासवर्डवर अवलंबून राहण्याऐवजी वैयक्तिक डिव्हाइसेसचे प्रमाणीकरण करण्यास सक्षम करते. EAP-TLS आणि EAP-TTLS दोन्ही या फ्रेमवर्क अंतर्गत कार्य करतात.

RADIUS (Remote Authentication Dial-In User Service)

एक नेटवर्किंग प्रोटोकॉल जो नेटवर्क सेवेशी कनेक्ट होणाऱ्या युझर्ससाठी केंद्रीकृत प्रमाणीकरण, अधिकृतता आणि अकाउंटिंग व्यवस्थापन प्रदान करतो. 802.1X उपयोजनांमध्ये, RADIUS सर्व्हर हा प्रमाणीकरण सर्व्हर असतो जो सर्टिफिकेट्स किंवा क्रेडेंशियल्सची पडताळणी करतो.

सर्टिफिकेट्स किंवा पासवर्ड्सची पडताळणी करणारा आणि नेटवर्क प्रवेश मंजूर करायचा की नाकारायचा याचे निर्देश ॲक्सेस पॉईंटला देणारा सर्व्हर घटक. समर्थित प्लॅटफॉर्म्समध्ये FreeRADIUS, Microsoft NPS आणि Cisco ISE समाविष्ट आहेत.

PKI (Public Key Infrastructure)

डिजिटल सर्टिफिकेट्स तयार करणे, व्यवस्थापित करणे, वितरित करणे, वापरणे, संग्रहित करणे आणि रद्द करण्यासाठी आवश्यक असलेल्या भूमिका, पॉलिसी, हार्डवेअर, सॉफ्टवेअर आणि प्रक्रियांचा संच. एका सामान्य एंटरप्राइझ PKI मध्ये ऑफलाइन रूट CA आणि ऑनलाइन जारी करणारी CA असते.

EAP-TLS प्रमाणीकरणामध्ये वापरले जाणारे क्लायंट आणि सर्व्हर सर्टिफिकेट्स जारी करण्यासाठी आवश्यक असलेली बॅकएंड इन्फ्रास्ट्रक्चर. PKI शिवाय, EAP-TLS तैनात केले जाऊ शकत नाही.

MDM (Mobile Device Management)

कर्मचाऱ्यांचे मोबाईल डिव्हाइसेस आणि लॅपटॉप्स यांचे निरीक्षण, व्यवस्थापन आणि सुरक्षितता राखण्यासाठी IT विभागांद्वारे वापरले जाणारे सॉफ्टवेअर. Microsoft Intune आणि Jamf सारखे MDM प्लॅटफॉर्म्स नोंदणीकृत डिव्हाइसेसवर सर्टिफिकेट्स आणि WiFi प्रोफाइल्सचे उपयोजन स्वयंचलित करू शकतात.

मोठ्या प्रमाणावर EAP-TLS साठी क्लायंट सर्टिफिकेट्सचे उपयोजन स्वयंचलित करण्यासाठी आवश्यक. MDM एकत्रीकरणाशिवाय, हजारो डिव्हाइसेसवर मॅन्युअली सर्टिफिकेट्स इन्स्टॉल करणे व्यावहारिकदृष्ट्या अशक्य आहे.

SCEP (Simple Certificate Enrollment Protocol)

नेटवर्क डिव्हाइसेसना डिजिटल सर्टिफिकेट्स जारी करणे स्वयंचलित करण्यासाठी वापरला जाणारा प्रोटोकॉल. MDM प्लॅटफॉर्म्स युझरच्या हस्तक्षेपाशिवाय नोंदणीकृत कॉर्पोरेट डिव्हाइसेसवर छुपेपणाने सर्टिफिकेट्सची विनंती आणि इन्स्टॉलेशन करण्यासाठी SCEP चा वापर करतात.

EAP-TLS उपयोजनांमध्ये झिरो-टच सर्टिफिकेट प्रोव्हिजनिंगसाठी मानक यंत्रणा. Microsoft Intune, Jamf आणि बहुतांश एंटरप्राइझ MDM प्लॅटफॉर्म्सद्वारे समर्थित.

CRL (Certificate Revocation List)

डिजिटल प्रमाणपत्रांची एक सूची जी जारी करणाऱ्या प्रमाणपत्र प्राधिकरणाद्वारे (Certificate Authority) त्यांच्या नियोजित समाप्ती तारखेपूर्वी रद्द केली गेली आहे. कनेक्ट होणाऱ्या डिव्हाइसचे प्रमाणपत्र अद्याप वैध आहे की नाही हे तपासण्यासाठी RADIUS सर्व्हर CRL तपासतात.

सर्टिफिकेट रद्द करून चोरीला गेलेले किंवा तडजोड झालेले डिव्हाइस ताबडतोब नेटवर्कवरून ब्लॉक करण्याची परवानगी देणारी यंत्रणा. RADIUS सर्व्हर्स वारंवार CRL तपासण्यासाठी कॉन्फिगर केले जावेत, किंवा रिअल-टाइम पडताळणीसाठी OCSP वापरावे.

X.509

सार्वजनिक की प्रमाणपत्रांचे स्वरूप परिभाषित करणारे ITU-T मानक. EAP-TLS आणि EAP-TTLS दोन्ही सर्व्हर प्रमाणीकरणासाठी X.509 प्रमाणपत्रे वापरतात. EAP-TLS ला क्लायंट डिव्हाइसवर देखील X.509 प्रमाणपत्रांची आवश्यकता असते.

सर्व एंटरप्राइझ PKI उपयोजनांमध्ये वापरला जाणारा प्रमाणपत्र स्वरूप. जेव्हा IT टीम 802.1X च्या संदर्भात 'डिजिटल प्रमाणपत्रे' असा उल्लेख करतात, तेव्हा त्यांचा अर्थ X.509 प्रमाणपत्रे असतो.

Inner authentication method

EAP-TTLS द्वारे स्थापित केलेल्या कूटबद्ध TLS बोगद्याच्या आत वापरला जाणारा दुय्यम प्रमाणीकरण प्रोटोकॉल. सामान्य अंतर्गत पद्धतींमध्ये PAP (Password Authentication Protocol), CHAP आणि MS-CHAPv2 समाविष्ट आहेत.

अंतर्गत प्रमाणीकरण पद्धतीची निवड EAP-TTLS उपयोजनाच्या सुरक्षा गुणधर्मांवर परिणाम करते. PAP बोगद्याच्या आत प्लेनटेक्स्ट स्वरूपात पासवर्ड पाठवतो; MS-CHAPv2 चॅलेंज-रिस्पॉन्स यंत्रणा वापरतो. बोगदा सर्व अंतर्गत प्रमाणीकरण ट्रॅफिक कूटबद्ध (encrypt) करतो.

सोडवलेली उदाहरणे

४०० स्टोअर्स असलेल्या राष्ट्रीय रिटेल साखळीला त्यांचे पॉइंट-ऑफ-सेल (POS) टर्मिनल्स आणि कर्मचार्‍यांचे हँडहेल्ड स्कॅनर सुरक्षित करणे आवश्यक आहे. हे वातावरण PCI-DSS ४.० च्या कक्षेत येते. सर्व डिव्हाइसेस Microsoft Intune मध्ये नोंदणीकृत आहेत. त्यांनी कोणता प्रोटोकॉल तैनात करावा आणि महत्त्वाच्या कॉन्फिगरेशन पायऱ्या कोणत्या आहेत?

EAP-TLS तैनात करा. पायरी १: एअर-गॅप्ड ऑफलाइन रूट CA आणि ऑनलाइन जारी करणार्‍या CA सह द्वि-स्तरीय PKI स्थापित करा. पायरी २: सर्व POS आणि स्कॅनर डिव्हाइसेसना लक्ष्य करणारे SCEP प्रमाणपत्र प्रोफाइलसह Microsoft Intune कॉन्फिगर करा. पायरी ३: RADIUS सर्व्हर (Microsoft NPS किंवा क्लाउड RADIUS) तैनात करा आणि अंतर्गत CA विरुद्ध क्लायंट प्रमाणपत्रे प्रमाणित करण्यासाठी ते कॉन्फिगर करा. पायरी ४: RADIUS सर्व्हरवर CRL चेकिंग किंवा OCSP सक्षम करा. पायरी ५: Intune द्वारे WiFi प्रोफाइल पुश करा ज्यामध्ये SSID, प्रमाणीकरण पद्धत म्हणून EAP-TLS, विश्वसनीय रूट CA आणि अपेक्षित RADIUS सर्व्हरचे नाव निर्दिष्ट असेल. पायरी ६: सर्व ४०० साइट्सवर रोल आउट करण्यापूर्वी १० डिव्हाइसेसच्या पायलट ग्रुपसह चाचणी करा. पायरी ७: प्रमाणपत्र संपण्याच्या ६०, ३० आणि सात दिवस आधी अलर्टसह प्रमाणपत्र मुदत संपण्याच्या देखरेखीची प्रक्रिया स्थापित करा.

परीक्षकाचे भाष्य: EAP-TLS हा योग्य पर्याय आहे कारण PCI-DSS ४.० कार्डधारक डेटा वातावरणातील वायरलेस नेटवर्कसाठी परस्पर प्रमाणपत्र प्रमाणीकरणाची जोरदार शिफारस करते. POS डिव्हाइसेससाठी पासवर्डवर (EAP-TTLS) अवलंबून राहिल्याने क्रेडेंशियल चोरीचा अस्वीकार्य धोका निर्माण होतो. SCEP द्वारे MDM एकत्रीकरण आवश्यक आहे - ४०० साइट्सवर व्यक्तिचलितपणे प्रमाणपत्र स्थापित करणे ऑपरेशनली अशक्य आहे. या परिस्थितीतील सर्वात सामान्य बिघाड बिंदू म्हणजे Intune WiFi प्रोफाइलमध्ये सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करण्यास विसरणे, ज्यामुळे EAP-TLS तैनात असूनही डिव्हाइसेस Evil Twin हल्ल्यांसाठी असुरक्षित राहू शकतात.

एका मोठ्या विद्यापीठ कॅम्पसला वैयक्तिक लॅपटॉप, स्मार्टफोन आणि टॅब्लेट (BYOD) चे मिश्रण वापरून २०,००० विद्यार्थ्यांसाठी सुरक्षित WiFi प्रदान करणे आवश्यक आहे. आयटी टीम वैयक्तिक डिव्हाइसेसवर प्रमाणपत्रे स्थापित करू शकत नाही. विद्यापीठ ओळख व्यवस्थापनासाठी Microsoft Entra ID वापरते. त्यांनी कोणता प्रोटोकॉल तैनात करावा?

अंतर्गत प्रमाणीकरण पद्धत म्हणून MS-CHAPv2 सह EAP-TTLS तैनात करा, जे RADIUS द्वारे Microsoft Entra ID सह एकत्रित केले जाईल. पायरी १: सर्व प्रमुख ऑपरेटिंग सिस्टम्सद्वारे विश्वसनीय असलेल्या सार्वजनिक CA कडून सर्व्हर प्रमाणपत्र मिळवा, किंवा अंतर्गत CA तैनात करा आणि व्यवस्थापित डिव्हाइसेससाठी विद्यापीठाच्या डिव्हाइस व्यवस्थापन साधनांद्वारे रूट प्रमाणपत्र वितरित करा. पायरी २: LDAP किंवा RADIUS प्रॉक्सी वापरून Microsoft Entra ID विरुद्ध प्रमाणित करण्यासाठी RADIUS सर्व्हर कॉन्फिगर करा. पायरी ३: विद्यार्थ्यांसाठी WiFi ऑनबोर्डिंग मार्गदर्शक तयार करा ज्यामध्ये SSID, EAP-TTLS, MS-CHAPv2 आणि विश्वसनीय CA निर्दिष्ट असेल. पायरी ४: Entra ID स्तरावर मजबूत पासवर्ड धोरणे लागू करा आणि सुरुवातीच्या नोंदणीसाठी मल्टी-फॅक्टर प्रमाणीकरण सक्षम करण्याचा विचार करा. पायरी ५: सर्व्हर प्रमाणपत्र प्रमाणीकरण लागू करण्यासाठी WiFi प्रोफाइल कॉन्फिगर करा आणि विश्वसनीय CA आणि RADIUS सर्व्हरचे नाव निर्दिष्ट करा.

परीक्षकाचे भाष्य: येथे EAP-TTLS हा एक व्यावहारिक पर्याय आहे. २०,००० व्यवस्थापित नसलेल्या वैयक्तिक डिव्हाइसेससाठी PKI व्यवस्थापित करणे व्यावहारिकदृष्ट्या अशक्य आहे. EAP-TTLS क्रेडेंशियल्ससाठी एक सुरक्षित टनेल प्रदान करते, जे त्यांना ओव्हर-द-एअर इंटरसेप्शनपासून सुरक्षित ठेवते आणि Windows, macOS, Linux, Android आणि iOS सह विविध ऑपरेटिंग सिस्टम्सना सपोर्ट करते. या परिस्थितीमधील मुख्य धोका म्हणजे विद्यार्थी सर्व्हर सर्टिफिकेटचे प्रमाणीकरण वगळण्यासाठी त्यांच्या डिव्हाइसेसचे चुकीचे कॉन्फिगरेशन करू शकतात. अचूक कॉन्फिगरेशन पायऱ्यांसह एक स्पष्ट ऑनबोर्डिंग मार्गदर्शक प्रकाशित केल्याने आणि सार्वजनिकरित्या विश्वसनीय सर्व्हर सर्टिफिकेट वापरल्याने हा धोका लक्षणीयरीत्या कमी होतो.

सराव प्रश्न

Q1. तुम्ही ५० ऑफिस लोकेशन्सवर पसरलेल्या ५,००० कॉर्पोरेट लॅपटॉप्सच्या ताफ्यासाठी EAP-TLS उपयोजित करत आहात. Microsoft Intune द्वारे WiFi प्रोफाइल पुश केल्यानंतर, डिव्हाइसेस कनेक्ट होण्यास अयशस्वी ठरत आहेत. RADIUS सर्व्हर लॉग प्रत्येक अयशस्वी प्रमाणीकरण प्रयत्नासाठी 'Unknown CA' दर्शवत आहेत. याचे सर्वात संभाव्य कारण काय आहे आणि तुम्ही त्याचे निवारण कसे कराल?

टीप: क्लायंटच्या बाजूने प्रमाणपत्र प्रमाणीकरण साखळीचा विचार करा, आणि MDM प्रोफाइलमध्ये केवळ EAP पद्धत सेटिंगव्यतिरिक्त काय समाविष्ट असणे आवश्यक आहे ते पहा.

नमुना उत्तर पहा

क्लायंट डिव्हाइसेस RADIUS सर्व्हरचे प्रमाणपत्र जारी करणाऱ्या अंतर्गत प्रमाणपत्र प्राधिकरणावर (Certificate Authority) विश्वास ठेवण्यासाठी कॉन्फिगर केलेले नाहीत. MDM WiFi प्रोफाइलमध्ये रूट CA प्रमाणपत्र (आणि कोणतेही इंटरमीडिएट CA प्रमाणपत्रे) समाविष्ट असणे आवश्यक आहे आणि सर्व्हर प्रमाणीकरणासाठी त्यांच्यावर विश्वास ठेवण्यासाठी सप्लिकंटला कॉन्फिगर करणे आवश्यक आहे. याशिवाय, क्लायंट RADIUS सर्व्हरचे प्रमाणपत्र नाकारतो आणि हँडशेक संपुष्टात आणतो. उपाय: 'Root certificate for server validation' सेटिंग अंतर्गत विश्वसनीय रूट CA प्रमाणपत्र समाविष्ट करण्यासाठी Intune WiFi प्रोफाइल अपडेट करा आणि हे प्रोफाइल सर्व डिव्हाइसेसवर पुन्हा पुश करा.

Q2. तुमच्या संस्थेने मिश्र BYOD वातावरणासाठी EAP-TTLS उपयोजित केले आहे. एका सुरक्षा पुनरावलोकनादरम्यान, तुमच्या पेनिट्रेशन टेस्टिंग टीमने हे दाखवून दिले की ते सेल्फ-साईन्ड प्रमाणपत्रासह बनावट ॲक्सेस पॉइंट सेट करून वापरकर्त्यांचे क्रेडेंशियल्स मिळवू शकतात. EAP-TLS वर स्थलांतर न करता तुम्ही या असुरक्षिततेचे निवारण कसे कराल?

टीप: अंतर्गत प्रमाणीकरण होण्यापूर्वी काय घडते आणि क्लायंटच्या बाजूने कोणते कॉन्फिगरेशन अविश्वासू सर्व्हरसह TLS बोगदा स्थापित होण्यापासून प्रतिबंधित करते याचा विचार करा.

नमुना उत्तर पहा

ही असुरक्षितता अस्तित्वात आहे कारण क्लायंट डिव्हाइसेस RADIUS सर्व्हरचे प्रमाणपत्र प्रमाणित करण्यासाठी कॉन्फिगर केलेले नाहीत. निवारण: सर्व्हर प्रमाणपत्र प्रमाणीकरण सक्तीचे करण्यासाठी सर्व WiFi प्रोफाइल (व्यवस्थापित डिव्हाइसेससाठी MDM द्वारे, आणि BYOD साठी नवीन ऑनबोर्डिंग मार्गदर्शकाद्वारे) अपडेट करा. प्रोफाइलमध्ये विश्वसनीय CA आणि अपेक्षित RADIUS सर्व्हरचे नाव निर्दिष्ट करा. अशा प्रकारे कॉन्फिगर केलेले क्लायंट निर्दिष्ट विश्वसनीय CA द्वारे स्वाक्षरी केलेले प्रमाणपत्र सादर करू न शकणाऱ्या कोणत्याही सर्व्हरसह TLS बोगदा स्थापित करण्यास नकार देतील, ज्यामुळे बनावट ॲक्सेस पॉइंटचा हल्ला करण्याचा मार्ग नष्ट होईल.

Q3. हॉस्पिटलचे IT डायरेक्टर त्यांच्या वैद्यकीय IoT डिव्हाइसेससाठी (इन्फ्युजन पंप, पेशंट मॉनिटर्स, पर्यावरणीय सेन्सर) 802.1X उपयोजित करू इच्छितात. ते EAP-TTLS चा विचार करत आहेत कारण त्यांचे असे मत आहे की प्रमाणपत्र व्यवस्थापन अत्यंत गुंतागुंतीचे आहे. हा युक्तिवाद चुकीचा का आहे आणि योग्य दृष्टिकोन कोणता आहे?

टीप: हेडलेस IoT डिव्हाइसेस प्रमाणीकरण प्रॉम्प्ट्स कसे हाताळतात आणि जेव्हा एखादे डिव्हाइस क्रेडेंशियल्स प्रविष्ट करू शकत नाही तेव्हा काय होते याचा विचार करा.

नमुना उत्तर पहा

हा युक्तिवाद दोन कारणांमुळे चुकीचा आहे. पहिले म्हणजे, बहुतेक स्क्रीन नसलेल्या वैद्यकीय IoT उपकरणांमध्ये क्रेडेंशियल्स प्रविष्ट करण्यासाठी युझर इंटरफेस नसतो, ज्यामुळे युझरनेम/पासवर्ड इनर ऑथेंटिकेशनसह EAP-TTLS चा वापर करणे व्यावहारिकदृष्ट्या अशक्य होते. दुसरे म्हणजे, प्रत्यक्ष वापरात IoT साठी EAP-TLS प्रत्यक्षात सोपे आहे: उपयोजनापूर्वी डिव्हाइस स्टेजिंग दरम्यान प्रमाणपत्रे प्रदान केली जाऊ शकतात, आणि उपकरण कोणत्याही युझर हस्तक्षेपाशिवाय आपोआप ऑथेंटिकेट होते. योग्य दृष्टीकोन म्हणजे स्टेजिंग दरम्यान वापरल्या जाणाऱ्या डिव्हाइस मॅनेजमेंट सिस्टीमद्वारे प्रदान केलेल्या प्रमाणपत्रांसह EAP-TLS वापरणे होय. हे आरोग्य सेवा वातावरणात मजबूत वायरलेस ऑथेंटिकेशनसाठी HIPAA च्या आवश्यकता देखील पूर्ण करते.

Q4. तुम्ही २०० मालमत्ता असलेल्या हॉटेल समूहाचे नेटवर्क आर्किटेक्ट आहात. तुम्हाला ३,००० व्यवस्थापित कर्मचारी उपकरणांसाठी (Intune मध्ये नोंदणीकृत) Staff WiFi सुरक्षित करणे आवश्यक आहे आणि स्वतःचे लॅपटॉप आणणाऱ्या कंत्राटदार आणि बाह्य विक्रेत्यांना सुरक्षित WiFi देखील प्रदान करणे आवश्यक आहे. या ऑथेंटिकेशन आर्किटेक्चरची रचना करा.

टीप: एकच SSID आणि एकच EAP पद्धत या दोन्ही प्रकारच्या वापरकर्त्यांना सेवा देऊ शकते का, आणि दोन युझर प्रकारांमुळे नेटवर्क सेगमेंटेशनवर काय परिणाम होतो याचा विचार करा.

नमुना उत्तर पहा

वेगळ्या ऑथेंटिकेशन पद्धती आणि VLAN असाइनमेंटसह दोन स्वतंत्र SSID तैनात करा. SSID 1 (Staff WiFi): EAP-TLS, Intune SCEP द्वारे पाठवलेली प्रमाणपत्रे, हॉटेल व्यवस्थापन प्रणालींमध्ये पूर्ण प्रवेशासह कर्मचारी नेटवर्क सेगमेंटला नियुक्त केलेले VLAN. SSID 2 (कंत्राटदार WiFi): MS-CHAPv2 सह EAP-TTLS, वेगळ्या डिरेक्टरी किंवा Microsoft Entra ID मधील वेळ मर्यादित कंत्राटदार खात्याद्वारे क्रेडेंशियल्सची पडताळणी, अंतर्गत प्रणालींमध्ये प्रवेश नसलेल्या केवळ-इंटरनेट आयसोलेटेड सेगमेंटला नियुक्त केलेले VLAN. दोन्ही SSID ने सर्व्हर प्रमाणपत्र पडताळणी लागू करणे आवश्यक आहे. हे आर्किटेक्चर कर्मचाऱ्यांना सर्वोच्च सुरक्षा प्रदान करते आणि कंत्राटदारांना व्यावहारिक ऑथेंटिकेशन पद्धत देते, तसेच नेटवर्क सेगमेंटेशन हे सुनिश्चित करते की कंत्राटदाराचे क्रेडेंशियल तडजोड झाले तरीही ते हॉटेलच्या अंतर्गत व्यवस्थापन प्रणालींपर्यंत पोहोचू शकत नाहीत.

या मालिकेमध्ये पुढे वाचा

पाहुण्यांच्या WiFi साठी RADIUS प्रमाणीकरण कॉन्फिगर करण्यासाठी नेटवर्क ॲडमिनिस्ट्रेटरचे मार्गदर्शक

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

मार्गदर्शिका वाचा →

Guest आणि Staff WiFi नेटवर्क्ससाठी RADIUS Authentication कॉन्फिगर करणे

हे तांत्रिक संदर्भ मार्गदर्शक एंटरप्राइझ guest आणि staff WiFi नेटवर्क्ससाठी RADIUS authentication च्या आर्किटेक्चर, कॉन्फिगरेशन आणि डिप्लॉयमेंटची रूपरेषा स्पष्ट करते. हे नेटवर्क आर्किटेक्ट्स आणि IT मॅनेजर्सना सुरक्षित, स्केलेबल वायरलेस ॲक्सेस कंट्रोल सिस्टम्स तयार करण्यासाठी आवश्यक असलेले अचूक प्रोटोकॉल्स, सुरक्षा मानके आणि ट्रबलशूटिंग पद्धती प्रदान करते.

मार्गदर्शिका वाचा →

Passpoint आणि OpenRoaming: संपूर्ण मार्गदर्शक

हे तांत्रिक संदर्भ मार्गदर्शक एंटरप्राइझ WiFi नेटवर्कमधील Passpoint (Hotspot 2.0) आणि WBA OpenRoaming फ्रेमवर्कचे सर्वसमावेशक विश्लेषण प्रदान करते. हे सुरक्षित, विनाव्यत्यय अतिथी कनेक्टिव्हिटी स्थापित करण्यासाठी आवश्यक असणारे मूलभूत ऑथेंटिकेशन प्रोटोकॉल, आर्किटेक्चरल घटक आणि डिप्लॉयमेंट धोरणांचे सविस्तर वर्णन करते. नेटवर्क आर्किटेक्ट्स आणि IT लीडर्स एंटरप्राइझ-दर्जाची सुरक्षा राखून मॅन्युअल लॉगिनचे अडथळे दूर करण्यासाठी या मानकांची रचना, अंमलबजावणी आणि ट्रबलशूटिंग कसे करावे हे शिकतील.

मार्गदर्शिका वाचा →

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.

EAP-TLS विरुद्ध EAP-TTLS: आपण कोणते प्रमाणपत्र-आधारित WiFi प्रोटोकॉल निवडले पाहिजे? | Purple