Guarded host windows 10 что это
Device Guard в Windows 10. Политика целостности кода
Автор статьи — Андрей Каптелин, участник ИТ-сообщества
Device Guard – набор программно-аппаратных технологий защиты, доступный для устройств с Windows 10. Статья посвящена одной из компонент Device Guard – политике Code Integrity (CI). С деталями настройки и применения CI можно познакомиться здесь.
Назначение Device Guard
В современном мире киберугрозы развиваются очень быстро. Технологии защиты уже не поспевают за развитием вредоносных программ, как за их количеством, так и расширяющимся спектром атак.
Вирусы из забавы для одиночек переросли в организованную киберпреступность. Автоматизация и низкая стоимость сложных атак не оставляет шанса даже небольшим компаниям оставаться незамеченными.
Классическое решение основывается на трех основных условиях: установленные обновления, обновленный антивирус и отсутствие административных привилегий. Это уже давно сложившийся подход. Однако, совершенно легальная с точки зрения антивируса программа может выполнять нежелательные действия и не использовать при этом уязвимости ПО. Такой взгляд на безопасность ставит под подозрение любую программу. Уже нельзя полагаться на список сигнатур антивируса, а анализировать действия всех программ довольно трудно.
Новые угрозы требуют новых решений безопасности, и в Windows 10 они уже имеются. Одно из решений – запускать только одобренное программное обеспечение. Такой подход успешно опробован на мобильных платформах Windows и Apple. В них абсолютно все ПО проходит проверку и имеет цифровую подпись, на основании которой устройство разрешает его запуск. В Windows эту функцию обеспечивает механизм проверки целостности кода – Code Integrity (CI).
Уже на стадии запуска компьютера можно контролировать запуск программного обеспечения, подписанного доверенными сертификатами. Далее, имея список своего программного обеспечения, можно запретить запуск чего-то иного, и задача обеспечения безопасности решена. Список доверенных сертификатов, используемых для подписи исполняемых файлов, представляет собой файл-политику, которым и руководствуется операционная система.
Но мир ПО на Windows весьма разнообразен, и далеко не все программы имеют цифровые подписи, а многие не получат их никогда. Для этого механизм Code Integrity может использовать подписанные вашим сертификатом каталоги – списки файлов программы и их хэш-коды.
В итоге, для использования нового механизма, требуется создать политику, содержащую список доверенных сертификатов и хэш-коды не подписанных файлов и, при необходимости, дополнить её файлами-каталогами разрешенного программного обеспечения.
Самым простым использование Device Guard будет для новых, либо уже имеющихся рабочих мест с фиксированным списком ПО. Достаточно сформировать политику целостности кода и активировать функционал, после этого ничто постороннее не сможет запуститься на этих компьютерах.
Существует также возможность создания политик на основе нескольких возможных вариантов рабочих мест и слияние их в единую политику, назначаемую в последующем всем рабочим местам.
Для продвинутых пользователей, которые сами выбирают и устанавливают программы, достаточно режима аудита. Журнал запускаемых приложений пригодится в дальнейшем для определения нужных и ненужных программ.
Замечу, Device Guard с механизмами Code Integrity и Virtualization Based Security (VBS) доступен только в редакции Windows 10 Enterprise.
Настройка политики Code Integrity
Настройка Device Guard в пользовательском режиме (User Mode Code Integrity) наиболее близка к обычным задачам ограничения запуска программного обеспечения.
Для того чтобы создать политику Code Integrity на эталонном компьютере, потребуется создать теневую копию диска и запустить командлет сканирования файлов. В данном случае теневая копия позволяет получить процессу сканирования доступ ко всем, в том числе открытым на момент сканирования, файлам.
Полученный снимок диска, подмонтированный в папку C:\scpy, можно просканировать следующим командлетом:
Данная команда создаст список подписей (сертификатов), обнаруженных на эталонном компьютере, и посчитает хэш-коды исполняемых файлов, не имеющих подписи. Результатом будет XML-файл содержащий следующие параметры:
Опция, включающая работу модуля Code Integrity в режиме аудита, при котором все не попадающие под сформированную политику исполняемые файлы записываются в журнал аудита.
Пример обнаруженного сертификата. Все подписанные им исполняемые файлы будут выполняться без ограничений.
Пример обнаруженного файла без цифровой подписи. При совпадении хэш-кода, данный файл будет запущен.
Полученный XML-файл необходимо скомпилировать в бинарный формат и поместить в системную папку C:\Windows\System32\CodeIntegrity\.
После перезагрузки компьютера механизм Code Integrity начнет работу в режиме аудита. Проверив запуск и работу всех необходимых программ, можно дополнить политику данными, собранными аудитом, выполнив следующую команду.
Ключ -Audit указывает, что необходимо создать политику на основе записей в журнале аудита.
Файл AuditPolicy.xml аналогичен по структуре файлу BasePolicy.xml, сформированному ранее.
Для объединения результатов первичного сканирования и собранной в режиме аудита информации существует команда объединения политик.
Чтобы включить принудительное применение политики, в полученном файле отключаем режим аудита.
В результате удаляется запись Enabled:Audit Mode из XML-файла, и такая политика будет блокировать всё неучтенное в ней ПО.
Далее компилируем XML-файл в бинарный формат, снова выполнив команду
Распространить политику на целевые компьютеры можно как скопировав удобным способом файл SIPolicy.bin, так и воспользовавшись групповой политикой Windows 10 в разделе Computer Configuration\Administrative Templates\System\Device Guard.
Создание файла-каталога
Политика Code Integrity представляет собой монолитный список разрешенного программного обеспечения, что не всегда удобно. Для использования новых или обновленных программ, если их не удаётся заверить электронной подписью, можно создать файл-каталог.
Для примера возьмём программу 7zip, для которой создадим файл каталога, содержащий как данные об дистрибутиве, так и о всех исполняемых файлах после установки дистрибутива.
Для этого на станции без активного Device Guard запустим утилиту мониторинга PackageInspector (входит в состав Windows 10 Enterprise), указав в качестве параметров букву диска для наблюдения и запускаемый файл дистрибутива программы.
По окончании установки 7zip проверяем его запуск и работу и останавливаем мониторинг командой
Файл 7zip.cdf покажет все исполняемые файлы, подвергшиеся мониторингу.
Файл 7zip.cat содержит скомпилированную информацию для Device Guard.
Чтобы созданный файл каталога стал доверенным для Device Guard, подпишем его своей цифровой подписью.
Если у администратора уже имеется импортированный сертификат с назначением Code Sign, его можно использовать для подписи прямо из PowerShell, указав алгоритм хеширования SHA256, необходимый для Device Guard.
Сертификат должен быть выдан доверенным центром сертификации, корневой сертификат которого был импортирован на эталонный компьютер перед созданием политики.
Далее нужно поместить сгенерированный и подписанный файл каталога на нужные компьютеры, скопировав в хранилище каталогов по пути
C:\Windows\System32\CatRoot\
В отличие от политики, файлы каталогов применяются сразу и без перезагрузки. Теперь установка и работа 7zip на компьютере разрешена.
Обзор защищенной структуры и экранированных виртуальных машин
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
Обзор защищенной структуры
Безопасность виртуализации — это основная вложенная область в Hyper-V. Помимо защиты узлов или других виртуальных машин от ВМ с вредоносными программами необходимо также защитить их от скомпрометированного узла. Это фундаментальная опасность для каждой платформы виртуализации сегодня, будь то Hyper-V, VMware или любой другой. Простыми словами, если файл виртуальной машины извлекается из системы организации (злонамеренно или случайно), его можно запустить в любой другой системе. Защита ценных ресурсов, таких как контроллеры домена, конфиденциальные файловые серверы и системы отдела кадров, — самая приоритетная задача в организации.
чтобы помочь защититься от скомпрометированной структуры виртуализации, Windows Server 2016 Hyper-V предоставили экранированные виртуальные машины. экранированная виртуальная машина — это виртуальная машина поколения 2 (поддерживается в Windows Server 2012 и более поздних версиях) с виртуальным доверенным платформенным модулем, шифруется с помощью BitLocker и может выполняться только на работоспособных и утвержденных узлах в структуре. Благодаря экранированным виртуальным машинам и защищенной структуре поставщики облачных служб или администраторы корпоративного частного облака предоставляют более безопасную среду для клиентских виртуальных машин.
Защищенная структура состоит из:
Когда клиент создает экранированные виртуальные машины, запущенные в защищенной структуре, узлы Hyper-V и эти виртуальные машины защищаются с помощью службы HGS. HGS предоставляет две различные службы: аттестации и защиты ключей. Служба аттестации гарантирует, что экранированные виртуальные машины могут запускаться только на доверенных узлах Hyper-V, тогда как служба защиты ключей предоставляет ключи, с помощью которых можно включить виртуальные машины и выполнить их динамическую миграцию на другие защищенные узлы.
Видео: введение в экранированные виртуальные машины
Режимы аттестации в решении защищенной структуры
HGS поддерживает различные режимы аттестации для защищенной структуры:
Рекомендуется использовать аттестацию по ключу доверенного платформенного модуля, так как она предоставляет более надежные гарантии, что описано в приведенной ниже таблице. Но в этом случае требуется, чтобы у узлов Hyper-V был доверенный платформенный модуль версии 2.0. Если в настоящее время нет доверенного платформенного модуля (TPM) 2,0 или TPM, можно использовать аттестацию ключа узла. Если вы приобретете новое оборудование и захотите перейти на аттестацию по ключу доверенного платформенного модуля, смените режим аттестации в службе защиты узла без прерывания или с минимальным прерыванием работы структуры.
| Режим аттестации, выбираемый для узлов | Гарантии узла |
|---|---|
| Аттестация по ключу доверенного платформенного модуля: предоставляет самую надежную защиту, но требует дополнительной настройки. Оборудование и встроенное по узла должны включать в себя TPM 2,0 и UEFI 2.3.1 с включенной безопасной загрузкой. | Защищенные узлы утверждаются на основе удостоверения доверенного платформенного модуля, измеряемой последовательности загрузки и политик целостности кода, чтобы гарантировать выполнение только утвержденного кода. |
| Аттестация ключа узла: Предназначен для поддержки существующего оборудования узла, когда доверенный платформенный модуль 2,0 недоступен. Такая аттестация требует меньше этапов настройки и совместима со стандартным серверным оборудованием. | Защищенные узлы утверждаются в зависимости от принадлежности ключа. |
другой режим с именем «доверенная аттестация с правами администратора» устарел, начиная с Windows Server 2019. Этот режим основан на защищенном членстве узла в назначенной группе безопасности домен Active Directory Services (AD DS). Аттестация ключа узла обеспечивает аналогичную идентификацию узла и проще в настройке.
Гарантии, предоставляемые службой защиты узла
HGS, а также методы создания экранированных виртуальных машин обеспечивают следующие гарантии.
| Тип гарантии для виртуальных машин | Гарантии экранированной виртуальной машины, предоставленные службой защиты ключей и методами создания экранированных виртуальных машин |
|---|---|
| Шифрование дисков с помощью BitLocker (диски ОС и диски данных) | Экранированные виртуальные машины используют BitLocker для защиты своих дисков. Ключи BitLocker, необходимые для загрузки виртуальной машины и расшифровки дисков, защищаются виртуальным доверенным платформенным модулем экранированной виртуальной машины с помощью проверенных отраслевых технологий, таких как безопасная измеряемая загрузка. Хотя экранированные виртуальные машины автоматически шифруют и защищают только диск операционной системы, можно также шифровать диски с данными, подключенные к этим машинам. |
| Развертывание новых экранированных виртуальных машин из «доверенных» шаблонов дисков и образов | При развертывании новых экранированных виртуальных машин клиенты могут указать, каким шаблонам дисков они доверяют. В экранированных шаблонах дисков есть подписи, которые определяются в тот момент, когда их содержимое распознается как надежное. Подписи дисков затем сохраняются в каталоге подписей, который безопасно передается клиентами структуре при создании экранированных виртуальных машин. Во время подготовки экранированных виртуальных машин подпись диска определяется снова и сравнивается с доверенными подписями в каталоге. Если подписи совпадают, машина развертывается. В противном случае шаблон диска такой машины считается ненадежным и происходит сбой развертывания. |
| Защита паролей и других секретов при создании экранированной виртуальной машины | При создании виртуальных машин необходимо убедиться, что секреты виртуальной машины, такие как подписи доверенных дисков, сертификаты RDP и пароль учетной записи локального администратора виртуальной машины, не будут представлены в структуре. Эти секреты хранятся в файле данных экранирования (PDK-файле) — зашифрованном файле, который защищен ключами клиента и отправлен клиентом в структуру. При создании экранированной виртуальной машины клиент выбирает, какие данные экранирования использовать. При этом секреты безопасно передаются доверенным компонентам внутри защищенной структуры. |
| Контроль на уровне клиента в отношении структуры для запуска виртуальной машины | Данные экранирования также содержат список защищенных структур, в которых разрешен запуск определенной экранированной виртуальной машины. Это полезно в случаях, когда экранированная виртуальная машина обычно находится в локальном частном облаке, но для аварийного восстановления ее нужно перенести в другое облако (частное или общедоступное). Целевое облако или структура должны поддерживать экранированные виртуальные машины, и эти машины должны разрешать запуск в этой структуре. |
Что такое данные экранирования и зачем они нужны
Файл данных экранирования (также называемый файлом данных подготовки, или PDK-файлом) — это зашифрованный файл, который создает клиент или владелец виртуальной машины, чтобы защитить важную информацию о конфигурации виртуальной машины (пароль администратора, протокол удаленного рабочего стола и другие сертификаты с информацией об удостоверениях, учетные данные для присоединения домена и т. д.). Администратор структуры использует файл данных экранирования при создании экранированной виртуальной машины, но не может просматривать и использовать содержащиеся в нем сведения.
Кроме того, файлы данных экранирования содержат следующие секреты:
Файл данных экранирования (PDK-файл) гарантирует, что виртуальная машина будет создана так, как предполагал клиент. Например, когда клиент размещает файл ответов (unattend.xml) в файле данных экранирования и передает его поставщику услуг размещения, последний не может просматривать файл ответов или вносить в него изменения. Поставщик услуг размещения также не может указать другой VHDX при создании экранированной виртуальной машины, так как файл данных экранирования содержит подписи доверенных дисков, на основе которых можно создать экранированные виртуальные машины.
На рисунке ниже показан файл данных экранирования и связанные с ним элементы конфигурации.
Типы виртуальных машин, которые могут выполняться в защищенной структуре
В защищенной структуре могут запускаться виртуальные машины одного из следующих типов:
Виртуальные машины с поддержкой шифрования предназначены для случаев, когда есть полное доверие к администратору структуры. Например, предприятие может развернуть защищенную структуру, чтобы выполнять для дисков виртуальной машины шифрование неактивных данных с целью соответствия требованиям. Администраторы структуры по-прежнему могут использовать удобные средства управления, например подключения к консоли виртуальной машины, PowerShell Direct и другие повседневные средства управления и устранения неполадок.
Экранированные виртуальные машины предназначены для структур, где данные и состояние виртуальной машины должны быть защищены как от администраторов структуры, так и от ненадежного программного обеспечения, которое может выполняться на узлах Hyper-V. К примеру, экранированные виртуальные машины никогда не разрешат подключение к консоли виртуальной машины, тогда как для виртуальных машин с поддержкой шифрования администратор структуры может включить или отключить эту защиту.
В следующей таблице перечислены различия между поддерживаемыми шифрованием и экранированными виртуальными машинами.
| Функция | Второе поколение. Поддержка шифрования | Второе поколение. Экранирование |
|---|---|---|
| Безопасная загрузка | Да, необходимо, но есть возможность настройки | Да, необходимо, применяется принудительно |
| Виртуальный доверенный платформенный модуль | Да, необходимо, но есть возможность настройки | Да, необходимо, применяется принудительно |
| Шифрование состояния виртуальной машины и трафика динамической миграции | Да, необходимо, но есть возможность настройки | Да, необходимо, применяется принудительно |
| Компоненты интеграции | Настраивается администратором структуры | Некоторые компоненты интеграции заблокированы (например, обмен данными, PowerShell Direct) |
| Подключение к виртуальной машине (консоль), HID-устройства (например, клавиатура, мышь) | Включено, не может быть отключено | включено на узлах, начинающихся с Windows Server версии 1803; Отключено на более ранних узлах |
| Последовательные или COM-порты | Поддерживается | Отключено (не может быть включено) |
| Подключение отладчика (к процессу виртуальной машины) 1 | Поддерживается | Отключено (не может быть включено) |
1 Традиционные отладчики, которые присоединяются непосредственно к процессу, например WinDbg.exe, заблокированы для экранированных виртуальных машин, так как рабочий процесс виртуальной машины (VMWP.exe) является защищенным процессом (PPL). Альтернативные методы отладки, такие как используемые LiveKd.exe, не блокируются. В отличие от экранированных виртуальных машин, Рабочий процесс для поддерживаемых шифрованием виртуальных машин не выполняется в виде PPL, поэтому традиционные отладчики, такие как WinDbg.exe, будут продолжать работать в обычном режиме.
Как экранированные виртуальные машины, так и виртуальные машины с поддержкой шифрования продолжают поддерживать стандартные возможности управления структуры, в том числе динамическую миграцию, реплику Hyper-V, контрольные точки виртуальной машины и т. д.
Служба защиты узла в действии. Включение экранированной виртуальной машины
Включается виртуальная машина VM01. Прежде чем защищенный узел сможет включить экранированную виртуальную машину, нужно подтвердить его работоспособность. Чтобы доказать, что он работоспособен, он должен предоставить сертификат работоспособности службе защиты ключей. Он передается в ходе аттестации.
Узел запрашивает аттестацию. Защищенный узел запрашивает аттестацию. Режим аттестации устанавливается службой защиты узла.
Аттестация, доверенная доверенным платформенным модулем. узел Hyper-V отправляет сведения, содержащие:
сведения, определяющие доверенный платформенный модуль (ключ подтверждения);
сведения о процессах, запущенных в течение последней последовательности загрузки (журнал TCG);
Сведения о политике целостности кода (CI), примененной на узле.
Аттестация происходит при запуске узла, а затем каждые 8 часов. Если по какой-либо причине у узла нет сертификата аттестации при попытке запуска виртуальной машины, это также активирует аттестацию.
Аттестация ключа узла. узел Hyper-V отправляет открытую половину пары ключей. HGS проверяет, что ключ узла зарегистрирован.
Аттестация по группе доверенного администратора. Узел Hyper-V отправляет билет Kerberos, который определяет группы безопасности, в которые входит узел. HGS проверяет, принадлежит ли узел к группе безопасности, которую ранее настроил доверенный администратор HGS.
Аттестация завершается успешно (или с ошибкой). Режим аттестации определяет, какие проверки необходимы для успешной аттестации работоспособности узла. При использовании аттестации, доверенной для доверенного платформенного модуля, проверяется удостоверение TPM узла, измерения загрузки и политика целостности кода. При использовании аттестации ключа узла проверяется только регистрация ключа узла.
Сертификат аттестации отправляется на узел. Предполагая, что аттестация прошла успешно, сертификат работоспособности отправляется на узел, а узел считается защищенным (разрешено запускать экранированные виртуальные машины). Узел использует сертификат работоспособности для авторизации службы защиты ключей, чтобы безопасно освободить ключи, необходимые для работы экранированных виртуальных машин.
Узел запрашивает ключ виртуальной машины. У защищенного узла отсутствуют ключи, необходимые для включения экранированной виртуальной машины (в этом случае VM01). Чтобы получить необходимые ключи, защищенный узел должен предоставить службе защиты ключей следующее:
Ключ освобождается. Служба защиты ключей проверяет сертификат работоспособности на допустимость. Сертификат не должен быть просрочен, и служба защиты ключей должна доверять службе аттестации, выдавшей его.
Ключ возвращается на узел. Если сертификат работоспособности допустим, служба защиты ключей пытается расшифровать секрет и безопасно вернуть ключи, необходимые для включения виртуальной машины. Обратите внимание, что ключи шифруются в VBS защищенного узла.
Device Guard: Что это такое и как включить или отключить
К примеру, если хакер взломал и получил доступ к Windows 10, то он мог получить и доступ к хэшу, который используется для шифрования учетных записей, так как хэш храниться в локальной ОЗУ без защиты. В Credential Guard хэш храниться в виртуальном контейнере, и даже, если система будет скомпрометирована, то хакер не получит доступ к этому хэшу.
Ограничение на использование Device Guard
Как включить и отключить Device Guard
В групповых политиках перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Система» > «Device Guard» > справа выберите «Включить средство обеспечения безопасности на основе виртуализации«.
Ошибка несовместимости с Credential Guard сторонних виртуальных машин
Иногда, пользователи могут видеть ошибку «VMware Workstation и устройства Device/Credential Guard несовместимы. VMware Workstation можно запустить после отключения Device/Credential Guard» при использовании сторонних виртуальных машин как VirtualBox или VMware Workstation.
Способ 1. В этом случае нужно отключить несколько компонентов как Aplication Guard, Hyper-V и песочница Windows. Также, посмотрите не включен ли Credential Guard в групповых политиках, указанном выше способом.
Способ 2. Если выше способ не помог и виртуальные машины выдают ошибку на несовместимость Credential Guard, то откройте редактор реестра и перейдите по пути:
Если после перезапуска Windows, ошибка появляется, то запустите командную строку от имени администратора и введите:
Если хотите вернуть команду по умолчанию, то введите bcdedit /set hypervisorlaunchtype auto