समिति में एक से ज़्यादा लोग सॉफ्टवेयर चलाते हैं — सचिव, लेखाकार, कैशियर, डेटा-एंट्री कर्मचारी। हर किसी को सब कुछ करने का अधिकार देना सुरक्षित नहीं — इससे गलती व दुरुपयोग दोनों का जोखिम बढ़ता है। यहीं काम आती हैं भूमिकाएँ (roles) और अनुमतियाँ (permissions)। यह लेख इन्हें आसान भाषा में, व्यावहारिक उदाहरणों सहित समझाता है।
भूमिका पहुँच-अधिकारों का एक नामित समूह है (जैसे Admin, Accountant, Data-entry) जो हर उपयोगकर्ता को दिया जाता है — यह तय करता है कि वह क्या देख व कर सकता है। भूमिका देने से हर व्यक्ति के लिए अलग-अलग अधिकार तय करने की ज़रूरत नहीं पड़ती — बस उसे सही भूमिका दे दें, और उसके अधिकार अपने-आप तय हो जाते हैं।
अनुमति किसी खास काम को करने का अधिकार है — जैसे वाउचर बनाना, रिपोर्ट देखना, स्वीकृति देना, या मिटाना। कई अनुमतियाँ मिलकर एक भूमिका बनाती हैं। यानी भूमिका "पद" है, और अनुमतियाँ उस पद के साथ आने वाले "अधिकार"।
| भूमिका | आम पहुँच (उदाहरण) |
|---|---|
| Admin | सब कुछ |
| Accountant | एंट्री, रिपोर्ट, मिलान |
| Data-entry | केवल वाउचर एंट्री |
⚠️ सुविधा के लिए सबको Admin बनाना नियंत्रण खत्म कर देता है। हर भूमिका को उतनी ही पहुँच दें, जितनी ज़रूरी है (least-privilege)।
सुरक्षा का सबसे बुनियादी सिद्धांत है least-privilege — हर व्यक्ति को सिर्फ़ उतना ही अधिकार दें जितना उसके काम के लिए ज़रूरी है, एक भी ज़्यादा नहीं। इसका कारण सरल है: जितने कम लोगों के पास संवेदनशील अधिकार (मिटाना, बदलना, मंज़ूरी), उतना कम जोखिम — चाहे गलती से हो या जानबूझकर। एक डेटा-एंट्री कर्मचारी को रिपोर्ट मिटाने या लेन-देन मंज़ूर करने का अधिकार क्यों चाहिए? नहीं चाहिए — इसलिए मत दीजिए। यह किसी पर अविश्वास नहीं, बल्कि सबकी सुरक्षा है — कम अधिकार का मतलब कम जिम्मेदारी का बोझ भी।
हर समिति अपनी ज़रूरत के अनुसार भूमिकाएँ बना सकती है, पर आम तौर पर ये होती हैं:
इस तरह हर व्यक्ति अपना काम कर सके, पर किसी के पास ज़रूरत से ज़्यादा अधिकार न हो।
संवेदनशील काम (जैसे मिटाना, स्वीकृति) सीमित रखें, और वाउचर स्वीकृति (maker-checker) जोड़ें — एक व्यक्ति एंट्री बनाए, दूसरा जाँचे। इससे गलतियाँ व दुरुपयोग दोनों रुकते हैं, और ऑडिट-ट्रेल मज़बूत होता है।
🔍 ऑडिटर भूमिका-आधारित पहुँच और कर्तव्यों के बँटवारे (separation of duties) को महत्व देते हैं।
maker-checker का सिद्धांत सरल पर ताक़तवर है — कोई भी बड़ा या संवेदनशील लेन-देन एक अकेले व्यक्ति के हाथ में पूरा न हो। एक बनाता है (maker), दूसरा जाँचकर मंज़ूर करता है (checker)। इससे एक की गलती दूसरे की नज़र में आ जाती है, और अकेले किसी के दुरुपयोग की गुंजाइश घटती है। बड़े भुगतान, वाउचर-सुधार व डिलीट जैसे कामों पर यह नियंत्रण ख़ासकर उपयोगी है। (देखें: समिति में आंतरिक नियंत्रण।)
एक और अहम सिद्धांत है कर्तव्य-विभाजन — यानी एक ही व्यक्ति किसी लेन-देन के सारे चरण अकेले न करे। उदाहरण के लिए, जो व्यक्ति नकद संभालता है, वही अकेले उसकी बही न लिखे और अकेले सत्यापन न करे। इसी तरह, जो वाउचर बनाता है, वही उसे मंज़ूर न करे। भूमिकाएँ व अनुमतियाँ इसी कर्तव्य-विभाजन को लागू करने का साधन हैं। छोटी समिति में, जहाँ कम लोग हैं, वहाँ भी कम-से-कम दो लोगों के बीच अहम काम बाँटना — यह सुरक्षा की बड़ी परत जोड़ता है।
अगर सबको एक जैसा (या Admin) अधिकार दे दिया जाए, तो कई जोखिम खड़े होते हैं:
इसलिए सही भूमिकाएँ सिर्फ़ सुविधा नहीं, बल्कि सुरक्षा व जवाबदेही की ज़रूरत हैं।
किस भूमिका को क्या अधिकार, यह एक तालिका में देखना सबसे साफ़ रहता है (यह सिर्फ़ एक उदाहरण है — अपनी समिति के अनुसार समायोजित करें):
| काम | Admin/सचिव | लेखाकार | कैशियर | डेटा-एंट्री | ऑडिटर |
|---|---|---|---|---|---|
| वाउचर बनाना | ✅ | ✅ | नकद ही | ✅ | ❌ |
| वाउचर मंज़ूर करना | ✅ | ❌ | ❌ | ❌ | ❌ |
| रिपोर्ट देखना | ✅ | ✅ | सीमित | ❌ | ✅ |
| नकद-मॉड्यूल | ✅ | ✅ | ✅ | ❌ | देखना |
| मिटाना (delete) | सीमित | ❌ | ❌ | ❌ | ❌ |
| उपयोगकर्ता-प्रबंधन | ✅ | ❌ | ❌ | ❌ | ❌ |
| सेटिंग्स बदलना | ✅ | ❌ | ❌ | ❌ | ❌ |
इस मैट्रिक्स से साफ़ है कि सबसे संवेदनशील अधिकार (मंज़ूरी, मिटाना, उपयोगकर्ता-प्रबंधन, सेटिंग्स) सिर्फ़ Admin के पास हैं, और ऑडिटर सब देख सकता है पर कुछ बदल नहीं सकता। यही संतुलन सुरक्षा व सुचारु काम — दोनों देता है।
छोटी समिति में अक्सर एक-दो लोग ही सब कुछ संभालते हैं, इसलिए लग सकता है कि भूमिकाओं की ज़रूरत नहीं। पर वहाँ भी कुछ सरल कदम बड़ा फ़र्क़ डालते हैं: कम-से-कम दो लोगों के बीच अहम काम बाँटें (जैसे एक नकद संभाले, दूसरा बही जाँचे); बड़े भुगतान/डिलीट पर दूसरे की सहमति लें; और हर व्यक्ति का अलग लॉगिन रखें। इस तरह बिना जटिल ढाँचे के भी "दो आँखें एक से बेहतर" का सिद्धांत लागू होता है। पूर्ण Admin-अधिकार सिर्फ़ एक भरोसेमंद व्यक्ति (सचिव) के पास रखें, और बाकी को सीमित भूमिका दें — छोटी समिति के लिए भी यह सुरक्षा की बड़ी परत है।
अच्छे सहकारी सॉफ्टवेयर में भूमिका-प्रबंधन आसान होता है: उपयोगकर्ता-प्रबंधन में जाकर हर व्यक्ति के लिए एक लॉगिन बनाएँ, उसे उपयुक्त भूमिका दें (जैसे लेखाकार/कैशियर/एंट्री), और ज़रूरत हो तो अनुमतियाँ बारीकी से समायोजित करें। संवेदनशील अधिकार (मंज़ूरी/डिलीट) पर maker-checker चालू करें। स्टाफ बदलने पर पुराने लॉगिन को निष्क्रिय करें व नया बनाएँ। यह सब कुछ ही मिनटों का काम है, और एक बार सही सेट कर देने पर सालों तक सुरक्षा व स्पष्ट नियंत्रण देता है। (मदद के लिए देखें: User Permission कैसे दें।)
सबसे अनदेखी की जाने वाली सुरक्षा-भूल है — कोई कर्मचारी/पदाधिकारी जाने पर उसकी पुरानी पहुँच न हटाना। जो व्यक्ति अब समिति में नहीं, उसका लॉगिन सक्रिय रहना बड़ा जोखिम है। इसलिए जैसे ही कोई भूमिका छोड़े, उसकी पहुँच तुरंत हटाएँ या निष्क्रिय करें, और उसके अधिकार नए व्यक्ति को दें। इसी तरह, हर व्यक्ति का अलग लॉगिन हो — साझा लॉगिन से जवाबदेही खत्म हो जाती है (पता नहीं चलता किसने क्या किया)। (देखें: डेटा सुरक्षा व बैकअप।)
भूमिका-आधारित पहुँच का एक बड़ा लाभ ऑडिट-ट्रेल है — जब हर व्यक्ति का अलग लॉगिन व तय अधिकार हों, तो सिस्टम दर्ज कर सकता है कि कौन-सी एंट्री किसने, कब बनाई या बदली। यह पारदर्शिता गड़बड़ी रोकती है और किसी समस्या की जड़ तक पहुँचना आसान बनाती है। इसके विपरीत, साझा लॉगिन या सबको एक-सा अधिकार होने पर यह ट्रेल बेकार हो जाता है। इसलिए भूमिकाएँ सिर्फ़ पहुँच-नियंत्रण नहीं, जवाबदेही का भी आधार हैं। (देखें: वाउचर नैरेशन व दस्तावेज़।)
मान लीजिए एक समिति में सचिव, एक लेखाकार व एक डेटा-एंट्री कर्मचारी हैं। सही व्यवस्था होगी: सचिव को Admin (सब कुछ, पर maker-checker में मंज़ूरीकर्ता); लेखाकार को एंट्री + रिपोर्ट + मिलान; डेटा-एंट्री कर्मचारी को सिर्फ़ वाउचर दर्ज करने का अधिकार (मिटाना/मंज़ूरी नहीं)। जब डेटा-एंट्री कर्मचारी कोई वाउचर बनाता है, तो वह मंज़ूरी के लिए सचिव के पास जाता है (maker-checker)। कर्मचारी के जाने पर उसकी पहुँच तुरंत हटा दी जाती है। इस सरल व्यवस्था से हर कोई अपना काम करता है, कोई अकेले बड़ी गड़बड़ी नहीं कर सकता, और हर बदलाव का रिकॉर्ड रहता है।
भूमिका और अनुमति में फर्क? — भूमिका अनुमतियों का समूह है (जैसे एक पद); अनुमति एक खास काम का अधिकार। क्या सबको Admin बना दें? — नहीं; least-privilege अपनाएँ — उतनी ही पहुँच जितनी ज़रूरी। क्या डिलीट सबको देना चाहिए? — नहीं; मिटाना/स्वीकृति जैसी संवेदनशील अनुमतियाँ बहुत सीमित रखें। least-privilege क्या है? — हर व्यक्ति को सिर्फ़ उतना अधिकार जितना काम के लिए ज़रूरी — सुरक्षा की रीढ़। maker-checker क्या है? — एक व्यक्ति एंट्री बनाए, दूसरा जाँचकर मंज़ूर करे — गलती व दुरुपयोग दोनों रुकते हैं। कर्तव्य-विभाजन क्यों ज़रूरी? — ताकि एक ही व्यक्ति किसी लेन-देन के सारे चरण अकेले न करे; जोखिम व शक दोनों घटते हैं। स्टाफ जाने पर क्या करें? — उसकी पहुँच तुरंत हटाएँ/निष्क्रिय करें, और अधिकार नए व्यक्ति को दें। साझा लॉगिन क्यों नहीं? — इससे "किसने क्या किया" पता नहीं चलता; हर व्यक्ति का अलग लॉगिन रखें। छोटी समिति को भी भूमिकाओं की ज़रूरत है? — हाँ; कम-से-कम अहम काम दो लोगों में बाँटें व अलग लॉगिन रखें — यह बड़ी सुरक्षा-परत है। भूमिकाएँ सेट करना कितना कठिन है? — नहीं; अच्छे सॉफ्टवेयर में हर व्यक्ति का लॉगिन बनाकर उपयुक्त भूमिका देना कुछ ही मिनटों का काम है।
सही भूमिकाएँ और अनुमतियाँ डेटा को सुरक्षित और नियंत्रण को साफ़ रखती हैं — और ऑडिट को आसान। यह कोई जटिल व्यवस्था नहीं; बस तीन सिद्धांत याद रखें — least-privilege (उतना ही अधिकार जितना ज़रूरी), कर्तव्य-विभाजन (एक काम एक हाथ में नहीं), और अलग लॉगिन के साथ maker-checker। इन्हें अपनाने वाली समिति में हर कोई अपना काम बिना रुकावट करता है, कोई अकेले बड़ी गड़बड़ी नहीं कर सकता, और हर बदलाव का रिकॉर्ड रहता है — यही सुरक्षित, पारदर्शी व भरोसेमंद प्रबंधन की नींव है।
एक बात याद रखिए — भूमिकाएँ व अनुमतियाँ किसी पर अविश्वास का प्रतीक नहीं, बल्कि पूरी टीम की सुरक्षा हैं। जब हर किसी के अधिकार स्पष्ट व सीमित हों, तो न कोई अनजाने में बड़ी गलती करता है, न किसी पर बेवजह शक आता है, और हर काम का रिकॉर्ड साफ़ रहता है। यही स्पष्टता एक स्वस्थ, भरोसेमंद व ऑडिट-रेडी समिति की पहचान है — और इसे सेट करना कुछ ही मिनटों का काम है।
✅ सुरक्षित, भूमिका-आधारित पहुँच — SahakarLekha पर मुफ्त शुरू करें।
जुड़ी पढ़ाई: डेटा सुरक्षा व बैकअप · समिति में आंतरिक नियंत्रण · वाउचर नैरेशन व दस्तावेज़ · ऑडिट की तैयारी
जुड़े शब्द: उपयोगकर्ता भूमिका · उपयोगकर्ता अनुमति · वाउचर स्वीकृति · least-privilege · Maker-Checker
मदद पेज: User Permission कैसे दें
📘 स्रोत: सक्रिय Knowledge Items (KI-000310/311/065) — Evidence Level A (शैक्षिक)।
अपनी समिति का खाता डिजिटल कीजिए — रजिस्टर करें →