Defense in Depth

الدفاع بالعمق Defense in Depth

لا تعتمد على طبقة حماية واحدة — ضع عدة طبقات دفاعية متتالية، بحيث لو فشلت واحدة تبقى البقية قائمة.

فكرة مستعارة من الدفاع العسكري التقليدي: بدل خط دفاع واحد قوي (يصبح نقطة فشل وحيدة إن اخترق)، تُبنى عدة طبقات مستقلة — شبكة، تطبيق، بيانات — بحيث اختراق طبقة واحدة لا يعني اختراق النظام كاملًا.

في أمن API عمليًا: حتى لو نجح مهاجم بتجاوز Rate Limiting، يجب أن يصطدم بـ Input Validation؛ ولو تجاوزها، يجب أن يصطدم بصلاحيات RBAC؛ ولو تجاوزها، يجب أن تكون البيانات الحساسة مشفّرة أصلًا فلا تفيده حتى لو وصل إليها.

الصياغة

طبقة شبكة (Firewall/Rate Limit) → طبقة تطبيق (Validation/Auth) → طبقة بيانات (Encryption/Least Privilege)

📄 مثال

// مثال: طبقات متتالية على مسار واحد حساس
app.post('/api/transfer',
  rateLimit({ max: 3, windowMs: 60000 }),   // طبقة 1: شبكة
  authenticate,                              // طبقة 2: هوية
  requireRole('verified-user'),              // طبقة 3: صلاحية
  validateBody(transferSchema),              // طبقة 4: تحقق مدخلات
  requireMfaForHighValue,                    // طبقة 5: تحقق إضافي للمبالغ الكبيرة
  transferHandler                            // طبقة 6: بيانات مشفّرة أصلًا بقاعدة البيانات
);

أهم النقاط

النقطة	الوظيفة
الفكرة	طبقات دفاعية مستقلة بحيث فشل واحدة لا يعني اختراق النظام
أين تُطبَّق	شبكة (Rate Limit/Firewall)، تطبيق (Validation/AuthZ)، بيانات (Encryption)
الفرق عن Zero Trust	Zero Trust مبدأ 'لا تثق'، Defense in Depth مبدأ 'لا تعتمد على طبقة واحدة' — متكاملان لا بديلان

💡 نصائح عملية

رتّب الطبقات من الأرخص حسابيًا للأغلى (Rate Limit قبل استعلام قاعدة بيانات) لتقليل الحمل على الخادم

⚠️ أخطاء شائعة

اعتبار جدار الحماية أو WAF وحده 'كافيًا' والاستغناء عن التحقق داخل كود التطبيق نفسه

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار API-SECURITY الكامل بالعربي.