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