EAP-TLS विरुद्ध PEAP: सुरक्षा, प्रमाणपत्रे आणि उपयुक्तता
Published
eap tls vs peap वर दिलेला सर्वात सामान्य सल्ला सुटसुटीत आणि चुकीचा आहे. EAP-TLS निवडा कारण ते "अधिक सुरक्षित," आहे आणि PEAP अशा टीम्ससाठी सोडा ज्या अजून प्रगत झालेल्या नाहीत. हे त्या प्रश्नाला बगल देते जो सोमवारी मल्टी - साइट WLAN अजूनही चालू आहे की नाही हे ठरवतो. ते वापरणे अपेक्षित असलेल्या प्रत्येक डिव्हाइससाठी तुम्ही प्रमाणपत्र वितरीत, नूतनीकरण आणि रद्द करू शकता का?
मी पूर्ण मालमत्तेवर एकच पद्धत लागू करणार नाही. EAP-TLS ही अशा उपकरणांवर वापरली पाहिजे जी तुम्ही नोंदवू शकता आणि नूतनीकरण करू शकता. PEAP, जवळजवळ नेहमीच अंतर्गत EAP-MSCHAPv2 सह, तिथे वापरली जावी जिथे डिरेक्टरी पासवर्ड आधीपासून अस्तित्वात आहे आणि प्रमाणपत्र नोंदणी व्यावहारिक नाही. कठीण पद्धत ही नेहमीच चालवता येण्याजोगी असेल असे नाही. हॉटेलच्या बॅक ऑफिसमधील कालबाह्य झालेले प्रमाणपत्र कर्मचाऱ्यांचे खाते वैध असतानाही त्यांना सिस्टममधून बाहेर ठेवू शकते. सर्व्हर तपासणी वगळणारे PEAP प्रोफाइल एखाद्या बनावट ॲक्सेस पॉइंटला डिरेक्टरी पासवर्ड सोपवू शकते. दोन्ही अपयश हे ऑपरेशनल आहेत. संपूर्ण नेटवर्कसाठी एकच पद्धत शोधण्याऐवजी ती पद्धत वापरकर्त्यांच्या वर्गवारीनुसार नियुक्त करा.
अनुक्रमणिका
- EAP-TLS आणि PEAP एकाच वेळी
- प्रत्येक पद्धत कशी ऑथेंटिकेट करते आणि पासवर्ड कुठे लीक होतात
- रोलआउटपूर्वी प्रमाणपत्राच्या आवश्यकता
- प्रमाणपत्र लाइफसायकल आणि रोलआउटचे प्रयत्न
- रिव्होकेशन रोमिंग स्पीड आणि क्लायंट सपोर्ट
- प्रत्येक लोकसंख्येची नियुक्ती करा आणि विभाजन सिद्ध करा
EAP-TLS आणि PEAP समोरासमोर
EAP-TLS आणि PEAP मधील व्यावहारिक फरक म्हणजे प्रत्येक एंडपॉइंट ज्या क्रेडेन्शियलला सपोर्ट करू शकतो ते आणि ते वापरण्यायोग्य ठेवण्यासाठी लागणारे काम. तुम्ही एनरोल आणि नूतनीकरण करू शकता अशा डिव्हाइसेससाठी EAP-TLS वापरा. जिथे युजर्सकडे आधीच डायरेक्टरी पासवर्ड आहेत आणि प्रमाणपत्र एनरोलमेंट व्यावहारिक नाही तिथे PEAP वापरा. प्रत्येक युजर बेससाठी कोणतीही एक पद्धत एकमेव योग्य उत्तर असू शकत नाही.
| निकष | EAP-TLS | PEAP |
|---|---|---|
| EAP प्रकार ID | 13 | 26 |
| क्लायंट क्रेडेंशियल | X.509 क्लायंट प्रमाणपत्र | वापरकर्तानाव आणि पासवर्ड, सहसा EAP-MSCHAPv2 किंवा EAP-GTC |
| सर्व्हर क्रेडेंशियल | RADIUS सर्व्हर प्रमाणपत्र | बाह्य TLS टनेलवर RADIUS सर्व्हर प्रमाणपत्र |
| परस्पर ऑथेंटिकेशन (Mutual authentication) | क्लायंट आणि सर्व्हर प्रमाणपत्रे | सर्व्हर प्रमाणपत्र अधिक अंतर्गत वापरकर्ता किंवा डिव्हाइस ऑथेंटिकेशन |
| वायरवरील पासवर्ड | काहीही नाही | होय, TLS टनेलच्या आत |
| क्लायंटने सर्व्हर तपासण्या वगळल्यास रोग AP (Rogue AP) काय चोरी करू शकतो | पासवर्डसारखे काहीही नाही; ऑथेंटिकेशन बंद स्थितीत अयशस्वी होते (fails closed) | डिरेक्टरी पासवर्ड |
| एका डिव्हाइसचे प्रमाणपत्र रद्द करणे (Revocation) | ते प्रमाणपत्र रद्द करा किंवा मुदत संपवा | खाते निष्क्रिय करा किंवा पुन्हा वापरला जाऊ शकणारा पासवर्ड रिसेट करा |
| PKI काम | सर्व्हर आणि क्लायंट प्रमाणपत्रे, नूतनीकरण आणि पुनर्प्राप्ती | केवळ सर्व्हर प्रमाणपत्र |
| सर्वोत्तम पहिली पसंती | MDM-व्यवस्थापित कर्मचारी आणि विशेषाधिकारप्राप्त डिव्हाइसेस | प्रमाणपत्रे नोंदवू न शकणारे अव्यवस्थापित एंडपॉइंट्स |
एक 2025 Authentik तांत्रिक लेख EAP-TLS ला EAP टाईप ID 13 आणि PEAP ला टाईप ID 26 म्हणून ओळखतो. हे ID RADIUS आणि सप्लिकंटच्या पद्धती ओळखतात. कोणत्या लोकांनी किंवा उपकरणांनी त्यांचा वापर करावा हे ते ठरवत नाहीत.
या ओळी प्रत्यक्षात काय बदलतात
क्लायंट क्रेडेन्शियल हे कर्यकारी सीमा निश्चित करते. EAP-TLS हे X.509 क्लायंट प्रमाणपत्र सादर करते. PEAP हे युझरनेम आणि पासवर्ड वापरते, सामान्यतः EAP-MSCHAPv2 किंवा EAP-GTC द्वारे. हे पद्धतींच्या तात्विक रँकिंगपेक्षा प्रमाणपत्र नोंदणी आणि नूतनीकरणाला मुख्य कार्यभार बनवते.
विश्वास तपासण्या देखील भिन्न असतात. EAP-TLS क्लायंट आणि सर्व्हर दोन्ही प्रमाणपत्रांचे प्रमाणीकरण करते. PEAP बाह्य TLS टनेलवर RADIUS सर्व्हर प्रमाणपत्राची पडताळणी करते, आणि नंतर अंतर्गत पद्धतीद्वारे वापरकर्ता किंवा डिव्हाइसचे प्रमाणीकरण करते.
पासवर्ड उघड होणे हे सप्लिकंट कॉन्फिगरेशनवर अवलंबून असते. EAP-TLS मध्ये वायरवर कोणताही पासवर्ड नसतो. PEAP टनेलच्या आत पासवर्ड घेऊन जातो, त्यामुळे सर्व्हर तपासण्यांकडे दुर्लक्ष करणारा क्लायंट डिरेक्टरी पासवर्ड एखाद्या बनावट ॲक्सेस पॉईंटला उघड करू शकतो. EAP-TLS सह, गहाळ किंवा अविश्वसनीय क्लायंट प्रमाणपत्रामुळे ऑथेंटिकेशन अयशस्वी होते.
ऑफबोर्डिंग हे कशाचे व्यवस्थापन केले जात आहे यावर देखील अवलंबून असते. एखाद्या व्यक्तीचा डिरेक्टरी पासवर्ड रिसेट न करता डिव्हाइस प्रमाणपत्र रद्द केले जाऊ शकते किंवा ते कालबाह्य होऊ दिले जाऊ शकते. खाते निष्क्रिय केल्याने किंवा पुन्हा वापरलेला पासवर्ड बदलल्याने त्या क्रेडेंशियलशी जोडलेल्या इतर लॉगिनवर परिणाम होऊ शकतो.
ऑपरेशनल तडजोड स्पष्ट आहे: EAP-TLS ला क्लायंट प्रमाणपत्रे, नूतनीकरण आणि रिकव्हरी पाथची आवश्यकता असते, तर PEAP ला सर्व्हर प्रमाणपत्र आणि काळजीपूर्वक सप्लिकंट कॉन्फिगरेशनची आवश्यकता असते. नोंदणीकृत कर्मचारी आणि विशेषाधिकारप्राप्त उपकरणांना EAP-TLS नियुक्त करा; प्रमाणपत्र व्यवस्थापनात समाविष्ट न होऊ शकणाऱ्या अनमॅनेज्ड एंडपॉइंट्ससाठी PEAP ठेवा. सदस्यत्व प्लॅटफॉर्मसाठी सर्व्हरलेस पायाभूत सुविधा चालवणाऱ्या टीम्सकडे भिन्न सदस्य, कर्मचारी आणि डिव्हाइस वर्गवारी असू शकते, परंतु होस्टिंग मॉडेल प्रमाणीकरण पद्धत ठरवत नाही. क्रेडेंशियल हे तुम्ही ज्यांचे व्यवस्थापन करू शकता त्याच्याशी जुळणारे असणे आवश्यक आहे.
प्रत्येक पद्धत कशी प्रमाणीकृत करते आणि पासवर्ड कुठे लीक होतात
EAP-TLS हे प्रत्येक वापरकर्त्यासाठी आपोआप योग्य उत्तर ठरत नाही. तुमची टीम प्रत्येक युझर ग्रुपसाठी प्रमाणपत्रे विश्वासार्हपणे जारी, नूतनीकरण आणि रद्द करू शकते की नाही हा मुख्य निर्णय आहे. PEAP अनमॅनेज्ड वापरकर्त्यांसाठी ऑनबोर्डिंग सोपे ठेवते, परंतु त्याचा पासवर्ड योग्य सप्लिकंट कॉन्फिगरेशनवर अवलंबून असतो.
दोन्ही पद्धती 802.1X वापरतात. सप्लिकंट हे ॲक्सेसची विनंती करणारे डिव्हाईस आहे, ऑथेंटिकेटर हे ती विनंती रिले करणारे ॲक्सेस पॉईंट किंवा स्विच आहे आणि RADIUS सर्व्हर ते स्वीकारतो किंवा नाकारतो. ते EAP फ्रेमवर्क शेअर करतात, क्रेडेंशियल नाही.
IETF EAP मानके निर्देशांक, IETF RFC 5216 मध्ये परिभाषित EAP-TLS ला परस्पर ऑथेंटिकेशन, परस्पर सुरक्षितता-संरक्षित सायफर-सूट वाटाघाटी आणि की मिळवण्यासह (key derivation) प्रमाणपत्र-आधारित क्लायंट आणि सर्व्हर ऑथेंटिकेशन म्हणून वर्णन करतो. हे मानक मार्च 2008 मध्ये प्रकाशित झाले होते. व्यावहारिकदृष्ट्या, EAP-TLS ला RADIUS सर्व्हर प्रमाणपत्रासोबत PKI द्वारे जारी केलेले क्लायंट प्रमाणपत्र आवश्यक असते.
दोन क्रम, एक फ्रेमवर्क
EAP-TLS एका TLS एक्सचेंजमध्ये दोन्ही एंडपॉइंट्सचे प्रमाणीकरण करते:
- supplicant हा authenticator सह EAP सुरू करतो, जो RADIUS कडे ही विनंती पाठवतो.
- TLS एक्सचेंज दरम्यान सर्व्हर आणि क्लायंट प्रमाणपत्रांची तपासणी केली जाते.
- हा एक्सचेंज सायफर-सूट निगोशिएशनचे संरक्षण करतो आणि कीज तयार करतो, ज्यामुळे फिशिंग, रिप्ले किंवा ब्रूट-फोर्स केला जाऊ शकेल असा पासवर्ड पाठवला जात नाही.
- गहाळ किंवा अमान्य क्लायंट प्रमाणपत्र असण्याचा अर्थ असा की डिव्हाइस नाकारले गेले आहे. ते पासवर्ड टाईप करण्याच्या पर्यायावर परत जाऊ शकत नाही.
PEAP एक बाह्य TLS बोगदा तयार करतो जो सर्व्हरचे प्रमाणीकरण करतो, नंतर अंतर्गत पद्धत चालवतो, सामान्यतः EAP-MSCHAPv2 किंवा EAP-GTC. अंतर्गत पद्धत युझरनेम आणि पासवर्ड वापरू शकत असल्याने, एंडपॉइंट्सना सामान्यत: क्लायंट प्रमाणपत्रांची आवश्यकता नसते. IETF EAP तपशील निर्देशांक देखील या पद्धती वापरत असलेल्या मानकांच्या फ्रेमवर्कचे वर्णन करतो.
वापरकर्त्यांना PEAP चे आऊटर टनेल दिसत नाही. इनर आयडेंटिटी, जी सहसा युझरनेम आणि पासवर्ड किंवा टोकन असते, ती TLS स्थापित झाल्यानंतरच पाठवली जाते. यामुळे डिरेक्टरी-आधारित सप्लिकंट्ससाठी PEAP परिचित बनते, परंतु क्लायंटने टनेलचे योग्यरित्या सत्यापन केले नाही तर पासवर्ड उघडा पडण्याचा धोका असतो.
अंतर्गत EAP-TLS सह PEAP ही अधिक गुंतागुंतीची विशेष केस आहे, जी प्रमाणपत्र पद्धतीला बाह्य TLS टनेलसह एकत्रित करते. "PEAP" असे लेबल असलेल्या डिप्लॉयमेंटचा सामान्यतः अर्थ PEAP-MSCHAPv2 असा होतो.
जिथे सप्लिकंट निकाल ठरवतो
एक enterprise wireless EAP methods write-up मधील फरक स्पष्ट करतो: EAP-TLS म्युच्युअल X.509 ऑथेंटिकेशन वापरते. RADIUS क्लायंट प्रमाणपत्राची पडताळणी करते आणि क्लायंट सर्व्हर प्रमाणपत्राची पडताळणी करतो. फिंशिंग, रिप्ले किंवा ब्रूट - फोर्स करण्यासाठी कोणताही पासवर्ड उपलब्ध नसतो. हा लेख असेही सांगतो की NIST साठी वायरलेस स्टेशन आणि ऑथेंटिकेशन सर्व्हर या दोघांकडे वैध प्रमाणपत्रे असणे आवश्यक आहे.
PEAP सह, क्लायंटने RADIUS प्रमाणपत्र साखळी आणि अपेक्षित सर्व्हर नाव व्हॅलिडेट केले पाहिजे. यापैकी कोणतीही तपासणी गहाळ असल्यास, एखादे बनावट ॲक्सेस पॉइंट डिरेक्टरी पासवर्ड मागू शकते. "व्हॅलिडेट करू नका" वर सेट केलेले सप्लिकंट प्रोफाईल पासवर्डचे रक्षण करत नाही.
व्यावहारिक नियम: WiFi प्रोफाईलमध्ये RADIUS सर्व्हरचे नाव आणि जारी करणारे CA पिन करा. या तपासण्यांशिवाय, PEAP एखाद्या बनावट सर्व्हरला पासवर्ड ऑफर करू शकते.
बनावट टनेलद्वारे आक्रमणकर्त्याला ते मिळाल्यानंतर हस्तगत केलेले MS-CHAPv2 प्रतिसाद ऑफलाईन क्रॅक केले जाऊ शकतात. टनेलचे प्रमाणीकरण हे नियंत्रण आहे; अंतर्गत पद्धत अविश्वासू सर्व्हर स्वीकारणाऱ्या प्रोफाइलची सुटका करत नाही. तोच पासवर्डचा धोका केवळ WiFi पुरता मर्यादित नाही. ऑस्ट्रेलियन लहान व्यवसायांमधील तडजोड केलेल्या क्रेडेशिअलच्या अहवालांवरून हे अधोरेखित होते की पुनरुपरोग केलेला डिरेक्टरी पासवर्ड आक्रमणकर्त्यासाठी का महत्त्वाचा राहतो.
व्यवस्थापित डिव्हाइसेस आणि वापरकर्त्यांना EAP-TLS असाइन करा ज्यांचे प्रमाणपत्र लाइफसायकल तुम्ही ऑपरेट करू शकता. जिथे वापरकर्ते किंवा डिव्हाइसेस विश्वसनीयपणे प्रमाणपत्रे मिळवू शकत नाहीत आणि नूतनीकरण करू शकत नाहीत तिथे PEAP वापरा, परंतु सप्लिकंट प्रोफाइलद्वारे सर्व्हर - नाव आणि CA व्हेलिडेशन लागू करा. ऑपरेशनल तडजोड थेट आहे: प्रमाणपत्रांसाठी नोंदणी आणि पुनर्प्राप्तीचे काम लागते, तर पासवर्ड तुम्हाला पुनर्वापर आणि खाते बदल व्यवस्थापित करण्यास भाग पाडतात. उत्तम पद्धत ही तुम्ही कोणाचे व्यवस्थापन करू शकता यावर अवलंबून असते, प्रत्येक SSID साठी एकच विजेता घोषित करण्यावर नाही.
रोलआउटपूर्वीच्या प्रमाणपत्र आवश्यकता
पहिल्या प्रॉडक्शन जॉईनपूर्वी लॅबमध्ये या सहा बाबींची पुष्टी करा. गहाळ साखळी किंवा चुकीचे नाव हे प्रमाणपत्र चुकांसारखे न दिसता "WiFi बंद आहे" असे दिसेल.
- RADIUS सर्व्हर प्रमाणपत्र. हे तुमच्या प्रायव्हेट CA कडून इश्यू करा. सप्लिकंट प्रोफाईल पिन करत असलेले नाव सब्जेक्ट किंवा SAN मध्ये टाका. सर्व्हर ऑथेंटिकेशन युसेज सेट करा आणि प्रमाणपत्रासह पूर्ण इंटरमिडिएट साखळी सर्व्ह करा. कोणत्याही मॅचिंग नावावर स्वाक्षरी करणारा पब्लिक CA हे अंतर्गत RADIUS नावासाठी चुकीचे ट्रस्ट मॉडेल आहे.
- क्लायंट प्रमाणपत्र. प्रति डिव्हाइस किंवा युजर एक, क्लायंट ऑथेंटिकेशन युसेजसह. SAN मध्ये युजर प्रिन्सिपल नेम किंवा डिव्हाइस सिरीयल यासारखी एक युनिक ओळख ठेवा. प्लॅटफॉर्म सपोर्ट करत असताना प्रायव्हेट की TPM किंवा सुरक्षित एन्क्लेव्हमध्ये स्टोअर करा.
- ट्रस्ट अँकर. MDM प्रोफाईलद्वारे अंतर्गत रूट किंवा इश्यूइंग CA इन्स्टॉल करा. डिव्हाइसेसना पब्लिक रूटकडे निर्देशित करू नका आणि नाव तपासणी पुरेशी आहे अशी आशा ठेवू नका.
- वैधता आणि नूतनीकरण. सर्व्हर प्रमाणपत्रासाठी आणि क्लायंट प्रमाणपत्रांसाठीचा कालावधी प्रकाशित करा. एक ओव्हरलॅप विंडो तयार करा जेणेकरून जुने प्रमाणपत्र एक्सपायर होण्यापूर्वी नवीन इन्स्टॉल केले जाईल.
- रिव्होकेशन. RADIUS सर्व्हरला तो पोहोचू शकेल असा CRL किंवा OCSP एंडपॉईंट द्या. तो एंडपॉईंट ऑफलाईन असताना ऑथेंटिकेशन अयशस्वी होते की पुढे जाते हे लिखित स्वरूपात ठरवा. ऑफलाईन केस टेस्ट करा. WAN ब्लिप दरम्यान याचा शोध घेऊ नका.
- एनरोलमेंट चॅनेल. MDM द्वारे SCEP किंवा PKCS#12 सह प्रमाणपत्रे पाठवा. तुम्ही समूहाला टार्गेट करण्यापूर्वी नूतनीकरणासह एका डिव्हाइसवर ते सिद्ध करा.
समजा एका क्लिनिक साइटवर कर्मचाऱ्यांच्या ओळखीसाठी Okta आणि लॅपटॉपसाठी Intune वापरले जाते. प्रोफाईलमधील RADIUS नाव प्रमाणपत्राशी जुळले पाहिजे, आणि क्लिनिकल VLAN वर जाणाऱ्या Okta ग्रुपची नोंदणी MDM द्वारेच केली पाहिजे. आमचे Okta WiFi authentication मधील नोट्स लॅबला पासवर्ड SSID मध्ये न बदलता ती ओळख हस्तांतरित करतात.
एका चाचणी लॅपटॉपला कनेक्ट करा, त्याचे प्रमाणपत्र मागे घ्या (revoke करा), आणि तुम्ही थेट फ्लोअरला स्पर्श करण्यापूर्वी पुढील असोसिएशन अयशस्वी झाल्याची पुष्टी करा.
प्रमाणपत्र जीवनचक्र आणि रोलआउटचे प्रयत्न
EAP-TLS सुरक्षा ही आउटेजमध्ये बदलते जेव्हा एखादे प्रमाणपत्र एक्सपायर होते, किंवा जेव्हा क्लायंट रिव्होकेशन माहितीपर्यंत पोहोचू शकत नाही आणि युझर खाते अजूनही पूर्णपणे वैध असते. हा विचारण्यासारखा प्रश्न आहे. "प्रमाणपत्रे कठीण आहेत" ही काही डिझाईन नाही.
NIST स्पेशल पब्लिकेशन 800-120 याच दायित्वाबद्दल सांगते. EAP-TLS ला विश्वासार्ह इश्युआन्स, डिस्ट्रिब्युशन, नूतनीकरण, ट्रस्ट-चेन व्यवस्थापन आणि रिव्होकेशन चेकिंग ची आवश्यकता असते. एक्स्पायर झालेले प्रमाणपत्र असलेले डिव्हाइस किंवा पोहोचण्यायोग्य नसलेली रिव्होकेशन सर्व्हिस यामुळे युजरची ओळख वैध असूनही नेटवर्क ॲक्सेस बंद होऊ शकतो. PEAP सहसा आऊटर TLS टप्प्यात सर्वर ऑथेंटिकेट करते आणि MS-CHAPv2 सारख्या इनर पद्धतीद्वारे युजरनेम आणि पासवर्ड ऑथेंटिकेट करते, त्यामुळे क्लायंट लाईफसायकलची पायरी वगळली जाते. सुरुवातीचा पहिला दिवस सोपा वाटला तरी नंतर पासवर्ड रिसेट आणि चुकीच्या प्रोफाईल्समुळे काम वाढते.
प्रमाणपत्रांना आउटेज बनण्यापासून रोखा
डिझाइनचा प्रतिसाद स्वयंचलन (automation) हा आहे, मोठा रनबुक नाही.
- MDM द्वारे एनरोल करा. प्रोफाइल, ट्रस्ट अँकर आणि प्रमाणपत्र एकत्र पुश करा. मॅन्युअल WiFi सेटअपमुळे सर्वर-नेम चेक्स अनटिक होतात.
- ओव्हरलॅप नूतनीकरण. जुने प्रमाणपत्र एक्स्पायर होण्यापूर्वी नवीन प्रमाणपत्र इन्स्टॉल करा. ज्या वीकेंडला प्रत्येक लॅपटॉप एकाच वेळी बंद पडतो, तिथे ओव्हरलॅप वेळ खूप कमी होती.
- ऑफलाईन रिव्होकेशन तपासा. CRL किंवा OCSP फेच करता येत नसताना RADIUS फेल-क्लोज्ड होते की फेल-ओपन होते ते जाणून घ्या.
- रिकव्हरी मार्ग ठेवा. अयशस्वी झालेल्या एंडपॉइंटला मागे येण्यासाठी "कोणाचा तरी PEAP पासवर्ड मागणे" याव्यतिरिक्त पर्याय असावा. व्हाईटबोर्डवर लिहिलेल्या शेअर केलेल्या सीक्रेटपेक्षा वायर असलेला हेल्पडेस्क पोर्ट किंवा सुरक्षित रिकव्हरी SSID उत्तम ठरतो.
Purple Access हे Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru, आणि Addigy कडून SCEP द्वारे वितरीत केलेले EAP-TLS प्रमाणपत्रे घेते, ज्यामध्ये प्रत्येक डिव्हाइसऐवजी संस्थेसाठी एकदाच पाच ते दहा मिनिटांचा सेटअप वेळ लागतो. सुरक्षित नेटवर्क पासवर्डलेस आणि प्रमाणपत्र - आधारित आहे, आणि पोस्चरमध्ये अयशस्वी होणाऱ्या डिव्हाइसला Conditional Access द्वारे ऑथेंटिकेशनच्या वेळी नाकारले जाते. ही एक अनुपालन - गेट केलेली नोंदणी आहे, दुसरी पासवर्ड प्रॉम्प्ट नाही.
जेंव्हा PKI अपुरे विकसित असते, जेंव्हा कंत्राटदारांचा MDM मध्ये समावेश केला जाऊ शकत नाही, किंवा जेंव्हा मिश्र BYOD वातावरण प्रमाणपत्र स्वीकारणार नाही, तेंव्हा PEAP हा सोपा पर्याय राहतो. आरोग्यसेवा, शिक्षण, आदरातिथ्य (hospitality) आणि इतर अनेक-साइट वरील ताफ्यांना एकाच वेळी या तिन्ही आव्हानांचा सामना करावा लागतो. व्यवस्थापित कॉर्पोरेट, कर्मचारी आणि उच्च - जोखीम असलेल्या उपकरणांसाठी EAP-TLS वापरा. अनमॅनेज्ड किंवा तात्पुरत्या एंडपॉइंट्ससाठी कडकपणे नियंत्रित पर्याय ठेवा. व्हेन्यू - स्केल ओळख हा महत्त्वाचा निर्णय आहे, TLS ने पासवर्डला हरवले असा नारा नाही.
जर RADIUS स्वतःच नाजूक भाग असेल, तर होस्ट केलेले बॅकएंड "HQ मधील कपाटातील एक सर्व्हर" अपयश काढून टाकते. तुम्ही EAP पद्धतीला दोष देण्यापूर्वी रीचेबिलिटी आणि रिडंडन्सी तपासण्यासाठी आमचा RADIUS as a service वरील लेख ही योग्य जागा आहे.
खालील संक्षिप्त वॉकथ्रू पासवर्ड अंतर्गत पद्धतीसोबत प्रमाणपत्र नोंदणी दाखवतो, जो नूतनीकरणास उशीर झाल्यावर हेल्पडेस्कला दिसणारा फरक आहे.
रिव्होकेशन रोमिंग गती आणि क्लायंट सपोर्ट
सपोर्ट आणि स्पीड या लुकअपच्या समस्या आहेत. सध्याचे Windows, macOS, iOS, Android, आणि ChromeOS सप्लिकंट्स दोन्ही पद्धतींचा वापर करतात. अयशस्वी मोड हाच फक्त वेगळा आहे.
जेव्हा प्रोफाईल, इश्यू करणारे CA किंवा वैधतेच्या तारखा चुकीच्या असतात तेव्हा EAP-TLS अयशस्वी होते. जेव्हा इनर पद्धत, आयडेंटिटी फॉरमॅट किंवा सर्व्हर-नेम तपासणी RADIUS पॉलिसीशी जुळत नाही तेव्हा PEAP अयशस्वी होते. कोणत्याही अपयशाचा अर्थ असा नाही की ॲक्सेस पॉइंट "एंटरप्राइझला सपोर्ट करत नाही."
रिव्होकेशनचेही असेच विभाजन आहे. एका डिव्हाईसचे प्रमाणपत्र डिसेबल केल्याने त्या व्यक्तीच्या इतर लॉगइनला स्पर्श न करता तो लॅपटॉप डिस्कनेक्ट होतो. डिरेक्टरी पासवर्ड रिसेट केल्याने तो अजूनही वापरत असलेल्या प्रत्येक अनमॅनेज्ड क्लायंटवर परिणाम होतो. तात्काळ, डिव्हाईस-विशिष्ट कट-ऑफ हा EAP-TLS चा फायदा आहे. मुदत संपलेल्या प्रमाणपत्रांमुळे होणारे गंभीर अपयश ही त्याची किंमत आहे.
हँडशेक्स, ब्रँडची नावे नाहीत
वायरलेस प्रमाणीकरण लेटन्सीवरील एक ACM पेपर दर्शवतो की कार्यप्रदर्शन हे पद्धतीच्या नावापेक्षा हँडशेक संख्या, रोमिंग, प्रमाणपत्र सत्यापन आणि बॅकएंड लेटन्सीवर जास्त अवलंबून असते. मानक EAP-TLS त्याच्या TLS एक्सचेंजमध्ये क्लायंट आणि सर्व्हर प्रमाणपत्र प्रमाणीकरण पूर्ण करते. PEAP एक TLS टनेल स्थापित करते आणि नंतर अंतर्गत प्रमाणीकरण चालवते, ज्यामुळे एक वेगळा टप्पा जोडला जातो. त्या पेपरमध्ये नमूद केलेली Cisco तांत्रिक माहिती सांगते की अंतर्गत EAP-TLS सह PEAP मध्ये दोन TLS हँडशेक समाविष्ट असतात आणि जेव्हा रोमिंग दरम्यान पूर्ण री-ऑथेंटिकेशन होते तेव्हा ते मंद होऊ शकते.
याचे स्वतंत्रपणे मापन करा. एका सरासरी लॉगिन वेळेवरून विजेता ठरवू नका.
- 95 वे-पर्सेंटाईल असोसिएशन-टू-IP वेळ
- पूर्ण ऑथेंटिकेशन विरुद्ध रोम-रिझम्पशन लॅटन्सी
- RADIUS राउंड-ट्रिप वेळ
- ऑथेंटिकेशन अपयश दर
- प्रमाणपत्र-नूतनीकरण अपयश
सेशन पुन्हा सुरू करणे, PMK caching किंवा 802.11r, स्थानिक RADIUS पोहोचयोग्यता, आणि एक लहान प्रमाणपत्र साखळी ही सायफर सूट बदलण्यापेक्षा या आकड्यांना जास्त प्रभावित करतात. PEAP पहिल्या दिवशी सोपे वाटू शकते आणि तरीही वारंवार पासवर्ड देवाणघेवाण आणि वापरकर्ता दुरुस्तीद्वारे विलंब निर्माण करू शकते. EAP-TLS नोंदणीनंतर त्वरित वाटू शकते आणि नंतर मुदत संपलेल्या प्रमाणपत्रावर पूर्णपणे अयशस्वी होऊ शकते.
| लक्षण | अधिक शक्यता असलेली पद्धत | सामान्य कारण | व्यावहारिक उपाय |
|---|---|---|---|
| अनोळखी AP जवळ पासवर्डसाठी पुन्हा विचारले जाते | PEAP | Supplicant सर्वरचे नाव किंवा साखळी सत्यापित करत नाही आहे | RADIUS नाव आणि CA ला पिन करणारी प्रोफाइल पुश करा |
| भूमिका (role) बदलल्यानंतर एका लॅपटॉपवरील ॲक्सेस बंद होतो | EAP-TLS | प्रमाणपत्र मागे घेतले आहे (revoked) किंवा डिव्हाइस MDM मधून हटवले आहे | मागे घेतल्याची (revocation) पुष्टी करा आणि केवळ तेच डिव्हाइस पुन्हा एनरोल करा |
| सोमवारी संपूर्ण टीमचा ॲक्सेस लॉक झाला | EAP-TLS | प्रमाणपत्रे एकाच वेळी एक्स्पायर झाली किंवा नूतनीकरणाची ओव्हरलॅप वेळ खूप कमी होती | एक्स्पायर होण्यापूर्वी नूतनीकरण करा आणि रिकव्हरी मार्ग तयार ठेवा |
| केवळ पूर्ण reauth वरच रोमिंग मंद वाटते | Inner EAP-TLS सह PEAP | दोन TLS हँडशेक्स | Resumption, PMK कॅशिंग किंवा 802.11r ला प्राधान्य द्या; आवश्यक नसल्यास inner EAP-TLS टाळा |
| केवळ एकाच साईटवर यादृच्छिकपणे रीजेक्ट्स होतात | कोणतीही एक | RADIUS राऊंड-ट्रिप किंवा चेन फेच समस्या, EAP नाव नाही | पद्धत बदलण्यापूर्वी RTT आणि 95 वे पर्सेंटाईल असोसिएशन-टू-IP मोजा |
एखाद्या साइटवरील धीमे रोमिंग हे सामान्यतः RADIUS अंतर किंवा चेन फेचमुळे असते, तुम्ही चुकीचा EAP प्रकार निवडल्याचा तो पुरावा नाही.
प्रत्येक घटकाला नियुक्त करा आणि विभाजन सिद्ध करा
एकाच इमारतीमध्ये कर्मचाऱ्यांचे लॅपटॉप, कॉन्फरन्स मधील गेस्ट, कंत्राटदारांचे Mac आणि POS टिल असू शकतात. त्यांनी समान क्रेडेंशियल प्रकार शेअर करू नये. प्रत्येक युझर ग्रुप मॅप करा, तुम्ही आधीपासून चालवत असलेल्या नेटवर्कच्या जवळ एका ठिकाणावर पायलट चाचणी करा, आणि डिझाइन कॉपी करण्यापूर्वी तिकिटे आणि ऑथेंटिकेशन लॉगचे मूल्यमापन करा.
| लोकसंख्या (Population) | वापरा | वापरू नका | कारण |
|---|---|---|---|
| MDM-व्यवस्थापित कर्मचारी आणि विशेषाधिकारप्राप्त वापरकर्ते | WPA-Enterprise SSID वर EAP-TLS | सामायिक (Shared) PSK किंवा PEAP | प्रमाणपत्र ओळख, गटानुसार VLAN, खाते निष्क्रिय केल्यावर ॲक्सेस समाप्त होतो |
| कमी कालावधीसाठी येणारे अतिथी आणि भेट देणारे | गेस्ट VLAN वर Captive portal किंवा Passpoint | डेस्कवर PEAP किंवा EAP-TLS नोंदणी | प्रमाणपत्र लाइफसायकल नाही आणि फिशिंग करण्यासाठी कोणताही डिरेक्टरी पासवर्ड नाही |
| अव्यवस्थापित लॅपटॉप आणि कंत्राटदार | सक्तीच्या सर्व्हर व्हॅलिडेशनसह केवळ PEAP-MSCHAPv2 | तुम्ही त्यांची नोंदणी किंवा नूतनीकरण करू शकत नसल्यास EAP-TLS | पासवर्ड आधीपासूनच अस्तित्वात आहेत, परंतु प्रोफाइलने RADIUS प्रमाणपत्राची तपासणी केली पाहिजे |
| प्रिंटर, टीव्ही, टिल्स, CCTV आणि सेन्सर | स्वतःच्या VLAN सह प्रति-डिव्हाइस PSK | EAP-TLS किंवा सामायिक PEAP पासवर्ड | हे डिव्हाइसेस सहसा प्रमाणपत्रे स्टोअर करू शकत नाहीत आणि सामायिक केलेली की बदलणे (rotate करणे) कठीण असते |
| एकाच इमारतीतील मिश्र ठिकाण (Venue) | वेगवेगळ्या VLAN वर ओळखीनुसार विभाजन करा | सर्वांसाठी एकच SSID आणि एकच पद्धत | कर्मचारी, अतिथी आणि डिव्हाइसेस वेगवेगळ्या प्रकारे त्रुटी दाखवतात आणि त्यांनी क्रेडेंशियल प्रकार सामायिक करू नये |
कोणी पासवर्डवर राहावे आणि कोणी राहू नये
मॅनेज केलेले कर्मचारी आणि विशेष अधिकार असलेले युझर्स WPA-Enterprise SSID वर EAP-TLS मिळवतात. हाउसकीपिंग, रिसेप्शन आणि ऑपरेशन्स कर्मचारी SCEP द्वारे MDM कडील प्रमाणपत्रांसह ऑथेंटिकेट करू शकतात, डिरेक्टरी ग्रुपनुसार VLAN वर पोहोचू शकतात आणि खाते डीफॉल्टनुसार डिसेबल झाल्यावर ॲक्सेस गमावू शकतात. शेअर केलेला PSK किंवा PEAP पासवर्ड तुम्ही बंद करू पाहत असलेली गोष्ट पुन्हा तयार करतो.
पाहुणे आणि भेट देणारे गेस्ट VLAN वर कॅप्टिव्ह पोर्टल किंवा Passpoint वर राहतात. फ्रंट डेस्कवर प्रमाणपत्रे एनरोल करू नका आणि ती PEAP वर ठेवू नका. अशी कोणतीही लाईफसायकल नाही जी तुम्ही चालवाल, आणि असा एक डिरेक्टरी पासवर्ड आहे जो तुम्ही फिश्ड होऊ देऊ इच्छित नाही. Passpoint प्रोफाईल नवीन तिकीट न घेता पुढील भेटीदरम्यान पुन्हा जॉईन होऊ शकते.
मॅनेज न केलेले लॅपटॉप आणि कंत्राटदार PEAP-MSCHAPv2 वर राहू शकतात, आणि केवळ जर प्रोफाईलने सर्व्हर व्हॅलिडेशन सक्तीचे केले असेल तरच. जर तुम्ही त्यांना एनरोल किंवा नूतनीकरण करू शकत नसाल, तर EAP-TLS त्यांना अडकवून ठेवेल. जर तुम्ही सर्व्हर चेक सक्तीचा करू शकत नसाल, तर पासवर्डचा धोका सोयीपेक्षा जास्त असतो आणि त्यांनी कर्मचाऱ्यांच्या SSID वर अजिबात असू नये.
प्रिंटर, टीव्ही, टिल्स, EPOS, CCTV, सेन्सर्स आणि डोअर कंट्रोलर्स यांना प्रति-डिव्हाइस PSK आणि त्यांचा स्वतःचा VLAN मिळतो. ते सहसा प्रमाणपत्रे स्टोअर करू शकत नाहीत. शेअर केलेला PEAP पासवर्ड शेअर केलेल्या - की ची समस्या परत आणतो. PCI DSS v4.0.1 Req 2.3.2 ला वायरलेस की माहित असलेली कोणतीही व्यक्ती सोडून गेल्यास ती बदलणे आवश्यक असते, जे शेअर केलेल्या की मुळे व्यावहारिक राहत नाही. xPSK त्या गोष्टींसाठी योग्य आहे. रूम टीव्ही, थर्मोस्टॅट्स आणि टिल्स की - बाउंड VLAN वर असले पाहिजेत जे पाहुण्यांना (guests) कधीही दिसत नाहीत.
ते एका साइटवर सिद्ध करा
नवीन डिझाइन आजच्या नेटवर्कच्या बाजूला, त्या साइटवर आधीपासून असलेल्या ॲक्सेस पॉइंट्सवर ठेवा. डेमो लॉगिनवर नाही, तर तिकीट आणि ऑडिट पुराव्यांवरून त्याचा न्याय करा.
एक प्रमाणीकरण लॉग आवश्यक आहे जो प्रत्येक स्वीकृती आणि नकार ओळख, डिव्हाइस, MDM नोंदणी स्थिती, पद्धत, ॲक्सेस पॉइंट, SSID, साइट, VLAN, भूमिका, कारण आणि वेळ सह नोंदवतो. तोच लॉग ISO 27001 ॲक्सेस आणि लॉगिंग नियंत्रणांसाठी तसेच PCI-DSS आवश्यकता 8 आणि 10 साठी पुरावा संच आहे. MDM शिवाय, प्रथम PEAP प्रोफाईल लॉक करा आणि केवळ व्यवस्थापित लोकसंख्येसाठी प्रमाणपत्रे शेड्यूल करा.
आम्ही ही विभागणी प्रति मालमत्ता तीन नेटवर्क म्हणून चालवू शकतो. अतिथी पोर्टल वापरतात, ज्यामध्ये मालमत्तेत असल्यास PMS रूम चेकचा समावेश होतो. कर्मचारी EAP-TLS किंवा Passpoint वापरतात. उपकरणे प्रति-डिव्हाइस कळा वापरतात. Cloud RADIUS प्रत्येक डिव्हाइसला ओळखीनुसार योग्य नेटवर्क आणि VLAN वर पाठवते आणि खाते अक्षम केलेल्या सोडणाऱ्या वापरकर्त्याला नाकारते. सामायिक केलेल्या कर्मचाऱ्यांच्या पासवर्डवरून स्थलांतर करण्याचा मार्ग हा आमच्या मार्गदर्शकामध्ये वर्णन केलेल्या मल्टी-साइट स्टाफ WiFi ला 802.1X वर हलवण्याच्या मार्गासारखाच आहे.
मी मॅनेज्ड स्टाफ SSID आणि टिल्ससाठी प्रति-डिव्हाइस की वापरून पायलट चाचणी सुरू करेन आणि एनरोलमेंट पूर्ण होईपर्यंत कंत्राटदारांना व्हॅलिडेट केलेल्या PEAP प्रोफाईलवर ठेवेन. प्रत्येकासाठी एकच पद्धत आकृतीमध्ये सुटसुटीत दिसते, परंतु प्रत्यक्ष अंमलबजावणीमध्ये ती तीन वेगवेगळ्या प्रकारे अयशस्वी ठरते.
Purple Access कडे तुमच्या मालकीच्या ॲक्सेस पॉइंट्सवरील गोष्टींसाठी प्रमाणपत्र-आधारित कर्मचारी WiFi आणि प्रति-डिव्हाइस कीज चालवण्याची सुविधा आहे, ज्यामुळे eap tls vs peap हा संपूर्ण इस्टेट-व्यापी जुगार न राहता लोकसंख्येचा पर्याय बनतो. तुम्ही एकाच साइटवर ओपन, सुरक्षित आणि xPSK सिद्ध करू शकता, मग मोठ्या प्रमाणावर रोलआउट करण्यापूर्वी तिकिटे आणि प्रमाणीकरण लॉगचे मूल्यमापन करू शकता. तुमचे कर्मचारी, अतिथी आणि डिव्हाइस नेटवर्क मॅप करण्यासाठी Purple Access ला भेट द्या.
