2021 पर्यंत, UK सरकारकडे सुमारे 121 स्वतंत्र सिंगल साइन-ऑन सोल्यूशन्स होते, ज्यामुळे SSO हे केवळ सुविधेच्या वैशिष्ट्यापेक्षा जास्त का आहे हे स्पष्ट होते. SSO हे फेडरेटेड आयडेंटिटी कन्सॉलिडेशन आहे: हे विश्वसनीय आयडेंटिटी प्रोव्हायडरद्वारे ऑथेंटिकेशनचे केंद्रीकरण करते तर प्रत्येक अनुप्रयोग ऑथेंटिकेट वापरकर्त्याला कशासाठी ऑथोराइज्ड केले आहे याचे नियंत्रण ठेवतो.
तुम्ही एखाद्या सामान्य कामाच्या दिवशी ही समस्या अनुभवली असेल. कर्मचाऱ्याला ईमेल, क्लाउड ॲप्लिकेशन, मालमत्ता-व्यवस्थापन प्रणाली, अंतर्गत WiFi आणि प्रशासकीय पोर्टलची आवश्यकता असते. प्रत्येक सेवेचा स्वतःचा लॉगिन, पासवर्ड पॉलिसी आणि खाते मालक असतो. जेव्हा कोणी सामील होते, भूमिका बदलते किंवा सोडून जाते, तेव्हा प्रशासकांना अनेक सिस्टीम अपडेट कराव्या लागतात, आणि वापरकर्त्यांना कोणते क्रेडेंशियल कोणत्या सेवेचे आहेत हे लक्षात ठेवावे लागते.
हे व्यावहारिक कारण आहे ज्यामुळे संस्था SSO explained शोधतात. प्रश्न केवळ लॉगिन स्क्रीनची संख्या कशी कमी करायची हा नाही. ॲप्लिकेशन-स्तरीय परवानग्या कमकुवत न करता किंवा अधिक धोकादायक केंद्रीय लक्ष्य निर्माण न करता एक विश्वासार्ह ओळख नियंत्रण प्लेन कसे तयार करायचे हा आहे.
विखंडित ओळखीमुळे ॲक्सेसच्या खऱ्या समस्या का निर्माण होतात
UK सरकारच्या अनुभवातून एक उपयुक्त सुरुवात होते. एका 2021 GOV.UK सेवा-मानक पुनरावलोकनाने असा अंदाज लावला आहे की मध्यवर्ती सरकारकडे अंदाजे 121 विविध SSO उपाय होते कारण सेवा पथकांनी संपूर्ण सरकार-व्यापी एक सामायिक ओळख प्लॅटफॉर्म वापरण्याऐवजी स्वतंत्र प्रमाणीकरण प्रणाली तयार केल्या होत्या. त्यामुळे अनेक सार्वजनिक सेवा वापरणाऱ्या लोकांकडे साइन-इन तपशीलांचे अनेक संच असू शकतात आणि विशिष्ट व्यवहारासाठी कोणते खाते आवश्यक आहे हे त्यांना माहित नसू शकते. (UK सरकारचे प्रमाणीकरण आणि डिजिटल ओळख पुनरावलोकन)
याचा अर्थ असा नाही की केवळ सरकारी यंत्रणाच गुंतागुंतीच्या आहेत. मोठे उद्योग, आरोग्य सेवा संस्था, हॉस्पिटॅलिटी ग्रुप्स, प्रॉपर्टी ऑपरेटर्स आणि सार्वजनिक क्षेत्रातील नेटवर्क याच पॅटर्नचा सामना करतात. प्रत्येक ॲप्लिकेशन एक आयडेंटिटी सायलो तयार करू शकते, आणि प्रत्येक सायलोचे स्वतःचे पासवर्ड नियम, रिकव्हरी प्रक्रिया, ग्रुप मॉडेल आणि ऑफबोर्डिंग वर्कफ्लो विकसित होऊ शकतात.
ऑथेंटिकेशन आणि ऑथरायझेशन ही वेगवेगळी कामे आहेत
ऑथेंटिकेशन उत्तरे देते, “तुम्ही कोण आहात?” ऑथरायझेशन उत्तरे देते, “तुम्ही येथे काय ॲक्सेस करू शकता?” SSO विश्वासू ओळख प्रदात्याद्वारे (identity provider) पहिल्या प्रश्नाचे एकत्रीकरण करते. टार्गेट ॲप्लिकेशन अजूनही हे ठरवते की ती ओळख रेकॉर्ड पाहू शकते, सिस्टीमचे प्रशासक पद सांभाळू शकते, नेटवर्क सेगमेंटमध्ये सामील होऊ शकते किंवा एखादे विशिष्ट वैशिष्ट्य वापरू शकते का.
एक उपयुक्त मानसिक मॉडेल असे दिसते:
युझर
|
| एकदा ऑथेंटिकेट करतो
v
आयडेंटिटी प्रोव्हायडर
|
| विश्वासार्ह ओळख माहिती पाठवतो
v
ॲप्लिकेशन किंवा नेटवर्क
|
| स्थानिक परवानग्या लागू करतो
v
ऑथराइज्ड सेशन
हा फरक जॉइनर, मूव्हर आणि लीव्हर प्रक्रियेदरम्यान महत्त्वाचा ठरतो. जेव्हा एखादी व्यक्ती निघून जाते तेव्हा मध्यवर्ती ओळख निष्क्रिय केली जाऊ शकते, तरीही प्रत्येक कनेक्ट केलेल्या सेवेला स्पष्ट ऑथरायझेशन मॉडेल आणि अधिकार काढून टाकण्याच्या विश्वासार्ह मार्गाची आवश्यकता असते.
व्यावहारिक नियम: SSO कडे मध्यवर्ती ओळख नियंत्रित करण्याचा एक मार्ग म्हणून पहा, ॲप्लिकेशन परवानग्यांचा पर्याय म्हणून नाही.
हाच नियम wireline and wireless deployment डिझाइन करताना लागू होतो. नेटवर्क ॲक्सेस हा ओळख इस्टेटचा भाग आहे, त्यामुळे टीम्सने सामायिक पासवर्डला ॲक्सेस जोडण्याऐवजी कोणत्या डिरेक्टरी ग्रुप्स कोणत्या नेटवर्क भूमिकांपर्यंत पोहोचू शकतात हे ठरवले पाहिजे.
कर्मचाऱ्यांच्या WiFi आणि आयडेंटिटी-अवेयर ॲक्सेससाठी, Purple चे आयडेंटिटी-बेस्ड नेटवर्किंग हे दर्शवते की नेटवर्क पॉलिसी सामान्य क्रेडेंशियलऐवजी वैयक्तिक आयडेंटिटीशी कशी जोडली जाऊ शकते. याचा परिणाम व्यक्ती, त्यांची डिरेक्टरी स्थिती आणि त्यांना मिळणारा ॲक्सेस यामधील अधिक स्पष्ट संबंधात होतो.
एंटप्राइज फेडरेशनमध्ये Single Sign-On कसे कार्य करते
एंटरप्राइझ फेडरेशनमध्ये, एक identity provider, एक relying party आणि एक स्वाक्षरी केलेला ओळख संदेश ही स्वतंत्र कामे करतात. identity provider वापरकर्त्याचे ऑथेंटिकेशन करतो, तर relying party, जसे की ॲप्लिकेशन किंवा नेटवर्क सेवा, परिणामी मिळालेल्या ओळख माहितीचे सत्यापन करते.
ऑथेंटिकेशन पासवर्ड, मल्टीफॅक्टर ऑथेंटिकेशन, डिव्हाइस अटी किंवा दुसरी मंजूर पद्धत वापरू शकते. त्यानंतर प्रदाता विनंती केलेल्या सेवेसाठी स्वाक्षरी केलेले ॲसर्टन किंवा टोकन जारी करतो. ती सेवा त्या संदेशाचे सत्यापन करते आणि स्वतःचे सेशन तयार करते, ज्यामुळे क्रेडेंशियल्स identity provider कडेच राहतात.
फेडरेशन प्रवाह
- युझर सेवेची विनंती करतो. ते एखादे ॲप्लिकेशन, प्रशासकीय पोर्टल किंवा सुरक्षित नेटवर्क सेवा उघडतात.
- सेवा विद्यमान सेशन तपासते. ते नसल्यास, ते युझरला आयडेंटिटी प्रोव्हायडरकडे रिडायरेक्ट करते.
- आयडेंटिटी प्रोव्हायडर युझरचे ऑथेंटिकेशन करतो. ते MFA किंवा कन्टिशनल ॲक्सेस सारखी कॉन्फिगर केलेली नियंत्रणे लागू करते.
- आयडेंटिटी प्रोव्हायडर स्वाक्षरी केलेला संदेश जारी करतो. हे इंटिग्रेशन सहसा SAML असर्शन किंवा OpenID Connect टोकन वापरते.
- सेवा संदेशाची पडताळणी करते. ते इश्यूअर, स्वाक्षरी, ऑडियन्स, मुदत समाप्ती आणि संबंधित दाव्यांची तपासणी करते.
- ॲप्लिकेशन स्वतःचे सेशन तयार करते. ते सत्यापित ओळखीचे स्थानिक परवानग्यांशी मॅपिंग करते आणि ऑथेंटिकेशन इव्हेंटची नोंद करते.
पडताळणीमुळे विश्वासाच्या संबंधांचे रक्षण होते. UK National Cyber Security Centre सल्ला देते की अविश्वासार्ह नेटवर्कवर प्राप्त झालेल्या SAML दाव्यांची (assertions) अपेक्षित सर्टिफिकेट अथॉरिटीशी पडताळणी केली पाहिजे. पडताळणी न केलेला दावा एखाद्या विश्वासार्ह identity-provider कनेक्शनद्वारे खाते हायजॅक करण्याचा (account-takeover) मार्ग तयार करू शकतो. (ओळख आणि ॲक्सेस व्यवस्थापनावर NCSC चे मार्गदर्शन)
वैध आयडेंटिटी तपासणीद्वारे ऑथेंटिकेट झालेली आयडेंटिटी मिळते, टार्गेट सेवेतील प्रत्येक परवानगी नाही. अनुप्रयोगाने केवळ ऑथोरायझेशनसाठी आवश्यक असलेले दावे (claims) वापरले पाहिजेत, नंतर स्वतःचे रोल आणि रिसोर्स नियम लागू केले पाहिजेत. हे विभाजन समान फेडरेशन पॅटर्नला कर्मचार्‍यांचे अनुप्रयोग, प्रशासकीय पोर्टल आणि आयडेंटिटी-अवेयर नेटवर्क सेवांना सपोर्ट करण्याची अनुमती देते.
एंटरप्राइज संदर्भात SAML, OIDC आणि OAuth
एकदा फेडरेशन मॉडेल स्पष्ट झाले की, प्रोटोकॉल निवडणे सोपे होते. एंटरप्राइज SSO साठी SAML आणि OpenID Connect ही सामान्य मानके आहेत, तर OAuth हे प्रामुख्याने API च्या नियुक्त प्रवेशासाठी एक ऑथोरायझेशन फ्रेमवर्क आहे. ऑथेंटिकेशन आणि OAuth मध्ये गोंधळ केल्यास टीम्स असे आयडेंटिटी फ्लो तयार करू शकतात जे त्यांच्या सुरक्षिततेच्या प्रश्नाचे उत्तर देत नाही.
| मानक (Standard) | व्यावहारिक भूमिका | योग्य वापर |
|---|---|---|
| SAML | स्वाक्षरी केलेल्या ओळख दाव्यांची देवाणघेवाण करते | स्थापित एंटरप्राइज आणि ब्राउझर - आधारित ॲप्लिकेशन्स |
| OpenID Connect | टोकन वापरून ओळख स्तर जोडते | आधुनिक SaaS, वेब आणि मोबाइल - ओरिएंटेड सेवा |
| OAuth | सुरक्षित संसाधनांचा प्रवेश सोपवते | वापरकर्ता किंवा सेवेच्या वतीने API ॲक्सेस |
SAML बऱ्याचदा प्रगल्भ एंटरप्राइझ सॉफ्टवेअरमध्ये दिसते कारण ते सुस्थापित ब्राउझर फेडरेशन मॉडेल वापरते. JSON, REST आणि टोकन-आधारित संवादांसाठी डिझाइन केलेल्या आधुनिक सेवांसाठी OIDC सामान्यतः अधिक नैसर्गिक आहे. योग्य निवड ॲप्लिकेशन कशाला सपोर्ट करते आणि सेवा ओळखीच्या माहितीचे सत्यापन कसे करते यावर अवलंबून असते.
सेवेने काय सत्यापित केले पाहिजे
मानक कोणतेही असले तरी, relying party ने सेशन तयार करण्यापूर्वी प्राप्त झालेल्या ओळख सामग्रीचे सत्यापन केले पाहिजे. मुख्य तपासण्यांमध्ये पुढील गोष्टींचा समावेश होतो:
- जारीकर्ता (Issuer): संदेश अपेक्षित अचूक ओळख प्रदात्याकडूनच (identity provider) आला आहे याची पुष्टी करा.
- स्वाक्षरी (Signature): संदेशावर विश्वासार्ह की (key) किंवा प्रमाणपत्राद्वारे स्वाक्षरी केली गेली आहे याची पडताळणी करा.
- श्रोता (Audience): संदेश याच सेवेसाठी तयार केला गेला होता याची खात्री करा.
- मुदत समाप्ती (Expiry): जुने किंवा कालबाह्य झालेले दावे (assertions) किंवा टोकन नाकारा.
- दावे (Claims): केवळ संबंधित, सत्यापित ओळख आणि गट माहितीचा वापर करा.
आयडेंटिटी प्रोव्हायडर MFA, कंडिशनल ॲक्सेस, पासवर्ड बंदी आणि ग्रुप मेंबरशिप यांसारखी धोरणे केंद्रीकृत करू शकतो. त्यानंतर ॲप्लिकेशनला युझरच्या पूर्ण ऑथेंटिकेशन प्रक्रियेची प्रत ठेवण्याऐवजी, स्वतःच्या ऑथरायझेशन निर्णयासाठी आवश्यक असलेले दावे प्राप्त होतात.
Microsoft Entra ID, Okta किंवा Google Workspace सारख्या प्लॅटफॉर्मचे एकत्रीकरण करताना ते वेगळेपण उपयुक्त ठरते. प्रदाता ऑथेंटिकेशन पॉलिसी हाताळतो, तर कनेक्ट केलेले ॲप्लिकेशन त्याच्या ॲक्सेस मॉडेल आणि सेशन कंट्रोल्ससाठी जबाबदार राहते. RADIUS-as-a-Service आधारित ॲक्सेससाठी Okta एकत्रीकरणाचे मूल्यमापन करणाऱ्या नेटवर्क ऑपरेटर्ससाठी तोच नियम लागू होतो: ओळख पडताळणी आणि नेटवर्क ऑथोरायझेशन यांनी एकत्र काम केले पाहिजे, परंतु ते समान नियंत्रण नाहीत.
SSO मुळे निर्माण होणारा केंद्रीकरण धोका (Concentration Risk)
एकच तडजोड केलेले ओळख-प्रदाता खाते एकाच वेळी अनेक कनेक्ट केलेल्या सेवा उघडू शकते. SSO पासवर्डचा विस्तार कमी करते, तर ओळख प्रदात्यावर विश्वास केंद्रित करते, ज्यामुळे ते उच्च-मूल्य नियंत्रण प्लॅन बनते. त्यामुळे संस्थांना हे मूल्यांकन करणे आवश्यक आहे की फेडरेशन त्यांच्या ब्लास्ट रेडियसवर आणि पुनर्प्राप्ती पर्यायांवर कसा प्रभाव पाडतो. प्रमाणीकरण पद्धती निवडण्याबद्दल NCSC चे मार्गदर्शन विश्वासाच्या या एकाग्रतेवर एक धोका म्हणून प्रकाश टाकते ज्यासाठी हेतुपुरस्सर मूल्यांकन करणे आवश्यक आहे.
SSO साइन-इन इव्हेंट्स एकत्र करते. फिशिंग रेझिस्टन्स, डिव्हाइस ट्रस्ट आणि लीस्ट-प्रिव्हिलेज ॲक्सेस हे फेडरेशन आर्किटेक्चरभोवती असलेल्या कंट्रोल्समधून आले पाहिजेत. एक मजबूत डिझाइन प्रोव्हायडरचे, ते तयार करत असलेले सेशन्सचे आणि ॲक्सेस पुनर्संचयित करू शकणाऱ्या रिकव्हरी प्रक्रियांचे संरक्षण करते.
प्रोव्हायडरभोवती स्तर तयार करा
नियंत्रणांमध्ये नियमित साइन-इन आणि खाते पुनर्प्राप्तीदरम्यान वापरल्या जाणाऱ्या कमी दृश्यमान मार्गांचा समावेश असावा:
- विशेषाधिकार प्राप्त वापरकर्त्यांसाठी मजबूत MFA: जिथे वातावरण त्यांना समर्थन देते तिथे फिशिंग-प्रतिरोधक पद्धती वापरा, विशेषतः प्रशासकांसाठी.
- सशुल्क प्रवेश: प्रवेश देण्यापूर्वी उपकरणाची स्थिती, स्थान, सत्राचा धोका आणि इतर उपलब्ध सिग्नलचे मूल्यांकन करा.
- स्वतंत्र प्रशासक ओळख: विशेषाधिकार प्राप्त प्रशासन सामान्य दैनंदिन क्रियाकलापांपासून वेगळे ठेवा.
- प्रमाणीकरण देखरेख: अशक्य प्रवास, टोकन-रिप्ले निर्देशक, वारंवार अपयश आणि अनपेक्षित विशेषाधिकार वाढीची चौकशी करा.
- पुनर्प्राप्ती संरक्षण: मंजुरी आणि देखरेखीसह, हेल्प-डेस्क रीसेट आणि आपत्कालीन खात्यांना संवेदनशील ओळख ऑपरेशन्स म्हणून वागवा.
NCSC MFA किंवा अटींवर आधारित ॲक्सेससह मजबूत वापरकर्ता आणि डिव्हाइस ऑथेंटिकेशनसह एंटरप्राइज SSO एकत्र करण्याची शिफारस करते. हे SaaS साठी देखील SSO ची शिफारस करते कारण केंद्रित नियंत्रणे वापरकर्ता आणि गट व्यवस्थापन अधिक सुसंगत बनवतात आणि क्रेडेन्शियल प्रत्येक ॲप्लिकेशनमध्ये सिंक होण्यापासून रोखतात. याचे ओळख आणि ऑथेंटिकेशनवरील क्लाउड सुरक्षा तत्व हा दृष्टिकोन मांडते.
SSO क्रेडेंशियलची संख्या कमी करते जे तुम्ही संचलित केले पाहिजे. हे क्रेडेंशियल सोडते आणि सत्र कनेक्ट केलेल्या सेवांचे संचालन करते ज्यासाठी मजबूत संरक्षण आवश्यक आहे.
नेटवर्क टीम्सने वर्कफोर्स ओळख गेस्ट ओळखीपासून वेगळी केली पाहिजे. कर्मचारी फेडरेशन किमान-विशेषधिकार (least-privilege) ॲक्सेस आणि जलद रद्द करण्यास सपोर्ट करू शकते. दोन्ही प्रवाह Captive Portal किंवा वायरलेस पायाभूत सुविधा वापरतात म्हणूनच गेस्ट ऑथेंटिकेशनला कर्मचाऱ्यांचे डिरेक्टरी विशेषाधिकार वारशाने मिळालेच पाहिजेत असे नाही.
पासवर्डशिवाय WiFi आणि डिरेक्टरी-आधारित नेटवर्क ॲक्सेस
WiFi शी जोडल्या जाणाऱ्या कर्मचाऱ्याला सामायिक पासवर्डची (shared password) गरज नसावी जो त्यांनी नोकरी सोडल्यानंतरही वैध राहतो. डिरेक्टरी-बॅक्ड डिझाइनची सुरुवात संस्थेच्या identity provider द्वारे प्रमाणीकरणाने होते, त्यानंतर सत्यापित ओळख किंवा ग्रुपचे नेटवर्क रोलमध्ये मॅपिंग केले जाते. त्यामुळे वायरलेस सेवा स्वतंत्र WiFi पासवर्डची यादी ठेवण्याऐवजी इतरत्र वापरले जाणारे तेच नोकरी आणि ॲक्सेसचे निर्णय लागू करते.
Purple Microsoft Entra ID, Google Workspace आणि Okta सोबतच्या एकात्मतेद्वारे (integrations) एंटरप्राइज WiFi साठी या मॉडेलला सपोर्ट करते. याचे passwordless WiFi approach सामायिक क्रेडेन्शियल आणि ऑन - प्रिमायसेस RADIUS व्यवस्थापन टाळते. डिरेक्टरीमधील बदल प्रोव्हिजनिंग किंवा रिव्होकेशन ट्रिगर करू शकतात. कर्मचाऱ्याचे गट सदस्यत्व नेटवर्क ॲक्सेस ठरवते, तर सोडणाऱ्या कर्मचाऱ्याचे डिरेक्टरी खाते निष्क्रिय केल्याने कोणालाही सामान्य पासवर्ड बदलण्याची वाट न पाहता तो ॲक्सेस काढला जाऊ शकतो.
नेटवर्कवर फेडरेशन कंट्रोल्स लागू करा
ओळख प्रदाता (identity provider), नेटवर्क पॉलिसी आणि मॉनिटरिंग या सर्वांचे ॲक्सेस निर्णयावर एकमत असणे आवश्यक आहे. डिरेक्टरी ग्रुप्सचे वेगवेगळ्या नेटवर्क रोलमध्ये मॅपिंग करा, जेणेकरून कर्मचारी, कंत्राटदार आणि ॲडमिनिस्ट्रेटरना बाय डीफॉल्ट समान ॲक्सेस मिळणार नाही. दावे किंवा टोकनची मुदत छोटी ठेवा, ज्यामुळे कालबाह्य झालेल्या ओळखीच्या माहितीचा गैरवापर मर्यादित होईल. ओळख प्रदात्यावर MFA आवश्यक करा, कारण वायरलेस SSO केवळ SSO वापरल्याने MFA बनत नाही.
यशस्वी आणि अयशस्वी ऑथेंटिकेशन इव्हेंट्सची नोंद करा, आणि प्रत्येक ओळख निर्णयाला परिणामी नेटवर्क ऑथोरायझेशनशी जोडा. मुदत संपण्यापूर्वी सर्टिफिकेट रोलओव्हरची चाचणी घ्या, कारण फेडरेशन ट्रस्ट अयशस्वी झाल्यास अन्यथा सुरळीत असलेला WiFi ॲक्सेस खंडित होऊ शकतो.
मल्टी-टेनंट साइट्ससाठी स्वतंत्र सीमा आवश्यक असते. निवासी मालमत्ता, विद्यार्थी निवास, हॉटेल्स आणि मिश्र-वापर ठिकाणे भाडेकरूंचा ट्रॅफिक आणि कर्मचारी सिस्टीम वेगळ्या ठेवून रहिवासी किंवा पाहुण्यांना सोपा ॲक्सेस देऊ शकतात. iPSK जुन्या उपकरणांना सपोर्ट करू शकते, तर वर्कफोर्स SSO एक वेगळा कर्मचारी ओळख मार्ग प्रदान करते.
गेस्ट WiFi संमती, धारणा आणि ग्राहक प्रोफाइलबद्दल देखील निर्णय तयार करते. व्हेन्यूसाठी गेस्ट डेटाची ही मार्गदर्शिका नेटवर्क डिझाइनसह एक उपयुक्त संदर्भ प्रदान करते, तर Purple आयडेंटिटी-बेस्ड ऑथेंटिकेशनला वायरलेस ॲक्सेस अनुभवाशी जोडते.
UK एंटरप्रायझेस आणि व्हेन्यूसाठी मोजता येण्याजोगे परिणाम
एक व्यावहारिक SSO व्यवसाय प्रकरण अशा क्रेडेंशियल्सपासून सुरू होते ज्यांचे संस्थेला यापुढे प्रशासन करण्याची आवश्यकता नसते. 16 आणि त्याहून अधिक वयाच्या 2,000 UK रहिवाशांच्या एप्रिल 2024 मधील इन्स्टिट्यूशन ऑफ इंजिनिअरिंग अँड टेक्नॉलॉजी सर्वेक्षणात असे आढळून आले की केवळ 20% लोक सुरक्षित पासवर्ड योग्यरित्या ओळखू शकले. त्याच सर्वेक्षणात असे नोंदवले गेले की पाचव्या भागातील एकाने अनेक वेबसाइट्स किंवा उपकरणांवर एकच पासवर्ड पुन्हा वापरला, तर 21% लोकांनी महत्त्वपूर्ण तारीख वापरली आणि 20% लोकांनी पाळीव प्राण्याचे नाव वापरले. यात असेही आढळून आले की 38% लोकांचा असा विश्वास होता की अक्षरांऐवजी संख्या वापरल्याने पासवर्ड सुरक्षा सुधारते, 65% लोकांचा असा विश्वास होता की पासवर्ड कधीही लिहून ठेवू नयेत, आणि 77% लोकांना वाटले की वारंवार पासवर्ड बदलल्याने सुरक्षा वाढते. (IET पासवर्ड सुरक्षा सर्व्हे)
हे निष्कर्ष वापरकर्त्यांना प्रत्येक ॲप्लिकेशन आणि नेटवर्कसाठी स्वतंत्र क्रेडेंशियल्स तयार करण्यास आणि ते लक्षात ठेवण्यास सांगण्याच्या मर्यादा दाखवतात. केंद्रीकृत ओळख संस्था कुठे नियंत्रणे लागू करते आणि प्रशासक किती वेगाने कारवाई करू शकतात हे बदलते, जरी फिशिंग आणि खाते तडजोड हे थेट धोके राहतात.
ऑपरेटरसाठी, परिणाम व्यावहारिक असतात:
- कमी व्यवस्थापित नसलेले क्रेडेंशियल: वापरकर्ते कमी स्वतंत्र ॲप्लिकेशन पासवर्ड तयार करतात, लक्षात ठेवतात आणि पुन्हा वापरतात.
- सुसंगत धोरण: ओळख प्रदाता कनेक्ट केलेल्या सेवांमध्ये MFA, सशुल्क प्रवेश आणि पासवर्ड निर्बंध लागू करू शकतो.
- जलद रद्द करणे: कनेक्ट केलेल्या सेवा जीवनचक्र बदल योग्यरित्या प्रक्रिया करत असल्यास, संस्थात्मक ओळख अक्षम करणे ही मध्यवर्ती प्रवेश-हटवण्याची कारवाई बनू शकते.
- अधिक स्पष्ट ऑडिट ट्रेल्स: लॉग व्यक्तीच्या ओळखीला प्रमाणीकरण आणि नेटवर्क अधिकृतता निर्णयांसह जोडू शकतात.
- कमी दुप्पट प्रशासन: कार्यसंघ प्रत्येक सेवेमध्ये समान नियंत्रणे पुनर्निर्मित करण्याऐवजी मध्यवर्तीपणे ओळख धोरण राखतात.
याचे मूल्य केवळ साइन-इन प्रॉम्ट्स कमी करण्यापुरते मर्यादित नाही. एखादा आरोग्यसेवा प्रदाता भूमिकेनुसार (role) ॲक्सेस देवू शकतो, हॉटेल समूह कर्मचारी आणि पाहुण्यांच्या सेवा वेगळ्या करू शकतो, आणि मालमत्ता चालक भाडेकरू आणि कर्मचाऱ्यांच्या हक्कांची अधिक स्पष्ट मालकी ठेवू शकतो. प्रत्येक प्रकरणात, मोजण्यायोग्य परिणाम म्हणजे क्रेडेंशियलची कमी संख्या, अधिक विश्वासार्ह सोडण्याची (leaver) प्रक्रिया आणि ॲप्लिकेशन किंवा नेटवर्क रोलचा ॲक्सेस कोणाला मिळाला याचा मजबूत पुरावा.
नवीन धोका निर्माण न करता SSO लागू करणे
सुरक्षित रोलआउटची सुरुवात आयडेंटिटी मॉडेलने होते, लॉगिन बटणाने नाही. अनुप्रयोगामध्ये पासवर्ड कॉपी करण्याऐवजी, ते जेथे योग्य बसतात तेथे SAML किंवा OIDC निवडा. आयडेंटिटी प्रोव्हायडरला ऑथेंटिकेशन अथॉरिटी म्हणून स्थापित करा, नंतर प्रत्येक कनेक्ट केलेल्या सेवेने सत्र (session) तयार करण्यापूर्वी इश्यूअर, स्वाक्षरी, प्रेक्षक, मुदत संपणे आणि दाव्यांचे (claims) व्हॅलिडेत करणे आवश्यक आहे.
ऑपरेशनल चेकलिस्ट वापरा
- अधिकृत गटांपासून सुरुवात करा: योग्य व्यवसाय किंवा IT टीमच्या मालकीच्या डिरेक्टरी गटांमधून ॲक्सेस मिळवून द्या.
- मूव्हर नियम परिभाषित करा: रोल मधील बदलाने नवीन अधिकार जोडण्यासोबतच जुने अधिकार काढून टाकले पाहिजेत.
- सोडून जाणाऱ्या लोकांची मध्यवर्ती प्रक्रिया करा: संस्थात्मक ओळख निष्क्रिय करा आणि कनेक्ट केलेले ॲप्लिकेशन्स व नेटवर्क रोल्स योग्यरित्या प्रतिसाद देतात याची पडताळणी करा.
- ब्रेक-ग्लास ॲक्सेस सुरक्षित करा: आणीबाणीची खाती सामान्य प्रशासनापासून वेगळी ठेवा, त्यांच्यावर बारकाईने लक्ष ठेवा आणि त्यांच्या रिकव्हरी प्रक्रियेची चाचणी घ्या.
- कर्मचारी आणि पाहुणे वेगळे करा: Workforce SSO कमीत कमी-हक्क ॲक्सेस आणि तो रद्द करण्यास सपोर्ट करू शकते. गेस्ट ऑथेंटिकेशनला कर्मचाऱ्यांच्या परवानग्या वारशाने मिळाल्या नाही पाहिजेत.
- ट्रस्ट बदलांची चाचणी घ्या: प्रोडक्शनवर अवलंबून राहण्यापूर्वी सर्टिफिकेट रोलओव्हर, टोकन मुदत समाप्ती, सेशन समाप्ती आणि प्रदाता आऊटिजची पडताळणी करा.
- मॉनिटरिंगचे पुनरावलोकन करा: तपासासाठी ऑथेंटिकेशन इव्हेंट्स, प्रशासकीय कृती आणि नेटवर्क ऑथोरायझेशन निर्णय उपलब्ध असल्याची खात्री करा.
एखाद्या ठिकाणाला त्यांच्या विद्यमान वायरलेस मालमत्तेला बदलण्याऐवजी अनेक नेटवर्क विक्रेत्यांना सपोर्ट करण्याची आवश्यकता असू शकते. Purple ला Meraki, Aruba, Ruckus, Mist आणि UniFi सोबत काम करण्यासाठी डिझाइन केले आहे, आणि याचे नमूद केलेले रोलआउट मॉडेल महिन्यांऐवजी आठवड्यांमध्ये मोजले जाते. या क्षमतांकडे अंमलबजावणीच्या बाबी म्हणून पहा, आर्किटेक्चर पुनरावलोकनाचे पर्याय म्हणून नाही. तंत्रज्ञान प्रदाते सुरक्षा उपायांचे वर्णन कसे करतात याच्या विस्तृत दृश्यासाठी, AdManage.ai चे trust आणि controls एक उपयुक्त तुलनात्मक पॉइंट प्रदान करते.
मुख्य निर्णय हा आहे की संस्था प्रत्येक कनेक्ट केलेल्या सेवेसाठी, वापरकर्त्याचे प्रमाणीकरण कोण करते, कोणत्या दाव्यांवर (claims) विश्वास ठेवला जातो, परवानग्या कशा असाइन केल्या जातात आणि आयडेंटिटी बदलल्यावर काय होते हे स्पष्ट करू शकते का. SSO हे आयडेंटिटी आणि ॲक्सेस मॅनेजमेंट प्रोग्राममधील एक स्तर आहे. ते MFA, कंडिशनल ॲक्सेस, ऑथेंटिकेशन मॉनिटरिंग, रिकव्हरी कंट्रोल्स किंवा लाइफसायकल गव्हर्नन्सची जागा घेत नाही.
Purple ही वर्कफोर्स आयडेंटिटी पासवर्डलेस WiFi, डिरेक्टरी-बेस्ड नेटवर्क रोल्स आणि स्वतंत्र गेस्ट ॲक्सेसशी जोडते, ज्यामुळे Entra ID, Google Workspace आणि Okta सह इंटिग्रेशनला सपोर्ट मिळतो. तिचे आयडेंटिटी-बेस्ड नेटवर्किंग मॉडेल तुमच्या सध्याच्या वायरलेस वातावरणात आणि SSO रोलआउटमध्ये कसे बसू शकते हे तपासण्यासाठी Purple ला भेट द्या.
