Модель угроз: думать как защитник

Моделирование угроз — это структурированный способ заранее найти слабые места ещё на этапе проектирования.

Модель угроз — описание того, какие активы система защищает, от каких нарушителей, через какие точки входа и какими мерами.

Чинить уязвимости после взлома дорого и стыдно. Дешевле подумать о них заранее. Моделирование угроз — это не магия, а четыре простых вопроса, которые задаёт команда при проектировании.

Четыре вопроса

1. Что мы строим? Нарисуйте, как данные текут через систему: браузер → API → база данных → внешние сервисы.
2. Что может пойти не так? Где данные пересекают границу доверия, там и появляется риск.
3. Что мы с этим делаем? Для каждой угрозы — мера защиты.
4. Достаточно ли хорошо мы сделали? Проверка и пересмотр.

Поверхность атаки

Поверхность атаки — это все точки, через которые злоумышленник может взаимодействовать с системой: формы, API-эндпоинты, загрузка файлов, параметры URL, заголовки запросов, cookie. Чем она больше, тем больше нужно защищать. Хорошая практика — сокращать поверхность: отключать неиспользуемые эндпоинты, убирать лишние права.

STRIDE как чек-лист

STRIDE — популярная памятка категорий угроз.

Как защищаться

Включите моделирование угроз в процесс разработки: при проектировании новой фичи команда полчаса обсуждает, какие из категорий STRIDE применимы и какие меры нужны. Документируйте границы доверия — места, где «внешним» данным начинают доверять.

Частые ошибки разработчиков

• Откладывают вопросы безопасности «на потом», когда переписывать архитектуру уже поздно.
• Доверяют данным, пришедшим от клиента, считая, что фронтенд их уже проверил.
• Забывают про внутренних нарушителей и про скомпрометированные зависимости.

Итог

• Модель угроз отвечает на 4 вопроса: что строим, что не так, что делаем, достаточно ли.
• Поверхность атаки — все точки входа; её нужно сокращать.
• STRIDE — удобный чек-лист категорий угроз.