Средства защиты виртуальной машины для управления структурой
Сценарий: развертывание защищенных узлов и экранированных виртуальных машин в VMM
Поддержка этой версии Virtual Machine Manager (VMM) прекращена. Рекомендуем перейти на VMM 2019.
В этой статье описывается, как развертывать защищенные узлы Hyper-V и экранированных виртуальных машин в вычислительной структуре System Center Virtual Machine Manager (VMM).
Защищенная структура обеспечивает дополнительную защиту виртуальных машин от мошенничества и кражи данных недобросовестным администратором или вредоносной программой. Вы как поставщик облачных служб или администратор частного облака можете развернуть защищенную структуру, которая, как правило, состоит из сервера, на котором выполняется служба защиты узла (HGS), одного или нескольких защищенных серверов узлов Hyper-V и одной или нескольких экранированных виртуальных машин, работающих на этих узлах. Дополнительные сведения о защищенных структурах см. здесь.
Почему нужно защищать виртуальные машины?
Виртуальные машины содержат конфиденциальные данные и настройки, которые их владельцы не хотели бы демонстрировать администратору структуры. Однако в связи с тем, что все данные для виртуальных машин хранятся в файлах, недобросовестный администратор или вредоносная программа могут скопировать и изучить эти данные. Экранированные виртуальные машины в Windows Server помогают предотвращать такие атаки за счет тщательной проверки работоспособности узла Hyper-V перед загрузкой виртуальной машины, обеспечения запуска виртуальных машин только в разрешенных владельцем центрах обработки данных и использования нового виртуального TPM для самостоятельного шифрования данных гостевой операционной системой. При создании виртуальной машины владелец может выбрать один из двух типов защиты конфиденциальных данных:
Управление защищенной структурой с помощью VMM
Базовая инфраструктура защищенной структуры (состоящая из одного или нескольких защищенных узлов Hyper-V, службы защиты узла и из артефактов, необходимых для создания экранированных виртуальных машин) входит в состав Windows Server 2016 и более поздних версий и должна быть настроена согласно соответствующей документации. После установки управление защищенной структурой можно упростить с помощью диспетчера виртуальных машин System Center.
VMM можно использовать для выполнения следующих действий.
Защита систем виртуализации
Защита систем виртуализации
Защита систем виртуализации
Тем, кому наскучили штампы о реальном и виртуальном
В основе виртуальных решений, как и в основе реальных, лежат машины фоннеймановской архитектуры. А это значит, что основные принципы обеспечения информационной безопасности должны соблюдаться и в таких системах. Поэтому разговоры о том, что виртуализация в меньшей степени нуждается в защите благодаря самой своей структуре, быстро закончились, не завоевав доверия. Вопрос о том, как защитить такие системы не менее надежно, чем реальные, стал основным фактором, сдерживающим распространение технологии, несмотря на все ее плюсы.
Простое наложение проверенных приемов защиты на новые системы невозможно, потому что аппаратный модуль доверенной загрузки (далее – АМДЗ) не может контролировать процессы загрузки виртуальных машин (далее – ВМ) и выполнять таким образом функции резидентного компонента безопасности. В то же время резидентный компонент безопасности должен присутствовать и иметь доступ к контролируемой среде.
В чем смысл?
Компонент безопасности должен находиться вне контролируемой программной среды – в этом и состоит одно из основных исходных положений концепции «точки опоры».
Поскольку реализация системы защиты виртуальных решений на аппаратной базе связана с рядом сложностей технического характера, концепция «точки опоры», или «правильного старта», сводится некоторыми разработчиками к самому факту наличия аппаратного компонента, причем даже не строго определенного. Здесь СЗИ НСД – это отдельное средство защиты информации, а не основа защитного комплекса: предлагается при необходимости устанавливать какие-либо средства доверенной загрузки ОС и разграничения доступа на компьютеры, на которых развернуты те или иные компоненты защиты, если не предполагается защищать их организационными мерами. В чем смысл компонента безопасности, который можно и вовсе не устанавливать? В чем смысл аппаратной базы, если она никак не связана с тем, базой чего она называется?
Резидентный компонент безопасности необходим не потому, что так привычно, а потому, что именно на его основе единственно возможно выполнение пошагового контроля целостности.
Пошаговый контроль – это контроль каждого следующего объекта только тем механизмом или средством, которое уже проверено (с положительным результатом) на предыдущем шаге и является доверенным, и на основе только тех данных, достоверность которых уже установлена на предыдущем шаге.
В этом смысле не все предлагаемые системы защиты выдерживают логику контролируемого старта от начала до конца. Нельзя забывать, что весь набор процедур от старта физического сервера до старта гостевой ОС (проконтролированной на предмет целостности тех файлов, которые должны быть неизменными) и создания внутри нее изолированной программной среды для каждого пользователя – это связанная цепочка последовательных и основанных одно на другом действий.
Очевидно, что в виртуальной инфраструктуре необходимо обеспечивать целостность гипервизора и его механизмов управления, а также целостность компонента безопасности, который в системах виртуализации находится на уровне между гипервизором и виртуальными машинами. Проверку целостности самого компонента безопасности и гипервизора должен производить аппаратный модуль доверенной загрузки, являясь не дополнительной возможностью, а основой системы защиты, и уже проверенные им компоненты безопасности должны контролировать файлы ВМ, обеспечивая ее правильный старт, и создавать изолированную программную среду каждого пользователя.
Каждое звено в этой цепочке контроля должно быть полноценным. Нет смысла контролировать гипервизор и при этом не контролировать средство его управления, Service Console. Точно так же бесполезно контролировать исключительно загрузочный сектор дисков виртуальных машин и не контролировать файлы ОС внутри ВМ.
Защищаемая инфраструктураи требования к защите
Рассмотрим особенности защиты виртуальной инфраструктуры (VMware vSphere 4.1, VMware vSphere 4.0 и VMware Infrastructure 3.5) по требованиям к защищенности информации в АС до класса 1В включительно.
Система защиты должна обеспечивать защищенность всех компонентов среды виртуализации: ESX-серверов и самих виртуальных машин, серверов управления vCenter, дополнительных серверов со службами VMware (например, VMware Consolidated Backup).
Управление системой защиты удобно осуществлять централизованно, например с сервера управления виртуальной инфраструктурой. Доступ к инструментам управления системой защиты должен быть только у администраторов безопасности, от администраторов виртуальной инфраструктуры эти инструменты должны быть скрыты.
Если система защиты полностью интегрируется в виртуальную инфраструктуру, то для ее функционирования не требуются дополнительные серверы. Главное, что при этом система защиты не должна в целях безопасности ограничивать возможности виртуальной инфраструктуры, сводя их к минимуму. Все преимущества систем виртуализации должны оставаться доступными.
Защита ESX-серверов
Основным компонентом в системе виртуализации vSphere является ESX-сервер. Он обеспечивает работу виртуальных машин, осуществляет их запуск, остановку, миграцию на другие ESX-сервера и т.д. Компрометация любого из его компонентов может привести к компрометации всех работающих на нем виртуальных машин, а следовательно, и данных, которые ими обрабатываются. Поэтому крайне важно обеспечить доверенную загрузку ESX-серверов и пошаговый контроль целостности всех его компонентов.
Доверенная загрузка ESX-серверов
Система защиты, естественно, должна обеспечивать доверенную загрузку ОС во время запуска физического сервера до запуска гипервизора (так же, как в реальных системах) с детальным журналированием всех попыток запуска серверов.
Контроль целостности гипервизора, Service Console и модулей защиты
Во время старта сервера АМДЗ проверяет целостность BIOS и физического оборудования сервера. После этого должна начинаться проверка целостности файлов гипервизора, управляющей консоли Service Console и модулей защиты (эти модули устанавливаются в Service Console и предназначены для контроля запуска ВМ). В случае успеха обеих проверок ги-первизор и Service Console загружаются в штатном режиме вместе с уже проверенными дополнительными модулями защиты.
Защита виртуальных машин
Виртуальным машинам присущи те же угрозы, что и их реальным аналогам. Для них точно так же необходимо обеспечивать доверенную загрузку, контроль целостности, разграничение доступа и надежную идентификацию/аутентификацию пользователей.
Средства разграничения доступа устанавливаются в гостевую ОС ВМ (аналогично тому, как в реальных системах они устанавливаются в ОС), а модули, осуществляющие процедуры загрузки и контроля целостности, находятся вне контролируемой ВМ. Эти модули просто обязаны быть независимыми от подконтрольного объекта, иначе это не защита, а имитация.
Для доступа пользователей к виртуальным машинам могут использоваться протоколы RDP или ICA1. На клиентские устройства должно устанавливаться дополнительное программное обеспечение, позволяющее подключаться по этим протоколам к ВМ и проходить идентификацию/аутентификацию с использованием аппаратных идентификаторов.
Контроль целостности файлов в ВМ
Перед запуском ВМ необходимо осуществлять проверку целостности ее файлов. Это утверждение настолько бесспорно, что вызывает желание подходить к нему исключительно формально. Однако это в корне неверный подход к вопросам безопасности. Контролировать необходимо, конечно, не файлы, являющиеся виртуальными машинами (об этом уже шла речь выше), а файлы внутри виртуальных машин. Список контролируемых файлов должен определяться администратором безопасности и назначаться в программе управления виртуальной инфраструктурой.
Разграничение доступа
В гостевых ОС необходимо осуществлять мандатное и/или дискреционное разграничение доступа пользователей и процессов ко всем ресурсам. При этом для каждого пользователя внутри ВМ необходимо создавать изолированную программную среду. Идентификация/аутентификация пользователей при доступе к приложениям и виртуальным рабочим столам должна осуществляться с помощью аппаратных идентификаторов, кроме случаев, когда администратор безопасности снял ту или иную ВМ с контроля, но такой режим работы не следует включать в перечень рекомендованных.
Защита элементов управления виртуальной инфраструктурой
Надежная защита vCenter от несанкционированного доступа и разграничение доступа администраторов виртуальной инфраструктуры имеют принципиальное значение при построении виртуальной инфраструктуры предприятия. Как правило, vCenter устанавливается на физический сервер, и для его защиты применяется надежное сертифицированное средство защиты информации, поддерживающее работу на терминальных серверах.
Защита дополнительных серверов со службами VMware, например VMware Update Manager, осуществляется аналогично серверу с vCenter, если они установлены на физическом сервере, или аналогично ВМ, если эти службы установлены на виртуальной машине.
Модули управления системой защиты устанавливаются на сервер с vCenter, что позволяет управлять всей системой защиты централизованно и анализировать журналы со всех ESX-серверов.
Доверенная загрузка vCenter
Перед загрузкой ОС и vCenter АМДЗ производит идентификацию/аутентификацию администраторов и детально журна-лирует все попытки загрузки операционной системы и vCenter.
После этого производится контроль целостности BIOS и оборудования сервера. Далее проверяется целостность файлов ОС и файлов vCenter, предназначенных для управления средой виртуализации. Также проверяются модули защиты и управления системой защиты.
Для администрирования виртуальной инфраструктуры или системы защиты администраторы также должны пройти процедуру идентификации/аутентификации. Естественно, идентификация должна быть аппаратной.
В vCenter необходимо производить дискреционное и/или мандатное разграничение доступа администраторов и процессов ко всем ресурсам. При этом для каждого администратора должна создаваться изолированная программная среда.
Строить воздушные замки или разрушать их?
Так ли в действительности велика разница между реальными и виртуальными системами? Как показывает аккуратное применение давно доказанной теоретической базы, различия минимальны. С точки зрения построения системы защиты они исчерпываются особенностями непосредственной технической реализации давно известных принципов, подтвержденных успешной практикой. Противопоставление виртуального и реального, как, впрочем, и сопоставление, уже давно перестало быть фигурой мысли, оставшись лишь порядком затертой фигурой речи. Думается, мы уже готовы не наступить на грабли.
Системы виртуализации – это не новое непостижимое явление природы, а лишь логичный и закономерный этап развития технологий. Значит, и системы их защиты тоже должны быть естественным развитием, новой надстройкой прочно стоящего на твердой земле базиса. Решения для реальной защиты систем виртуализации, учитывающие одновременно все существующие достижения сферы защиты информации и особенности новых архитектур, уже созданы, сертифицируются и предлагаются к внедрению.
Рекомендации по планированию защищенной структуры и экранированной виртуальной машины для поставщиков услуг размещения
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом разделе рассматриваются решения по планированию, которые необходимо внести, чтобы разрешить запуск экранированных виртуальных машин в структуре. Независимо от того, обновляется ли существующая структура Hyper-V или создает новую структуру, работающие экранированные виртуальные машины состоят из двух основных компонентов:
#1 принятия решений: уровень доверия в структуре
Реализация службы защиты узла и защищенных узлов Hyper-V будет зависеть главным образом от надежности, которую вы хотите достичь в вашей структуре. Сила доверия регулируется режимом аттестации. Существует два взаимоисключающих варианта:
Аттестация, доверенная доверенным платформенным модулем
Если ваша цель заключается в защите виртуальных машин от вредоносных администраторов или от скомпрометированной структуры, вы будете использовать аттестацию, доверенную доверенным платформенным модулем. этот вариант хорошо подходит для сценариев размещения с несколькими клиентами, а также для наиболее ценных активов в корпоративных средах, таких как контроллеры домена или серверы содержимого, такие как SQL или SharePoint. Политики целостности кода, защищенные гипервизором (обязательная политика HVCI), измеряются и их срок действия обеспечивает HGS, прежде чем узлу разрешается запускать экранированные виртуальные машины.
Аттестация ключа узла
Если требования в основном определяются соответствием требованиям, требующим, чтобы виртуальные машины были зашифрованы как при хранении, так и на лету, будет использоваться аттестация ключа узла. Этот вариант хорошо подходит для центров обработки данных общего назначения, где вы имеете опыт работы с администраторами узлов и структур Hyper-V, имеющими доступ к гостевым операционным системам виртуальных машин для повседневного обслуживания и эксплуатации.
В этом режиме администратор структуры несет ответственность за обеспечение работоспособности узлов Hyper-V. Так как HGS не позволяет решить, что такое или не разрешено запускать, вредоносные программы и отладчики будут работать так, как задумано.
Однако отладчики, пытающиеся выполнить прямое подключение к процессу (например, WinDbg.exe), блокируются для экранированных виртуальных машин, так как рабочий процесс виртуальной машины (VMWP.exe) является защищенным блоком процесса (PPL). Альтернативные методы отладки, такие как используемые LiveKd.exe, не блокируются. В отличие от экранированных виртуальных машин, Рабочий процесс для поддерживаемых шифрованием виртуальных машин не выполняется в виде PPL, поэтому традиционные отладчики, такие как WinDbg.exe, будут продолжать работать в обычном режиме.
аналогичный режим аттестации с именем «доверенная аттестация (на основе Active Directory)» устарел, начиная с Windows Server 2019.
Выбранный уровень доверия определяет требования к оборудованию для узлов Hyper-V, а также политики, применяемые к структуре. При необходимости можно развернуть защищенную структуру, используя существующее оборудование и аттестацию, доверенную администратором, а затем преобразовать ее в аттестацию, доверенную для доверенного платформенного модуля, при обновлении оборудования и необходимости усилить безопасность структуры.
#2 принятия решений: существующая структура Hyper-V в сравнении с новой отдельной структурой Hyper-V
Если у вас уже есть структура (Hyper-V или иным способом), скорее всего, ее можно использовать для запуска экранированных виртуальных машин вместе с обычными виртуальными машинами. Некоторые клиенты решили интегрировать экранированные виртуальные машины в существующие средства и структуры, в то время как другие отделяют структуру от бизнес-целей.
Планирование администратора HGS для службы защиты узла
Разверните службу защиты узла (HGS) в среде с высоким уровнем безопасности, будь это на выделенном физическом сервере, экранированной виртуальной машине, виртуальной машине на изолированном узле Hyper-V (отделенном от структуры, которую он защищает) или логически разделенной с помощью другой подписки Azure.
Краткое руководство по развертыванию защищенной структуры
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом разделе объясняется, что такое защищенная структура, ее требования и Сводка процесса развертывания. Подробные инструкции по развертыванию см. в разделе Развертывание службы защиты узла для защищенных узлов и экранированных виртуальных машин.
Что такое защищенная структура
защищенная структура — это Windows Server 2016ная структура Hyper-V, способная защищать рабочие нагрузки клиентов от вредоносных программ, выполняемых на узле, а также от системных администраторов. Эти виртуализированные рабочие нагрузки клиента, защищенные как при неактивных, так и в полете, называются экранированными виртуальными машинами.
Каковы требования к защищенной структуре
Требования для защищенной структуры включают:
Место для запуска экранированных виртуальных машин, которые свободны от вредоносных программ.
Они называются защищенными узлами. защищенные узлы — это Windows Server 2016 узлы Hyper-V выпуска datacenter, которые могут запускать экранированные виртуальные машины, только если они могут доказать, что они работают в известном надежном состоянии, внешнему центру, который называется службой защиты узла (HGS). HGS — это новая роль сервера в Windows Server 2016, которая обычно развертывается как кластер с тремя узлами.
Способ проверки того, что узел находится в работоспособном состоянии.
HGS выполняет аттестацию, где измеряет работоспособность защищенных узлов.
Процесс безопасного освобождения ключей для работоспособных узлов.
HGS выполняет защиту ключа и основные выпуски, при этом ключи возвращаются к работоспособным узлам.
Средства управления для автоматизации безопасной подготовки и размещения экранированных виртуальных машин.
При необходимости эти средства управления можно добавить в защищенную структуру:
при необходимости можно развернуть в режиме key, используя существующие узлы Hyper-V, которые были обновлены до Windows Server 2019 datacenter edition, а затем преобразовать их в более безопасный режим TPM при наличии поддерживаемого серверного оборудования (включая TPM 2,0).
Теперь, когда вы понимаете, что такое части, давайте рассмотрим пример модели развертывания.
Как получить из текущей структуры Hyper-V в защищенную структуру
давайте представьте себе этот сценарий — у вас есть существующая структура Hyper-V, например Contoso.com на следующем рисунке, и вы хотите создать Windows Server 2016 защищенную структуру.
Шаг 1. развертывание узлов Hyper-V под управлением Windows Server 2016
узлы Hyper-V должны работать Windows Server 2016 datacenter edition или более поздней версии. При обновлении узлов можно Перейти с выпуска Standard Edition на выпуск Datacenter.
Шаг 2. Развертывание службы защиты узла (HGS)
Затем установите роль сервера HGS и разверните его как кластер с тремя узлами, как показано на следующем рисунке, например relecloud.com. Для этого требуются три командлета PowerShell:
Если существующие серверы Hyper-V не соответствуют предварительным требованиям для режима TPM (например, у них нет доверенного платформенного модуля (TPM 2,0)), вы можете инициализировать HGS с помощью аттестации на основе администратора (режим AD), что требует Active Directory отношения доверия с доменом структуры.
В нашем примере компания Contoso изначально развертывает в режиме AD для немедленного удовлетворения требований соответствия требованиям и планирует преобразовать их в более защищенную аттестацию на основе доверенного платформенного модуля после приобретения соответствующего оборудования сервера.
Шаг 3. Извлечение удостоверений, базовых показателей оборудования и политик целостности кода
Процесс извлечения удостоверений из узлов Hyper-V зависит от используемого режима аттестации.
Для режима AD ИДЕНТИФИКАТОРом узла является учетная запись компьютера, присоединенного к домену, которая должна быть членом назначенной группы безопасности в домене структуры. Членство в назначенной группе является единственным определением того, является ли узел работоспособным.
В этом режиме администратор структуры несет ответственность за обеспечение работоспособности узлов Hyper-V. Так как HGS не позволяет решить, что такое или не разрешено запускать, вредоносные программы и отладчики будут работать так, как задумано.
Однако отладчики, пытающиеся выполнить прямое подключение к процессу (например, WinDbg.exe), блокируются для экранированных виртуальных машин, так как рабочий процесс виртуальной машины (VMWP.exe) является защищенным блоком процесса (PPL). Альтернативные методы отладки, такие как используемые LiveKd.exe, не блокируются. В отличие от экранированных виртуальных машин, Рабочий процесс для поддерживаемых шифрованием виртуальных машин не выполняется в виде PPL, поэтому традиционные отладчики, такие как WinDbg.exe, будут продолжать работать в обычном режиме.
Другими словами, строгие шаги проверки, используемые для режима TPM, не используются в режиме AD.
Для режима TPM требуются три вещи:
Все это — защищенная структура построена с точки зрения инфраструктуры для ее запуска. Теперь вы можете создать диск шаблона экранированной виртуальной машины и файл данных экранирования, чтобы обеспечить простую и безопасную подготовку экранированных виртуальных машин.
Шаг 4. Создание шаблона для экранированных виртуальных машин
Шаблон экранированной виртуальной машины защищает диски шаблонов, создавая сигнатуру диска в известном месте на момент времени. Если впоследствии диск шаблона заражен вредоносными программами, его подпись будет отличаться от исходного шаблона, который будет обнаружен в процессе подготовки защищенной экранированной виртуальной машины. Диски экранированных шаблонов создаются путем запуска мастера создания диска экранированного шаблона или с помощью обычного диска шаблона.
Каждый из них включен в компонент » средства экранированной виртуальной машины » в средства удаленного администрирования сервера для Windows 10. После загрузки RSAT выполните следующую команду, чтобы установить компонент » средства экранированной виртуальной машины «:
Доверенному администратору, например администратору структуры или владельцу виртуальной машины, потребуется сертификат (часто предоставляемый поставщиком услуг размещения) для подписи диска шаблона VHDX.
Подпись диска вычислена в разделе ОС виртуального диска. Если что-либо изменилось в разделе ОС, подпись также изменится. Это позволяет пользователям строго определять, какие диски они доверяют, указывая соответствующую подпись.
Шаг 5. Создание файла данных экранирования
Файл данных экранирования, также известный как PDK-файл, захватывает конфиденциальные сведения о виртуальной машине, например пароль администратора.
Файл данных экранирования также включает параметр политики безопасности для экранированной виртуальной машины. При создании файла данных экранирования необходимо выбрать одну из двух политик безопасности:
Наиболее безопасный вариант, который устраняет многие административные направления атак.
Менее низкий уровень защиты, который по-прежнему обеспечивает возможность шифрования виртуальной машины, но позволяет администраторам Hyper-V выполнять такие действия, как использование подключения консоли виртуальной машины и PowerShell Direct.
можно добавить дополнительные элементы управления, такие как VMM или Windows Azure Pack. Если вы хотите создать виртуальную машину, не устанавливая эти компоненты, см. статью Пошаговое руководство. Создание экранированных виртуальных машин без VMM.
Шаг 6. Создание экранированной виртуальной машины
Создание экранированных виртуальных машин значительно отличается от обычных виртуальных машин. в Windows Azure Pack взаимодействие еще проще, чем создание обычной виртуальной машины, так как вам нужно указать только имя, файл данных экранирования (содержащий оставшуюся часть информации о специализации) и сеть виртуальной машины.