BYOD ऑनबोर्डिंग: स्टाफ और गेस्ट एक्सेस कैसे सेट अप करें
Published
एक नया कर्मचारी व्यक्तिगत फोन के साथ आता है, एक ठेकेदार पुराने लैपटॉप के साथ आता है, और एक मेहमान को मीटिंग शुरू होने से पहले WiFi की आवश्यकता होती है। यदि तीनों को एक ही साझा पासवर्ड मिलता है, तो एक्सेस देना आसान होता है लेकिन बाद में इसे नियंत्रित करना कठिन होता है। BYOD ऑनबोर्डिंग तब बेहतर काम करती है जब आप प्रत्येक प्रकार के डिवाइस के लिए एक मार्ग चुनते हैं, और फिर योजना बनाते हैं कि तब क्या होगा जब कोई इसे एनरोल नहीं कर पाता है या नहीं करना चाहता है।
मुख्य बात यह है कि ऑनबोर्डिंग को एक जीवनचक्र (lifecycle) के रूप में देखा जाए। एक साइन-इन पृष्ठ यह रिकॉर्ड कर सकता है कि कौन जुड़ा था, लेकिन यह स्थापित नहीं करता है कि कोई उपकरण सुरक्षित है, यह तय नहीं करता है कि यह कहां तक पहुंच सकता है, या यह सुनिश्चित नहीं करता है कि इसकी पहुंच को रद्द किया जा सकता है।
विषय सूची
- BYOD ऑनबोर्डिंग विधि चुनना
- कैप्टिव पोर्टल और SSO साइन-इन सेटअप करें
- अपने MDM के माध्यम से EAP-TLS प्रमाण पत्र जारी करें
- साझा डिवाइसों के लिए MDMless ऑनबोर्डिंग और प्रति-डिवाइस कुंजियां
- असमर्थित और आंशिक रूप से प्रबंधित डिवाइसों के लिए फ़ॉलबैक मार्ग
- सहमति, गोपनीयता और ऑफबोर्डिंग नियम
- मार्ग क्रम की पुष्टि करें और पहले इसका पायलट परीक्षण करें
BYOD ऑनबोर्डिंग विधि चुनना
| विधि | आवश्यक डिवाइस प्रबंधन | जारी किया गया क्रेडेंशियल | इसके लिए सर्वोत्तम | मुख्य सीमा |
|---|---|---|---|---|
| SSO, Google, Apple, Facebook या SMS के साथ कैप्टिव पोर्टल | कोई नहीं | दर्ज सहमति के साथ ब्राउज़र सत्र | अतिथि और कभी-कभार आने वाले आगंतुक | पोर्टल साइन-इन डिवाइस की स्थिति साबित नहीं करता है |
| SCEP पर MDM द्वारा जारी किया गया EAP-TLS सर्टिफिकेट | Intune या Jamf Pro जैसा एनरोल किया गया MDM | प्रति-डिवाइस सर्टिफिकेट | प्रबंधित कर्मचारियों के फ़ोन और लैपटॉप | गैर-एनरोल व्यक्तिगत डिवाइस शामिल नहीं हो सकते |
| बिना MDM वाला ऐप-इन्स्टॉल WiFi पास | इंस्टॉलर ऐप, कोई MDM नहीं | प्रति-उपयोगकर्ता या प्रति-डिवाइस पास | सफाईकर्मी, एजेंसी कर्मचारी, व्यक्तिगत फ़ोन | डिवाइस की स्थिति पर कमजोर दृश्यता |
| प्रति-डिवाइस xPSK कुंजी | डिवाइस पर कोई नहीं | प्रति-डिवाइस अद्वितीय प्री-शेयर की गई कुंजी | साझा टिल, IoT, निवासी | कुंजी प्रबंधन और निरसन प्रक्रिया की आवश्यकता होती है |
| Passpoint या OpenRoaming प्रोफ़ाइल | डिवाइस पर इंस्टॉल की गई प्रोफ़ाइल | सर्टिफिकेट-आधारित पहचान | विभिन्न स्थानों पर लौटने वाले अतिथि | केवल वही डिवाइस जो Passpoint का समर्थन करते हैं |
ये मार्ग विश्वास के विभिन्न स्तरों और उपयोगकर्ताओं की अलग-अलग अपेक्षाओं के अनुकूल हैं। एक ब्राउज़र पोर्टल गेस्ट एक्सेस को सरल बनाए रखता है, लेकिन यह फोन की सुरक्षा स्थिति की जाँच नहीं कर सकता है। एक सर्टिफिकेट कनेक्शन के समय मैनेज्ड डिवाइस को अधिक मजबूत पहचान प्रदान करता है, लेकिन इसके लिए एनरोलमेंट की आवश्यकता होती है। जो डिवाइसेस MDM प्रोफाइल स्वीकार नहीं कर सकते, उनके लिए एक पास या यूनिक की पूरे साइट पर साझा किए गए पासवर्ड का एक विकल्प प्रदान करती है।
BYOD एक एक्सेस-नियंत्रण आवश्यकता बन गया क्योंकि व्यक्तिगत डिवाइस दैनिक कार्य में शामिल हो गए। 600 U.S. IT और व्यावसायिक नेताओं के 2012 Cisco IBSG सर्वेक्षण में, 95% ने कहा कि उनके संगठनों ने किसी न किसी रूप में कर्मचारियों के स्वामित्व वाले डिवाइसों की अनुमति दी है, और 84% ने व्यक्तिगत डिवाइसों की अनुमति दी और कम से कम कुछ सहायता प्रदान की (Cisco का 2012 BYOD अध्ययन)। वह अंतर मायने रखता है: WiFi पर किसी डिवाइस को अनुमति देना उसे सहायता देने, उसे उचित एक्सेस असाइन करने या उसके क्रेडेंशियल हटाने की तैयारी करने के समान नहीं है।
अपवाद से पहले डिफ़ॉल्ट चुनें
प्रत्येक डिवाइस श्रेणी के लिए एक डिफ़ॉल्ट मार्ग असाइन करके शुरुआत करें। प्रबंधित कर्मचारी डिवाइसों को प्रमाणपत्रों का उपयोग करना चाहिए; अतिथियों को एक पोर्टल का उपयोग करना चाहिए; बिना MDM वाले डिवाइसों को एक ऐप-इंस्टॉल्ड पास या अद्वितीय कुंजी मिलनी चाहिए, न कि साझा पासवर्ड। लौटने वाले अतिथियों के लिए Passpoint या OpenRoaming उपयुक्त हो सकता है यदि उनके डिवाइस प्रोफ़ाइल का समर्थन करते हैं।
फिर जांचें कि क्या आपके द्वारा चुने गए डिफ़ॉल्ट के लिए किसी ऐसी चीज़ की आवश्यकता है जो उपयोगकर्ता प्रदान नहीं करेगा, जैसे कि व्यक्तिगत फोन को प्रबंधित करने की अनुमति। सभी के लिए डिफ़ॉल्ट को कमजोर करने के बजाय, केवल उन अपवादों को फ़ॉलबैक मार्गों पर भेजें। एक WiFi पहुंच नियंत्रण अवलोकन टीमों को पहुंच नीति से प्रमाणीकरण मैप करने में मदद कर सकता है, लेकिन आपके उपकरण वर्गों और नेटवर्क अनुमतियों को अंतिम विकल्प संचालित करना चाहिए।
कैप्टिव पोर्टल और SSO साइन-इन सेट करें
मेहमानों के लिए एक कैप्टिव पोर्टल व्यावहारिक डिफॉल्ट है क्योंकि वे मैनेजमेंट प्रोफाइल इंस्टॉल किए बिना साइन इन कर सकते हैं। यह तब भी उपयोगी होता है जब आपको सहमति रिकॉर्ड करने की आवश्यकता होती है या आगंतुकों को उनके पास पहले से मौजूद खाते का उपयोग करके ऑथेंटिकेट करने की अनुमति देनी होती है। महत्वपूर्ण डिज़ाइन निर्णय यह है कि पोर्टल साइन-इन के बाद प्रत्येक उपयोगकर्ता को कहाँ भेजता है: ऑथेंटिकेशन को सही नेटवर्क तक ले जाना चाहिए, न कि डिफॉल्ट रूप से व्यापक एक्सेस प्रदान करना चाहिए।
साइन-इन फ़्लो बनाएं और उसका परीक्षण करें
नेटवर्क को मैप करें और एक पायलट साइट चुनें। एक डिज़ाइन सेशन में, एक्सेस पॉइंट्स, SSIDs, डायरेक्टरी ग्रुप्स और डिवाइस क्लासेज को ओपन, सिक्योर और xPSK नेटवर्क पर मैप करें। एक नेटवर्क इंजीनियर को टीम को एक योजना और पायलट साइट सौंपनी चाहिए, ताकि कॉन्फ़िगरेशन एक आदर्शात्मक आरेख के बजाय वास्तविक भौतिक संपत्ति को दर्शाए।
एक आइडेंटिटी एप्लिकेशन रजिस्टर करें। Entra ID, Google Workspace, या Okta में एक एप्लिकेशन सेटअप करें और साइन-इन के लिए आवश्यक डायरेक्टरी एक्सेस प्रदान करें। पहले पायलट रजिस्ट्रेशन का उपयोग करें, ताकि आप परिनियोजन का विस्तार करने से पहले अनुमतियों और लॉगिन अनुभव की जांच कर सकें।
कंट्रोलर में पोर्टल और RADIUS विवरण जोड़ें। RADIUS सर्वर और स्पलैश URL कॉन्फ़िगर करें। एक बार ऐप रजिस्ट्रेशन हो जाने के बाद, इन कंट्रोलर बदलावों सहित ग्राहक पक्ष को सेटअप करने में 15 मिनट से कम समय लगता है।
प्रत्येक दर्शक वर्ग के लिए साइन-इन विधियां चुनें। संगठन की पहचान की आवश्यकता वाले कर्मचारियों के लिए SSO का, व्यक्तिगत खातों के लिए Google या Apple का और जहां आगंतुक अपेक्षा करते हैं वहां Facebook का उपयोग करें। SMS वन-टाइम पासकोड ऐसे आगंतुकों को दूसरा विकल्प प्रदान करते हैं जिनके पास उपयुक्त खाता नहीं है।
पोर्टल को ब्रांड करें और सहमति को स्पष्ट बनाएं। सहमति पाठ को सरल भाषा में लिखें और प्रत्येक साइन-इन के लिए एक प्रविष्टि रिकॉर्ड करें। नोटिस को वहां रखें जहां उपयोगकर्ता स्वीकार करने से पहले इसे पढ़ सके, उस बटन के नीचे नहीं जिसे उन्हें दबाना है।
गेस्ट नेटवर्क पर वास्तविक डिवाइसों का परीक्षण करें। एक व्यक्तिगत iPhone, एक Android फोन और एक Windows लैपटॉप कनेक्ट करें। पुष्टि करें कि प्रत्येक उपयोगकर्ता गेस्ट VLAN पर पहुंचता है और क्लाइंट आइसोलेशन गेस्ट डिवाइसों को एक-दूसरे तक पहुंचने से रोकता है।
पायलट के दौरान होने वाली सामान्य गलतियाँ हैं - स्प्लैश URL का गलत कंट्रोलर की ओर पॉइंट होना, साइन-इन बटन के नीचे सहमति टेक्स्ट का छिपा होना, और केवल कॉर्पोरेट डिवाइसेस के साथ परीक्षण करना। इनमें से प्रत्येक गलती संकीर्ण परीक्षण में पोर्टल को सफल दिखा सकती है, जबकि यह उन लोगों के लिए विफल हो सकती है जिन्हें इसकी आवश्यकता है। Okta का उपयोग करने वाली टीमें पहचान कनेक्शन की योजना बनाते समय Okta WiFi ऑथेंटिकेशन से जुड़ी इस गाइड की समीक्षा भी कर सकती हैं।
अपने MDM के माध्यम से EAP-TLS प्रमाणपत्र जारी करें
प्रबंधित कर्मचारी उपकरणों के लिए, एक प्रमाण पत्र-आधारित जुड़ाव साझा WiFi पासवर्ड पर निर्भर रहने के बजाय नेटवर्क पहुंच को एक नामांकित उपकरण से जोड़ता है। उपकरण कनेक्शन के दौरान अपनी पहचान साबित करता है, और उपयोगकर्ता की पहचान यह निर्धारित कर सकती है कि कौन सी नेटवर्क अनुमतियां लागू होती हैं। NIST एक प्रोविज़न किए गए प्रमाण पत्र को कनेक्शन बिंदु पर एक मोबाइल उपकरण की पहचान और प्रमाणीकरण के तरीके के रूप में वर्णित करता है, और ध्यान देता है कि इसे उपयोगकर्ता क्रेडेंशियल्स के साथ संयोजित करने से दो-कारक प्रमाणीकरण प्रदान किया जा सकता है (NIST का मोबाइल उपकरण सुरक्षा मार्गदर्शन)।
स्केल शायद ही कभी यहाँ समस्या होती है। SCEP पर प्रमाणपत्र वितरित करने में पूरे संगठन के लिए एक बार में पांच से दस मिनट लगते हैं, इसलिए कटओवर की रात प्रबंधित लैपटॉप और फोन MDM से अपना प्रमाणपत्र प्राप्त करते हैं और स्वचालित रूप से जुड़ जाते हैं। कठिन काम यह तय करना है कि उस प्रमाणपत्र पर भरोसा करने से पहले किसी डिवाइस को किन जांचों को पास करना होगा।
डिवाइस ट्रस्ट को जोड़ने (join) की प्रक्रिया का हिस्सा बनाएं
उपयोगकर्ता को प्रमाणित करें। SSO या किसी अन्य स्वीकृत कारक के साथ शुरुआत करें, ताकि नेटवर्क किसी डिवाइस को किसी ज्ञात व्यक्ति या खाते से जोड़ सके।
एनरोलमेंट और स्थिति की जांच करें। पुष्टि करें कि डिवाइस एनरोल है और संगठन की न्यूनतम OS और सुरक्षा आवश्यकताओं को पूरा करता है। व्यक्तिगत स्वामित्व वाले डिवाइस को तब तक संभावित रूप से अविश्वसनीय मानें जब तक वह उन जांचों को पास न कर ले।
डिवाइस-बाउंड प्रमाण पत्र जारी करें। SCEP पर प्रमाण पत्र प्रदान करने के लिए MDM का उपयोग करें। एक डिवाइस-बाउंड क्रेडेंशियल साझा रहस्य की तुलना में अधिक प्रबंधनीय होता है क्योंकि इसे एक एनरोल किए गए एंडपॉइंट से बांधा जा सकता है और किसी अन्य चीज़ को प्रभावित किए बिना निरस्त किया जा सकता है।
EAP-TLS का उपयोग करके कनेक्ट करें। प्रासंगिक प्रमाण पत्रों को मान्य करने के लिए क्लाइंट और नेटवर्क को कॉन्फ़िगर करें। इसके बाद उपयोगकर्ता क्रेडेंशियल और डिवाइस प्रमाण पत्र कनेक्शन के समय अलग-अलग पहचान जांच प्रदान करते हैं।
समूह द्वारा एक्सेस असाइन करें। निर्देशिका समूहों को न्यूनतम-विशेषाधिकार VLAN से मैप करें, ताकि किसी कर्मचारी की भूमिका यह निर्धारित करे कि सत्र कहां तक पहुंच सकता है। एक सफल प्रमाणीकरण का मतलब स्वचालित रूप से हर आंतरिक सेवा तक पहुंच नहीं होना चाहिए।
अनुपालन की निरंतर पुनः जांच करें। नीति मूल्यांकन को प्रारंभिक एनरोलमेंट तक सीमित न रखें। डिवाइस की स्थिति का पुनर्मूल्यांकन करें और जब कोई डिवाइस अब आवश्यकताओं को पूरा नहीं करता है, या जब उसके पीछे का खाता अक्षम हो जाता है, तो एक्सेस हटा दें।
सामान्य हेल्प-डेस्क कारणों में असमर्थित OS संस्करण, समाप्त हो चुके प्रमाणपत्र, गलत सिस्टम समय, गायब ट्रस्ट-चेन प्रमाणपत्र, निजी MAC-एड्रेस रैंडमाइजेशन, और उपयोगकर्ताओं द्वारा प्रबंधन अनुमतियों को अस्वीकार करना शामिल है। डिवाइस मॉडल और OS संस्करण द्वारा विफलताएं ट्रैक करें, क्योंकि एक स्वस्थ समग्र नामांकन दर किसी एक प्लेटफ़ॉर्म पर बार-बार होने वाले व्यवधान को छिपा सकती है।
- असमर्थित OS: एक स्वीकृत अपग्रेड पाथ की पेशकश करें या डिवाइस को प्रतिबंधित एक्सेस पर पुनर्निर्देशित करें।
- समाप्त हो चुका प्रमाणपत्र: क्रेडेंशियल समाप्त होने पर आउटेज से बचने के लिए नवीनीकरण को पर्याप्त समय रहते स्वचालित करें।
- गलत समय या अनुपस्थित ट्रस्ट चेन: नेटवर्क नीति बदलने से पहले डिवाइस की घड़ी और प्रमाणपत्र इंस्टॉलेशन की जांच करें।
- प्राइवेट MAC रैंडमाइजेशन: पुष्टि करें कि क्या नेटवर्क की नीति एक स्थिर डिवाइस पते पर निर्भर करती है और प्लेटफॉर्म-विशिष्ट सेटअप निर्देश प्रदान करें।
- अस्वीकृत प्रबंधन अनुमतियां: स्पष्ट करें कि प्रबंधन क्या देख सकता है और व्यापक एक्सेस देने के बजाय एक फ़ॉलबैक मार्ग की पेशकश करें।
अनुपालन बेसलाइन स्वयं सरल रहती है। डिवाइसों को तुरंत और नियमित शेड्यूल पर सुरक्षा अपडेट प्राप्त होने चाहिए, स्क्रीन लॉकिंग का उपयोग करना चाहिए, केवल अधिकृत स्रोतों से ऐप इंस्टॉल करने चाहिए, और यदि वे रूट या जेलब्रोकन हैं तो उन्हें जुड़ने से रोका जाना चाहिए। जो डिवाइस उन पॉस्चर जांच में विफल रहता है, वह एक अलग, कम-विशिष्टता वाले नेटवर्क का हिस्सा है, न कि कॉर्पोरेट नेटवर्क का।
जब आप संदर्भ में प्रमाणपत्र प्रवाह को देख सकते हैं तो अनुक्रम को समझना आसान हो जाता है। नीचे दिया गया वीडियो ऑनबोर्डिंग चरणों के लिए एक दृश्य मार्गदर्शिका प्रदान करता है।
साझा डिवाइसों के लिए बिना MDM के ऑनबोर्डिंग और प्रति-डिवाइस कुंजियां
कुछ उपकरण MDM नामांकन पूरा नहीं कर सकते हैं। इसमें एक व्यक्तिगत फोन शामिल है जिसका स्वामी प्रबंधन की अनुमति नहीं देगा, एक साझा टिल या कियोस्क, और एक IoT सेंसर जिसमें कोई उपयुक्त नामांकन इंटरफ़ेस नहीं है। उत्तर उन सभी को कर्मचारी नेटवर्क पर डालना नहीं है। एक प्रतिबंधित मार्ग का उपयोग करें जो प्रत्येक उपकरण को एक पहचानने योग्य क्रेडेंशियल और एक स्पष्ट मालिक प्रदान करता है।
निर्धारित स्वामी वाले पास या की (key) का उपयोग करें
पुष्टि करें कि डिवाइस अनmanaged है या असमर्थित है। जांचें कि यह सर्टिफिकेट मार्ग का उपयोग नहीं कर सकता है, और इसका मालिक किसी भी इंस्टॉल ऐप के लिए सहमत है। यह केवल एनरोलमेंट में असुविधा होने के कारण किसी अपवाद को डिफ़ॉल्ट बनने से रोकता है।
व्यक्तिगत फ़ोन को ऐप-इन्स्टॉल किया गया WiFi पास दें। उपयोगकर्ता पूरा फ़ोन MDM में एनरोल किए बिना साइन इन करता है और पास इंस्टॉल करता है। एक प्रबंधित रोलआउट के लिए, व्यक्तिगत फ़ोन कटओवर की रात में Purple ऐप से दो टैप में WiFi पास इंस्टॉल कर सकते हैं।
प्रत्येक शेयर किए गए टर्मिनल को उसकी अपनी xPSK कुंजी दें। टिल या कियोस्क को उसकी अपनी VLAN पर रखें, जिसमें उसके कार्य के अनुकूल बैंडविड्थ सीमा हो। एक विशिष्ट कुंजी एक पासवर्ड को सभी टिल पर फैलने से रोकती है।
कुंजी की जीवनअवधि को उसके उपयोग से मिलाएं। इसे बुकिंग, अनुबंध, या शिफ्ट पैटर्न के अनुकूल सेट करें। एक अस्थायी क्रेडेंशियल व्यक्ति या डिवाइस को पहुंच की आवश्यकता समाप्त होने के बाद उपयोगी नहीं रहना चाहिए।
रिकॉर्ड रखें कि प्रत्येक कुंजी किसके पास है। क्रेडेंशियल के साथ एक डिवाइस या उपयोगकर्ता मालिक को संबद्ध रखें, ताकि सपोर्ट स्टाफ पहचान सके कि डिवाइस खो जाने या कर्मचारी के जाने पर किस एक्सेस को निरस्त करना है।
कुंजी निरस्त करें और परिणाम का परीक्षण करें। प्रस्थान पर एक्सेस हटाएं और पुष्टि करें कि डिवाइस नेटवर्क से हट जाता है। निरसन ऑनबोर्डिंग डिज़ाइन का हिस्सा है, न कि किसी समस्या के बाद सोचा जाने वाला कार्य।
ये मार्ग प्रमाणपत्र की तुलना में डिवाइस पॉस्चर में कम दृश्यता प्रदान करते हैं, इसलिए उन्हें कर्मचारियों के VLAN के बजाय प्रतिबंधित नेटवर्क पर रखें। परिचालन संबंधी ट्रेड-ऑफ सीधा है: प्रति-डिवाइस कुंजी जारी करने और ट्रैक करने में अधिक देखभाल की आवश्यकता होती है, लेकिन यह समझौता किए गए क्रेडेंशियल की पहुंच को सीमित करता है।
असमर्थित और आंशिक रूप से प्रबंधित डिवाइसों के लिए फ़ॉलबैक मार्ग
सपोर्ट इतना सुसंगत नहीं है कि "एनरोल करें या एक्सेस खोएं" को हर कर्मचारी के लिए एक व्यावहारिक नीति बनाया जा सके। एक Verizon 2025 मोबाइल सुरक्षा रिपोर्ट में पाया गया कि सर्वेक्षण में शामिल 15% संगठनों ने सभी मोबाइल-डिवाइस प्रकारों के लिए पूर्ण सहायता प्रदान की, जबकि 32% ने तदर्थ (ad hoc) सहायता की पेशकश की, 27% ने केवल निर्दिष्ट मॉडल का समर्थन किया, और 23% ने कोई सहायता प्रदान नहीं की। यह अंतर पुराने डिवाइसों का उपयोग करने वाले लोगों, ठेकेदारों, फ्रंटलाइन स्टाफ और उन कर्मचारियों को प्रभावित करता है जो व्यक्तिगत फोन की व्यापक निगरानी के लिए सहमति नहीं देते हैं।
| डिवाइस केस | ऑनबोर्डिंग रूट | नेटवर्क एक्सेस | प्रदान करने से पहले जांचें |
|---|---|---|---|
| पूरी तरह से प्रबंधित, समर्थित OS | EAP-TLS पर MDM सर्टिफिकेट | डायरेक्टरी ग्रुप द्वारा सुरक्षित नेटवर्क | अनुपालन स्थिति और सर्टिफिकेट समाप्ति |
| व्यक्तिगत फोन, कोई प्रबंधन अनुमति नहीं | कैप्टिव पोर्टल या ऐप WiFi पास | क्लाइंट आइसोलेशन के साथ गेस्ट VLAN | सहमति दर्ज की गई, कोई कॉर्पोरेट VLAN नहीं |
| असमर्थित OS संस्करण | नामित ऐप्स तक केवल ब्राउज़र एक्सेस | अलग किया गया कम-विशेषवाधिकार नेटवर्क | अपग्रेड तिथि और स्वीकृत ऐप सूची |
| साझा टिल या कियोस्क | प्रति-डिवाइस xPSK कुंजी | बैंडविड्थ सीमा के साथ स्वयं का VLAN | कुंजी मालिक और रद्दीकरण पथ |
| ठेकेदार या अस्थायी कर्मचारी | समय-सीमित गेस्ट साइन-इन या लोन डिवाइस | गेस्ट VLAN, अनुबंध समाप्त होने पर समाप्त हो रहा है | अनुबंध की समाप्ति तिथि और नामित प्रायोजक |
| अभिगम्यता या पुराने-डिवाइस अपील | लोन डिवाइस के साथ मैनुअल समीक्षा | स्वीकृत ऐप्स तक सीमित | समीक्षा तिथि और नामित मालिक |
अपवाद को सीमित और दस्तावेज़बद्ध रखें
प्रत्येक डिवाइस को काम पूरा करने के लिए न्यूनतम एक्सेस दें। एक व्यक्तिगत फोन जिसे किसी नाम निर्दिष्ट सेवा के लिए केवल ब्राउज़र एक्सेस की आवश्यकता है, उसे आंतरिक अनुप्रयोगों या कॉर्पोरेट VLAN के मार्ग की आवश्यकता नहीं है। एक साझा टिल (till) को उसकी असाइन की गई सेवाओं की आवश्यकता होती है, और उसके क्रेडेंशियल के लिए एक नामित मालिक और रद्दीकरण पथ की आवश्यकता होती है।
एक डिवाइस-कंपैटिबिलिटी मैट्रिक्स प्रकाशित करें ताकि कर्मचारी किसी साइट पर पहुंचने से पहले यह जांच सकें कि उनका OS और डिवाइस एनरोल हो सकता है या नहीं। असमर्थित ऑपरेटिंग सिस्टम और एप्लिकेशन्स की एक इन्वेंट्री रखें, और रिकॉर्ड करें कि प्रत्येक पर कौन सा फॉलबैक मार्ग लागू होता है। ठेकेदारों और आगंतुकों के लिए, समय-सीमित नेटवर्क मार्ग समाप्ति और स्पॉन्सरशिप को स्पष्ट करने में मदद करता है।
एक कठोर नियम सुरक्षा को अधिक खराब कर सकता है यदि वह कर्मचारियों को व्यक्तिगत हॉटस्पॉट, साझा पासवर्ड या अन्य अप्रबंधित कार्यविधियों की ओर ले जाता है। बिना किसी विकल्प के पहुंच से वंचित करने की तुलना में एक प्रतिबंधित, दस्तावेज़बद्ध रूट अक्सर अधिक सुरक्षित होता है।
सहमति, गोपनीयता और ऑफबोर्डिंग नियम
“क्या मैं BYOD को मना कर सकता हूँ, और मेरा नियोक्ता ठीक क्या देख या मिटा सकेगा?” कर्मचारी को प्रोफ़ाइल स्वीकार करने या ऐप इंस्टॉल करने के लिए कहे जाने से पहले ऑनबोर्डिंग नोटिस में उत्तर दें। तकनीकी प्रमाणीकरण यह नहीं दर्शाता है कि किसी ने शर्तों को समझा या चुनने के लिए स्वतंत्र महसूस किया।
देखभाल-क्षेत्र के एक सर्वेक्षण में, 50% प्रदाताओं ने BYOD का उपयोग किया, लेकिन उनमें से केवल आधे के पास BYOD नीति थी; व्यक्तिगत उपकरणों का उपयोग करने वाले केवल 40% कर्मचारियों को किसी भी नीति या मार्गदर्शन पर हस्ताक्षर करना याद था। 2025 के एक अलग सर्वेक्षण में पाया गया कि 70% कर्मचारी संगठन द्वारा प्रदान किए गए उपकरणों को प्राथमिकता देते हैं (2025 एडल्ट सोशल केयर BYOD रिपोर्ट)। वे निष्कर्ष इस धारणा को चुनौती देते हैं कि व्यक्तिगत-उपकरण पहुंच स्वचालित रूप से सस्ती है या श्रमिकों के लिए अधिक सुविधाजनक है।
नोटिस में सरल भाषा में लिखा होना चाहिए:
- क्या सुरक्षा टेलीमेट्री एकत्र की जाती है, और कौन सी व्यक्तिगत सामग्री संगठन नहीं देख सकता है।
- क्या हटाया जा सकता है, जिसमें यह पुष्टि भी शामिल है कि कार्य प्रोफ़ाइल को हटाने से व्यक्तिगत सामग्री नहीं मिटेगी।
- कार्य से संबंधित मोबाइल डेटा और उपकरण के घिसाव का भुगतान कौन करता है, संबंधित देश के लिए प्रतिपूर्ति नियमों के साथ।
- विकल्प क्या है यदि कर्मचारी व्यक्तिगत-उपकरण प्रबंधन को अस्वीकार करता है।
यदि भागीदारी प्रभावी रूप से अनिवार्य है तो एक चेकबॉक्स अर्थपूर्ण सहमति नहीं है। एक लोन उपकरण या कोई अन्य पहुंच मार्ग प्रदान करें, और यदि निगरानी या डेटा उपयोग बदलता है तो फिर से सहमति मांगें। विज़िटर चेक-इन प्रक्रियाओं के लिए, टीमें यह विचार करने के लिए एक संकेत के रूप में कि कौन सी पहचान जानकारी आवश्यक है और इसे कैसे संभाला जाना चाहिए, चेक-इन से पहले अतिथि आईडी सत्यापित करने के निर्देश का भी उपयोग कर सकती हैं।
ऑफबोर्डिंग के दौरान प्रमाणपत्र, प्रबंधन प्रोफ़ाइल, कैश्ड टोकन और डिवाइस से जुड़ी किसी भी xPSK कुंजी को हटा दिया जाना चाहिए। एक Purple Access डेमो एक इंजीनियर को एक अपार्टमेंट के डिवाइसों: एक लॉक, एक थर्मोस्टेट, एक अतिथि का लैपटॉप, और एक क्लाइंट के कर्मचारी के फोन का उपयोग करके एक लाइव नेटवर्क पर कुंजी जारी करते और रद्द करते हुए दिखा सकता है।
- लाइव डिवाइस पर एक कुंजी जारी करें।
- इसे निरस्त करें।
- समय मापें कि पहुंच बंद होने में कितना समय लगता है।
- पायलट के निरसन पास अंक के रूप में परिणाम रिकॉर्ड करें।
रूट क्रम की पुष्टि करें और पहले इसका पायलट परीक्षण करें
रूट्स (routes) को ऐसे क्रम में लागू करें जिससे अपवादों के कारण पूरा नेटवर्क प्रभावित न हो। प्रत्येक डिवाइस वर्ग को एक डिफ़ॉल्ट मान मिलता है, जबकि पायलट प्रोजेक्ट यह पुष्टि करता है कि रूट वास्तविक स्थान पर पहचानों, नियंत्रकों और उपकरणों के साथ सही ढंग से कार्य करता है।
EAP-TLS पर प्रबंधित स्टाफ डिवाइसों से शुरुआत करें। एनरोल किए गए लैपटॉप और फोन के लिए प्रमाणपत्र मार्ग का उपयोग करें, जिसमें एक्सेस डायरेक्टरी समूहों और परीक्षण किए गए निरसन मार्ग (revocation path) से जुड़ी हो।
गेस्ट पोर्टल जोड़ें। साइन-इन अनुभव को स्पष्ट बनाएं और प्रत्येक गेस्ट सत्र पर सहमति रिकॉर्ड करें।
व्यक्तिगत और अप्रबंधित स्टाफ फोन को WiFi पास पर स्थानांतरित करें। यह उपयोगकर्ताओं को एक ऐसा मार्ग प्रदान करता है जिसके लिए पूर्ण डिवाइस एनरोलमेंट की आवश्यकता नहीं होती है।
साझा टिल, कियोस्क और IoT डिवाइसों को अद्वितीय xPSK कुंजियों पर रखें। प्रत्येक डिवाइस को उसकी अपनी एक्सेस नीति असाइन करें और रिकॉर्ड करें कि उसकी क्रेडेंशियल का मालिक कौन है।
फ़ॉलबैक मार्गों को केवल अपवादों पर लागू करें। जहां डिफ़ॉल्ट मार्ग संभव न हो, वहां केवल-ब्राउज़र एक्सेस, गेस्ट या ठेकेदार नेटवर्क, लोन डिवाइस या मैन्युअल समीक्षा का उपयोग करें।
लॉन्च से पहले पायलट मानदंड निर्धारित करें
किसी के द्वारा एनरोलमेंट शुरू करने से पहले एक पायलट साइट चुनें और पास मार्क्स निर्धारित करें। एनरोलमेंट पूर्णता, पहला सफल ऑथेंटिकेशन, प्रति 100 एनरोलमेंट पर हेल्प-डेस्क संपर्क, और एक्सेस निरस्त करने में लगा समय मापें। यदि आप पायलट के बाद थ्रेशोल्ड निर्धारित करते हैं, तो कमजोर परिणाम को स्वीकार्य कहना बहुत आसान हो जाता है क्योंकि साइट पहले से ही लाइव होती है।
एक डिज़ाइन सेशन बुक करें और अपनी SSID लिस्ट, एक्सेस पॉइंट वेंडर, डायरेक्टरी और MDM की जानकारी साथ लाएं। एक नेटवर्क इंजीनियर उन विवरणों को ओपन, सिक्योर और xPSK नेटवर्क से मैप कर सकता है और रोलआउट से पहले पायलट साइट के खिलाफ योजना को मान्य कर सकता है। डेमो अनुरोध में संगठन और संपर्क विवरण के साथ-साथ यह भी कैप्चर किया जाता है कि ग्राहक के WiFi पर वर्तमान में क्या चल रहा है, जिसमें SSIDs, एक्सेस पॉइंट वेंडर, डायरेक्टरी और MDM शामिल हैं।
Purple Access कैप्टिव-पोर्टल साइन-इन और सहमति, MDM के माध्यम से EAP-TLS प्रमाणपत्र, और गैर-प्रबंधित उपकरणों के लिए प्रति-डिवाइस कुंजियों का समर्थन करता है। डेमो की व्यवस्था करने और डिज़ाइन सत्र में अपने डिवाइस और नेटवर्क विवरण लाने के लिए Purple Access पर जाएं।
