تصميم آمن (حوسبة)
في هندسة البرمجيات، آمن تصميميًا أو آمن بالتصميم تعني أن البرمجية مصممة لتكون آمنة بشكل أساسي.
تأخذ الاستراتيجيات والتكتيكات والأنماط الأمنية البديلة في الاعتبار في بداية تصميم البرمجية، ويختار أفضلها وتنفيذها حسب البنية، ويتم استخدامها كمبادئ توجيهية للمطورين. [1] كما يتم تشجيعه لاستخدام أنماط تصميم إستراتيجية لها تأثيرات مفيدة على الأمن، حتى لو لم تكن أنماط التصميم في الأصل مصصمة مع أخذ الأمن في الاعتبار. [2]
أصبح التصميم الآمن نهج التطوير السائد شيئًا فشيئًا لضمان أمان وخصوصية أنظمة البرمجيات، حيث يتم أخذ الأمان في الاعتبار ودمجه في النظام في كل طبقة ويبدأ ببنية قوية. تعتمد قرارات تصميم البنية الأمنية على استراتيجيات وتكتيكات وأنماط أمنية معروفة يتم تعريفها على أنها تقنيات قابلة لإعادة الاستخدام لتحقيق اهتمامات محددة تتعلق بالجودة. توفر التكتيكات/الأنماط الأمنية حلولًا لفرض متطلبات مطلوبة كالمصادقة والترخيص والسرية التامة وسلامة البيانات والخصوصية والمساءلة والتوافر والسلامة وعدم التنصل، حتى عندما يتعرض النظام للهجوم. [3] من أجل ضمان أمان نظام برمجي، ليس من المهم فقط تصميم بنية أمنية قوية مقصودة بل من الضروري أيضًا رسم استراتيجيات وتكتيكات وأنماط أمنية محدثة لتطوير البرمجيات من أجل الحفاظ على استمرارية الأمن.
توقع الهجمات
عدليجب افتراض حدوث هجمات ضارة على البرمجيات، ويتم توخي الحذر لتقليل التأثير. يُتوقع وجود ثغرات أمنية إلى جانب إدخال غير صالح من المستخدم. [4] يرتبط ارتباطًا وثيقًا بممارسة استخدام تصميم "جيد" للبرمجية -مثل تصميم مقاد بالنطاق- كوسيلة لزيادة الأمان عن طريق تقليل مخاطر إتاحة فرص لثغرات أمنية، حتى على الرغم من أن مبادئ التصميم المستخدمة لم يتم تصميمها في الأصل لأغراض أمنية.
تجنب الأمن من خلال الغموض
عدلبشكل عام، التصميمات التي تعمل بشكل جيد لا تعتمد على كونها سرية. في كثير من الأحيان تقلل السرية من عدد المهاجمين عن طريق تثبيط مجموعة فرعية من التهديد. المنطق هو أنه إذا كانت هناك زيادة في التعقيد بالنسبة للمهاجم، فإن جهد المهاجم المتزايد لتسوية الهدف يثبط عزيمته. في حين أن هذه التقنية تنطوي على تقليل المخاطر الكامنة فإن مجموعة لا حصر لها تقريبًا من الجهات الفاعلة والتقنيات التهديدية المطبقة بمرور الوقت ستؤدي إلى فشل معظم الأساليب السرية. ليس بالضرورة لكن الأمان المناسب يسمح عادةً للجميع بمعرفة تصميمه وفهمه لأنه آمن. ويمتاز بالسماح لعديد من الأشخاص بإلقاء نظرة على نص الحاسوب البرمجي، مما يزيد من احتمالات العثور على أي عيوب في وقت أقرب (راجع قانون لينوس). ويعاب بالسماح للمهاجمين بالحصول على الرمز البرمجي، مما يسهل عليهم العثور على نقاط ضعف لاستغلالها. ومع ذلك، يُعتقد بشكل عام أن ميزة المصدر المفتوح تفوق عيوبه.
صلاحيات أقل
عدلومن المهم أيضًا أن يعمل كل شيء بأقل قدر ممكن من الصلاحيات. على سبيل المثال، يمكن أن يتمتع خادم ويب يعمل كمستخدم إداري ("جذر" أو "مسؤول") بامتياز إزالة الملفات والمستخدمين. وبالتالي فإن وجود خلل في مثل هذه البرمجية يمكن أن يعرض النظام بأكمله للخطر، في حين أن خادم ويب يعمل داخل بيئة معزولة، ويتمتع فقط بالامتيازات الخاصة بوظائف الشبكة ونظام الملفات المطلوبة، فلا يمكنه تعريض النظام الذي يعمل عليه للخطر ما لم يكن الأمان المحيط به في حد ذاته معيب أيضا.
المنهجيات
عدليجب أن يكون التصميم الآمن في الاعتبار خلال جميع مراحل دورة حياة التطوير (أيًا كانت عملية تطوير البرمجيات المختارة). توجد بضعة منهجيات تطوير تصميم آمن معدة مسبقًا.
المعايير والتشريعات
عدلتوجد معايير وتشريعات لمساعدة التصميم الآمن بالتحكم في تعريف "آمن" وتوفير خطوات محددة لاختبار الأنظمة الآمنة ودمجها.
بعض الأمثلة على المعايير التي تغطي أو تتطرق إلى مبادئ التصميم الآمن:
- معيار المعهد الأوروبي لمعايير الاتصالات TS 103 645 [5] والذي تم تضمينه جزئيًا في "مقترحات حكومة المملكة المتحدة لتنظيم الأمن السيبراني للمنتجات الذكية الاستهلاكية" [6]
- تغطي سلسلة ISO/IEC 27000 العديد من جوانب التصميم الآمن.
بنيات الخادم/العميل
عدلفي بنيات الخادم/العميل، قد لا تكون البرمجية الموجودة في الطرف الآخر عميلاً معتمدًا وقد لا يكون خادم العميل خادمًا معتمدًا. وحتى عندما يكون الأمر كذلك، فإن هجوم الوسيط يمكن أن يضر بالاتصالات.
غالبًا ما تكون أسهل طريقة لكسر أمان نظام العميل/الخادم هي عدم الانتقال مباشرةً إلى آليات الأمان، بل بالالتفاف حولها. يعد هجوم الوسيط مثالًا بسيطًا على ذلك، حيث يمكن استخدامه لجمع التفاصيل لانتحال شخصية المستخدم. ولهذا السبب من المهم مراعاة التعمية والتلبيد وآليات أمان أخرى في التصميم للتيقن من أن المعلومات التي جمعها مهاجم لن تسمح بالوصول.
الميزة الرئيسية الأخرى لتصميم أمان خادم العميل هي ممارسة البرمجة الجيدة. على سبيل المثال، يمكن أن يساعد اتباع هيكل تصميم برمجي معروف -مثل العميل والوسيط- في تصميم هيكل متين. علاوة على ذلك، إذا كان سيتم تعديل البرمجية في المستقبل، فمن الأهم أن يتبع أساسًا منطقيًا للفصل بين العميل والخادم. وذلك لأنه إذا جاء مبرمج ولم يتمكن من فهم ديناميكيات البرمجية بوضوح، فقد ينتهي به الأمر إلى إضافة أو تغيير شيء قد يسبب ثغرة أمنية. حتى مع أفضل التصاميم، يظل هذا احتمالًا واردًا، ولكن كلما كان توحيد التصميم أفضل، قلت فرصة حدوث ذلك.
أنظر أيضا
عدل- أمن الحاسوب
- معايير الأمن السيبراني
- تصلب
- مستويات مستقلة متعددة من الأمان
- آمن بشكل افتراضي
- الأمن من خلال الغموض
- ضمان أمن البرمجيات
مراجع
عدل- ^ Santos، Joanna C. S.؛ Tarrit، Katy؛ Mirakhorli، Mehdi (2017). "A Catalog of Security Architecture Weaknesses". 2017 IEEE International Conference on Software Architecture Workshops (ICSAW). ص. 220–223. DOI:10.1109/ICSAW.2017.25. ISBN:978-1-5090-4793-2. S2CID:19534342.
- ^ Dan Bergh Johnsson؛ Daniel Deogun؛ Daniel Sawano (2019). Secure By Design. Manning Publications. ISBN:9781617294358.
- ^ Hafiz، Munawar؛ Adamczyk، Paul؛ Johnson، Ralph E. (أكتوبر 2012). "Growing a pattern language (For security)". Proceedings of the ACM international symposium on New ideas, new paradigms, and reflections on programming and software. ص. 139–158. DOI:10.1145/2384592.2384607. ISBN:9781450315623. S2CID:17206801.
- ^ Dougherty، Chad؛ Sayre، Kirk؛ Seacord، Robert C.؛ Svoboda، David؛ Togashi، Kazuya (أكتوبر 2009). "Secure Design Patterns". DOI:10.1184/R1/6583640.v1.
{{استشهاد بدورية محكمة}}: الاستشهاد بدورية محكمة يطلب|دورية محكمة=(مساعدة) - ^ "ETSI TS 103 645" (PDF). مؤرشف من الأصل (PDF) في 2024-05-28.
- ^ "Policy paper: Proposals for regulating consumer smart product cyber security - call for views". مؤرشف من الأصل في 2024-05-04.
