التحكم في الوصول في معيار SACS-210 لا يعني فقط إنشاء كلمات مرور أو تفعيل المصادقة متعددة العوامل. المطلوب هو وجود عملية متكاملة تحدد من هو المستخدم، وكيف تتم مصادقته، وما الموارد التي يسمح له بالوصول إليها، ومتى يجب تعديل صلاحياته أو إلغاؤها، وكيف تثبت المنشأة أن هذه الضوابط تعمل فعلياً.
بالنسبة للمنشآت السعودية الصغيرة، لا يعني ذلك بناء منظومة IAM معقدة كالتي تستخدمها المؤسسات الكبرى. المطلوب هو وجود إدارة مركزية ومنضبطة وقابلة للإثبات للهوية والصلاحيات تتناسب مع حجم البيئة التقنية وتحقق متطلبات SACS-210.
المتطلبات العامة الأساسية الخاصة بإدارة الهوية والمصادقة والتحكم في الوصول هي TPC1.9 إلى TPC1.15. وترتبط بها متطلبات أخرى تشمل سياسة إدارة الوصول، انضمام الموظفين ومغادرتهم، الوصول إلى بيانات الـProponent، تسجيل الأحداث، وإلغاء بيانات اعتماد الـProponent.
وللنظرة الأوسع على الحوكمة والمسؤوليات وربط المتطلب بالدليل، راجع دليل GRC في المتطلبات العامة لـSACS-210.
الخلاصة: كيف يعمل التحكم في الوصول وفق SACS-210؟
يمكن تلخيص النموذج العملي كالتالي:
الهوية ← المصادقة ← منح الصلاحية ← المراجعة ← إلغاء الوصول ← الأدلة
ويجب أن تستطيع المنشأة الإجابة بوضوح عن الأسئلة التالية:
- من هو المستخدم؟
- كيف يتم التحقق من هويته؟
- ما الأنظمة والبيانات التي يستطيع الوصول إليها؟
- من وافق على هذه الصلاحيات؟
- ماذا يحدث عند تغيير وظيفته أو مشروعه؟
- ماذا يحدث عند انتهاء الحاجة إلى الوصول؟
- ما الأدلة التي تثبت أن هذه الإجراءات مطبقة فعلياً؟
لا يفرض SACS-210 منتجاً تجارياً محدداً لإدارة الهوية.
قد يكون دليل المستخدمين المركزي جزءاً من الحل، لكن صلاحيات المستخدمين على الأنظمة والتطبيقات يجب أن تتم إدارتها من خلال قدرة مركزية لإدارة الهوية والوصول (IAM).
التقنية المستخدمة يمكن أن تختلف، لكن النتيجة المطلوبة واحدة: وصول مركزي، مصادقة آمنة، صلاحيات مقيدة، وأدلة قابلة للتحقق.
متطلبات التحكم في الوصول في SACS-210
| المتطلب | المطلوب عملياً |
|---|---|
| TPC1.9 | إدارة مركزية للهوية والصلاحيات وفق الحاجة إلى المعرفة والاستخدام، وأقل صلاحية، والفصل بين المهام |
| TPC1.10 | بيانات اعتماد مصادقة فريدة لكل مستخدم |
| TPC1.11 | قواعد كلمات المرور ورموز المصادقة |
| TPC1.12 | فرض MFA في حالات وصول محددة |
| TPC1.13 | السماح بـSSO بشرط MFA عند تسجيل الدخول الأول |
| TPC1.14 | مراجعة حسابات المستخدمين وصلاحيات الوصول مرة سنوياً على الأقل |
| TPC1.15 | استخدام آليات مصادقة آمنة للأصول التقنية |
وينص المعيار أيضاً على أن سياسات الأمن السيبراني يجب أن تشمل إدارة الوصول، وأن عملية الانضمام والمغادرة الموثقة تشمل إزالة حقوق الوصول. كما يقصر TPC1.7 مشاركة بيانات الـProponent على الأفراد المشاركين في العمل المحدد بالعقد.
ويمكن مراجعة معيار SACS-210 للأمن السيبراني للأطراف الخارجية للاطلاع على النص الكامل للمتطلبات العامة والخاصة.
الإدارة المركزية وأقل صلاحية — TPC1.9
يتطلب TPC1.9 إدارة صلاحيات المستخدمين للأنظمة والتطبيقات من خلال حل مركزي مؤسسي لإدارة الهوية والوصول.
ويجب أن تعتمد الصلاحيات على:
- هوية المستخدم؛
- الحاجة إلى المعرفة؛
- الحاجة إلى الاستخدام؛
- مبدأ أقل صلاحية؛
- الفصل بين المهام.
بمعنى آخر، لا يحصل الموظف على صلاحية لأنه قد يحتاجها مستقبلاً أو لأنها أكثر راحة لفريق تقنية المعلومات، بل لأن هناك حاجة عمل فعلية ومحددة.
يمكن أن تكون عملية منح الصلاحية في منشأة صغيرة بسيطة:
المستخدم ← المورد المطلوب ← سبب العمل ← مستوى الصلاحية ← الموافقة ← التنفيذ
لا تحتاج طبقة الطلب والموافقة بالضرورة إلى منصة Governance كبيرة. يمكن استخدام نموذج معتمد أو تذكرة خدمة أو Workflow موثق.
لكن هذه الأدوات لا تحل محل IAM نفسه. الموافقة توثق سبب منح الصلاحية، بينما يجب أن تتم إدارة الصلاحيات الفعلية مركزياً في النظام أو منصة الهوية.
ويجب أيضاً تجنب منح صلاحيات Administrator للمستخدمين العاديين ما لم تكن هناك حاجة فعلية ومبررة.
الحسابات الفريدة وكلمات المرور — TPC1.10 وTPC1.11
يتطلب TPC1.10 أن تتم مصادقة المستخدم بناءً على بيانات اعتماد فريدة.
لذلك يجب أن يكون الموظف أو المتعاقد قابلاً للتعريف من خلال حسابه الشخصي، بدلاً من استخدام حساب تفاعلي واحد يشترك فيه عدة أشخاص.
الحسابات الفريدة تساعد على ربط النشاط الأمني بالشخص الذي قام به، مثل:
- تسجيل الدخول؛
- تغيير البيانات؛
- تعديل الصلاحيات؛
- تنفيذ إجراءات إدارية.
أما الحسابات التقنية أو Service Accounts فيجب التعامل معها وفق وظيفتها ومخاطرها، وعدم الخلط بينها وبين مشاركة عدة موظفين لحساب مستخدم عادي.
أما TPC1.11 فيحدد، حيثما كان ذلك ممكناً، قواعد لكلمات المرور ورموز المصادقة تشمل:
- كلمات مرور أو عبارات مرور بطول 8 إلى 64 حرفاً؛
- أحرفاً صغيرة؛
- أحرفاً كبيرة؛
- أرقاماً؛
- رموزاً خاصة؛
- استخدام MFA؛
- عدم استخدام تلميحات لكلمات المرور.
ويجب أن تتطابق السياسة المكتوبة مع الإعدادات التقنية المطبقة فعلياً.
إذا كانت السياسة تقول إن كلمات المرور القوية إلزامية، بينما يسمح النظام بإعدادات أضعف، فإن السياسة وحدها لا تثبت التنفيذ.
ومن المهم أيضاً أن TPC1.11 لا يحدد تغيير كلمة المرور كل 30 أو 60 أو 90 يوماً. يمكن للمنشأة تطبيق ضوابط إضافية، ولكن لا ينبغي نسبتها إلى SACS-210 وكأنها متطلب صريح.
كذلك لا ينبغي تفسير عبارة where feasible في TPC1.11 على أنها تجعل MFA اختيارياً، لأن TPC1.12 يحدد بشكل مستقل حالات يجب فيها فرض MFA صراحة.
المصادقة متعددة العوامل وSSO — TPC1.12 وTPC1.13
يتطلب TPC1.12 فرض المصادقة متعددة العوامل (MFA) على خمس حالات:
- الوصول عن بُعد، بما في ذلك الوصول من الإنترنت.
- الخدمات السحابية.
- الوصول إلى بريد الشركة عبر الويب أو الأجهزة المحمولة.
- التطبيقات المواجهة للإنترنت.
- المستخدمون ذوو الحسابات ذات الصلاحيات المرتفعة.
وبالتالي لا يكفي أن تقول المنشأة:
لدينا MFA.
السؤال الصحيح هو:
هل MFA مفروضة فعلياً على جميع حالات TPC1.12 التي تنطبق على بيئتنا؟
| الحالة | ما الذي يجب التحقق منه؟ |
|---|---|
| الوصول عن بُعد | VPN أو وسيلة الوصول المعتمدة تتطلب MFA |
| الخدمات السحابية | الوصول إلى الخدمات السحابية المشمولة يتطلب MFA |
| البريد الإلكتروني | الوصول عبر الويب والجوال محمي بـMFA |
| التطبيقات الخارجية | دخول المستخدم إلى التطبيقات المواجهة للإنترنت يتطلب MFA |
| الحسابات المميزة | حسابات الإدارة والصلاحيات المرتفعة تتطلب MFA |
ويجب التمييز بين تسجيل المستخدم في MFA وفرض MFA.
قد يكون المستخدم قد أضاف تطبيق مصادقة أو هاتفاً أو رمزاً أمنياً، لكن بعض مسارات تسجيل الدخول قد تظل متاحة دون عامل ثانٍ. لذلك يجب أن يثبت الدليل أن MFA مفروضة، لا أنها متاحة فقط.
أما TPC1.13 فيسمح باستخدام تسجيل الدخول الموحد (SSO) بشرط أن يكون مرتبطاً بـMFA عند تسجيل الدخول الأول.
SSO يساعد على تبسيط وإدارة المصادقة مركزياً، لكنه ليس بديلاً عن MFA.
مراجعة الصلاحيات ومصادقة الأصول — TPC1.14 وTPC1.15
يتطلب TPC1.14 مراجعة حسابات المستخدمين وحقوق الوصول مرة واحدة سنوياً على الأقل.
الهدف هو اكتشاف الحسابات أو الصلاحيات التي لم تعد مناسبة، مثل:
- حسابات غير مستخدمة؛
- حسابات موظفين غادروا المنشأة؛
- صلاحيات إدارية لم تعد مطلوبة؛
- وصول أوسع من الحاجة الفعلية؛
- عضويات Groups لم تعد مرتبطة بوظيفة المستخدم؛
- صلاحيات قديمة بقيت بعد تغيير الوظيفة أو المشروع.
المراجعة الجيدة لا تنتهي باكتشاف المشكلة فقط، بل يجب أن ينتج عنها إجراء تصحيحي.
مثال:
الملاحظة: موظف انتقل إلى وظيفة جديدة وما زال يمتلك صلاحية Administrator.
الإجراء: إزالة الصلاحية غير الضرورية.
الدليل: سجل مراجعة الوصول بالإضافة إلى الإعداد الجديد بعد التصحيح.
وهنا يجب تثبيت الفرق المهم:
TPC1.14 = مراجعة الحسابات وحقوق الوصول.
أما TPC1.15 فهو متطلب مختلف، ويشترط استخدام آليات مصادقة آمنة لجميع الأصول التقنية التابعة للطرف الثالث.
وقد تشمل هذه الأصول، بحسب البيئة:
- أجهزة المستخدمين؛
- الخوادم؛
- التطبيقات؛
- أجهزة الشبكة؛
- أنظمة الحماية؛
- واجهات الإدارة.
التحكم في الوصول طوال دورة حياة الموظف
إدارة الوصول لا تنتهي عند إنشاء الحساب.
النموذج العملي هو:
انضمام ← موافقة ← إنشاء الصلاحية ← تغيير الدور ← مراجعة ← مغادرة ← إلغاء الوصول
يركز هذا القسم على جانب إدارة الوصول من TPC1.4. أما المتطلب الكامل فيشمل كذلك عناصر أوسع مثل الفحوصات السابقة للتوظيف وإعادة الأصول عند المغادرة.
عند الانضمام
عند انضمام موظف أو متعاقد جديد، يجب أن تستند الصلاحيات إلى حاجة عمل موثقة.
عملية بسيطة يمكن أن تشمل:
- تحديد الموظف ودوره؛
- تحديد الأنظمة المطلوبة؛
- الحصول على الموافقة؛
- إنشاء هوية فريدة؛
- إضافة الأدوار أو المجموعات المطلوبة؛
- تفعيل MFA حيثما يلزم؛
- الاحتفاظ بسجل التنفيذ.
عند تغيير الوظيفة أو المشروع
عند انتقال الموظف إلى قسم أو مشروع أو مسؤولية جديدة، لا ينبغي الاكتفاء بإضافة صلاحيات جديدة.
يجب التحقق من:
- هل ما زالت الصلاحيات القديمة مطلوبة؟
- ما الصلاحيات الجديدة المطلوبة؟
- هل يجب إزالة عضويات سابقة؟
- هل ظهرت مشكلة في الفصل بين المهام؟
- هل أصبح المستخدم يمتلك صلاحيات مرتفعة؟
هذا يقلل من تراكم الصلاحيات مع مرور الوقت.
عند المغادرة
يشمل TPC1.4 إزالة حقوق الوصول ضمن عملية المغادرة الموثقة.
وقد يشمل ذلك:
- حساب الهوية المؤسسي؛
- البريد الإلكتروني؛
- الخدمات السحابية؛
- VPN والوصول عن بُعد؛
- تطبيقات الأعمال؛
- المجلدات المشتركة؛
- الحسابات ذات الصلاحيات المرتفعة.
المهم أن تكون عملية إلغاء الوصول موثقة ومنظمة وليست اعتماداً على ذاكرة موظف في تقنية المعلومات.
بيانات اعتماد الـProponent — TPC1.33
عندما يكون للموظف بيانات اعتماد مستخدم مقدمة من الـProponent، يضيف TPC1.33 متطلباً آخر.
يجب إخطار الـProponent عندما لا يعود الموظف بحاجة إلى هذا الوصول، بما في ذلك حالات:
- النقل؛
- إعادة التعيين؛
- التقاعد؛
- انتهاء ارتباط الموظف بالطرف الثالث.
وهذا يعني أن المنشأة قد تحتاج إلى تنفيذ عمليتين منفصلتين:
إلغاء الوصول الداخلي
و
إخطار الـProponent بشأن بيانات الاعتماد الخارجية
إلغاء حساب الموظف داخل بيئة المنشأة لا يعني بالضرورة إلغاء حساب خارجي تديره جهة أخرى.
تقييد الوصول إلى بيانات الـProponent — TPC1.7
ينص TPC1.7 على أن بيانات الـProponent لا تتم مشاركتها إلا مع الأفراد المشاركين في العمل المحدد بالعقد.
وهذا متطلب Authorization وليس مجرد Authentication.
قد يكون الموظف يعمل لدى المنشأة بشكل نظامي، لكنه لا يحتاج إلى الوصول إلى مشروع أو مستودع مستندات أو نظام معين تابع للعقد.
يمكن تنفيذ ذلك من خلال:
- تحديد الأشخاص المشاركين في العمل التعاقدي؛
- تقييد الوصول إلى المجلدات والتطبيقات؛
- استخدام Roles أو Groups عند الحاجة؛
- إزالة الوصول عند انتهاء مشاركة الشخص في المشروع.
الفرق ببساطة:
المصادقة: من أنت؟
منح الصلاحية: هل يحق لك الوصول إلى هذا المورد؟
نموذج عملي لمنشأة سعودية صغيرة
يمكن بناء نموذج فعال دون تعقيد زائد من خلال سبع ممارسات:
1. إدارة الهوية والصلاحيات مركزياً
استخدم IAM مؤسسياً لإدارة الهويات والوصول إلى الأنظمة والتطبيقات.
2. حساب فريد لكل مستخدم
يجب أن يكون كل موظف أو متعاقد قابلاً للتعريف بشكل مستقل.
3. توثيق الموافقة على الوصول
احتفظ بسبب الطلب، والصلاحية المطلوبة، والشخص الذي وافق عليها.
4. تطبيق أقل صلاحية
لا تمنح صلاحيات إدارية أو مرتفعة إلا عند وجود حاجة فعلية.
5. فرض MFA في نطاق TPC1.12
تحقق من الوصول عن بُعد، والخدمات السحابية، والبريد الإلكتروني، والتطبيقات المواجهة للإنترنت، والحسابات المميزة.
6. ربط تغييرات الموظفين بتغييرات الوصول
التوظيف، والنقل، وإعادة التعيين، والمغادرة يجب أن تؤدي إلى إجراءات واضحة في أنظمة الوصول.
7. مراجعة الصلاحيات والاحتفاظ بالأدلة
نفذ المراجعة السنوية وسجل ما تمت مراجعته وما تم تصحيحه.
لا يجب أن تكون العملية بيروقراطية، لكنها يجب أن تكون:
منظمة، متكررة، وقابلة للإثبات.
ويمكن لفرق تقنية المعلومات ومقدمي الخدمات المدارة استخدام قائمة التنفيذ التقني لمعيار SACS-210 كمرجع عملي أوسع للإعدادات التقنية والتحقق منها.
ما الأدلة التي ينبغي الاحتفاظ بها؟
يحدد SACS-210 المتطلبات، ثم تحتاج المنشأة خلال التقييم إلى إثبات أن الضوابط موجودة وتعمل في البيئة الفعلية.
الأمثلة التالية أمثلة عملية للأدلة وليست قائمة ثابتة تنطبق على كل بيئة أو كل شركة تدقيق.
| المتطلب | التنفيذ | أمثلة على الأدلة |
|---|---|---|
| TPC1.9 | IAM مركزي وأقل صلاحية | إعدادات IAM، الأدوار والمجموعات، موافقات الوصول |
| TPC1.10 | حسابات فريدة | سجلات المستخدمين في Directory أو IAM |
| TPC1.11 | قواعد المصادقة وكلمات المرور | إعدادات كلمات المرور والمصادقة |
| TPC1.12 | فرض MFA | Policies والإعدادات وعينات من الحسابات |
| TPC1.13 | SSO مع MFA | إعدادات SSO ومزود الهوية |
| TPC1.14 | المراجعة السنوية | تقرير المراجعة، الموافقات، الملاحظات والمعالجة |
| TPC1.15 | مصادقة الأصول | إعدادات المصادقة للأصول ذات الصلة |
| TPC1.4 | الانضمام والمغادرة | سجلات onboarding وoffboarding |
| TPC1.33 | إلغاء بيانات اعتماد الـProponent | سجل الإلغاء والإخطار |
الفكرة الأساسية هي:
السياسة ≠ التنفيذ التقني ≠ العملية التشغيلية ≠ الدليل
وجود سياسة تقول إن MFA إلزامية لا يثبت أنها مفعلة.
وصورة إعداد MFA لا تثبت أن المنشأة تلغي حسابات الموظفين عند مغادرتهم.
أما الجاهزية الأقوى فتتحقق عندما تتطابق السياسة والإعدادات والعملية والسجلات.
ولتقييم الأدلة ضمن الصورة الأشمل للنطاق والوثائق والاستعداد للتحقق، راجع دليل جاهزية تدقيق أرامكو CCC.
تسجيل أحداث الوصول وإمكانية التتبع
يتطلب TPC1.31 تفعيل سجلات التدقيق والأحداث السيبرانية على الأنظمة والتطبيقات، والتقاط الأحداث المحددة في Appendix C. كما أن TPC1.33 يعالج انتهاء الحاجة إلى بيانات اعتماد الـProponent.
ومن الأحداث المرتبطة بالهوية والوصول:
- محاولات تسجيل الدخول الفاشلة؛
- عمليات تسجيل دخول ناجحة من مواقع جغرافية متباعدة خلال فترة قصيرة؛
- إضافة حسابات المستخدمين وحذفها؛
- رفع أو تعديل الصلاحيات؛
- نشاط الحسابات ذات الصلاحيات المرتفعة؛
- تغييرات الإعدادات أو السياسات الأمنية ذات الصلة.
ويجب عدم خلط المتطلبات الثلاثة التالية:
- TPC1.25: مزامنة الأصول التقنية مع مصدر وقت معتمد.
- TPC1.26: حماية سجلات الأحداث من التعديل أو الحذف أو الوصول غير المصرح به.
- TPC1.31: تفعيل سجلات التدقيق والأحداث السيبرانية.
أين يأتي Microsoft Entra ID؟
Microsoft Entra ID أحد الحلول التقنية التي يمكن استخدامها لتنفيذ أجزاء من إدارة الهوية والوصول.
وقد يدعم، بحسب الترخيص والإعداد:
- إدارة الهويات؛
- المصادقة؛
- MFA؛
- SSO؛
- الأدوار والصلاحيات.
لكن:
استخدام Microsoft Entra ID لا يجعل المنشأة متوافقة تلقائياً مع SACS-210.
لا تزال المنشأة مسؤولة عن تحديد المتطلبات المطبقة، وضبط الإعدادات بشكل صحيح، وإدارة دورة حياة المستخدم، وفهم حدود الترخيص والمنتج، والاحتفاظ بالأدلة.
وسيكون تنفيذ Microsoft-specific موضوعاً مستقلاً في دليل Microsoft Entra ID لتطبيق متطلبات التحكم في الوصول في SACS-210.
أما هذا المقال فيبقى محايداً تقنياً ويركز على المتطلبات نفسها.
أخطاء شائعة في التحكم في الوصول
من أكثر الفجوات شيوعاً:
- وجود Directory مركزي دون عملية منظمة لمنح الصلاحيات؛
- اعتبار نموذج طلب الوصول بديلاً عن IAM؛
- تفعيل MFA للحسابات الإدارية فقط وإهمال بقية حالات TPC1.12؛
- تسجيل المستخدمين في MFA دون فرضها فعلياً؛
- تراكم الصلاحيات بعد انتقال الموظف بين الأدوار؛
- إجراء مراجعات وصول دون الاحتفاظ بسجلاتها؛
- الخلط بين TPC1.14 لمراجعة الوصول وTPC1.15 لمصادقة الأصول؛
- إلغاء الحساب الداخلي مع نسيان بيانات اعتماد الـProponent.
كثير من مشكلات التحكم في الوصول لا تكون بسبب نقص التقنية، بل بسبب عدم الترابط بين الإدارة والموارد البشرية وتقنية المعلومات والأنظمة التي تنفذ فيها الصلاحيات فعلياً.
من المتطلب إلى الدليل
يمكن استخدام النموذج التالي:
المتطلب ← المسؤول ← العملية ← التحكم التقني ← الدليل ← المراجعة
مثال على TPC1.14:
المراجعة السنوية لحقوق الوصول
← تحديد المسؤول عن المراجعة
← استخراج المستخدمين والصلاحيات الحالية
← التحقق منها مع المديرين أو ملاك الأنظمة
← إزالة الصلاحيات غير المطلوبة
← تسجيل الملاحظات والإجراءات التصحيحية
← الاحتفاظ بالمراجعة المكتملة
بهذا تصبح الأدلة نتيجة طبيعية للعمل اليومي، بدلاً من محاولة إعادة بناء كل شيء قبل التقييم مباشرة.
الخلاصة
التحكم الفعال في الوصول وفق SACS-210 لا يتطلب تعقيداً غير ضروري.
بالنسبة لمعظم المنشآت السعودية الصغيرة، الأساس هو:
إدارة الهويات والصلاحيات مركزياً، استخدام حسابات فريدة، فرض MFA في النطاق المطلوب، تطبيق أقل صلاحية، إدارة الوصول طوال دورة حياة الموظف، مراجعة الصلاحيات مرة سنوياً على الأقل، والاحتفاظ بأدلة تثبت أن هذه الضوابط تعمل فعلياً.
المتطلبات الأساسية هي TPC1.9 إلى TPC1.15، وتدعمها متطلبات أخرى خاصة بالسياسات، والانضمام والمغادرة، وبيانات الـProponent، والتسجيل، وبيانات الاعتماد الخارجية.
قد تختلف التقنية المستخدمة، لكن الهدف يبقى واحداً:
وصول منضبط، مصادقة آمنة، وأدلة قابلة للتحقق.
هل تحتاج مساعدة في متطلبات شهادة CCC لأرامكو؟
احصل على استشارة مجانية مع أحد خبرائنا.
علي الجبيلي
خبير سعودي رائد في مجال الأمن السيبراني وتقنية المعلومات، يتمتع بخبرة تزيد عن 20 عامًا في بناء برامج أمنية متكاملة للشركات السعودية الصغيرة والمتوسطة. متخصص في معيار أرامكو للأمن السيبراني للأطراف الثالثة (CCC)، والامتثال لمعايير الهيئة الوطنية للأمن السيبراني (NCA) الخاصة بأمن المعلومات، وتطبيق ضوابط أمنية تقنية للمؤسسات العاملة في قطاعات الإنشاءات والطاقة والتجارة.
