моделирование угроз: ошибки, компромиссы и безопасный откат. Практический разбор архитектуры SaaS: место в системе, компромиссы, порядок реализации, метрики, риски и критерии готовности.
Почему задача возникает
Главная ошибка — ограничиваться периметром, не проверяя доступы внутри контекста арендатора. Для «моделирование угроз» нужно явно отделять продуктовые правила, логику приложения, изоляцию данных и эксплуатацию платформы: у каждого слоя свои контракты, тесты и владельцы.
Как спроектировать решение
Цель — сделать изоляцию и контроль данных доказуемыми. Для темы «моделирование угроз» сначала фиксируют тип клиентов, модель арендаторов, критичные данные, SLO и границы ответственности. Затем выбирают самый простой вариант, который проходит тесты изоляции, нагрузочный профиль, сценарий сбоя, миграцию и восстановление. Решение документируют в ADR и проверяют на пилоте.
Практический сценарий
Пример: продукт на отраслевых данных применяет «моделирование угроз». Команда описывает поток запроса и данных, назначает контекст арендатора, вводит идемпотентность и аудит, задаёт лимиты, собирает метрики по арендаторам, проводит нагрузочный тест и учение по откату. Решение принимают только после проверки изоляции и восстановления.
Что измерять
Критерии: результаты тестов изоляции, полнота аудита, возраст секрета и время восстановления. Дополнительно измеряют долю запросов с контекстом арендатора, p95 критичных операций, очередь, ошибки по тарифам, время доставки вебхука, стоимость на арендатора, RTO/RPO и скорость безопасного отката.
Порядок действий
- Зафиксируйте модель арендаторов, данные, риск и владельца.
- Опишите контракты идентификации, API, биллинга и событий.
- Проведите тесты изоляции и нагрузочный базовый уровень.
- Добавьте трассировки, ограничения, резервное копирование и эксплуатационную инструкцию.
- Отрепетируйте миграцию, сбой и откат.