cm/controlmapping
हिन्दी
स्रोत
चरण-दर-चरण मार्गदर्शिका · SOC 2 · ISO 27001 · PCI DSS · HIPAA · CMMC

हर ऑडिटर को संतुष्ट करने वाली उपयोगकर्ता एक्सेस समीक्षाएँ

एक्सेस समीक्षाएँ ऑडिट में सबसे अधिक बार विफल होने वाले नियंत्रणों में से एक हैं, और इसका कारण शायद ही यह होता है कि उन्हें किसी ने किया नहीं, बल्कि आम तौर पर यह होता है कि कोई यह साबित नहीं कर पाता कि वे ठीक से की गई थीं।

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

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

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

फ़्रेमवर्क की आवश्यकताएँ क्या हैं

फ़्रेमवर्कएक्सेस कंट्रोललिंक
NIST CSF 2.0PR.AA-01PR.AA-05विषय परिभाषा
ISO 27001A.5.15A.5.16A.5.18A.8.3क्रॉसवॉक
CIS v8.1CIS 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 2CC6.1CC6.2CC6.3संपादकीय
PCI DSS7.2.17.2.27.2.48.2.1क्रॉसवॉक
CMMCAC.L2-3.1.1AC.L2-3.1.2क्रॉसवॉक
800-53AC-2AC-3क्रॉसवॉक
HIPAA§164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d)क्रॉसवॉक
GDPRArt.25(2)Art.32(1)(b)संपादकीय
NIS211.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) और न्यूनतम विशेषाधिकार लागू हो।

ऐसी समीक्षा जो पास हो

  1. पूरी जनसंख्या। उपयोगकर्ता सूची सीधे सिस्टम से निकालें (निर्यात, न कि कोई स्प्रेडशीट जिसे कोई मैन्युअल रूप से रखता हो), जिसमें सेवा और साझा खाते भी शामिल हों।
  2. सही समीक्षक। सिस्टम या डेटा का स्वामी, या हर उपयोगकर्ता का प्रबंधक, न कि वह प्रशासक जिसने एक्सेस दिया था।
  3. पर्याप्त संदर्भ। समीक्षकों को हर उपयोगकर्ता की भूमिका और एक्सेस स्तर दिखाएँ, ताकि "स्वीकृत" एक सूचित निर्णय हो।
  4. हर खाते पर एक निर्णय। रखें, बदलें या हटाएँ, समीक्षक का नाम और तारीख के साथ।
  5. बदलाव वास्तव में किए गए। हटाने के लिए टिकट बनाएँ और यह प्रमाण रखें कि वे पूरे हुए।
  6. साक्ष्य सुरक्षित रखें। निर्यात, निर्णय, टिकट और अनुमोदन, सब एक साथ संग्रहीत।
लकड़ी की मेज़ पर पुरानी चाबियों के एक बड़े गुच्छे की फ़ोटो, साथ में एक छोटी खाली नोटबुक
एक्सेस चुपचाप जमा होता रहता है; समीक्षाएँ ही उसे छाँटती हैं।

आवृत्ति

सभी दायरे में आने वाले सिस्टमों के लिए 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 परिणाम साझा करता है: जाँचने योग्य है, मैपिंग नहीं · हमारे डेटा में कोई मैपिंग नहीं हमारे डेटा में कुछ भी मैप नहीं है; अक्सर यह नया काम होता है, पर कवरेज नोट्स जाँच लें. यह अनुपालन सलाह नहीं है।

संबंधित पोस्ट

विश्लेषण · 2026-10-27APRA CPS 234 और ISO 27001: आपका ISMS क्या कवर करता है और APRA क्या जोड़ता हैISO 27001 ISMS APRA के CPS 234 के लगभग हर अनुच्छेद को कवर करता है, फिर भी APRA बोर्ड की जिम्मेदारियाँ, तृतीय पक्ष आश्वासन और सख़्त सूचना समय-सीमाएँ जोड़ता है।विश्लेषण · 2026-10-1311 सुरक्षा फ़्रेमवर्क में MFA आवश्यकताओं की तुलनाकौन-से फ़्रेमवर्क MFA की आवश्यकता रखते हैं, किन उपयोगकर्ताओं के लिए और कितनी सख़्ती से: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 और HIPAA की साथ-साथ तुलना।विश्लेषण · 2026-09-29NIST CSF 2.0 के नज़रिये से HIPAA सुरक्षा नियमNIST CSF 2.0 कार्यक्रम लगभग हर HIPAA सुरक्षा नियम आवश्यकता से मैप होता है। क्या आगे ले जाया जा सकता है, वे दो जो नहीं होतीं, और HIPAA से परे CSF क्या जोड़ता है।