Продолжаем нашу серию статей о продукте номер 1 - vGate R2, который необходим для защиты виртуальных инфраструктур VMware vSphere. Напомним, что продукт позволяет автоматически настроить среду виртуализации (хост-серверы и ВМ) в соответствии с регламентами и стандартами информационной безопасности, а также защитить инфраструктуру от несанкционированного доступа. Сегодня мы поговорим об администрировании продукта со стороны службы ИБ предприятия.
В первой части статьи "Развертывание средства защиты виртуальной инфраструктуры vGate R2" мы рассказали о том, как правильно развернуть решение vGate R2 и провести его первоначальную настройку. А сегодня расскажем, какие возможности он предоставляет для службы ИБ вашей компании (напомним также, что есть версия vGate-S R2 для организаций, работающих с гостайной и сертификат ФСТЭК для обеих версий продукта).
Предварительная настройка vGate R2
Сначала откроем консоль админстратора (она может быть установлена на сервере авторизации или на рабочей станции администратора информацонной безопасности) и добавим лицензионный ключ (напомним, что vGate R2 лицезируется по числу процессоров хостов ESX / ESXi, а сервер авторизации - на экземпляр):
Давайте перейдем в настройки vGate R2 (пункт меню "Конфигурация" в категории "Главная"). Начнем с добавления хостов vCenter и ESX / ESXi в консоли управления, где вы увидите такую картинку (добавляем сразу vCenter):
Тут надо отметить, что если у вас несколько серверов vCenter - придется устанавливать для каждого из них свой сервер авторизации vGate R2 и каждый из этих периметров защищать отдельно.
После успешного добавления сервера мы сможем увидеть список виртуальных машин на вкладке "Виртуальные машины":
Также в меню "Конфигурация" можно настроить оповещения по SNMP, а также дополнительные параметры vGate R2:
Чтобы администраторы vSphere со своих рабочих мест могли получить доступ к управлению виртуальной инфраструктурой, которая находится в защищенном периметре,
должны быть определенным образом настроены правила маршрутизации. По умолчанию маршрут к защищенной сети добавляется на рабочие места администраторов vSphere (где установлен клиент vGate) с
сервера авторизации в момент запуска службы аутентификации vGate, после
чего маршрут записывается в локальную таблицу маршрутизации ПК.
Помните, что на всех компьютерах защищаемого периметра (хост-серверы и vCenter) в качестве шлюза по умолчанию нужно указать IP-адрес адаптера защищаемого периметра сервера авторизации, поскольку все соединения проксируются через сервер авторизации.
Если планируется использование других вариантов настройки маршрутизации, необходимо отменить добавление маршрута к защищенной сети (подробнее тут).
По умолчанию уровни конфиденциальности (иерархические) используются и для полномочного управления доступом, и для управления политиками безопасности. При необходимости контроль доступа по уровням конфиденциальности можно отключить.
Настройка учетных записей пользователей
Теперь можно настроить учетные записи пользователей на вкладке "Учетные записи":
Для аутентификации администраторов vSphere в vGate нельзя использовать существующие доменные или локальные учетные записи пользователей Windows (или другой ОС). Поэтому для каждого пользователя vGate следует создать свою учетную запись средствами консоли управления.
Главная учетная запись, создаваемая при установке - это единственная учетная запись, которая может редактировать список пользователей, поэтому если у вас несколько администраторов в службе ИБ, данная привилегия будет только у одного.
В списке пользователей могут присутствовать учетные записи
компьютеров - их не трогайте. Они создаются автоматически при установке агента аутентификации на компьютеры сервисных служб (DNS, AD и т. п.) во внешнем периметре
сети администрирования.
Добавление защищаемых серверов и правил доступа
Далее можно приступить к добавлению защищаемых серверов ESX / ESXi. Нужно добавить все хосты ESX / ESXi и сервер vCenter, а также другие хосты, находящиеся в периметре администрирования сети виртуальной инфраструктуры. Это могут быть системы хранения данных, серверы DNS, AD и другие, на которых также может быть установлен агент аутентификации (ссылка "Автономный сервер"):
Если DNS-сервер находится во внешней сети, то для использования доменных имен
для защищаемых серверов необходимо выполнить предварительную настройку, которая описана в документации (руководство администратора, страница 60).
Здесь же нужно задать правила доступа администраторов vSphere к этим серверам:
Обратите внимание, что тут можно добавить VMware View Connection Server, если у вас есть инфраструктура виртуальных ПК VMware View.
Тут можно использовать шаблон из предлагаемых vGate R2 - их достаточно для задания стандартных операций администратора по работе с хостом vCenter и хостами ESX / ESXi. Тут можно ограничить пользователей, которы могут управлять хостами ESX / ESXi и vCener, а также определить с каких IP они могут соединяться с сервером vCenter и хостами (полезная вещь).
Если для пользователя создано хотя бы одно правило доступа
к серверу vCenter, то в списки правил всех его ESX-серверов автоматически добавляется правило, отмеченное специальным значком. Это правило указывает на то, что этот пользователь может управлять данным ESX-сервером через vCenter в
объеме предоставленных ему на vCenter прав. Такие правила автоматически удаляются с хостов, как
только удалено последнее правило доступа пользователя к серверу vCenter.
Если требуется какой-то нестандартный порт или служба, то нажмите "Создать новое правило":
Развертывание компонентов защиты
Теперь перейдем к развертыванию компонентов защиты на серверах ESX / ESXi. Для этого переходим в раздел "Развертывание" в группе "Защищаемые серверы" и нажимаем пункт "Установить":
Здесь потребуется ввести пароль root на сервере ESX / ESXi. Повторяем процедуру для всех хост-серверов из списка. На этом предварительная настройка vGate закончена и можно переходить к управлению доступом пользователей к ресурсам виртуальной инфраструктуры.
Настройка меток безопасности и управление доступом к ресурсам vSphere
Есть 5 видов ресурсов с точки зрения управления доступом пользователей к объектам или объектов друг к другу:
защищаемый ESX-сервер;
хранилище ВМ;
виртуальная машина;
физический сетевой адаптер;
виртуальная сеть (Virtual Network)
Отдельной сущностью у нас идет администратор VMware vSphere (то есть тот, кто через vSphere Client управляет виртуальной инфраструктурой). Его учетной записи назначается определенная метка конфиденциальности (т.е., по-сути, это его уровень допуска к информации в виртуальной инфраструктуре). А при выполнении ряда стандартных операций с объектами виртуальной инфраструктуры осуществляется сравнение меток конфиденциальности перечисленных ресурсов и учетных записей администраторов.
Метка конфиденциальности - это принадлежность ресурса или пользователя к какой-либо категории (то есть, например, отдел или класс информации, например, секретно). Есть три типа меток конфиденциальности, которые "накладываются" на ресурсы и учетные записи пользователей:
Иерархическая метка - это метка, которая содержит уровень конфиденциальности. Уровень конфиденциальности - это сущность, которая строго иерархически определяет возможность доступа пользователей к ресурсам и ресурсов друг к другу. То есть, пользователь с уровнем ДСП не сможет работать с секретными и совсекретными ресурсами, а секретные виртуальные машины не могут находиться на неконфиденциальных хранилищах. Наоборот же, например, на уровень ниже пользователь или ресурс сможет работать с ресурсами, но только если для него установлено соответствующее разрешение.
Неиерархическая метка - это метка, которая содержит категорию конфиденциальности. В вашей инфраструктуре может быть сколько угодно категорий, при этом все они будут находиться на одном уровне иерархии. Поэтому механизм прост - если у ресурса есть такая метка (категория) - то пользователь из этой категории может его использовать. Понятное дело, что на одном ресурсе может быть несколько меток - это значит, что несколько категорий пользователей используют его совместо (например, финансисты и бухгалтерия). Здесь становится видно, что данная модель защиты от НСД вполне подходит коммерческим компаниям. По умолчанию, у вас есть пять категорий, обозначенных цветом ("Синий", "Зеленый", "Желтый" и т. д.), его можно просто менять.
Составная метка - это метка, которая содержит одновременно один уровень конфиденциальности и одну или несколько категорий конфиденциальности. Например, они могут пригодиться для работы с совсекретными данными (уровень), но с которыми работают разные отделы (категория).
Помните, что по умолчанию включен только контроль доступа по категориям конфиденциальности.
Перед тем, как назначать метки конфиденциальности, вам нужно сесть и подумать, как будет выглядеть виртуальная инфраструктура с точки зрения управления доступом к ресурсам (с учетом миграции виртуальных машин между хостами средствами vMotion, перемещения хранилищ за счет Storage vMotion и прочего), то есть нужно нарисовать что-то вроде вот такой картинки:
Здесь мы можем проследить картину "доменов безопасности", в которых находятся пользователи и ресурсы vSphere (машины, сети, адаптеры, хранилища, хосты). Вот их вам и нужно спроектировать, исходя из требований к ИБ в вашей организации.
Только после этого можно переходить к настройке меток. Основное окно настройки меток конфиденциальности ("Метки безопасности") находится в категории "Главная":
Тут уже есть некоторый набор меток для категорий конфиденциальности (напомним, что между ними нет иерархических отношений - они равнозначны), которые можно переименовать, например, в соответствии с названиями отделов вашей организации.
Чтобы добавить плоскую метку (категория), нажимаем "Добавить" в разделе "Категории":
В группе настроек "Уровни конфиденциальности" отображается перечень допустимых уровней конфиденциальности (добавить их нельзя, можно только переименовать, при этом иерархические отношения между ними останутся). Это как раз и есть категории секретности ваших данных и ресурсов виртуальной инфраструктуры, к которым различные категории администраторов будут иметь доступ.
Иногда имеет смысл настроить составные метки (уровень + категория), но нужно запретить определенные их комбинации (например, нельзя делать метку "совсекретно+отдел болтунов"). Для этого есть настраиваемая матрица сочетаний. По умолчанию, администратор ИБ может назначать любые комбинации:
Теперь давайте посмотрим, где назначаются эти метки ресурсам vSphere для создания доменов безопасности в вашей виртуальной инфраструктуре. Ниже приведена последовательность настройки, которой лучше придерживаться.
Сначала назначим уровень (опционально - категорию) администратору vSphere (он же пользователь vGate):
Это определит допуск администратора vSphere к ресурсам различных уровней и категорий (к более высоким он не будет иметь допуска).
Потом в категории "Защищаемые серверы" выберем пункт "Назначить метку" для серверов ESX / ESXi:
Обратите внимание на пункт "Может исполнять машины с меньшим уровнем" - если он отмечен, то, например, секретный хост ESX / ESXi сможет выполнять несекретные машины (в некоторых организациях это важно, например, где придерживаются стандарта PCI). Наоборот - нельзя: неконфиденциальный хост сможет выполнять только неконфиденциальные машины.
Далее назначим метку для хост-сервера:
Затем назначаем метку для физических аплинков (сетевых адаптеров) хостов:
Уровень конфиденциальности каждого из
адаптеров должен быть не выше уровня
конфиденциальности его сервера. Также можно отметить "Возможен трафик для VLAN разных уровней", но такая конфигурация не соответствует некоторым регламентам.
Далее для виртуальной сети (VLAN):
Уровень конфиденциальности VLAN должен быть:
Не больше уровня конфиденциальности физического сетевого адаптера, к которому она подключена (если поле "Возможен трафик для VLAN разных уровней" для адаптера отмечено).
Равен уровню конфиденциальности физического сетевого адаптера, к которому она подключена (если поле "Возможен трафик для VLAN разных уровней" для адаптера не отмечено).
То есть среди ресурсов vSphere вы можете также проследить иерархию, от которой зависит настройка vGate.
Далее для хранилища:
Отметьте галочку "Может хранить ВМ с меньшим уровнем", но это тоже может оказаться некорректно по отношению к некоторым регламентам и стандартам.
Этого всего будет достаточно для того, чтобы создаваемые виртуальные машины автоматически получали метки безопасности (метка машины = метка хранилища, где она находится).
Наконец назначаем метки для существующих виртуальных машин:
Уровень конфиденциальности ВМ должен быть:
Не выше уровня конфиденциальности ESX-сервера, на котором она выполняется (если отмечено поле "Может исполнять машины с меньшим уровнем"), или равен уровню ESX-сервера хранилища (если поле не отмечено).
Не выше уровня конфиденциальности хранилища, на котором хранятся файлы ВМ (если отмечено поле "Может хранить ВМ с меньшим уровнем"), или равен уровню конфиденциальности хранилища (если поле не отмечено).
Помните о том, что администраторы могут перемещать виртуальные машины между хостами и хранилищами, что надо учитывать при разработке архитектуры доменов безопасности vGate.
Далее администратор ИБ в процессе функционирования виртуальной инфраструктуры должен следить за изменением ресурсов в ней и своевременно назначать им метки безопасности.
Как проверяются условия выполнения операций для уровней и категорий
Это один из важный моментов при использовании vGate - понимание логики работы при выполнении различных операций. На этой картинке приведен список того, что у вас получается, когда вы пытаетесь произвести те или иные операции в рамках домена безопасности, определенного уровнями или категориями.
Взаимосвязь меток безопасности и политик безопасности
vGate R2 нужен не только для того, чтобы защищать информацию в виртуальной инфраструктуре от несанкционированного доступа, но и чтобы автоматически настраивать объекты vSphere в соответствии с политиками безопасности. Об этом написано в нашей статье "Шаблоны и политики безопасности в продукте vGate 2 от Кода Безопасности".
Поскольку метки безопасности, накладываемые на ресурсы, создают домены безопасности, в рамках каждого из них мы можем определить свои собственные политики. Наборы политик создаются из уже готовых шаблонов, таких как, например, VMware Security Hardening или PCI DSS.
Таким образом, для каждого уровня или категории мы настраиваем политики безопасности:
Ниже мы опишем, как они создаются и что это такое.
Управление политиками безопасности vGate R2
Политики безопасности, реализованные в vGate, контролируют критичные для безопасности виртуальной среды настройки серверов ESX и ВМ. Помните те самые политики, на предмет соответствия которым вы сканировали инфраструктуру виртуализации с помощью бесплатного средства vGate Compliance Checker? Так вот теперь их можно задать для хостов VMware ESX, а также виртуальных машин. И, соответственно, привести их в соответствие с этими политиками, т.е. автоматически настроить виртуальную инфраструктуру.
Основная идея таких политик - облегчить жизнь администратору виртуальной инфраструктуры VMware vSphere и сотрудникам службы ИБ при работе с серверами VMware ESX / ESXi, чтобы не настраивать их вручную и не изучать, что конкретно требуется для приведения инфраструктуры к стандартам различных видов.
Шаблонов наборов политик в vGate много (подробнее о них можно узнать из документации к продукту):
vGate - встроенный базовый набор политик
CIS 1.0 - в соответствие с документом CIS VMware ESX Server 3.x Benchmark (v 1.0)
CIS 1.2 - в соответствие с документом CIS VMware ESX Server 3.5 Benchmark (v 1.2.0)
PCI DSS - для соответствия требованиям PCI DSS 1.2 и PCI DSS 2.0
VMware - для соответствия документу
VMware Security Hardening Best Practice
АС 1Г - для стандарта автоматизированных систем класса 1Г в
соответствие РД ФСТЭК "Автоматизированные системы. Защита от
несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации"
АС 1В - класса 1В
АС 1Б - класса 1Б
СТО БР ИСПДн-Д - рекомендуемый набор политик безопасности для приведения перенесенных в виртуальную среду информационных систем персональных
данных класса ИСПДн-Д в соответствие стандарту СТО БР ИББС (стандарт Банка России)
СТО БР ИСПДн-Б
СТО БР ИСПДн-И
СТО БР ИСПДн-С
ИСПДн К1 Рекомендуемый набор политик безопасности для приведения перене-
сенных в виртуальную среду информационных систем персональных
данных класса К1 в соответствие законодательству в области защиты персональных данных (ФЗ 152)
ИСПДн К2
ИСПДн К3
Вообще, политики - это очень обширный функционал vGate, который позволяет существенно сэкономить на настройке инфраструктуры vSphere,
Для начала работы с политиками нужно добавить новый набор в разделе "Политики безопасности":
Нам предложат выбрать один или несколько шаблонов политик безопасности, которые будут привязаны к создаваемому нами набору шаблонов:
Выбираем необходимое нам количество шаблонов (в соответствии с требованиями вашей компании) и нажимаем "Далее". Тут мы видим уже конкретные политики, которые можно включить/выключить, а также редактировать их параметры.
Тут мы видим, что мы можем настроить пароль загрузчика Grub для хост-сервера. Описание политики весьма детальное:
Полный список существующих политик приведен в документации к продукту. Надо отметить, что для серверов VMware ESXi на данный момент поддерживаются только следующие политики:
Запрет клонирования виртуальных машин;
Запрет создания снимков виртуальных машин;
Список запрещенных устройств;
Доверенная загрузка виртуальных машин;
Запрет подключения USB-носителей к ESX-серверу;
Очистка памяти виртуальных машин;
Запрет доступа к консоли виртуальной машины;
Запрет доступа к файлам виртуальных машин;
Затирание остаточных данных на СХД при удалении ВМ;
Запрет смешивания разных типов сетевого трафика.
Политики применяются к трем объектам:
хост-серверы
виртуальные машины
сетевые адаптеры (тут только одна политика "Запрет смешивания разных типов сетевого трафика")
Таким образом, порядок применения политик к объектам таков:
Создаете и настраиваете набор политик из шаблонов
Назначаете этот набор метке конфиденциальности (см. предыдущий блок статьи)
Назначаете метку ресурсам VMware vSphere (хосты, ВМ и адаптеры)
После выполнения настройки набор политик начинает действовать не сразу, а по истечении некоторого периода времени. Этот период задается в параметре intrerval секции
vagent в конфигурационном файле сервера ESX /etc/vgate/vgate.cfg (по умолчанию 10 минут). Для виртуальных машин некоторые политики начинают действовать только после их перезагрузки.
Информацию о статусе применения всех политик на защищаемые объекты, а также о возникновении ошибок можно получить с помощью отчета "Соответствие стандартам безопасности (подробно)".
Если вам нужно будет создать новый набор политик, его можно создать из существующего набора:
Назначим созданный нами набор политик для начала конфигурации виртуальной инфраструктуры для соответствия требованиям безопасности:
Другие возможности vGate R2
Настройку политики паролей для пользователей vGate R2 можно найти в разделе "Учетные записи":
Для предотвращения использования легко подбираемых паролей каждый пароль
проверяется по словарю часто используемых паролей. Пароль может быть назначен только в
случае отсутствия его в словаре.
В категории "Аудит" можно посмотреть список зарегистрированных vGate событий:
Здесь есть широкие возможности по поиску событий.
Для каждого события есть подробное описание:
Также в vGate R2 есть широкий функционал по формированию отчетов, которые позволяют в
любой момент получить актуальную информацию о состоянии настроек безопасности, соответствии политик безопасности отраслевым стандартам, а также об изменениях конфигурации и произошедших событиях информационной безопасности за определенный промежуток времени.
Подготовленный отчет можно выгрузить в следующие форматы:
XML-файл с данными отчета;
текстовый файл с разделителями (CSV);
графический файл (TIFF);
файл Adobe Acrobat (PDF);
веб-архив (MHT);
файл Excel (XLS).
О функционале отчетов, а также о средствах контроля целостности и некоторых других аспектах работы vGate R2 мы расскажем в следующей статье. Приходите почаще.
RSS
