Threat Modeling и контроль рисков

1) Принципы

1. Architectural First. Начинаем с контекстов, границ доверия и потоков данных.
2. Risk ≈ Likelihood × Impact. Меряем, а не чувствуем.
3. Defense in Depth. Контроли на каждом слое: код → протокол → платформа → люди.
4. Shift Left/Right. Ранние гейты в PR + мониторинг и реакция в проде.
5. Privacy by Design. Моделируем не только угрозы безопасности, но и риски приватности.
6. Automate Where Possible. Политики как код, автопроверки, «красные линии».

2) Инвентаризация: активы, субъекты, границы доверия

Активы: данные (PII, финансы, секреты), вычислительные ресурсы, ключи, доступы, бизнес-процессы.
Субъекты: пользователи, сервисы, админы, партнеры, внешние провайдеры.
Границы доверия: пользователи ↔ фронт, фронт ↔ API-шлюз, сервисы ↔ БД/кэши/очереди, регионы/облака.
Поверхность атаки: входные точки (API, вебхуки, UI, сети, CI/CD, supply chain).

mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end

3) Фреймворки угроз

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (процесс): от бизнес-целей и акторов угроз → технические детали → тестовые сценарии.

4) Оценка рисков

DREAD/OWASP Risk Rating или CVSS для уязвимостей.
Вероятность (L): мотив/возможности атакующего, сложность, экспозиция поверхности.
Влияние (I): финансы, юрриски, простои, утечки ПД.
Риск (R = L×I) → приоритезация и тритмент: Avoid / Reduce / Transfer / Accept.

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

Регистр рисков (минимум полей): `id, сценарий, STRIDE, актив, L, I, R, владельцы, контроли, статус, дата пересмотра`.

5) Контроли: Prevent / Detect / Respond

• Аутентификация/авторизация: OIDC/OAuth2, PoLP, RBAC/ABAC, сервис-креды короткого срока.
• Секреты/ключи: KMS/HSM, ротация, принцип «не знать», FPE/шифрование полей.
• Безопасные протоколы: TLS1.2+, mTLS, подписи вебхуков, идемпотентность и анти-replay.
• Валидация/санитария: схемы (JSON Schema/Proto), лимиты, нормализация.
• Изоляция: network policies, сегментация, sandbox, namespaces, bulkheads.

• Аудит-логи (неотрекаемые), корелляция в SIEM, алерты на аномалии.
• Мониторинг подписи и целостности (экспорт хэшей артефактов, attestation).
• Honeytokens/канарейки для раннего детекта утечки ключей.

• Runbook IR: классификация, изоляция, отзыв ключей, оповещения, форензика.
• Автоматический kill-switch/feature-flag, «черные списки» токенов.
• Уведомления пользователей/регуляторов при инцидентах с ПД.

6) SDL и гейты безопасности

В идеи/дизайне: threat model (RFC/ADR), чек-лист контролей.
В разработке: SAST/secret-scan, зависимостные сканы (SCA), политика зависимостей.
В сборке: SBOM, подпись артефактов, политика уязвимостей (CVSS пороги).
В деплое: OPA/Kyverno — политика IaC/манифестов (securityContext, сетевые политики, проброс секретов).
В проде: IDS/WAF, anomaly detection, canary-проверки, хаос-безопасность (например, истекший сертификат).

rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}

7) Supply Chain и доверие к артефактам

SBOM на каждый образ/пакет; обновления зависимостей — через бота/политику.
SLSA/Provenance: воспроизводимые сборки, подписи, attestations.
Контейнеры: минимальные образы, rootless, drop capabilities, read-only FS.
IaC-сканы: Terraform/Helm — политика по шифрованию, открытым портам, сетевым правилам.

8) Приватность и комплаенс

LINDDUN-карта угроз приватности, data minimization, псевдонимизация/анонимизация.
Политики хранения: TTL/ретеншн, «право на удаление», аудит доступа к ПД.
Локализация: гео-ограничения, «данные остаются в регионе».
Прозрачность: журналы обработки, уведомления и согласия.

9) Облака и периметры

Zero Trust: аутентификация каждого запроса, mTLS/OPA между сервисами.
Сегментация: VPC/подсети/SG, приватные эндпоинты, egress-контроль.
Ключи/секреты: KMS, rotation, короткие креды в CI (OIDC-федерация).
Резерв/DR: зашифрованные бэкапы, ключи отдельно, репетиции восстановления.

10) Красные/фиолетовые команды и tabletop-упражнения

Red Team: проверка гипотез угроз, социальная инженерия, эксплуатация цепочек.
Purple Team: совместная отладка детектов/алертов, улучшение playbook’ов IR.
Tabletop: сценарии «истек сертификат», «утечка ключей», «supply-chain компрометация». Результат — обновленные контроли и метрики.

11) Метрики зрелости и управление

Coverage: % сервисов с актуальным threat model и DFD.
MTTD/MTTR безопасности, доля инцидентов, пойманных контролями.
Policy pass-rate в CI, время закрытия уязвимостей по критичности.
Приватность: % датасетов с TTL/ILM, доля доступов с обоснованием.
Аудит: регулярность пересмотра регистра рисков (ежеквартально).

12) Шаблоны артефактов

12.1 Карточка риска (пример)

Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High  Impact: High  Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts  Статус: Reduce (в работе)
Дата пересмотра: 2025-12-01

12.2 Чек-лист дизайна

Идентифицированы активы и PII? Границы доверия отмечены?
DFD/контуры данных составлены и привязаны к ADR?
STRIDE/LINDDUN пройдены по каждой стрелке DFD?
Выбран тритмент риска; есть владельцы/сроки/DoD?
Политики как код добавлены (OPA/Kyverno/CI-гейты)?
План мониторинга/алертов и IR-runbook обновлены?
Privacy: минимизация, шифрование, TTL/ретеншн, локализация?

12.3 Политика вебхуков (псевдокод)

python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 200

13) Анти-паттерны

Threat model «для галочки» без DFD/инвариантов.
«Супер-периметр» без внутренней аутентификации сервиса-к-сервису.
Долгоживущие секреты в переменных окружения/репо.
Политики, не внедренные как код → ручное «забывается».
Логи с ПД без маскировки и без ретеншна/TTL.
Игнорирование supply chain (нет SBOM/подписей/сканов).
Принятие риска (Accept) без владельца и даты пересмотра.

14) Интеграция в процессы

RFC/ADR: каждое значимое решение содержит раздел «Угрозы и контроли».
Docs-as-Code: threat model, DFD, регистр рисков в версии рядом с кодом.
Release gates: релиз блокируется при провале SAST/SCA/SBOM-политик или отсутствующих контролях высокой критичности.
Обучение: плейбуки для разработчиков (секреты, подписи, PoLP), регулярные tabletop.

Заключение

Threat Modeling — это инженерная практика управления риском, а не одноразовый документ. Определите активы и границы доверия, примените STRIDE/LINDDUN, измерьте риск, зафиксируйте его в регистре и реализуйте контроли как код, встроив их в CI/CD и эксплуатацию. С метриками зрелости и регулярным пересмотром вы превратите безопасность в предсказуемую архитектурную способность — с понятной ценой, эффектом и скоростью.