द कंप्लायन्स प्लेबुक: GDPR आणि गेस्ट WiFi डेटा प्रायव्हसी

Purple च्या तांत्रिक माहिती पत्रकामध्ये आपले स्वागत आहे. मी Purple चा एक वरिष्ठ तांत्रिक कंटेंट स्ट्रॅटेजिस्ट आहे आणि आज आपण अशा एका महत्त्वाच्या विषयावर चर्चा करणार आहोत जो प्रत्येक IT व्यवस्थापक, नेटवर्क आर्किटेक्ट आणि वेन्यू ऑपरेशन्स डायरेक्टरने योग्यरित्या हाताळणे आवश्यक आहे: तो म्हणजे अतिथी WiFi साठी GDPR चे पालन करणे. मी आधी पार्श्वभूमी स्पष्ट करतो. समजा तुम्ही एखादे हॉटेल, रिटेल चेन, स्टेडियम किंवा कॉन्फरन्स सेंटर चालवता आणि तिथे अतिथी WiFi सुविधा देता. ज्या क्षणी एखादा अभ्यागत कनेक्ट होतो, त्या क्षणी जनरल डेटा प्रोटेक्शन रेग्युलेशन अंतर्गत तुम्ही डेटा कंट्रोलर बनता. हे एक विशिष्ट कायदेशीर पदनाम आहे. यामध्ये काही वास्तविक जबाबदाऱ्या, वास्तविक दंड आणि काही चूक झाल्यास तुमच्या प्रतिष्ठेला प्रत्यक्ष धोका उद्भवू शकतो. याबाबत इन्फॉर्मेशन कमिशनर ऑफिस अत्यंत स्पष्ट आहे: जर मॅक ॲड्रेस, IP ॲड्रेस, सेशन टाइमस्टॅम्प आणि लोकेशन डेटा एखाद्या ओळखता येण्याजोग्या व्यक्तीशी जोडले जाऊ शकत असतील, तर तो सर्व पर्सनल डेटा मानला जातो. अतिथी WiFi वातावरणात, असे बहुतेक वेळा करणे शक्य असते. ज्या क्षणी अतिथी त्यांच्या ईमेल ॲड्रेस तुमच्या स्प्लॅश पेजवर टाईप करतो, त्या क्षणी तुम्ही त्या उपकरणाबद्दल गोळा करत असलेला प्रत्येक डेटा पॉईंट हा पर्सनल डेटा बनतो. चला तर मग आता तांत्रिक संरचनेबद्दल सविस्तर जाणून घेऊया. हीच खरी महत्त्वाची माहिती आहे. तुमचे Captive Portal - म्हणजेच अतिथी ऑनलाइन जाण्यापूर्वी त्यांना दिसणारे स्प्लॅश पेज - हा तुमचा प्राथमिक कंप्लायन्स इंटरफेस आहे. याच ठिकाणी बहुतांश वेन्यू गंभीर चुका करतात. सर्वात सामान्य चूक म्हणजे 'बंडलिंग' करणे. यामध्ये अनेकदा वेन्यू अतिथीला ऑनलाइन जाण्यासाठी मार्केटिंग ईमेल स्वीकारण्याची अट घालतात. GDPR कलम ७ अंतर्गत, संमती ही स्वेच्छेने दिलेली असावी लागते. जर तुम्ही नेटवर्क ऍक्सेसला मार्केटिंग संमतीशी बंडल केले, तर ती संमती स्वेच्छेने दिलेली मानली जात नाही. त्यामुळे ती अवैध ठरते. अगदी सरळ आहे. तुमच्या Captive Portal वर किमान दोन स्वतंत्र संमती घटक सादर करणे आवश्यक आहे. पहिला अनिवार्य आहे: नेटवर्क ऍक्सेससाठी तुमच्या सेवा अटींचा स्वीकार करणे. दुसरा पर्यायी आहे, जो बाय डिफॉल्ट अनटिक केलेला असावा: मार्केटिंग संदेश प्राप्त करण्यास संमती. अतिथीने मार्केटिंगला संमती न देताही तुमच्या WiFi शी कनेक्ट होणे शक्य असले पाहिजे. तसे नसल्यास, तुम्ही नियमांचे उल्लंघन करत आहात. GDPR परिच्छेद ३२ स्पष्टपणे प्री-टिक केलेल्या बॉक्सेसना प्रतिबंधित करतो. संमतीच्या संरचनेव्यतिरिक्त, युझरने कोणताही डेटा सबमिट करण्यापूर्वी तुमच्या पोर्टलवर एक स्पष्ट गोपनीयता नोटीस दाखवणे आवश्यक आहे. GDPR कलम १३ अंतर्गत, या नोटीसमध्ये तुम्ही कोणता डेटा गोळा करता, तो का गोळा करता, तो किती काळ ठेवता आणि तो कोणाशी शेअर करता, हे स्पष्ट केले पाहिजे. यामध्ये तुमच्या संपूर्ण गोपनीयता धोरणाची लिंक असावी लागतील. आणि सर्वात महत्त्वाचे म्हणजे, तुमच्या सिस्टीमने प्रत्येक संमती इव्हेंट लॉग केला पाहिजे: कोणी संमती दिली, ती कधी दिली, कशासाठी दिली आणि त्या क्षणी त्यांनी पाहिलेली गोपनीयता नोटीसची अचूक आवृत्ती कोणती होती. जर एखाद्या नियंत्रकाने चौकशी केली, तर हा संमती ऑडिट ट्रेल तुमच्या पालनाचा पुरावा असेल. आता, तुमचे अतिथी WiFi नेटवर्क प्रत्यक्ष गोळा करत असलेल्या डेटाच्या चार श्रेणींबद्दल बोलूया, कारण ही व्याप्ती बहुतेक टीम्सच्या कल्पनेपेक्षा मोठी आहे. पहिली श्रेणी: रजिस्ट्रेशन डेटा. नाव, ईमेल ॲड्रेस, फोन नंबर, सोशल लॉगिन क्रेडेन्शियल्स. हा तो डेटा आहे जो अतिथी तुमच्या Captive Portal वर स्वतःहून देतात. यासाठीचा कायदेशीर आधार संमती आहे, आणि ती संमती तपशीलवार असणे आवश्यक आहे.दुसरे: डिव्हाइस आणि सेशन डेटा. MAC पत्ते, IP पत्ते, कनेक्शन आणि डिस्कनेक्शनचे टाइमस्टॅम्प, सेशनचा कालावधी, ट्रान्सफर केलेला डेटा. एखादे डिव्हाइस तुमच्या नेटवर्कशी जोडले गेल्यावर हा डेटा स्वयंचलितपणे गोळा केला जातो. नेटवर्क सुरक्षा आणि ट्रबलशूटिंगसाठी मूलभूत सेशन लॉगिंग करणे न्याय्य हितांतर्गत (Legitimate Interest) येऊ शकते - परंतु हे केवळ तेव्हाच शक्य आहे जर तुम्ही Legitimate Interest Assessment केले असेल आणि तुमचे हित वापरकर्त्याच्या गोपनीयतेच्या अधिकारांवर गदा आणत नाही हे सिद्ध करू शकत असाल. तिसरे: लोकेशन डेटा. जर तुम्ही पाऊलखुणा ट्रॅक करण्यासाठी, ड्वेल टाइम मोजण्यासाठी किंवा हीटमॅप जनरेट करण्यासाठी WiFi ॲनालिटिक्स वापरत असाल, तर तुम्ही लोकेशन डेटावर प्रक्रिया करत आहात. जरी तो तुमच्या डॅशबोर्डमध्ये एकत्रित (aggregated) दाखवला जात असला, तरी वैयक्तिक डिव्हाइसवरून गोळा केलेला प्रारंभिक डेटा हा वैयक्तिक डेटाच असतो. यासाठी तुमच्या गोपनीयता सूचनेत (privacy notice) स्पष्ट प्रकटीकरण आणि अनेक प्रकरणांमध्ये स्पष्ट संमती आवश्यक असते. चौथे: वापर डेटा. ब्राउझिंग वर्तन, ॲप्लिकेशन वापरण्याचे पॅटर्न, बँडविड्थचा वापर. जर तुम्ही ट्रॅफिकमधील मजकुराची तपासणी किंवा लॉगिंग करत असाल, तर तुमच्याकडे अत्यंत स्पष्ट कायदेशीर आधार आणि त्या डेटाभोवती मजबूत सुरक्षा नियंत्रणे असणे आवश्यक आहे. नेटवर्क आर्किटेक्चरच्या दृष्टिकोनातून, सेगमेंटेशन करणे अपरिहार्य आहे. तुमचा गेस्ट WiFi ट्रॅफिक एका समर्पित VLAN - व्हर्च्युअल लोकल एरिया नेटवर्क - वर आयसोलेट केलेला असणे आवश्यक आहे, जो तुमच्या कॉर्पोरेट नेटवर्कपासून पूर्णपणे वेगळा असेल. गेस्ट डिव्हाइसेसना कोणत्याही अंतर्गत सबनेटमध्ये प्रवेश करण्यापासून रोखण्यासाठी ऍक्सेस कंट्रोल लिस्ट वापरा. क्लायंट आयसोलेशन सक्षम करा जेणेकरून गेस्ट डिव्हाइसेस एकमेकांशी संवाद साधू शकणार नाहीत. ही केवळ GDPR ची आवश्यकता नाही; तर ही मूलभूत सुरक्षा स्वच्छता आहे. ऑथेंटिकेशनसाठी, तुमच्या वायरलेस LAN कंट्रोलरला क्लाउड RADIUS सर्व्हरसह इंटिग्रेट करा. Remote Authentication Dial-In User Service - RADIUS - हा प्रोटोकॉल आहे जो एंटरप्राइझ नेटवर्कवर ऑथेंटिकेशन, ऑथरायझेशन आणि अकाउंटिंग हाताळतो. जेव्हा एखादा वापरकर्ता Captive Portal फ्लो पूर्ण करतो, तेव्हा प्लॅटफॉर्म कंट्रोलरला RADIUS Access-Accept संदेश पाठवतो आणि प्रवेश मंजूर करतो. यामुळे ऑथेंटिकेशन लेयर आणि डेटा कलेक्शन लेयरमध्ये एक स्पष्ट विभाजन तयार होते. एन्क्रिप्शनबाबत: तुमच्या गेस्ट SSID ने WPA3 चा वापर केला पाहिजे जिथे तुमचे हार्डवेअर त्याला सपोर्ट करते. WPA3 हे Simultaneous Authentication of Equals चा वापर करते, जे WPA2 च्या फोर-वे हँडशेक मधील त्रुटी दूर करते. किमान, AES एन्क्रिप्शनसह WPA2 लागू करा. आणि तुमचे Captive Portal वैध TLS प्रमाणपत्रासह HTTPS वर चालवले गेले पाहिजे. वैयक्तिक डेटा गोळा करणारा फॉर्म HTTP वर चालवणे ही एक गंभीर सुरक्षा चूक आहे. Purple चा प्लॅटफॉर्म Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet हार्डवेअरवर काम करतो. या हार्डवेअर-अज्ञेयवादी (hardware-agnostic) दृष्टिकोनाचा अर्थ असा आहे की तुमच्या छतावर कोणतेही ऍक्सेस पॉइंट्स असले तरीही तुम्ही सुसंगत अनुपालन नियंत्रणे लागू करू शकता. आता आपण डेटा रिटेंशनकडे वळूया, कारण इथेच संस्था काळानुरूप नकळतपणे जोखीम वाढवून ठेवतात. GDPR चा स्टोरेज मर्यादा सिद्धांत - कलम 5(1)(e) - आवश्यक करतो की वैयक्तिक डेटा ज्या हेतूसाठी गोळा केला गेला होता त्या हेतूसाठी आवश्यक असेल त्यापेक्षा जास्त काळ ठेवला जाऊ नये. एक बचावात्मक बेसलाइन याप्रमाणे दिसते. सत्र लॉग - IP पत्ते, MAC पत्ते, कनेक्शन टाइमस्टॅम्प - ३० दिवसांनंतर काढून टाकले पाहिजेत. नेटवर्क सुरक्षा लॉग १२ महिन्यांपर्यंत ठेवले जाऊ शकतात. संमती रेकॉर्ड सेवा संबंधांच्या कालावधीसाठी आणि सामान्यतः शेवटच्या संवादानंतर दोन वर्षांपर्यंत ठेवले पाहिजेत. मार्केटिंग प्रोफाइल केवळ तोपर्यंतच ठेवले पाहिजेत जोपर्यंत वापरकर्त्याची संमती वैध आहे. वापरकर्त्याने संमती मागे घेताच, त्यांचे मार्केटिंग प्रोफाइल हटवले जाणे आवश्यक आहे. संग्रहित (archived) नाही. हटवलेच पाहिजे. हे नियम मोठ्या प्रमाणावर लागू करणे हे मोठे आव्हान आहे. जर तुम्ही डझनभर किंवा शेकडो ठिकाणी पाहुण्यांचे WiFi व्यवस्थापित करत असाल, तर डेटा व्यक्तिशः मॅन्युअली हटवणे शक्य नाही. तुम्हाला अशा प्लॅटफॉर्मची आवश्यकता आहे जो डेटा धारणा अंमलबजावणी स्वयंचलित करतो. Purple प्रत्येक डेटा श्रेणीसाठी कॉन्फिगर करण्यायोग्य डेटा धारणा नियम लागू करते, ज्यामुळे रेकॉर्ड त्यांच्या डेटा धारणा कालावधीच्या शेवटी पोहोचल्यावर स्वयंचलितपणे काढून टाकले जातात. ८०,००० सक्रिय ठिकाणांवर आणि ३५० दशलक्ष अनन्य वापरकर्त्यांमध्ये, मोठ्या प्रमाणावर सुसंगत राहण्याचा हा ऑटोमेशन एकमेव मार्ग आहे. आता मी तुम्हाला अशा दोन वास्तविक परिस्थितींमधून घेऊन जातो जेथे ही तत्त्वे एकत्र येतात. पहिली परिस्थिती: २०० खोल्यांचे हॉटेल. हॉटेल टीमला लॉयल्टी प्रोग्रामच्या साइन-अपला चालना देण्यासाठी पाहुण्यांचे ईमेल गोळा करायचे आहेत. त्यांच्या सध्याच्या प्रणालीमध्ये पाहुण्यांना ऑनलाइन जाण्यासाठी मार्केटिंग स्वीकारणे आवश्यक आहे. हे स्पष्टपणे GDPR चे उल्लंघन आहे. यावरील उपाय सरळ आहे: स्वतंत्र संमती टिकबॉक्ससह एक सुसंगत Captive Portal तैनात करा. अनिवार्य टिकबॉक्समध्ये सेवा अटी समाविष्ट आहेत. पर्यायी, अनटिक केलेला टिकबॉक्स मार्केटिंग संमती कव्हर करतो. एकत्रित दृष्टिकोनाच्या तुलनेत हॉटेलला मार्केटिंग ऑप्ट-इनचे प्रमाण कदाचित कमी दिसेल - परंतु या यादीची गुणवत्ता आणि कायदेशीरपणा नाट्यमयीरित्या सुधारतो. जे पाहुणे सक्रियपणे ऑप्ट इन करतात ते त्यानंतरच्या संवादांमध्ये गुंतण्याची शक्यता लक्षणीयरीत्या जास्त असते. आणि मुख्य म्हणजे, हॉटेल आता ICO अंमलबजावणीच्या कारवाईच्या कचाट्यात सापडणार नाही. दुसरी परिस्थिती: स्टेडियमची IT टीम. त्यांना गर्दीची घनता मॉनिटर करण्यासाठी आणि कार्यक्रमांमध्ये सुरक्षा व्यवस्थापित करण्यासाठी WiFi विश्लेषणाचा वापर करायचा आहे. कायदेशीर टीमची चिंता अशी आहे की संमतीशिवाय डिव्हाइसच्या स्थानांचा मागोवा घेणे हे GDPR चे उल्लंघन आहे. यावर दुहेरी उपाय आहे. पहिला, गर्दी व्यवस्थापन आणि सुरक्षिततेच्या उद्देशाने स्थान डेटावर प्रक्रिया केली जाते हे स्पष्टपणे उघड करण्यासाठी Captive Portal गोपनीयता सूचना अद्ययावत करा. दुसरे, डेटा क्लाउड विश्लेषण प्लॅटफॉर्मवर पोहोचण्यापूर्वी एजवर - थेट ॲक्सेस पॉइंट्सवरच - MAC पत्त्यांचे छद्मनावकरण (pseudonymisation) लागू करा. याचा अर्थ असा की विश्लेषण प्रणाली कच्च्या MAC पत्त्यांऐवजी छद्मनावाच्या आयडेंटिफायर्ससह काम करते, ज्यामुळे गोपनीयतेचा धोका आणि नियामक धोके लक्षणीयरीत्या कमी होतात. आता आपण अंमलबजावणीतील त्रुटी आणि जोखीम कमी करण्याच्या उपायांबद्दल बोलूया - ज्या गोष्टींमुळे टीम्स सर्वकाही नीट कव्हर केले आहे असे समजत असतानाही अडचणीत येतात. पहिली त्रुटी: संमतीचा कंटाळा (consent fatigue). जर तुमचे पोर्टल खूप क्लिष्ट असेल, तर वापरकर्ते एकतर कनेक्शन सोडून देतील किंवा विचार न करता प्रत्येक गोष्टीवर क्लिक करतील. ते सोपे ठेवा. साधी भाषा वापरा. मूल्याची देवाणघेवाण स्पष्टपणे समजावून सांगा: ईमेल पत्त्याच्या बदल्यात आणि अधूनमधून तुमच्याकडून ऐकण्याच्या पर्यायाच्या बदल्यात जलद, विनामूल्य WiFi. दुसरी चूक: डेटा विषयाच्या अधिकारांचा आदर न करणे. GDPR च्या कलम १५ ते २२ अंतर्गत, वापरकर्त्यांना त्यांच्या डेटाचा अ‍ॅक्सेस मिळवणे, दुरुस्त करणे, हटवणे आणि पोर्ट करण्याचा अधिकार आहे. तुमच्याकडे यासाठी एक प्रक्रिया असणे आवश्यक आहे. एक सेल्फ - सर्व्हिस प्रेफरन्स सेंटर जेथे वापरकर्ते त्यांच्या संमतीचे व्यवस्थापन करू शकतात आणि Data Subject Access Requests - DSARs - सबमिट करू शकतात, हे सर्वात सर्वोत्तम मानले जाते. Purple चे प्लॅटफॉर्म हेच सुलभ करण्यासाठी साधने प्रदान करते, ज्यामुळे मॅन्युअल हस्तक्षेपाशिवाय DSARs ला प्रतिसाद देणे सोपे होते. तिसरी चूक: स्वाक्षरी नसलेले व्हेंडर करार. तुमचा गेस्ट WiFi प्लॅटफॉर्म प्रदाता हा एक डेटा प्रोसेसर आहे. त्यांच्याकडे कोणताही वैयक्तिक डेटा जाण्यापूर्वी, तुमच्याकडे स्वाक्षरी केलेले Data Processing Addendum असणे आवश्यक आहे. हे तुमच्या WiFi विश्लेषक प्रदाता, तुमचे CRM आणि तुमच्या ईमेल मार्केटिंग प्लॅटफॉर्मला लागू होते. DPA नाही, तर डेटा शेअरिंग नाही. चौथी चूक: कोणताही डेटा ब्रीच रिस्पॉन्स प्लॅन नसणे. GDPR च्या कलम ३३ अंतर्गत, तुम्हाला वैयक्तिक डेटा ब्रीचची जाणीव होताच ७२ तासांचा नोटिफिकेशन क्लॉक सुरू होतो. तुमचा तपास पूर्ण झाला नसला तरीही, तुम्ही ७२ तासांच्या आत ICO ला सूचित केले पाहिजे. तुम्हाला गरज पडण्यापूर्वीच, हा टाइमलाइन आता तुमच्या इन्सिडेंट रिस्पॉन्स प्लॅनमध्ये समाविष्ट करा. चला - आता काही झटपट प्रश्न पाहूयात. हे ते प्रश्न आहेत जे आम्हाला वारंवार विचारले जातात. आम्ही केवळ अ‍ॅनालिटिक्ससाठी MAC अ‍ॅड्रेस गोळा करत असल्यास आम्हाला संमतीची आवश्यकता आहे का? होय. जर ते अ‍ॅनालिटिक्स एखाद्या डिव्हाइसशी आणि त्याच्या वापरकर्त्याच्या वर्तनाशी जोडले जाऊ शकत असतील, तर तो वैयक्तिक डेटा आहे. तुम्हाला एकतर स्पष्ट संमती आवश्यक आहे किंवा गोळा केल्यावर लगेचच होणारी एक मजबूत अनामितीकरण (anonymisation) प्रक्रिया आवश्यक आहे. सोशल मीडिया लॉगिन GDPR सुसंगत आहे का? ते असू शकते, परंतु तुम्हाला सोशल प्लॅटफॉर्मवरून कोणता डेटा मिळतो याबद्दल पारदर्शक असणे आवश्यक आहे, आणि बेसिक ऑथेंटिकेशन पलीकडे त्या डेटाच्या कोणत्याही वापरासाठी तुम्हाला स्वतंत्र संमती मिळवणे आवश्यक आहे. आम्ही एक लहान ठिकाण असल्यास GDPR लागू होतो का? होय. संस्थेचा आकार कोणताही असला तरी GDPR लागू होतो. ICO कडे केलेली एक तक्रार देखील तपासाला कारणीभूत ठरू शकते. दंडाची रक्कम तुमच्या आकाराच्या प्रमाणात असू शकते, परंतु नियमांचे पालन करण्याचे बंधन पूर्ण आहे. आम्हाला Data Protection Impact Assessment ची गरज आहे का? जर तुमच्या गेस्ट WiFi उपयोजनामध्ये मोठ्या प्रमाणावर लोकेशन ट्रॅकिंग, वर्तणुकीचे प्रोफाइलिंग किंवा संवेदनशील गटांमधील डेटा प्रक्रियेचा समावेश असेल, तर GDPR कलम ३५ अंतर्गत DPIA कायदेशीररित्या अनिवार्य आहे. हे अनिवार्य नसले तरीही, ही एक चांगली पद्धत आहे आणि रेग्युलेटरकडे उत्तरदायित्व दर्शवते. मी तुमच्या पुढील चरणांसह सांगता करतो. तुम्ही या आठवड्यात करू शकता अशा चार कृती. पहिली: तुमच्या सध्याच्या Captive Portal चे ऑडिट करा. मार्केटिंग संमती नेटवर्क अ‍ॅक्सेस अटींसह एकत्रित केली आहे की नाही हे तपासा. तसे असल्यास, तुमच्या पुढील ICO ऑडिटपूर्वी ते दुरुस्त करा. दुसरी: तुमच्या डेटा रिटेंशन सेटिंग्जचे पुनरावलोकन करा. तुमच्याकडे ऑटोमेटेड डिलीशन पॉलिसी नसल्यास, तुम्ही प्रत्येक जाणाऱ्या दिवसासोबत धोका वाढवत आहात. तिसरी: तुमचे व्हेंडर करार तपासा. तुमच्या वतीने गेस्ट डेटावर प्रक्रिया करणाऱ्या प्रत्येक थर्ड - पार्टी प्लॅटफॉर्मसोबत तुमच्याकडे स्वाक्षरी केलेले Data Processing Addendum असल्याची खात्री करा. चार: एक पसंती केंद्र (preference centre) लागू करा. तुमच्या पाहुण्यांना त्यांची संमती व्यवस्थापित करण्यासाठी आणि डेटा संबंधित प्रवेश विनंत्या (DSARs) सबमिट करण्यासाठी एक स्वयं-सेवा मार्ग द्या. यामुळे मॅन्युअली DSARs हाताळण्याचा ऑपरेशनल बोजा नाटकीयरित्या कमी होतो. Purple कडे ISO 27001 प्रमाणपत्र आहे, ते GDPR आणि CCPA चे पालन करते, आणि जागतिक स्तरावर 80,000 ठिकाणांवर कार्यरत आहे. आम्ही केवळ 2024 मध्येच 440 दशलक्ष लॉगिन प्रक्रियेत आणले आहेत आणि 29 अब्ज डेटा पॉइंट्स गोळा केले आहेत - हे सर्व ठिकाणे आणि त्यांचे अभ्यागत दोघांचेही संरक्षण करण्यासाठी डिझाइन केलेल्या अनुपालन आर्किटेक्चर अंतर्गत केले गेले आहे. आमचे प्लॅटफॉर्म संमती लॉगिंग, डेटा धारणा अंमलबजावणी आणि DSAR व्यवस्थापन स्वयंचलित करते, जेणेकरून तुम्ही अनुपालन स्प्रेडशीट्स व्यवस्थापित करण्याऐवजी तुमचे नेटवर्क चालवण्यावर लक्ष केंद्रित करू शकता. या Purple Technical Briefing मध्ये सामील झाल्याबद्दल धन्यवाद. अतिथी WiFi अनुपालनावरील अधिक संसाधनांसाठी, purple.ai ला भेट द्या. अनुपालक रहा, आणि सुरक्षित रहा.