День 2228.
Почему Разработчики Должны Заботиться о Безопасности
Разрабатывает ли кто-нибудь ПО, в котором сбои не имеют последствий? Даже незначительные сбои ПО могут иметь далеко идущие последствия: компании теряют миллионы, а пользователи доверие, и всё из-за сбоев, которые можно было бы предотвратить. Вспомним Crowdstrike. Не должны ли все разработчики думать о безопасности и надёжности, даже при создании приложений, которые кажутся некритичными?

Однозначно да. Принятие принципов разработки ПО, ориентированных на безопасность, может помочь создавать более надёжные, заслуживающие доверия и устойчивые системы. Речь не об оверинжиниринге, а о принятии ответственности за то, что происходит, когда что-то неизбежно идёт не так.

1. Всё ПО следует считать высокорискованным
Каждый сбой имеет последствия. Где-то потеря активов или дохода, а где-то от этого могут зависеть жизни. Этот принцип означает признание того, что каждая система взаимодействует с пользователями, данными или процессами способами, сбои в которых могут иметь каскадные эффекты. Готовясь к сбоям, разработчики улучшают коммуникацию, проектируют с оглядкой на надёжность, и в итоге предоставляют системы, которым пользователи могут доверять.

2. Проектирование для неизбежного сбоя
Сбои неизбежны. Каждая система в итоге столкнётся с условием, для которого она явно не была разработана, и то, как она реагирует на это, определяет, вызовет ли сбой серьёзную проблему.
В критически важных системах множественные сбои могут происходить без потери функциональности или данных. Но не нужно заходить так далеко для повседневного ПО.
Например, при активно-пассивном проектировании систем активный компонент обрабатывает запросы, а резервный остаётся бездействующим. Если активный компонент выходит из строя, пассивный берёт на себя управление, сводя к минимуму время простоя. Прокси и балансировщики нагрузки распределяют трафик между несколькими экземплярами, гарантируя, что отказ в одном не сможет вывести из строя всю систему.
Распределённые системы также упрощают изоляцию и восстановление после сбоев, поскольку отдельные сервисы можно перезапускать или изменять, не влияя на другие.
Разработчики также могут вести непрерывный мониторинг для раннего обнаружения проблем. Чем быстрее вы можете обнаружить и диагностировать проблему, тем быстрее вы сможете её исправить.
Тестирование на отказ не менее важно. Такие практики, как хаос-инжиниринг, подразумевающие намеренное внесение сбоев в систему, помогают выявлять слабые места и обеспечивать корректное восстановление.

3. Изучение критически важных для безопасности практик
Отрасли, где безопасность критически важна, вкладывают значительные средства в упреждающую защиту. Защитное программирование является ключевой практикой: надёжная проверка ввода, обработка ошибок и подготовка к крайним случаям. Простая ошибка ввода может привести к сбою сервиса, если её не обработать должным образом. Создание систем с учётом этого гарантирует, что вы всегда будете предвидеть неожиданности.
Нормой должно быть строгое тестирование, а не только модульные тесты. Рассмотрите тестирование с внедрением неисправностей (потерянные пакеты, повреждённые данные или недоступные ресурсы), чтобы наблюдать, как реагирует система.
Постепенная деградация — ещё один принцип, который стоит принять. Если система выходит из строя, она должна это делать безопасным и понятным образом. Система онлайн-платежей может временно отключить обработку кредитных карт, но позволить пользователям сохранять товары в корзине. Сервис потокового видео может снизить качество воспроизведения вместо полной остановки. Пользователи должны иметь возможность продолжать работу с ограниченной функциональностью, а не сталкиваться с полными отключениями.

Хотя разработка ПО с учётом безопасности может показаться излишним для некритических приложений, даже упрощённые версии этих принципов могут привести к более надёжному и удобному для пользователя ПО.

Источник: https://stackoverflow.blog/2025/01/22/why-all-developers-should-adopt-a-safety-critical-mindset/