हर ऑडिटर को संतुष्ट करने वाली उपयोगकर्ता एक्सेस समीक्षाएँ
एक्सेस समीक्षाएँ ऑडिट में सबसे अधिक बार विफल होने वाले नियंत्रणों में से एक हैं, और इसका कारण शायद ही यह होता है कि उन्हें किसी ने किया नहीं, बल्कि आम तौर पर यह होता है कि कोई यह साबित नहीं कर पाता कि वे ठीक से की गई थीं।
यह पोस्ट उन 11 फ़्रेमवर्कों को कवर करती है जिन्हें इसके लिखे जाने के समय ControlMapping ने मानचित्रित किया था। तब से DORA, CPS 234, Cyber Essentials को 2026-10-27 पर जोड़ा गया है; उनके पृष्ठ और कवरेज मैट्रिक्स में वे शामिल हैं।

बहुत कम नियंत्रण उपयोगकर्ता एक्सेस समीक्षाओं जितने सार्वभौमिक हैं या उतनी ही बार विफल होते हैं। हर फ़्रेमवर्क अपेक्षा करता है कि कोई व्यक्ति समय-समय पर जाँच करे कि हर व्यक्ति को अब भी वह एक्सेस चाहिए या नहीं जो उसके पास है। अधिकांश संगठन समीक्षा करते हैं। लेकिन बहुत कम ही ऑडिटर को यह दिखा पाते हैं कि वह समीक्षा पूरी थी, स्वतंत्र थी और उस पर कार्रवाई हुई।
फ़्रेमवर्क की आवश्यकताएँ क्या हैं
| फ़्रेमवर्क | एक्सेस कंट्रोल | लिंक |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | विषय परिभाषा |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | क्रॉसवॉक |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | क्रॉसवॉक |
| SOC 2 | CC6.1CC6.2CC6.3 | संपादकीय |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | क्रॉसवॉक |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | क्रॉसवॉक |
| 800-53 | AC-2AC-3 | क्रॉसवॉक |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | क्रॉसवॉक |
| GDPR | Art.25(2)Art.32(1)(b) | संपादकीय |
| NIS2 | 11.111.211.5 | क्रॉसवॉक |
| Essential Eight | — | हमारे डेटा में कोई मैपिंग नहीं |
पूर्ण विवरण और हर संबंध का कारण: फ़्रेमवर्क में एक्सेस कंट्रोल →
PCI DSS एकमात्र ऐसा फ़्रेमवर्क है जिसमें निश्चित आवृत्ति तय है: सभी उपयोगकर्ता खातों और विशेषाधिकारों की कम से कम हर छह महीने में समीक्षा (7.2.4), और एप्लिकेशन व सिस्टम खातों की भी (7.2.5.1)। SOC 2 के ऑडिटर जाँचते हैं कि एक्सेस उचित रूप से अधिकृत, संशोधित और हटाया गया है (CC6.2, CC6.3), और साक्ष्य के रूप में नियमित समीक्षाएँ खोजते हैं। ISO 27001 के अनुसार एक्सेस अधिकारों की नियमित अंतराल पर समीक्षा होनी चाहिए (A.5.18)। HIPAA के लिए सूचना एक्सेस प्रबंधन और गतिविधि की समीक्षा आवश्यक है (§164.308(a)(4))। CMMC अपेक्षा करता है कि एक्सेस केवल अधिकृत उपयोगकर्ताओं और कार्यों तक सीमित हो (AC.L2-3.1.1, 3.1.2) और न्यूनतम विशेषाधिकार लागू हो।
ऐसी समीक्षा जो पास हो
- पूरी जनसंख्या। उपयोगकर्ता सूची सीधे सिस्टम से निकालें (निर्यात, न कि कोई स्प्रेडशीट जिसे कोई मैन्युअल रूप से रखता हो), जिसमें सेवा और साझा खाते भी शामिल हों।
- सही समीक्षक। सिस्टम या डेटा का स्वामी, या हर उपयोगकर्ता का प्रबंधक, न कि वह प्रशासक जिसने एक्सेस दिया था।
- पर्याप्त संदर्भ। समीक्षकों को हर उपयोगकर्ता की भूमिका और एक्सेस स्तर दिखाएँ, ताकि "स्वीकृत" एक सूचित निर्णय हो।
- हर खाते पर एक निर्णय। रखें, बदलें या हटाएँ, समीक्षक का नाम और तारीख के साथ।
- बदलाव वास्तव में किए गए। हटाने के लिए टिकट बनाएँ और यह प्रमाण रखें कि वे पूरे हुए।
- साक्ष्य सुरक्षित रखें। निर्यात, निर्णय, टिकट और अनुमोदन, सब एक साथ संग्रहीत।

आवृत्ति
सभी दायरे में आने वाले सिस्टमों के लिए PCI DSS की छह महीने की अवधि को आधार मानें, और विशेषाधिकार प्राप्त एक्सेस की समीक्षा तिमाही करें। यदि आपके पास SOC 2 Type II है, तो सुनिश्चित करें कि हर अवलोकन अवधि में कम से कम एक समीक्षा (आदर्श रूप से दो) आए।
ऑडिटर क्या पाते हैं
- बिना जाँचे मंज़ूरी (Rubber-stamping): हर खाता मिनटों में किसी ऐसे व्यक्ति द्वारा स्वीकृत, जो जानता ही नहीं था।
- अधूरी जनसंख्या: समीक्षा में एप्लिकेशन शामिल था पर डेटाबेस नहीं, या मानव खाते शामिल थे पर सेवा खाते नहीं।
- स्व-समीक्षा: प्रशासक अपने ही एक्सेस को स्वीकृत कर रहे हैं।
- हटाने का काम पूरा नहीं हुआ: समीक्षा में हटाने को कहा गया, पर खाता महीनों बाद भी मौजूद है।
- समीक्षा में पकड़े गए छोड़कर जाने वाले कर्मचारी: यह संकेत है कि आपकी ऑफ़बोर्डिंग प्रक्रिया विफल हो रही है, जिसे ऑडिटर अलग से जाँचेंगे।
मुख्य बिंदु
- समीक्षाएँ प्रयास के बजाय साक्ष्य पर विफल होती हैं: अधूरी जनसंख्या, स्व-समीक्षा और कभी पूरे न हुए हटाने।
- सिस्टम निर्यात, सही समीक्षक, हर खाते पर एक निर्णय और बदलावों का प्रमाण उपयोग करें।
- छह-मासिक समीक्षाएँ (PCI DSS का नियम) और विशेषाधिकार प्राप्त एक्सेस के लिए तिमाही समीक्षाएँ हर फ़्रेमवर्क को संतुष्ट करती हैं।
- दायरा उन सिस्टमों तक सीमित रखें जो मायने रखते हैं, और प्रक्रियात्मक काम को स्वचालित करें।
इसे टिकाऊ बनाना
निर्यात और रिमाइंडर स्वचालित करें, उपयोगकर्ता के बजाय सिस्टम के अनुसार समीक्षा करें, और दायरा उन सिस्टमों तक रखें जो मायने रखते हैं: प्रोडक्शन, ग्राहक डेटा, विशेषाधिकार प्राप्त टूल और वह सब कुछ जो किसी फ़्रेमवर्क के दायरे में है। एक छोटी, अच्छी तरह साक्ष्य-आधारित समीक्षा उस बड़ी समीक्षा से बेहतर है जो हमेशा देर से होती है।
हर आवश्यकता और उसके स्रोत के लिए एक्सेस कंट्रोल और विशेषाधिकार प्राप्त एक्सेस विषय पृष्ठ देखें, और SOC 2, ISO 27001 और PCI DSS में साक्ष्य का पुनः उपयोग पर हमारा ब्लॉग पोस्ट भी देखें।
प्रश्न
उपयोगकर्ता एक्सेस की समीक्षा कितनी बार होनी चाहिए?
PCI DSS के अनुसार उपयोगकर्ता खातों और एक्सेस विशेषाधिकारों की कम से कम हर छह महीने में समीक्षा होनी चाहिए (7.2.4)। अधिकांश अन्य फ़्रेमवर्क आपके तय की गई आवृत्ति पर आवधिक समीक्षा माँगते हैं; विशेषाधिकार प्राप्त एक्सेस के लिए तिमाही और अन्यों के लिए हर छह महीने एक सामान्य आधार है।
एक्सेस समीक्षा कौन करे?
सिस्टम या डेटा का स्वामी, या उपयोगकर्ता का प्रबंधक, न कि वह प्रशासक जिसने एक्सेस दिया था। ऑडिटर स्वतंत्रता और सूचित समीक्षक की तलाश करते हैं।
क्या सेवा खातों की एक्सेस समीक्षा ज़रूरी है?
हाँ। ऑडिटर अब अधिकाधिक सेवा, साझा और API खातों को समीक्षा की जनसंख्या में शामिल कर रहे हैं; PCI DSS स्पष्ट रूप से एप्लिकेशन और सिस्टम खातों की नियमित समीक्षा अनिवार्य करता है (7.2.5.1)।
2026-10-27 तक का डेटा: इस पोस्ट के आँकड़े वर्तमान क्रॉसवॉक से गणना किए गए हैं और उसके बदलने पर अपडेट होते हैं। क्रॉसवॉक प्रकाशित क्रॉसवॉक (NIST, ENISA, CIS, PCI SSC) यह संबंध बनाता है · संपादकीय जहाँ कोई क्रॉसवॉक मौजूद नहीं है वहाँ ControlMapping का निर्णय; कारण दिखाया गया है · केवल एक CSF 2.0 परिणाम साझा करता है: जाँचने योग्य है, मैपिंग नहीं · हमारे डेटा में कोई मैपिंग नहीं हमारे डेटा में कुछ भी मैप नहीं है; अक्सर यह नया काम होता है, पर कवरेज नोट्स जाँच लें. यह अनुपालन सलाह नहीं है।