Когда актуально

Особенно актуально, если:

• инфраструктура работает на виртуализации или в облаке (IaaS, PaaS, SaaS), и неясно, где заканчивается ответственность провайдера и начинается ваша;
• в продуктивной среде используются контейнеры и оркестраторы — Kubernetes или аналогичные платформы;
• нужно защитить гипервизор и виртуальные машины от компрометации, в том числе для регулируемых систем;
• система относится к регулируемой — например, ГИС, ИСПДн или значимому объекту КИИ, — и применимые требования предусматривают меры защиты виртуальной или облачной инфраструктуры и, в зависимости от нормативного режима, требования к функциям и форме оценки соответствия используемых средств защиты;
• идёт миграция с иностранной платформы виртуализации или облака на отечественную.

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

С чего начинаем

Не знаете, где граница ответственности с провайдером? Разбираем модель разделённой ответственности для конкретного облака и формата услуги (IaaS, PaaS, SaaS) — это первый шаг: без него легко закрыть то, что провайдер уже закрывает, и пропустить то, что остаётся на вас.

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

Нужна ли именно сертифицированная защита виртуализации? Определяем это по применимым требованиям к конкретной системе, а не по общему правилу «раз есть виртуализация — нужен сертификат».

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

Как это соотносится с соседними услугами

Несколько услуг относятся к защите инфраструктуры, но на разных уровнях и в разном формате.

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

Форматы работы

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

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

Защита контейнерных сред. Настройка RBAC и политик безопасности кластера, сегментация и сетевые политики, контроль образов и реестров, сканирование уязвимостей, управление секретами, контроль допуска workload в кластер и мониторинг событий контейнерной среды — в составе, поддерживаемом используемой платформой.

Сопровождение. Регулярный контроль конфигураций, обновление политик при изменении инфраструктуры.

Кто за что отвечает — вы или провайдер

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

• Для IaaS, как правило, заказчик отвечает за операционную систему, приложения, данные, настройки сети внутри виртуальной инфраструктуры и управление доступом; провайдер — за физическую инфраструктуру и слой виртуализации.
• Для PaaS, как правило, часть ответственности за платформенный слой (операционная система, среда выполнения) переходит к провайдеру, но конфигурация приложения и данные остаются на заказчике.
• Для SaaS, как правило, большая часть инфраструктуры на провайдере, но управление доступом пользователей, настройки безопасности сервиса и данные — всё ещё зона ответственности заказчика.

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

Как мы выстраиваем защиту

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

Что вы получаете

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

Особенности и ограничения

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

Эскалация при инциденте

Порядок согласуется на установочной сессии и фиксируется в договоре:

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

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

Метрики

Показатели согласуем на старте, чтобы результат можно было оценивать по понятным и измеримым критериям.

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

Чего мы не используем как показатель эффективности. Общее число выявленных находок само по себе: оно отражает объём проверки, а не то, насколько снижен реальный риск для критичных ресурсов.

Конфиденциальность

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

Регуляторный контекст

Методический документ ФСТЭК России от 12.04.2026 предусматривает отдельные группы мер «Защита виртуализации и облачных вычислений» (ЗСВ) и «Защита технологий контейнерных сред и их оркестрации» (ЗКО). Его область применения охватывает соответствующие информационные системы, подпадающие под приказ ФСТЭК № 117, и обеспечение безопасности значимых объектов КИИ в пределах установленных для них требований. Группа ЗСВ охватывает, в частности, доверенную загрузку, контроль целостности, регистрацию событий, управление доступом и резервное копирование в виртуальной среде. Группа ЗКО предусматривает меры по контролю целостности и уязвимостей контейнеров и образов, управлению доступом, регистрации событий, резервному копированию, изоляции контейнеров, идентификации и аутентификации, а также управлению контейнерами и их образами. Конкретный состав применимых мер определяется применимым нормативным режимом, классом защищённости и/или категорией значимости объекта, актуальными угрозами и архитектурой конкретной системы.

Требования к сертифицированным средствам защиты различаются по нормативному режиму. Для информационных систем, подпадающих под приказ ФСТЭК № 117, применяются сертифицированные средства защиты информации с классом защиты и уровнем доверия, соответствующими классу защищённости системы. Для информационных систем персональных данных приказ ФСТЭК № 21 устанавливает необходимые функции защиты и, при использовании сертифицированных средств, требования к их классу — из этого нельзя вывести универсальное правило «для любой ИСПДн определённого уровня обязательно отдельное сертифицированное средство защиты виртуализации». Для значимых объектов КИИ порядок оценки соответствия средств защиты, установленный приказом ФСТЭК № 239, также не сводится во всех случаях только к сертификации — предусмотрены и другие формы оценки соответствия. Необходимость конкретного сертифицированного средства определяется отдельно для каждой системы, а не выбирается по единому перечню для всех организаций.

Указ Президента РФ № 250 с 1 января 2025 года запрещает органам и организациям, на которые он распространяется, включая субъектов КИИ, использовать средства защиты информации, происходящие из указанных в Указе иностранных государств, — это касается и средств защиты виртуализации, если они подпадают под определение таких средств. Применимость определяется статусом организации, а не самим фактом использования виртуализации или облака.

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

Материалы работ могут использоваться как документы, подтверждающие принятые меры защиты. Подтверждением полного соответствия нормативным требованиям сам по себе факт внедрения защиты виртуализации или облака не является.

Порядок работы, сроки, стоимость и приёмка

Как начинается работа: бесплатная первичная оценка (до 30 минут, без подключения к инфраструктуре) → предварительное определение задачи и используемых платформ → договор и NDA → инвентаризация инфраструктуры и определение модели ответственности → выявление ошибок конфигурации → проектирование и настройка защиты → передача в сопровождение.

Объём услуги определяется числом виртуальных машин и облачных ресурсов, используемыми платформами (виртуализация, облачные провайдеры, оркестраторы), необходимостью сертифицированных решений и объёмом сопровождения. В договоре фиксируются состав работ, критерии приёмки и порядок эскалации при инцидентах.

Ориентировочные сроки: инвентаризация и определение модели ответственности — от 1 до 3 недель; выявление ошибок конфигурации и настройка защиты — от 3 до 6 недель, в зависимости от масштаба инфраструктуры.

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

Почему IST

• В сфере информационной безопасности с 2011 года
• Более 80 специалистов; офисы в Самаре, Оренбурге и Нижнем Новгороде, представительство в Москве
• Лицензии ФСТЭК и ФСБ
• Помогаем определить реальную границу ответственности с провайдером, а не продаём защиту того, что провайдер уже закрывает
• Работаем с распространёнными в российской инфраструктуре платформами виртуализации, облаками и оркестраторами
• Полный цикл: от аудита контейнерной инфраструктуры до постоянной защиты виртуализации, облака и передачи в проактивный мониторинг (SOC)

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

Отвечает ли облачный провайдер за нашу безопасность? Частично — за то, что он предоставляет как услугу (инфраструктура, платформа — в зависимости от формата IaaS/PaaS/SaaS). За настройку, конфигурацию доступа и данные внутри этой инфраструктуры отвечает заказчик. Точную границу определяем для вашего конкретного провайдера и договора.

Нужна ли сертифицированная защита виртуализации, если у нас обычная виртуализация? Не обязательно. Это определяется применимыми требованиями к конкретной системе — например, к ГИС, ИСПДн определённого уровня или значимому объекту КИИ, — а не самим фактом использования виртуализации.

Чем это отличается от аудита контейнеров и CI/CD? Аудит — это разовая оценка защищённости контейнерной инфраструктуры и конвейера сборки. Эта услуга — постоянная защита виртуализации, облака и контейнерных сред, включая внедрение и сопровождение мер, а не только их оценку.

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

Что будет, если провайдер изменит настройки платформы? Изменения на стороне провайдера могут повлиять на конфигурацию ваших ресурсов — поэтому мониторинг конфигураций настраивается на постоянной основе, а не как разовая проверка.