Моделирование угроз нужно не ради красивой таблицы, а ради способности увидеть слабое место системы до того, как им воспользуются.
Глава показывает, как диаграммы потоков данных, STRIDE и LINDDUN переводят разговор о безопасности и приватности данных в разбор конкретных потоков, точек входа, границ доверия и мер защиты.
На интервью этот материал особенно полезен тем, что даёт чёткий маршрут ответа: актив, поток, угроза, мера защиты, остаточный риск вместо абстрактного разговора про безопасность вообще.
Практическая польза главы
Практика проектирования
Фиксируйте активы, потоки данных, границы доверия и категории угроз до того, как архитектурное решение станет дорогим для изменения.
Качество решений
Проверяйте меры защиты через конкретные угрозы STRIDE и LINDDUN, а не через общий список пожеланий по безопасности.
Аргументация на интервью
Стройте ответ как цепочку: актив, поток данных, угроза, мера защиты, остаточный риск. Так легче показать зрелое мышление.
Формулировка компромиссов
Явно описывайте цену мер защиты: сложность реализации, задержку, стоимость эксплуатации, приватность данных и регуляторные ограничения.
Контекст
OWASP Top 10 в контексте System Design
OWASP отвечает на вопрос «что защищать», а STRIDE и LINDDUN помогают системно находить угрозы.
переводит разговор о безопасности и приватности данных из общих опасений в проверяемые архитектурные решения.
В этой главе мы идём от активов и к , категориям STRIDE и LINDDUN, , приоритизации риска и бэклогу мер защиты.
Когда выбирать STRIDE, LINDDUN или оба подхода
STRIDE: угрозы безопасности
Подходит для анализа целостности, доступности и прав доступа: , , и .
LINDDUN: риски приватности данных
Помогает разобрать действий, , раскрытие персональных данных и .
STRIDE + LINDDUN: цифровые продукты с PII
Комбинируйте оба подхода, если одновременно важны угрозы безопасности и риски обработки персональных данных.
STRIDE: категории угроз и архитектурные меры защиты
SПодмена личности
Spoofing
Ключевой вопрос: Кто может выдать себя за доверенный субъект?
Пример угрозы: Подмена для доступа к внутреннему API.
Меры защиты: MFA, , подписанные токены, идентичность устройства или рабочей нагрузки.
TНесанкционированное изменение
Tampering
Ключевой вопрос: Где данные могут быть изменены без разрешения?
Пример угрозы: Подмена между BFF и серверным сервисом.
Меры защиты: Подписи сообщений, , и строгая авторизация.
RОтказ от совершённого действия
Repudiation
Ключевой вопрос: Кто может отрицать уже выполненное действие?
Пример угрозы: Пользователь оспаривает оплату, а у системы нет доказуемого .
Меры защиты: Связанные журналы аудита, отметки времени, идентификаторы запросов и доказуемая история действий.
IРаскрытие информации
Information Disclosure
Ключевой вопрос: Какие данные могут утечь?
Пример угрозы: PII попадает в логи и трассировки с широким доступом.
Меры защиты: , маскирование, шифрование и доступ по политике.
DОтказ в обслуживании
Denial of Service
Ключевой вопрос: Что может вывести сервис из строя или исчерпать его ресурсы?
Пример угрозы: Публичный API перегружен бот-трафиком без ограничения частоты запросов.
Меры защиты: Ограничение частоты запросов, очереди, границы автомасштабирования, размыкатели цепи и .
EПовышение привилегий
Elevation of Privilege
Ключевой вопрос: Как атакующий может получить более широкие права?
Пример угрозы: IDOR позволяет перейти с роли пользователя на возможности администратора.
Меры защиты: , проверка политик на каждом переходе, границы разрешений и регулярный пересмотр прав.
LINDDUN: риски приватности данных и меры защиты
LСвязываемость
Linkability
Ключевой вопрос: Можно ли связать разные действия одного пользователя?
Пример риска: Один идентификатор устройства связывает поведение пользователя в разных контекстах.
Меры защиты: , ротация идентификаторов и разделение наборов данных.
IИдентифицируемость
Identifiability
Ключевой вопрос: Можно ли восстановить личность по доступным данным?
Пример риска: Комбинация индекса, даты рождения и пола снова идентифицирует пользователя.
Меры защиты: , агрегация, k-anonymity и дифференциальная приватность там, где она уместна.
NНеотказуемость в контексте приватности
Non-repudiation
Ключевой вопрос: Не нарушает ли доказуемость действий ожидания приватности?
Пример риска: Подробные журналы операций позволяют восстановить полную историю поведения пользователя.
Меры защиты: Хранение по политике, ограниченный доступ к аудиту и .
DОбнаруживаемость
Detectability
Ключевой вопрос: Можно ли обнаружить наличие пользователя или его чувствительного состояния?
Пример риска: Время ответа показывает, существует ли аккаунт.
Меры защиты: Ответы с постоянным временем, и маскировка трафика для чувствительных сценариев.
DРаскрытие информации
Disclosure of Information
Ключевой вопрос: Где возможна утечка персональных данных?
Пример риска: Экспорт данных по умолчанию отдаёт чувствительные поля.
Меры защиты: Шифрование, редактирование чувствительных полей, DLP и доступ к данным по минимально необходимым правам.
UНеосведомлённость
Unawareness
Ключевой вопрос: Понимает ли пользователь, какие данные собираются и зачем?
Пример риска: Телеметрия собирается без понятного сценария согласия пользователя.
Меры защиты: , контекстные уведомления и прозрачное объяснение использования данных.
NНесоответствие требованиям
Non-compliance
Ключевой вопрос: Соответствуют ли процессы закону и внутренним политикам?
Пример риска: Данные хранятся дольше разрешённого срока.
Меры защиты: Политики хранения, учёт и автоматические проверки соблюдения требований.
Пошаговый процесс моделирования угроз
1. Зафиксировать границы и архитектурный контекст
Определите границы системы, типы пользователей, доверенные и недоверенные зоны, а также бизнес-активы с наибольшим риском.
Результат: Список активов и .
2. Построить диаграмму потоков данных
Отрисуйте между клиентом, шлюзом API, сервисами, очередями и хранилищами. Отдельно выделите .
Результат: с явными границами доверия.
3. Прогнать STRIDE по каждому элементу схемы
Для процесса, , потока данных и задайте вопросы STRIDE и зафиксируйте конкретные угрозы безопасности.
Результат: Черновой безопасности.
4. Прогнать LINDDUN по потокам PII
Для идентификаторов, профилей, аналитики и событий оцените риски приватности данных и требования к прозрачности обработки.
Результат: Реестр рисков приватности и .
5. Приоритизировать угрозы и назначить ответственных
Оцените вероятность и ущерб, выберите или принятие , затем назначьте ответственного за каждую запись.
Результат: Приоритизированный .
6. Встроить меры защиты в жизненный цикл изменений
Добавьте меры защиты в ADR, проверки CI/CD, и план .
Результат: План внедрения и критерии приёмки.
Практический пример: оформление заказа и профиль пользователя
Checkout API
STRIDE: Подмена личности: поддельный токен клиента; несанкционированное изменение: изменение суммы заказа; отказ в обслуживании: перегрузка публичного API.
LINDDUN: Обнаруживаемость: существование аккаунта видно по разным ошибкам; раскрытие информации: PII попадает в логи оплаты.
Меры защиты: , подписанный JWT, , ограничение частоты запросов, и единообразные ответы об ошибках.
User Profile Service
STRIDE: Повышение привилегий: чтение чужого профиля; отказ от совершённого действия: нет доказуемого аудита изменений.
LINDDUN: Связываемость: объединение поведенческих событий; несоответствие требованиям: нарушение сроков хранения профилей.
Меры защиты: Проверки ABAC/ReBAC, неизменяемый журнал аудита, псевдонимные аналитические идентификаторы и автоматизация сроков хранения.
Артефакты после сессии
- Диаграмма потоков данных с явными границами доверия и перечнем внешних зависимостей.
- STRIDE + LINDDUN с уровнем критичности, ответственным и .
- Список обязательных мер защиты для архитектуры и CI/CD.
- Набор тестов безопасности и приватности, связанных с конкретными угрозами.
- План регулярного пересмотра при изменениях архитектуры.
Типичные антипаттерны и рекомендации
Типичные антипаттерны
Проводить моделирование угроз один раз перед релизом только для отчётности.
Ограничиваться STRIDE и игнорировать риски приватности данных в продуктах с PII.
Не фиксировать ответственных и сроки закрытия угроз, оставляя список без исполнения.
Не обновлять модель угроз после новых интеграций и потоков данных.
Рекомендации
Включайте в Definition of Ready для крупных архитектурных изменений.
Начинайте с простой диаграммы потоков данных и коротких сессий, а не с попытки сразу покрыть всю систему.
Связывайте каждую угрозу высокого риска с конкретной мерой защиты и проверкой в CI/CD.
Комбинируйте STRIDE и LINDDUN для систем, где важны и безопасность, и приватность данных.
Связанные материалы
Связанные главы
- OWASP Top 10 в контексте System Design - помогает связать выявленные угрозы с архитектурными мерами защиты и приоритизацией бэклога безопасности.
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - закрывает важную часть STRIDE-рисков через корректные потоки идентичности и контроль прав.
- API Security Patterns - переводит модель угроз в прикладные API-контроли: валидацию, защиту от злоупотреблений и управление ключами или токенами.
- Zero Trust: современный подход к безопасности архитектуры - усиливает модель угроз непрерывной проверкой доверия и сегментацией границ доверия.
- Data Governance & Compliance - добавляет управленческий и регуляторный взгляд на LINDDUN-риски при работе с персональными данными.