Общие соображения безопасности

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

Естественно  будет выделить  несколько  уровней  виртуальной инфраструктуры, подход к защите которых различается:

Q  уровень виртуализации (гипервизор, VMkernel);

Q  уровень виртуальных машин;

Q  ESX Service Console;

Q  виртуальная сеть на ESX(i);

Q  системы хранения;

Q  vCenter Server.

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

Скомпрометированная виртуальная машина может перемещаться между серверами и компрометировать виртуальные машины на других серверах.

Обратите внимание. VMware предлагает свое решение межсетевого экрана для ВМ – vShield Zones. Кроме того, есть достаточное  количество средств обеспечения безопасности от других производителей.

Также VMware предлагает набор программных  интерфейсов (API) под названием VMSafe. C его помощью приложение из одной ВМ может получать  доступ к другим ВМ на этом ESX(i) через гипервизор. Например, мы можем иметь одну ВМ с антивирусом,  которая  будет сканировать память  всех прочих ВМ на этом сервере. В каких-то продуктах могут быть реализованы и другие полезные  функции, например сканирование выключенных ВМ.

Несмотря на то что несколько  ВМ работают  на одном сервере, как-то перераспределяют  его память, их совместная  работа не ухудшает ситуацию с безопасностью.  Изнутри одной  ВМ  нет способа  получить  доступ  внутрь  другой  через гипервизор,  кроме  специализированных API  VMsafe.  Использование этих  API требует четкого понимания механизмов работы гипервизора и целесообразности включения в эту работу. По умолчанию  эти API не используются никем. Чтобы они начали работать, потребуется в явном виде предпринять ряд действий, как-то: установить соответствующее  ПО или Appliance, запустить его и настроить.

VMkernel. Гипервизор  ESX и ESXi. Вопрос безопасности  гипервизора достаточно важен, так как захват гипервизора позволит злоумышленнику перехваты-

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

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

Из  средств  внутренней  защиты  присутствуют  только  брандмауэр  (на  ESX) и система  разграничения прав. Если  вопрос безопасности  стоит остро, то имеет смысл обратиться  к сторонним  производителям средств безопасности, в чьих активах уже есть специализированные программные  продукты для ESX(i).

Зато гипервизор  является узкоспециализированной операционной системой, как следствие  – поверхность  атаки значительно меньше, чем для традиционных операционных систем. В простых случаях безопасность гипервизора обеспечива ется прежде всего изоляцией его сети. Сеть для VMotion, для Fault Tolerance, сеть для трафика  iSCSI и NFS желательно выделять  в отдельные физические сети или VLAN.

Service Console – управляющий компонент  ESX.  Собой  представляет  Red Hat  Enterprise Linux 5, в котором оставили  в основном  только необходимые для ESX компоненты.  Для обеспечения  безопасности  Service Console рекомендуется ее интерфейсы опять  же помещать  в изолированные сети. Также  в составе Service Console есть брандмауэр, который имеет смысл настраивать на блокирование всех незадействованных Service Console портов. Про настройку этого брандмауэра  я расскажу позднее.

VMware  регулярно выпускает  обновления, закрывающие уязвимости,  найденные в VMkernel  (впрочем,  таковых было известно очень мало) и Service Console. Своевременная установка  обновлений – важная часть обеспечения  безопасности. VMware  предлагает  специальный компонент  – VMware  Update Manager, который дает возможность устанавливать обновления в автоматическом режиме на серверы  ESX(i). О нем буду рассказывать в последней  главе. Обратите  внимание: обновления для Service Console надо получать  у VMware, а не у Red Hat.  Установка  обновления от Red Hat  (если она вообще получится) может заменить  некоторые библиотеки, что вредно и для нормальной работы, и для безопасности  Service Console.

C точки  зрения  безопасности,  полезным  шагом является настройка централизованного журналирования.  Например, VMware  предлагает  vMA  –  vSphere Management Appliance. Это ВМ с Linux, внутри  которой установлены необходимые для управления vSphere компоненты. Управление выполняется из командной  строки. Так вот, например, эту vMA несложно настроить на сбор файлов журналов  с серверов ESX(i).

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

VMware vCenter – это  приложение для  Windows.   Каких-то  специальных средств  обеспечения  безопасности  для него не существует. Но стандартные  для таких задач – это опять же установка  обновлений, настройка  межсетевого экрана и антивирус,  помещение  vCenter в изолированную сеть. Всем этим надо пользоваться.

Возможно, у вас доступ к управлению виртуальной инфраструктурой, то есть к vCenter через клиент  vSphere,  будут иметь  несколько  людей. В  таком  случае крайне желательным является жесткое разграничение прав. О механизме разграничения прав в vCenter вскоре расскажу.

Виртуальные сети. Виртуальные коммутаторы   VMware  имеют  некоторые отличия  от коммутаторов физических в силу своей природы. Например, вКоммутаторы  не поддерживают Spanning  tree, не устанавливают соответствие  MACадресов  и портов  путем  анализа  трафика  и т. д. Данные  отличия  вытекают  из особенностей эксплуатации вКомутаторов – для них не предполагается прямого соединения  между собой, поэтому Spanning  tree и не нужен. MAC-адреса ВМ им сообщает гипервизор,  генерирующий эти MAC-адреса для ВМ, и анализировать трафик нет нужды.

Вывод:  с сетевой  безопасностью  нет  особо  усложняющих работу  нюансов. Разумеется, надо знать и понимать  важные настройки вКоммутаторов,  в первую очередь из группы настроек «Security».

Хранилища. Безопасность хранилищ для ВМ в основном сводится к правиль ному зонированию и маскировке  LUN для серверов ESX(i). Так как сами ВМ не знают о физическом хранилище  ничего (у ВМ нет доступа к HBA/iSCSI инициа тору/клиенту NFS), с их стороны угроз безопасности хранилищ нет. Для полноты картины стоит упомянуть  о том, что виртуальная машина может получить доступ к дисковому контроллеру с помощью функции VMDirectPath, и о том, что системы хранения  iSCSI и NFS могут быть подключены  по сети сразу к виртуальной машине, не через гипервизор. Но такие конфигурации уже не связаны с вопросом безопасности  гипервизора и его служб.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий