Безопасность с этапа архитектуры ПО — а не после него
Наибольшие издержки большинства инцидентов безопасности восходят к архитектурным решениям, принятым в первые дни проекта.
Распространённая практика в разработке ПО такова: сначала создаётся продукт, а затем в конце проводится оценка безопасности или тест на проникновение. Такой порядок превращает безопасность в опциональный слой, добавляемый в конце — именно тогда, когда изменение архитектуры обходится дороже всего.
Многие серьёзные уязвимости — от неправильной обработки пользовательских сессий до слабого контроля доступа — коренятся в ранних архитектурных решениях, а не в деталях реализации. Проверка безопасности в конце проекта может выявить эти проблемы, но их устранение на этом этапе часто требует пересмотра фундаментальных частей системы.
Подход BAYA заключается в том, чтобы поднимать и решать вопросы безопасности — управление идентификацией, контроль доступа, границы доверия между сервисами — одновременно с проектированием основной архитектуры. Это требует больше времени на старте, но снижает общую стоимость проекта в долгосрочной перспективе.
Для технологических руководителей это означает один простой, но эффективный запрос к любому техническому партнёру: попросите показать документ по архитектуре безопасности прежде, чем увидите первую демоверсию.