التصميم الموثوق
مبادئ التصميم الآمن
Categories:
معمارية الأمان ومبادئ التصميم
العناصر الثلاثة للأمان ومبادئ تصميم الأمان
- السلامة (Integrity)
- التوفر (Availability)
- السرية (Confidentiality)
مبدأ التصميم المفتوح
Open Design
- لا ينبغي أن يكون التصميم سراً، التصميم المفتوح أكثر أماناً.
- لا يعتمد الأمان على السرية.
مبدأ الفشل-الافتراضي الآمن
Fail-safe defaults
- تُستند قرارات الوصول إلى “السماح”، وليس إلى “الرفض”.
- بشكل افتراضي لا يُسمح بالوصول، وتُستخدم آليات الحماية فقط لتحديد الحالات المسموح بالوصول إليها.
- السلامة في حالة الفشل: يجب أن يكون لأي نظام معقد آلية أمان طارئة بعد فشل الوظيفة، كما يجب الحذر من رسائل الخطأ وسجلات الأحداث لمنع تسرب المعلومات.
- الأمان الافتراضي: يجب أن تكون التكوينات الافتراضية للنظام آمنة في حالتها الأولية، وتُوفر أقصى قدر من الأمان باستخدام أقل عدد ممكن من الخدمات والنظام.
مبدأ فصل الصلاحيات
Separation of Privilege
- آلية الحماية التي تتطلب مفتاحين لفتح القفل أقوى وأكثر مرونة من تلك التي تتطلب مفتاحاً واحداً.
- أهداف فصل الصلاحيات:
- منع تضارب المصالح، وسوء استخدام السلطة الفردية
- تفكيك صلاحية مهمة إلى صلاحيات متعددة، لجعل من الصعب على المهاجمين الوصول إلى الكائنات التي تحتاج إلى الحماية، وبالتالي زيادة الأمان.
- فصل مسؤوليات وصلاحيات العمليات المختلفة
يمكن للنظام ضبط 3 أدوار افتراضية، حيث تكون صلاحيات حسابات النظام مستقلة بين بعضها البعض، وتُفصل المسؤوليات:
- مسؤول النظام: مسؤول عن إدارة المستخدمين اليومية للنظام، وإدارة التكوين.
- مسؤول الأمان: مسؤول عن تفعيل وإيقاف حالة المستخدم، وتكوين الأمان.
- مدقق الأمان: مسؤول عن مراجعة عمليات الاثنين السابقين، ويملك صلاحية تصدير السجلات لضمان إمكانية تتبع جميع عمليات المستخدمين في النظام.
مبدأ أقل صلاحيات
Least Privilege
- يجب أن يستخدم كل مستخدم وكل برنامج في النظام أقل مجموعة صلاحيات ضرورية لإنجاز العمل.
- التأكد من أن التطبيقات تستخدم أقل صلاحيات ممكنة للتشغيل.
- عند تشغيل مختلف البرامج للمستخدمين في النظام، مثل قواعد البيانات، وخدمات الويب، يجب الانتباه إلى تشغيلها أو الاتصال بها بحساب صلاحياته أدنى، وليس بحساب صلاحياته العليا في النظام.
- عند إنشاء حساب جديد، يتم تعيينه افتراضياً لأدوار ذات صلاحيات أقل.
مبدأ الاقتصاد في الآلية
Economy of Mechanism
- الحفاظ على تصميم النظام وكتابته برمجياً بأبسط صورة ممكنة، وأكثر إحكاماً.
- كلما كان تصميم البرمجيات أكثر تعقيداً، زاد احتمال ظهور الأخطاء (bug) في الكود، وإذا كان التصميم أنيقاً قدر الإمكان، فستقل احتمالية حدوث مشكلات أمنية.
- حذف الكود والأجزاء الوظيفية غير الضرورية، فالاحتفاظ بها لا يزيد من هجوم النظام.
- تصميم مكونات يمكن إعادة استخدامها لتقليل الكود المكرر.
- اقتصادي ومناسب: بسيط، أنيق، معياري.
- لا تبالغ في التصميم
مبدأ أقل تعميم
Least Common Mechanism
- تجنب قدر الإمكان توفير سيناريوهات حيث يشارك كائنات متعددة نفس المورد، ويجب تقليل عدد ونسبة استخدام الموارد المشتركة بين الكائنات.
- تُوفر الكائنات المشتركة قنوات خطرة محتملة لتدفق المعلومات والتفاعل غير المقصود، لذا يجب تقليل قدر الإمكان توفير سيناريوهات حيث يشارك كائنات متعددة نفس المورد.
- إذا لم يكن كائن أو أكثر راضياً عن الخدمة التي تقدمها آلية المشاركة، فيمكنهم اختيار عدم استخدام آلية المشاركة على الإطلاق لتجنب هجوم غير مباشر من أخطاء الكائنات الأخرى.
- تقليل موارد الذاكرة المشتركة
- تقليل منافذ الربط المشتركة
- تقليل الاتصالات، والدفاع ضد هجمات DoS
مبدأ التحكيم الكامل
Complete Mediation
- يتطلب مبدأ التحكيم الكامل أن تخضع كل محاولة وصول إلى كل كائن لفحص أمني.
- عندما يحاول الكائن الوصول إلى الكائن الآخر، يتحقق النظام في كل مرة مما إذا كان الكائن لديه تلك الصلاحية.
- من الأفضل قدر الإمكان أن يقوم مالك المورد باتخاذ قرارات التحكم في الوصول، على سبيل المثال إذا كان عنوان URL، فيتحقق منه الخادم الخلفي، ولا يجب إجراء التحقق في الواجهة الأمامية.
- الانتباه بشكل خاص إلى استخدام وفحص الذاكرة المؤقتة، حيث لا يمكن ضمان أن معلومات الذاكرة المؤقتة لم يتم العبث بها من قبل المتسللين. على سبيل المثال: التزوير في ذاكرة DNS المؤقتة.
مبدأ القابلية النفسية
Psychological Acceptability
- قد تضيف آليات الأمان عبئاً إضافياً على المستخدمين، ولكن يجب أن يكون هذا العبء أقل ما يمكن ومعقول.
- يجب أن تكون آليات الأمان صديقة قدر الإمكان لمستخدمي النظام، وتسهل عليهم استخدام وفهم النظام.
- إذا كانت طريقة التكوين معقدة جداً ومتعبة، فقد يقوم مسؤول النظام无意اً بتكوين خيار خاطئ، مما يجعل النظام أقل أماناً.
- يرتبط هذا المبدأ عموماً بالتفاعل بين الإنسان والحاسوب، وتصميم واجهة المستخدم المركزة حول المستخدم (UCD).
مبدأ الدفاع العميق
Defense in Depth الدفاع العميق هو مبدأ دفاعي شامل يتطلب مستوى عالٍ جداً من المهارة، ويتطلب عموماً من مهندس المعمارية استخدام مبادئ التصميم الأمني المختلفة الأخرى بشكل شامل، واستخدام نقاط متعددة وآليات أمنية متعددة للتحقق، واتخاذ نظرة شاملة على مستوى معمارية النظام للتركيز على آلية الدفاع الأمني على مستوى النظام، ولا يمكن الاعتماد على آلية أمنية واحدة فقط.