قبل كتابة أول سطر من الكود، يجب أن نعرف ما يجب أن يحققه النظام من حيث الحماية. متطلبات البرمجيات الآمنة (Security Requirements) هي وصف لما يجب أن يفعله النظام لمنع، اكتشاف، أو الاستجابة للتهديدات.
مثال: "يجب أن يُسمح بالوصول إلى صفحة لوحة التحكم فقط للمستخدمين الذين لديهم صلاحية المسؤول (admin)."
✅ مصادر رئيسية تشمل:
السياسات الأمنية هي مجموعة من القواعد التي تحكم كيفية التعامل مع البيانات والأنظمة. عند تحليل السياسات يجب طرح الأسئلة التالية:
مرجع مفيد: SANS Security Policy Project
لتطبيق الحماية بشكل فعال، يجب تصنيف كل من:
ثم يُحدد من يحق له الوصول إلى ماذا باستخدام ما يسمى بـ مصفوفة التحكم في الوصول (Access Control Matrix).
| البيانات/المستخدم | مستخدم عادي | مشرف |
|---|---|---|
| تقرير مبيعات | عرض فقط | تحرير |
| إعدادات النظام | ممنوع | تحرير |
RTM هي أداة تُستخدم لتوثيق وتتبع العلاقة بين المتطلبات الأمنية ومخرجات المشروع.
مثال: إذا كان لدينا متطلب أمني خاص بالمصادقة، فيجب أن نرى أثره في التصميم، الترميز، والاختبار.
قالب جاهز لـ RTM: RTM Template
من الخطأ الشائع تأجيل متطلبات الأمان حتى مرحلة متقدمة من المشروع. يجب دمج الأمن في وقت مبكر من التحليل بجانب المتطلبات الوظيفية، مثل:
"كلما تم دمج الأمان أبكر في المشروع، قلّت الكلفة وزادت الفعالية."
تحليل المخاطر يُستخدم لتحديد ما الذي يمكن أن يُستغل في النظام، ويُحدد الأولويات. أشهر النماذج:
يحلل:
دليل مبسط من Microsoft: Microsoft Threat Modeling Tool
أداة STRIDE مجانية من OWASP: OWASP Threat Modeling
"يجب تسجيل جميع محاولات الدخول غير الناجحة والناجحة، والاحتفاظ بالسجلات لمدة لا تقل عن 90 يومًا."
"يُمنع المستخدمون غير المعتمدين من تحميل أو حذف ملفات في النظام."
في هذه الوحدة، تعلمنا كيفية استخراج وصياغة متطلبات الأمان من مصادر مختلفة. كما استعرضنا أدوات مثل مصفوفة التحكم في الوصول ونماذج تحليل المخاطر.
الخطوة التالية في دورة تطوير البرمجيات الآمنة هي التصميم الأمني — فكيف نبني تطبيقًا يقلل الثغرات منذ البداية؟ سنتناول ذلك في الوحدة الثالثة.