Главная Security, Virtualization, Новое Hyper-V Security или безопасность Hyper-V
  • Hyper-V Security или безопасность Hyper-V

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

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

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

     

     

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

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

    Image 1

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

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

    В качестве примера таких систем можно привести:

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

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

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

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

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

    Например:

    • – Сетевой адаптер
    • – Жесткий диск
    • – Клавиатура
    • – Мышь
    • – Видео подсистема и т.д.

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

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

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

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

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

    Image2

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

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

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

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

    В разных решениях виртуализации существуют разные подходы в реализации архитектуры построения Гипервизоров, существуют два основных подхода в реализации гипервизоров  «Монолитный» и «Микроядерный».

    • В частности в VMware ESX реализован принцип «монолитного» Гипервизора.
    • Microsoft Hyper-V реализована архитектура «микроядерного» гипервизора.

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

    clip_image006[4]

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

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

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

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

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

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

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

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

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

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

    clip_image008[4]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    clip_image010 

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

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

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

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

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

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

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

    Виртуальные Устройства также поддерживают технологию Windows Server Virtualization, называемую Прогрессивный Ввод/Вывод (англ. 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, чем прочие операционные системы, которым требуется более медленная эмуляция устройств.

    clip_image012

    Рисунок 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. Используется для изоляции процесса работы одной виртуальной машины от другой. Полностью изолируется возможность доступа к файлам, дискам ,памяти одной виртуальной машину к другой

    clip_image014

    Рисунок 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:

    An x64-based processor. Сервер 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-разрядных версий ОС.

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

    Hardware-enforced Data Execution Prevention (DEP) must be available and enabled. В частности, необходимо задействовать разряд Intel XD (разряд отключения исполнения) или разряд AMD NX (разряд запрета исполнения)

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

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

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

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

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

    clip_image015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    clip_image016

    Рисунок 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). 

    Names Permissions Apply to
    Administrators

    System

    Full Control This folder, subfolders, and files
    Creator Owner Full Control Subfolders and files only
    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

    This folder, subfolders, and files

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

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

    Каталог файлов конфигурации виртуальных машин. По умолчанию это: C:\ProgramData\Microsoft\Windows\Hyper-V.

    Каталог файлов виртуальных жестких дисков виртуальных машин. По умолчанию это: C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.

    Каталог файлов моментальных снимков. По умолчанию это: %systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots.
    Дополнительно рекомендуется ознакомиться с документом 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;
    • Сконфигурируйте антивирусное программное обеспечение, исключите и real-time сканирования ресурсы 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

    clip_image018

    Рисунок 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 включают в себя:

    System Center Virtual Machine Manager позволяет использовать базу данных Operations Manager 2007, в которой собраны данные о производительности физических серверов, и определить наиболее подходящие для виртуализации серверы.

    System Center Virtual Machine Manager имеет встроенные средства миграции (ранее для этих целей использовался Virtual Server Migration Toolkit), использующие службы теневого копирования тома для преобразования физических серверов в виртуальных, без их остановки. Кроме того, System Center Virtual Machine Manager позволяет преобразовать виртуальные машины VMware в формат Hyper-V.

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

    System Center Virtual Machine Manager позволяет централизовать управление вашими ресурсами, управление гипервизорами Hyper-V, Virtual Server, VMware ESX и др. Позволяет увеличить доступность виртуальных машин, с точки зрения переноса виртуальных машин, в случае проблем с оборудованием, в случае большой нагрузки на оборудовании, путем перемещения виртуальной машины на другой узел. Позволяет управлять ресурсами хост сервера и ресурсами виртуальных машин.

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

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

    System Center Virtual Machine Manager предоставляет портал самообслуживания, который представляет собой Web-приложение для самостоятельного развертывания виртуальных машин пользователями. Администратор определяет политики самообслуживания, которые включают в себя правила создания, развертывания и использования виртуальных систем. Взаимодействие портала с управляющим сервером производится по модели сервисно-ориентированных систем WCF (Windows Communication Foundation).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Шаги по обеспечению безопасности Hyper-V включают в себя как использование access control lists (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
    http://technet.microsoft.com/ru-ru/library/dd283088(WS.10).aspx

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

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

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

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

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

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

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

Комментарии

  1. Специалисты по виртуализации стукните плз в аську 403240790 есть несколько вопросов

  2. Хорошая, годная статья. Автору респект.

  3. Полезная статья, завтра на свежую голову прочту.

  4. “VM editions” – наверно VM additions.

  5. test, подозреваю это специальная метка по определению внимательных читателей))))

  6. Денис, а про MIIS можете написать статейку?
    Как скрестить AD и NDS -у Вас ведь есть такой опыт?
    Такой инфы в инете нет?

  7. Да, опыт есть. На данный момент пишу 2 статьи по MIIS одна из которых, как раз описывет вариант скрещивания AD и Novell.

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

    Вы пытаетесь подменять понятия, главная особенность монолитных гипервизоров (VMware) в том что все драйвера исключительно от самого производителя гипервизора и его саппорт за них отвечает. Отсюда и HCL. Все для того чтобы в продуктивной enterprise среде, не получить странные глюки например при попытке использования агрегированных сетевых каналов, или просто под высокой нагрузкой, что в Hyper-V сплошь и рядом из-за драйверов не рассчитанных на такое использование. А цена таких неприятностей в enterprise среде крайне высока. Так что описанное в цитате как раз справедливо в первую очередь для Hyper-V.

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

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

  11. Eстественно каждый выбирает для себя сам. 🙂 Однако если ставить непроверенные драйверы тут далеко не уедешь. К стати на сервере, установленном в режиме Server Core можно использовать только те драйвера и приложения, которые прошли проверку на совместимость. 🙂

  12. > на сервере, установленном в режиме Server Core можно использовать только те драйвера и приложения, которые прошли проверку на совместимость

    А не просто подписанные доверенным сертификатом? Дайте ссылку на источник, пожалуйста 🙂

  13. Николай, все верно я как раз это и имел ввиду, после применения всех рекомендованных процедур описанных в Best Practices по hyper-V, нет возможности поставить не подписанные драйверы, если конечно вы явно это не разрешите. Другой механизм мне пока неизвестен 🙂

  14. Я не пытаюсь спорить о крутости тех или иных систем, давно я из этого вырос. Просто люблю объективность.
    Много ли вендоров тестируют драйвера под Hyper-V?
    В режиме высокой нагрузки на десятках виртуальных машин?
    В различных режимах (к примеру network team)?
    На различном базовом железе?
    Очень сомневаюсь, не нашел ничего подобного. Если есть, покажите плиз.
    А вот насчет монолитных гипервизоров, это именно так. И если платформа попадает в список совместимых, это значит что служба поддержки готова решать проблемы и не отошлет вас к вендору за драйверами и не скажет что нибудь вроде “Этот режим не поддерживается.”.
    Для enterprise это очень актуально, т.к. виртуализация поднимается на могучем железе и на одном хосте работают десятки виртуальных машин.
    А про “качество” драйверов некоторых вендоров железа давно легенды ходят, и это относится как к стабильности, так и к производительности.
    Это на десктопе можно с драйверами играться, enterprise админы – консервативны и недоверчивы, от подобных развлечений звереют знаете ли 🙂

  15. Сергей, я с вами в чем-то согласен. Технология Hyper-V относительно молода. Но есть один нюанс это “Windows 2008” это продукт, существует большое кол-во времени плюс опыт накопленный годами начиная с Win2k даром не проходит. Если посмотреть подробнее архитектуру Hyper-V то можно увидеть, что драйверы ставятся не в гипервизор, а именно в ОС Windows 2008 в родительском разделе. То есть, когда вы говорите о тестировании и надежности драйверов под Hyper-V это автоматически подразумевается тестирование и надежность драйверов под Windows 2008 в этом и суть архитектуры. Все драйверы ставятся в управляющей ОС Windows 2008, а уж под эту платформу уже столько натестировано не счесть (как хорошего так и плохого) и она (ОС) настолько широко используется в Энтерпрайз сегменте, что некоторым продуктам до половины сегмента рынка ь (Windows) еще расти и расти. Повторюсь на мой взгляд вся прелесть в том, что драйвер можно заменить в любой момент времени. 🙂

  16. Отвечу просто свежей ссылкой http://communities.intel.com/thread/6362

    Цитата:”Повторюсь на мой взгляд вся прелесть в том, что драйвер можно заменить в любой момент времени.”
    Если следовать такой логике “Вся прелесть например Linux, в том что в случае проблемы исходный код драйвера можно быстренько подправить самому и быстренько пересобрать ядро системы” 🙂

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

    Я абсолютно нейтрально отношусь к вендорам виртуализации, все зависит от конкретной ситуации и от квалификации персонала.

  17. Вы привели правильную ссылку! – из ссылки следует, что в итоге у человека проблема с адаптером решилась как ?

    Thanks for your effort, Kamal.
    I could solve the problem this weekend by installing the latest intel LAN Drivers (v 14.4). Thanks to everybody in here!

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

  18. “duke nukem must die”

  19. я понял! Hyper-V Ru1eZ 4ever
    🙂

  20. Правильно бы было так – %duke nukem% must die
    Это переменная )))

  21. Сергей. Вот вы тут пишите о непогрешимости VMWare и о том как они хорошо драйвера тестируют.

    А как вам недавний случай о том как обновление от VMWare повалило кучу серверов у клиентов и они не работали 2 дня?

    Это вам ни о чем не говорит? Особенно если учесть что это не первый случай удачных обновлений от производителя монолитного гипервизора. Так же недавно был случай был когда после апдейта переставал работать VMotion.

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

    Все делают ошибки и непогрешимые программисты тоже.

    Поэтому мне кажется что за микроядерным гипервизором будущее т.к он надежнее и безопаснее.

  22. Ну прям гениальные рассуждения по поводу ошибок, а вспомните к примеру сколько у майкрософта глюков критических в софте было (а сколько еще будет то!), vmware рядом с эдаким гигантом ошибок кажется совсем маленьким ягненком, а почему бы вам не сделать сравнение с citrix xen? По моему вполне было бы разумно такое написать, что говорить, если к примеру за основу виртуализации выбрал citrix xen.

  23. чуть чуть поправлюсь, не дописал))
    SAP использует XEN

  24. >а вспомните к примеру сколько у майкрософта глюков критических в софте было (а сколько еще будет то!),
    Вы мне такими фразами пользователей напоминаете:
    -ААААА!!!! У меня не работает!!!!!!
    -Что конкретно не работает?
    -АААА!!!!У меня все не работает!!!!

    можно список глюков критических от MS, которые были и которые будут?

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

  26. А вы батенька хам.

    Для начла используем гугл
    http://www.google.ru/search?hl=ru&newwindow=1&q=список+критических+уязвимостей+microsoft&btnG=Поиск&lr=&aq=f&oq=
    А потом уже постим по теме, софт от мелкасофта потому в критических областях в принципе не используется , что не надежен. С этим вряд ли кто то будет спорить. Вот к примеру сам использую XEN от Citrix, проблем никаких не знаю, после данной статьи появилось стойкое ощущение, что автор специально выгораживал Hyper-v, вот если проводить спец анализ рынка виртуализации то тут Hyper-v окажется не лучшем свете.

  27. И пожалуйста не надо быть такими твердолобыми, Win* истсемы никогда думаю не будут надежнее *nix систем, на серверных платформах.

  28. Чингиз, не провоцируйте на holywar.

    Ответьте для начала на вопрос:

    1. Сколько продуктов у VMWare, Citrix, Microsoft?
    2. Почему вы сравниваете колличественно, при этом показателем является кол-во найденных ссылок в Интернете?
    3. Сравните булыжник и ноутбук, что надежней? Не хотите вместо ноутбука положить в сумку булыжник? Почему?

  29. >Для начла используем гугл
    Простите, а как количество уязвимостей системы (пропатченных между прочим), коррелирует с вашей фразой о “глюках критических в софте”.

    >И пожалуйста не надо быть такими твердолобыми,
    Спешу вас растроить, твердолобым пока пытаетесь быть вы. Профессионалы используют тот инструмент, который им больше подходит по условиям задачи. И только люди с красными глазами, говорят о том что “Win* истсемы никогда думаю не будут надежнее *nix систем, на серверных платформах”

  30. Чингиз, Вы совершенно правы. Мелкомягким никогда не догнать *nix, и это хорошо.

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

  31. для Ильи
    1. Я сравниваю качество кода, увы у микрософта оно во большинстве продуктов не блещет, хотя бывают редкие приятные исключения
    2. А как вы думаете престиж компании не портит то что одни патчи могут и исправлять и калечить системы, особенно десктопные, надеюсь вы с этим не будуете спроить?
    3. Для меня некорректно поставлен вопрос

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

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

    ЛЮДИ ХОЛИВАР Я НЕ ХОЧУ РАЗВОДИТЬ И НЕ БУДУ, Я СТАРАЮСЬ ОТТАЛКИВАТЬСЯ ОТ СВОИХ ЗНАНИЙ И УМЕНИЙ, ТАК ЧТО СИЛЬНО НЕ РУГАЙТЕ ))

  32. Знаете, а меня повеселила данная статья http://inf.by/linux/7/ , ведь не все сидели с самого начала на винде, вот незадача, а человеку то неудобен оказался

  33. Статья очень показательна. Человек не читает документацию: “Читать документацию и создавать файл unattended? а что это собственно такое?”
    а потом удивляется что у него что-то работает не так, как он ожидал.

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

  34. >1. Я сравниваю качество кода, увы у микрософта оно во большинстве продуктов не блещет, хотя бывают редкие приятные исключения
    Вы работаете в органах госбезопасности? Насколько мне известно, только им MS предоставляет образцы исходного кода, и то частично. Или вы возможно являетесь одним из разработчиков данного кода?

    >то что одни патчи могут и исправлять и калечить системы, особенно десктопные, надеюсь вы с этим не будуете спроить
    не буду спорить, если вы будете оперировать фактами.ДА, я таки прошу пруф 🙂

    >Личный опыт на многих предприятиях говорит о не лучшей стабильности продуктов данной компании
    Личный опыт всегда субъективен. Знаю многих людей, которым легче заявить начальству: “Этажевинда!!! Чтовыхотите!?!”, чем прочитать наконец документацию.

    >А тут как раз вы то и ошибаетесь, опыт опять же мой говорит, о том, что во многих областях лучше воспользоваться ник системами чем вин
    Ну давайте, наконец оперировать фактами, а не фразами “Всем известно!!!”. Вы области применения, где по вашему мнению nix системы лучше чем Win привести можете?

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

    >ЛЮДИ ХОЛИВАР Я НЕ ХОЧУ РАЗВОДИТЬ И НЕ БУДУ
    Ну так не разводите 🙂 Аргументируйте нормально свою точку зрения, а не оперируйте фразами: всем известно, все знают, вася пожил, вася знает

  35. >Или вы возможно являетесь одним из разработчиков данного кода?

    Я так и знал, что нас читают в Силиконовой долине)

  36. Сегодня посмотрел Ваш доклад на течдеи. Нормик =)) но, как то длиновато =))) зато читать не пришлось =)

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