Требования, модель угроз и безопасный дизайн

Зачем это нужно

• Дефекты дизайна исправлять дороже всего: их лучше не допускать.
• Требования дают проверяемые критерии приёмки вместо общих пожеланий.
• Моделирование угроз делает обсуждение рисков конкретным.

Теория

Требования безопасности формулируют проверяемо: например, «сессии инвалидируются при смене пароля», «все административные действия записываются в журнал с указанием инициатора», «данные пользователя недоступны другому пользователю при любом обращении». Ориентиры: OWASP ASVS как каталог требований и NIST SSDF как процесс. Требования вносят в задачи и проверяют в приёмке, иначе они останутся благими намерениями.

Моделирование угроз: описать систему и её границы, активы и потоки данных, участников и их возможности, определить, что может пойти не так на каждом шаге, и выбрать меры. Практические методы: диаграммы потоков данных, STRIDE для категоризации угроз, приоритизация по влиянию и вероятности. Результат — список рисков с мерами и владельцами, а не документ «для галочки».

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

Ключевые концепции

Проверяемое требование

Требование безопасности, которое можно протестировать и включить в критерии приёмки.

Диаграмма потоков данных

Схема, показывающая компоненты, потоки и границы доверия: основа моделирования угроз.

STRIDE

Категории угроз: подмена, изменение данных, отказ от авторства, раскрытие, отказ в обслуживании, повышение прав.

Архитектурная запись

Документ о принятом решении и его обосновании: сохраняет контекст для будущих изменений.

Граница доверия

Место, где данные переходят между зонами с разным уровнем доверия.

Принятый риск

Осознанное решение не устранять риск: должно быть записано с обоснованием и сроком пересмотра.

Инструменты

• OWASP ASVS как каталог требований.
• Средства построения диаграмм и документирования архитектуры.
• Платформы управления задачами для отслеживания мер.
• Реестры архитектурных решений и рисков.
• Шаблоны приёмки, включающие проверки безопасности.

Практика в легальных лабораториях

• Составьте десять проверяемых требований безопасности для учебного сервиса.
• Постройте диаграмму потоков данных и отметьте границы доверия.
• Проведите моделирование угроз по STRIDE и приоритизируйте риски.
• Опишите архитектурную запись для одного решения.
• Составьте чек-лист приёмки, включающий требования безопасности.

Защита, детект и защитные меры

• Включайте требования безопасности в критерии приёмки задач.
• Проводите моделирование угроз для новых функций, работающих с деньгами или данными.
• Фиксируйте принятые риски с обоснованием и сроком пересмотра.
• Держите архитектурные записи рядом с кодом: они объясняют решения.

Правовая рамка и этика

• Требования к обработке данных определяются законодательством и отраслевыми нормами: учитывайте их в требованиях, а не после.
• Моделирование угроз не должно превращаться в сбор избыточных данных о пользователях.

Типичные ошибки

• Формулировать требования как пожелания: «система должна быть безопасной».
• Проводить моделирование угроз один раз и забывать о нём.
• Не включать меры в задачи и владельцев: риски остаются без исполнения.

Чек-лист «умею»

• Умею формулировать проверяемые требования безопасности.
• Строю диаграммы потоков данных и определяю границы доверия.
• Провожу моделирование угроз по STRIDE.
• Фиксирую архитектурные решения и принятые риски.
• Включаю безопасность в критерии приёмки.

Вопросы на интервью

• Как вы убедитесь, что требование безопасности выполнимо и проверяемо?
• Как провести моделирование угроз для небольшого сервиса?
• Что вы сделаете с риском, который бизнес принимает?

Источники и первоисточники

• OWASP ASVS
• NIST SSDF
• OWASP SAMM