Обзор vGate 4.1 - защита виртуальных инфраструктур на базе VMware vSphere и Microsoft Hyper-V

1. Введение
2. Новые функциональные возможности vGate 4.1
3. Установка и настройка vGate 4.1
4. Системные требования vGate 4.1
5. Работа с vGate 4.1
1. 5.1. Заявка на развертывание виртуальной машины, на которой планируется работа  с конфиденциальными документами
2. 5.2. Новому сотруднику нужно выдать соответствующие права доступа к необходимым ресурсам
3. 5.3. Нужно создать правила взаимодействия для виртуальных машин сотрудников из разных отделов компании (временная рабочая группа)
6. Архитектура vGate 4.1
7. Лицензирование vGate 4.1
8. Выводы

Введение

Российская компания «Код безопасности» обновила продукт vGate до версии 4.1. Решение предназначено для защиты платформ виртуализации на базе VMware vSphere и Microsoft Hyper-V. На данный момент разработка vGate 4.1 завершена, и продукт уже проходит процесс сертификации во ФСТЭК России.

Значительные изменения в концепции построения ИТ-инфраструктуры, в частности, массовое внедрение средств виртуализации, безусловно, повлияли и на риски, связанные с ее эксплуатацией.

С одной стороны, с внедрением виртуализации в бизнес-процессы организация получает экономию средств на дорогостоящем оборудовании, гибкость и отказоустойчивость, а с другой — дополнительный уровень абстракции создает и дополнительные риски.

Администратор виртуальной среды имеет ничем не ограниченный доступ к любому элементу инфраструктуры. Его ошибки или намеренные действия могут повлиять на работу всех частей виртуальной среды.

Согласно исследованию «Кода Безопасности», две трети компаний опасаются ущерба, нанесенного действиями оператора виртуальной инфраструктуры (ВИ), причем как умышленными так и непреднамеренными.

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

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

• защита каждой виртуальной машины при помощи полноценного продукта;
• защита на уровне гипервизора, без установки агентов на виртуальные машины — так называемый подход agent-less;
• защита на уровне гипервизора и при помощи «легкого» агента.

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

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

Новые функциональные возможности vGate 4.1

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

• На VMware vSphere появился виртуальный межсетевой экран уровня гипервизора, дающий возможность более гибко настраивать взаимодействие защищаемых узлов. С его помощью можно объединять в один сегмент машины даже на разных ESXi-серверах.
• Появилась возможность накладывать политики безопасности напрямую на защищаемые объекты (виртуальные машины и ESXi-серверы) и группы объектов, минуя прежний механизм меток безопасности. Впрочем, метками по-прежнему можно воспользоваться.
• В рамках локальной консоли появилась возможность группировки защищаемых объектов.
• В продукте помимо знакомой локальной консоли управления появилась еще веб-консоль, куда перенесли часть функций из старой консоли (отчеты, журнал событий, настройка межсетевого экрана). В планах — перевести в новую консоль максимум функций.
• Существенно расширился набор шаблонов политик безопасности.
• Начиная с 2014 года помимо VMware vSphere, vGate поддерживает платформу виртуализации Microsoft Hyper-V.

Основные функции vGate, безусловно, сохранились:

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

Установка и настройка vGate 4.1

Процесс установки vGate 4.1 с момента предыдущего обзора изменился незначительно, поэтому мы лишь вкратце коснемся этой темы.

Предполагается, что в сети, где будет внедряться защита, уже проведена подготовительная работа. А именно, есть машина с контроллером домена, в отдельную подсеть отделены физические машины, в том числе те, с которых потом будут работать администраторы информационной безопасности (АИБ) и виртуальной инфраструктуры (АВИ). Также в отдельную подсеть должны быть выделены гипервизоры, системы хранения данных и виртуальные машины. Вероятнее всего, в такой сети может быть выделенный маршрутизатор, отвечающий за разделение подсетей с физическими и виртуальными машинами.

Рисунок 1. Принципиальная схема организации защиты виртуальной инфраструктуры при помощи vGate 4.1

Ключевые моменты, на которые следует обращать внимание при установке:

• На маршрутизаторе, отделяющем виртуальную инфраструктуру, должно быть настроено правило, запрещающее обращение ко всем машинам внутри этой подсети за исключением той, на которой будет развернут сервер авторизации vGate, так как именно он должен стать единой точкой для всех входящих запросов из внешних сетей.
• В ходе настройки сервера авторизации следует сразу позаботиться о создании отдельных учетных записей для администраторов информационной безопасности (АИБ) и виртуальной инфраструктуры (АВИ). Более того, в ходе установки на машины АИБ должны быть установлены консоль управления vGate, сервер отчетов и мониторинга. Для роли АВИ будет достаточно агента аутентификации, чтобы у него была возможность, авторизовавшись через vGate, получить доступ к управлению виртуальной инфраструктурой.
• Продуктом vGate поддерживаются сценарии установки, когда в сети может не быть контроллера домена или отдельного маршрутизатора. В этом случае для аутентификации на vGate можно будет использовать только внутренние учетные записи вместо доменных, а функцию маршрутизатора может на себя взять сервер аутентификации.

Более подробно этот и другие сценарии установки рассматриваются в документации.

Системные требования vGate 4.1

Таблица 1. Системные требования для установки vGate на VMware vSphere

Таблица 2. Системные требования для установки vGate для Microsoft Hyper-V

Работа с vGate 4.1

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

Заявка на развертывание виртуальной машины, на которой планируется работа с конфиденциальными документами

Очевидно, что виртуальные машины, на которых предполагается работа с важными документами, должны контролироваться особенно тщательно при помощи политик безопасности. При работе с vGate подобную задачу можно решить элегантным способом, используя сразу несколько механизмов продукта. Исходя из формулировки задачи можно предположить, что такого плана заявки появляются регулярно. В этом случае имеет смысл создать отдельную группу, куда будут попадать все виртуальные машины, на которых предполагается работа с секретными документами.

Рисунок 2. Создание новой группы объектов в локальной консоли vGate 4.1

Отдельно хочется обратить внимание на пункт «Включить автодобавление виртуальных машин в группу». Если отметить галочкой этот параметр, появляется возможность задать ключевое слово в имени виртуальной машины. Ориентируясь на него, все последующие виртуальные машины станут добавляться в эту группу без дополнительных действий администратора. В приведенном примере это слово secret.

Рисунок 3. Добавление объектов в группу в локальной консоли vGate 4.1

Помимо самих виртуальных машин в группу могут входить ESXi, хранилища данных, виртуальные сети и сетевые адаптеры.

Рисунок 4. Создание политики безопасности в локальной консоли vGate 4.1

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

Рисунок 5. Применение политики безопасности в локальной консоли vGate 4.1

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

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

Новому сотруднику нужно выдать соответствующие права доступа к необходимым ресурсам

Типовая задача добавления стандартного набора прав новому сотруднику может быть решена путем простого добавления его виртуальной машины в уже имеющуюся группу. Действия будут аналогичны тем, которые рассматривались в предыдущем сценарии. А в определенных исключительных случаях, когда по той или иной причине добавление в группу неуместно, vGate 4.1 позволяет накладывать политику безопасности напрямую на выбранную виртуальную машину.

Рисунок 6. Применение политики безопасности к виртуальной машине в локальной консоли vGate 4.1

Нужно создать правила взаимодействия для виртуальных машин сотрудников из разных отделов компании (временная рабочая группа)

В этом примере задача посложнее, так как кросс-функциональные команды находятся в разных частях организационной структуры компании, в том числе и с точки зрения ИТ. А если предположить, что рабочая группа объединяет несколько отдельных офисов, то может возникнуть целый ряд сложностей.

Впрочем, vGate 4.1 позволяет справиться и с такой задачей при помощи своего нового межсетевого экрана. Этот компонент располагается в новой веб-консоли и позволяет создавать гибкие логические структуры сети.

Рисунок 7. Включение межсетевого экрана на ESXi-серверах в веб-консоли vGate 4.1

Итак, первым делом в настройках межсетевого экрана (МЭ) необходимо включить этот компонент на ESXi-серверах, так как по умолчанию он выключен.

Рисунок 8. В веб-консоли vGate 4.1 указываются конкретные виртуальные машины на ESXi, на которых будет работать экран

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

Рисунок 9. Объединение виртуальных машин в сегменты в веб-консоли vGate 4.1

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

Рисунок 10. Создаем правила взаимодействия между сегментами в веб-консоли vGate 4.1

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

Создаем свое новое правило: разрешим весь трафик внутри нашего нового сегмента по всем портам.

Стоит отдельно сказать, что дополнительным плюсом веб-консоли является то, что многие процессы из рассмотренных в этом примере поддаются автоматизации при помощи REST API. Аналогично и для консоли управления — компанией «Код безопасности» предоставляется специальная утилита, позволяющая во многом автоматизировать процессы.

Рисунок 11. Журнал событий в веб-консоли vGate 4.1

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

Возвращаясь к исходному сценарию, мы объединили машины наших сотрудников из рабочей группы в виртуальные сегменты, невзирая на то, что они физически расположены в разных филиалах и что виртуальные машины находятся на разных ESXi-серверах. А затем при помощи правил фильтрации настроили систему так, чтобы эти машины работали в едином пространстве. И, конечно же, есть возможность сформировать отчеты по событиям системы.

Рисунок 12. Создание отчета в веб-консоли vGate 4.1

Как видно, в продукте более чем достаточно предварительно настроенных шаблонов.

Важно отметить, что даже в нашем простом примере все эти продвинутые конфигурации становятся актуальны только для больших компаний со сложной инфраструктурой. Это вполне логично, и по этой же причине вам потребуется версия vGate 4.1 в исполнении Enterprise Plus, чтобы получить эту функциональность.

Архитектура vGate 4.1

Решение vGate 4.1 состоит из целого ряда компонентов. На сайте производителя вы можете найти исчерпывающие описания каждого из них. Мы же рассмотрим логику построения системы безопасности и перечислим функциональную нагрузку каждого из компонентов.

Рисунок 13. Принципиальная схема организации защиты виртуальной инфраструктуры при помощи vGate 4.1

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

Таблица 3. Компоненты, используемые vGate для защиты

Лицензирование vGate 4.1

Отдельно стоит сказать несколько слов об изменениях в лицензировании — его заметно упростили. Вот основные моменты, на которые нужно обратить внимание:

• Начиная с версии 4.0, продукт выпускается в трех редакциях:
  Standard, Enterprise и Enterprise Plus (vGate 2.8 и более ранние версии приравниваются к редакции Standard). С возможностями каждой редакции можно ознакомиться на сайте.
• Для гипервизоров VMware и Microsoft используется единая лицензия, причем сервер авторизации сразу включается в эту стоимость.
• Расчет необходимого количества лицензий может также зависеть от количества физических процессоров в вашей виртуальной инфраструктуре.

Чтобы предварительно оценить стоимость, можно воспользоваться онлайн-калькулятором на сайте «Кода безопасности».

Выводы

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

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

Решение vGate 4.1 защищает платформы виртуализации на базе VMware vSphere и Microsoft Hyper-V. Основной фокус в защите сделан на контроль действий администратора виртуальной среды, контроль настроек среды виртуализации и ее сегментацию.

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

Важно отметить, что в настоящее время vGate 4.1 уже проходит сертификацию во ФСТЭК России. После успешного завершения сертификационных испытаний новая версия решения «Кода безопасности» пополнит линейку продуктов, подходящих для применения в государственных учреждениях, в том числе — работающих с гостайной. Протестировать продукт можно уже сейчас, скачав демоверсию на сайте компании «Код безопасности».

Преимущества:

• Комплексный подход к защите — от внешних и внутренних угроз в соответствии с требованиями регуляторов.
• Российское решение для защиты виртуальной инфраструктуры с широкими функциональными возможностями.
• Поддержка VMware vSphere и Microsoft Hyper-V.
• Возможность разграничения прав доступа на сервере авторизации vGate для администратора информационной безопасности и администратора виртуальной инфраструктуры, а также логирование всех их действий в системе.
• Система мониторинга и оповещения администратора ИБ в случае возникновения инцидента безопасности.
• Наличие шаблонов политик, соответствующих требованиям регуляторов, в том числе для государственных информационных систем всех уровней, Стандарта Банка России, ГОСТа защищенности информации и безопасности финансовых (банковских) операций, для объектов критической информационной инфраструктуры.
• Система лицензирования vGate 4.1 оптимизирована с учетом масштаба бизнеса организации и ее потребностей в защите ВИ.

Недостатки:

• Межсетевой экран уровня гипервизора есть пока только для VMware vShpere.
• Отсутствие поддержки VMware vShpere 6.7.
• Интерфейсы новой веб-консоли требуют доводки — это могло бы сделать процесс конфигурации и создания правил более наглядным.
• Пока отсутствует сертификация ФСТЭК России (ожидается в I квартале 2019 года).
• Отсутствие в продукте антивирусного ядра — оно бы значительно усилило степень защищенности от внешних угроз.