لماذا ملف الأدلة عاجل
دخل توجيه NIS2 حيز التنفيذ في يناير 2023، وكان الموعد النهائي لنقله إلى التشريع الوطني من قِبل دول الاتحاد الأوروبي في 17 أكتوبر 2024. وقد مُنحت الكيانات التي أُخطرت بعد هذا التاريخ عموماً مهلة 18 شهراً لتحقيق الامتثال، تنتهي في الوقت الحالي بالنسبة لمعظم المنظمات المعنية. انطلقت الموجة الأولى من إجراءات التطبيق في عدة دول أعضاء، وباتت السلطات المختصة تُوجّه طلبات رسمية للتوثيق.
لا يكتفي تدقيق NIS2 بالتحقق من وجود تدابير تقنية: بل يتطلب أدلة مؤرخة وقابلة للتتبع والإثبات. نظام مُهيَّأ بشكل صحيح لكنه غير موثق لن ينجح في التدقيق، وتقرير حادث بلا طابع زمني موثوق كذلك. لذا يُعدّ بناء ملف الأدلة مهمة مستقلة عن التوافق التقني ذاته، وتشمل مزود الاستضافة بقدر ما تشمل فرقك الخاصة.
ما تتناوله هذه المقالة
- نطاق المزود — ما يقع على عاتقه إثباته وما لا يستطيع إثباته نيابةً عنك
- سجلات الوصول والأمان — أي السجلات تطلب، وبأي شكل، ولأي مدة احتفاظ
- إدارة التصحيحات — تقارير الثغرات والتصحيحات المطبقة على البنية التحتية الأساسية
- SLA الأمني — البنود التعاقدية ذات الحجية في التدقيق
- خطة استمرارية الأعمال (BCP) — ما يوثقه المزود وما يجب أن تنتجه بنفسك
- تقرير الحادث — الجدول الزمني للإخطار وفق المادة 23 من NIS2 وسلسلة الأدلة الواجب إعادة تكوينها
- ما لا يستطيع المزود إثباته — الحد الفاصل الواضح بين البنية التحتية وسياسة أمان العميل
الحد الفاصل بين ما يثبته المزود وما يقع على عاتقك
أكثر اعتراض يرد في التدقيق: «مزود استضافتنا حاصل على شهادة ISO 27001، أيغطي ذلك امتثالنا لـNIS2؟» الجواب: لا، والتمييز بالغ الأهمية. يُثبت المزود أمان بنيته التحتية: مركز البيانات، وجهاز المراقبة الافتراضية، والشبكة، والإجراءات الداخلية لموظفيه. أما أنت فتثبت أمان ما تنشره فوقها: تطبيقاتك وبياناتك وضوابط وصولك وإجراءاتك.
تفرض المادة 21 من توجيه NIS2 تدابير على الكيان الخاضع للتوجيه، لا على مزود الاستضافة. يُمثّل المزود عنصراً في سلسلة توريدك (م.21.د): يجب أن توثق كيف قيّمت ممارساته الأمنية، وما البنود التعاقدية التي تحميك، وما آليات الإخطار بالحوادث التي يوفرها. ما لا يستطيع المزود إنتاجه نيابةً عنك إطلاقاً: خريطة أصولك، وسياسة الأمان المدوّنة، وتدريب فرقك، وإجراءك الخاص لإدارة الحوادث، وإثبات تشفير بياناتك التطبيقية وفق خياراتك.
توزيع المسؤوليات التوثيقية
مرّر الجدول أفقيًا
| المجال | ما يوثقه المزود | ما توثقه أنت |
|---|---|---|
| البنية التحتية المادية | شهادة مركز البيانات (ISO 27001، SOC 2)، ضبط الوصول المادي، الطاقة المكررة | اختيار مركز البيانات وتبرير الموقع الجغرافي للبيانات |
| الشبكة وجهاز المراقبة الافتراضية | سجلات تدفق الشبكة، عزل الأجهزة الافتراضية، تحديث المراقب الافتراضي | تهيئة جدار الحماية التطبيقي، قواعد الشبكة على جانب نظام التشغيل الضيف |
| إدارة التصحيحات | نشرات التصحيحات المطبقة على البنية التحتية، الثغرات المعالجة | تحديثات نظام التشغيل والاعتمادات التطبيقية وبيئة التشغيل |
| سجلات الوصول | الوصول إلى لوحة الإدارة، الإجراءات الإدارية على البنية التحتية | سجلات التطبيق وسجلات مصادقة SSH والوصول إلى قاعدة البيانات |
| حوادث الأمان | الإخطار ضمن مواعيد المادة 23 من NIS2، تقرير الحادث المتعلق بالبنية التحتية | تقرير الحادث الخاص بك، وأثره على بياناتك وخدماتك |
| استمرارية الأعمال | SLA التوفر، خطة استرداد البنية التحتية، نسخ لقطات الأجهزة الافتراضية الاحتياطية | RPO/RTO المحددة، اختبار استعادة التطبيق المدوّن، خطة الأزمات الموثقة |
| سياسة الأمان | سياسة الأمان الداخلية للمزود (تُقدَّم بناءً على الطلب التعاقدي) | سياسة أمان نظام المعلومات الخاص بك، خريطة الأصول، تدريب الفرق |
سجلات الوصول والأمان: ما يجب طلبه
السجلات هي أول ما يطلبه مدقق NIS2، إذ تتيح إعادة تكوين مسار الحادث (م.21.ب) وإثبات تطبيق ضوابط الوصول فعلياً. على VPS، تشمل سلسلة السجلات طبقتين: طبقة المزود (الوصول إلى لوحة الإدارة، والعمليات على البنية التحتية) وطبقتك الخاصة (نظام التشغيل الضيف، والتطبيقات).
من جانب المزود، السجلات الواجب طلبها صراحةً هي: أحداث تسجيل الدخول إلى لوحة الإدارة (بعنوان IP المصدر والطابع الزمني)، وعمليات تغيير حجم الأجهزة الافتراضية واللقطات وإعادة التثبيت، والتنبيهات الأمنية المكتشفة على مستوى البنية التحتية. يجب أن تكون هذه السجلات قابلة للتصدير بصيغة منظمة (JSON، CSV) وتغطي 90 يوماً على الأقل. أما سجلات المصادقة والإدارة فتوصي معظم CSIRT الوطنية بالاحتفاظ بها 12 شهراً.
على جانب VPS الخاص بك، يشمل الحد الأدنى المُوثَّق: مركزة سجلات auth.log نحو تخزين لا يستطيع حساب التطبيق تعديله، والاحتفاظ بسجلات Nginx/Apache مع ضبط تدوير يُبقي على 90 يوماً على الأقل، والتصدير إلى حل خارجي للحفاظ على سلامة السجلات في حالة اختراق الخادم.
الوثائق الواجب طلبها من المزود بشأن السجلات
- سجل الوصول إلى لوحة الإدارة — تصدير الاتصالات بعنوان IP المصدر والتاريخ والوقت والإجراء المنفذ، لمدة 12 شهراً على الأقل
- سجل عمليات البنية التحتية — إنشاء/حذف/تغيير حجم الأجهزة الافتراضية، واللقطات، وتعديلات تهيئة الشبكة
- سياسة الاحتفاظ الموثقة — مدة الاحتفاظ الرسمية بسجلات المزود، والتنسيق وإجراء التصدير
- تنبيهات أمان الشبكة — تقارير الشذوذات المكتشفة على مستوى البنية التحتية (عمليات المسح، ومحاولات التسلل الحدودي)
- إجراء الوصول إلى السجلات خلال الحوادث — القناة ووقت الاستجابة وتنسيق التسليم في حالات الطلب العاجل من مدقق أو جهة رسمية
إدارة التصحيحات: الأدلة على جانب المزود والعميل
تفرض المادة 21 من NIS2 تدابير لضمان الأمان في اقتناء الأنظمة وتطويرها وصيانتها. بالنسبة لـVPS، يشمل ذلك نطاقين متمايزين سيفحصهما المدقق بشكل منفصل.
من جانب المزود، العناصر الواجب طلبها هي: سياسة إدارة الثغرات المطبقة على المراقب الافتراضي والبنية التحتية للشبكة، والنشرات الأمنية الصادرة أو المرسلة للعملاء بشأن الثغرات الحرجة المؤثرة على البنية التحتية، ومواعيد نشر التصحيحات الحرجة المضمونة تعاقدياً. على ServOrbit، توثق سياسة إدارة تصحيحات البنية التحتية وتُبلَّغ عنها إبان الحوادث؛ يمكنك طلب نسخة رسمية لملف التدقيق.
على جانب العميل، يجب توثيق: وتيرة تحديثات نظام التشغيل (أسبوعية أو شهرية وفق سياستك)، وإدارة اعتمادات التطبيق (أداة المسح، وسجل الثغرات المعالجة)، والاختبارات المجراة قبل نشر أي تصحيح في الإنتاج. يُعدّ سجل تحديث مؤرخ وموقَّع — حتى في جدول بيانات — دليلاً صالحاً إذا جرى الاحتفاظ به بشكل منتظم.
بناء ملف أدلة NIS2: خطوات عملية
طلب ملف الامتثال للبنية التحتية من مزودك
قدّم طلباً مكتوباً لمزودك مع تحديد إطار NIS2 والعناصر المطلوبة: شهادة ISO 27001 أو SOC 2 سارية المفعول، ومواقع مراكز البيانات، وسياسة إدارة الثغرات، وإجراء الإخطار بالحوادث. على ServOrbit، يمكن طلب هذا الملف عبر الدعم مع الإشارة إلى مسار تدقيق NIS2 الخاص بك.
تدقيق سجلات وصول VPS وتصديرها
سجّل الدخول إلى لوحة إدارة ServOrbit وصدّر تاريخ الاتصالات والعمليات. على VPS ذاته، تحقق من تهيئة
logrotateلـauth.logوسجلات تطبيقاتك: يجب أن تتيح توجيهةrotateاحتفاظاً لا يقل عن 90 يوماً. هيّئ التصدير إلى تخزين خارجي باستخدامrsyslogأو عميل Loki إن لم يكن ذلك موجوداً — هذه الطريقة الوحيدة لإثبات سلامة السجلات عند اختراق الخادم.التحقق من البنود التعاقدية ذات الحجية وتوثيقها
أعد قراءة عقد الاستضافة بحثاً صريحاً عن: SLA التوفر مع غرامات قابلة للقياس، والتزامات الإخطار عند الحوادث الأمنية (الموعد والقناة)، ومدة الاحتفاظ بالسجلات وإجراء الوصول إليها أثناء التحقيق، وشروط التدقيق أو التفتيش من قِبل العميل أو ممثله، والتزامات الاستمرارية مع مقاييس قابلة للقياس (RTO، RPO).
إنتاج سياسة الأمان الموثقة الخاصة بك
لا يستطيع المزود إنتاج هذه الوثيقة نيابةً عنك. يجب أن تغطي كحد أدنى: خريطة الأصول الحرجة المستضافة، وقواعد إدارة الوصول (MFA إلزامي، ومفاتيح SSH، وسياسة تدوير الأسرار)، وسياسة النسخ الاحتياطي (التكرار والموقع واختبار الاستعادة)، والأشخاص المخوّلين بالوصول إلى البنية التحتية.
وضع خطة استمرارية الأعمال واختبارها
تغطي خطة الاستمرارية NIS2 مستويين: مستوى المزود (توفر البنية التحتية، وإجراء الإخفاق والتبديل) ومستواك أنت (إجراء استعادة التطبيق، وجهات الإحالة، وقرار التبديل). على ServOrbit، وثّق اللقطات التلقائية المتاحة وتكرارها ومدة احتفاظها، وأضف إجراء استعادتك المختبَر والمؤرخ.
إعداد إجراء الإخطار بالحوادث وفق NIS2
تفرض المادة 23 من التوجيه: تحذيراً مبكراً للسلطة الوطنية المختصة في غضون 24 ساعة من اكتشاف الحادث المهم، وإخطاراً رسمياً في غضون 72 ساعة يتضمن تقييماً أولياً للأثر والسبب المحتمل، وتقريراً نهائياً في غضون شهر. حدد كتابةً: من هو المسؤول عن الإخطار، وما عتبة الأهمية المعتمدة، وأي قناة تُستخدم.
تهيئة النسخ الاحتياطية مع إثبات اختبار الاستعادة
على ServOrbit، تغطي اللقطات التلقائية طبقة الجهاز الافتراضي. للطبقة التطبيقية، هيّئ نسخة احتياطية منفصلة تُصدَّر إلى تخزين كائنات خارجي (متوافق مع S3). وثّق كل اختبار استعادة: التاريخ، والنسخة المستعادة، والمدة، والنتيجة. جدول في ملف مُصنَّف إصدار (git) يُعدّ أثراً صالحاً. التكرار الأدنى الموصى به لاختبار الاستعادة الكاملة هو ربع سنوي.
التحقق من سلسلة التوريد (م. 21.د)
أحصِ جميع الموردين الذين يصلون إلى بنيتك التحتية: المزود، والخدمات المُدارة، والمطورون الخارجيون، والمدمجون، وبائعو المكتبات الحرجة. لكل منهم، وثّق: مستوى الوصول الممنوح، والبنود الأمنية في العقد، والإجراء المتبع إذا تعرض المورد نفسه لحادث.
أرشفة الملف بالكامل وتصنيفه إصداراً
يجب أن يكون ملف الامتثال NIS2 قابلاً للتأريخ والإثبات. خزّن جميع الوثائق في فضاء محكوم الوصول ومصنَّف إصداراً (مستودع git خاص مناسب) مع تاريخ التعديلات. يجب أن تحمل كل وثيقة تاريخاً وإصداراً وهوية المعتمِد. خطّط لمراجعة سنوية على الأقل، موثقة بدورها.
SLA الأمني: البنود ذات الحجية
SLA التوفر (توفر نسبة التوفر التعاقدية) ليس SLA أمنياً. لتدقيق NIS2، تختلف البنود التعاقدية ذات الحجية وتكون أكثر تحديداً. إليك ما يُميّز عقد استضافة مقبولاً من عقد غير كافٍ في ضوء التوجيه.
البنود الجوهرية لـNIS2 تتعلق بـ: الموعد النهائي للإخطار بحوادث الأمان المؤثرة على البنية التحتية (يجب أن يكون 24 ساعة أو أقل للتوافق مع المادة 23)، ونوع المعلومات المُرسَلة أثناء الحادث (كحد أدنى: طبيعة الحادث، والأنظمة المتأثرة، والتدابير المتخذة)، ومدة الاحتفاظ بالسجلات وإجراء الوصول إليها أثناء التحقيق، وشروط التدقيق أو التفتيش من قِبل العميل، والتزامات الاستمرارية مع مقاييس قابلة للقياس.
على ServOrbit، توثّق الشروط العامة التزامات التوفر وواجبات الإخطار. للكيانات الخاضعة لـNIS2، نوصي باستكمال ذلك بتبادل مكتوب يحدد مواعيد الإخطار بالحوادث وإجراءات الوصول إلى السجلات — هذا التبادل ذاته يُشكّل قطعة في ملف الأدلة.
التصلب: لا تكتفِ بشهادة ISO 27001 لمزودك دليلاً وحيداً. تغطي ISO 27001 عمليات المزود الداخلية لا بيئتك تحديداً. اطلب صراحةً نطاق الشهادة (هل مركز بياناتك مدرج؟) وتاريخ إصدارها. أضف النشرات الأمنية الأخيرة وتقارير الحوادث لآخر 12 شهراً حيثما توفرت. بالنسبة لنطاقك الخاص، يُعدّ اختبار الاختراق السنوي من طرف ثالث وتقريره أقوى دليل على نضج وضعيتك الأمنية — بكثير من قائمة تحقق ذاتية الإعلان.
تقرير حادث NIS2: سلسلة الأدلة الواجب إعادة تكوينها
المادة 23 من توجيه NIS2 من أكثر الالتزامات ملموسيةً وإلزاميةً: تفرض تسلسلاً دقيقاً للإخطار، وغياب الأدلة المؤرخة في أي خطوة يُعدّ انتهاكاً بحد ذاته. فهم هذا التسلسل قبل وقوع أي حادث أمر لا غنى عنه.
الجدول الزمني المفروض هو: في غضون 24 ساعة من اكتشاف الحادث المهم، يجب إرسال تحذير مبكر للسلطة الوطنية المختصة. في غضون 72 ساعة، يجب إرسال إخطار رسمي يتضمن تقييماً أولياً للخطورة والأنظمة المتأثرة والسبب المحتمل. في غضون شهر من حل الحادث، يجب إعداد تقرير نهائي يوثق المسار الكامل والتدابير التصحيحية والدروس المستخلصة.
لتكون قادراً على إنتاج هذه الوثائق، يجب أن توفر بنيتك التحتية أدلة في كل خطوة: الطابع الزمني الدقيق للكشف (سجل بطابع زمني للخادم)، وقائمة الأنظمة المتأثرة (جرد محدّث)، وطبيعة البيانات المكشوفة (خريطة الأصول)، والإجراءات المتخذة (سجل العمليات). يجب على مزودك تزويدك بجداوله الزمنية الخاصة إن كان الحادث يمس بنيته التحتية — هذا الالتزام يجب أن يرد في عقدك.
خلاصة وروابط للمزيد
بناء ملف أدلة NIS2 ليس إجراءً بيروقراطياً: بل هو الترجمة التوثيقية لممارسات أمنية حقيقية لا تحتاج سوى إلى التقنين إذا كانت متبعة فعلاً. التمييز الجوهري الواجب استيعابه هو بين ما يثبته مزود الاستضافة (بنيته التحتية وعملياته وشهاداته) وما يجب عليك إنتاجه بنفسك (سياستك وأصولك وإجراءاتك واختباراتك).
على VPS ServOrbit، اللبنات التقنية متاحة: لقطات تلقائية، وسجلات وصول قابلة للتصدير، وإخطار تعاقدي بالحوادث، وبنية تحتية معتمدة. ما تحتاج إضافته هو الطبقة التوثيقية التي تجعل هذه العناصر قابلة للاحتجاج بها أمام مدقق: طلبات موثقة، وبنود تعاقدية مُتحقَّق منها، وإجراءات مكتوبة ومختبرة.
لمزيد من التعمق: الالتزامات العامة لمزودي الاستضافة وعملائهم في إطار NIS2 مفصّلة في [nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026). أثر قانون المرونة الإلكترونية (CRA) على مكونات البرمجيات في بنيتك التحتية مغطى في [cra-cyber-resilience-act-hebergement-2027](/blog/cra-cyber-resilience-act-hebergement-2027). التزامات توطين البيانات ونقلها في إطار CNDP معالَجة في [conformite-cndp-hebergement-hors-maroc](/blog/conformite-cndp-hebergement-hors-maroc).
