دليل ENISA Playbook الأمان بالتصميم والإعدادات الافتراضية (Secure by Design & Default)

يصف Secure by Design كيف يُبنى النظام: تُنمذج التهديدات مبكرًا، وتُدمج الأنماط المعمارية والتشفير المُختبَر والإدارة المنهجية للثغرات الأمنية في عملية التطوير بدلًا من إضافتها لاحقًا. ويصف Secure by Default كيف يصل المنتج إلى العميل: بأكثر الإعدادات أمانًا ومعقولية من المصنع، دون أن يحتاج المستخدمون إلى معرفة متخصصة – آليات الحماية مفعّلة، ومن يُضعفها يفعل ذلك عن وعي. ويوزّع الـPlaybook مبادئ التصميم الـ14 على مجموعتَي Architectural Foundations وOperational Integrity، والمبادئ الافتراضية الـ8 على مجموعتَي Default Hardening وGuided Protection.

تشمل Architectural Foundations ‏(6) ‏Trust Boundaries ونمذجة التهديدات، وLeast Privilege، وبنية قوية للهوية والمصادقة، والحد الأدنى من سطح الهجوم، وDefence in Depth، وOpen Design. وتضيف Operational Integrity ‏(8) إدارة دورة الحياة، والتصميم المتمحور حول المستخدم، والبرمجة الآمنة والتحقق، والتسجيل والمراقبة، وإدارة الإعدادات والتغييرات، والاستجابة للحوادث، وإدارة الثغرات الأمنية والتصحيحات، وضوابط سلسلة التوريد بما في ذلك SBOM. وفي الجانب الافتراضي توجد الحد الأدنى من الخدمات الافتراضية، والوصول الأولي المقيّد، والاتصالات المشفّرة من المصنع، والهويات الفريدة للأجهزة (Default Hardening)، إضافةً إلى التهيئة الأمنية الإلزامية، والتحديثات التلقائية، والوضع الأمني الشفاف، وعمليات الاستعادة ونقل الملكية الآمنة (Guided Protection).

يتبع كل مبدأ الصيغة ذاتها المكوّنة من خمسة أقسام: المبدأ، والهدف، وقائمة تحقق بالإجراءات الأكثر فاعلية، والحد الأدنى من أدلة الإثبات (Minimum Evidence) – أصغر مجموعة من المخرجات التي تثبت التنفيذ – وبوابة إصدار بمعايير نجاح/إخفاق لمراجعات الإصدار أو لخط CI/CD. وينبغي أن تتكوّن أدلة الإثبات من مخرجات هندسية قائمة (مخططات معمارية، وسجلات CI، وتذاكر، وSBOMs)، ويجوز أن تخدم عدة Playbooks في آن واحد؛ والاستثناءات مسموح بها، لكن فقط إذا وُثّقت مع المسؤول وتاريخ المراجعة. وللإدخال توصي ENISA بثلاث مراحل: أولًا توضيح السياق والأولويات، ثم إرساء خط أساس هندسي من البرمجة الآمنة والتسجيل وإدارة الثغرات الأمنية وضوابط سلسلة التوريد – مستكملًا بـPlaybooks الإعدادات الافتراضية ذات الصلة بالمنتج – وأخيرًا توسيع التغطية والأتمتة. مهم: خطة المراحل تنظّم الجهد، لكنها لا تؤجّل أي التزامات قانونية.

بدلًا من التحليلات الثقيلة، يوصي الـPlaybook بـMinimum Viable Threat Model وفق الأسئلة الأربعة لإطار Shostack: على ماذا نعمل؟ ما الذي قد يسوء؟ ماذا نفعل حيال ذلك؟ هل كان ذلك جيدًا بما يكفي؟ والنتيجة صفحة واحدة: مخطط يضم المكوّنات وتدفقات البيانات وTrust Boundaries، وأهم خمسة إلى عشرة سيناريوهات تهديد، ولكل سيناريو ضوابط مع إعداد Secure Default وطريقة التحقق – إضافةً إلى محفّزات محدّدة لوقت وجوب تحديث النموذج. وتسمّي ENISA الأنماط المضادة النموذجية صراحةً: نمذجة التهديدات كتمرين امتثال لمرة واحدة، ونماذج مفرطة التفصيل بلا أثر على قرارات التصميم، وغياب التحديث بعد تغييرات المنتج. وبالنسبة للمنتجات ذات مكوّنات الذكاء الاصطناعي، ينبغي أن يتضمن النموذج أيضًا Prompt Injection وModel Poisoning وAdversarial Inputs.

الجزء الأكثر استشرافًا في المستند: تنتقل البيانات الأمنية من ملفات PDF الثابتة إلى مخرجات منظّمة قابلة للتوقيع (JSON/YAML) تربط ثلاث طبقات – الأهداف الأمنية (Control Layer)، والضوابط المنفّذة مع إعداداتها (Implementation Layer)، ونتائج الفحص المؤتمتة مع تجزئات أدلة الإثبات (Assessment & Verification Layer). ومن خلال المثال المحسوب بالكامل SafeGate-X1، وهو وحدة تحكم صناعية تعمل بـLinux، تُظهر ENISA كيف تصبح التهديدات قابلة للتتبّع عبر المبادئ وصولًا إلى بوابات الإصدار المؤتمتة – من بوابة فحص Nmap إلى اختبار نظام الملفات للقراءة فقط في CI. ولا تفرض ENISA عمدًا مخططًا جديدًا، بل تحيل إلى معايير قائمة مثل NIST OSCAL، وOWASP CycloneDX مع CDXA وVEX، وSPDX-3.0-Security-Profile، ومشاريع OpenSSF مثل Scorecard وSLSA، إضافةً إلى in-toto وSigstore. ويُوضَّح أيضًا: إقرار الشركة المصنِّعة ليس دليلًا قاطعًا – فالتحقق والتقييم المستقل يبقيان خطوتين منفصلتين.

يسرد الملحق B من الـPlaybook متطلبات الأمن السيبراني الأساسية الواردة في الملحق I من قانون المرونة السيبرانية الأوروبي (CRA)، ويربط الملحق C كل مبدأ من المبادئ الـ22 بها بشكل استرشادي – مثل التحديثات التلقائية بالملحق I الجزء I ‏2(c)، وضوابط سلسلة التوريد بالتزام SBOM في الجزء II، أو الوصول الأولي المقيّد بالإعداد الافتراضي الآمن وفق الجزء I ‏2(b). وبذلك يصلح المستند مدخلًا هندسيًا إلى تحليلات فجوات CRA: ترى الفرق أي Playbooks تخدم أي متطلبات، وتجمع عبر بوابات الإصدار أدلة إثبات متينة في وقت مبكر. وتؤكد ENISA في الوقت ذاته أن اتباع الـPlaybook لا يؤسس مطابقةً لـCRA – فتقييم المطابقة والمعايير المنسّقة والوثائق التقنية وفق اللائحة تبقى التزامات مستقلة.