مراجعات صلاحيات المستخدمين التي تُرضي كل مدقق
تُعد مراجعات الصلاحيات من أكثر الضوابط إخفاقاً في عمليات التدقيق، ونادراً ما يكون السبب عدم إجرائها، بل غالباً عدم قدرة أحد على إثبات أنها أُجريت بالشكل الصحيح.
تغطي هذه المقالة الأطر 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 من النوع الثاني، فتأكد من أن مراجعة واحدة على الأقل (ويفضل اثنتان) تقع ضمن كل فترة مراقبة.
ما يجده المدققون
- الاعتماد الآلي دون فحص: اعتماد كل الحسابات في دقائق من شخص لا يمكنه أن يعرف تفاصيلها.
- مجتمعات غير مكتملة: شملت المراجعة التطبيق دون قاعدة البيانات، أو الحسابات البشرية دون حسابات الخدمات.
- المراجعة الذاتية: مسؤولون يعتمدون صلاحياتهم الخاصة.
- عمليات إلغاء لم تكتمل: نصّت المراجعة على الإلغاء، لكن الحساب ما زال موجوداً بعد شهور.
- مغادرون تكشفهم المراجعة: مؤشر على فشل عملية إنهاء الخدمة، وسيختبرها المدققون بشكل منفصل.
أبرز النقاط
- تفشل المراجعات في التدقيق بسبب الأدلة لا الجهد: مجتمعات غير مكتملة، ومراجعة ذاتية، وإلغاءات لم تُنفَّذ.
- استخدم تصديراً من النظام، ومراجعاً مناسباً، وقراراً لكل حساب، وإثباتاً للتغييرات.
- المراجعات كل ستة أشهر (قاعدة PCI DSS)، وربع سنوية للوصول المميز، تلبي كل الأطر.
- اقصر النطاق على الأنظمة المهمة، وأتمت الإجراءات التشغيلية.
جعلها مستدامة
أتمت التصدير والتذكيرات، وراجع حسب النظام لا حسب المستخدم، واقصر النطاق على الأنظمة المهمة: الإنتاج وبيانات العملاء والأدوات المميزة وكل ما يندرج ضمن نطاق أي إطار. مراجعة أصغر حجماً وموثّقة جيداً أفضل من مراجعة واسعة تتأخر دائماً.
راجع صفحات الموضوع التحكم في الوصول والوصول المميز لكل متطلب مع مصدره، ومقالتنا عن إعادة استخدام الأدلة عبر SOC 2 وISO 27001 وPCI DSS.
الأسئلة
ما مدى تكرار مراجعة صلاحيات المستخدمين؟
يشترط PCI DSS مراجعة حسابات المستخدمين وصلاحيات الوصول مرة واحدة على الأقل كل ستة أشهر (7.2.4). تشترط معظم الأطر الأخرى مراجعة دورية وفق تكرار تحدده المؤسسة؛ والمعيار الشائع هو المراجعة ربع السنوية للوصول المميز، والمراجعة كل ستة أشهر لبقية الصلاحيات.
من ينبغي أن يُجري مراجعة الصلاحيات؟
مالك النظام أو البيانات، أو مدير المستخدم، وليس المسؤول الذي منح الصلاحية. يبحث المدققون عن الاستقلالية ووجود مراجع على دراية كافية.
هل تحتاج حسابات الخدمات إلى مراجعة الصلاحيات؟
نعم. يُدرج المدققون بصورة متزايدة حسابات الخدمات والحسابات المشتركة وحسابات واجهات البرمجة ضمن مجتمع المراجعة، كما يشترط 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يغطي نظام ISMS وفق ISO 27001 تقريباً كل فقرة من CPS 234 الصادر عن APRA، ومع ذلك تضيف APRA واجبات على مجلس الإدارة، وتأكيداً من أطراف ثالثة، ومواعيد إخطار صارمة.
التحليل · 2026-10-13متطلبات MFA مقارنةً عبر 11 إطارًا أمنيًاأي الأطر تتطلب MFA، ولمن، وبأي درجة من الصرامة: مقارنة جنبًا إلى جنب لـ PCI DSS وCMMC وNIS2 وEssential Eight وISO 27001 وSOC 2 وHIPAA.
التحليل · 2026-09-29قاعدة الأمن في HIPAA من منظور إطار NIST CSF 2.0يغطي برنامج NIST CSF 2.0 تقريبًا كل متطلب من متطلبات قاعدة الأمن في HIPAA. ما الذي ينتقل كما هو، والمتطلبان اللذان لا يتطابقان معهما، وما الذي يضيفه CSF فوق HIPAA.