Средства безопасности Hyper-V в системе Windows Server 2008

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

Корпорация Microsoft выпускает два продукта, обеспечивающие виртуализацию серверов. Первый из них — это Microsoft Virtual Server, бесплатно распространяемый программный пакет, с помощью которого можно запускать виртуальные серверы поверх систем Windows Server 2003, Windows XP и Windows Vista. Второй продукт, новейшее средство виртуализации, разработанное специалистами Microsoft, — это система Hyper-V, интегральная часть Windows Server 2008. Подобно Microsoft Virtual Server, Hyper-V обеспечивает виртуализацию операционных систем, как входящих, так и не входящих в семейство Windows.

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

Механизмы защиты в Hyper-V

В процессе загрузки системы Hyper-V создается тонкий программный компонент (менее 1 Мбайт), который называется гипер­ви­зором. Он функционирует между аппаратными компонентами физического сервера и «базовой» операционной системой. Гипервизор напрямую взаимодействует с аппаратными компонентами сервера и загружается до запуска базовой операционной системы. Его еще можно определить как мини-операционную систему, обеспечивающую виртуализацию других операционных систем. Все операционные системы, запускаемые на сервере Hyper-V (как виртуальные, так и базовая) всегда функционируют внутри виртуальной машины (VM) под присмотром гипервизора. В Virtual Server реализован другой подход: «базовая» операционная система выполняется за пределами слоя виртуализации и тоже напрямую взаимодействует с аппаратными компонентами.

Чтобы можно было использовать виртуализацию на основе гипервизора, процессор системы должен поддерживать технологию, именуемую аппаратной поддержкой виртуализации. Эта возможность, как правило, обеспечивается современными семействами процессоров Intel и AMD, и называется она Intel VT и AMD-V соответственно. В архитектуре ядра процессоров, обеспечивающих аппаратную поддержку виртуализации, преду­смотрен наделенный широкими привилегиями слой, обеспечивающий среду выполнения гипервизора, полностью изолированную от остальных компонентов системы.
Гипервизор выполняет важнейшие задачи, такие как управление памятью, и обеспечивает защитную изоляцию базовой операционной системы от виртуальных. В соответствии с терминологией Hyper-V среда, в которой выполняется базовая операционная система или виртуальная операционная система, именуется разделом. Раздел можно также определить, как основную единицу изоляции. Раздел, где выполняется базовая операционная система, называется родительским, тогда как разделы, в которых выполняются виртуальные операционные системы, именуются дочерними разделами.

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

Родительский раздел должен функционировать под управлением 64‑разрядной системы Server 2008. Решение Microsoft использовать в родительском разделе 64‑разрядную систему продиктовано главным образом тем, что в этой системе доступны расширенная память и средства обработки. Дело в том, что расширенная память позволяет размещать на одной платформе большее число виртуальных машин. Но 64‑разрядная Windows дает преимущества и в сфере безопасности: устаревший код в этой системе не используется, и она строится от начала до конца с использованием методики SDL (Microsoft Security Development Lifecycle). Специалисты Microsoft создали SDL для того, чтобы иметь возможность писать более защищенные программы, а также сделать процесс разработки программного обеспечения более предсказуемым. Методика SDL предназначена для того, чтобы превратить искусство разработки программных средств в науку. Более подробные сведения о SDL можно найти на сайте Microsoft Security Development Lifecycle (http://www.microsoft.com/security/sdl/default.aspx).

Учитывая важную роль гипервизора в контексте изоляции раздела и стремясь еще больше ограничить площадь атаки на гипервизор, разработчики Microsoft сокращают объем кода и количество служб, выполняемых внутри гипервизора. Гипервизор не включает в себя ни стеки ввода/вывода, ни драйверы устройств. Дочерние разделы взаимодействуют с физическими аппаратными компонентами через драйверы устройств, выполняемые в родительском разделе. Такой подход к взаимодействию с драйверами устройств именуется архитектурой гипервизора с микроядром. Но хотя данная архитектура снижает угрозу безопасности для гипервизора, она создает дополнительные угрозы для родительского раздела. Так, опасность для родительского раздела могут представлять вышедшие из строя или модифицированные злоумышленниками драйверы устройств. В разделе «Защита родительского раздела» я высказываю свои соображения относительно того, как нужно укреплять раздел Hyper-V.

Аппаратные средства безопасности

В Hyper-V могут использоваться современные, базирующиеся на аппаратных компонентах средства безопасности, такие как Data Execution Prevention (DEP) и Address Space Layout Randomization (ASLR).

DEP — это метод предотвращения переполнения буфера, блокирующий внедрение вредоносного исполнимого кода в буферы данных системной памяти. Для использования Hyper-V требуются средства принудительного применения DEP на основе аппаратных средств, иначе говоря, необходим процессор, поддерживающий функцию No Execute (NX по терминологии AMD) или функцию eXecute Disable (XD по терминологии Intel).

ASLR — это средство защиты от вредоносного программного обеспечения, размещающее важнейшие файлы в случайном порядке на этапе между перезагрузками системы. Таким образом оно парализует вредоносные программы (червей и троянцев), которые атакуют одни и те же адреса памяти на разных системах. Дополнительную информацию о средствах DEP и ASLR можно найти в статье «Борьба с 'вредителями' в Vista и Windows Server 2008», опубликованной в Windows IT Pro/RE № 7 за 2008 год.

Ранее я уже упоминал три характеристики оборудования, прямо или косвенно используемые системой Hyper-V для организации защиты, — это аппаратная поддержка виртуализации, реализованный на базе аппаратных компонентов метод DEP для предотвращения переполнения буфера и поддержка 64‑разрядной обработки. Дабы удостовериться в том, что ваша система удовлетворяет этим требованиям Hyper-V, можете воспользоваться бесплатным инструментальным средством SecurAble (http://www.grc.com/securable.htm). Или же, если в системе установлен процессор AMD-V, воспользуйтесь утилитой AMD-V Hyper-V Compatibility Check (http://www.amd.com/us-en/assets/content_type/utilities/AMD-V_Hyper-V_Compatibility_Check_Utility.zip). На экране 1 представлен интерфейс инструментального средства SecurAble, а на экране 2 — средства AMD.

Разработчики SecurAble обращаются к пользователям с важным предупреждением: «Успешные результаты трех выполненных на той или иной оснащенной процессором AMD машине тестов SecurAble (поддержка 64‑разрядной обработки, аппаратные средства DEP и поддержка аппаратной виртуализации) не всегда дают гарантию того, что на этой системе можно устанавливать и выполнять модуль Hyper-V». Утилита не проверяет систему на наличие определенных наборов микросхем AMD и конкретной версии BIOS, необходимых для выполнения Hyper-V. Когда ваш компьютер оснащен процессором AMD, из соображений безопасности рекомендуется запустить утилиту AMD. Я запускал обе программы на компьютере с процессором AMD Turion, и результаты их выполнения представлены на экранах 1 и 2. Обратите внимание на то, что хотя мой процессор прошел испытания SecurAble, программа AMD сообщает, что он несовместим с Hyper-V.

Еще одна интересная ситуация может возникнуть при запуске утилиты SecurAble в системе, на которой выполняется программа Hyper-V. Утилита может сообщить вам, что процессор не поддерживает технологию аппаратной виртуализации — и это несмотря на тот факт, что, по данным той же программы, ваш процессор поддерживал аппаратную виртуализацию до того, как вы установили Hyper-V. В данном случае с утилитой SecurAble все в порядке; пример просто иллюстрирует один из аспектов архитектуры гипервизора Hyper-V. Во время запуска гипервизор скрывает некоторые возможности процессора на разделах, выполняемых в базовой системе (включая родительский раздел). Это делается для того, чтобы ни один из программных компонентов родительской или гостевой операционной системы не пытался воспользоваться возможностями процессора (например, аппаратной виртуализацией), находящимися под контролем гипервизора.

После запуска этих инструментальных средств, для того чтобы запустить Hyper-V, вам следует прежде всего установить 64‑разрядную операционную систему Server 2008. Затем нужно установить части Hyper-V (их можно загрузить с сайта Microsoft, http://www.microsoft.com/hyper-v-server/en/us/default.aspx). Наконец, добавьте поддержку Hyper-V, для чего требуется активировать серверную роль Hyper-V, и перезагрузите систему.

Защита родительского раздела

В разделе статьи, посвященном механизмам защиты, которые реализованы в архитектуре Hyper-V, я упоминал о важной роли родительского раздела, в котором на сервере Hyper-V выполняется 64‑разрядная базовая операционная система Server 2008. Теперь же я разъясню, как можно сократить площадь атаки родительского раздела, чтобы обеспечить более эффективную глубоко эшелонированную оборону сервера виртуализации Hyper-V и размещенных на нем виртуальных машин. Для защиты родительского раздела вы можете воспользоваться параметром установки Server Core Server 2008, а также средствами Server 2008 Authorization Manager (AzMan) и BitLocker Drive Encryption (BDE).

Еще один способ защиты родительского раздела Hyper-V состоит в том, чтобы при создании сервера виртуализации использовать автономную программу Hyper-V Server 2008 и не устанавливать Hyper-V поверх системы Server 2008 Standard, Enterprise или Datacenter Edition. Hyper-V Server 2008 представляет собой нестандартную, не требующую больших объемов памяти и не оснащенную графическим интерфейсом платформу виртуализации, но в этом продукте не реализованы интересные функциональные возможности, такие как средства для создания отказоустойчивых кластеров Windows Failover Clustering (WFC) — компоненты режима высокой доступности, о котором речь пойдет ниже.

Server Core — вариант установки сервера Server 2008, обеспечивающий минимальную среду для выполнения определенных серверных ролей, таких как контроллер домена (DC), файловый сервер, а также роль Hyper-V. Server Core существенно сокращает требования к обслуживанию, уменьшает площадь атаки сервера Windows и является одним из лучших с точки зрения обеспечения безопасности методов установки сервера Hyper-V. Более подробную информацию о том, как устанавливать Hyper-V в системе Server Core, можно найти в статье Microsoft «Hyper-V Planning and Deployment Guide» (http://www.microsoft.com/downloads/details.aspx? FamilyID=5DA4058E-72CC-4B8D-BBB1-5E16A136EF42&displaylang=en).

Система Server Core не включает традиционный интерфейс Windows, и, чтобы настроить ее локально, придется выполнять все операции из командной строки. Но вы также можете управлять сервером Server Core дистанционно через подключение к службам терминалов, через консоль Microsoft Management Console (MMC) или с помощью инструментов командной строки, обеспечивающих взаимодействие в дистанционном режиме. Возможность дистанционного управления сервером Hyper-V с системы Server 2008 или Vista SP1 обеспечивается с помощью оснастки Hyper-V Manager MMC, включенной в пакеты программных обновлений, которые описаны в перечисленных ниже статьях Microsoft. Для системы Server 2008 см. статью Microsoft «Description of the update for the release version of the Hyper-V technology for Windows Server 2008» (http://support.microsoft.com/kb/950050), а для Vista SP1 — статью «Description of the Windows Vista Management Tools update for the release version of Hyper-V» (http://support.microsoft.com/kb/952627).

Чтобы соблюсти принцип предоставления минимальных прав и обеспечить такое положение, когда администраторы виртуальных машин могут управлять только своими виртуальными машинами и не имеют возможности вносить изменения в родительский раздел, следует ограничить разрешения, предоставляемые администраторам виртуальных машин. На сервере Hyper-V можно использовать функцию Authorization Manager (AzMan), которая позволяет задавать администраторам виртуальных машин конкретные роли и обеспечивает предоставление им лишь таких прав, которые применимы исключительно к их виртуальным машинам. Microsoft реализовала AzMan в системе Server 2003, с тем чтобы разработчики и администраторы могли с легкостью добавлять к своим приложениям правила управления доступом на основе ролей. К сожалению, лишь немногие администраторы Windows используют AzMan или знают, как настраивается это средство.

Превосходное описание процедуры настройки AzMan для делегирования разрешений на сервере Hyper-V опубликовано в блоге по адресу http://dungkhoang.spaces.live.com/. На экране 3 показано, как настраиваются правила AzMan для Hyper-V из оснастки Authorization Manager консоли MMC. В этой связи стоит упомянуть такой продукт Microsoft, как System Center Virtual Machine Manager (VMM), разработанное специалистами Microsoft средство управления предприятиями, предназначенное для управления серверами виртуализации и их виртуальными машинами. VMM понижает уровень сложности при настройке и применении правил авторизации AzMan, поскольку решение этих задач программа берет на себя. Более подробные сведения о VMM можно найти на сайте Microsoft System Center Virtual Machine Manager 2008 R2 (http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/default.aspx).

BitLocker Drive Encryption

BitLocker Drive Encryption (BDE) — это средство шифрования на уровне томов, которое Microsoft включает в комплект поставки Server 2008 и Vista. BDE обеспечивает защиту данных в автономном режиме; это значит, что данные находятся в зашифрованном состоянии даже в то время, когда компьютер Windows не подключен к источнику питания или не функционирует. Кроме того, BDE предусматривает обязательную процедуру многофакторной аутентификации во время загрузки защищаемой системы. Таким образом блокируются попытки злоумышленников обойти защитный механизм BDE путем загрузки компьютера с другой операционной системой или с помощью хакерских инструментов. BDE на системах Hyper-V можно использовать для обеспечения доступа к томам, которые содержат файлы, относящиеся к виртуальным машинам, — скажем, виртуальные жесткие диски и файлы конфигурации. Более подробные сведения о поддержке BDE системой Hyper-V можно найти в руководстве Microsoft «Windows Server 2008 Hyper-V and BitLocker Drive Encryption» (http://download.microsoft.com/download/4/1/d/41d3cbff-6a2d-457e-a6ab-0e1607629c16/Windows_Server_2008_Hyper-V_and_BitLocker_Drive_Encryption_(2008-05-27).docx).

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

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

Не забывайте регулярно устанавливать на виртуальных системах новейшие версии программного обеспечения, обновления для системы безопасности и модули коррекции. Для виртуальных машин это так же важно, как и для любой другой системы Windows. Как и при работе с физическими серверами, вы можете использовать стандартные средства автоматического обновления Microsoft, такие как Windows Update, Windows Server Update Services (WSUS) или System Center Configuration Manager (SCCM).

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

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

Наряду с этим корпорация Microsoft выпускает специальное инструментальное средство Offline Virtual Machine Servicing Tool, предназначенное для того, чтобы помочь клиентам должным образом обновлять образы виртуальных машин. Это средство управляет потоком работ по обновлению большого числа не подключенных к сети виртуальных машин. Offline Virtual Machine Servicing Tool взаимодействует с диспетчером VMM и с разработанными Microsoft системами управления обновлением программного обеспечения уровня предприятия WSUS и SCCM. Более подробные сведения об установке хостов обслуживания можно найти в статье на сайте TechNet «Planning for Hosts» (http://technet.microsoft.com/en-us/library/bb963750.aspx). Загрузить утилиту Offline Virtual Machine Servicing Tool можно на сайте Microsoft (http://technet.microsoft.com/en-us/library/cc501231.aspx).

Обеспечение высокого уровня доступности

Обновление виртуальных машин — дело важное, но не менее существенно обеспечивать высокий коэффициент доступности серверов виртуализации и их виртуальных машин. Как правило, задача обеспечения высокого уровня доступности решается с помощью кластеров. В системе Server 2008 разработчики Microsoft реализовали важные изменения, касающиеся средств отказоустойчивости кластеров на базе Windows (Windows-based failover cluster, WFC). В число этих нововведений входят меры по упрощению процедур установки и настройки кластеров, а также усовершенствования в области надежности, стабильности, масштабируемости, сетевых технологий и безопасности. Наряду с этим в системе Server 2008 специалисты Microsoft упростили методы применения WFC для организации в кластеры серверов Hyper-V.

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

С помощью Server 2008 WFC можно, к примеру, создать двухуз­ловой кластер для родительского раздела Hyper-V и настроить виртуальные машины как ресурсы кластера. В этом случае, если один из узлов кластера выйдет из строя, виртуальные машины переключатся на другой узел. Более подробные сведения о настройке кластеризированного сервера Hyper-V можно найти в подготовленной специалистами TechNet статье «Hyper-V: Using Hyper-V and Failover Clustering» (http://technet.microsoft.com/en-us/library/cc732181%28WS.10%29.aspx).

Кроме того, с помощью WFC можно выполнять задания по эксплуатации и обслуживанию родительского раздела сервера Hyper-V (базовой операционной системы) с минимальным воздействием на рабочую среду. Если вы хотите, к примеру, применить последние обновления для системы безопасности к активному узлу кластера Hyper-V, то можете вручную переключить кластер на использование пассивного узла. Специалисты Microsoft называют этот процесс «быстрым переносом Hyper-V», Hyper-V Quick Migration. Более подробные сведения о быстрой миграции приведены в руководстве Microsoft по Hyper-V (http://download.microsoft.com/download/3/B/5/3B51A025-7522-4686‑AA16-8AE2E536034D/Quick%20Migration%20with%20Hyper-V.doc).

Но, хотя быстрый перенос в WFC представляется удачным решением с точки зрения обеспечения высокой доступности, он не равнозначен динамической миграции функционирующей системы, реализованной в Server 2008 R2. Динамическую миграцию можно осуществлять и с помощью других средств виртуализации, таких как VMotion корпорации VMware или XenMotion от компании XenServer.

Реальная защита виртуальности 

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

Изложенные мною меры не составляют исчерпывающего списка способов обеспечения безопасности, которым должны руководствоваться администраторы серверов виртуализации. Так, я не писал о том, что при обслуживании виртуальной машины выполнение антивирусных программ и программ для борьбы со шпионским программным обеспечением, а также своевременное обновление этих программ столь же важны, как при работе с физической системой. Microsoft планирует включить такой исчерпывающий список в следующий выпуск руководства Windows Server 2008 Security Guide. Уверен, что, следуя приведенным в статье рекомендациям и обратившись к ресурсам по ссылкам, вы сможете организовать более эффективную защиту своих инфраструктур виртуализации Hyper-V.

Жан де Клерк (jan.declercq@compaq.com) — консультант корпорации Compaq, специалист по проблемам безопасности продуктов семейства Microsoft BackOffice