Безопасность · Средняя
Провести threat modeling для изменения
Разобрать, какие активы, роли, входные точки и сценарии атак появляются после нового backend-изменения.
Быстро понять за 2 минуты
Разобрать, какие активы, роли, входные точки и сценарии атак появляются после нового backend-изменения. На выходе: критичные активы и входные точки перечислены.
Контекст
Пункт относится к этапу «Безопасность». Его задача — превратить рабочее действие в проверяемый результат. Он нужен до передачи результата frontend, QA, DevOps и владельцу продукта: иначе команда рискует считать внутренний сервис полностью доверенным.
Что это дает
Threat modeling помогает находить риски до code review и релиза. Это практичный способ не забыть про права, доверенные границы, внешние интеграции и хранение чувствительных данных.
Как выполнить
- Опишите активы: персональные данные, платежи, токены, бизнес-операции, административные действия.
- Перечислите входные точки и доверенные границы: API, webhooks, queues, админка, внутренние сервисы.
- Сформулируйте угрозы и меры защиты: валидация, авторизация, rate limit, аудит, шифрование, алерты.
Критерии приемки
- Критичные активы и входные точки перечислены.
- Для основных угроз есть меры защиты или принятое решение о риске.
- Новые проверки добавлены в code review, тесты или runbook.
Типичные ошибки
- Считать внутренний сервис полностью доверенным.
- Проверять только аутентификацию и забывать про авторизацию.
- Не фиксировать принятое решение по риску.
Инструменты
Рабочий артефакт
Security checklist
Краткая модель угроз изменения
Пример для разработки серверного модуля: специалист начинает с действия «Опишите активы: персональные данные, платежи, токены, бизнес-операции, административные действия». Затем фиксирует результат в рабочем артефакте и передает его команде. Пункт считается выполненным только когда выполнено условие: «Критичные активы и входные точки перечислены».
- Auth checks
- Access rules
- Secrets
- Rate limits
Контроль качества
Контроль безопасности backend
Критичные активы и входные точки перечислены.
После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.
Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.
Перед отметкой выполнено: Критичные активы и входные точки перечислены.
Как применять
Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.