Моделирование угроз по STRIDE: пошаговое руководство для команды
Продвинутое4 минРедакция Innovialabs
Коротко
Моделирование угроз по STRIDE — это схема движения данных в системе, отметки мест, где меняется уровень доверия, шесть стандартных вопросов к каждому элементу и перевод реальных рисков в приоритетные задачи бэклога ещё до написания кода.
Что такое моделирование угроз по STRIDE
Моделирование угроз (threat modeling) — это структурированный разговор о том, что может пойти не так в системе и что вы с этим сделаете. Лучше всего оно работает на этапе проектирования, когда исправить изъян — значит поправить схему, а не переписать сервис.
STRIDE — список из шести категорий угроз, созданный в Microsoft:
| Буква | Угроза | Какое свойство нарушает | Пример |
|---|---|---|---|
| S | Spoofing — подмена | Аутентификация | Вход по украденному токену |
| T | Tampering — искажение | Целостность | Изменение цены в запросе |
| R | Repudiation — отказ | Неотказуемость | Пользователь отрицает действие, и логов нет |
| I | Information disclosure — утечка | Конфиденциальность | API отдаёт данные чужих пользователей |
| D | Denial of service — отказ в обслуживании | Доступность | Тяжёлый эндпоинт кладёт базу |
| E | Elevation of privilege — повышение привилегий | Авторизация | Обычный пользователь вызывает админский метод |
Вся сессия строится на четырёх простых вопросах: Что мы строим? Что может пойти не так? Что мы с этим сделаем? Хорошо ли мы справились?
Шаг 1. Нарисуйте диаграмму потоков данных
Для диаграммы потоков данных (DFD) нужно всего пять типов элементов:
- Внешняя сущность — пользователь, система партнёра, платёжный провайдер, которых вы не контролируете.
- Процесс — ваш код: API, воркер, фронтенд.
- Хранилище — база данных, кэш, файловое хранилище, очередь.
- Поток данных — стрелка: какие данные и как передаются (HTTPS, gRPC, webhook).
- Граница доверия — пунктир там, где меняется уровень доверия.
Держите масштаб одной функции или одного сервиса. Схему на один экран обсуждают, схему во всю стену игнорируют. Инструменты вроде OWASP Threat Dragon помогают, но маркерная доска работает не хуже.
Шаг 2. Отметьте границы доверия
На границах живёт большинство угроз. Типичные границы:
- интернет и ваш бэкенд;
- бэкенд и сторонний API;
- публичный сервис и внутренняя админка;
- приложение и база данных;
- арендаторы в multi-tenant системе.
Каждая стрелка, пересекающая границу, — это вопрос: кто это отправляет, можно ли это подделать и что будет, если данные вредоносные?
Шаг 3. Примените STRIDE к каждому элементу
Идите по элементам. Не каждая категория применима везде; распространённое соответствие:
| Элемент | Актуальные категории |
|---|---|
| Внешняя сущность | S, R |
| Процесс | S, T, R, I, D, E |
| Хранилище | T, I, D (и R, если там логи) |
| Поток данных | T, I, D |
Формулируйте угрозу конкретным предложением: «Атакующий повторно отправляет перехваченный webhook и помечает неоплаченный заказ как оплаченный». Размытые записи вроде «взлом» нельзя ни исправить, ни протестировать.
Практические советы для сессии:
- Позовите разработчика, QA, кого-то из продукта и, если возможно, того, кто отвечает за инфраструктуру.
- Ограничьте время: 60–90 минут на одну функцию.
- Один человек ведёт и задаёт вопросы STRIDE, другой записывает.
- Не спорьте о решениях на этапе поиска. Сначала собираем, потом решаем.
Шаг 4. Расставьте приоритеты
Угроз найдётся больше, чем ресурсов на их закрытие. Простая шкала работает лучше точных формул:
- Ущерб: что теряется — деньги, персональные данные, доступность, репутация.
- Вероятность: насколько атака проста, нужен ли внутренний доступ, есть ли готовые инструменты.
Сведите это к уровням высокий / средний / низкий. Для каждой угрозы выберите реакцию: снизить (добавить защиту), устранить (убрать функцию или данные), передать (провайдеру, который это решает) или принять (зафиксировать решение и того, кто его принял).
Шаг 5. Превратите угрозы в задачи бэклога
Модель угроз, оставшаяся в документе, ничего не меняет. Каждая закрываемая угроза становится задачей с проверяемыми критериями приёмки:
Задача: проверять подпись webhook от платёжного провайдера. Угроза: Tampering/Spoofing на потоке «провайдер → бэкенд». Готово, когда: запросы без валидной подписи отклоняются; запросы старше допустимого окна отклоняются; оба случая покрыты тестом.
Связывайте задачи с моделью, добавьте проверки безопасности в definition of done и возвращайтесь к схеме при изменении архитектуры — новая интеграция, новое хранилище, новая роль пользователя.
Частые ошибки
- Моделировать всю компанию сразу. Начните с одной функции, которая работает с деньгами, персональными данными или правами доступа.
- Делать это после релиза. Тогда всё превращается в отчёт пентеста, на который нет времени.
- Искать только технические угрозы. Отказ от действий и злоупотребление бизнес-логикой, например бесконечные промокоды, важны не меньше.
- Нет ответственного. У каждого принятого риска должно быть имя и дата пересмотра.