नेटवर्कच्या सर्वोत्तम पद्धती एका मूलभूत वास्तवाने सुरू होतात: 2025 मध्ये, UK शासनाच्या Cyber Security Breaches Survey 2025 नुसार, 43% UK व्यवसायांनी मागील 12 महिन्यांत सायबर सुरक्षा उल्लंघन किंवा हल्ल्याचा अनुभव आल्याची नोंद केली आहे. कोणत्याही ठिकाणासाठी किंवा एंटरप्राइझसाठी, प्रश्न हा नाही की नेटवर्क सुरक्षित करायचे की नाही. प्रश्न हा आहे की प्रवेश, बदल आणि कर्मचार्‍यांचे गमन या गोष्टी काय चुकीचे घडते ते मर्यादित ठेवण्यासाठी पुरेशा चांगल्या प्रकारे व्यवस्थापित केल्या आहेत की नाही.
गेस्ट नेटवर्क सोयीस्कर असावे, परंतु डिझाइननुसार ते अविश्वासू मानले गेले पाहिजे. कर्मचारी, अभ्यागत, भाडेकरू आणि ऑपरेशन्सच्या उपकरणांना वेगवेगळ्या प्रकारच्या ऍक्सेसची आवश्यकता असते, आणि जेव्हा लोक सोडून जातात, डिव्हाइसेस असुरक्षित होतात किंवा इन्फ्रास्ट्रक्चर अपडेट केले जाते तेव्हा त्या परवानग्या बदलणे आवश्यक असते.
मुख्य नेटवर्क सर्वोत्तम पद्धती एका दृष्टीक्षेपात
४३% उल्लंघन-किंवा-हल्ला आकृती ही नेटवर्क सुरक्षेला निव्वळ पर्याय न ठेवता जोखीम व्यवस्थापनाचा एक पायाभूत भाग बनवते. अशा सहा नियंत्रणांपासून सुरुवात करा जे अनधिकृत ऍक्सेसची शक्यता कमी करतात आणि अयशस्वी झालेल्या गोष्टी हाताळणे सोपे करतात.
| पद्धत | हे काय रोखते | हे सर्वात जास्त कुठे महत्त्वाचे आहे | पहिली तपासणी |
|---|---|---|---|
| श्रोते आणि उद्दिष्टानुसार वर्गीकरण करा | एक डिव्हाइस हॅक झाल्यानंतर होणारी लॅटरल मूव्हमेंट | ज्या ठिकाणी अतिथी आणि कर्मचारी एकच नेटवर्क वापरतात | अतिथी आणि कर्मचाऱ्यांचा ट्रॅफिक वेगवेगळ्या VLANs वर आहे का? |
| प्रत्येक युझर आणि डिव्हाइसचे प्रमाणीकरण करा | चोरीला गेलेले सामायिक पासवर्ड आणि अनमॅनेज्ड डिव्हाइसेस | कर्मचाऱ्यांचे नेटवर्क आणि सामायिक-की असणारी ठिकाणे | कर्मचाऱ्यांना सामायिक पासवर्डद्वारे प्रवेश दिला जातो का? |
| मॅनेजमेंट आणि युझर ट्रॅफिक वेगळा करा | हॅकर्स कंट्रोलर्स आणि ॲडमिन कन्सोलपर्यंत पोहोचणे | प्रत्येक मल्टी-साइट इस्टेट | अतिथी डिव्हाइस कंट्रोलर ॲड्रेसपर्यंत पोहोचू शकते का? |
| चाचण्या आणि रोलबॅकसह बदल नियंत्रित करा | कॉन्फिगरेशन बदलांमुळे स्वतःहून निर्माण होणारे आउटिज | मल्टी-साइट आणि 24/7 ऑपरेशन्स | प्रत्येक बदलासाठी ओनर आणि रोलबॅक पायरी निश्चित आहे का? |
| प्रमाणीकरण आणि प्रवेशाचे निरीक्षण करा | सायलंट फेल्युरर्स आणि मंद गतीने होणारे रिव्होकेशन | हेल्थकेअर, हॉस्पिटॅलिटी आणि रिटेल | अयशस्वी लॉगिन आणि रिव्होकेशन्सचे दरमहा पुनरावलोकन केले जाते का? |
| प्रवेश स्वयंचलितपणे रद्द (Revoke) करा | माजी कर्मचारी आणि कालबाह्य कंत्राटदारांचा प्रवेश सुरू राहणे | कर्मचारी, कंत्राटदार आणि भाडेकरूंचे नेटवर्क्स | डिरेक्टरी बदलापासून नेटवर्कवरून काढण्यापर्यंत किती वेळ लागतो? |
उत्तम नेटवर्क सराव म्हणजे विक्रेत्याची डीफॉल्ट सेटिंग्ज एकदा लागू करून ती विसरून जाणे नव्हे. हा वास्तविक धोक्यांशी जुळणारा, लोक आणि डिव्हाइसेस व्यवहारात नेटवर्कचा कसा वापर करतात याविरुद्ध तपासलेला आणि त्या गरजा बदलल्यानुसार राखला जाणारा नियंत्रणांचा संच आहे.
तीन वेगवेगळ्या प्रेक्षकांसाठी डिझाइन करा
गेस्ट्सना सोप्या कनेक्टिव्हिटीची गरज असते, परंतु ते अंतर्गत प्रणालींपर्यंत पोहोचू नयेत. कर्मचाऱ्यांना त्यांच्या भूमिकांनुसार विशिष्ट ॲप्लिकेशन्सचा ॲक्सेस मिळणे आवश्यक आहे, आणि तो ॲक्सेस हटवण्याची एक विश्वासार्ह पद्धत असणे आवश्यक आहे. ऑपरेशनल डिव्हाइसेस, जसे की टिल्स, सेन्सर्स आणि बिल्डिंग कंट्रोल्सना सहसा फक्त थोड्या प्रमाणातील सेवांशी संवाद साधावा लागतो आणि ते आधुनिक साइन-इन पद्धतींना सपोर्ट करू शकत नाहीत.
एक सामायिक केलेले नेटवर्क एकाच वेळी तिन्ही गटांना निष्फळ ठरवते. सामायिक केलेला पासवर्ड कोणी किंवा कशाने कनेक्ट केले हे ओळखणे कठीण करतो, तर विस्तृत प्रवेशामुळे एक त्रुटी असलेले उपकरण अशा सिस्टीमपर्यंत पोहोचू शकते ज्याच्याशी त्याचा काहीही संबंध नाही. सुरक्षित एन्क्रिप्ट केलेले WiFi कनेक्शन देखील त्या प्रवेशाची समस्या सोडवत नाही.
त्रुटी तपासण्यासाठी या तक्त्याचा वापर करा. कोणत्याही पहिल्या तपासणीच्या प्रश्नाचे प्रामाणिक उत्तर नाही असे असल्यास, त्या ओळीला पहिल्या दुरुस्तीचा पर्याय म्हणून समजा. या मार्गदर्शकाचा उर्वरित भाग झोनची रचना कशी करावी, ऑथेंटिकेशन कसे निवडावे, बदलांदरम्यान सेवा कशी सुरू ठेवावी आणि जेव्हा लोक किंवा उपकरणांना गरज नसेल तेव्हा प्रवेश कसा काढून घ्यावा हे स्पष्ट करतो.
स्थळे आणि उपक्रमांसाठी नेटवर्क झोन कसे डिझाइन करावे
वेन्यू नेटवर्क हे एखाद्या इमारतीसारखे असते: प्रत्येक खोलीला स्वतःचे कुलूप असणे आवश्यक आहे. हॉटेलच्या अतिथींच्या खोल्या, बॅक ऑफिस, किचन टिल्सन आणि प्लांट रूमसाठी एकच कल्ली वापरली जाऊ नये. डिव्हाइसेसचे गट फक्त मजला किंवा स्विचनुसार न करता, ते कोण वापरते आणि ते काय करतात यानुसार करा.
| झोन | ठराविक वापरकर्ते आणि डिव्हाइसेस | अनुमती दिलेला ॲक्सेस | मुख्य नियंत्रण |
|---|---|---|---|
| पाहुणे | भेट देणाऱ्यांचे फोन आणि लॅपटॉप | केवळ इंटरनेट, कोणतेही अंतर्गत पत्ते नाहीत | स्वतःचे VLAN, क्लायंट आयसोलेशन आणि सत्र मर्यादा |
| कर्मचारी | व्यवस्थापित लॅपटॉप आणि हँडहेल्ड्सवरील कर्मचारी | त्यांच्या भूमिकेसाठी नामांकित अंतर्गत ॲप्स | प्रमाणपत्र किंवा डिरेक्टरी साइन-इन आणि भूमिका-आधारित धोरण |
| ऑपरेशनल आणि IoT | टिल्स, सेन्सर्स, बिल्डिंग कंट्रोल्स आणि प्रिंटर्स | केवळ व्हेंडर सेवा किंवा कंट्रोलर | स्वतंत्र VLAN आणि डीफॉल्टनुसार नाकारा नियम |
| भाडेकरू किंवा रहिवासी | प्रत्येक रहिवाशाचे फोन, कंसोल आणि टीव्ही | केवळ त्यांचे स्वतःचे खाजगी नेटवर्क | प्रति भाडेकरू युनिक की आणि भाडेकरूंमध्ये आयसोलेशन |
| व्यवस्थापन | ॲक्सेस पॉइंट्स, स्विचेस आणि कंट्रोलर्स | व्यवस्थापित डिव्हाइसवरून नामांकित ॲडमिन्स | स्वतंत्र व्यवस्थापन प्लेन आणि ॲडमिन लॉगिनवर MFA |
वास्तविक अवलंबित्वांवरून झोन तयार करा
प्रथम, प्रत्येक उपकरणाचा वर्ग आणि त्याच्या मालकाची यादी करा. प्रिंटर, बिल्डिंग नियंत्रणे, पेमेंट टर्मिनल्स आणि ॲक्सेस पॉइंट्स यासारख्या कमी दृश्यमान उपकरणांचा समावेश करा. जेव्हा उपकरण बदलले जाते किंवा त्याचा उद्देश बदलतो तेव्हा नामांकित मालकाशिवाय इन्व्हेंटरी तंतोतंत ठेवणे कठीण असते.
दुसरे, कोणत्या झोनला संवाद साधणे आवश्यक आहे आणि त्यांना कोणत्या सेवांची आवश्यकता आहे याचा मॅप तयार करा. "टिल्सना नेटवर्क ॲक्सेस आवश्यक आहे" असे लिहू नका; त्यांना पेमेंट सर्व्हिस किंवा कोणत्या कंट्रोलरपर्यंत पोहोचणे आवश्यक आहे ते स्पष्ट करा. तिसरे, बाय डीफॉल्ट झोनमधील संवादाला नकार द्या, आणि नंतर फक्त तुमच्या मॅपमधील फ्लोला अनुमती द्या. बारच्या कार्ड टर्मिनलला त्याच्या पेमेंट प्रदात्यापर्यंत पोहोचण्याची आवश्यकता असू शकते, परंतु कर्मचाऱ्यांच्या फाइल शेअरपर्यंत पोहोचण्याचे कोणतेही कारण नाही.
या दृष्टिकोनासाठी सर्व डिव्हाइसेस एकाच नेटवर्कवर ठेवण्यापेक्षा अधिक नियोजनाची आवश्यकता असते. जेव्हा खरी व्यावसायिक गरज बदलते तेव्हा यामुळे काम देखील निर्माण होते, कारण कोणीतरी संबंधित नियम अपडेट केला पाहिजे आणि त्याची चाचणी घेतली पाहिजे. हा एक चांगला व्यवहार आहे: कोणीतरी जोडल्याचे कोणाच्याही लक्षात नसलेल्या विस्तृत अपवादांच्या संग्रहापेक्षा स्पष्ट, मर्यादित पॉलिसीचे पुनरावलोकन करणे सोपे असते.
2025 मध्ये, UK Government's Cyber Security Breaches Survey 2025 technical report नुसार, 3% UK व्यवसायांनी मागील 12 महिन्यांत रॅन्समवेअर ब्रीच किंवा हल्ल्याचा अनुभव घेतल्याचे नमूद केले आहे. डिव्हाइस सुरक्षितता धोक्यात आल्यास सेगमेंटेशन परिणाम नियंत्रित करण्यात मदत करते. एका संक्रमित टिलचा (till) ऑफिस सिस्टीमपर्यंत मार्ग नसावा.
गेस्ट ट्रॅफिक त्याच्या स्वतःच्या VLAN वर असू शकते. कॉन्फिगर करा जेणेकरून व्हिजिटरचा लॅपटॉप अंतर्गत पत्ते न पाहता इंटरनेटवर ॲक्सेस मिळवू शकेल, आणि केवळ नेटवर्क आकृतीवर अवलंबून राहण्याऐवजी गेस्ट डिव्हाइसवरून हे वेगळेपण तपासा. VLAN एक उपयुक्त सीमा प्रदान करते, परंतु नेटवर्कमधील प्रत्येक विनंती सुरक्षित असल्याचा तो पुरावा नाही. कोणते सर्व्हिसेस आणि सिस्टीम्स संवाद साधू शकतात हे ठरवण्यासाठी अद्याप ॲक्सेस नियमांची आवश्यकता आहे.
अतिथी आणि कर्मचाऱ्यांसाठी ऑथेंटिकेशन निवडणे
SSID ऐवजी ओळख आणि उपकरणाच्या क्षमतेनुसार ऑथेंटिकेशन निवडा. पाहुण्यांनी ऑथेंटिकेट केले असले तरीही अतिथी नेटवर्कला अविश्वासू मानले पाहिजे. कर्मचाऱ्यांच्या प्रवेशासाठी स्वतःची ओळख तपासणी आणि जेव्हा एखादी व्यक्ती किंवा उपकरण यापुढे पात्र राहत नाही तेव्हा प्रवेश काढून घेण्याची प्रक्रिया आवश्यक असते.
| पद्धत | प्रति वापरकर्ता किंवा डिव्हाइस ओळख | इतरांना स्पर्श न करता एका वापरकर्त्यास मागे घ्या | सर्वात योग्य |
|---|---|---|---|
| सामायिक प्री-शेअर की | नाही | नाही, प्रत्येक डिव्हाइसला नवीन की आवश्यक आहे | लेगसी डिव्हाइसेस आणि लहान खाजगी साइट्स |
| ईमेल किंवा सोशल लॉगिनसह Captive portal | प्रति भेट देणारा खाते | होय, पोर्टलद्वारे | स्थळांमधील अधूनमधून येणारे पाहुणे |
| Passpoint किंवा OpenRoaming | प्रति डिव्हाइस आणि खाते | होय, प्रदात्याद्वारे | स्वयंचलित कनेक्शन इच्छिणारे पुन्हा येणारे पाहुणे |
| Identity PSK (xPSK) | प्रति डिव्हाइस किंवा व्यक्ती एक की | होय, ती की मागे घ्या | IoT आणि प्रमाणपत्रे चालवू न शकणारे डिव्हाइसेस |
| प्रमाणपत्रांसह 802.1X | प्रति डिव्हाइस एक प्रमाणपत्र | होय, प्रमाणपत्र मागे घ्या किंवा नूतनीकरण थांबवा | व्यवस्थापित कर्मचारी लॅपटॉप आणि हँडहेल्ड्स |
| डिरेक्टरी साइन-इनसह 802.1X | प्रति वापरकर्ता, डिरेक्टरीशी लिंक केलेले | होय, खाते अक्षम करा | कॉर्पोरेट खात्यांसह साइन इन करणारे कर्मचारी |
ऍक्सेस पद्धतीला पद्धतीनुसार जुळवा
कधीतरी येणाऱ्या पाहुण्यांसाठी, Captive Portal एखाद्या भेट देणाऱ्याला अशा खात्याशी जोडू शकते जे ठिकाण रद्द करू शकते. हे पोर्टल प्रवेश नियंत्रित करते, प्रवेश दिलेल्या उपकरणाला कशापर्यंत पोहोचता येते हे नाही. पाहुण्यांचा ट्रॅफिक वेगळा ठेवा आणि साइन-इन केल्यानंतर प्रवेश मर्यादित करा. ऑथेंटिकेशन नेटवर्क पॉलिसीची जागा घेत नाही.
पुन्हा येणाऱ्या पाहुण्यांसाठी, Passpoint किंवा OpenRoaming प्रोफाइल प्रोव्हिजन झाल्यावर स्वयंचलित कनेक्शनला अनुमती देऊन वारंवार साइन-इन करणे कमी करू शकते. तो ट्रॅफिक कर्मचारी आणि ऑपरेशनल सेवांपासून वेगळा ठेवा. सोयीमुळे पाहुणे कसे कनेक्ट होतात ते बदलते, त्यांना किती प्रवेश मिळावा हे नाही.
कर्मचाऱ्यांच्या उपकरणांना एखाद्या व्यक्तीशी किंवा व्यवस्थापित उपकरणाशी जोडलेल्या क्रेडेंशियल्सची आवश्यकता असते. प्रमाणपत्रांसह 802.1X प्रत्येक व्यवस्थापित उपकरणाला वैयक्तिक क्रेडेंशियल देते. डिरेक्टरी-आधारित साइन-इन प्रवेशास कॉर्पोरेट खात्याशी जोडते, त्यामुळे ते खाते निष्क्रिय केल्याने वापरकर्त्याचा प्रवेश काढला जाऊ शकतो. संस्थेच्या विद्यमान आयडेंटिटी आणि डिव्हाइस-व्यवस्थापन प्रक्रियांना अनुकूल असलेला पर्याय निवडा आणि डीप्लॉयमेंटपूर्वी ते रद्द करण्यासाठी मालकी नियुक्त करा. त्या मालकाशिवाय, कर्मचार्‍यांचे खाते किंवा उपकरण काढून टाकले जाणे आवश्यक असतानाही त्यांचा प्रवेश कायम राहू शकतो.
xPSK, किंवा आयडेंटिटी प्री-शेअर की, सेन्सर्स, जुने टिल्स आणि प्रमाणपत्रे वापरू न शकणाऱ्या इतर उपकरणांसाठी योग्य आहे. प्रत्येक डिव्हाइस किंवा व्यक्तीसाठी स्वतंत्र की असल्याने ऑपरेटर संपूर्ण इस्टेटमधील क्रेडेंशियल्स न बदलता एका आयडेंटिटीचा ॲक्सेस रद्द करू शकतो. शेअर केलेल्या प्री-शेअर की ला कोणतीही वैयक्तिक आयडेंटिटी नसते: एका युजरला हटवणे म्हणजे प्रत्येक डिव्हाइसवर नवीन की वितरीत करणे असू शकते, आणि चुकलेल्या डिव्हाइसेसचा ॲक्सेस तसाच राहू शकतो.
Purple च्या कर्मचारी WiFi कनेक्शन पद्धतींमध्ये Passpoint, xPSK, Certificate WiFi आणि MDM द्वारे WiFi समाविष्ट आहे. Staff WiFi व्यवसायाच्या आधीपासूनच मालकीच्या असलेल्या ॲक्सेस पॉइंट्सवर चालते, ज्यामध्ये कोणतेही PKI तयार करावे लागत नाही. एंटरप्राइझ ऑथेंटिकेशन आवश्यक असलेल्या कर्मचार्‍यांसाठी, WPA-Enterprise सामायिक पासवर्डऐवजी 802.1X वापरते. ऑपरेशनल तडजोड सरळ आहे: मजबूत वैयक्तिक क्रेडेंशियल्स नियंत्रण सुधारतात, परंतु त्यांना प्रोव्हिजनिंग, नूतनीकरण आणि रिव्होकेशनसाठी स्पष्ट प्रक्रियेची आवश्यकता असते.
UK Information Commissioner's Office चेतावणी देते की सुरक्षित नसलेले WiFi खाजगी फाइल्स आणि माहिती उघड करू शकते. त्यांचे WiFi सुरक्षा मार्गदर्शन एन्क्रिप्शन वापरण्याची आणि अनोळखी नेटवर्कवर ऑटोमॅटिक कनेक्शन बंद करण्याची शिफारस करते. ते संरक्षण लागू करा, नंतर गेस्ट ॲक्सेसला अविश्वासू मानून त्यावर उपचार करा: योग्य तिथे युजर्स किंवा डिव्हाइसेसचे प्रमाणीकरण करा, ट्रॅफिक वेगळे करा आणि ॲक्सेस निर्णयांची नोंद ठेवा.
NCSC's zero-trust architecture principles वापरकर्ते, डिव्हाइसेस आणि सेवा ओळखण्यावर, संदर्भाचे मूल्यमापन करण्यावर आणि पॉलिसीनुसार प्रत्येक विनंतीला अधिकृत करण्यावर लक्ष केंद्रित करतात. व्यवहारात, याचा अर्थ असा की प्रमाणीकरण (authentication) हा निर्णयाचा एक भाग आहे. अतिथी आणि कर्मचाऱ्यांचा एक्सेस वेगळा ठेवा, जिथे डिव्हाइस सपोर्ट करते तिथे क्रेडेंशियल्स वैयक्तिकरित्या मागे घेण्यायोग्य (revocable) करा, आणि ओळख किंवा डिव्हाइसची स्थिती बदलते तेव्हा कोण कारवाई करते ते परिभाषित करा.
सामायिक जोखमीशिवाय मल्टी-टेनंट नेटवर्क
एका अपार्टमेंट इमारतीमध्ये पाईप्स आणि मीटर शेअर केले जातात, परंतु प्रत्येक फ्लॅटचे स्वतःचे दार लॉक असते. शेअर केलेले WiFi इन्स्टॉलेशन देखील अशाच प्रकारे कार्य करू शकते. शेअर केलेल्या ॲक्सेस पॉइंट्सचा अर्थ शेअर केलेला ॲक्सेस असा असण्याची गरज नाही: महत्त्वाचा प्रश्न असा आहे की प्रत्येक भाडेकरूची वेगळी ओळख आणि खाजगी नेटवर्क आहे की नाही, आणि डिझाइन एका भाडेकरूला दुसऱ्या भाडेकरूपर्यंत पोहोचण्यापासून रोखते की नाही.
प्रत्येक रहिवाशाचा ऍक्सेस वैयक्तिक ठेवा
प्रत्येक रहिवासी, भाडेकरू किंवा डिव्हाइसला एक युनिक की द्या, आणि नंतर प्रत्येक भाडेकरूचे ट्रॅफिक इतरांपासून विभक्त करा. xPSK सह, संपूर्ण इमारतीचे क्रेडेंशियल्स न बदलता एका ओळखीसाठी की रद्द केली जाऊ शकते. जेव्हा एखादा रहिवासी सोडून जातो तेव्हा पुन्हा वितरीत कराव्या लागणाऱ्या एकाच शेअर केलेल्या पासवर्डपेक्षा हे मूव्ह-इन आणि मूव्ह-आउटसाठी अधिक सोयीस्कर आहे.
ब्राउझर नसलेल्या डिव्हाइसेसकडे विशेष लक्ष देण्याची गरज आहे. टेलिव्हिजन किंवा गेम्स कन्सोल Captive Portal उघडण्यास आणि वेब-आधारित साइन-इन पूर्ण करण्यास सक्षम नसू शकतात. ते कनेक्ट होण्यापूर्वी त्याला आयडेंटिटी प्रोव्हिजन करणे आवश्यक आहे, जेणेकरून ते शेजारी किंवा इमारत व्यवस्थापनाद्वारे वापरल्या जाणाऱ्या नेटवर्कवर परवानगी न मिळवता रहिवाशांच्या खाजगी नेटवर्कमध्ये सामील होऊ शकेल.
Purple चे Multi-Tenant Wi-Fi guide कन्सोल आणि टीव्हीसह त्यांच्या डिव्हाइसेसवर प्रत्येक रहिवाशासाठी प्रायव्हेट नेटवर्कचे वर्णन करते. याचे Multi-Tenant WiFi प्रत्येक रहिवाशाचे नेटवर्क इतर अतिथींपासून आयसोलेटेड ठेवते, आणि याचा xPSK दृष्टिकोन टेनंट आयसोलेशनसह एक अद्वितीय प्री-शेअर की प्रदान करतो. हे प्रॉपर्टी टीम्सना प्रत्येक घराला स्वतंत्र एक्सेस सीमा देत सामायिक इन्फ्रास्ट्रक्चर वापरण्याची अनुमती देते.
जागा सोडण्याला ऍक्सेस बदल मानून हाताळा
जेव्हा एखादे फ्लॅट रिकामे केले जाते, तेव्हा त्या भाडेकरूच्या क्यु रद्द करा आणि संबंधित प्रवेश काढून टाका. संपूर्ण इमारतीसाठी एकच पासवर्ड बदलू नका आणि प्रत्येक रहिवाशाला पुन्हा कनेक्ट होण्यास सांगू नका. याचा व्यावहारिक फायदा सुरक्षा आणि सेवा दोन्ही आहे: एका व्यक्तीच्या जाण्याने इतर प्रत्येक भाडेकरूसाठी सपोर्टची समस्या निर्माण होऊ नये.
मल्टी-टेनंट डिझाईन्स इमारतीमध्ये आधीच स्थापित केलेल्या एक्सेस पॉईंट्सचा वापर करू शकतात, ज्यामध्ये Meraki, Aruba, Ruckus आणि UniFi यांचा समावेश आहे. वैयक्तिक ओळख सुरू करण्यासाठी कार्यरत हार्डवेअर बदलणे टाळता येऊ शकते, तरीही ओळख स्तर कॉन्फिगर करणे आणि ऑपरेट करणे आवश्यक आहे. डिझाईन मंजूर करण्यापूर्वी, एका टेनंटच्या डिव्हाइसवरून दुसऱ्या डिव्हाइसवर आयसोलेशनची चाचणी घ्या, नवीन रहिवाशाला किती वेगाने की (key) मिळू शकते याचे मोजमाप करा आणि फ्लॅट रिकामा झाल्यावर एक्सेस रद्द करण्यासाठी जबाबदार व्यक्ती किंवा टीमचे नाव निश्चित करा.
साइन-ऑफ चाचणी: एका भाडेकरूला चाचणी उपकरण द्या, नंतर दुसऱ्या भाडेकरूच्या उपकरणांपर्यंत आणि बिल्डिंग-मॅनेजमेंट नेटवर्कपर्यंत पोहोचण्याचा प्रयत्न करा. दोन्ही प्रयत्न अयशस्वी झाले पाहिजेत.
आउटेज रोखणारे मॉनिटरिंग आणि चेंज कंट्रोल
कॉन्फिगरेशन बदलांमुळे ग्राहकांवर गंभीर परिणाम होऊ शकतो. Ofcom च्या कनेक्टेड नेशन्स रिपोर्टमध्ये असे आढळून आले की नेटवर्क बदलाच्या उपक्रमांमुळे ग्राहकांच्या वाया गेलेल्या तासांच्या दृष्टीने सर्वात गंभीर प्रकरणे निर्माण झाली, तर हार्डवेअर दोषांमुळे एकूण वाया गेलेल्या तासांपैकी एक तृतीयांशपेक्षा कमी तास नोंदवले गेले. Ofcom कनेक्टेड नेशन्स UK रिपोर्ट चेंज कंट्रोलला मुख्य विश्वासार्हता पद्धत बनवतो, केवळ मोठ्या अपग्रेडसाठी राखीव कागदोपत्री काम नाही.
प्रत्येक बदल पूर्ववत करण्यायोग्य ठेवा
फायरवॉल नियम, SSID बदल, कंट्रोलर अपडेट्स आणि ऑथेंटिकेशन-पॉलिसी संपादनांसाठी हीच छोटी रुटीन वापरा:
- प्रथम लॅब नेटवर्कवर किंवा एका साइटवर बदलाची चाचणी करा.
- सेवेवर अवलंबून असलेल्या लोकांसाठी सोयीची बदल विंडो शेड्युल करा.
- कामास मंजूरी देऊ शकणाऱ्या आणि त्याचे निरीक्षण करू शकणाऱ्या एका नियुक्त मालकाची नोंद करा.
- शुरू करण्यापूर्वी रोलबॅक स्टेप लिहा, आणि मागील कॉन्फिगरेशन उपलब्ध असल्याची खात्री करा.
लॅबमध्ये कार्य करणारा बदल एखाद्या व्यस्त साइटवर अयशस्वी होऊ शकतो जर तिची डिव्हाइसेस किंवा अवलंबित्व भिन्न असतील. टप्प्याटप्प्याने रोल आउट करा, प्रत्येक टप्प्यानंतर ऑथेंटिकेशन आणि ॲक्सेस तपासा, आणि जर निरीक्षित वर्तन अपेक्षित परिणामाशी जुळत नसेल तर थांबवा. रोलबॅक प्लॅन कसा अंमलात आणायचा हे कोणालाच माहित नसेल तर तो उपयुक्त ठरत नाही.
| सिग्नल | हे तुम्हाला काय सांगते | इशाऱ्याचे चिन्ह |
|---|---|---|
| ऑथेंटिकेशन अयशस्वी होण्याचा दर | चुकीचे क्रेडेंशियल्स, मुदतबाह्य झालेली प्रमाणपत्रे किंवा खराब पॉलिसी | बदल किंवा नूतनीकरणाच्या तारखेनंतर अचानक झालेली वाढ |
| RADIUS रिस्पॉन्स टाइम | ऑथेंटिकेशन सर्व्हर पीक वेळेत टिकून राहतो की नाही | चेक इन वेळी किंवा व्यस्त वेळेत मंद लॉगिन |
| डिरेक्टरी-टू-रिव्होकेशन वेळ | काम सोडणारी व्यक्ती किती काळ नेटवर्क ॲक्सेस ठेवते | सहमती दिलेल्या लक्ष्यापेक्षा जास्त वेळ, उदाहरणार्थ एक कामकाजाचा तास |
| अंतर्गत श्रेणींपर्यंत पोहोचणारा गेस्ट ट्रॅफिक | गेस्ट सेगमेंटेशन टिकून आहे की नाही | शून्यापेक्षा जास्त कोणतीही संख्या |
| अनतिकीट केलेले कॉन्फिगरेशन बदल | कोणी, काय आणि कधी बदलले | मालक किंवा नोंद नसलेला कोणताही बदल |
| प्रति झोन क्लायंट संख्या | क्षमता आणि असामान्य वापर | शांत वेळेत सातत्याने होणारी वाढ |
प्रत्येक अपयशी लॉगिनवर नाही, तर बदल आणि महत्त्वाच्या ट्रेंडवर अलर्ट सेट करा. कर्मचाऱ्यांना कमी मूल्याच्या अलर्टचा पूर आला, तर ते त्याकडे दुर्लक्ष करायला शिकतील. ऑथेंटिकेशन अपयशाचे दर आणि रद्द करण्याचा वेळ नियमितपणे तपासा, आणि एखाद्या बदलाशी, प्रमाणपत्राच्या नूतनीकरणाशी किंवा व्यस्त ऑपरेटिंग कालावधीशी संबंधित अचानक झालेल्या वाढीची चौकशी करा.
ॲक्सेस पॉइंट्स, स्विचेस, कंट्रोलर्स आणि VPN उपकरणांना निश्चित फर्मवेअर वेळापत्रकावर ठेवा. प्रत्येक साइटवर चालणाऱ्या व्हर्जनची नोंद ठेवा जेणेकरून टीम कोणत्या ठिकाणांवर काम करणे आवश्यक आहे आणि बदलामुळे नवीन समस्या निर्माण झाली आहे का ते ओळखू शकेल. ॲनालिटिक्स गती आणि स्थळाचे कव्हरेज दाखवण्यात मदत करू शकतात; Purple Connect मध्ये नेटवर्क ॲनालिटिक्स समाविष्ट आहे जे दोन्हीचे निरीक्षण करते. जर एखादा प्लॅटफॉर्म वापर किंवा वापरकर्ता लोकसंख्याशास्त्र नोंदवत असेल, तर प्रथम उद्देश आणि कायदेशीर आधार निश्चित करा, नंतर संकलन स्थळाला काय आवश्यक आहे तेवढेच मर्यादित करा. Purple चे पोर्टल वापरकर्ता लोकसंख्याशास्त्रासह साप्ताहिक WiFi वापर KPI देखील पाठवते, त्यामुळे ते रिपोर्टिंग वापरण्यापूर्वी तुमच्या संस्थेला कशाचे पुनरावलोकन करणे आवश्यक आहे ते ठरवा.
एखादी व्यक्ती सोडून गेल्यावर ऍक्सेस कसा काढून घ्यावा
शेअर केलेली की (key) माजी कर्मचाऱ्याचे डिव्हाइस त्यांची भूमिका संपल्यानंतरही कनेक्ट ठेवू शकते. पुनरावृत्ती करता येणाऱ्या रिव्होकेशन प्रक्रियेसह, नेटवर्क एक्सेसला स्पष्ट ओळख आणि डिव्हाइस लाईफसायकलशी जोडून ते टाळा. NCSC चे 2025 चे नेटवर्क-सुरक्षा मार्गदर्शन किमान अधिकार (least privilege), ओळख आणि नेटवर्क आर्किटेक्चर समजून घेणे आणि डिव्हाइस आरोग्य व वर्तनाकडे सतत लक्ष देण्यावर भर देते. यात असेही म्हटले आहे की VPN सॉफ्टवेअर आणि ॲप्लायन्सेसना त्यांच्या संपूर्ण लाईफसायकल दरम्यान देखभालीची आवश्यकता असते.
प्रत्येक वेळी तोच रिव्होकेशन क्रम वापरा
- डिरेक्टरी खाते निष्क्रिय करा किंवा नेटवर्क ॲक्सेस देणारा स्टाफ ग्रुप हटवा. यामुळे टीमला ॲक्सेस समाप्त करण्यासाठी एक केंद्रीय नियंत्रण बिंदू मिळतो.
- डिव्हाइस प्रमाणपत्रे मागे घ्या किंवा नूतनीकरण करणे थांबवा. त्या व्यक्तीला नियुक्त केलेले प्रत्येक मॅनेज केलेले डिव्हाइस तपासा, कारण खाते बदलल्यानंतरही डिव्हाइस क्रेडेंशियल वापरण्यायोग्य राहू शकते.
- व्यक्तिची आयडेंटिटी की रद्द करा. त्यांनी वैयक्तिक xPSK वापरल्यास, इतर वापरकर्त्यांसाठी क्रेडेंशियल बदलण्याऐवजी ती की हटवा.
- डिव्हाइस पुन्हा ऑथेंटिकेट करू शकत नाही याची चाचणी करा. चाचणी खाते किंवा हटवलेले डिव्हाइस वापरा आणि नवीन कनेक्शनचा प्रयत्न अयशस्वी झाल्याची पुष्टी करा.
- रद्द केल्यानंतरच्या सत्रांसाठी ऑथेंटिकेशन लॉगचे पुनरावलोकन करा. ॲक्सेस बदलल्यानंतर यशस्वी लॉगिन झाल्यास तपासणी करणे आवश्यक आहे.
- मॅनेज केलेले हार्डवेअर रिकव्हर करा किंवा वाईप करा, नंतर निघून गेलेला वेळ नोंदवा. डिरेक्टरी बदलापासून ते डिव्हाइस नेटवर्कमध्ये सामील होण्यास असमर्थ असल्याची पुष्टी होईपर्यंत वेळ मोजा.
कंत्राटदारांना एक समाप्ती तारीख द्या जी त्यांचा ऍक्सेस आपोआप रद्द करेल. जेव्हा एखादा भाडेकरू सोडतो, तेव्हा याच प्रक्रियेचा वापर करून त्यांची स्वतःची की रद्द करा. एखादे डिव्हाइस हरवल्यास, अनुसूचित पुनरावलोकनाची वाट पाहण्याऐवजी त्याचे सर्टिफिकेट किंवा आयडेंटिटी की त्वरित रद्द करा.
रद्दीकरणादरम्यान (revocation) ओळख मार्ग उपलब्ध राहणे आवश्यक आहे. सिंगल ऑन-प्रीमिस प्रमाणीकरण सर्व्हरमधील त्रुटीमुळे एक्सेस काढण्यास उशीर होऊ शकतो, तर जुने VPN किंवा ॲप्लायन्स सॉफ्टवेअर अतिरिक्त धोका निर्माण करू शकते. Purple चे staff WiFi lifecycle approach 99.9% uptime SLA सह क्लाउड RADIUS वापरते. कोणतीही सिस्टीम अमलात असली तरी, एक्सेस काढण्याची जबाबदारी एका मालकाकडे सोपवा आणि तातडीने निघून जाण्यापूर्वी प्रक्रियेची चाचणी घ्या.
डिरेक्टरी बदलापासून नेटवर्क रिमूव्हलपर्यंतच्या वेळेचा मागोवा घ्या आणि मान्य केलेल्या मर्यादेशी दरमहा याचे पुनरावलोकन करा. ॲक्सेस लक्ष्यापेक्षा जास्त काळ राहिल्यास, विलंबाचा बिंदू ओळखा: डिरेक्टरी सिंक्रोनायझेशन, प्रमाणपत्र हाताळणी, मॅन्युअल कार्य, किंवा इन्व्हेंटरीमधून गहाळ असलेले डिव्हाइस. स्पष्ट नोंदीमुळे वारंवार येणाऱ्या त्रुटी दुरुस्त करणे सोपे होते.
गो-लाइव्ह पूर्वीची डिप्लॉयमेंट चेकलिस्ट
पॉलिसी स्क्रीनपासून नाही, तर उपकरणांच्या इनव्हेंटरीपासून सुरुवात करा. प्रत्येक ॲक्सेस पॉइंट, स्विच आणि कंट्रोलर, त्याची फर्मवेअर आवृत्ती आणि त्याचा मालक यांची नोंद करा. xPSK आणि Multi-Tenant WiFi हे Meraki, Aruba, Ruckus आणि UniFi ॲक्सेस पॉइंट्सना सपोर्ट करतात, त्यामुळे आयडेंटिटीच्या कामाचे नियोजन करण्यापूर्वी सपोर्ट केलेल्या लिस्टविरुद्ध प्रत्येक साइटचे हार्डवेअर तपासा.
या तपासण्या क्रमाने चालवा. पास स्थिती ही अशी गोष्ट असावी जी तुम्ही तपासू शकता आणि नोंदवू शकता, केवळ तोंडी आश्वासन नाही.
- डिव्हाइसेसची यादी तयार करा. प्रत्येक ॲक्सेस पॉइंट, स्विच आणि कंट्रोलरची फर्मवेअर आवृत्ती आणि नियुक्त ओनरची नोंद असल्यास पास मानले जाईल.
- ॲडमिन ॲक्सेस सुरक्षित करा. डीफॉल्ट ॲडमिन पासवर्ड बदलले गेल्यास आणि न वापरलेले मॅनेजमेंट इंटरफेस डिसेबल केल्यास पास मानले जाईल.
- मॅनेजमेंट ट्रॅफिक वेगळा करा. मॅनेजमेंट सिस्टीम्स अतिथी आणि कर्मचाऱ्यांच्या VLANs पेक्षा वेगळ्या नेटवर्कवर असल्यास पास मानले जाईल.
- अतिथी आयसोलेशनची चाचणी घ्या. अतिथी डिव्हाइसला कंट्रोलर ॲड्रेससह अंतर्गत ॲड्रेसेसवरून कोणताही प्रतिसाद न मिळाल्यास पास मानले जाईल.
- कर्मचाऱ्यांच्या परवानग्या तपासा. कर्मचारी डिव्हाइस त्याच्या भूमिकेसाठी मंजूर असलेल्या ॲप्लिकेशन्सपर्यंत पोहोचू शकत असल्यास, आणि इतर अंतर्गत सेवांपर्यंत नाही, तर पास मानले जाईल.
- प्रमाणपत्रे तपासा. कालबाह्यता तारखा नोंदवल्या गेल्यास आणि नूतनीकरण धमक्या/अलर्ट्स सक्रिय असल्यास पास मानले जाईल.
- RADIUS लवचिकतेची चाचणी घ्या. बॅकअप ऑथेंटिकेशन पाथ उपलब्ध असल्यास आणि दस्तऐवजीकरण केलेला फॉलबॅक यशस्वीरीत्या कार्य करत असल्यास पास मानले जाईल.
- लॉगिंगची पडताळणी करा. ऑथेंटिकेशन इव्हेंट्स लॉग स्टोअरमध्ये पोहोचत असल्यास आणि पुनरावलोकनासाठी प्राप्त करता येत असल्यास पास मानले जाईल.
- रिव्होकेशन सराव करा. डिरेक्टरी बदलामुळे प्रवेश काढून टाकला गेल्यास आणि लागलेला वेळ नोंदवला गेल्यास पास मानले जाईल.
- बॅकअप आणि रोलबॅक योजना जतन करा. सध्याच्या कॉन्फिगरेशनचा बॅकअप घेतला असल्यास आणि बदल करणाऱ्या ओनरकडे लिखित रोलबॅक पायऱ्या उपलब्ध असल्यास पास मानले जाईल.
लाइव्ह सेवेशी संबंधित असलेल्या तपासण्यांसाठी, नियंत्रित वेळेत चाचणी करा आणि मागील कॉन्फिगरेशन पुनर्संचयित करण्यासाठी बदलाचा मालक तयार ठेवा. कंट्रोलर पत्त्यावरून कोणताही प्रतिसाद न देणारे अतिथी उपकरण हे स्वतंत्र VLAN दर्शवणाऱ्या आकृतीपेक्षा अधिक मजबूत चाचणी निकाल आहे.
लाँच केल्यानंतर प्रोजेक्ट फोल्डरमध्ये बसणारी चेकलिस्ट नेटवर्क सुरक्षित ठेवणार नाही. ती ठरलेल्या वेळापत्रकानुसार आणि जेव्हा एखादी साइट, डिव्हाइस क्लास किंवा ॲक्सेस पॉलिसी बदलते तेव्हा पुन्हा रन करा.
कोणती सराव पद्धत प्रथम सुधारायची ते ठरवा
सर्वात मोठा धोका निर्माण करणाऱ्या त्रुटीपासून सुरुवात करा, प्रोजेक्ट अपडेटमध्ये वर्णन करायला सर्वात सोप्या असलेल्या गोष्टीपासून नाही. जर कर्मचाऱ्यांचा शेअर केलेला पासवर्ड ठिकाणाच्या प्रत्येक भागात पोहोचत असेल, तर आधी तो बदला: एक लीक झालेली की कोणत्याही अनधिकृत व्यक्तीला व्यापक ॲक्सेस देऊ शकते. त्यानंतर, काम सोडणाऱ्या कर्मचाऱ्यांची प्रक्रिया सुधारा, जेणेकरून नोकरी संपल्यानंतर ॲक्सेस चालू राहणार नाही. नंतर गेस्ट ट्रॅफिकला अंतर्गत सिस्टीम्सपासून वेगळे करा.
काम ९० दिवसांच्या मार्गावर ठेवा
- आठवडे 1 ते 2: साइट आणि डिव्हाइस इन्व्हेंटरी तयार करा, मालकांची नावे निश्चित करा आणि झोन व आवश्यक संप्रेषण मार्ग मॅप करा.
- आठवडे 3 ते 6: अतिथी आणि कर्मचारी ट्रॅफिक वेगळे करा, नंतर कर्मचार्‍यांना प्रमाणपत्र-आधारित किंवा डिरेक्टरी साइन-इनवर हलवा.
- आठवडे 7 ते 10: नावांकित मालक आणि चाचणी केलेल्या रोलबॅक पायऱ्यांसह मॉनिटरिंग आणि बदल नियंत्रण कार्यान्वित करा.
- आठवडे 11 ते 12: पूर्ण रिव्होकेशन ड्रिल चालवा, नेटवर्क काढून टाकण्याचा वेळ मोजा आणि कोणताही विलंब दुरुस्त करा.
आयडेंटिटी स्टॅक इन-हाऊस चालवायचा की मॅनेज्ड प्लॅटफॉर्म वापरायचा हे सुरुवातीलाच ठरवा. तुमचा स्वतःचा RADIUS सर्व्हर आणि सर्टिफिकेट अथॉरिटी तुम्हाला नियंत्रण देतात, परंतु तुमच्या टीमने त्यांची देखभाल करणे, नूतनीकरणास सपोर्ट देणे आणि अपयशांचे नियोजन करणे आवश्यक आहे. मॅनेज्ड प्लॅटफॉर्म तुमच्या टीमला करावे लागणारे आयडेंटिटीचे काम कमी करू शकते, परंतु स्वाक्षरी करण्यापूर्वी त्याची अपटाइम वचनबद्धता आणि डेटा हाताळणीची पुनरावलोकन करा.
Purple ची Staff WiFi आणि xPSK सोल्यूशन्स ही प्रॉपर्टी पोर्टफोलिओ आकार, ॲक्सेस पॉइंट संख्या आणि आयडेंटिटी प्रदाता आवश्यकतांवर आधारित कस्टम किंमतीत उपलब्ध आहेत. अतिथी Wi-Fi साठी, Purple त्याच्या Capture आणि Engage प्लॅन्सची 30 दिवसांची मोफत चाचणी देते; चाचणीनंतर, ग्राहक निवडलेल्या पॅकेजसह पुढे जाऊ शकतात किंवा मोफत Connect प्लॅनवर जाऊ शकतात. प्रदात्याची निवड पहिली ऑपरेशनल कार्ये बदलत नाही: प्रत्येक साइटच्या हार्डवेअर इन्व्हेंटरीनुसार डीप्लॉयमेंट तपासणी पूर्ण करा, नंतर तुम्हाला जे सापडेल त्यावरून आयडेंटिटी कामाचा आकार ठरवा.
Purple गेस्ट WiFi, स्टाफ ऑथेंटिकेशन आणि मल्टी-टेनंट नेटवर्किंग प्रदान करते जे सपोर्टेड असलेल्या विद्यमान हार्डवेअरवर शेअर केलेले पासवर्ड्स आयडेंटिटी-आधारित ॲक्सेससह बदलण्यासाठी डिझाइन केलेले आहे. तुमच्या साइट्ससाठी पर्याय शोधण्यासाठी आणि वैध युजर्ससाठी ॲक्सेस सोयीस्कर, भूमिकेनुसार मर्यादित आणि रद्द करण्यासाठी सरळ असलेले नेटवर्क प्लॅन करण्यासाठी Purple ला भेट द्या.
