متطلبات أمن منصة HSE: ما الذي تضعه تقنية المعلومات في كراسة الشروط

ما الذي يجعل أمن نظام السلامة مختلفًا؟

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

ابدأ الملحق بهذا الجدول بعد تعبئته بفئات بياناتك، فهو يشرح للموردين لماذا تطلب ما تطلبه، ويمنحك أساسًا لترتيب الأولويات. ثم اكتب المتطلبات بالصيغة التالية: رمز، ونص المتطلب، والأولوية (M إلزامي، S مهم، C مرغوب كما في قالب كراسة متطلبات نظام HSE)، وطريقة التحقق: عرض حي، أو وثيقة، أو إجابة استبيان، أو اختبار في البيئة التجريبية.

متطلبات أمن منصة HSE في الهوية والدخول

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

في منصتنا تذكر صفحة الأمن والاستضافة هذه الضوابط بأسمائها: MFA «إلزامي للأدوار الحساسة حسب السياسة»، وSSO «بحساب المنشأة»، وSession Management «مهلة الجلسة، وإنهاء الجلسات، وتقييد الأجهزة»، وPassword Policies «التعقيد والانتهاء وحظر المحاولات المتكررة». وتذكر صفحة العمل الميداني الأجهزة اللوحية المشتركة مع «تسجيل دخول سريع لكل مستخدم أو وضع الإبلاغ العام». أما SEC-ID-08 بتفاصيل الحماية من الإرسال الآلي فاطلب وصفه مكتوبًا من كل مورد.

الصلاحيات وسجل التدقيق: من يرى ماذا وكيف يُثبت

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

صفحة المستخدمين والصلاحيات تصف هذا النموذج في المنصة بأبعاده: الدور، والنطاق في الهيكل، ونوع السجل، والحقول، مع Audit Logs «بالقيم قبل وبعد» وLogin History وActions History وApprovals History، وتقرير دوري بالمستخدمين وصلاحياتهم. والسبب الذي تذكره الصفحة هو جوهر SEC-AC-04: بعد حادث جسيم يكون السؤال الأول من اعتمد التصريح ومتى، وهل عُدّل التقييم بعد الحادث. أما تصدير السجلات إلى أداة بعينها لديك فاكتبه سؤالًا ينتظر وصف المورد.

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

لا تكتب «تشفير قوي». اكتب أين يُطلب التشفير، ومن يدير المفاتيح، وما الذي يُسجل عن كل اتصال برمجي.

في المنصة تذكر صفحة الأمن «تشفير البيانات أثناء النقل وفي التخزين»، وAPI Security بـ«مصادقة وصلاحيات وتشفير وسجل وحدود استخدام». وتفاصيل مثل إدارة المفاتيح وحماية البيانات المحلية على الجوال تُطلب في الاستبيان الأمني لكل مورد، ومنها منصتنا. متطلبات التكامل نفسها، من مصدر الحقيقة إلى معالجة الأخطاء، تفصلها متطلبات التكامل لنظام EHS.

الاستضافة ومكان البيانات والنسخ والاستعادة

هذه المتطلبات تختلف باختلاف نوع النشر، فاكتبها مشروطة به بدل أن تفرض صيغة واحدة على الجميع.

المنصة تتيح ثلاثة خيارات نشر كما في صفحة الأمن: Cloud مُدار بالكامل، أو Private Cloud مخصصة للمنشأة وحدها، أو On-Premise على خوادم المنشأة تحت إدارة تقنية المعلومات لديها، مع خيار استضافة داخل المملكة في الخيارين السحابيين. وتذكر الصفحة «نسخ احتياطي دوري واختبار للاستعادة» و«خطة تعافٍ بأهداف استعادة يُتفق عليها». فإن كان التثبيت على خوادمك، فمسؤوليات النسخ والتحديث والوصول عن بعد تتغير، وتفصيلها في متطلبات نظام HSE On-Premise.

اختبار الاختراق وإدارة الثغرات: كيف تكتبه متطلبًا

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

1. من ينفذ ونطاقهيذكر المورد إن كان يجري اختبار اختراق للتطبيق وواجهاته وتطبيق الجوال، ومن ينفذه (فريق داخلي أم جهة مستقلة)، ودوريته، وآخر تاريخ أُجري فيه.
2. ما يُشارك مع المنشأةملخص النتائج حسب الخطورة وحالة معالجتها، دون اشتراط تسليم التقرير الكامل إن كانت سياسة المورد تمنع ذلك؛ المهم أن تعرف أن الثغرات العالية عولجت.
3. مهل المعالجةمهلة معالجة لكل درجة خطورة يقترحها المورد وتُكتب في العقد، مع إعادة اختبار بعد المعالجة.
4. اختبار المنشأة نفسهاهل يحق لفريق المنشأة أو جهة تكلفها اختبار البيئة التجريبية؟ وبأي شروط وإشعار مسبق؟ في On-Premise يصبح هذا جزءًا من سياستك أصلًا.

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

الحوادث الأمنية: الإبلاغ والسجلات والتعاون

في السحابة لن تكتشف بنفسك اختراقًا في بنية المورد، وفي On-Premise قد تحتاج المورد لتحليل ما حدث في التطبيق. في الحالتين، ما يهمك أن يصلك الخبر مبكرًا ومعه ما يكفي لتقييم الأثر.

المهلة في SEC-IR-01 تحددها أنت لا المورد، لأنها مشتقة من التزاماتك تجاه الجهات المختصة والأشخاص المعنيين. منصة حوكمة البيانات الوطنية لحماية البيانات الشخصية لدى سدايا تتيح خدمة إشعار تسرب البيانات الشخصية؛ حدد مع الشؤون القانونية ما يلزمك ومتى، ثم اكتب مهلة المورد بحيث تسبق التزامك بوقت كافٍ.

حماية البيانات الشخصية: ما يُطلب من المورد بصفته معالجًا

المنشأة هي من تقرر لماذا تجمع بيانات عمالها الصحية وكيف تستخدمها، والمورد يعالجها نيابة عنها في أغلب الحالات. تحديد الصفة النظامية لكل طرف مسؤولية الشؤون القانونية، لكن الكراسة يجب أن تطلب من المورد ما يمكّنك من الوفاء بالتزاماتك:

• SEC-PD-01: اتفاقية معالجة بيانات تحدد الغرض والنطاق، وتمنع استخدام بياناتك لأي غرض آخر لدى المورد.
• SEC-PD-02: قائمة بالأطراف التي يستعين بها المورد في المعالجة أو الاستضافة، وإشعار مسبق بأي تغيير فيها.
• SEC-PD-03: لا نقل للبيانات الشخصية خارج المكان المتفق عليه إلا بموافقة مكتوبة ووفق الأحكام المنظمة لنقل البيانات خارج المملكة كما تحددها الشؤون القانونية لديك.
• SEC-PD-04: مبدأ الحد الأدنى من الاطلاع مطبق في النظام، مع إمكانية تقليل الحقول المجمعة لكل نموذج.
• SEC-PD-05: القدرة على استخراج بيانات شخص معين أو تصحيحها أو حذفها ضمن ما تسمح به سياسات الاحتفاظ، لتمكين المنشأة من التعامل مع طلبات أصحاب البيانات.
• SEC-PD-06: عند انتهاء العقد: تصدير كامل بصيغ قياسية يشمل المرفقات، ثم حذف موثق للبيانات لدى المورد.
• SEC-PD-07: المساعد الذكي، إن وُجد، يعمل ضمن صلاحيات المستخدم نفسه، ويوضح المورد أين تُعالج البيانات عند استخدامه.

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

المرجعية النظامية: كيف تذكر ضوابط الهيئة دون سطر عام

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

• الضوابط الأساسية للأمن السيبراني (ECC 2-2024) إن كانت منشأتك من الجهات المشمولة بها أو تتبناها سياسةً داخلية.
• ضوابط الأمن السيبراني للحوسبة السحابية (CCC-2:2024) إن كان النشر سحابيًا، وهي بحسب الهيئة امتداد للضوابط الأساسية وتحدد المتطلبات من منظور مقدمي الخدمات والمشتركين معًا.

ثم حوّل ما ينطبق إلى جدول مطابقة يرفق بالكراسة: عمود بالضابط كما يحدده فريقك، وعمود بالمتطلب المقابل في الملحق (SEC-ID-02 مثلًا)، وعمود يملؤه المورد: كيف يحقق الضابط، وما الدليل، وما الذي يبقى على المنشأة بصفتها مشتركًا أو مالكًا للبنية. بهذه الطريقة يصبح الإطار النظامي متطلبات قابلة للتحقق، ويتضح ما يقع على المورد وما يبقى عليك. ولا تقبل في الرد عبارة «متوافق مع الضوابط» دون هذا الجدول.

سيناريو: شركة تعدين تعيد كتابة ملحقها الأمني

كيف تقيّم الردود الأمنية دون أن تغرق في الاستبيانات

الملحق الأمني الجيد يولّد ردودًا طويلة. لا تقرأها كلها بالدرجة نفسها من العمق:

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

الأسئلة الشفهية التي تطرحها تقنية المعلومات في الجلسات مكمّلة لهذا الملحق، وتجدها في أسئلة لمزود نظام السلامة، وطريقة صياغة بقية متطلبات الكراسة في كتابة RFP لنظام HSE.

الأسئلة الشائعة

اقرأ أيضًا