Изменения в AD Windows Server 2012. Часть 1. Динамический контроль доступа

Динамический контроль доступа: все дело в заявках

Динамический контроль доступа представляет собой наиболее фундаментальное изменение в плане безопасности, которое включено в Server 2012. Динамический контроль доступа интегрирует в себе модель контроля доступа на основе заявок (claims-based access control — CBAC) с моделью ОС Windows и AD. Заявки (claims) представляют собой своеобразные утверждения о пользователях или устройствах (например, “Имя моей учетной записи JanDC”, “Я состою в отделе продаж” и т.д.), которые выпускаются доверенными источниками (trusted authority). Microsoft впервые представила CBAC в Active Directory Federation Services v 1.0 (ADFS v1) в Windows Server 2003.

Заявки могут представить гибкий механизм для обмена доверенными идентификационными атрибутами между ADFS серверами. Организации теперь могут использовать заявки для защиты данных в файле и папке, хранящихся на доменных (domain-joined) машинах под Windows Server 2012 или Windows 8. Контроллеры домена в Server 2012 могут выпускать заявки (claim statements) в ходе аутентификации пользователя или машины; осуществляется это путем включения заявки в аутентификационный билет (authentication ticket) пользователя или машины. (Более подробная информация о заявках и том, как Microsoft использует их, находится на MSDN A Guide to Claims-based Identity and Access Control.)

Динамический контроль доступа основан на нескольких новых и усовершенствованных функциях авторизации данных в Windows, которые предназначены для:

• Классификации и тегирования данных
• Применения настроек контроля доступа на основе заявок (CBAC)
• Аудита доступа к данным
• Шифрования данных.

С точки зрения разработчиков в динамический контроль доступа были внесены многочисленные изменения в ключевые компоненты, службы и протоколы Windows. Они касаются AD, объектов групповых политик, DNS, Kerberos, Local Security Authority (LSA) и Netlogon процессов, равно как и такие сетевых протоколов как Server Message Block (SMB), LDAP и удаленный вызов процедур (remote procedure call – RPC). Microsoft привнесла несколько изменений в Server 2012, которые были обусловлены появлением динамического контроля доступа:

• Расширение логики контролера домена и Kerberos Key Distribution Center (KDC) для того, чтобы активировать выпуск заявок и токенах аутентификации (authentication tokens)
• Изменение формата токена Kerberos для осуществления транспортировки заявок
• Добавлены альтернативные потоки данных (alternate data streams — ADS) в NTFS, добавлена поддержка кастомных свойств для файлов и папок
• Включено хранение конфиденциальных выражений в ACL файла и папки для осуществления гибкого контроля доступа и настройки аудита
• Расширена схема AD, что теперь позволяет осуществлять централизованное хранение свойств и политик динамического контроль доступа.

Политики центрального доступа

Динамический контроль доступа может использовать AD для хранения политик центрального доступа (central access policies — CAP); делается это для того, чтобы применить эти политики к членам домена. В диалоговом окне Advanced Security Settings для папок была добавлена вкладка Central Policy (показано на рисунке 1). Из этой вкладки, администраторы могут выбрать политику центрального доступа (CAP), которую они хотят присвоить заданной папке. Теперь можно задавать политику доступа к файлам и папкам в вашем домене или лесе, основываясь на значениях стандартных и кастомных атрибутов ваших объектов AD (пользователи или компьютеры). Например, вы можете отказать пользователю в доступе к сетевой папке на файловом сервере, если атрибут Department пользовательского объекта AD не содержит значение “Sales» или «Marketing.» Эта гибкая логика авторизации очень отличается от той логики, которая была раньше (SID пользователя и группы).

Центральные политики доступа (CAP) можно задать из контейнера динамического контроля доступа (DAC), который представлен в обновленном Active Directory Administrative Center (ADAC), что показан на рисунке 2, или c помощью PowerShell комендлетов. С помощью тех же инструментов можно активировать поддержку заявок (claim statements) для объектов AD (пользователи и компьютеры) и добавить значения этим атрибутам. Контроллер домена Server 2012 добавит заявки (claim statements) к токенам авторизации пользователя и компьютера только в том случае, если атрибуты этих объектов действительно содержат информацию и связаны с активированным типом заявки. Перед тем как ваш контроллер домена в Windows Server 2012 сможет выпускать заявки, эту фунцию необходимо включить; имейте ввиду, что КД в Server 2012 по умолчанию не активны для использования CBAC. Чтобы включить CBAC, используйте настройку объекта групповой политики Domain Controller support for Dynamic Access Control and Kerberos armoring в контейнере \Computer Configuration\Policies\Administrative Templates\System\KDC. Чтобы использовать объекты групповых политик для распространения CAP на ваши машины, вы можете использовать опцию объекта групповой политики Central Access Policy в контейнере \Computer Configuration\Policies\Windows Settings\Security Settings\File System.

Аудит доступа к файлам и папкам в Windows Server 2012

С введением динамического контроля доступа заявки можно гибко использовать не только для делегирования доступа к файлам и папкам, но и для аудита доступа к ним. Например, в Server 2012 мы можете настроить правило аудита для отслеживания всех пользователей, которым был предоставлен или запрещен доступ к папкам, которые помечены как “конфиденциальные” (свойство “confidential”). Чтобы централизованно задать настройки аудита для файлов и папок на основании заявок, используйте объект групповой политики Global Object Access Auditing, который Microsoft представила в Windows Server 2008 R2 и который теперь расширен с помощью динамического контроля доступа.

Администраторы могут задавать гибкие настойки контроля доступа и аудита доступа к файлам и папкам; это осуществлять как в качестве добавления, так и независимо от централизованно определённых CAP’ов. Были изменены диалоговые окна в Advanced Security Settings в Windows 8 и Server 2012, чтобым можно было задавать условные выражения (conditional expressions) при настройке авторизации и аудита файлов и папок. Рисунок 3 показывает этот новый интерфейс, иллюстрируя тем самым определение разрешения, которые включает условное выражение в папку, названную SharedData.

Классификация данных

Помимо аудита и контроля доступа Dynamic Access Control также дает новые гибкие механизмы классификации данных. Теперь можно добавить кастомные свойства файлу или папке, которые получили название свойства глобальных ресурсов (global resource properties); это осуществляется через диалоговые окна настроек аудита и контроля доступа. Снова, вы можете сделать то же самое с помощью ADAC или PowerShell командлетов. Чтобы распространить (propagate) эти кастомные свойства на ваши доменные компьютеры, Microsoft оснастила клиенты Windows 8 и Server 2012 специальными расширениями, которые используют LDAP, чтобы подключиться к AD и извлечь эти свойства. Эта новая функция классификации дает вам осуществлять гибкую классификацию данных на основе выбранных вами атрибутов и, соответственно, применять защиту.

Вы можете классифицировать файлы и папки вручную, используя вкладку Classification в свойствах файла или папки, как показано на рисунке 4. Эта вкладка появляется только в системах, в которых присутствует установленная функция Desktop Experience и которая хостит (host) File Server Resource Manager role service

Автоматизация процесса классификации файлов

Процесс классификации файлов можно автоматизировать, если использовать функцию File Classification Infrastructure (FCI). FCI была представлена в Server 2008 R2 и позволяет администраторам определять кастомные классификационные ярлыки (теги), устанавливать правила классификации и истечения ее срока и формировать отчеты по классификациям. Администраторы могут управлять FCI прямо из File Server Resource Manager (FSRM). FCI может быть использована с RMS Bulk Protection Tool, чтобы автоматически применять RMS защиту к файлам.

Это довольно короткое введение в динамический контроль доступа. Подробную информацию (настройка, конфигурирование, решение проблем) можно найти в white paper от Microsoft («Understand and Troubleshoot Dynamic Access Control in Windows Server 8 Beta».)

Меры безопасности Windows Server 2012 и Hyper-V

Windows Server 2012 и Hyper-V — фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere

Windows Server 2012 и Hyper-V — фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere.

Среди изменений Hyper-V — несколько новых функций, направленных на повышение безопасности. Виртуализация сети Network Virtualization — первый шаг Microsoft к централизованно программируемым сетям Software-Defined Networking (SDN). В SDN управление сетевым трафиком возлагается на программы, исполняемые не на физическом оборудовании сети. В результате мы получаем более гибкое управление и точную настройку сети. С точки зрения безопасности, благодаря SDN и виртуализации сети компании и поставщики услуг «облака» могут надежнее изолировать виртуальные машины на сетевом уровне.

В Hyper-V 3.0 также реализовано множество мелких, но не менее важных изменений, относящихся к безопасности. Например, это расширяемый коммутатор виртуальной сети, новая группа администраторов Hyper-V и усовершенствованное шифрование дисков BitLocker.

Определение виртуализации сети

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

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

Hyper-V поддерживает использование виртуальных локальных сетей VLAN для создания изолированных виртуальных сетей с момента выхода Windows Server 2008, но масштабируемость и гибкость виртуальных локальных сетей ограничены. Виртуальные локальные сети поддерживают лишь определенное число изолированных сетей клиентов. Основная причина в том, что коммутаторы, как правило, поддерживают не более 1000 идентификаторов VLAN из теоретического максимума 4096. По данным Microsoft, виртуализация сети обеспечивает функционирование более 16 млн виртуальных сетей.

Кроме того, виртуальным локальным сетям не хватает гибкости. Они плохо приспособлены для динамической «облачной» среды, в которой виртуальные машины клиентов регулярно появляются и исчезают в центре обработки данных и перемещаются между физическими серверами в целях балансировки нагрузки и управления вычислительными ресурсами. Управление VLAN отличается сложностью и требует изменения конфигурации на уровне коммутатора при перемещениях виртуальных машин на другой уровень. Операционная система Server 2012 также совместима с частными виртуальными локальными сетями PVLAN благодаря расширению на уровне виртуального коммутатора Hyper-V. PVLAN увеличивают уровень изоляции между виртуальными машинами, но не решают проблему сложности управления VLAN на виртуальных и физических сетевых устройствах. С этой проблемой можно справиться только с помощью виртуализации сетей.

Внутренний механизм виртуализации сетей

Для виртуализации сети каждой виртуальной машине назначается два IP-адреса. Один IP-адрес видим для виртуальных машин и имеет значение только в контексте данной виртуальной или централизованно программируемой сети клиентов. Этот адрес называется адресом клиента Customer Address (CA). Второй IP-адрес имеет значение только в контексте физической сети. Этот адрес называется адресом поставщика Provider Address (PA). Разделение на CA и PA приносит ряд преимуществ.

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

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

Помимо адресов CA и PA, при виртуализации сети используется третий важный компонент: идентификатор виртуальной подсети VSID. Каждая виртуальная подсеть при виртуализации сети уникально идентифицируется посредством VSID. С помощью идентификаторов VSID узлы Hyper-V отмечают трафик из различных виртуальных подсетей соответствующими тегами и различают трафик виртуальных машин с одинаковыми CA. Программная логика виртуализации сети инкапсулирует VSID, CA и PA в каждый сетевой пакет.

Чтобы распространить конкретные сети клиентов на несколько виртуальных подсетей (и таким образом IP-подсетей), идентификаторы VSID можно сгруппировать в одну сеть клиентов, которая уникально идентифицируется с использованием идентификатора домена маршрутизации RDID. В этих ситуациях изоляция виртуализации сети будет применяться на уровне определенных сетей клиентов. В этом еще одно отличие между виртуальными сетями Network Virtualization и традиционными VLAN: сети VLAN могут быть связаны только с одной IP-подсетью.

Виртуализация сети требует только узла Hyper-V Server 2012. При виртуализации сети гостевой операционной системе в виртуальной машине неизвестно, что ее IP-адрес виртуализован. С точки зрения виртуальных машин все связи устанавливаются с использованием CA. Это также означает, что виртуальная машина, которая является частью сети на основе Network Virtualization, может работать с любой операционной системой: не только Windows 8 и Server 2012, но и более старыми версиями Windows и других операционных систем.

На экране 1 показаны принципы организации виртуализации сети. В сущности, виртуализация сети реализуется как новый сетевой драйвер (ms_netwnv), который может быть привязан к физическим сетевым адаптерам на каждом физическом сервере и виртуальном сервере Server 2012. Новый виртуальный коммутатор Hyper-V, к которому мы еще вернемся в данной статье, вызывает этот сетевой драйвер для инкапсуляции и деинкапсуляции сетевых пакетов при сетевой виртуализации.

Экран 1. Реализация виртуализации сети в качестве драйвера сетевого фильтра

Транспортировка и маршрутизация при виртуализации сети

Для транспортировки и маршрутизации IP-пакетов с виртуализованными адресами CA через физическую сеть могут использоваться два механизма. В основе первого из них лежит протокол туннелирования Generic Routing Encapsulation (GRE), определенный в документах RFC 2784 и 2890. В этом контексте GRE используется для инкапсуляции сетевых пакетов, формируемых виртуальной машиной (с адресом CA), в пакеты, формируемые узлом (с адресом PA). Совместно с другими компаниями, занимающимися «облачными» технологиями (HP, Intel, Emulex, Dell и другими), Microsoft представила в комитет IETF проект, цель которого — сделать стандартом разновидность GRE для Network Virtualization (под названием NVGRE).

Второй механизм, переопределение IP-адреса, можно сравнить с преобразованием сетевых адресов Network Address Translation (NAT). Этот механизм переопределяет пакеты с виртуализованными адресами CA в пакеты с PA, которые можно маршрутизировать по физической сети.

На момент подготовки данной статьи переопределение IP-адреса больше подходит для виртуальных машин с высокими требованиями к пропускной способности (10 Гбит/с) благодаря использованию механизмов разгрузки сетевого адаптера на аппаратном уровне, таких как разгрузка больших пакетов large send offload (LSO) и очередь виртуальных машин virtual machine queue (VMQ). Существенный недостаток переопределения IP-адреса заключается в необходимости одного уникального PA для каждого CA виртуальной машины. В противном случае было бы невозможно распознавать и маршрутизировать сетевые пакеты, исходящие и поступающие в виртуальные машины разных клиентов с перекрывающимися IP-адресами.

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

Недостаток GRE состоит в невозможности задействовать механизмы разгрузки сетевого адаптера на аппаратном уровне. Поэтому, если вы планирует использовать NVGRE для виртуализации сети с высокой пропускной способностью, рекомендуется подождать выпуска сетевых адаптеров с функцией разгрузки NVGRE. Microsoft ожидает, что такие платы для Server 2012 появятся в продаже в 2013 году. При использовании GRE не забудьте о брандмауэрах, в которых по умолчанию могут быть заданы правила для блокирования GRE. Всегда проверяйте, разрешен ли туннельный трафик GRE (IP Protocol 47) в брандмауэре.

Реализация Network Virtualization

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

Чтобы определить политики виртуализации сети локально на узле, необходимо использовать сценарии Windows PowerShell. Для централизованного определения политик можно задействовать графический интерфейс диспетчера Microsoft System Center Virtual Machine Manager (VMM) с пакетом обновления 1 (SP1). VMM — унифицированное решение Microsoft для управления виртуальными машинами. В крупной среде Network Virtualization настоятельно рекомендуется использовать VMM. VMM может запускать нужные команды PowerShell от имени пользователя и применять политики виртуализации сети на узле Hyper-V через локальные агенты узла System Center. Важное ограничение, существующее на данный момент, заключается в том, что графический интерфейс VMM можно использовать только для задания политик переопределения IP-адресов. Чтобы назначить политики NVGRE, необходимо задействовать сценарии PowerShell. Начинающие пользователи могут освоить приемы настройки Network Virtualization через PowerShell с помощью примера сценария на PowerShell в демонстрационном пакете Simple Hyper-V Network Virtualization Demo, подготовленном компанией Microsoft (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-d3efb3b8).

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

Шлюзы Network Virtualization поставляются в различных конструктивных вариантах. Они могут быть построены на шлюзе VPN, который формирует VPN-соединение, чтобы связать две виртуальные сети через физическую сеть. Для этой цели можно использовать сервер Server 2012, на котором выполняется служба маршрутизации RRAS. Функциональность шлюза Network Virtualization может быть предоставлена и выделенным сетевым устройствам (например, коммутаторам, сетевым устройствам), которые действуют как шлюз маршрутизации для виртуализации сети. На данный момент шлюзовые устройства Network Virtualization выпускаются или готовятся к выпуску компаниями F5 Networks и nAppliance Networks. Настроить шлюзы Network Virtualization можно с помощью PowerShell. Начинающим полезно познакомиться с примером сценария в статье Microsoft «Simple Hyper-V Network Virtualization Script with Gateway» (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-6928e91b).

К счастью, существуют расширения VMM SP1 для централизованного и автоматического управления политиками шлюза Network Virtualization. При создании или обновлении виртуальной машины VMM может автоматически обновить топологию маршрутизации каждого устройства шлюза Network Virtualization. Дополнительные сведения о шлюзах Network Virtualization можно найти в статье Microsoft «Hyper-V Network Virtualization Gateway Architectural Guide» (http://technet.microsoft.com/en-us/library/jj618319.aspx).

Гораздо более подробная общая информация о виртуализации сети приведена в статье Microsoft «Microsoft Windows Server 2012 Hyper-V Network Virtualization Survival Guide» (http://social.technet.microsoft.com/wiki/contents/articles/11524.windows-server-2012-hyper-v-network-virtualization-survival-guide.aspx). Хорошую сводку шагов для настройки виртуализации сети можно найти в блоге Microsoft TechNet «Step-by-Step: Hyper-V Network Virtualization» (http://blogs.technet.com/b/keithmayer/archive/2012/10/08/gettingstartedwithhypervnetworkvirtualization.aspx).

Расширяемый виртуальный коммутатор

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

Партнеры Microsoft могут расширять возможности коммутаторов с использованием платформы Windows Filtering Platform (WFP) или фильтров network device interface specification (NDIS) для мониторинга и изменения сетевых пакетов, авторизации соединений или фильтрации трафика. Благодаря новой архитектуре расширяемый коммутатор поможет применить политики безопасности и изолирования при подключении виртуальных машин к сети. Виртуальный коммутатор — идеальное место для проверки данных, пересылаемых между виртуальными машинами, при поиске опасных программ. Классические средства противодействия вредоносному программному обеспечению и несанкционированному доступу обычно не проверяют этот трафик с его помощью и анализируют только трафик между физическими узлами. Некоторые партнеры Microsoft уже работают с расширяемыми коммутаторами: компания sFlow со своим расширением для мониторинга; 5nine, которая выпустила расширение виртуального брандмауэра; NEC, подготовившая расширение для мониторинга на основе OpenFlow. OpenFlow — важный открытый протокол для сетей SDN.

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

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

Наконец, в расширяемом коммутаторе реализованы такие новые функции безопасности, как DHCP Guard, разгрузка операций IPsec Task Offload, задачи IPsec и защита от подделки протокола разрешения адресов Address Resolution Protocol (ARP). С помощью DHCP Guard можно запретить виртуальным машинам работать в качестве сервера DHCP. DHCP Guard отвергает любые пакеты, отправляемые виртуальными машинами, которые указывали бы, что это сервер DHCP. DHCP Guard — свойство, которое можно настроить для любого сетевого адаптера виртуальной машины. Сделать это можно из диспетчера Hyper-V, в разделе дополнительных параметров сетевого адаптера в свойствах виртуальных машин, как показано на экране 2. Рекомендуется включить этот режим при создании «золотого» образа виртуальных машин.

Экран 2. Включение DHCP Guard

Разгрузка операций IPsec позволяет Hyper-V передать обработку, связанную с IPsec, в сетевой адаптер. Это возможно только в том случае, если сетевой адаптер поддерживает данную функцию. Разгрузка операций IPsec позволяет сократить рабочую нагрузку на процессор узла Hyper-V, связанную с использованием алгоритмов шифрования IPsec. Можно также включить этот режим из диспетчера Hyper-V: используйте раздел Hardware Acceleration в параметрах сетевого адаптера в свойствах виртуальных машин, как показано на экране 3.

Экран 3. Включение разгрузки операций IPsec

Расширяемый коммутатор обеспечивает защиту от подмены ARP, чтобы вредоносные виртуальные машины не могли предпринять атаку типа man-in-the-middle. В ходе такой атаки вредоносная машина использует ложные сообщения ARP, чтобы связать фальшивые MAC-адреса с не принадлежащими ей IP-адресами. В результате обманутые машины могут отправлять сообщения вредоносной машине. Чтобы включить защиту от подмены ARP, необходимо оставить флажок Enable MAC address spoofing (включить спуфинг MAC-адресов) в изначальном состоянии (сброшен).

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

Упрощенное делегирование и расширение BitLocker

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

Наконец, нужно указать, что в Server 2012 можно воспользоваться новыми функциями шифрования BitLocker на уровне томов для защиты конфиденциальности и целостности образов виртуальных машин, хранящихся в местах с ненадежной физической защитой. В Server 2012 технология BitLocker расширена для шифрования томов операционной системы и данных на дисках в отказоустойчивых кластерах, в том числе общих томах кластеров. Дополнительные сведения можно найти в статье «BitLocker в Windows 8», опубликованной в Windows IT Pro/RE № 10 за 2012 год.

Важные отличия от средств безопасности vSphere

Новые функции безопасности — важное отличие Hyper-V от ближайшего конкурента, VMware vSphere. Хороший пример — расширяемый коммутатор Hyper-V. VMware также предоставляет виртуальный сетевой коммутатор, но он доступен только в редакции высокого уровня vSphere Enterprise Plus, цена которой, естественно, выше. Коммутатор vSphere не открытый, не расширяемый и не располагает передовыми функциями защиты (например, DHCP Guard и списки ACL виртуального порта) коммутатора Hyper-V. Чтобы дополнить vSphere такими функциями, необходимо приобрести дополнительные программы, например компонент App комплекса VMware vCloud Networking and Security (vCNS).

То же справедливо и для компонента Hyper-V Network Virtualization. Чтобы получить аналогичную функциональность в среде vSphere, потребителям необходимо обратиться к комплексу vCNS, в котором реализована технология VXLAN. Для VXLAN требуется коммутатор vSphere Distributed Switch (VDS), который есть только в редакции высокого уровня vSphere. Ожидается, что VMware скоро реализует централизованно программируемые сети SDN благодаря приобретению компании Nicira.

Отменная гибкость

Таким образом, Hyper-V 3.0 располагает мощными новыми функциями безопасности, которые позволят повысить гибкость и управляемость многоабонентских «облаков» на основе Hyper-V. Пришло время поближе познакомиться с новым продуктом Hyper-V. Кроме того, обязательно изучите новые возможности VVM SP1, незаменимый инструмент для управления развертыванием Hyper-V.

Поделитесь материалом с коллегами и друзьями