Модель угроз для ЗОКИИ в облаке: почему готового перечня мер нет

Если вы ищете список облачных мер защиты для значимого объекта КИИ, чтобы сверить с предложением провайдера, его не существует. Приказ № 239 выводит состав мер из модели угроз конкретной системы. Поэтому часть работы, которую вы рассчитывали переложить на площадку, остаётся у вас: как минимум модель угроз и обоснование класса СКЗИ.

Для ГИС перечень облачных мер есть: девять мер ЗСВ

Приказ ФСТЭК № 117 в пункте 63 перечисляет базовые меры для государственных систем, и среди них под литерой «г» стоит «защита виртуализации и облачных вычислений». Методический документ ФСТЭК от 12 апреля 2026 года раскрывает её в разделе 4.4: девять мер группы ЗСВ, от доверенной загрузки средств виртуализации (ЗСВ.1) до управления виртуальными машинами (ЗСВ.9), с матрицей применимости по классам К1, К2, К3 и требованиями к усилению.

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

Как определить меры защиты ЗОКИИ в облаке?

Приказ ФСТЭК № 239 группу ЗСВ не упоминает ни разу. Единственная норма о мерах в среде виртуализации в нём, пункт 19: меры «выбираются и реализуются в значимом объекте с учетом угроз безопасности информации применительно ко всем объектам и субъектам доступа на аппаратном, системном, прикладном и сетевом уровнях, в том числе в среде виртуализации».

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

Когда провайдер говорит, что площадка соответствует приказу № 239, спросите, по чьей модели угроз. Своей у него нет: он не видел ни вашей категории, ни ваших процессов, ни расчёта ущерба.

Что меняется в модели угроз при переезде в облако

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

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

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

Канал до облака, как правило, выходит за пределы контролируемой зоны, и здесь включается криптография. Если значимый объект одновременно ГИС или система госоргана, ГУП, учреждения, действует приказ ФСБ № 321 (с 11 сентября 2026 года); для остальных субъектов КИИ приказ прямо не адресован, но подход тот же: класс СКЗИ выводится из модели угроз.

Пункт 11 приказа задаёт: если по модели угроз атаки возможны только вне контролируемой зоны, СКЗИ класса не ниже КС1. Пункт 4 требует обосновать класс в модели угроз (он «подлежит обоснованию в модели угроз»), а при взаимодействии с другими системами пункт 9 берёт наиболее высокий из классов. Так что класс СКЗИ на канале тоже задаёт ваша модель, и в прайсе провайдера этой строки не будет: он не знает, какой класс вы обоснуете.

Появляется подрядчик с доступом к объекту. С 1 марта 2027 года приказ ФСТЭК № 220 требует от организаций, «которым предоставляется доступ к значимому объекту… для оказания услуг, проведения работ по обработке, хранению информации», рассчитывать показатель уровня зрелости Узи до получения доступа. Облачный провайдер обрабатывает и хранит информацию объекта, то есть попадает под первое же основание пункта. У вас появляется измеримое требование к такому подрядчику, рассчитанный Узи, и основание закрепить его в договоре до предоставления доступа.

Меры ЗСВ при этом годятся как ориентир. Девять мер из методического документа к приказу № 117 написаны для ГИС, но как опросник для площадки они работают и для ЗОКИИ:

• доверенная загрузка;
• целостность гипервизора;
• регистрация событий среды виртуализации (ЗСВ.3, именно её вы будете просить у площадки в виде журналов);
• управление доступом;
• резервное копирование;
• ограничение программной среды;
• защита памяти;
• идентификация и аутентификация;
• управление виртуальными машинами.

В проект защиты ЗОКИИ они попадают только по результату модели угроз.

Для ГИС, постоянно подключённой к интернету, площадку дополнительно проверяют по перечню провайдеров хостинга.

На что отвечает модель угроз облачной системы

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

1. Какие угрозы приходят через персонал и оборудование провайдера.
2. Какой класс СКЗИ из этого следует.
3. Какие меры уровня гипервизора вы требуете от провайдера по договору, а какие остаются на ваших виртуальных машинах.
4. Какие требования к подрядчику, от Узи до сроков уведомления, должны попасть в договор.

Из этих ответов и складывается тот перечень, которого вы не нашли в приказе № 239.

Модели угроз для ЗОКИИ и ГИС в облаке мы пишем как лицензиат ФСТЭК; для ГИС готовим комплект к согласованию с ФСТЭК и ФСБ по пункту 3 постановления № 676.