Hyper-V Security или безопасность Hyper-V

Денис Абраменко

Сегодня поговорим о безопасности систем виртуализации на базе Hyper-V.

Рассмотрим четыре основные темы:

• Обзор систем виртуализации Microsoft;
• Архитектура Hyper-V;
• Hyper-V подход к безопасности;
• Обзор Hyper-V Security Guide

Реализация виртуализации в более ранних версиях

При рассмотрении темы безопасности мы поговорим о безопасности Hyper-V в целом, кратко рассмотрим архитектурные особенности гипервизора Hyper-V. Поговорим о том, что необходимо учитывать при планировании, развертывании и поддержке инфраструктуры Hyper-V. Для начала рассмотрим небольшое сравнение различных архитектур виртуализации. Рассмотрим несколько подходов к виртуализации в целом, как в более ранних версиях, так и в виртуализации на базе гипервизора Windows Server 2008 R2.

Рис. 1. Архитектура систем виртуализации более ранних версий.

На данный момент существует несколько типов систем виртуализации – предыдущие версии систем виртуализации и системы виртуализации на базе гипервизора.

В качестве примера предыдущие версий систем можно привести:

• Microsoft Virtual PC
• Microsoft Virtual Server
• VMware Workstation
• VMware Player

Давайте рассмотрим основные отличия предыдущих версий систем виртуализации от систем на базе гипервизора.

Архитектура предыдущих систем виртуализации предполагает, что монитор виртуальных машин (МВМ) устанавливается прямо поверх операционной системы и работает в среде хостовой операционной системы (ОС).

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

В обычной операционной системе Windows Server 2003 или Windows XP выполняется установка программного обеспечения, будь то Virtual Server или WMware Workstation. При этом в операционную систему устанавливаются и настраиваются некоторые службы, которые запускаются после загрузки основной операционной системы. Данные службы выполняются в пользовательском окружении процессора – так называемом пользовательском режиме. Этот режим является самым низкоприоритетным. Все виртуальные машины, которые запускаются данными службами, работают в этом же режиме. Основным недостатком работы такого типа виртуальных машин являются возникающие сложности с операциями ввода-вывода при обращении к устройствам ввода-вывода: сетевому адаптеру, жесткому диску, клавиатуре, мыши, видеоподсистеме и т.д.

Дело в том, что виртуальная машина ничего не знает о системе виртуализации. C точки зрения виртуальной машины, она работает на некоем аппаратном обеспечении, которое в свою очередь эмулируется приложением и службами систем виртуализации (за исключением Windows Vista, Windows 7, Windows Server 2008/R2).

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

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

Для ускорения операций в разных системах виртуализации реализованы некоторые инструменты, так называемые «Компоненты интеграции». ДляVirtual Server это VM editions, в VMware Workstation это VMware Tools. Инструменты интеграции позволяют устранить некоторые прослойки между виртуальным оборудованием и уровнем абстрагирования физического сервера.

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

Рис. 2. Архитектура систем виртуализации на базе гипервизора.

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

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

Благодаря использованию в Hyper-V синтетических драйверов, которые не требуют дополнительной эмуляции виртуальных устройств, обмены данными при операциях ввода/вывода происходят гораздо быстрее по сравнению с традиционными решениями. Максимальный эффект достигается при использовании в гостевых виртуальных машинах операционных систем Windows Server 2008 и Windows Vista™ с установленными в них драйверами синтетических устройств. В такой конфигурации находят, в частности применение синтетические драйверы для сетевых адаптеров и адаптеров памяти, тесно взаимодействующие с Windows-AРI. Это позволяет Hyper-V осуществлять быстрое преобразование I/O-запросов от гостевых систем в запросы к физическому оборудованию на родительском разделе. Используя соответствующие компоненты интеграции, синтетические драйверы могут применяться также в отличных от Windows операционных системах (таких, как, например, операционные системы Linux с XEN).

В разных решениях виртуализации применяются разные подходы к реализации архитектуры построения гипервизоров –монолитный и микроядерный.

В частности, в VMware ESX реализован принцип монолитного гипервизора.

Microsoft Hyper-V реализована архитектура микроядерного гипервизора.

Монолитный подход в реализации гипервизора

Рис. 3. Архитектура монолитного гипервизора.

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

В монолитной (monolithic) модели – гипервизор для доступа к оборудованию использует собственные драйверы. Гостевые ОС работают на виртуальных машинах поверх гипервизора. Когда гостевой системе нужен доступ к оборудованию, она должна пройти через гипервизор и его модель драйверов. Обычно одна из гостевых ОС играет роль администратора или консоли, в которой запускаются компоненты для предоставления ресурсов, управления и мониторинга всех гостевых ОС, работающих на сервере.

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

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

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

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

Такая реализация гипервизора накладывает существенные проблемы с точки зрения неподдерживаемого оборудования. Например, вы собрались использовать оборудование «Сервер» достаточно мощный и надежный, но при этом в гипервизоре не оказалось нужного драйвера для RAID-контроллера или сетевого адаптера. Это сделает невозможным использование соответствующего оборудования, а, значит, и сервера. Тоже справедливо и для вновь подключаемых устройств – если в гипервизоре нет драйвера для устройства, вы его использовать не сможете.

Если даже в новой версии гипервизора будет нужный драйвер, вам потребуется остановить все виртуальные машины на узле или перенести виртуальные машины (в случае, если это кластер) на другой узел, после чего произвести обновление гипервизора. Сами обновления, с точки зрения безопасности, тоже не самое безопасное мероприятие.

Микроядерный подход в реализации гипервизора

Рис. 4. Микроядерный подход в реализации гипервизора.

Альтернативу монолитному подходу в реализации гипервизора составляет микроядерная (microkernelized) реализация. В ней можно говорить о «тонком гипервизоре», в этом случае в нем совсем нет драйверов. Да-да, именно так – вообще нет драйверов. Вместо этого драйверы работают в каждом индивидуальном разделе, чтобы любая гостевая ОС имела возможность получить через гипервизор доступ к оборудованию. При такой расстановке сил каждая виртуальная машина занимает совершенно обособленный раздел, что положительно сказывается на защищенности и надежности.

В микроядерной модели гипервизора (в виртуализации Windows Server 2008 R2 используется именно она) один раздел является родительским (parent), остальные – дочерними (child). Раздел – это наименьшая изолированная единица, поддерживаемая гипервизором.

Каждому разделу вы назначаете конкретные аппаратные ресурсы – долю процессорного времени, объем памяти, устройства и пр. Родительский раздел создает дочерние разделы и управляет ими, а также содержит стек виртуализации (virtualization stack), используемый для управления дочерними разделами. Родительский раздел, вообще говоря, является также корневым (root), поскольку он создается первым и владеет всеми ресурсами, не принадлежащими гипервизору. Обладание всеми аппаратными ресурсами означает среди прочего, что именно корневой (то есть, родительский) раздел управляет питанием, подключением самонастраивающихся устройств, ведает вопросами аппаратных сбоев и даже управляет загрузкой гипервизора.

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

Стек виртуализации также обеспечивает доступ к интерфейсу управления, который в случае Windows Server 2008 R2 является поставщиком WMI.

Преимущество микроядерного подхода, примененного в Windows Server 2008 R2, по сравнению с монолитным подходом состоит в том, что драйверы, которые должны располагаться между родительским разделом и физическим сервером, не требуют внесения никаких изменений в модель драйверов. Иными словами, в системе можно просто применять существующие драйверы. В Microsoft этот подход избрали, поскольку необходимость разработки новых драйверов сильно затормозила бы развитие системы. Что же касается гостевых ОС, они будут работать с эмуляторами или синтетическими устройствами.

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

Размер гипервизора Hyper-V менее 1,5 Мб , он может поместиться на одну 3.5-дюймовую дискету.

В итоге получается:

Основная задача гипервизора – это планирование ресурсов, гипервизор отвечает за то, кто, когда получает доступ к таким ресурсам как процессор и память, каким образом разделяется доступ между операционной памятью физической ОС и виртуальной. Доступ к физическим устройствам контролируется основной операционной системой.

Эта ОС отвечает за доступ к устройствам ввода вывода. Драйверы всех устройств устанавливаются поверх Windows Server 2008 R2. Большим преимуществом такого подхода является возможность обновлять драйвера устройств. При этом нет необходимости выполнять переустановку гипервизора. Не нужно вносить никакие исправления в гипервизор, нет прямой зависимости от вендора в части драйверов и обновлений. С точки зрения безопасности такой процесс является оптимальным.

С точки зрения безопасности, чем меньше объем самого гипервизора, тем безопаснее; меньше вероятность потенциальных ошибок в коде. Сам гипервизор работает с уровнем привелегий Ring 0 – это ниже чем приоритет работы ядра ОC – включение драйверов в гипервизор увеличивает его объем и потенциальную возможность уязвимости такого гипервизора.

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

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

Архитектура Hyper-V на базе Windows Server 2008 R2

Рис. 5. Архитектура гипервизора.

Чтобы обеспечить высокое быстродействие гостевых систем, компания Microsoft пошла на значительное изменение архитектуры серверной платформы Windows Server 2008 R2. При установке операционной системы, поверх аппаратного обеспечения сервера устанавливается «тонкий» слой программного обеспечения (гипервизор), управляющий ресурсами как хостовой, так и гостевых операционных систем.

Hyper-V поддерживает разграничение согласно понятию «раздел». Раздел – логическая единица разграничения, поддерживаемая гипервизором, в котором работают операционные системы. Каждый экземпляр гипервизора должен иметь один родительский раздел, с запущенным Windows Server 2008 R2. Стек виртуализации запускается в родительском разделе и обладает прямым доступом к аппаратным устройствам. Затем родительский раздел порождает дочерние разделы, в которых и располагаются гостевые ОС. Дочерний раздел также может порождать собственные дочерние разделы. Родительский раздел создает дочерние при помощи API гипервызова, представленого в Hyper-V.

В родительском разделе находиться хостовая операционная система и запущенный в ней стек виртуализации (Virtualization Stack), обеспечивающий виртуализацию устройств и предоставление интерфейса управления Windows (Windows Management Interface, WMI). В хостовой операционной системе на уровне ядра будут работать службы Virtualization Service Providers (VSPs), предоставляющие возможности по совместному использованию оборудования, клиентами которых являются Virtualization Service Clients (VSCs) в гостевых системах.

Внутри гостевой ОС работает служба виртуализации Virtualization Service Provider( VSP) –серверная компонента, которая запускается в родительском разделе (или любом другом разделе, распоряжающемся ресурсами оборудования). VSP общается с драйверами устройств и предлагает услуги оборудование всем, кто их запрашивает (например, в ответ на запросы ввода/вывода). VSP может передать запрос для обработки либо непосредственно физическому устройству через драйвер, работающий в привилегированном или пользовательском режиме, либо соответствующей службе, такой как файловая система.

В пользовательском режиме в родительском разделе работают службы Virtual Machine Service (VM Service), обеспечивающие средства управления виртуальными машинами и их рабочими процессами.

Virtual Machine Worker Process – это процесс в стеке виртуализации, который представляет и обслуживает определенную машину, работающую в системе (для каждой машины запущен один VM Worker Process). И, наконец, WMI Provider, обеспечивает набор интерфейсов для управления виртуализацией в системе.

Внутри унаследованной гостевой ОС в привилегированном режиме работает Virtualization Service Client (VSC) – «клиентская» компонента, работающая в дочернем разделе и потребляющая услуги от VSP. Ключевым моментом является то, что для каждого типа устройств создается своя пара VSP/VSC.

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

Дочерние разделы не имеют непосредственного доступа к аппаратным ресурсам, но зато получают виртуальное представление ресурсов, называемое виртуальными устройствами. Любая попытка обращения к виртуальным устройствам перенаправляется через VMBus к устройствам родительского раздела, которые и обработают данный запрос. VMBus – это логический канал, осуществляющий взаимодействие между разделами. Ответ возвращается также через VMBus. Если устройства родительского раздела также являются виртуальными устройствами, то запрос будет передаваться дальше, пока не достигнет такого родительского раздела, где он получит доступ к физическим устройствам. Родительские разделы запускают Virtualization Service Provider, который соединяется с VMBus и обрабатывает запросы доступа к устройствам от дочерних разделов. Виртуальные устройства дочернего раздела работают с клиентом сервиса виртуализации (Virtualization Service Client – VSC), который перенаправляет запрос через VMBus к VSP родительского раздела. Этот процесс прозрачен для гостевой ОС.

Разделы виртуализации не имеют ни доступа к физическому процессору, ни возможности управлять его реальными прерываниями. Вместо этого, у них есть виртуальное представление процессора и гостевой виртуальный адрес, зависящий от конфигурации гипервизора, вовсе необязательно при этом, занимая все виртуальное адресное пространство. Гипервизор может определять набор процессоров для каждого раздела. Гипервизор управляет прерываниями процессора и перенаправляет их в соответствующий раздел, используя логический контроллер искусственных прерываний (Synthetic Interrupt Controller, SynIC). Hyper-V может аппаратно ускорять трансляцию адресов между различными гостевыми виртуальными адресными пространствами при помощи IOMMU (I/O Memory Management Unit – устройство управления вводом-выводом памяти), которое работает независимо от аппаратного управления памятью, используемого процессором.

Виртуальные устройства также поддерживают технологию прогрессивного ввода/вывода (Enlightened I/O) для накопителей, сетевых и графических подсистем. Enlightened I/O – специализированная виртуализационная реализация высокоуровневых протоколов таких, как например, SCSI. Она обеспечивает возможность работать с VMBus напрямую, что позволит параллельно обрабатывать любые уровни эмуляции устройства. Это делает взаимодействие более эффективным, но взамен требует от гостевой ОС поддержки Enlightened I/O. Windows Server 2008 R2, Windows Vista, Windows 7 и SUSE Linux сейчас являются единственными операционными системами, которые обладают поддержкой Enlightened I/O, позволяющей им работать быстрее в качестве гостевых ОС под Hyper-V, чем прочие операционные системы, которым требуется более медленная эмуляция устройств.

Рис. 6. Возможный вариант деструктивных действий.

Безопасность гипервизора

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

Защита памяти: привязка физической памяти к виртуальной машине

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

Защита системы ввода вывода

Основная ОC имеет возможность настройки правил доступа к устройствам ввода/вывода для виртуальных машин. Это позволит ограничивать доступ к тем или иным устройствам ввода/вывода по средствам применения политик.

Реализован механизм защиты доступа к гипервызовам

Гипервизор не дает использовать привилегированные инструкции процессора.

Тесная интеграция с Authorization Manager

Система позволяет настроить ролевое управление виртуальными машинами.

Разграничение прав на группы виртуальных машин

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

Защита общих ресурсов

Доступ ко всем ресурсам Hyper-V предоставляется только на чтение. Например, нельзя подключить образ к нескольким виртуальным машинам и произвести изменения с любой из них.

SID виртуальной машины

С появлением механизма виртуализации Hyper-V в составе Windows Server 2008 встал вопрос об изоляции файлов и памяти одной виртуальной машины от других. Очевидно, что все виртуальные машины работают в контексте службы Hyper-V Virtual Machine Management в рамках процесса Virtual Machine Worker Process (vmwp.exe). Так как же давать раздельные права объектам, работающим внутри одной службы? Для этого и было введено понятие SID виртуальной машины. Если взглянуть на ACL файлов ВМ, мы увидим там SID вида NT VIRTUAL, который используется для изоляции процесса работы одной виртуальной машины от другой. Полностью изолируется возможность доступа к файлам, дискам, памяти одной виртуальной машину к другой

Рис. 7. SID виртуальной машины.

Hyper-V Руководство по безопасности

Основные вопросы безопасности:

• Безопасность управляющей операционной системы;
• Безопасность виртуальных машин;

Безопасность управляющей операционной системы. Рекомендации по установке

При установке сервера Hyper-V рекомендуется выполнить ряд шагов, повышающих общую безопасность системы. Можно уменьшить потенциальную площадь атаки, установив роль Hyper-V на сервер Windows 2008 R2, развернутый в режиме ядра без графической оболочки. Также рекомендуется использовать дополнительные сетевые адаптеры (как минимум два), один из которых будет использоваться для работы виртуальных машин, другой для администрирования сервера с установленной ролью Hyper-V.

Итак, первая рекомендация: используйте в качестве управляющей операционной системы вариант установки Server Core для ОС Windows Server 2008 R2. Установка Server Core обеспечивает наименьшую поверхность атаки и уменьшает количество исправлений, обновлений и перезапусков, требуемых для обслуживания.

Важное замечание: Невозможно обновить вариант установки Server Core до полной установки ОС Windows Server 2008 R2. Если потребуется пользовательский интерфейс Windows или серверная роль, которая не поддерживается в установке Server Core, вам придется выполнить полную установку Windows Server 2008 R2.

Таким образом, можно выделить основные преимущества варианта установки Server Core:

• Минимизируется площадь атаки на управляющую операционную систему (присутствуют только минимальный набор служб приложений);
• Используется минимальное кол-во устройств;
• Более высокая производительность системы, за счет использования минимального количества компонентов в системе. Минимум обновлений – система требует минимального кол-ва перезапусков.

Основные недостатки варианта установки Server Core:

• Сервером, развернутым в режиме Server Core нельзя управлять с консоли традиционными средствами графического интерфейса – на сервере отсутствуют графические инструменты управления;
• Некоторые драйверы и приложения не поддерживаются в режиме Server Core. В частности отсутствует компонент .NET Framework;
• На сервере, установленном в режиме Server Core можно использовать только те драйвера и приложения, которые прошли проверку на совместимость;

Все замечания справедливы для всех версий Windows 2008 R2 (Standard, Enterprise, Datacenter).

Установка роли Hyper-V в ОС Windows Server 2008 в варианте установки Server Core.

Используйте оборудование, протестированное для работы с Hyper-V. Ознакомиться со списком оборудования можно на сайте Microsoft в разделе Windows Server catalog.

Требования к оборудованию для развертывания роли Hyper-V

Процессор с 64-разрядной архитектурой. Сервер Hyper-V доступен в 64-разрядных версиях Windows Server 2008 R2, а именно в 64-разрядных версиях Windows Server 2008/R2 Standard, Windows Server 2008/R2 Enterprise и Windows Server 2008/R2 Datacenter. Роль Hyper-V недоступна для 32-разрядных версий (версий x86) Windows Server 2008/R2. Также эта роль недоступна для серверов на базе процессоров Itanium. Однако средства управления Hyper-V доступны для 32-разрядных версий ОС.

Аппаратная поддержка виртуализации. Эта возможность доступна в процессорах с поддержкой виртуализации, а именно в процессорах, построенных с использованием технологии виртуализации Intel (Intel VT) или технологии виртуализации AMD (AMD-V).

Аппаратно реализуемое предотвращение выполнения данных (Data Execution Prevention, DEP) должно присутствовать и быть задействовано. В частности, необходимо выставить разряд Intel XD (разряд отключения исполнения) или разряд AMD NX (разряд запрета исполнения).

Контрольный список при установке:

• Для роли Hyper-V используйте сервер, установленный в режиме Server Core;
• Перед установкой роли Hyper-V установите все необходимые обновления на сервер, используя соответствующие команды, после установки обновлений перезагрузите сервер;
• Перед установкой роли Hyper-V убедитесь, что на оборудовании активированы соответствующие опции для поддержки виртуализации;
• После установки роли Hyper-V проверьте системные журналы на предмет ошибок;
• После установки роли Hyper-V проверьте наличие обновлений для Hyper-V и установите их. Список доступных обновлений можно найти на на узле ;

Для управления средой Hyper-V используйте последние версии инструментов управления для Windows Vista/Windows 7 или Windows 2008 Server, которые позволяют в полной мере управлять сервером Hyper-V через графический интерфейс.

Конфигурация сетевых интерфейсов

Правильная конфигурация сетевых интерфейсов значительно повышает общий уровень безопасности узлов Hyper-V. Microsoft рекомендует использовать как минимум два сетевых адаптера на узле Hyper-V. Для операционной системы сервера виртуализации используйте выделенный сетевой адаптер. По умолчанию для управляющей операционной системы виртуальная сеть не настраивается. Для управления сервером, где выполняется Hyper-V, используйте выделенный сетевой адаптер, подключите его к доверенной подсети и изолируйте от всех остальных подсетей. Не используйте этот сетевой адаптер для работы виртуальных машин. Для работы сети виртуальных машин используйте один или несколько различных выделенных сетевых адаптеров. Это позволяет применять разные уровни политик безопасности сети и конфигурации виртуальных машин.

Например, можно настроить сеть таким образом, что доступ к сети для виртуальных машин будет отличаться от доступа к сети для управляющей операционной системы, включая использование виртуальных локальных сетей, IP-безопасность (IPSec), защиту доступа к сети (NAP).

Перед настройкой виртуальной сети необходимо определить структуру и тип виртуальной сети, которую планируется использовать. Следует иметь в виду, что Hyper-V не поддерживает беспроводные сети.

Рис. 8. Сетевые подключения.

Итак, вторая рекомендация: после настройки роли Hyper-V правильно конфигурируйте виртуальные коммутаторы. Вы можете подключать виртуальные сетевые адаптеры к нужным подсетям по средствам виртуальных сетевых коммутаторов.

Типы виртуальных сетей

Виртуальные сети можно создать на компьютере под управлением Hyper-V. Это позволит определить различные топологии сети для виртуальных машин и сервера виртуализации. Используя диспетчер виртуальной сети (доступный из диспетчера Hyper-V), можно настраивать три различных типа виртуальных сетей.

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

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

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

Пример конфигурации для среды многоуровневых Web-приложений

Рассмотрим пример инфраструктуры, которая включает в себя:

• базу данных;
• сервер приложений;
• web-сервер.

В приведенном примере (Рис. 9) сервер с установленной ролью Hyper-V имеет два физических сетевых интерфейса.

Первый сетевой интерфейс подключается к сети управления и полностью изолирован от других сетей. Он используется для управления узлом Hyper-V с рабочего места администратора.

Второй сетевой адаптер подключен к общедоступной сети (сеть отмечена на рисунке «Front-end network»). К этой же сети подключены серверы и клиенты. Виртуальная машина с веб-сервером подключена к общедоступной сети через внешнюю виртуальную сеть External. Дополнительно в данной конфигурации существует частная виртуальная сеть Private (отмечена на рисунке, как «Private Virtual Network»), посредством которой web-сервер подключен к виртуальной машине с установленной базой данных и виртуальной машиной с установленным сервером приложений.

Такая конфигурация позволяет изолировать весь трафик между web-сервером и другими виртуальными машинами от внешней сети, а также обеспечивает выделенный изолированный сетевой интерфейс для управления узлом Hyper-V.

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

Рис. 9. Пример конфигурации для среды многоуровневых web-приложений.

Конфигурация местоположения файлов виртуальных машин

Файлы, содержащие информацию о конфигурации виртуальных машин, по умолчанию располагаются в папке:

%programdata%\Microsoft\Windows\Hyper-V\

Файлы конфигурации не занимают много места; теоретически местоположение по умолчанию может быть приемлемым для любых сценариев работы узлов Hyper-V.

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

Также следует помнить, что виртуальные диски могут быть, как фиксированного размера (Fixed), так и динамически расширяться (Dynamic). Microsoft рекомендует использовать фиксированные размеры дисков виртуальных машин для большей производительности и исключения ситуации, когда место на физических носителях может неожиданно закончиться.

По умолчанию все файлы VHD храниться в папке %users %\Public\Documents\Hyper-V\. Вы можете изменить местоположение на то, которое необходимо для вашей конфигурации.

Для упрощения работы и делегирования полномочий рекомендуется создать удобную структуру папок (например, типичная структура могла бы быть следующей):

• W:\Virtualization Resources\Virtual Machines
• W:\Virtualization Resources\Virtual Hard Disks
• W:\Virtualization Resources\Virtual Floppy Disks
• W:\Virtualization Resources\ISO files

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

Таблица 1. Разрешение папки (хранилище VHD).

Имена	Разрешения	Применимо
Administrators System	Full Control	К текущей папке, подпапкам и файлам
Creator Owner	Full Control	Только к подпапкам и файлам
Interactive Service Batch	Create files/write data Create folders/append data Delete Delete subfolders and files Read attributes Read extended attributes Read permissions Write attributes Write extended attributes	К текущей папке, подпапкам и файлам

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

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

• Каталог файлов конфигурации виртуальных машин. Поумолчаниюэто
• Каталог файлов виртуальных жестких дисков виртуальных машин. Поумолчаниюэто
• КаталогфайловмоментальныхснимковПоумолчаниюэто

Дополнительно рекомендуется ознакомиться с документом Windows Server 2008 Security Guide. В данный документ входит ряд рекомендаций по установке значений безопасности для достижения оптимального уровня безопасности. Microsoft рекомендует применять базовые настройки безопасности, описанные в документе Windows Server 2008 Security Guide и Windows Server 2008 Security Compliance Management Toolkit для серверов Windows Server 2008, выполняющих роль Hyper-V.

Управление хост-сервером и администрирование виртуальных машин

Не предоставляйте администраторам виртуальных машин разрешения в управляющей операционной системе. Согласно принципу предоставления наименьших привилегий, администраторам виртуальных машин (иногда называемым администраторами отделов или делегированными администраторами) необходимо предоставлять минимально необходимые разрешения. Управление требуемыми разрешениями на всех объектах, связанных с виртуальной машиной, может быть сложным и при неверном использовании может привести к проблемам безопасности.

Безопасность хост-сервера с установленной ролью Hyper-V (контрольный список):

• Используйте сервер в режиме Server Core;
• Своевременно проверяете и устанавливайте обновления безопасности;
• Используйте выделенный сетевой адаптер для управления сервером Hyper-V. Изолируйте его от других подсетей;
• Обеспечьте безопасность для хранилищ, где размещаются файлы виртуальных машин;
• Применяйте базовые настройки для операционной системы, описанные в документе Windows Server 2008 Security Compliance Management Toolkit;
• Сконфигурируйте антивирусное программное обеспечение, исключите из сканирования в реальном времени ресурсы Hyper-V;
• Не запускайте приложения в управляющей операционной системе – все приложения должны выполняться в виртуальных машинах;
• Не предоставляйте администраторам виртуальных машин права на управление хост-сервером Hyper-V;
• Защищайте свои виртуальные машины, это повысит общий уровень безопасности системы;
• Используйте шифрование BitLocker для защиты ресурсов;
• Защищайте ресурсы хост-сервера от виртуальных машин путем выделения соответствующих пулов ресурсов для виртуальных машин;
• Разграничивайте права доступа в среде Hyper-V.

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

Рекомендуется использовать управление доступом на основе ролей, которое дает возможность задавать управление доступом в терминах организационной структуры компании, то есть путем создания нового объекта, называемого ролью. Пользователям назначаются роли для выполнения своих должностных обязанностей. Hyper-V использует политики диспетчера авторизации для управления доступом на основе ролей.

Для стандартной небольшой инфраструктуры рекомендуется разделять полномочия администраторов по следующему типу:

Администраторы Hyper-V – административные учетные записи, у которых есть полный административный доступ ко всем ресурсам Hyper-V, включая конфигурации виртуальных машин. Администраторы Hyper-V осуществляют глобальные настройки конфигурации, которые затрагивают, как саму операционную систему управления, так и все виртуальные машины на узлах Hyper-V.

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

Рекомендуется использовать учетную запись с правом администратора Hyper-V только в тех случаях, когда это необходимо.

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

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

Чтобы избежать их, существует ряд инструментов позволяющих в полной мере разграничивать права доступа между пользователями и администраторами. Примерамитакихинструментовявляется Authorization Manager и System Center Virtual Machine Manager.

Использование Authorization Manager для делегирования управления VM

Рис. 10. Делегирование управления VM.

Для разграничения прав на операции с виртуальными машинами можно использовать приложение Authorization Manager, которое входит в состав ОС Windows 2008 Server.

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

Authorization Manager позволяет размещать информацию в файле,в Active Directory или в базе данных. Поддерживает как 64-разрядные, так и 32-разрядные системы. По умолчанию Authorization Manager хранит свои данные в текстовом файле формата xml на локальном сервере.

Рассмотрим, какие компоненты существуют в Authorization Manager:

• Operation – Операция
• Task – Задача
• Role Роль
• Scope Область

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

**Task (Задача).**Операции группируются в задачи. Таким образом, получается группа операций, которые можно делегировать пользователю. В Authorization Manager уже есть сформированные задачи практически на все основные действия с виртуальными машинами; дополнительно существует возможность формировать свои задачи, если это необходимо.

Роль (Role). Определяет круг задач для учетной записи. Например, учетная запись может иметь право выполнять все операции и задачи, связанные с конфигурацией виртуальной сети. При необходимости такую роль можно создать и делегировать пользователю.

Область (Scope). Параметр, который позволяет указать какими виртуальными машинами может управлять определенная роль пользователя. По умолчанию при создании виртуальных машин они помещаются в область по умолчанию Default Scope. Если вы хотите предоставить административный доступ к определенным виртуальным машинам, вам потребуется создать область, в которую необходимо поместить эти виртуальные машины, после чего применить настройки к данной области. Это можно реализовать специальным сценарием. Пользователь, которому делегирована некая область управления, будет видеть только свои виртуальные машины и не будет видеть и иметь доступа к другим.

Если в вашей организации более трех узлов Hyper-V, рекомендуется опубликовать хранилище Authorization Manager в Active Directory.

Использование System Center Virtual Machine Manager 2008 R2

В крупной инфраструктуре для управления виртуальными машинами и делегирования прав на виртуальные машины и хост-системы рекомендуется использовать System Center Virtual Machine Manager.

Ключевое достоинство System Center Virtual Machine Manager – тесная интеграция с другими решениями Microsoft для управления инфраструктурой Windows-серверов семейства System Center. System Center Virtual Machine Manager позволяет создать гибкую виртуальную инфраструктуру на основе платформы Hyper-V и упростить развертывание виртуальных систем из центральной библиотеки шаблонов. Основные возможности System Center Virtual Machine Manager включают в себя:

• использование базы данных Operations Manager 2007, в которой собраны данные о производительности физических серверов, и определение наиболее подходящих для виртуализации серверов;
• встроенные средства миграции (ранее для этих целей использовался Virtual Server Migration Toolkit), использующие службы теневого копирования тома для преобразования физических серверов в виртуальные, без их остановки. Кроме того, System Center Virtual Machine Manager позволяет преобразовать виртуальные машины VMware в формат Hyper-V;
• возможность автоматически перемещать виртуальные серверы на физических компьютерах, используя данные об их рабочих нагрузках;
• централизацию управления ресурсами, управление гипервизорами Hyper-V, Virtual Server, VMware ESX и др. Пакет позволяет увеличить доступность виртуальных машин с точки зрения их переноса в случае проблем с оборудованием и в случае большой нагрузки на оборудование. Он позволяет управлять ресурсами хост-сервера и ресурсами виртуальных машин;
• возможность создавать группы физических серверов Hyper-V и делегировать управление ими;
• создание библиотек, которые могут быть использованы для хранения виртуальных машин, образов и шаблонов;
• предоставление портала самообслуживания, который представляет собой web-приложение для самостоятельного развертывания виртуальных машин пользователями. Администратор определяет политики самообслуживания, которые включают в себя правила создания, развертывания и использования виртуальных систем. Взаимодействие портала с управляющим сервером производится по модели сервисно-ориентированных систем WCF (Windows Communication Foundation);
• создание пользовательских ролей, делегирование разрешений для групп хост-серверов, виртуальных машин и серверов библиотек.

Серверы Hyper-V могут быть объединены в группы, организованные по некоторым логическим категориям (например, «Тестовые машины», «Веб-порталы» и т.п.) Довольно удобно организовать группы хостов в соответствии со структурой Active Directory. Естественно, System Center Virtual Machine Manager полностьюподдерживаетслужбукаталога Active Directory.

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

Обеспечение безопасности виртуальных машин

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

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

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

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

На каждой виртуальной машине рекомендуется использовать:

• межсетевой экран;
• антивирус;
• другие средства обнаружения вторжений, применимые для вашей среды;

Рекомендуется размещать серверы Hyper-V в соответствующих организационных единицах Active Directory и применять к ним групповые политики, которые настраивают базовые значения параметров безопасности.

Защита файловой системы

Для защиты файловой системы необходимо использовать стандартные средства – access control lists (ACLs) – для определения доступа к файлам виртуальных машин. Такой подход предотвратит ситуацию, когда злоумышленник попытается получить несанкционированный доступ к файлам виртуальной машины для того, чтобы скопировать их на съемный носитель или заменить их, – сценариев довольно много.

Тем не менее, использование ACLs не позволит защитить саму виртуальную машину от несанкционированного доступа.

На сервере Hyper-V каждая виртуальная машина работает в контексте безопасности процесса vmwp.exe, который выполняется от имени NETWORK SERVICE и который имеет доступ к файлам виртуальной машины. Это необходимо чтобы использовать консоль Hyper-V manager для управления виртуальными машинами coстороны пользователей, обладающих определенными правами в системе.

Шаги по обеспечению безопасности Hyper-V включают в себя как использование ACLs, так и использование инструментов управления и обеспечения безопасности, таких как System Center Virtual Machine Manager 2008 или Authorization Manager, которые применяются для разграничения прав на виртуальные машины.

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

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

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

Пример:

W:\Virtualization Resources\Project A\Virtual Machines

W:\Virtualization Resources\Project A\Virtual Hard Disks

W:\Virtualization Resources\Project A\Virtual Floppy Disks

W:\Virtualization Resources\Project A\ISO files

W:\Virtualization Resources\Project B\Virtual Machines

W:\Virtualization Resources\Project B\Virtual Hard Disks

W:\Virtualization Resources\Project B\Virtual Floppy Disks

W:\Virtualization Resources\Project B\ISO files

W:\Virtualization Resources\Project C\Virtual Machines

W:\Virtualization Resources\Project C\Virtual Hard Disks

W:\Virtualization Resources\Project C\Virtual Floppy Disks

W:\Virtualization Resources\Project C\ISO files

Шифрование файловой системы

Использование шифрования BitLocker

Применяйте шифрование диска BitLocker для защиты ресурсов Hyper-V. Шифрование диска BitLocker использует компоненты оборудования и микропрограмму сервера для обеспечения безопасной загрузки операционной системы и шифрования диска, даже если на сервер не подается электропитание. Это позволяет защитить данные, если диск будет украден и смонтирован на другой компьютер для интеллектуального анализа. Шифрование диска BitLocker также помогает защитить данные, если злоумышленник использует другую операционную систему или пытается получить несанкционированный доступ к диску.

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

Аудит событий доступа к объектам

Функции обеспечения безопасности на файловой системе могут предотвратить несанкционированный доступ к критически важным объектам виртуальных машин, например, файлов VHD. Использование аудита доступа к объектам позволит выявлять попытки несанкционированного доступа. Включите аудит доступа к объектам на сервере Hyper-V. Активируйте события на «Успех» и «Отказ». После включения данной опции будут регистрироваться все события доступа к файлам пользователями. Если по каким-либо причинам целостность файлов будет нарушена, то в журнале событий будет отражена каждая попытка пользователя получить доступ к файлам. Таким образом, вы сможете определить ответственное лицо в большинстве случаев.

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

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

Например, администратор, настроенный против компании, осуществляет несанкционированное копирование файла критически важной виртуальной машины. При этом система зарегистрирует событие в системных журналах и, таким образом, можно отследить все попытки несанкционированного доступа и нарушения регламентов безопасности, а с использованием System Center Operation Manager можно настроить уведомления сотруднику отдела безопасности.

Часто бывает, что на виртуальных машинах требуется разместить конфиденциальные данные. В таких случаях необходимо обеспечить более высокий уровень защиты виртуальной машины. Одним из преимуществ виртуальных машин является возможность быстрого перевода виртуальных машин в автономный режим и возврата к работе с помощью функции приостановки работы (suspend) Hyper-V. Корневой сервер сертификатов, например, содержит данные такой важности, что, вероятно, вы захотите, чтобы доступ к нему был возможен только в моменты выполнения определенных операций.

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

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

Обслуживание виртуальных машин

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

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

Для автоматизации процесса используйте Offline Virtual Machine Servicing Tool – это типичный Solution Accelerator, позволяющий автоматизировать данный процесс.

Offline Virtual Machine Servicing Tool работаетсовместнос SCVMM 2008 исистемойобновленияОС – System Center Configuration Manager (SCCM) 2007 R2 или Windows Server Update Services (WSUS) 3.0.

Для выполнения своих задач Offline Virtual Machine Servicing Tool использует задачи на обслуживание (service jobs), получая от SCVMM список виртуальных машин и задавая команды PowerShell для работы с ВМ.

Для каждой виртуальной машины выполняются три шага:

• виртуальная машина включается (активируется на сервере, имеющем достаточно свободных ресурсов – даже если она всего лишь лежала в библиотеке);
• принудительно запускается цикл обновления (SCCM 2007 или WSUS 3.0);
• виртуальная машина выключается (и при необходимости возвращается назад в библиотеку).

Для планирования расписания выполнения таких процессов используется стандартный планировщик задач (инструмент Scheduled Tasks).

Контрольный список безопасности VM

Контрольный список для виртуальных машин:

• Используйте диски фиксированного размера для виртуальных машин;
• Сохраняйте файлы виртуальных машин и образы на защищенном хранилище данных;
• Определяйте сколько ресурсов необходимо для виртуальной машины;
• Разделяйте подсети виртуальных машин, конфигурируйте сетевые адаптеры виртуальной машины таким образом, чтобы каждый адаптер находился в требуемой подсети;
• Добавляйте только необходимые устройства для работы виртуальной машины;
• Применяйте базовые настройки для операционной системы виртуальной машины, описанные Windows Server 2008 Security Compliance Management Toolkit;

Перед использованием виртуальных машин убедитесь, что установлены все обновления безопасности и инструменты Hyper-V Integration Services.

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

Планирование безопасности Hyper-V: https://technet.microsoft.com/ru-ru/library/dd283088 (WS.10).aspx

Портал Microsoft Virtualization: http://www.hyper-v.ru/On.aspx

Блог Russian Windows Virtualization Discussion: https://blogs.technet.com/vm/default.aspx

Блог Андрея Бешкова: https://blogs.technet.com/abeshkov/

Более детальную информацию можно получить из следующих источников:

Windows Server 2008 Security Compliance Management Toolkit: https://technet.microsoft.com/en-us/library/cc514539.aspx

Hyper-V Security Guide: https://technet.microsoft.com/en-us/library/dd569113.aspx