कौन क्या कर सकता है? बढ़ती टीम के लिए रोल-आधारित एक्सेस और ऑडिट लॉग

तीन outlet वाले एक रिटेल कारोबार की मालकिन को सोमवार की सुबह सोचिए। वे refund report खोलती हैं तो देखती हैं कि रविवार को outlet 2 से 41 refund हुए, कुल 2,870 डॉलर के। इनमें से 38 refund 50 से 300 डॉलर के बीच के हैं, यानी उस दायरे के जिसमें दूसरे व्यक्ति की मंज़ूरी ज़रूरी थी। फिर भी हर refund एक ही कैशियर के login से जारी हुआ, और मंज़ूरी भी उसी login ने दी।

किसी ने system हैक नहीं किया। दो साल पहले एक व्यस्त दिन उस कैशियर को "सिर्फ़ वीकेंड के लिए" शिफ़्ट लीड का रोल दिया गया था, जो कभी वापस नहीं लिया गया। system ने ठीक वही किया जो उससे कहा गया था। यह समझाने के लिए गढ़ा गया दृश्य है, पर पैटर्न आम है: एक्सेस जल्दबाज़ी में दिया जाता है, उसकी समीक्षा कभी नहीं होती, और जो लॉग बनता है उसे कोई पढ़ता नहीं।

यह लेख उन तीन बातों पर है जो ऐसी घटना रोकती हैं: काम की ज़रूरत के हिसाब से बने रोल, पैसे या stock को हिलाने वाले हर काम में दो लोग, और ऐसा audit लॉग जिसे चुपके से बदला न जा सके। साथ में तीन outlet वाले रिटेलर के लिए एक रोल template है और एक refund रिकॉर्ड के फ़ील्ड भी।

टीम बढ़ने पर एक्सेस कैसे बिखरता है

तीन लोगों की टीम में सब एक-दूसरे को जानते हैं, और एक साझा admin login से कोई नुक़सान होता नहीं दिखता। लेकिन तीन outlet में पंद्रह लोग हों तो वही आदतें जोखिम बन जाती हैं। वजहें बहुत मामूली हैं:

• धीरे-धीरे जमा होती permission। कोई काम बदलता है और पुराना एक्सेस साथ रखता है, क्योंकि जोड़ना एक मिनट का काम है और हटाना किसी की ज़िम्मेदारी नहीं।
• कॉपी किए गए account। नए कर्मचारी को "प्रिया जैसा" सेट कर दिया जाता है, उस सबके साथ जो प्रिया को 2024 में एक प्रोजेक्ट के लिए मिला था।
• साझा login। पूरी शिफ़्ट के लिए एक ही टिल login हो तो लॉग में नाम नहीं, सिर्फ़ "till" लिखा मिलता है।
• लावारिस एक्सेस। पूर्व कर्मचारी का account, या उसका बनाया API key, महीनों बाद भी चलता रहता है।

यहाँ ज़्यादातर नुकसान किसी नाटकीय हमले से नहीं होता। वह छोटे, बार-बार होने वाले, अनदेखे कामों से होता है, जो ऐसे व्यक्ति ने किए जिसे उनकी इजाज़त थी। नुकसान के सारे रास्तों में भीतर वाला रास्ता वही है जिसे रिटेलर सबसे बेहतर तरीके से क़ाबू में रख सकता है।

रोल, permission और स्कोप: तीन अलग चीज़ें

रोल-आधारित एक्सेस कंट्रोल तब तक अमूर्त लगता है, जब तक उसे हिस्सों में न बाँटा जाए। permission एक चीज़ पर एक क्रिया है: refund.issue, refund.approve, stock.adjust, customer.export। रोल किसी काम से मेल खाते permission का नाम वाला समूह है: कैशियर, शिफ़्ट लीड, अकाउंटेंट। और स्कोप बताता है कि रोल कहाँ लागू होगा: एक outlet, एक गोदाम, या हर जगह।

असली इकाई रोल नहीं, असाइनमेंट है। "सना outlet 2 की शिफ़्ट लीड है" एक पंक्ति है: user, रोल, स्कोप, शुरू की तारीख और चाहें तो ख़त्म होने की तारीख़। सना को outlet 3 भेजते ही पंक्ति बदल जाती है; outlet 2 का एक्सेस चुपचाप उसके पास नहीं रह जाता।

व्यवहार में न्यूनतम अधिकार

न्यूनतम अधिकार (least privilege) का मतलब है कि किसी व्यक्ति के पास उतने ही permission हों जितने आज का काम करने के लिए चाहिए। NIST SP 800-53 के AC-6 कंट्रोल में यही कहा गया है: system तय कामों के लिए ज़रूरी सबसे सीमित अधिकार ही लागू करे। रिटेल system में यह तीन आदतों में उतरता है।

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

काम का बँटवारा: जो जोड़ियाँ एक हाथ में नहीं रहनी चाहिए

न्यूनतम अधिकार तय करता है कि एक व्यक्ति क्या कर सकता है। काम का बँटवारा (segregation of duties) तय करता है कि वह अकेले क्या कर सकता है। NIST AC-5 इसे ऐसे बताता है: काम अलग-अलग लोगों में बाँटे जाएँ ताकि अधिकार के दुरुपयोग के लिए मिलीभगत ज़रूरी हो जाए। तरीक़ा सीधा है: उन काम-जोड़ियों की सूची बनाइए जिन्हें एक व्यक्ति के पास होने पर नुकसान किया या छिपाया जा सकता है, फिर system से उस मेल को रुकवाइए।

ये चार बंद जोड़ियाँ किसी भी कॉमर्स कारोबार का ज़्यादातर पैसा कवर कर लेती हैं। जो supplier बना सकता है और उसी को भुगतान भी कर सकता है, वह फ़र्ज़ी vendor खड़ा कर सकता है। जो refund जारी भी करे और मंज़ूर भी, जैसे हमारा सोमवार वाला कैशियर, वह अपना काम खुद पास कर लेता है। payroll बदलना और payroll चलाना भी इसी साँचे का है। और stock एडजस्ट करना तथा उसे सही ठहराने वाली गिनती खुद मंज़ूर करना, इसी तरह कमी ग़ायब हो जाती है।

यह नियम software को काम के वक़्त लागू करना चाहिए, सिर्फ़ पॉलिसी के दस्तावेज़ में नहीं। "मंज़ूर करने वाला अनुरोध करने वाले से अलग user होना चाहिए", इस जाँच में लॉजिक की एक पंक्ति लगती है, और इससे समस्या की एक पूरी श्रेणी ख़त्म हो जाती है।

संवेदनशील कामों को सिर्फ़ login नहीं, एक गेट चाहिए

login साबित करता है कि आप कौन हैं। यह साबित नहीं करता कि यह ख़ास काम वाजिब है। कुछ चुनिंदा कामों के लिए, जैसे refund, प्राइस ओवरराइड, तय सीमा से ऊपर की छूट, stock एडजस्टमेंट, ग्राहक data का एक्सपोर्ट और payroll रन, एक ऐसा गेट जोड़िए जो रकम देखकर फ़ैसला करे।

नीचे के फ़्लो में थ्रेशोल्ड उदाहरण के तौर पर हैं। अपने थ्रेशोल्ड इस आधार पर चुनिए कि आपके कारोबार में एक ग़लती की क़ीमत कितनी है।

इस फ़्लो की तीन बारीकियाँ दिखने से ज़्यादा मायने रखती हैं।

1. permission की जाँच में स्कोप भी शामिल है। "refund.issue है" काफ़ी नहीं। सवाल यह है कि "outlet 2 पर refund.issue है या नहीं"।
2. मंज़ूरीकर्ता का मिलान अनुरोधकर्ता से होता है, सिर्फ़ permission से नहीं। शिफ़्ट लीड अपना ही refund मंज़ूर नहीं कर सकता।
3. इनकार भी लॉग होता है। जो कैशियर एक हफ़्ते में 400 डॉलर का refund चार बार करने की कोशिश करे और हर बार रोका जाए, वह कोशिश अपने आप में जानकारी है। सिर्फ़ सफलताएँ लिखेंगे तो यह खो जाएगी।

सबसे ऊँचे स्तर के लिए, यहाँ 300 डॉलर से ऊपर, दो मंज़ूरीकर्ता रखिए, जैसे outlet मैनेजर और फ़ाइनेंस का कोई व्यक्ति। स्तर कम रखिए। तीन स्तर काउंटर पर समझाए जा सकते हैं; सात हों तो लोग उनका तोड़ निकाल लेते हैं।

तीन outlet वाले रिटेलर के लिए रोल template

यह तालिका शुरुआती बिंदु है, कोई मानक नहीं। "अपना" का मतलब है कि permission सिर्फ़ user के तय outlet पर लागू है। "अनुरोध" का मतलब है कि व्यक्ति काम शुरू कर सकता है, पर मंज़ूरी किसी और को देनी होगी।

permission	कैशियर	शिफ़्ट लीड	outlet मैनेजर	stock क्लर्क	अकाउंटेंट	मालिक
काउंटर पर बिक्री	अपना	अपना	अपना	नहीं	नहीं	सभी
50 डॉलर तक refund जारी करना	अपना	अपना	अपना	नहीं	नहीं	सभी
50 से 300 डॉलर का refund मंज़ूर करना	नहीं	अपना	अपना	नहीं	नहीं	सभी
300 डॉलर से ऊपर का refund मंज़ूर करना	नहीं	नहीं	अपना (दो में पहला)	नहीं	दूसरा मंज़ूरीकर्ता	सभी
प्राइस ओवरराइड	नहीं	अनुरोध	अपना, तय प्रतिशत के भीतर	नहीं	नहीं	सभी
stock एडजस्ट करना	नहीं	नहीं	नहीं	अपना	नहीं	सभी
stock गिनती मंज़ूर करना	नहीं	नहीं	अपना	नहीं	हाँ	सभी
supplier बनाना	नहीं	नहीं	नहीं	नहीं	नहीं	सभी
supplier को भुगतान	नहीं	नहीं	नहीं	नहीं	हाँ	नहीं
ग्राहक सूची एक्सपोर्ट करना	नहीं	नहीं	नहीं	नहीं	नहीं	सभी
user और रोल मैनेज करना	नहीं	नहीं	नहीं	नहीं	नहीं	सभी, दूसरे मालिक की मंज़ूरी के साथ

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

audit रिकॉर्ड में क्या होना ही चाहिए

audit लॉग बाद में एक सवाल का जवाब देता है: किसने, किस रिकॉर्ड पर, कब, क्यों और किसकी इजाज़त से क्या किया। "refund प्रोसेस हुआ" लिखी एक पंक्ति यह जवाब नहीं देती। ऊपर के फ़्लो वाले 184 डॉलर के refund का रिकॉर्ड यह रहा।

फ़ील्ड	उदाहरण	क्यों ज़रूरी है
रिकॉर्ड आईडी और समय	R-20931, 09:41:07 UTC	क्रम और खोज के लिए। UTC में सहेजें, स्थानीय समय में दिखाएँ।
कर्ता	cashier-07 (नाम वाला user, कभी "till" नहीं)	जवाबदेही
काम और लक्ष्य	order 48211 पर refund.issue	कौन-सा रिकॉर्ड बदला
कहाँ	outlet 2, रजिस्टर 3, डिवाइस और IP	स्कोप और असामान्य लोकेशन की जाँच
रकम और कारण	$184.00, कारण-कोड "damaged"	कारण के हिसाब से पैटर्न का विश्लेषण
पहले और बाद	payment कैप्चर होकर वापस; stock +1, return बिन में	असर का सबूत
लागू नियम	"50 से 300 डॉलर का refund: एक मंज़ूरीकर्ता"	उस वक़्त कौन-सी पॉलिसी लागू थी, यह दिखाता है
मंज़ूरीकर्ता और समय	lead-02, 09:42:31 UTC	दूसरे व्यक्ति के होने का सबूत
नतीजा	पूरा हुआ	सफल, इनकार या ख़ारिज
पिछला हैश और अपना हैश	7f3a…c91e	छेड़छाड़ की पहचान

छेड़छाड़ की पहचान, रिटेंशन और समीक्षा

जिस लॉग को admin बदल सकता है, उसका सबूत के तौर पर वज़न कम है। दो सस्ते उपाय काम आते हैं। पहला, टेबल को एप्लिकेशन के लिए append-only बनाइए: अपडेट या डिलीट की इजाज़त नहीं, और सुधार नई पंक्ति के रूप में लिखे जाएँ। दूसरा, रिकॉर्ड को कड़ी में जोड़िए। हर पंक्ति अपनी सामग्री और पिछली पंक्ति के हैश को मिलाकर SHA-256 हैश रखती है, इसलिए पुरानी पंक्ति बदलते ही उसके बाद के सारे हैश टूट जाते हैं। लॉग की कॉपी हर रात ऐसे स्टोरेज में रखिए जहाँ एप्लिकेशन लिख न सके।

रिटेंशन आपके नियमों पर निर्भर है। एक संदर्भ के तौर पर, PCI DSS v4.0.1 की आवश्यकता 10.5.1 audit लॉग का इतिहास कम से कम 12 महीने रखने को कहती है, जिसमें हाल के तीन महीने विश्लेषण के लिए तुरंत उपलब्ध हों। इसके ऊपर आपके टैक्स, payroll और प्राइवेसी नियम क्या माँगते हैं, यह देखिए, और अवधि लिखकर रखिए।

आख़िरी सवाल: इसे पढ़ेगा कौन? जिस लॉग को कोई नहीं देखता, वह डायरी है। outlet से बाहर के एक नामित व्यक्ति को, जैसे फ़ाइनेंस लीड या मालिक को, ज़िम्मा दीजिए और उन्हें तीन सेव किए हुए व्यू दीजिए: user के हिसाब से refund, हाथ से किए stock एडजस्टमेंट और एक्सपोर्ट। हफ़्ते के दस मिनट काफ़ी हैं, सोमवार के कैशियर को सोमवार से पहले पकड़ लेने के लिए।

नए जुड़ने वाले, बदली वाले और जाने वाले

एक्सेस की ज़्यादातर समस्याएँ हमले से नहीं, नौकरी बदलने के मौक़ों से शुरू होती हैं। इन तीनों मौक़ों को तय क्रम वाली रूटीन की तरह चलाइए।

नया जुड़ने वाला: मैनेजर template से रोल माँगता है, रोल का ज़िम्मेदार व्यक्ति मंज़ूरी देता है, और व्यक्ति पहले इस्तेमाल से पहले दूसरा साइन-इन फ़ैक्टर चालू करता है। बदली वाला: पहले पुराना रोल हटाइए, फिर नया जोड़िए। यही क्रम permission जमा होने से रोकता है। जाने वाला: account बंद कीजिए (मिटाइए नहीं, इतिहास बना रहना चाहिए), सेशन ख़त्म कीजिए, साझा कोड और API key बदलिए, और अटकी हुई मंज़ूरियाँ किसी और को सौंपिए।

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

तिमाही एक्सेस समीक्षा, क़दम दर क़दम

हर रोल असाइनमेंट की पुष्टि कम से कम एक तय अंतराल पर किसी इंसान को करनी चाहिए। PCI DSS 7.2.4 स्कोप वाले system के लिए अधिकतम अंतराल छह महीने रखता है; जिस रिटेलर के यहाँ कर्मचारी ज़्यादा बदलते हैं, उसके लिए हर तीन महीने बेहतर लय है। ठीक से तैयारी हो तो समीक्षा में एक घंटा लगता है।

1. सारे असाइनमेंट एक्सपोर्ट कीजिए: user, रोल, स्कोप, शुरू और ख़त्म की तारीख़, आख़िरी साइन-इन।
2. हर outlet मैनेजर को उसके लोकेशन की सूची भेजिए और हर पंक्ति पर हाँ या ना माँगिए।
3. जिन account में 60 दिन से साइन-इन नहीं हुआ, और जो अब कर्मचारी नहीं हैं, उन्हें हटाइए।
4. ऊपर के मैट्रिक्स की किसी बंद जोड़ी के दोनों हिस्से जिसके पास हों, उसे चिह्नित कीजिए।
5. "सभी outlet" वाले हर स्कोप की सूची बनाइए और मालिक से नाम लेकर दोबारा मंज़ूरी लीजिए।
6. दर्ज कीजिए कि किसने समीक्षा की, कब की और क्या बदला। समीक्षा खुद एक audit रिकॉर्ड है।

क्या मापें

कुछ संख्याएँ बता देती हैं कि कंट्रोल काम कर रहे हैं या नहीं, और किसी के लिए dashboard प्रोजेक्ट की ज़रूरत नहीं।

• खुद मंज़ूर किए संवेदनशील काम: लक्ष्य शून्य। शून्य से ऊपर का हर आँकड़ा ऐसा नियम है जिसे लाँघा जा सकता है।
• जाने वाले का account बंद करने में लगा समय: लक्ष्य उसी दिन, और बेहतर होगा एग्ज़िट बातचीत से पहले।
• 60 दिन में साइन-इन न करने वाले account: हर तिमाही शून्य की ओर घटें।
• user के हिसाब से refund दर, उसी outlet के साथियों से तुलना में। अलग दिखने वाला आँकड़ा सवाल है, फ़ैसला नहीं।
• हफ़्ते में ठुकराई गई कोशिशें: कुछ सामान्य हैं, एक ही व्यक्ति से अचानक झुंड आए तो बात करने लायक़ है।

सोमवार की सुबह पर वापसी

अब इन कंट्रोल के साथ शुरुआती दृश्य दोबारा चलाइए। कैशियर के रोल में बिक्री और 50 डॉलर तक का refund है। 184 डॉलर का refund एक शिफ़्ट लीड के पास जाता है, जो कोई दूसरा व्यक्ति है, और system वही login दो बार नहीं मानता। वीकेंड वाली पदोन्नति पर ख़त्म होने की तारीख़ है, इसलिए वह सोमवार को ही लैप्स हो जाती है।

41 refund पहले की तरह नहीं होते। कुछ फिर भी संदिग्ध रहें तो मालकिन उन्हें हफ़्ते की दस मिनट की समीक्षा में पकड़ लेती हैं, क्योंकि हर refund के साथ user, नियम, मंज़ूरीकर्ता और हैश जुड़ा है। अब वे नुकसान की खोज नहीं करतीं, एक report पढ़ती हैं।

मुख्य बातें

• permission, रोल और स्कोप को अलग रखिए, और एक्सेस को शुरू और ख़त्म की तारीख़ वाले असाइनमेंट की तरह चलाइए।
• न्यूनतम अधिकार लागू कीजिए और हर रोल का स्कोप डिफ़ॉल्ट रूप से एक लोकेशन का रखिए।
• चार पुरानी कॉन्फ़्लिक्ट जोड़ियाँ software में बंद कीजिए: supplier बनाना और भुगतान, refund जारी और मंज़ूर, payroll बदलना और चलाना, stock एडजस्ट और मंज़ूर।
• संवेदनशील कामों पर रकम के हिसाब से गेट लगाइए, जाँचिए कि मंज़ूरीकर्ता अनुरोधकर्ता नहीं है, और सफलता के साथ इनकार भी लॉग कीजिए।
• audit लॉग को append-only और हैश-चेन वाला बनाइए, उसे उतने समय तक रखिए जितना आपके नियम कहें, और एक नामित व्यक्ति को साप्ताहिक समीक्षा दीजिए।
• जुड़ने, बदली और विदाई के क़दम तय क्रम में चलाइए, और हर तिमाही सारे एक्सेस की समीक्षा कीजिए।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।