أصعب لحظة في الحادث ليست الضغط على restore، بل اختيار النسخة والسبب.

نُشر في 19 يوليو 2026 · Ransomware / Restore Decision / VPS Backup

NIST IR 8374 Rev. 1 يقدم ransomware كخطر يحتاج إدارة عبر الوقاية والاكتشاف والاستجابة والتعافي، وليس كملف خبيث فقط. في بيئة VPS أو cPanel، وجود نسخة احتياطية لا يكفي إذا لم يعرف الفريق من وافق على الاسترجاع، ولماذا اختيرت هذه النسخة، وما الذي تم التحقق منه بعدها.

ما هو restore decision log؟

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

هذا السجل لا يبطئ الفريق إذا كان قالبه جاهزًا. بالعكس، يمنع نقاشًا عشوائيًا وقت الضغط ويحمي القرار من الاعتماد على الذاكرة.

لماذا تحتاجه المواقع المستضافة؟

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

وجود سجل يساعدك بعد الحادث في فهم هل كانت RPO وRTO واقعية، وهل التنبيهات والنسخ والموافقات عملت كما يجب.

Checklist السجل

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

كيف تربطه بالمراقبة؟

التنبيه يجب أن يفتح incident record، وليس محادثة متناثرة. اربط مراقبة uptime وbackup status بحقل owner وحالة القرار، حتى يعرف الفريق هل ينتظر موافقة أم ينفذ إجراء متفقًا عليه مسبقًا.

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

أسئلة شائعة

هل السجل ضروري لموقع صغير؟ نعم لكن يمكن أن يكون صفحة واحدة.

هل نكتب تفاصيل حساسة؟ اكتب ما يكفي للمراجعة الداخلية بدون نشر أسرار أو بيانات شخصية.

هل السجل بديل عن backup monitoring؟ لا. هو يكمل المراقبة عند اتخاذ قرار الاسترجاع.

المصادر

• NIST IR 8374 Rev. 1: Ransomware Risk Management.
• NIST CSRC: Ransomware Protection and Response.
• CISA: StopRansomware Guide.
• CISA Secure Our World: Back It Up.