Слайд 3. Threat Modeling: найти угрозы до атакующего

Блок 1. Фундамент архитектурного подхода Threat Modeling: найти угрозы до атакующего Слайд 3 / 15

ДИАГРАММА ПОТОКОВ ДАННЫХ (DATA FLOW DIAGRAM): ТИПИЧНОЕ ВЕБ-ПРИЛОЖЕНИЕ

Пользователь

→

Браузер

→

S+T+D

Шлюз API (API Gateway)

S+T+D

→

T+I

Сервер приложений (App Server)

T+R+E

→

I+T

База данных (Database)

I+T+E

Data Flow Diagram — пример архитектуры предприятия

УГРОЗА → КОНТРОЛЬ → СТАТУС

Подмена идентичности (Spoofing) на входеMFA (Multi-Factor Authentication / многофакторная аутентификация) на API GatewayРеализовано (Implemented)

Подмена данных (Tampering) в транзитеTLS 1.3 обязательно (mandatory)Реализовано (Implemented)

Раскрытие информации (Info disclosure) в БДШифрование на уровне колонок для PII (Personally Identifiable Information / персональные данные)Запланировано (Planned)

Повышение привилегий (Elevation of privilege)RBAC (Role-Based Access Control / управление доступом на основе ролей) + регулярная проверка доступовНе рассмотрено (Not Addressed)

STRIDE: МЕТОДОЛОГИЯ MICROSOFT

SSpoofing, подмена идентичности (фишинг, кража учётных данных)

TTampering, подмена данных (инъекции, модификация запросов)

RRepudiation, отказ от действий (невозможно проследить)

IInformation disclosure, раскрытие информации (утечка данных)

DDenial of service, отказ в обслуживании (DDoS, ресурсоёмкие запросы)

EElevation of privilege, повышение привилегий (вертикальный прыжок)

ПАРАЛЛЕЛЬ: ФИЗИЧЕСКАЯ ОХРАНА

Когда строится новый объект, до начала строительства спрашиваем: кто может проникнуть, через какие точки, с какой мотивацией, что делаем для блокировки каждого вектора.

Никто не строит здание, а потом ставит охрану. В цифровой инфраструктуре, пока строят, а потом ставят.

Threat Modeling не для разработчиков. Это для всех, кто отвечает за безопасность. Документ Threat Model, ваш способ убедиться, что архитектура осмыслена с точки зрения защиты, а не просто «функционально работает».