Разбор методологии моделирования угроз STRIDE на обезличенном примере системы документооборота: шесть вопросов и реальные архитектурные решения.

STRIDE на реальном примере, а не на абстрактной схеме

Моделирование угроз по методологии STRIDE часто объясняют через абстрактные диаграммы со стрелочками, и это создаёт у людей ощущение, что это какая-то академическая практика, далёкая от реальной разработки. На практике это просто список из шести конкретных вопросов к системе, и ответы на них иногда меняют архитектуру ещё до того, как написана первая строчка кода.

Возьму обезличенный пример из своей практики: система с ролевым доступом, где у разных пользователей разные права на просмотр и изменение документов, что-то вроде внутреннего документооборота компании. Разберу её по буквам STRIDE, и покажу, какие реальные решения из этого вышли.

Spoofing, подмена личности. Вопрос в том, может ли кто-то выдать себя за другого пользователя. В этой системе был момент, когда сессия проверялась только по токену в cookie без дополнительной привязки к устройству или IP, и теоретически украденный токен работал откуда угодно. Решение простое, но его легко забыть, если не задать вопрос заранее: привязать токен к отпечатку устройства и инвалидировать сессии при смене IP за пределами разумного диапазона.

Tampering, изменение данных в пути. Можно ли подменить данные документа между тем, как пользователь его отправил, и тем, как он сохранился. Здесь важно было не только шифрование канала, HTTPS и так далее, но и проверка целостности на уровне самого документа, потому что часть обработки шла через очередь фоновых задач, а не напрямую, и между этими шагами документ теоретически можно было подменить, если скомпрометировать саму очередь.

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

Information disclosure, утечка данных. Куда реально уходят данные, которые не должны быть видны посторонним. Здесь обнаружилось, что часть документов попадала в полнотекстовый поисковый индекс без учёта прав доступа, то есть пользователь с ограниченными правами мог случайно увидеть содержимое чужого документа через поисковую выдачу, даже не имея прямого доступа к самому документу. Эту дыру нашли именно на этапе моделирования, до того как написали код индексации, и заложили фильтрацию по правам сразу в саму логику индекса, а не прикрутили заплаткой потом.

Denial of service, отказ в обслуживании. Что будет, если один компонент перегрузить запросами или отключить. Для внутренней системы документооборота это не самый критичный пункт, но даже здесь нашлось слабое место: генерация PDF из документа была синхронной и блокирующей, и массовая генерация в пиковые часы могла положить весь сервис для всех пользователей разом. Вынесли в асинхронную очередь.

Elevation of privilege, повышение привилегий. Может ли обычный пользователь получить права, которых у него быть не должно. Здесь нашли классическую проблему: права проверялись на уровне интерфейса, кнопки скрывались для пользователей без доступа, но сам API не делал повторную проверку, если запрос отправить напрямую, минуя интерфейс. Это тот случай, когда без явного вопроса «а что если обойти фронтенд» проблему легко не заметить вообще, потому что в обычном использовании через интерфейс всё работает правильно.

Из шести вопросов пять дали реальные архитектурные решения ещё до того, как основная часть системы была написана. Это и есть смысл моделирования угроз: не заменить аудит кода после разработки, а сделать так, чтобы часть проблем просто не попала в код, потому что их заметили на этапе, когда менять архитектуру стоило копейки по сравнению с переделкой готовой системы.

Если проектируете что-то новое и хотите так же пройтись по вашей системе, можно обсудить это здесь.