Модель угроз для облачной инфраструктуры и ЦОД в

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

В статье разберём, обязательна ли модель угроз для облачных систем и ЦОД в , как её построить по Методике ФСТЭК 2021, какие угрозы виртуализации учесть и что будет, если оставить модель «от старой серверной». В конце — состав услуги сопровождения и стоимость.

Нужна ли модель угроз: компания, размещающая системы в облаке или собственном ЦОД

Ответ зависит от типа системы: обрабатываются ли персональные данные, является ли система государственной или значимым объектом КИИ. Для коммерческой корпоративной системы без ПДн и ГИС разработка модели угроз — право оператора, но на практике её делают, чтобы обосновать выбор средств защиты и не спорить с аудиторами.

Какие системы и объекты воздействия учитывать

Облачная модель угроз описывает не только виртуальные машины, но и всю цепочку: от уровня гипервизора до каналов связи с провайдером. Если что-то выпадает из периметра, сценарии атак становятся нереалистичными.

Нарушители и сценарии атак

Методика ФСТЭК 2021 выделяет уровни возможностей нарушителей от Н1 (базовые) до Н4 (высокие). Для облачных систем часто актуальны нарушители уровней Н2–Н3 — внешние злоумышленники с опытом эксплуатации уязвимостей и инсайдеры с доступом к управлению. Если провайдер не передал результаты своей оценки угроз, по п. 2.11 Методики его инфраструктуру считают скомпрометированной нарушителем с максимальными возможностями (Н4).

Типовые сценарии для облачной инфраструктуры и ЦОД, которые отражают в модели:

• Первоначальный доступ через фишинг или утечку учётных данных. Злоумышленник получает доступ к консоли управления облаком или VPN-аккаунту администратора. Далее — повышение привилегий и закрепление.
• Эксплуатация уязвимостей гипервизора. Выход из виртуальной машины на хост или в другую ВМ. Для IaaS это критичный сценарий, если провайдер не подтвердил изоляцию.
• Атака на интерфейсы управления облаком. Подбор или перехват API-ключей, эксплуатация уязвимостей веб-консоли. Приводит к массовой компрометации.
• Компрометация резервных копий. Если бэкапы хранятся в том же облаке и доступны тем же учётным записям, злоумышленник шифрует и основные данные, и резервы.
• DDoS на каналы связи с провайдером. Отказ в обслуживании приводит к недоступности системы, а не к краже данных, но включается в модель как угроза доступности.
• Инсайдер с доступом к виртуализации. Сотрудник провайдера или собственный администратор намеренно выводит ВМ из строя или копирует данные.

Как разработать модель угроз: этапы по Методике

Методика ФСТЭК 2021 задаёт три основных этапа: негативные последствия, объекты воздействия, оценка возможности реализации и актуальности угроз. На практике оператор готовит документ силами своего специалиста по защите информации при участии ИТ-службы. Мы предоставляем шаблон, методические указания и проверку.

Особенности, о которых забывают

• ✓ Разделение ответственности с провайдером. В модели нужно явно зафиксировать, какие компоненты защищает провайдер, а какие — вы. Если этого нет, по п. 2.11 Методики инфраструктура провайдера считается скомпрометированной нарушителем с максимальными возможностями.
• ✓ Аттестованное облако для ГИС и ПДн. Для ГИС инфраструктура облака должна соответствовать требованиям приказа ФСТЭК № 117. На практике госзаказчики требуют от провайдера аттестат соответствия или подтверждение защищённости.
• ✓ Угрозы виртуализации в БДУ ФСТЭК. Актуальные техники атак на гипервизоры и системы управления облаком фиксируются в Банке данных угроз. Модель, построенная только на устаревших перечнях, не пройдёт проверку.
• ✓ Бэкапы как отдельный объект воздействия. Если резервные копии находятся в том же облаке и управляются теми же учётными записями, сценарий «шифрование данных + резервов» будет актуальным. Это нужно явно указать.
• ✓ Обновление модели при модернизации. Переезд на новый облачный сервис, смена провайдера, подключение нового API — всё это повод актуализировать модель (п. 2.14 Методики).

Разбор на примере: SaaS-сервис учёта для клиник в облаке

Как шла работа:

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

Что будет без модели угроз

Специального штрафа «за отсутствие модели угроз» в КоАП нет. Ответственность наступает за последствия: утечку персональных данных, нарушение требований о защите информации для ГИС или значимых объектов КИИ.

Для коммерческих ИСПДн при утечке могут применить ст. 13.11 КоАП (части 12–18): штрафы для юрлиц от 3 до 20 млн рублей, при повторном нарушении — оборотные штрафы 1–3% выручки. Отсутствие модели ухудшает позицию оператора: сложнее доказать, что меры были обоснованы и реализованы.

Для ГИС без модели угроз нарушаются требования приказа ФСТЭК № 117 и ПП № 676 — это состав ч. 6 ст. 13.12 КоАП (для юрлиц 50–100 тыс. рублей). Для значимых объектов КИИ отсутствие модели при создании системы безопасности — нарушение приказа ФСТЭК № 239, что влечёт применение ст. 13.12.1 КоАП.

Чем поможем и сколько это стоит

Мы не разрабатываем модель угроз под ключ: по Методике ФСТЭК 2021 её готовит и утверждает сам оператор. Наша услуга — методическое сопровождение: вы получаете адаптированный шаблон, указания по каждому разделу, консультации и проверку готового документа. Для ГИС, значимых объектов КИИ или если нужна договорная разработка, подключаем партнёра-лицензиата ФСТЭК.

• Опросный лист и шаблон модели по структуре Методики ФСТЭК 2021 под ваш тип системы (облако, ЦОД, ИСПДн, ГИС, КИИ, АСУ ТП).
• Методические указания по каждому разделу: негативные последствия, объекты воздействия, нарушители Н1–Н4, сценарии по тактикам и техникам БДУ.
• Две консультации со специалистом по защите информации: разбор архитектуры, сценариев, разделения ответственности с провайдером.
• Проверка готового документа с письменными замечаниями и проект приказа об утверждении.
• Для ИСПДн — помощь в определении типа угроз и уровня защищённости по ПП № 1119.

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

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

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