कर्मचारी बाहेर पडल्यावर WiFi ॲक्सेस कसा रद्द करावा

कर्मचारी नोकरी सोडून गेल्यावर WiFi ॲक्सेस कसा रद्द करावा, या तांत्रिक माहिती सत्रात आपले स्वागत आहे. ही समस्या जितकी दिसते त्यापेक्षा अनेकदा मोठी असते. कोणीतरी शुक्रवारी नोकरी सोडतो. त्यांचे व्यवस्थापक ईमेल बंद करतात आणि लॅपटॉप परत घेतात. तरीही त्यांचा फोन किंवा वैयक्तिक डिव्हाइस सोमवारी Staff WiFi शी कनेक्ट होऊ शकतो. हॉटेलच्या बाबतीत, यामुळे माजी कर्मचाऱ्याला ऑपरेशनल सिस्टम्सच्या जवळ जाण्याची संधी मिळू शकते. रिटेल क्षेत्रात, यामुळे अनेक स्टोअर्समधील स्टाफ नेटवर्कमध्ये प्रवेश मिळू शकतो. स्टेडियम किंवा कॉन्फरन्स सेंटरमध्ये, यामुळे व्यस्त इव्हेंटचा दिवस व्यवस्थापित करणे अधिक कठीण होऊ शकते. तात्काळ प्रश्न हा नाही की नोकरी सोडणाऱ्याला पासवर्ड माहित आहे का. प्रश्न असा आहे की तुमचे WiFi त्या व्यक्तीला एक स्वतंत्र ओळख म्हणून ओळखू शकते का, आणि इतरांना कोणताही त्रास न देता त्या ओळखीचा प्रवेश नाकारू शकते का. एकच सामायिक केलेला WPA2 पासफ्रेज हे करू शकत नाही. प्रत्येक व्यक्तीकडे एकच क्रेडेंशियल असते. एकदा तो पासफ्रेज नोकरी सोडणाऱ्या व्यक्तीशी शेअर झाला की, त्या व्यक्तीला आणि इतर अधिकृत कर्मचाऱ्यांना (ज्यांना तो पासवर्ड माहित आहे) वेगळे करण्याचा कोणताही सोपा मार्ग नेटवर्ककडे उरत नाही. यावर व्यावहारिक उपाय म्हणजे संपूर्ण कंपनीचा पासफ्रेज बदलणे आणि त्यानंतर प्रत्येक मंजूर डिव्हाइसवर तो अपडेट करणे. हे ऑपरेशनलदृष्ट्या खर्चिक आहे, यामुळे सपोर्ट तिकिटे वाढतात आणि अनेकदा याला उशीर होतो. वेगवेगळ्या ठिकाणी पसरलेल्या वेन्यू एस्टेटसाठी हा एकाच दिवसात ऑफबोर्डिंग नियंत्रित करण्याचा विश्वासार्ह मार्ग नाही. यासाठी तीन विश्वासार्ह पर्याय आहेत. पहिला म्हणजे EAP-TLS सह प्रति-व्यक्ति 802.1X. दुसरा म्हणजे iPSK, ज्याला काहीवेळा इंडिव्हिज्युअल प्री-शेअर्ड की म्हटले जाते. तिसरा म्हणजे SCIM चा वापर करून आयडेंटिटी-प्रोव्हाइडर-चालित डीप्रोव्हिजनिंग. तुम्ही या पद्धती एकत्र देखील वापरू शकता. मुख्य डिझाइन निवड अजूनही तीच आहे: ॲक्सेस क्रेडेंशियल हे एखाद्या व्यक्तीशी किंवा व्यवस्थापित डिव्हाइसशी जोडलेले असावे आणि त्यानंतर ते काढून टाकणे ही एक नियंत्रित, लॉग केलेली प्रक्रिया असावी. चला 802.1X आणि EAP-TLS ने सुरुवात करूया. IEEE 802.1X ही नेटवर्क ॲक्सेस-कंट्रोल फ्रेमवर्क आहे. हे नेटवर्कमध्ये सामील होण्यासाठी विनंती करणारे डिव्हाइस, नेटवर्कच्या टोकावरील ऑथेंटिकेटर आणि बॅक-एंड ऑथेंटिकेशन सर्व्हिस यांना वेगळे करते. EAP-TLS ही एक एक्सटेन्सिबल ऑथेंटिकेशन प्रोटोकॉल पद्धत आहे जी म्युच्युअल ऑथेंटिकेशन आणि की मिळवण्यासाठी प्रमाणपत्रांचा (certificates) वापर करते. साध्या शब्दांत सांगायचे तर, डिव्हाइसकडे प्रमाणपत्र असल्याचे सिद्ध होते आणि नेटवर्क त्याच ऑथेंटिकेशन एक्सचेंज दरम्यान स्वतःची ओळख सिद्ध करते. हा मॉडेल व्यवस्थापित स्टाफ डिव्हाइसेस आणि उच्च-सुरक्षा नेटवर्कसाठी योग्य आहे. नोकरी सोडणाऱ्या व्यक्तीसाठीची कृती सामायिक केलेला पासवर्ड बदलणे ही नसते. तर ती ओळख निष्क्रिय करणे आणि प्रमाणपत्राचा ऑथेंटिकेट करण्याचा अधिकार रद्द करणे, नाकारणे किंवा काढून टाकणे ही असते. जेव्हा एखादे डिव्हाइस ऑथेंटिकेट होते, तेव्हा तुमचे RADIUS आणि सर्टिफिकेट-व्हॅलिडेशन डिझाइन हा बदल ओळखण्यास सक्षम असणे आवश्यक आहे. प्रमाणपत्राची मुदत संपणे (expiry) आणि प्रमाणपत्र रद्द करणे (revocation) यामध्ये गल्लत करू नका. मुदत संपणे हे नियोजित असते. रद्द करणे ही ती ऑफबोर्डिंग कृती आहे जी तुम्ही नियोजित समाप्ती तारखेपूर्वी घेता.वेळ खूप महत्त्वाची आहे. प्रमाणपत्र-आधारित WiFi प्रवेशाची पडताळणी ऑथेंटिकेशनच्या वेळी केली जाते. त्यामुळे तुमचे व्यावहारिक उद्दिष्ट स्पष्ट आहे: पुढील ऑथेंटिकेशनच्या प्रयत्नात प्रमाणपत्र यशस्वी होण्यापासून रोखा आणि त्या निकालाची चाचणी घ्या. जर कर्मचाऱ्याचे आधीपासूनच सक्रिय सेशन असेल, तर तुमच्या पॉलिसीनुसार सेशन डिस्कनेक्ट करणे आवश्यक आहे की नाही याचा स्वतंत्रपणे निर्णय घ्या. ही नेटवर्क-ऑपरेशन्सची निवड आहे, ओळख रद्द करण्यासाठीचा पर्याय नाही. तसेच तुमच्या डिझाइन आणि चाचणी प्रक्रियेदरम्यान जलद रीकनेक्ट वर्तन आणि कॅश केलेल्या सेशन्सचा विचार करा. लॅबमध्ये योग्य दिसणारे डिझाइन जर तुमच्या प्रोडक्शन ऑथेंटिकेशन पाथने इच्छित बदल वैध केला नाही तर अंधुक बिंदू (blind spot) तयार करू शकते. EAP-TLS साठी ऑपरेशनल चेकलिस्ट सरळ आहे. प्रथम, संबंधित व्यक्तीचे ओळख रेकॉर्ड आणि शेवटची कामाची वेळ याची पुष्टी करा. दुसरे, सोर्स आयडेंटिटी निष्क्रिय करा. तिसरे, तुमच्या प्रमाणपत्र प्राधिकरणा (certificate authority) आणि RADIUS प्रक्रियेनुसार संबंधित प्रमाणपत्र रद्द करा किंवा नाकारा. चौथे, तुमच्या पॉलिसीनुसार आवश्यक असल्यास सक्रिय सेशन काढून टाका किंवा समाप्त करा. पाचवे, माजी कर्मचाऱ्याच्या मॅनेज्ड डिव्हाइससह किंवा नियंत्रित समतुल्य डिव्हाइससह नवीन कनेक्शनचा प्रयत्न करा. शेवटी, विनंती, बदल, निकाल, वेळ आणि जबाबदार मालक यांचे रेकॉर्ड जतन करा. दुसरा पॅटर्न iPSK आहे. संपूर्ण वर्कफोर्सने एकच पासफ्रेज शेअर करण्याऐवजी, प्रत्येक व्यक्ती किंवा डिव्हाइसकडे समान स्टाफ WiFi नेटवर्कवर एक वेगळी की असते. यामुळे काढून टाकण्याची प्रक्रिया लक्ष्यित होते. कंपनी सोडणाऱ्या कर्मचाऱ्याशी संबंधित की हटवा, नवीन जोडणीचा प्रयत्न अयशस्वी झाल्याची पुष्टी करा आणि इतर सर्व की तशाच ठेवा. जिथे तुमच्याकडे अशी डिव्हाइसेस आहेत जी प्रमाणपत्रे वापरू शकत नाहीत, जिथे मॅनेज्ड-डिव्हाइस प्रोग्राम अजूनही विकसित होत आहे, किंवा जिथे तुम्हाला एका शेअर केलेल्या पासफ्रेजपासून व्यावहारिक बदलाची आवश्यकता आहे तिथे iPSK चांगल्या प्रकारे काम करू शकते. iPSK हे वेगळ्या नावाच्या सामान्य स्टाफ पासवर्डसारखे नाही. ही की एका ओळख किंवा डिव्हाइस रेकॉर्डशी जोडलेली असणे आवश्यक आहे. कीचा मालक, जारी केल्याची तारीख, डिव्हाइस किंवा व्यक्तीची जोडणी, नेटवर्क भूमिका आणि काढून टाकल्याची स्थिती यांची नोंद ठेवा. की पुरेशी वेगळी ठेवा जेणेकरून की हटवल्याची घटना कंपनी सोडणाऱ्या व्यक्तीशी जोडली जाऊ शकेल. जर तीच iPSK एखाद्या टीमने, कंत्राटदार गटाने किंवा शिफ्टने पुन्हा वापरली, तर तुम्ही शेअर केलेल्या गुपित पासवर्डची समस्या एका छोट्या स्वरूपात पुन्हा निर्माण केली आहे. तिसरा पॅटर्न SCIM-चालित डीप्रोव्हिजनिंग आहे. SCIM हा सिस्टीममधील आयडेंटिटी डेटा प्रोव्हिजनिंग आणि व्यवस्थापित करण्यासाठीचा एक मानक HTTP-आधारित प्रोटोकॉल आहे. एका चांगल्या जॉइनर-मूव्हर-लीव्हर प्रक्रियेमध्ये, HR किंवा IT तुमच्या आयडेंटिटी प्रोव्हाइडरमधील खाते निष्क्रिय करते, निष्क्रिय स्थिती WiFi प्रवेश सेवेकडे पाठवली जाते आणि नंतरचे WiFi ऑथेंटिकेशन नाकारले जाते. Purple हे SCIM द्वारे WiFi प्रवेशाला आयडेंटिटी प्रोव्हाइडरशी जोडते. संबंधित आयडेंटिटी प्रोव्हाइडर Microsoft Entra ID, Okta आणि Google Workspace आहेत. याचा ऑपरेशनल फायदा कोणतीही जादू नाही. हा सत्याचा एकच स्रोत (single source of truth) आहे: जी घटना रोजगार संपवते, तीच घटना WiFi प्रवेश काढून टाकण्यास देखील सुरवात करते. SCIM ला एक नियंत्रण मार्ग म्हणून समजा, केवळ एक घोषणा समजू नका. तुम्हाला एका युनिक आयडेंटिफायरची गरज आहे जो आयडेंटिटी-प्रदाता खात्याला WiFi ऍक्सेस रेकॉर्डशी जोडतो. तुम्हाला सहमती असलेला डिसेबल इव्हेंट आवश्यक आहे. डिसेबल विनंती अपयशी ठरल्यास रिसिव्हिंग सर्व्हिस कोणती एरर दाखवते हे तुम्हाला माहित असणे आवश्यक आहे. आणि तुमचे मॉनिटरिंग ते अपयश ओळखू शकते हे सिद्ध करण्यासाठी तुम्हाला चाचणी ओळख आवश्यक आहे. आता डिझाइनकडून अंमलबजावणीकडे वळा. ऍक्सेस इन्व्हेंटरीपासून सुरुवात करा. प्रत्येक स्टाफ WiFi नेटवर्क, त्याचा सुरक्षा मोड, आयडेंटिटी सोर्स, उपस्थित असल्यास RADIUS मार्ग, उपस्थित असल्यास सर्टिफिकेट ऑथोरिटी, उपस्थित असल्यास iPSK ओनर रेकॉर्ड, सेशन-डिस्कनेक्ट क्षमता आणि लॉग डेस्टिनेशन यांची यादी तयार करा. हे व्हेन्यू ग्रुपच्या आधारे करा, कंपनीची एकच सरसकट यादी बनवू नका. एक हॉटेल, हाय-स्ट्रीट स्टोअर आणि स्टेडियम वेगवेगळ्या ऑपरेशनल टीम्स आणि हार्डवेअर वापरत असतानाही समान पॉलिसी शेअर करू शकतात. यानंतर, लीव्हर प्रक्रियेतून (संस्था सोडणाऱ्या कर्मचाऱ्यांसाठी) सर्वात जास्त मॅन्युअल काम कमी करणारे नियंत्रण निवडा. मॅनेज्ड कॉर्पोरेट डिव्हाइसेससाठी, जिथे तुमचे सर्टिफिकेट ऑथोरिटी, RADIUS डिझाइन आणि डिव्हाइस मॅनेजमेंट सपोर्ट करू शकते तिथे EAP-TLS सह 802.1X वापरा. मिक्स्ड एस्टेट आणि सर्टिफिकेट वापरू न शकणाऱ्या डिव्हाइसेससाठी, iPSK चा वापर केवळ तेव्हाच करा जेव्हा प्रत्येक की युनिक मालकीची आणि डिलीट करण्यायोग्य असेल. आधीपासूनच Microsoft Entra ID, Okta किंवा Google Workspace वापरत असलेल्या एस्टेटसाठी, WiFi रिमूव्हल ट्रिगर करण्यासाठी खाते डिसेबल करण्यासाठी SCIM-ड्रिव्हन डिप्रॉव्हिजनिंग वापरा. Purple त्या आयडेंटिटी इव्हेंटला WiFi ऍक्सेस स्टेटसशी कनेक्ट करू शकते. एक्सेप्शन पाथ असल्याशिवाय दुसरा मॅन्युअल तिकीट मार्ग जोडू नका. एकाच दिवशी ऑफबोर्डिंग करणारी रनबुक तयार करा. HR अंतिम वेळेची पुष्टी करते. आयडेंटिटी ओनर खाते डिसेबल करतो. नेटवर्क ओनर संबंधित सर्टिफिकेट, iPSK किंवा WiFi ऍक्सेस रेकॉर्ड यापुढे वैध नसल्याची पुष्टी करतो. सक्रिय सेशन डिस्कनेक्ट करण्याची आवश्यकता आहे की नाही हे ऑपरेशन्स ठरवते. एक नियुक्त केलेला टेस्टर नवीन ऑथेंटिकेशनचा प्रयत्न करतो. निकाल रेकॉर्ड झाल्यावरच केस बंद होते. हे जाणूनबुझून साधे ठेवले आहे. तसेच हे मूल्यमापनकर्ता पुन्हा तपासून पाहू शकतो असा भाग आहे. ISO 27001 किंवा SOC 2 पुराव्यासाठी, एक लहान पण संपूर्ण चेन राखून ठेवा: ऑथराइज्ड ऑफबोर्डिंग विनंती, आयडेंटिटी प्रदाता बदल, WiFi बदल, व्हेरिफिकेशन निकाल, टाइमस्टॅम्प आणि प्रत्येक पायरीचा ओनर. नियंत्रणासाठी आवश्यक असलेल्या डेटापेक्षा जास्त वैयक्तिक डेटा गोळा करणे टाळा. ऍक्सेस रेकॉर्ड हा वैयक्तिक डेटा असू शकतो, त्यामुळे तुमच्या रिटेंशन आणि ऍक्सेस-कंट्रोल निर्णयांमध्ये त्यांचा समावेश करा. जर स्टाफ WiFi चा पेमेंट सिस्टमवर परिणाम होऊ शकत असेल, तर WiFi रिव्होकेशनला स्वतंत्र कंप्लायन्स दावा मानण्याऐवजी PCI DSS साठी जबाबदार असलेल्या टीमसोबत स्कोप आणि सेगमेंटेशनवर चर्चा करा. चार प्रकारच्या अपयशांवर बारीक लक्ष ठेवा. पहिले, दुर्लक्षित केलेल्या SSID वर सामायिक पासवर्ड अजूनही वापरात असणे. दुसरे, WiFi रेकॉर्ड ड्युरेबल आयडेंटिटीऐवजी बदलण्यायोग्य ईमेल पत्त्याशी जुळणे. तिसरे, डिसेबल इव्हेंट आयडेंटिटी प्रदात्यापर्यंत पोहोचणे परंतु WiFi ऍक्सेस सर्व्हिसपर्यंत न पोहोचणे. चौथे, तुम्ही केवळ डॅशबोर्ड स्टेटची चाचणी घेणे आणि वास्तविक नवीन जॉईन प्रयत्नाची चाचणी न घेणे. जर तुम्ही इन्व्हेंटरी, मॉनिटर आणि नियंत्रणाची चाचणी घेतली तर प्रत्येक प्रकारचे अपयश टाळता येऊ शकते. रॅपिड-फायर प्रश्न. एका सोडणाऱ्या व्यक्तीसाठी सामायिक केलेला WPA2 पासवर्ड रद्द केला जाऊ शकतो का? नाही. तो सर्वांसाठी बदला, किंवा प्रति-ओळख नियंत्रणासह बदला. EAP-TLS ऍक्सेस किती वेगाने रद्द केला जाऊ शकतो? पुढील ऑथेंटिकेशन दरम्यान, जर तुमचे सर्टिफिकेट आणि RADIUS प्रमाणीकरण डिझाइन हे रद्दीकरण ओळखत असेल. SCIM सक्रिय सेशन काढून टाकते का? स्वतःहून नाही. सेशन नियंत्रणाकडे एक स्वतंत्र ऑपरेशनल निर्णय म्हणून पहा. iPSK प्रत्येक डिव्हाइससाठी योग्य आहे का? नाही. जेथे सर्टिफिकेट ऑथेंटिकेशन योग्य नाही, अशा ठिकाणी हे एक व्यावहारिक ओळख-बद्ध की मॉडेल (identity-bound key model) आहे. पुढील पायरी म्हणजे एक लहान डिझाइन पुनरावलोकन आहे. एक Staff WiFi नेटवर्क निवडा. HR कडून आलेल्या नोटिफिकेशनपासून ते ऑथेंटिकेशन नाकारले जाण्यापर्यंतच्या एका कर्मचारी सोडण्याच्या प्रक्रियेचा मागोवा घ्या. मॅन्युअल स्टेप शोधा आणि ती काढून टाका. WiFi क्रेडेंशियल हे कर्मचाऱ्याने संस्था सोडल्यावर लगेचच रद्द झाले पाहिजे, पुढील पासवर्ड-बदलण्याच्या प्रोजेक्टपर्यंत थांबण्याची गरज नाही.