Из практики админа 02. BitLocker и ключи восстановления в AD: настроить заранее

Note

Материал сверен с официальной документацией (Microsoft Learn и др.; ссылки — в конце статьи). Статья основана на реальном случае, описанном обезличенно: названия, адреса и значения изменены. Примеры вывода — иллюстрации. Перед работой на боевых системах проверьте шаги на тестовой машине.

В домене были рабочие станции и серверы. Ни одного ключа BitLocker в Active Directory: объектов восстановления в каталоге ноль, а сам BitLocker нигде не включён. Спокойное положение, которое легко потерять. Стоит администратору или пользователю включить шифрование, и пароль восстановления окажется в файле, на бумаге или вовсе нигде, а диск без него — набор шифртекста. Поэтому мы решили сначала настроить сохранение ключей в каталоге, а уже потом разрешать шифрование. В статье вы:

настроите групповую политику, которая сохраняет ключи BitLocker в Active Directory и не даёт включить шифрование без их копии;
найдёте ключ в каталоге и поймёте, кто вправе его читать;
проверите всю цепочку на тестовом диске и узнаете, как сохранить ключ тома, зашифрованного до политики;
разберёте компромисс, который лучше не повторять: автоматическая разблокировка диска скриптом, где ключ лежит рядом с диском.

Что нужно знать заранее

BitLocker — шифрование тома. Защитник ключа (key protector) — способ получить ключ шифрования: TPM (Trusted Platform Module, доверенный платформенный модуль), ПИН-код, пароль, пароль восстановления. Пароль восстановления (recovery password) — 48-значное число, которым открывают том, когда обычный способ не сработал. Ключ восстановления (recovery key) — файл на съёмном носителе. Пакет ключа (key package) — данные для утилиты ремонта повреждённого диска. BitLocker To Go — шифрование съёмных дисков.
AD DS (Active Directory Domain Services) — службы каталога. Эскроу в этой статье — хранение копии ключа в каталоге, а не только у владельца компьютера. GPO (Group Policy Object) — объект групповой политики, GPMC (Group Policy Management Console) — консоль для работы с ним.
Тома делятся на три типа: системный (operating system drive), фиксированные диски данных (fixed data drives) и съёмные (removable drives). Политики настраивают для каждого типа отдельно.
Большинство политик BitLocker срабатывает в момент первого включения шифрования тома, а если настройки изменить позже, шифрование не перезапускается. Если политика не настроена, сведения о восстановлении в AD DS не сохраняются.
Групповые политики и их проверка — Windows Server с нуля 06; BitLocker и ключи в AD кратко — Windows Server с нуля 12, раздел про Defender и шифрование дисков. Порядок «политика, пилот, проверка ключа» в сжатом виде — Безопасность для начинающих 04, раздел 6; здесь подробности: три типа дисков, сквозная проверка, компромисс. Что делать пользователю с запросом ключа — врезка в Поддержка пользователей 03.
Среда: домен lab.example, контроллер DC1, тестовый компьютер PC1 (Windows 11) с пустым вторым диском D:, администратор admin-lab (член Domain Admins). Политика называется CMP-BitLocker-AD-Backup. Команды рассчитаны на Windows PowerShell 5.1 с модулем ActiveDirectory; в русской консоли названия политик переведены, ориентируйтесь на английские.

Симптомы

Это случай без аварии: сбоя нет, есть отсутствие защиты.

Ключей BitLocker в Active Directory нет, BitLocker нигде не включён.
Ничто не мешает его включить: без политики пароль восстановления остаётся на усмотрение владельца компьютера. Документация (и текущая, и архивная) говорит об этом прямо: если политика не настроена, сведения о восстановлении в AD DS не сохраняются, копию хранит сам пользователь, и если он её потерял или ушёл из организации, администратор не может легко получить доступ к диску.

Как проверяли исходное состояние

Шаг 1. Считаем объекты восстановления

Сведения о восстановлении хранятся как дочерние объекты компьютера. Класс называется msFVE-RecoveryInformation, внутри — атрибуты с паролем восстановления, его GUID, GUID тома и (если включено) пакет ключа. В имени объекта есть дата, время и GUID пароля восстановления.

$base = (Get-ADDomain).DistinguishedName
@(Get-ADObject -SearchBase $base `
    -Filter 'objectClass -eq "msFVE-RecoveryInformation"').Count

Пример вывода: 0. Такой же счётчик пригодится потом, чтобы убедиться, что ключи пошли.

Шаг 2. Схема и права

Класс msFVE-RecoveryInformation есть в схеме Active Directory с Windows Server 2008; расширять схему вручную нужно было только для контроллеров Windows Server 2003. У нас схема современная, отдельных шагов не потребовалось. Отдельные права для записи тоже не понадобились: по описанию в архивной документации (Windows 7 и Server 2008 R2) компьютер сохраняет сведения о восстановлении под правами по умолчанию на своём объекте. В архивной таблице прав по умолчанию для SELF (специальный субъект «сам объект», здесь — сам компьютер) указаны Create All Child Objects и Delete All Child Objects; на современных версиях проверьте это на своём объекте. Читать сведения по умолчанию могут только администраторы домена: атрибуты помечены как конфиденциальные.

Шаг 3. Нет ли конфликтующих политик

Если другая GPO уже настраивает те же параметры BitLocker для части компьютеров, итог определяется порядком применения (Windows Server с нуля 06), и наша настройка может не победить. Поэтому до привязки посмотрите результирующие политики на тестовом компьютере: gpresult /h gp.html от имени администратора или Group Policy Results в GPMC.

Что сработало

1. Создаём политику

В GPMC создайте непривязанную GPO CMP-BitLocker-AD-Backup и отключите её пользовательскую часть (пользовательские настройки нам не нужны). Для Windows Server документация другого способа настроить BitLocker, кроме групповой политики, не предлагает. Настройки лежат в Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption:

Тип дисков	Политика	Сохранять в AD DS	«Не включать BitLocker без копии»
Системные	Operating System Drives → Choose how BitLocker-protected operating system drives can be recovered	пароль и пакет ключа	да
Фиксированные диски данных	Fixed Data Drives → Choose how BitLocker-protected fixed drives can be recovered	пароль и пакет ключа	да
Съёмные	Removable Data Drives → Choose how BitLocker-protected removable drives can be recovered	пароль и пакет ключа (см. оговорку ниже)	нет

В каждой политике выбирают Enabled, отмечают Save BitLocker recovery information to Active Directory Domain Services и в списке выбирают Backup recovery password and key package. Пакет ключа нужен для восстановления данных с физически повреждённого диска; вариант Backup recovery password only сохраняет только пароль. Флажок «Do not enable BitLocker until recovery information is stored in AD DS for …» не даёт включить шифрование, пока копия не сохранена, а когда он включён, пароль восстановления создаётся автоматически.

Для съёмных дисков мы копию сохраняем, но не требуем: иначе на компьютере вне домена (или без связи с контроллером) нельзя было бы включить BitLocker To Go. Цена требования на остальных дисках понятна: компьютер, который не видит контроллер (например, ноутбук вне офиса и без VPN), не сможет включить шифрование, пока не вернётся в сеть.

Документация здесь непоследовательна: описание политики предлагает сохранять данные съёмных дисков в AD DS, а обзор восстановления пишет, что автоматического способа для съёмных носителей нет и копию делают вручную (manage-bde -protectors -adbackup, Backup-BitLockerKeyProtector). Проверьте на тестовой машине в домене: включите BitLocker To Go на тестовой флешке и посмотрите, появился ли объект восстановления; если нет, сохраняйте ключ командой.

2. Привязка: пилот, потом корень домена

Warning

Привязка к корню домена затрагивает все компьютеры, включая серверы и контроллеры. Для машин без BitLocker политика в нашем случае оказалась безвредной (практика автора): большинство её настроек применяется только при включении шифрования. Но требование копии ключа всё равно повлияет на всех, кто станет шифровать. Не привязывайте политику сразу к корню. Откат: в GPMC удалите ссылку (Delete Link(s)); сама GPO и уже созданные в AD объекты восстановления останутся.

Привяжите GPO к подразделению с тестовым компьютером PC1.
На PC1 выполните gpupdate /force, затем gpresult /h gp.html и убедитесь, что CMP-BitLocker-AD-Backup в списке применённых, а параметры не перекрыты другой GPO. Мы наблюдали эффект на клиенте после обновления политики или перезагрузки.
Пройдите сквозную проверку из раздела ниже.
Только после этого привяжите GPO к корню домена. В описанном случае итогом стала именно такая привязка: политика действует на все компьютеры, пользовательская часть отключена. Пилотное подразделение перед этим — наша рекомендация для вашей сети.

3. Где смотреть ключ

Для просмотра в консоли нужен инструмент BitLocker Recovery Password Viewer: он входит в средства RSAT (Remote Server Administration Tools) и расширяет оснастку Active Directory Users and Computers (dsa.msc). Откройте свойства компьютера, вкладка BitLocker Recovery. Найти пароль по идентификатору можно командой контекстного меню домена Find BitLocker Recovery Password: нужны первые восемь символов идентификатора, который BitLocker показывает на экране восстановления. По умолчанию доступ к этим сведениям есть только у администраторов домена, но его можно делегировать. Для конфиденциальных атрибутов одного права Read property мало, нужен ещё Control access; Full Control включает его, но даёт лишнее. Делегируйте узкой группе и проверьте делегирование на тестовой учётной записи.

В PowerShell то же можно сделать так (имя без свойства msFVE-RecoveryPassword: пароль не попадёт на экран):

$base = (Get-ADDomain).DistinguishedName
$pc = Get-ADObject -SearchBase $base `
    -Filter 'objectClass -eq "computer" -and name -eq "PC1"'
Get-ADObject -SearchBase $pc.DistinguishedName `
    -Filter 'objectClass -eq "msFVE-RecoveryInformation"' |
    Select-Object Name

Запрос с -Properties 'msFVE-RecoveryPassword' покажет сам пароль. Делайте это только осознанно: вывод может остаться в истории консоли, журнале транскрипции или заявке. Точное имя компонента RSAT с этим инструментом проверьте на своей системе.

4. Сквозная проверка на тестовом ПК

Проверка нужна, чтобы убедиться, что ключ не просто «где-то есть», а совпадает с тем, что на компьютере. Делайте её на тестовой машине и на пустом диске данных, который не жалко: шифрование меняет диск. Для виртуальной машины перед началом сделайте контрольную точку.

Мы включали BitLocker на диске данных (без перезагрузки) с параметрами -RecoveryPasswordProtector, -UsedSpaceOnly и -SkipHardwareTest; в примере добавлен метод шифрования, потому что документация советует указывать его явно (по умолчанию XTS-AES-128):

Enable-BitLocker -MountPoint 'D:' -RecoveryPasswordProtector `
    -UsedSpaceOnly -SkipHardwareTest -EncryptionMethod XtsAes256
$rp = (Get-BitLockerVolume -MountPoint 'D:').KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
Backup-BitLockerKeyProtector -MountPoint 'D:' `
    -KeyProtectorId $rp.KeyProtectorId

Параметр -RecoveryPasswordProtector создаёт случайный пароль восстановления, -UsedSpaceOnly шифрует только занятое место (быстрее, но незанятое пространство тома остаётся нешифрованным), -SkipHardwareTest пропускает пробный запуск. Последняя команда явно сохраняет защитник в AD: в тесте это снимает сомнения (при включённой политике успешное сохранение — условие включения шифрования).

Дальше сравниваем. На компьютере идентификатор и пароль защитника показывает (Get-BitLockerVolume -MountPoint 'D:').KeyProtector | Format-Table KeyProtectorId, RecoveryPassword, а в AD идентификатор входит в имя объекта восстановления, пароль виден на вкладке BitLocker Recovery. Мы сверили идентификатор и пароль, и они совпали. Реальные ключи не копируйте в заявки, чаты и статьи.

По желанию проверьте и сам ключ. По документации тома данных блокируются при выключении и перезапуске системы, если не настроена авторазблокировка; после перезагрузки откройте тестовый том паролем из AD (Unlock-BitLocker -MountPoint D -RecoveryPassword ...).

Откат теста: Disable-BitLocker -MountPoint 'D:' расшифрует диск и удалит защитники. Объекты восстановления в AD при этом остаются: каталог хранит историю паролей, пока не удалён объект компьютера.

5. Тома, зашифрованные до политики

Политика действует при включении шифрования и ключи уже зашифрованных томов в каталог не отправляет. Исправляется командой для каждого тома (идентификатор защитника в фигурных скобках берут из вывода -get, в PowerShell его заключают в кавычки):

manage-bde -protectors -get C:
manage-bde -protectors -adbackup C: -id '{ID}'

Тот же результат даёт Backup-BitLockerKeyProtector -MountPoint 'C:' -KeyProtectorId '{ID}', скобки обязательны. Чтобы найти компьютеры, у которых в каталоге уже есть сведения о восстановлении, перечислите владельцев объектов (пароли не запрашиваются) и сравните со своим списком зашифрованных машин:

$base = (Get-ADDomain).DistinguishedName
Get-ADObject -SearchBase $base `
    -Filter 'objectClass -eq "msFVE-RecoveryInformation"' |
    ForEach-Object { ($_.DistinguishedName -split ',', 2)[1] } |
    Sort-Object -Unique

Компромисс, который мы не рекомендуем: ключ рядом с диском

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

Это ослабляет защиту. Пароль восстановления лежит на незашифрованном системном диске, то есть рядом с защищаемым диском, в открытом виде. Кто получил компьютер целиком (украденный ноутбук, снятый образ, резервная копия файла), получил и ключ. BitLocker остаётся лишь защитой от кражи одного диска данных. Права на файл эту проблему не снимают: они действуют, пока работает операционная система. Кроме того, пароль в командной строке виден в списке процессов и может остаться в журналах создания процессов, если в них включена командная строка (практика автора; соответствующую политику аудита в этой статье мы не перепроверяли). Если пароль всё же приходится писать в скрипт, принятый риск стоит зафиксировать письменно, а не считать его снятым (практика автора).

Документированная альтернатива другая. Автоматическая разблокировка (Enable-BitLockerAutoUnlock -MountPoint 'D:') устроена так: после того как пользователь разблокирует системный том, BitLocker берёт зашифрованные данные из реестра и метаданных тома и открывает тома данных. Для фиксированных дисков она требует, чтобы системный диск тоже был защищён BitLocker; если это не так, автоматически разблокировать фиксированный диск нельзя. Значит, правильный путь — защитить системный диск (через TPM) и уже тогда включать авторазблокировку для диска данных. Это отдельный проект со своим пилотом, и он тоже требует заранее настроенного хранения ключей в AD. Если диск настроен только на автоматическую разблокировку, его без нужного окружения откроют ключом восстановления или агентом восстановления данных (DRA, если он настроен), и это ещё один довод хранить копию.

Выводы и чек-лист