في كثير من المشاريع البرمجية، يُجدوَل الأمن كمرحلة: اختبار اختراق قبل الإطلاق ببضعة أسابيع. وعندها تكون المعمارية قد ثبتت، ونموذج البيانات قد اكتمل، فتتحول كل ملاحظة جوهرية إلى إعادة عمل مكلفة، أو إلى خطر «مقبول» لا يرتاح أحد لتوقيعه.
ينقل مبدأ الأمن بالتصميم هذه القرارات إلى حيث تكون تكلفتها في أدنى مستوياتها: المتطلبات، والمعمارية، وسير العمل الهندسي اليومي. والسؤال العملي للقيادات ليس كيف يصبحون خبراء أمن، بل ما الذي يجب أن يطلبوه من الشركاء الذين يبنون برمجياتهم، وكيف يتحققون من أن ذلك يُنفَّذ فعلًا.
اجعل الأمن متطلبًا لا مرحلة
اكتب متطلبات الأمن في كراسة الطلب وفي العقد بالدقة نفسها التي تكتب بها النطاق الوظيفي. ومن الطرق العملية لذلك الإحالة إلى معيار مرجعي معروف، مثل مستوى يناسب مخاطر النظام من معيار OWASP للتحقق من أمن التطبيقات (ASVS)، واشتراط نمذجة التهديدات أثناء التصميم: مراجعة منظمة لما قد يسوء، بمنهجية مثل STRIDE، تُحدَّث كلما تغيرت المعمارية.
عشرة متطلبات تطلبها من شريك التطوير
- نمذجة التهديدات لكل ميزة رئيسية وكل تغيير معماري، مع توثيق إجراءات المعالجة.
- دورة تطوير آمنة: مراجعة الشيفرة بين الزملاء وفق معايير أمنية، والتحليل الساكن، وفحص المكتبات الخارجية، وفحص الأسرار، مدمجة كلها في خط التكامل المستمر.
- هوية ووصول محكمان: دخول موحد عبر OpenID Connect حيث أمكن، وتحقق متعدد العوامل للوصول الإداري، وأدوار بأقل الصلاحيات اللازمة، وإدارة آمنة للجلسات.
- حماية البيانات: TLS لكل الاتصالات، وتشفير البيانات المخزنة بمفاتيح مُدارة، وحماية على مستوى الحقل للبيانات شديدة الحساسية، وعدم جمع إلا ما يحتاجه المنتج فعلًا.
- إدارة الأسرار: لا بيانات اعتماد في الشيفرة أو المستودعات أو رسائل المحادثة، بل أداة مخصصة لإدارة الأسرار مع تدوير دوري.
- سجلات التدقيق: تسجيل الأحداث ذات الصلة بالأمن في سجلات تكشف أي عبث، بمدة احتفاظ محددة، ودون كتابة بيانات شخصية حساسة فيها.
- فصل البيئات: لا تُنسخ بيانات الإنتاج إلى بيئات التطوير أو الاختبار دون إخفاء البيانات الحساسة فيها.
- اختبار مستقل: اختبار اختراق قبل الإطلاق وبعد كل تغيير جوهري، مع متابعة الملاحظات حتى إغلاقها.
- إدارة الثغرات: قائمة بمكونات البرمجيات (SBOM)، ومُدد متفق عليها لمعالجة الثغرات الحرجة.
- الاستجابة للحوادث: جهات اتصال مسماة، ومسارات تصعيد، ومُدد إخطار، ودليل تشغيل مُجرَّب.
وأضف إلى العقد بندًا أخيرًا: عند التسليم تستلم الشيفرة المصدرية، وملفات البنية التحتية كشيفرة، والتوثيق، وجميع بيانات الاعتماد، ويُلغى وصول الشريك إلى بيئة الإنتاج أو يُعاد تحديد نطاقه رسميًا.
مدّ المتطلبات إلى الأطراف الخارجية وميزات الذكاء الاصطناعي
التطبيقات الحديثة تُجمَّع بقدر ما تُكتب: حزم الدفع، وأدوات التحليلات، والمكتبات مفتوحة المصدر، وواجهات نماذج الذكاء الاصطناعي، كلها تصبح جزءًا من سطح الهجوم ومن مسارات البيانات لديك، فينبغي أن ينطبق عليها الانضباط نفسه.
- المكونات الخارجية: قائمة معتمدة بالحزم والخدمات، ومراجعة للبيانات التي يتلقاها كل منها، وفحص لتراخيص المكتبات مفتوحة المصدر.
- ميزات الذكاء الاصطناعي: قواعد واضحة للبيانات التي يجوز إرسالها إلى مزودي النماذج الخارجيين، وحماية من حقن التعليمات، ومراجعة بشرية للإجراءات ذات الأثر المالي أو القانوني.
- سلسلة التوريد البرمجية: بناء موقّع، وفروع محمية، ووصول مضبوط إلى خط النشر، حتى يكون ما يصل إلى الإنتاج هو بالضبط ما رُوجع.
السياق التنظيمي في المملكة
ينبغي للمنشآت العاملة في المملكة الرجوع إلى الأطر الوطنية ذات الصلة مبكرًا، أثناء كتابة المتطلبات لا بعد بناء النظام. ومن أبرزها عادةً: نظام حماية البيانات الشخصية ولوائحه التنفيذية الذي تشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا)، والضوابط الأساسية للأمن السيبراني (ECC) الصادرة عن الهيئة الوطنية للأمن السيبراني وما يرتبط بها من أطر مثل ضوابط الأمن السيبراني للحوسبة السحابية، إضافة إلى المتطلبات القطاعية لجهات مثل البنك المركزي السعودي للمؤسسات المالية. والشريك التقني الكفء يستطيع ترجمة هذه الأطر إلى ضوابط تقنية محددة وأدلة قابلة للتحقق.
أسئلة تطرحها عند اختيار المورّد
- «هل يمكنكم أن تعرضوا علينا نموذج تهديدات من مشروع سابق بعد حجب تفاصيله؟»
- «كيف يصل سرٌّ ما إلى بيئة الإنتاج، ومن يستطيع قراءته؟»
- «أُعلنت مساء الخميس ثغرة حرجة في إحدى المكتبات التي نعتمد عليها. ماذا يحدث بعد ذلك؟»
- «من في فريقكم سيصل إلى بيانات الإنتاج لدينا، وكيف يُسجَّل هذا الوصول ويُراجَع؟»
- «ما الذي نستلمه بالتحديد عند التسليم، وبأي صيغة؟»
الشريك الجيد يجيب بتفاصيل ومستندات. أما الطمأنة العامة فهي في حد ذاتها إجابة.
إشارات تحذير
- «سنهتم بالأمن في نهاية المشروع».
- حسابات إدارية مشتركة، أو بيانات اعتماد تُرسل عبر البريد أو المحادثة.
- غياب بيئة اختبار منفصلة، أو استخدام بيانات الإنتاج في الاختبار.
- التردد في السماح باختبار اختراق مستقل.
- إجابات غير واضحة عن مكان استضافة البيانات ومن يصل إليها.
الأمن صفة في طريقة بناء البرمجيات، لا ميزة تُضاف قبل الإطلاق.
كيف يبدو الوضع السليم يومًا بيوم؟
في المشروع السليم، يظهر الأمن ضمن تعريف الإنجاز لكل ميزة، لا في تقرير منفصل في النهاية. فطلبات دمج الشيفرة تُظهر اجتياز الفحوص الأمنية، والقرارات المعمارية تسجل مفاضلاتها الأمنية، وتتلقى القيادة أدلة، من نتائج الفحص وتقارير الاختبار ومراجعات الصلاحيات، لا وعودًا. هذه الأدلة هي ما يمكّن القائد من اعتماد الإطلاق بثقة، وهي المعيار الذي تلتزم به AMA GROUP في أعمال هندسة الأمن.