يُوصف الأمن غالباً كميزة. نرى هذا الوصف أضيق مما ينبغي. في المنتجات التقنية، الأمن نتيجة قرارات كثيرة عبر الهندسة والهوية وتطوير البرمجيات والبنية والتشغيل ومعالجة البيانات وتصميم المنتج. تبدأ تلك القرارات قبل مراجعة أمنية بوقت طويل. هذا هو المبدأ خلف مقاربتنا للأمن منذ التصميم في Quanizon.
الأمن يبدأ من الهندسة
ضوابط الأمن أكثر فاعلية عندما تجعلها الهندسة طبيعية. هذا يعني طرح أسئلة مبكراً: أين توجد البيانات الحسّاسة، وأي أنظمة ينبغي السماح لها بالتواصل، وكيف تُوثَّق هوية المستخدمين والخدمات، وأي مستوى وصول يحتاجه كل دور فعلاً، وأي إجراءات تحتاج أن تكون قابلة للتدقيق، وماذا يحدث عند اختراق اعتماد أو جهاز، وكيف يؤثر نموذج النشر في المخاطر، وأي خدمات خارجية تصبح جزءاً من حدود الثقة.
نادراً ما توجد إجابة واحدة عامة. منتج SaaS عام، ونظام مؤسسي داخلي، ونشر محلي يمكن أن تتطلب نماذج أمن مختلفة جداً. لذلك يبدأ الأمن منذ التصميم بفهم السياق لا بتطبيق القائمة نفسها في كل مكان.
الهوية حد أمني
كثير من الحوادث الأمنية في النهاية مشكلات تحكم في الوصول. لذلك الهوية والصلاحيات مركزيتان في نظرتنا إلى أمن المنتج. حيث يناسب ذلك، ينظر اتجاه المنتج والهندسة إلى مبادئ مثل أقل صلاحية، والتحكم في الوصول حسب الدور، وفصل المسؤوليات، ومصادقة قوية، وإدارة الجلسات والأجهزة، وتكامل الهوية المؤسسية، والرؤية الإدارية، وإجراءات امتياز قابلة للتدقيق.
ينبغي أن يجعل الأمن الجيد من الصعب على مستخدم أو مسؤول أو خدمة أو اعتماد مخترق الوصول إلى موارد لا يحتاجها.
التطوير الآمن عملية مستمرة
لا يبدأ الأمن عندما ينتهي التطوير. ينبغي أن يكون جزءاً من كيفية تصميم البرمجيات وتنفيذها ومراجعتها واختبارها ونشرها وصيانتها. بحسب المنتج وملف مخاطره، يمكن أن يشمل ذلك ممارسات حول مراجعة الشفرة، وإدارة الاعتمادات، والتحليل الساكن والديناميكي، وإدارة الأسرار، والتهيئة الآمنة، وتحصين البنية، وتقييم الثغرات، والتسجيل والمراقبة، واختبار الأمن قبل الإطلاق، وتتبع المشكلات المكتشفة ومعالجتها.
لا تجعل أداة واحدة البرمجيات آمنة. الأدوات تدعم عملية. وثقافة الهندسة حول كيفية مراجعة النتائج وترتيبها ومعالجتها ومنع تكرارها لا تقل أهمية.
قابلية التدقيق مهمة
لكثير من المنتجات المؤسسية، معرفة أن إجراءً وقع لا تكفي. قد تحتاج المؤسسات أن تفهم من نفّذه ومتى حدث وما الذي تغيّر وأي سياق إداري كان معنياً. لذلك تؤثر قابلية التدقيق في تصميم المنتج. هذا مهم خصوصاً حول الإجراءات الإدارية، وتغيّر الصلاحيات، وأحداث المصادقة، والتهيئة الحسّاسة، والوصول إلى البيانات، والاستثناءات الأمنية، والتغيّرات التشغيلية.
ليس كل منتج يحتاج العمق التدقيقي نفسه. لكن عندما تكون المساءلة جزءاً من المشكلة التشغيلية، لا ينبغي إضافة قابلية التدقيق لاحقاً.
حماية البيانات تعتمد على السياق
حماية البيانات أوسع من التشفير. التشفير أثناء النقل وفي حالة السكون يمكن أن يكون ضوابط مهمة، لكن الأمن يعتمد أيضاً على كيفية جمع البيانات وتصنيفها والوصول إليها والاحتفاظ بها ونسخها ونقلها وإزالتها في النهاية. ينبغي أن تتجنب المنتجات جمع بيانات لمجرد أنها قد تصبح مفيدة لاحقاً. ينبغي أن يكون الوصول مقصوداً. وينبغي أن يكون للاحتفاظ غرض. وينبغي أن تتلقى المعلومات الحسّاسة ضوابط تناسب مخاطرها.
وينبغي اعتبار بيئة النشر جزءاً من هذا النموذج. قد تحتاج مؤسسات مختلفة مقاربات مختلفة للسحابة أو الخاصة أو المحلية أو الهجينة.
الأمن والامتثال ليسا الادعاء نفسه
نحرص على اللغة المستخدمة حول الامتثال. قد يُصمَّم منتج مع متطلب تنظيمي أو معيار أو إطار أمني في الاعتبار دون أن يكون تلقائياً معتمداً أو ممتثلاً له. الامتثال الرسمي يعتمد على النطاق والتنفيذ والحوكمة وإجراءات التشغيل والأدلة والتقييم — والاعتماد المستقل حيث ينطبق.
لذلك نتجنب استخدام مصطلحات الامتثال كتسمية تسويقية عامة. عندما نشير إلى معايير أو متطلبات تنظيمية، هدفنا وصف اعتبار التصميم بدقة. وينبغي ألا تُطرح ادعاءات الاعتماد أو الامتثال الرسمي إلا عندما يمكن إثباتها للنطاق المعني.
الأمن لا ينتهي عند الإطلاق
يمكن أن يكون النظام آمناً أمام مجموعة مخاطر اليوم ومعرّضاً لمجموعة مختلفة غداً. اعتمادات البرمجيات تتطور، وتُكتشف ثغرات جديدة، وتكتسب المنتجات قدرات جديدة، وتتغيّر البنية، وتتطور أساليب الهجوم، ويتبنّى المستخدمون والمؤسسات المنتجات بطرق لم تُتوقَّع في الإطلاق الأول. لذلك يحتاج الأمن أن يتطور مع المنتج. هذا يتطلب مراقبة وصيانة وتصحيحاً ومراجعة واستعداداً لإعادة النظر في القرارات مع تغيّر الظروف.
فلسفة أمن عملية
الأمن منذ التصميم لا يعني ادعاء أن المخاطر يمكن إلغاؤها. يعني معاملة الأمن كمسؤولية هندسة ومنتج من البداية. بالنسبة إلى Quanizon، هذا يعني السعي لبناء منتجات تؤثر اعتبارات الأمن في الهندسة، والهوية، والصلاحيات، ومعالجة البيانات، وتطوير البرمجيات، والبنية، والنشر، والتشغيل، والصيانة طويلة المدى.
الهدف ليس الأمن كشعار. بل الأمن كجزء من كيفية بناء المنتج.