متطلبات الأمن السيبراني في أنظمة الموافقات الإلكترونية

لماذا يأتي الأمن قبل المزايا

نظام الموافقات ليس أداة إنتاجية فحسب؛ إنه مستودع للقرارات المالية والإدارية لمنشأتك. من يعتمد صرف مليون ريال، ومن فوّض من، ومتى وُقّع العقد — كل هذا يعيش داخل النظام. لو تسرّب أو عُدّل دون أثر، فأنت لا تفقد بيانات فقط، بل تفقد القدرة على إثبات أن قراراتك سليمة.

الخطأ الشائع في الشراء أن تُقيّم النظام بواجهته وسهولته، ثم تكتشف بعد التشغيل أن سجل التدقيق قابل للتعديل، أو أن البيانات مستضافة خارج المملكة. تصحيح هذه الفجوات بعد التشغيل مكلف وأحيانًا مستحيل. لذلك تُكتب المتطلبات الأمنية في كراسة الشروط كبنود قابلة للقياس، لا كأمنيات.

المصادقة وإدارة الهوية

الباب الأول لأي اختراق هو هوية مسروقة. كلمة مرور وحدها لم تعد كافية لنظام يعتمد صرفيات ويحمل بيانات موظفين. اشترط أن يدعم النظام طبقات هوية واضحة، لا وعودًا عامة بـ«الأمان».

ما تطلبه تحديدًا

• مصادقة متعددة العوامل (MFA) إلزامية لكل من يملك صلاحية اعتماد، لا اختيارية.
• الدخول الموحّد (SSO) عبر الربط مع Active Directory، ليُدار المستخدمون من مصدر واحد.
• سياسة كلمات مرور قابلة للضبط: طول أدنى، تعقيد، ومنع إعادة الاستخدام.
• قفل الحساب بعد محاولات فاشلة متتالية، مع تنبيه لمسؤول الأمن.
• إدارة الجلسات: انتهاء تلقائي عند الخمول، وإنهاء الجلسة عند تغيير كلمة المرور.

الربط مع مزوّد الهوية المركزي ليس رفاهية؛ فهو يضمن أن الموظف المغادر يُوقف وصوله فورًا من مكان واحد، بدلًا من تتبّع حساباته في كل نظام على حدة. هذه النقطة وحدها تغلق أكثر ثغرات المغادرين شيوعًا.

الحسابات ذات الصلاحيات العالية

حسابات مديري النظام هي الجائزة الكبرى لأي مهاجم، لأنها تصل إلى كل شيء. اشترط معاملة خاصة لها: مصادقة متعددة العوامل بلا استثناء، تسجيل كامل لكل ما تفعله، وفصلها عن حسابات الاستخدام اليومي. مدير النظام الذي يتصفح بريده بالحساب نفسه الذي يدير به الخوادم يضاعف سطح الخطر دون داعٍ. حدّد عدد هذه الحسابات، وراجعه دوريًا، واجعل كل استخدام لها مبررًا وموثّقًا.

التشفير وحماية البيانات

التشفير يحمي البيانات في حالتين: أثناء انتقالها عبر الشبكة، وأثناء تخزينها على الخوادم. غياب أيّ منهما يترك ثغرة. اشترط تشفير النقل عبر TLS 1.2 فأعلى لكل الاتصالات، وتشفير التخزين لقواعد البيانات والمرفقات والنسخ الاحتياطية.

اسأل المورّد صراحةً: أين تُدار مفاتيح التشفير، ومن يملك الوصول إليها؟ للتوسع في هذا الجانب راجع تشفير بيانات نظام سير العمل. التشفير يساعد على حماية البيانات الشخصية بما يدعم متطلبات نظام حماية البيانات الشخصية، لكنه جزء من منظومة لا بديل عنها.

الصلاحيات وسجل التدقيق

مبدأ الحد الأدنى من الصلاحية أساس الأمن: كل مستخدم يرى ويفعل ما يلزم دوره فقط، لا أكثر. اشترط تحكمًا في الوصول قائمًا على الأدوار (RBAC) يفصل بين من يقدّم الطلب ومن يعتمده ومن يدير النظام. للتفصيل راجع إدارة الأدوار والصلاحيات RBAC.

سجل التدقيق — البند الذي لا يُساوَم عليه

سجل التدقيق يوثّق كل حدث: من دخل، ماذا عدّل، من اعتمد، ومتى — بختم زمني وهوية. الشرط الحاسم أن يكون غير قابل للتعديل حتى من مدير النظام. اسأل هذا السؤال في التقييم: هل يستطيع مدير النظام حذف أو تعديل سطر في السجل؟ الإجابة المقبولة الوحيدة هي «لا».

• سجل شامل يغطي الدخول والاعتماد والتفويض وتغيير الصلاحيات.
• غير قابل للتعديل ويُحفظ منفصلًا عن بيانات التشغيل.
• قابل للتصدير للمدققين دون منحهم صلاحية تشغيلية.
• مرتبط بالوقت الرسمي عبر مصدر توقيت موثوق.

اشترط أيضًا مراجعة دورية للصلاحيات، وتوثيق كل تغيير عليها. راجع تسجيل تغييرات الدخول والصلاحيات وسجل التدقيق لفهم أعمق.

الاستضافة والنسخ الاحتياطي

مكان البيانات قرار سيادي قبل أن يكون تقنيًا. للجهات الحكومية والمنشآت الكبيرة، اشترط استضافة بيانات الموافقات داخل المملكة لدى مزوّد معتمد، مع وضوح تام حول من يصل إليها. للتوسع راجع استضافة بيانات الموافقات داخل السعودية والسحابة مقابل الاستضافة الداخلية.

النسخ الاحتياطي والتعافي من الكوارث

النظام الذي لا يُستعاد بسرعة بعد عطل هو مخاطرة تشغيلية. حدّد في الكراسة مؤشرين رقميين: RPO (أقصى بيانات يُقبل فقدها) وRTO (أقصى زمن للعودة). اطلب نسخًا آلية مجدولة، مخزّنة في موقع منفصل، وجرّب الاستعادة دوريًا لا مرة واحدة عند التركيب.

• نسخ آلية يومية على الأقل، مشفّرة ومنفصلة جغرافيًا.
• اختبار استعادة دوري موثّق، لأن نسخة لم تُختبر ليست نسخة.
• خطة تعافي مكتوبة بأدوار ومسؤوليات واضحة.
• سياسة احتفاظ تحدد مدة حفظ البيانات ثم إتلافها بأمان.

للمزيد راجع النسخ الاحتياطي والتعافي من الكوارث وسياسة الاحتفاظ بالوثائق.

المراقبة وتأمين الواجهات البرمجية

الأمن لا يكتمل عند التركيب؛ إنه عملية مستمرة. اشترط مراقبة فعلية تكشف السلوك غير الطبيعي قبل أن يتحول إلى حادث: محاولات دخول فاشلة كثيرة، تصدير غير معتاد للبيانات، أو تغيير صلاحيات خارج ساعات العمل.

• مراقبة وتنبيه على الأحداث الأمنية الحرجة في الوقت الفعلي.
• تأمين الواجهات البرمجية (API) بمفاتيح ومصادقة وحدود معدل الطلبات.
• تحصين الخوادم بإغلاق المنافذ غير اللازمة وتحديث مستمر.
• فصل البيئات بين الإنتاج والاختبار، فلا بيانات حقيقية في بيئة تجربة.
• اختبار اختراق دوري من جهة مستقلة، مع خطة معالجة للثغرات.

الواجهات البرمجية بوابة قوية وخطيرة في آن: هي ما يربط نظام الموافقات بالموارد البشرية والنظام المالي، وهي أيضًا سطح هجوم إن تُركت مكشوفة. راجع أهمية الواجهات البرمجية في سير العمل لفهم كيف تُؤمَّن دون أن تُعطّل التكامل.

انتبه أيضًا إلى مدة حفظ سجلات الأحداث الأمنية. سجل يُمسح بعد أسبوع لا يفيد في تحقيق يبدأ بعد شهر. حدّد في الكراسة مدة احتفاظ واضحة بسجلات الدخول والتغييرات، متسقة مع سياسة الاحتفاظ العامة، وتأكد أنها محمية من الحذف والتعديل. المراقبة بلا سجل محفوظ لمدة كافية تكشف الحادث لكنها لا تساعد على تحليله ولا إثباته لاحقًا.

مثال تطبيقي — اعتماد تغيير أمني

المتطلبات السابقة تظهر قيمتها في موقف حقيقي. تخيّل جهة حكومية يطلب فيها مهندس أنظمة فتح منفذ خارجي على خادم إنتاج لربط خدمة جديدة. هذا التغيير حساس: منفذ مفتوح خطأً قد يكون بوابة اختراق. لذا يمر عبر مسار اعتماد صارم بدلًا من رسالة بريد:

ما الذي أضافه النظام هنا؟ ليس التعقيد، بل الأثر والفصل. مسؤول أمن المعلومات يقيّم الأثر قبل الاعتماد، ورئيس الأمن السيبراني يعتمد كطرف منفصل عن طالب التغيير — تطبيقًا لفصل المهام. وعند أي مراجعة لاحقة، السجل يجيب: من طلب، من قيّم، من اعتمد، ومتى نُفّذ.

لاحظ أن التغيير لا يُنفَّذ إلا بعد اكتمال المسار كاملًا، فلا يستطيع مهندس واحد فتح منفذ حساس بقراره المنفرد مهما كانت صلاحيته التقنية. هذا الفصل بين القدرة التقنية على التنفيذ والصلاحية الإدارية على الاعتماد هو جوهر تأمين التغييرات الحساسة. وحين يقترن بمراقبة تكشف أي تغيير نُفِّذ خارج هذا المسار، تكتمل الحلقة: كل تغيير إما معتمَد وموثّق، وإما ينبّه النظام إليه فورًا باعتباره شذوذًا يستحق التحقيق.

هذا النموذج نفسه ينطبق على طلبات الوصول للأنظمة؛ راجع طلبات الوصول لأنظمة تقنية المعلومات لمسار مكمّل.