SCEP साठी एंटरप्राइझ मार्गदर्शक: स्वयंचलित कॅम्पस WiFi सुरक्षेसाठी सिम्पल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल तैनात करणे

शुभ प्रभात. जर तुम्ही हॉटेल समूह, रिटेल इस्टेट, स्टेडियम किंवा युनिव्हर्सिटी कॅम्पसमध्ये WiFi इन्फ्रास्ट्रक्चर व्यवस्थापित करत असाल, तर ही माहिती तुमच्यासाठी आहे. आम्ही SCEP - Simple Certificate Enrollment Protocol - आणि विशेषतः ते एंटरप्राइझ WiFi मधील सर्वात कठीण समस्यांपैकी एक कशी सोडवते याबद्दल बोलणार आहोत: हेल्पडेस्कवर तिकिटांचा भार न वाढवता, हजारो उपकरणांवर स्वयंचलितपणे प्रमाणपत्रे कशी मिळवायची. [short pause] चला पार्श्वभूमी समजून घेऊया. तुम्ही योग्य निर्णय घेतला आहे की स्टाफ WiFi साठी प्री-शेअर्ड की आता स्वीकार्य नाहीत. एकच तडजोड केलेला पासवर्ड तुमच्या संपूर्ण नेटवर्क सेगमेंटला धोक्यात आणतो. तुम्ही 802.1X ऑथेंटिकेशनवर स्थलांतरित झाला आहात किंवा होत आहात. हा IEEE मानक आहे ज्यासाठी प्रत्येक उपकरणाला नेटवर्क ॲक्सेस मिळण्यापूर्वी स्वतःची ओळख सिद्ध करणे आवश्यक असते. 802.1X चा सर्वात सुरक्षित प्रकार म्हणजे EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - जो पासवर्डऐवजी डिजिटल प्रमाणपत्रे वापरतो. प्रमाणपत्रे प्रत्येक उपकरणासाठी क्रिप्टोग्राफिकदृष्ट्या अद्वितीय असतात, ती शेअर केली जाऊ शकत नाहीत आणि एखादे उपकरण हरवल्यास किंवा कर्मचाऱ्याने नोकरी सोडल्यास ती त्वरित रद्द केली जाऊ शकतात. [short pause] इथपर्यंत सर्व काही ठीक आहे. खरी समस्या वितरणाची आहे. तंत्रज्ञाने प्रत्येक उपकरणाला स्पर्श न करता - Windows, iOS, Android, macOS वर - तुमच्या इस्टेटमधील प्रत्येक लॅपटॉप, प्रत्येक फोन, प्रत्येक टॅबलेटवर तुम्ही एक अद्वितीय प्रमाणपत्र कसे मिळवाल? SCEP नेमकी हीच समस्या सोडवते. [medium pause] SCEP ला २०२० मध्ये RFC 8894 मध्ये इंटरनेट इंजिनिअरिंग टास्क फोर्सद्वारे औपचारिक रूप देण्यात आले होते, जरी ते २००० च्या दशकाच्या सुरुवातीपासून एंटरप्राइझ वातावरणात वापरात आहे. हा असा प्रोटोकॉल आहे जो व्यवस्थापित उपकरणाला प्री-कॉन्फिगर केलेल्या URL आणि चॅलेंज पासवर्डचा वापर करून थेट तुमच्या सर्टिफिकेट ऑथॉरिटीकडून स्वतःच्या प्रमाणपत्राची विनंती करू देतो. येथील महत्त्वाचा सुरक्षा मुद्दा: प्रायव्हेट की उपकरणावरच तयार केली जाते, उपकरणाच्या सुरक्षित एन्क्लेव्हमध्ये साठवली जाते - म्हणजेच Windows उपकरणांवरील TPM चिप किंवा Apple हार्डवेअरवरील Secure Enclave - आणि ती कधीही नेटवर्कवर प्रवास करत नाही. उपकरण सर्टिफिकेट सायनिंग रिक्वेस्ट तयार करते, ती SCEP गेटवेकडे पाठवते, गेटवे चॅलेंज प्रमाणित करतो, विनंती तुमच्या सर्टिफिकेट ऑथॉरिटीकडे पाठवतो, CA त्यावर स्वाक्षरी करतो आणि स्वाक्षरी केलेले प्रमाणपत्र उपकरणाकडे परत येते. ही संपूर्ण प्रक्रिया अंतिम वापरकर्त्यासाठी अदृश्य असते. [short pause] आता, Microsoft वातावरणात, SCEP गेटवे सामान्यतः NDES - Network Device Enrollment Service - असतो, जो Windows Server रोल आहे आणि तुमच्या MDM प्लॅटफॉर्म आणि तुमच्या CA मधील मध्यस्थ म्हणून काम करतो. Microsoft Intune SCEP प्रोफाइल व्यवस्थापित उपकरणांवर पुश करते, जे त्यांना NDES URL आणि चॅलेंज पासवर्ड सांगते. उपकरणे उर्वरित प्रक्रिया स्वयंचलितपणे करतात. [medium pause] प्रत्यक्ष उपयोजन (deployment) कसे दिसते ते मी तुम्हाला सविस्तर सांगतो. १५० मालमत्ता असलेले एक हॉटेल ग्रुप गृहीत धरा - प्रीमियर इन (Premier Inn) च्या आकाराचे. त्यांच्याकडे फ्रंट-ऑफ-हाउस कर्मचाऱ्यांसाठी Windows लॅपटॉप्स, हाउसकीपिंग सुपरवायझर्ससाठी iOS डिव्हाइसेस आणि रेस्टॉरंटच्या पॉइंट-ऑफ-सेलवर Android टॅब्लेट्सचे मिश्रण आहे. SCEP च्या आधी, ते दर तिमाहीला बदलल्या जाणाऱ्या सामायिक पासवर्डसह WPA2-Personal चालवत होते. प्रत्येक वेळी पासवर्ड बदलल्यावर हेल्पडेस्क कॉल्सचा पूर यायचा. SCEP आणि Intune सह, ते सलग तीन प्रोफाइल उपयोजित करतात. पहिले, Trusted Root Certificate प्रोफाइल - हे प्रत्येक डिव्हाइसला कंपनीच्या Certificate Authority वर विश्वास ठेवण्यास सांगते. दुसरे, SCEP Certificate प्रोफाइल - हे डिव्हाइसेसना त्यांचे स्वतःचे युनिक क्लायंट सर्टिफिकेट मिळवण्याची सूचना देते. तिसरे, WiFi प्रोफाइल - हे SSID कॉन्फिगर करते, सुरक्षा प्रकार WPA2-Enterprise किंवा WPA3-Enterprise वर सेट करते आणि ऑथेंटिकेशनसाठी SCEP सर्टिफिकेटकडे निर्देशित करते. ही तीन प्रोफाइल Intune मधील एकाच डिव्हाइस ग्रुपवर उपयोजित करा, आणि प्रत्येक व्यवस्थापित डिव्हाइस कोणत्याही युझर हस्तक्षेपाशिवाय, युनिक सर्टिफिकेटसह कॉर्पोरेट SSID शी आपोआप कनेक्ट होते. [short pause] RADIUS सर्व्हर - सामान्यतः Microsoft NPS किंवा क्लाउड RADIUS सेवा - EAP-TLS ऑथेंटिकेशन विनंती प्राप्त करतो, CA कडून सर्टिफिकेट प्रमाणित करतो, Certificate Revocation List तपासतो आणि प्रवेश मंजूर किंवा नाकारतो. जर एखाद्या कर्मचाऱ्याला कामावरून काढून टाकले, तर तुम्ही CA मधील त्यांचे सर्टिफिकेट रद्द करता. पुढील ऑथेंटिकेशन सायकलमध्ये त्यांच्या डिव्हाइसचा WiFi प्रवेश बंद होतो. कोणताही पासवर्ड रिसेट करण्याची गरज नाही. तिमाही पासवर्ड बदलण्याची वाट पाहण्याची गरज नाही. [medium pause] आता, लोक सहसा SCEP आणि PKCS - Public Key Cryptography Standards मधील फरकाबद्दल विचारतात. दोन्ही Intune सोबत काम करतात. मुख्य फरक हा आहे की प्रायव्हेट की (private key) कुठे जनरेट होते. SCEP सह, ती डिव्हाइसवरच जनरेट होते. PKCS सह, CA दोन्ही की मध्यवर्ती ठिकाणी जनरेट करतो आणि प्रायव्हेट की डिव्हाइसवर पाठवतो. याचा अर्थ प्रायव्हेट की नेटवर्कवरून प्रवास करते, ज्यामुळे सैद्धांतिकदृष्ट्या ती मध्येच हॅक होण्याचा धोका निर्माण होतो. PKCS चे स्वतःचे स्थान आहे - हे S/MIME ईमेल एन्क्रिप्शनसाठी अधिक योग्य आहे जिथे की एस्क्रो (key escrow) महत्त्वाचे असते. WiFi ऑथेंटिकेशनसाठी, SCEP हाच योग्य पर्याय आहे. प्रत्येक वेळी. [short pause] मी तुम्हाला दुसरे उदाहरण देतो - एक रिटेल इस्टेट. संपूर्ण यूकेमध्ये २०० स्टोअर्स असलेल्या एका फॅशन रिटेलरची कल्पना करा, जे प्रत्येक ठिकाणी Cisco Meraki ॲक्सेस पॉइंट्स चालवत आहेत. त्यांची पॉइंट-ऑफ-सेल सिस्टीम Windows-आधारित आहे, जी Intune द्वारे व्यवस्थापित केली जाते. त्यांना PCI DSS अनुपालनाची (compliance) आवश्यकता आहे, ज्याचा अर्थ कार्डधारक डेटा हाताळणाऱ्या कोणत्याही डिव्हाइससाठी नेटवर्क सेगमेंटेशन आणि मजबूत ऑथेंटिकेशन आवश्यक आहे. SCEP-आधारित EAP-TLS त्यांना स्टाफ SSID वर डिव्हाइस-स्तरीय ऑथेंटिकेशन देते, ज्यामध्ये VLAN असाइनमेंट RADIUS पॉलिसीद्वारे नियंत्रित होते. POS टर्मिनल्स आपोआप PCI-स्कोप असलेल्या VLAN वर पोहोचतात. गेस्ट WiFi - जे Purple सारख्या प्लॅटफॉर्मद्वारे स्वतंत्रपणे हाताळले जाते - ते स्वतःच्या ऑथेंटिकेशन फ्लोसह पूर्णपणे वेगळ्या SSID वर चालते. हे दोन्ही नेटवर्क कधीही एकमेकांना स्पर्श करत नाहीत. ऑडिटर्स समाधानी राहतात. सुरक्षा टीम शांतपणे झोपू शकते. [medium pause] चला, आता काही त्रुटींबद्दल बोलूया, कारण अशा काही गोष्टी आहेत ज्या टीम्सना अडचणीत आणतात. [short pause] सर्वात सामान्य बिघाड मोड म्हणजे Intune मधील ग्रुप टार्गेटिंग विसंगती. तुमचे Trusted Root प्रोफाइल, तुमचे SCEP प्रोफाइल आणि तुमचे WiFi प्रोफाइल हे सर्व एकाच Azure AD ग्रुपला टार्गेट करणारे असावे. जर SCEP प्रोफाइल User ग्रुपला टार्गेट करत असेल आणि WiFi प्रोफाइल Device ग्रुपला टार्गेट करत असेल, तर Intune ही डिपेंडन्सी सोडवू शकत नाही आणि WiFi प्रोफाइल एरर दाखवते. आधी तुमचे असाइनमेंट्स तपासा - बहुतांश वेळा हेच मुख्य कारण असते. [short pause] दुसरी त्रुटी: NDES सर्व्हरची उपलब्धता. रिमोट डिव्हाइसेस ऑन-साइट येण्यापूर्वी त्यांची नोंदणी करण्यासाठी तुमचा NDES सर्व्हर इंटरनेटवरून ॲक्सेसिबल असणे आवश्यक आहे. हे सुरक्षितपणे करण्याचा मार्ग म्हणजे Azure AD Application Proxy वापरणे, जे तुम्हाला इनबाउंड फायरवॉल पोर्ट्स न उघडता रिमोट ॲक्सेस देते. NDES थेट इंटरनेटवर उघडू नका. [short pause] तिसरी: CRL उपलब्धता. प्रत्येक वेळी डिव्हाइस ऑथेंटिकेट होते तेव्हा तुमचा RADIUS सर्व्हर Certificate Revocation List तपासतो. जर CRL Distribution Point ॲक्सेसिबल नसेल - कदाचित सर्व्हर डाउन असेल किंवा फायरवॉल नियम बदलला असेल - तर सर्वांसाठी ऑथेंटिकेशन अयशस्वी होते. तुमचे CRL एंडपॉइंट्स हायली-अवेलेबल ठेवा आणि त्यांची नियमित चाचणी घ्या. [short pause] चौथी: सर्टिफिकेट टेम्पलेट परमिशन्स. जर तुमच्या NDES कनेक्टर सर्व्हिस अकाउंटला सर्टिफिकेट टेम्पलेटवर Read आणि Enroll परमिशन्स नसतील, तर डिव्हाइसेसना त्यांचे सर्टिफिकेट गोळा करण्याचा प्रयत्न करताना HTTP 403 एरर येतात. हा एक साधा परमिशन्सचा बदल आहे, पण सुरुवातीच्या सेटअप दरम्यान याकडे सहज दुर्लक्ष होऊ शकते. [medium pause] आता रॅपिड-फायर राउंड. [short pause] SCEP हे नॉन-Microsoft MDMs सोबत काम करू शकते का? होय - Apple डिव्हाइस फ्लीट्ससाठी Jamf, VMware Workspace ONE आणि बहुतांश एंटरप्राइझ MDM प्लॅटफॉर्म्स SCEP प्रोफाइल्सना सपोर्ट करतात. हा प्रोटोकॉल वेंडर-न्यूट्रल आहे. [short pause] SCEP हे क्लाउड PKI सोबत काम करते का? होय. Intune Suite मधील Microsoft चे स्वतःचे क्लाउड PKI ऑन-प्रिमाइसेस NDES सर्व्हरची गरज पूर्णपणे काढून टाकते. SecureW2 आणि Keyfactor सारखे थर्ड-पार्टी क्लाउड PKI प्रोव्हाइडर्स देखील क्लाउड SCEP एंडपॉइंट्स ऑफर करतात. [short pause] WPA3-Enterprise बद्दल काय? WPA3-Enterprise समान 802.1X आणि EAP-TLS ऑथेंटिकेशन स्टॅक वापरते. SCEP-इश्यू केलेले सर्टिफिकेट्स अगदी तशाच प्रकारे काम करतात. हे अपग्रेड वायरलेस प्रोटोकॉल लेयरवर आहे, सर्टिफिकेट लेयरवर नाही. [short pause] सर्टिफिकेट्स किती काळ टिकतात? सहसा एक वर्ष, जरी तुम्ही कमी वैधतेचा कालावधी कॉन्फिगर करू शकता. Intune कालबाह्य होण्यापूर्वी ऑटोमॅटिक रिन्यूअल हाताळते, त्यामुळे युजर्सना कधीही व्यत्यय येत नाही. [medium pause] थोडक्यात सांगायचे तर. SCEP मोठ्या प्रमाणावर सर्टिफिकेट वितरणाचे ऑटोमेशन करते, ज्यामुळे मोठ्या डिव्हाइस फ्लीट्समध्ये PKI डिप्लॉयमेंटचा मॅन्युअल ओव्हरहेड नाहीसा होतो. प्रायव्हेट की डिव्हाइसवरच राहते - हा EAP-TLS चा सुरक्षेचा पाया आहे. क्रमाने डिप्लॉय करा: आधी Trusted Root, नंतर SCEP प्रोफाइल, तिसरे WiFi प्रोफाइल, सर्व एकाच ग्रुपला टार्गेट करणारे. Application Proxy द्वारे तुमचा NDES एंडपॉइंट सुरक्षितपणे पब्लिश करा. तुमचे CRL एंडपॉइंट्स हायली-अवेलेबल ठेवा. आणि जर तुम्ही नव्याने सुरुवात करत असाल, तर ऑन-प्रिमाइसेस NDES डिपेंडन्सी पूर्णपणे काढून टाकण्यासाठी क्लाउड PKI चे मूल्यांकन करा. [short pause] गेस्ट WiFi साठी - स्वतंत्र, अभ्यागतांसाठी असलेले नेटवर्क - सर्टिफिकेट-आधारित ऑथेंटिकेशन हा योग्य मॉडेल नाही. गेस्ट्सकडे मॅनेज्ड डिव्हाइसेस नसतात. अशा ठिकाणी Purple सारखे प्लॅटफॉर्म ऑथेंटिकेशन फ्लो हाताळते: captive portal, सोशल लॉगिन, ईमेल कॅप्चर, किंवा SMS व्हेरिफिकेशन, जे सर्व तुमच्या मार्केटिंग टीमला प्रत्यक्षात वापरता येईल अशा फर्स्ट-पार्टी डेटा लेयरमध्ये फीड केले जाते. हे दोन्ही दृष्टिकोन एकमेकांना पूरक आहेत: तुमच्या मॅनेज्ड स्टाफ इस्टेटसाठी SCEP, आणि तुमच्या गेस्ट नेटवर्कसाठी Purple. दोन्ही एकाच हार्डवेअरवर चालतात, जे VLAN द्वारे स्पष्टपणे विभागलेले असतात. [short pause] ही तुमची SCEP एंटरप्राइझ WiFi ऑनबोर्डिंगवरील माहिती आहे. आर्किटेक्चर डायग्राम्स, स्टेप-बाय-स्टेप Intune कॉन्फिगरेशन आणि सविस्तर उदाहरणांसह संपूर्ण लिखित मार्गदर्शिका Purple वेबसाइटवर उपलब्ध आहे. ऐकल्याबद्दल धन्यवाद.