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

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

كيف تُخترق المواقع عادةً؟

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

• برمجيات قديمة: نظام إدارة المحتوى أو القالب أو الإضافات أو إصدار لغة الخادم، حين تحتوي ثغرات معلنة يعرفها المهاجمون وتبحث عنها برامجهم تلقائيًا.
• كلمات مرور ضعيفة أو مكررة: إن تسربت كلمة مرور أحد أفراد الفريق من خدمة أخرى، جرّبتها البرامج الآلية على لوحة تحكمك وبريدك، وهو ما يسمى حشو بيانات الدخول (Credential Stuffing).
• التصيد الاحتيالي (Phishing): رسالة تبدو صادرة عن شركة الاستضافة أو مسجل النطاق تطلب «تأكيد الحساب» عبر رابط مزيف.
• شيفرة غير آمنة: في البرمجة الخاصة تحديدًا، كحقن قواعد البيانات (SQL Injection)، وحقن السكربتات (XSS)، ورفع ملفات بلا قيود.
• إعدادات خاطئة: ملفات نسخ احتياطية أو ملفات إعدادات متروكة في مجلد عام، أو صفحات إدارة مكشوفة، أو رسائل خطأ تكشف تفاصيل داخلية.
• أطراف خارجية: سكربت أو إضافة من مزوّد تعرّض هو نفسه للاختراق.

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

التحديثات: أبسط دفاع وأكثره إهمالًا

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

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

كلمات المرور والتحقق بخطوتين

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

مبدأ أقل الصلاحيات

مبدأ أقل الصلاحيات (Least Privilege) يعني أن يحصل كل شخص وكل نظام على الصلاحيات التي يحتاجها لعمله فقط، وللمدة التي يحتاجها فقط:

• كاتب المحتوى يحتاج صلاحية محرر أو كاتب، لا صلاحية مدير كامل.
• الوكالة أو المستقل يحصل على حساب مستقل يُلغى عند انتهاء المشروع، لا على كلمة مرور المدير.
• عند مغادرة موظف، تُعطَّل حساباته في اليوم نفسه، وتُغيَّر أي كلمات مرور مشتركة كان يعرفها.
• مستخدم قاعدة البيانات الذي يتصل به الموقع يملك الصلاحيات اللازمة للموقع فقط.
• مفاتيح واجهات البرمجة (API Keys) محدودة النطاق، وتُغيَّر دوريًا، ولا تُكتب أبدًا في شيفرة منشورة أو مستودع عام.

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

HTTPS وشهادة SSL

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

النسخ الاحتياطي واختبار الاستعادة

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

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

وتذكّر أن نسخ شركة الاستضافة ميزة إضافية لا خطة كاملة؛ اعرف شروطها ومدة احتفاظها، واحتفظ بنسخك الخاصة.

التحقق من المدخلات والبرمجة الآمنة

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

• تحقق على الخادم: النوع والطول والصيغة والقيم المسموحة. التحقق في المتصفح يحسّن التجربة لكنه لا يحمي، كما يوضح أساسيات HTML وCSS وجافاسكربت.
• الاستعلامات المُعدّة مسبقًا: تفصل البيانات عن أمر قاعدة البيانات، فتمنع حقن قواعد البيانات.
• ترميز المخرجات: كل بيانات يدخلها المستخدم ثم تُعرض في الصفحة يجب أن تُرمَّز لمنع حقن السكربتات. محركات القوالب الحديثة تفعل ذلك افتراضيًا، فلا تعطّله.
• رموز الحماية من الطلبات المزورة (CSRF Tokens) في النماذج التي تغيّر بيانات.
• رفع الملفات: اسمح بأنواع محددة، وافحص المحتوى لا الامتداد فقط، وحدد الحجم، وأعد تسمية الملفات، واحفظها بحيث لا يمكن تنفيذها.
• كلمات مرور المستخدمين تُخزَّن بعد معالجتها بخوارزمية تجزئة مخصصة لذلك مثل bcrypt أو Argon2، لا نصًا صريحًا ولا بخوارزميات قديمة سريعة.
• رسائل الخطأ: عامة للزائر، والتفاصيل في سجلات لا يراها إلا الفريق.
• الحماية من الرسائل المزعجة: حد لعدد الإرسالات، وحقل خفي يكشف البرامج الآلية، وأداة تحقق بشري عند الحاجة.

هذا مثال بلغة PHP يوضح الفرق بين استعلام خطر واستعلام آمن:

// Unsafe: user input is glued into the query
$sql = "SELECT id, name FROM clients WHERE email = '" . $_POST['email'] . "'";

// Safe: a prepared statement keeps data separate from the query
$stmt = $pdo->prepare('SELECT id, name FROM clients WHERE email = ?');
$stmt->execute([$_POST['email']]);
$client = $stmt->fetch();

في الحالة الأولى يستطيع مهاجم أن يكتب في حقل البريد نصًا يغيّر معنى الاستعلام نفسه. وفي الثانية يُرسل الاستعلام أولًا ثم تُمرَّر البيانات منفصلة، فتُعامل دائمًا بوصفها بيانات لا أوامر.

قائمة OWASP لأخطر عشرة مخاطر

مشروع OWASP مجتمع مفتوح غير ربحي ينشر موارد مجانية في أمن تطبيقات الويب، وأشهرها قائمة OWASP Top 10: وثيقة توعوية تجمع أخطر فئات المخاطر في تطبيقات الويب، وتُحدَّث كل بضع سنوات. ومن الفئات التي تتكرر عبر إصداراتها: الخلل في التحكم بالوصول، كأن يغيّر عميل رقم الطلب في الرابط فيرى طلب عميل آخر، والحقن بأنواعه، والإعدادات الأمنية الخاطئة، والمكونات القديمة أو الضعيفة، وإخفاقات التحقق من الهوية، وإخفاقات التشفير.

لا تحتاج إلى حفظ القائمة، لكنها لغة مشتركة مفيدة مع المطورين. اسأل من يبني موقعك: كيف تتعامل شيفرتك مع مخاطر قائمة OWASP؟ وراجع الإصدار الحالي منها عند التعاقد على مشروع برمجي كبير.

ترويسات الأمان

ترويسات الأمان (Security Headers) تعليمات يرسلها الخادم مع كل صفحة ليفعّل المتصفح حمايات إضافية. أهمها:

• Strict-Transport-Security: يلزم المتصفح باستخدام HTTPS دائمًا مع نطاقك. فعّله بعد التأكد أن كل النطاقات الفرعية تعمل عبر HTTPS، لأن المتصفح سيرفض غيره طوال المدة المحددة.
• Content-Security-Policy: يحدد المصادر المسموح أن تُحمَّل منها السكربتات والأنماط والصور، وهو دفاع قوي ضد حقن السكربتات. يحتاج ضبطًا دقيقًا، فابدأ بوضع التقرير فقط (Report-Only) قبل التطبيق الفعلي.
• X-Content-Type-Options: يمنع المتصفح من تخمين نوع الملف بخلاف ما أعلنه الخادم.
• X-Frame-Options أو توجيه frame-ancestors في سياسة المحتوى: يمنع تضمين موقعك داخل إطار في موقع آخر لخداع الزائر بالنقر.
• Referrer-Policy: يحدد مقدار الرابط الذي يُرسل إلى المواقع الأخرى حين ينتقل إليها الزائر.
• Permissions-Policy: يعطّل خصائص المتصفح التي لا يحتاجها موقعك، كالكاميرا والميكروفون والموقع الجغرافي.

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

هذه قيم شائعة للبدء لا وصفة جاهزة لكل موقع. توجد أدوات فحص مجانية على الإنترنت تعرض الترويسات المفعّلة في موقعك وما ينقصه.

المراقبة والإنذار المبكر

• مراقبة التوافر لتعرف فورًا إن توقف الموقع.
• تنبيهات عند إنشاء مستخدم مدير جديد أو الدخول من مكان غير معتاد.
• فحص دوري للملفات بحثًا عن تعديلات أو شيفرات خبيثة، من الاستضافة أو من أداة أمان موثوقة.
• جدار حماية لتطبيقات الويب (WAF) تقدمه كثير من شركات الاستضافة وشبكات توصيل المحتوى، يصد أنماط الهجوم المعروفة قبل وصولها إلى موقعك.
• تقرير مشكلات الأمان في Google Search Console، الذي ينبهك إن اكتشفت جوجل محتوى مخترقًا أو برمجيات خبيثة في موقعك.
• الاحتفاظ بسجلات الخادم مدة كافية، فهي أول ما تحتاجه لفهم أي حادث.

ماذا تفعل إذا اختُرق موقعك؟

1. لا تتسرع في الحذف: وثّق ما تراه بلقطات شاشة وأوقات، وخذ نسخة من الملفات وقاعدة البيانات والسجلات قبل التنظيف، فهي دليلك لمعرفة ما حدث.
2. احتوِ الضرر: ضع الموقع في وضع الصيانة أو أوقفه مؤقتًا إن كان ينشر برمجيات خبيثة أو يسرق بيانات، وأبلغ شركة الاستضافة.
3. غيّر كل كلمات المرور من جهاز سليم: الاستضافة ولوحة التحكم وقاعدة البيانات والبريد ومسجل النطاق، وألغِ الجلسات المفتوحة ومفاتيح واجهات البرمجة، وابحث عن حسابات مدير لا تعرفها.
4. حدد نقطة الدخول: إضافة قديمة؟ كلمة مرور مسروقة؟ ملف مرفوع؟ من دون إغلاقها سيعود المهاجم.
5. نظّف أو استعد: استعد نسخة سليمة تسبق الاختراق، ثم حدّث كل شيء وأغلق الثغرة قبل إعادة الموقع للعمل، أو استعن بمتخصص في التنظيف. وافحص الموقع بحثًا عن أبواب خلفية متروكة.
6. راجع سمعتك الرقمية: إن نبهتك جوجل إلى مشكلة أمنية فاطلب المراجعة بعد التنظيف، وإن أُرسلت رسائل مزعجة من خادمك فتحقق من قوائم الحظر الخاصة بالبريد.
7. البيانات الشخصية: إن احتمل تسرب بيانات عملاء، فقد تُلزمك أنظمة حماية البيانات في بلدك أو بلدان عملائك بإبلاغ جهة مختصة أو المتأثرين خلال مدة محددة. استشر مستشارًا قانونيًا مبكرًا.
8. راجع ما حدث: اكتب ملخصًا لما جرى وكيف عولج وما الذي ستغيّره، حتى لا يتكرر.

قائمة تحقق دورية

شهريًا:

• تطبيق تحديثات النظام والقوالب والإضافات.
• التأكد من أن النسخ الاحتياطي يعمل وأن آخر نسخة مكتملة.
• مراجعة المستخدمين ذوي الصلاحيات العالية.
• مراجعة تقارير Search Console وتنبيهات المراقبة.

كل ربع سنة:

• اختبار استعادة نسخة كاملة على بيئة تجريبية.
• مراجعة سجل الحسابات وإلغاء صلاحيات من غادر.
• مراجعة الإضافات والسكربتات الخارجية وحذف ما لا يلزم.
• فحص ترويسات الأمان وتاريخ انتهاء الشهادة.

وإن كان موقعك متجرًا يتعامل مع بيانات العملاء والمدفوعات، فأكمل بـأمان المتجر الإلكتروني وحماية بيانات العملاء. ولترى موقع الأمان ضمن مراحل بناء الموقع وصيانته، ارجع إلى الدليل الشامل لبناء موقع شركتك.