قائمة التحقق من Cayvora لإطلاق موقع ويب آمن

إن إطلاق موقع ويب بدون تدقيق أمني صارم يشبه فتح خزنة بنك مع ترك الباب مفتوحاً. في Cayvora Security، تكشف بيانات الاستجابة للحوادث لدينا عن إحصائية مذهلة: 80% من حوادث الأمان بعد الإنتاج كان يمكن منعها من خلال قائمة تحقق أمنية منهجية قبل الإطلاق. هذا الدليل هو المرجع النهائي لمديري التكنولوجيا وفرق DevSecOps ومديري تكنولوجيا المعلومات في المغرب وخارجه.

الإطلاق الآمن ليس رفاهية — إنه الاستثمار الأكثر جدوى اقتصادية في بنيتك التحتية الرقمية. إصلاح ثغرة في الإنتاج يكلف 30 ضعفاً أكثر من اكتشافها قبل النشر.

---

1. أمن النطاق و DNS

اسم النطاق الخاص بك هو هويتك الرقمية. اختراقه يعني إعادة توجيه قاعدة عملائك بالكامل إلى خادم يتحكم فيه المهاجم. أمن DNS هو الأساس الذي تُبنى عليه جميع الحمايات الأخرى.

1.1 حماية WHOIS وقفل النطاق

• تفعيل حماية خصوصية WHOIS: منع المهاجمين من جمع تفاصيل الاتصال بالمسجل (الاسم، البريد الإلكتروني، الهاتف) لحملات التصيد الاحتيالي المستهدفة.
• تفعيل قفل المسجل (clientTransferProhibited): يمنع عمليات نقل النطاق غير المصرح بها. بدون هذا العلم، يمكن للمهاجم الذي يخترق حساب المسجل الخاص بك نقل نطاقك بصمت.
• تفعيل DNSSEC: يوقع DNSSEC سجلات DNS الخاصة بك بشكل تشفيري، مما يمنع هجمات تسميم ذاكرة التخزين المؤقت لـ DNS.

1.2 مصادقة البريد الإلكتروني: SPF و DKIM و DMARC

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

• SPF: انشر سجل DNS TXT يسرد عناوين IP والخدمات المصرح لها بإرسال البريد الإلكتروني لنطاقك. اختم بـ -all (رفض صارم).
• DKIM: قم بتكوين خادم البريد الخاص بك لتوقيع رسائل البريد الإلكتروني الصادرة بشكل تشفيري. يتحقق الخادم المستلم من التوقيع عبر مفتاح عام منشور في DNS الخاص بك.
• DMARC: عيّن سياسة DMARC (p=reject) تعليمات للخوادم المستلمة برفض رسائل البريد الإلكتروني التي تفشل في فحوصات SPF و DKIM. قم بتكوين التقارير المجمعة (rua=) لمراقبة محاولات الانتحال.

; أمثلة على سجلات DNS لأقصى أمان للبريد الإلكتروني
; سجل SPF
@ IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; سجل DMARC
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

; سجل CAA (تقييد إصدار الشهادات)
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issuewild ";"

1.3 سجلات CAA (تفويض سلطة الشهادة)

• تقييد إصدار الشهادات: انشر سجلات DNS CAA لتحديد سلطات الشهادات المسموح لها بإصدار شهادات TLS لنطاقك بالضبط.
• حظر شهادات Wildcard: إذا كنت لا تستخدم شهادات wildcard، ارفضها صراحةً بـ issuewild ";".

1.4 تكوين CDN والحماية من DDoS

• نشر CDN مع WAF: خدمات مثل Cloudflare أو AWS CloudFront أو Akamai توفر شبكة حافة عالمية تمتص هجمات DDoS قبل وصولها إلى خادمك الأصلي.
• إخفاء عنوان IP الأصلي: لا تكشف أبداً عنوان IP الحقيقي لخادمك الأصلي. يجب أن تشير جميع سجلات DNS A إلى عناوين IP الحافة لـ CDN.
• تفعيل تحديد المعدل: قم بتكوين تحديد المعدل على مستوى CDN لمنع هجمات القوة الغاشمة على صفحات تسجيل الدخول ونقاط نهاية API.

---

2. معايير التشفير وتكوين TLS

التشفير أثناء النقل أمر غير قابل للتفاوض. يجب تشفير كل بايت من البيانات المتبادلة بين المستخدمين والخوادم ببروتوكولات حديثة ومدققة.

2.1 فرض TLS 1.2+

• تعطيل TLS 1.0 و TLS 1.1: تحتوي هذه البروتوكولات القديمة على ثغرات حرجة (BEAST، POODLE، CRIME). جميع المتصفحات الحديثة أسقطت دعمها.
• تفضيل TLS 1.3: يوفر TLS 1.3 مصافحة أسرع (1-RTT مقابل 2-RTT)، وحزم تشفير أقوى افتراضياً، ويقضي على فئات كاملة من الهجمات.
• حزم التشفير القوية فقط: استخدم شيفرات AEAD (AES-256-GCM، ChaCha20-Poly1305). أزل الشيفرات القديمة مثل RC4 و 3DES.

# تكوين TLS المقوى لـ Nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

2.2 HSTS (أمن النقل الصارم عبر HTTP)

• نشر HSTS بفترة Max-Age طويلة: عيّن Strict-Transport-Security: max-age=63072000; includeSubDomains; preload لإجبار المتصفحات على استخدام HTTPS لمدة سنتين.
• التسجيل في قائمة التحميل المسبق HSTS: سجل نطاقك في hstspreload.org حتى تفرض جميع المتصفحات الرئيسية HTTPS من أول اتصال.

2.3 هدف الحصول على تقييم A+ من SSL Labs

• اختبر مع SSL Labs: مرر نطاقك عبر Qualys SSL Labs واستهدف تقييم A+. أي تقييم أقل من A يشير إلى ضعف في التكوين.
• مراقبة شفافية الشهادات: اشترك في خدمات مراقبة سجلات CT لتلقي تنبيهات في حال إصدار شهادات غير مصرح بها لنطاقك.

---

3. رؤوس الأمان وحمايات المتصفح

رؤوس الأمان هي خط دفاعك الثاني بعد TLS. إنها تعلم المتصفح بتطبيق سياسات أمان صارمة للتخفيف من هجمات XSS والنقر الخادع وحقن البيانات.

• Content-Security-Policy (CSP): حدد قائمة سماح صارمة لمصادر المحتوى. احظر النصوص البرمجية المضمنة في الإنتاج.
• X-Frame-Options: DENY: امنع النقر الخادع بحظر تضمين موقعك في إطارات iframe.
• X-Content-Type-Options: nosniff: امنع هجمات استنشاق نوع MIME.
• Referrer-Policy: strict-origin-when-cross-origin: حدد المعلومات المسربة في رأس Referer.
• Permissions-Policy: ارفض صراحةً الوصول إلى ميزات المتصفح التي لا تستخدمها (الكاميرا، الميكروفون، تحديد الموقع الجغرافي).

---

4. الامتثال التنظيمي المغربي

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

4.1 الامتثال لـ CNDP (القانون 09-08)

تطبق اللجنة الوطنية لمراقبة حماية المعطيات ذات الطابع الشخصي (CNDP) قانون حماية البيانات المغربي (القانون 09-08). قبل الإطلاق، يجب عليك:

• تقديم تصريح CNDP: إرسال إخطار رسمي يصف البيانات الشخصية التي تجمعها وأغراض الجمع وفترات الاحتفاظ وممارسات المشاركة مع أطراف ثالثة.
• الحصول على موافقة صريحة: تنفيذ آليات موافقة واضحة وإيجابية لجمع البيانات. مربعات الاختيار المحددة مسبقاً غير قانونية بموجب القانون المغربي.
• تعيين مسؤول حماية البيانات (DPO): تعيين شخص مسؤول عن الامتثال لحماية البيانات داخل مؤسستك.
• تنفيذ حقوق أصحاب البيانات: توفير آليات للمستخدمين للوصول إلى بياناتهم الشخصية وتصحيحها وحذفها.

4.2 قانون التجارة الإلكترونية المغربي (القانون 31-08)

• معلومات قانونية إلزامية: عرض البيانات القانونية الكاملة، بما في ذلك تسجيل الشركة ورقم ICE والتعريف الضريبي والعنوان الفعلي.
• إفصاحات حماية المستهلك: عرض واضح للأسعار (شاملة جميع الضرائب) وشروط التسليم وسياسات الإرجاع (حق الانسحاب لمدة 14 يوماً) وضمانات أمان الدفع.
• الامتثال للعقود الإلكترونية: التأكد من أن عملية الدفع تتبع قاعدة التأكيد المزدوج (مراجعة الطلب ← تأكيد الطلب) كما يتطلبه القانون المغربي.

4.3 الامتثال المتقاطع RGPD / GDPR

إذا كان موقعك يستهدف أو يعالج بيانات مواطني الاتحاد الأوروبي (شائع للشركات المغربية ذات العملاء الأوروبيين)، يجب عليك أيضاً الامتثال لـ GDPR:

• شريط موافقة ملفات تعريف الارتباط: تنفيذ آلية موافقة متوافقة تحظر ملفات تعريف الارتباط غير الأساسية حتى يقدم المستخدم موافقة إيجابية.
• سياسة خصوصية بعدة لغات: نشر سياسة خصوصية شاملة بجميع اللغات التي يخدمها موقعك.
• اتفاقيات معالجة البيانات (DPA): التأكد من أن جميع مقدمي الخدمات الخارجيين قد وقعوا على اتفاقيات DPA تضمن حمايات بمستوى GDPR.

---

5. تدقيق أمان التطبيق قبل الإطلاق

• فحص ثغرات التبعيات: قم بتشغيل npm audit أو pip audit أو ما يعادلها لتحديد وتصحيح الثغرات المعروفة في المكتبات الخارجية.
• اختبار أمان التطبيق الثابت (SAST): استخدم أدوات فحص الكود الآلية (SonarQube، Semgrep) لاكتشاف عيوب الحقن والأسرار المشفرة في الكود.
• إدارة الأسرار: تأكد من عدم تخزين أي مفاتيح API أو بيانات اعتماد قاعدة البيانات في قاعدة الكود الخاصة بك.
• معالجة الأخطاء: عطّل تتبعات المكدس ورسائل الأخطاء المفصلة في الإنتاج.
• تعطيل قائمة المجلدات: تحقق من أن خادم الويب لا يكشف قوائم المجلدات.

---

6. النسخ الاحتياطي واستعداد الاستجابة للحوادث

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

---

تحميل القائمة الكاملة