Модель угроз: как думать о безопасности

Проект ЦИТадель

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

Абсолютной безопасности не бывает: любая защитная мера имеет границы применимости, а после её введения остаётся остаточный риск. Поэтому задача инженера — не объявить систему безопасной вообще, а снизить конкретные риски до согласованного уровня и зафиксировать то, что остаётся. Раздел 1 вводит четыре вопроса модели угроз. Раздел 2 разбирает соразмерность защиты и экономику обеих сторон. Затем речь пойдёт о поверхности атаки, доверии и наименьших привилегиях, глубине обороны и типичных ошибках мышления. В разделе 7 эти идеи собраны в практикум.

1. Четыре вопроса

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

• Что мы строим и защищаем? Нужно задать границы системы, её компоненты, потоки и хранилища данных, внешние зависимости и активы. Для актива важно назвать требуемое свойство: например, конфиденциальность медицинских данных, целостность платёжного поручения или доступность службы связи.
• Что может пойти не так? Нужны не только портреты противников, но и конкретные сценарии: кто при каких предпосылках через какой вход сможет что сделать и к каким последствиям это приведёт. Автоматический бот, мошенник, подрядчик с доступом и целевой атакующий различаются возможностями, мотивами и терпением.
• Что мы с этим сделаем? Для каждого существенного сценария принимают решение: устранить источник угрозы, уменьшить вероятность или последствия, разделить ответственность с другой стороной либо осознанно принять риск. Решение должно иметь владельца и превращаться в выполнимое требование, а не в пожелание «усилить безопасность».
• Достаточно ли хорошо? Модель сверяют с фактической системой, выбранные меры — с реализацией и тестами, а остаточный риск — с тем уровнем, который готов принять его владелец. После новой функции, изменения архитектуры или инцидента ответы пересматривают.

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

Активы, противники, поверхность атаки и последствия — необходимые входные данные, но сами по себе они ещё не образуют законченную модель. В ней каждому приоритетному сценарию сопоставлены решение, способ проверки и принятый владельцем остаточный риск. Тогда вопрос «нужно ли шифровать это поле?» можно связать с определённой угрозой и проверить, действительно ли шифрование уменьшает её.

2. Соразмерность: экономика обеих сторон

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

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

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

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

3. Поверхность атаки

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

Ненужный вход надёжнее устранить, чем постоянно защищать. Поэтому закрывают неиспользуемые службы, удаляют лишние зависимости и учётные записи, отключают отладочные интерфейсы в рабочей среде, ограничивают административный доступ и не собирают данные без цели. Данные, которых у организации нет, не утекут из её хранилища; удалённая служба не потребует патчей. Сокращение поверхности часто даёт более простой и проверяемый результат, чем добавление очередного рубежа вокруг лишней функции.

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

4. Доверие: границы и наименьшие права

Доверие — это предположение о подлинности, поведении или целостности субъекта либо компонента. Его нужно называть явно. Граница доверия проходит там, где меняются уровень привилегий, владелец или основания доверять данным: например, между браузером пользователя и сервером, внешним поставщиком удостоверений и приложением, средой сборки и рабочей средой. Не всякий вызов между двумя сервисами образует такую границу, а подключённая библиотека нередко исполняется внутри неё с теми же правами, что и приложение.

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

Принцип наименьших привилегий требует дать каждому человеку, процессу и токену доступ только к необходимым операциям и ресурсам и только на необходимый срок. Сборочной стадии, которая не выполняет развёртывание, не нужен доступ к рабочей среде; веб-процессу не нужны права root; токен интеграции должен давать доступ только к требуемым методам API и данным. Это не предотвращает компрометацию, но ограничивает радиус поражения. Дополняет принцип правило предполагать компрометацию: для каждого компонента стоит проверить, куда атакующий сможет перейти, какие данные выгрузить и можно ли обнаружить такое поведение. Если один украденный токен открывает всю систему, границы проведены, а полномочия ограничены недостаточно строго.

5. Глубина обороны

Для существенного риска опасно без отдельного решения полагаться на единственную меру. Глубина обороны сочетает рубежи предотвращения, ограничения ущерба, обнаружения, реагирования и восстановления. Сегментация сети сокращает доступные пути, аутентификация подтверждает заявленную личность, авторизация проверяет конкретное действие, обработка ввода защищает интерпретаторы, журналирование и мониторинг помогают заметить атаку, а отделённые от основной системы и проверенные резервные копии — восстановиться после некоторых её последствий.

Рубежи ценны, если у них разные условия отказа. Три средства, зависящие от одной учётной записи администратора или одного ключа, могут быть пробиты одновременно. Шифрование хранилища, например, защищает конфиденциальность украденного носителя или отдельной копии данных, если ключ хранится отдельно. Но оно не остановит атакующего, который скомпрометировал приложение и получает открытые данные штатным путём. Поэтому для каждого слоя нужно называть сценарий, который он останавливает, и проверять его независимо.

Каждый дополнительный рубеж увеличивает сложность и создаёт собственные режимы отказа. Средство, которое никто не умеет настраивать, проверять и возвращать в работу после сбоя, способно снизить безопасность. Число слоёв определяют не правилом «чем больше, тем лучше», а риском, независимостью мер и возможностью сопровождать их.

6. Ошибки мышления

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

• Безопасность через неясность. Скрытый URL или неизвестное устройство системы не заменяют авторизацию и другие проверяемые меры. Неочевидность может замедлить разведку, но её нельзя считать самостоятельным рубежом. Особый случай — намеренно созданная ссылка с достаточно длинным и непредсказуемым токеном: она действует как предъявительский секрет, поэтому её нужно защищать, ограничивать по правам и сроку, уметь отзывать и не раскрывать в журналах.
• Периметр как единственный рубеж. Принадлежность к внутренней сети сама по себе не подтверждает право: узел или учётная запись уже могут быть скомпрометированы. Подход нулевого доверия не требует «не доверять никому», а исключает неявное доверие только по местоположению: доступ к ресурсу явно аутентифицируют, авторизуют и ограничивают с учётом контекста.
• Требование безошибочности от человека. Пользователь может открыть фишинговую страницу, разработчик — случайно опубликовать ключ, администратор — ошибиться в настройке. Это предсказуемые сценарии, а не объяснение «слабым звеном». Ключи доступа (passkeys), менеджеры паролей, наименьшие права, подтверждение опасных операций и автоматический поиск секретов уменьшают зависимость от постоянной внимательности.
• «Нас незачем взламывать». Автоматические сканеры и бот-сети выбирают доступную уязвимость, а не известную организацию; вычислительные ресурсы, учётные записи и каналы рассылки имеют ценность сами по себе. Это обосновывает базовую гигиену для всех систем, но не означает, что всем требуется одинаковый набор дорогостоящих мер.

7. Практикум: модель угроз своей системы

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

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

Задание 2. Возможные противники. Выберите не менее трёх подходящих вариантов: например, бот, массово сканирующий сеть, мошенник, пользователь с законным доступом, подрядчик с избыточными полномочиями, атакующий, похитивший его учётную запись, или целевой атакующий. Для каждого запишите цель, исходный доступ, возможности и ограничения. Не исключайте сильного противника только по отрасли организации: если сценарий не входит в модель, укажите основание и того, кто принял это допущение.

Задание 3. Карта системы и поверхности. Нарисуйте компоненты, хранилища, внешние сущности и потоки данных. Отметьте места, где меняются владелец, привилегии или основания доверять данным. Добавьте к карте API, административные интерфейсы, загрузки, зависимости и обновления, CI/CD, резервные копии, доступ поддержки и другие пути, по которым можно влиять на систему.

Задание 4. Сценарии. Составьте не менее пяти утверждений по форме: «при такой предпосылке такой противник через этот вход может выполнить такое действие, что приведёт к такому последствию». Свяжите каждый сценарий с активом и элементами карты. Название уязвимости без пути и последствия сценарием не считается.

Задание 5. Приоритет. Для каждого сценария оцените правдоподобие и тяжесть последствий по трём уровням — низкому, среднему и высокому — и поясните оценку. Учтите уже действующие меры и отдельно запишите важную неопределённость. Выберите несколько сценариев, требующих решения в первую очередь; не перемножайте условные баллы, если их точность ничем не обоснована.

Задание 6. Наименьшие права и компрометация. Для трёх компонентов, токенов или учётных записей сравните фактические полномочия с необходимыми. Затем предположите компрометацию одного из них и проследите возможное боковое перемещение и доступ к данным. Наметьте сокращение прав или новую границу. Изменения в рабочей системе проводите через принятый процесс с тестированием и возможностью отката, а не как импровизированную часть упражнения.

Задание 7. Решения и проверка. Для каждого приоритетного сценария выберите одно из решений: устранить источник, уменьшить вероятность или последствия, разделить ответственность либо принять риск. Запишите обоснование и владельца. Для новой меры сформулируйте проверяемое требование и тест, а также способ обнаружить атаку и восстановиться, если предотвращение не сработает. В конце убедитесь, что у каждого приоритетного сценария есть решение, а у принятого остаточного риска — названный владелец и срок пересмотра.

Итоги

• Модель угроз отвечает на четыре вопроса: что мы строим и защищаем, что может пойти не так, что с этим делать и достаточно ли хорошо выполнена работа. Это не разовый документ: его пересматривают вместе с системой.
• Соразмерность опирается на правдоподобие сценария и тяжесть последствий. Экономика атакующего важна, но не сводит достаточность защиты к формуле «атака дороже приза».
• Поверхность атаки включает все доступные пути воздействия, а не только сетевые порты. Устранение ненужного интерфейса, разрешения или данных уменьшает и риск, и объём дальнейшей защиты.
• Границы доверия проводят там, где меняются привилегии или основания доверять данным. Проверки выбирают по контексту, а наименьшие привилегии и предположение о компрометации ограничивают радиус поражения.
• Глубина обороны требует рубежей с разными условиями отказа и охватывает предотвращение, ограничение ущерба, обнаружение, реагирование и восстановление. Непонятный и непроверяемый дополнительный слой может стать новой уязвимостью.
• Законченная модель связывает приоритетные сценарии с решениями, владельцами и проверками и фиксирует остаточный риск.

Литература

1. A. Shostack, "Threat Modeling: Designing for Security," Wiley, 2014 — систематическое руководство по построению моделей угроз.
2. R. Anderson, "Security Engineering," 3rd ed., 2020 — инженерная безопасность, устройство атак и экономика защиты.
3. OWASP Threat Modeling Cheat Sheet — четыре вопроса, моделирование системы, выявление угроз, выбор мер и проверка результата.
4. NIST SP 800-207, Zero Trust Architecture — принципы нулевого доверия, явная проверка доступа и отказ от доверия только по сетевому местоположению.
5. Связанные статьи проекта: «Как устроен браузер» (правило одного источника), «Инфраструктура как код» (ограничение радиуса поражения), «Наблюдаемость» (обнаружение), «Облака на практике» (оценка издержек). Продолжение раздела: цепочка поставок, аутентификация и авторизация, веб-безопасность.