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

لماذا فشلت قاعدة 3-2-1 القديمة بصمت

القاعدة الكلاسيكية — ثلاث نسخ من بياناتك، على وسيطين مختلفين، مع نسخة واحدة خارج الموقع — صُممت أصلاً لمواجهة عطل الأجهزة أو الحريق أو السرقة أو فني نسي القرص الصحيح. لم تُبنَ أبداً لتواجه مهاجماً يدخل شبكتك، يجلس بصمت لأيام، ثم يحذف أو يشفّر كل نسخة احتياطية يصل إليها قبل أن يُطلق الهجوم الفعلي. مجموعات الفدية الحديثة تستهدف مستودعات النسخ الاحتياطي عمداً. وإذا كانت نسختك "خارج الموقع" مجرد مجلد شبكي مربوط (mapped drive) أو مجلد سحابي متصل دائماً وقابل للكتابة دائماً، فهي فعلياً ليست خط دفاع منفصل — بل مجرد مجلد إضافي يشفّره المهاجم وهو في طريقه للخروج.

هذه هي الفجوة التي يسدّها نموذج 3-2-1-1-0. يحافظ على كل ما كان جيداً في القاعدة القديمة ويضيف شيئين تحترمهما الفدية فعلاً: نسخة لا يستطيع المهاجم تعديلها فيزيائياً، ودليل على أن السلسلة كاملة تعمل فعلاً.

نموذج 3-2-1-1-0 بشكل مبسّط

فكّكه وستجده سهل الحفظ، حتى لو كان يحتاج انضباطاً حقيقياً لتطبيقه:

• 3 نسخ من بياناتك — النسخة الإنتاجية بالإضافة إلى نسختين احتياطيتين.
• وسيطان مختلفان — مثلاً قرص محلي/NAS بالإضافة إلى شريط (tape) أو تخزين سحابي كائني. لا تضع كل نسخك الاحتياطية على نفس تقنية التخزين.
• نسخة واحدة خارج الموقع — منفصلة جغرافياً عن موقعك الرئيسي، بحيث لا يأخذ الحريق أو الفيضان أو السرقة في المكتب خيار التعافي معه أيضاً.
• نسخة واحدة غير قابلة للتعديل أو معزولة فيزيائياً (air-gapped) — هذا هو الجزء الجديد. على الأقل نسخة واحدة يجب أن تكون خارج متناول أي شخص يملك صلاحيات إدارية عادية، حتى لو كان حساب domain admin مخترقاً.
• 0 أخطاء — النسخ يتم التحقق منها باستمرار وتُختبر لإمكانية الاستعادة الفعلية، وليس فقط التأكد من علامة "مكتمل" خضراء في ملف السجل.

هذا الرقم الرابع "1" — عدم القابلية للتعديل أو العزل الفيزيائي — هو أكبر ترقية على النموذج القديم، وهو ما تتجاهله أغلب الشركات الصغيرة لأنه يكلف أكثر قليلاً أو يحتاج إعداداً أكثر قليلاً. صناديق تخزين بخاصية object-lock، أجهزة NAS تدعم WORM، أو مجموعة أشرطة/أقراص تُفصل فيزيائياً بعد كل عملية نسخ — أي منها يفي بالغرض. ما لا يفي بالغرض: مشاركة نسخ احتياطي تبقى مربوطة وقابلة للكتابة على مدار الساعة من نفس السيرفر الذي أُصيب للتو بالفدية.

ماذا تطلب إرشادات CISA #StopRansomware فعلياً

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

كما تنبّه CISA إلى نقطة تستحق الانتباه قبل شراء أي شيء: مزودو الخدمات السحابية الذين يقدمون تخزيناً "غير قابل للتعديل" قد يحمون البيانات دون بيئة منفصلة، لكن هذه الخاصية لا تلبي تلقائياً كل المتطلبات التنظيمية، وسياسة احتفاظ (retention policy) مضبوطة بشكل خاطئ قد تراكم عليك تكاليف تخزين لم تحسب لها حساباً. اقرأ التفاصيل الدقيقة لقفل الاحتفاظ قبل الالتزام — واختبر إعدادات القفل في bucket تجريبي أولاً، وليس على مجموعة النسخ الاحتياطي الإنتاجية.

حدّد RTO و RPO قبل أن تتسوق للأدوات

الكثير من الشركات الصغيرة تشتري منتج نسخ احتياطي أولاً ثم تكتشف توقعات التعافي لاحقاً. هذا معكوس. RTO (زمن التعافي المستهدف) هو المدة التي تتحمّلها الشركة وهي متوقفة. RPO (نقطة التعافي المستهدفة) هي كمية البيانات التي تستطيع تحمّل خسارتها، مقاسة بالزمن — ساعة من المعاملات، يوم، أسبوع. التوقف عن العمل مكلف على كل حال: الشركات خسرت في المتوسط 300,000 دولار في الساعة أثناء الأعطال في 2024، وهذا الرقم وحده يبرر جلسة نقاش جادة مع الإدارة قبل أن تلمس أي جهاز نسخ احتياطي.

ابدأ بتحليل تأثير الأعمال (Business Impact Analysis) قصير. اسأل بصراحة، لكل نظام على حدة: إذا توقف سيرفر Odoo أو قاعدة بيانات المحاسبة أو جهاز تسجيل CCTV الآن، كم ساعة تستطيع الشركة تحمّلها قبل أن يبدأ الضرر الفعلي، وكم من البيانات المفقودة مقبول فعلاً؟ نظام المحاسبة عادة يحتاج RPO يُقاس بالدقائق إلى الساعات — لا أحد يريد إعادة إدخال فواتير يوم كامل. أرشيف CCTV غالباً يتحمّل RPO أوسع بكثير. وثّق هذه الأرقام لكل نظام على حدة، وليس كسياسة واحدة شاملة، وابنِ تكرار النسخ الاحتياطي وخطة التعافي على أساسها — وليس العكس.

أين تذهب النسخة "خارج الموقع" في ظل قانون حماية البيانات الشخصية العُماني (PDPL)؟

هذا الجزء يوقع الكثير من مدراء IT هنا في خطأ، لأن "خارج الموقع" كانت تعني سابقاً "أي مكان آخر" فقط. بموجب قانون حماية البيانات الشخصية في عُمان، النهج الأكثر أماناً هو اختيار مزودي خدمة سحابية لديهم مراكز بيانات فعلية داخل عُمان، وتطبيق التشفير على أي بيانات شخصية قبل أن تعبر الحدود إذا كان استخدام مزوّد أجنبي أمراً لا مفر منه. إذا كنت تنسخ ملفات موارد بشرية أو قواعد بيانات عملاء أو أي شيء يحوي بيانات شخصية، لا تتجه تلقائياً إلى bucket سحابي عالمي عام فقط لأنه رخيص — تحقق أين يقع الإقليم فعلياً، وشفّر من جانب العميل قبل الرفع في كل الأحوال.

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

ابنِ جدولاً لاختبار الاستعادة يثبت شيئاً فعلياً

عملية نسخ احتياطي تكتمل بنجاح كل ليلة لا تخبرك شيئاً تقريباً عن قدرتك على التعافي فعلاً. الصفر في 3-2-1-1-0 موجود لأن إهمال اختبار الاستعادة المنتظم هو بالضبط الطريقة التي تكتشف بها المؤسسات — أثناء حادثة حقيقية — أن ملف النسخة تالف، أو أن مفتاح التشفير فُقد، أو أن الاستعادة تستغرق أربع عشرة ساعة بينما الشركة تتحمّل ساعتين فقط. الاختبار يجب أن يكون مجدولاً، لا مجرد أمنية:

• شهرياً: استعادة ملف واحد حرج أو جدول قاعدة بيانات إلى بيئة تجريبية والتأكد أنه يفتح ويُقرأ بشكل صحيح.
• ربع سنوي: استعادة كاملة لسيرفر حرج واحد (سيرفر Odoo/المحاسبة مرشح جيد) إلى VM معزولة، وقياس زمن العملية كاملة مقابل RTO الموثّق لديك.
• سنوياً: تشغيل محاكاة تعافي كارثة كاملة تشمل كامل المنظومة — السيرفر، إعدادات الشبكة، وعلى الأقل استعادة واحدة لجهاز CCTV/NVR — وتدوين ما تعطّل.

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

قائمة تحقق من صفحة واحدة سلّمها للإدارة هذا الأسبوع

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

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

المصادر

• 3-2-1 Backup Rule Explained (Veeam)
• How to Implement the 3-2-1-1-0 Backup Rule in 2026
• 3-2-1 Backup Rule (Commvault)
• #StopRansomware Guide (CISA)
• #StopRansomware: Akira Ransomware Advisory (CISA)
• Oman's data privacy laws and how Global Companies can comply
• Data privacy handbook for the Sultanate of Oman (PwC)
• Disaster Recovery Plan Guide 2025: Complete Steps & Templates

مصدر الصورة: tawalker — BY