نسخة احتياطية منسية على خادمك يستطيع أي شخص تنزيلها

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

القصة المعتادة هكذا: ينقل المطوّر موقعك إلى شركة استضافة جديدة، أو يجري عليه تغييرات كبيرة. ومن باب الاحتياط يضغط الموقع كله في ملف backup.zip، ويصدّر قاعدة البيانات إلى database.sql، ويترك الملفين في مجلد الموقع ليكونا في متناول يده. ينتهي العمل، ويعمل الموقع، وتبقى الملفات. وبعد سنة لا يتذكر أحد أنها موجودة.

لكن مجلد الموقع عام. كل ما فيه يمكن تنزيله بمتصفح عادي لمن يعرف العنوان أو يخمّنه.

ما الذي يُنسى عادة

أكثر ما نجده يشبه هذا:

• أرشيفات للموقع كاملًا، مثل backup.zip أو site.tar.gz أو www-2023.zip،
• تفريغات لقاعدة البيانات: dump.sql وdatabase.sql وdb_backup.sql،
• نسخ من ملف الإعدادات: wp-config.php.bak وwp-config.php.old وconfig.php~،
• إصدارات قديمة كاملة من الموقع في مجلدات اسمها old/ أو test/ أو backup/،
• أرشيفات وملفات تثبيت تتركها إضافات نقل المواقع.

وأخطرها في الغالب أصغرها: نسخة من ملف الإعدادات. الخادم يشغّل الملف الأصلي wp-config.php كبرنامج، فلا يستطيع أحد من الخارج قراءة محتواه. أما wp-config.php.bak فهو عند الخادم مجرد ملف نصي، فيسلّمه كاملًا، ومعه اسم قاعدة البيانات واسم المستخدم وكلمة المرور.

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

لماذا تبحث عنها الروبوتات

لا يحتاج أحد إلى معرفة أن لديك أنت تحديدًا نسخة احتياطية على الخادم. برامج فحص آلية تجوب الإنترنت، وتجرّب في كل موقع تصل إليه قائمة بالأسماء الشائعة: /backup.zip و/site.zip و/dump.sql و/wp-config.php.bak و/.env. العملية رخيصة وسريعة، فهي تجري طوال الوقت.

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

والطريق الثاني هو Google. إن كان عرض محتوى المجلدات (directory listing) مفعّلًا، فزيارة yourdomain.com/backup/ تعرض قائمة بسيطة بالملفات عنوانها «Index of /backup». وصفحات كهذه تظهر أحيانًا في نتائج البحث، وعندها يجدها أي شخص دون تخمين.

ما تستطيع فحصه بنفسك دون دخول إلى الخادم

بعض الفحوص تأخذ خمس دقائق:

1. ابحث في Google عن site:yourdomain.com intitle:"index of". غياب النتائج علامة جيدة.
2. اكتب في المتصفح بضعة عناوين، مثل yourdomain.com/backup.zip أو yourdomain.com/database.sql أو yourdomain.com/old/. إن بدأ تنزيل أو ظهرت قائمة ملفات بدل صفحة الخطأ، فقد عرفت الجواب.
3. افحص الموقع بأداة مثل ShieldWave، التي تجرّب من الخارج الأسماء الشائعة نفسها التي تجرّبها الروبوتات. والفرق أن النتائج تصل إليك أنت.

لكن للتخمين حدود. فالأسماء الممكنة بالمئات، وقد يكون المطوّر سمّى الملف أي اسم. الجواب الموثوق الوحيد يأتي ممن ينظر إلى الملفات على الخادم.

كيف تطلب الفحص من المطوّر أو شركة الاستضافة

لا تحتاج إلى التفاصيل التقنية. تكفي رسالة قصيرة تطلب أربعة أمور:

• التأكد من أن مجلد الموقع العام (واسمه عادة public_html أو www أو httpdocs) لا يحوي ملفات .zip أو .tar.gz أو .sql أو .bak أو .old، ولا مجلدات مثل old أو backup أو test،
• نقل ما يُعثر عليه إلى خارج المجلد العام، أو حذفه،
• إيقاف عرض محتوى المجلدات إن كان مفعّلًا،
• مراجعة سجلات الخادم لمعرفة هل نزّل أحد تلك الملفات.

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

وإن كان الملف الذي نُزّل يحوي بيانات العملاء، فأنت أمام انتهاك للبيانات الشخصية. وبموجب المادة 33 من اللائحة العامة لحماية البيانات (GDPR) لديك عندها 72 ساعة من علمك بالانتهاك لإبلاغ سلطة حماية البيانات، ما لم يكن من غير المرجح أن يعرّض الانتهاك الأشخاص المعنيين للخطر. وفي المملكة المتحدة هذه السلطة هي مكتب مفوض المعلومات (ICO). وحتى إن لم تبلّغ، فالمتوقع أن تحتفظ بسجل للانتهاك.

أين يجب أن تُحفظ النسخ الاحتياطية

النسخة الاحتياطية الجيدة تستوفي شروطًا بسيطة:

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

انتبه لإضافات النسخ الاحتياطي في WordPress. بعضها يحفظ الأرشيفات افتراضيًا داخل مجلد الموقع، في مكان ما داخل wp-content مثلًا، ويحميها بملف .htaccess. هذه الحماية تعمل على خوادم Apache وLiteSpeed، لكن خادم nginx لا يقرأ هذا الملف أصلًا. والحل الأبسط أن تضبط الإضافة لترسل النسخ إلى مكان آخر دون الاحتفاظ بنسخة محلية.

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

وإن كان لديك سؤال واحد فقط لمن يدير موقعك، فليكن هذا: أين نسخنا الاحتياطية، ومن غيرنا يستطيع تنزيلها؟