टीम में SaaS अकाउंट साझा करना: चार जोखिम और अनुपालन वाले विकल्प

किसी SaaS टूल में एक अतिरिक्त यूज़र सीट जोड़ना छोटी लागत नहीं होती। टीम में लोगों की संख्या बढ़ते ही यह खर्च साफ़ दिखाई देने लगता है।

इसीलिए एक ही लॉगिन जानकारी साझा करना स्वाभाविक लग सकता है, खासकर तब जब किसी को केवल कभी-कभी रिपोर्ट देखनी हो या थोड़े समय के लिए किसी ग्राहक के लिए डेटा जाँचना हो। लेकिन इसकी वास्तविक कीमत अक्सर कम आँकी जाती है और कई हिस्सों में बँटी होती है: सेवा की शर्तें, लॉगिन क्रेडेंशियल, गतिविधि लॉग और टीम में बदलाव। हर हिस्से की अपनी समस्या है।

शर्तें स्पष्ट हैं: अकाउंट साझा नहीं किए जाने चाहिए

अधिकांश SaaS उत्पाद सीट-आधारित लाइसेंसिंग मॉडल पर चलते हैं। उन एंटरप्राइज़ या टीम प्लान को छोड़कर जो स्पष्ट रूप से कई यूज़र का समर्थन करते हैं, बाकी प्लान आम तौर पर एक व्यक्ति के उपयोग तक सीमित होते हैं। सेवा की शर्तें प्रायः कई लोगों द्वारा एक ही लॉगिन जानकारी साझा करने को स्पष्ट रूप से प्रतिबंधित करती हैं, और प्लेटफ़ॉर्म इसका पता चलने पर एक्सेस निलंबित या रद्द कर सकता है। एक बात आसानी से छूट जाती है: इस तरह एक्सेस समाप्त होने पर सामान्यतः रिफंड नहीं मिलता, इसलिए पहले से दिया गया पैसा सीधे खो सकता है।

एक और कम दिखाई देने वाली लागत भी है। साझा करने का उद्देश्य पैसे बचाना है, लेकिन प्लेटफ़ॉर्म की यह व्यवस्था नहीं बदलती कि एक्सेस की ज़रूरत रखने वाले लोगों की संख्या के अनुसार शुल्क लिया जाता है। असल में बचत लाइसेंस लागत को अनुपालन जोखिम से बदल देती है; यह जोखिम तब तक दिखाई नहीं देता जब तक कोई समस्या न हो।

पासवर्ड कई लोगों के पास हो तो यह तय करना कठिन है कि काम किसने किया

अकाउंट साझा करने का मतलब है कि पासवर्ड कई लोगों के बीच घूमेगा, और अक्सर चैट ऐप, नोट्स या ऐसी जगहों से गुज़रेगा जहाँ एक संदेश लंबे समय तक रिकॉर्ड बनकर रह सकता है।

समस्या केवल पासवर्ड नहीं है, बल्कि उससे पैदा होने वाले दो परिणाम हैं। पहला, एक्सपोज़र बढ़ जाता है: जितने अधिक लोग साझा करने में शामिल होंगे, उतनी अधिक संभावना होगी कि किसी ने यही पासवर्ड कहीं और दोबारा इस्तेमाल किया हो या किसी डिवाइस से समझौता हुआ हो, जिससे अकाउंट में प्रवेश का रास्ता बन सकता है। दूसरा, जवाबदेही तय करना मुश्किल हो जाता है। यदि अकाउंट से डेटा एक्सपोर्ट किया गया, सेटिंग बदली गई या ऐसा कुछ भेजा गया जिसे नहीं भेजना चाहिए था, तो बाद में केवल यह पता चलता है कि अकाउंट ने क्या किया, यह नहीं कि वास्तव में किस व्यक्ति ने किया। जिन टीमों को ग्राहकों के सामने डेटा के प्रवाह का हिसाब देना होता है, उनके लिए यह अक्सर सबसे कठिन समस्याओं में से एक है।

गतिविधि लॉग अकाउंट को दर्ज करते हैं, व्यक्ति को नहीं

SaaS एडमिन सिस्टम आम तौर पर गतिविधि को अकाउंट के आधार पर दर्ज करते हैं: किसने रिपोर्ट एक्सपोर्ट की, कौन-सी सेटिंग बदली और कौन-सा डेटा हटाया गया। लॉग में अक्सर केवल एक अकाउंट नाम दिखाई देता है।

जब कई लोग वही अकाउंट इस्तेमाल करते हैं, तो यह ट्रेसबिलिटी टूट जाती है। टीम के भीतर यह पता नहीं चलता कि बदलाव किसने किया, और प्लेटफ़ॉर्म का असामान्य गतिविधि पहचानने वाला सिस्टम भी इसी समस्या से जूझता है। वह एक ही अकाउंट को कई शहरों, कई डिवाइस और अलग-अलग नेटवर्क निकास से लॉगिन करते हुए तथा एक साथ कई सेशन चलते हुए देख सकता है और गतिविधि को चिह्नित कर सकता है। आम कार्रवाई में जबरन लॉगआउट, अस्थायी रोक या दोबारा सत्यापन की माँग शामिल है। यदि यह टूल रोज़मर्रा के काम के लिए ज़रूरी है, तो काम के समय एक्सेस बंद होना कुछ अतिरिक्त सीटों की कीमत से कहीं अधिक महँगा पड़ सकता है।

प्रॉक्सी बदलना या ब्राउज़र फ़िंगरप्रिंट को एक जैसा बनाना केवल पहचान होने की संभावना घटा सकता है; इससे कई लोगों का एक अकाउंट साझा करना नियमों के अनुरूप नहीं हो जाता। इसके अलावा, यदि सभी लॉगिन एक ही वातावरण से जुड़े हों, तो उस वातावरण में समस्या—जैसे IP का चिह्नित होना या वातावरण का असामान्य माना जाना—सभी लोगों का एक्सेस एक साथ रोक सकती है और समस्या का असर बढ़ा सकती है।

व्यक्ति चला जाता है, लेकिन एक्सेस रह जाता है

जब कोई कर्मचारी नौकरी छोड़ता है या किसी बाहरी ठेकेदार का काम समाप्त होता है, तो साझा अकाउंट का एक्सेस वापस लेने की जिम्मेदारी अक्सर किसी एक व्यक्ति के पास स्पष्ट रूप से नहीं होती। कारण सीधा है: अकाउंट सबका है, इसलिए कोई निश्चित हैंडओवर चरण नहीं होता।

कई जोखिम पीछे रह जाते हैं। जा चुका सदस्य अभी भी पासवर्ड जान सकता है, और किसी को यह पता नहीं होता कि और किसने उसे सुरक्षित कर रखा है। पहले जारी किए गए सेशन कुकी अभी भी मान्य हो सकते हैं। यदि उस व्यक्ति ने इस अकाउंट से ऑटोमेशन स्क्रिप्ट या API कॉल सेट किए थे, तो वे रास्ते भी अपने आप बंद नहीं होंगे। समस्या का पता चलने तक डेटा पहले ही बदला जा सकता है।

इसके अलावा, टीम में हर बदलाव पर सभी के लिए पासवर्ड बदलना पड़ेगा। साझा मॉडल में यह बदलाव पूरी तरह लागू करना अक्सर कठिन होता है।

अनुपालन वाले विकल्प जटिल नहीं हैं

यदि साझा करने के कारणों को अलग-अलग देखें, तो उपयुक्त विकल्प काफी स्पष्ट हैं।

• स्थायी सदस्यों को लंबे समय तक एक्सेस चाहिए: अतिरिक्त यूज़र सीट खरीदें। कई लोगों के उपयोग के लिए यही एकमात्र आधिकारिक रूप से समर्थित तरीका है और इससे लॉग में व्यक्ति-स्तर की ट्रेसबिलिटी वापस आती है।
• टीम बड़ी है: देखें कि प्लेटफ़ॉर्म बहु-यूज़र टीम या एंटरप्राइज़ प्लान देता है या नहीं। ऐसे प्लान में अक्सर अनुमति मॉडल होता है, जिससे भूमिका के आधार पर तय किया जा सकता है कि कौन क्या देख या बदल सकता है।
• केंद्रीकृत नियंत्रण चाहिए: SSO का उपयोग करें। किसी सदस्य के जाने पर उसका एक्सेस एक जगह से बंद किया जा सकता है और किसी व्यक्ति के याद रखने पर निर्भर नहीं रहना पड़ता।
• ग्राहक को केवल थोड़े समय के लिए परिणाम दिखाना है: रिपोर्ट एक्सपोर्ट करें या केवल पढ़ने योग्य शेयरिंग लिंक बनाएँ, ताकि ग्राहक अकाउंट में लॉगिन किए बिना डेटा जाँच सके।

अकाउंट साझा करना और कई अकाउंट इस्तेमाल करना अलग बातें हैं। पहले मामले में कई लोग एक ही क्रेडेंशियल सेट का उपयोग करते हैं। दूसरे में हर व्यक्ति के अपने क्रेडेंशियल होते हैं, लेकिन एक ही डिवाइस पर उन्हें बिना एक-दूसरे में हस्तक्षेप किए काम करना होता है; यह दूसरा मॉडल अपने आप में अनुपालन वाला हो सकता है। उदाहरण के लिए, यदि टीम ने हर सदस्य के लिए सीट खरीदी है और सबके अपने अकाउंट हैं, तो एक ही ब्राउज़र में कुकी और सेशन एक-दूसरे को ओवरराइट कर सकते हैं। हर अकाउंट को अलग ब्राउज़र वातावरण देने से सेशन, कैश और डेटा अलग रखे जा सकते हैं। PurpleMark इसी प्रकार की वातावरण पृथक्करण क्षमता देता है। यह एक ही डिवाइस पर कई वैध अकाउंट को स्थिर रूप से साथ चलाने की समस्या हल करता है; कई लोगों द्वारा एक ही लॉगिन क्रेडेंशियल साझा करना फिर भी सेवा की शर्तों का उल्लंघन रहता है और कोई टूल इस तथ्य को नहीं बदलता।

निर्णय लेने से पहले लागत का हिसाब करें

मूल रूप से, अकाउंट साझा करना थोड़ी सीट लागत बचाने के बदले अनुपालन जोखिम लेना है। कभी-कभार, अस्थायी और एक व्यक्ति का उपयोग कुछ समय तक ठीक चलता हुआ लग सकता है, लेकिन टीम के स्तर पर एक्सेस रद्द होने या डेटा घटना की कीमत बचाई गई रकम से कहीं अधिक हो सकती है।

पहले लाइसेंस लागत स्पष्ट रूप से निकालें, फिर तरीका चुनें। यदि सीट खरीद सकते हैं तो सीट खरीदें; यदि डेटा एक्सपोर्ट कर सकते हैं तो उसे एक्सपोर्ट करें।

सटीक लाइसेंस नियमों के लिए हर उत्पाद की आधिकारिक शर्तों को आधार मानें।