BitLocker: шифрование дисков на серверах и хранение ключей в AD

Сервер украли, диск вытащили из corpus и подключили к другой машине для чтения «в обход» — сценарий не такой уж и редкий для филиалов, серверных без должного физического контроля, да и просто для списанного оборудования, которое потом всплывает на вторичном рынке с базой данных на борту. Без шифрования диска всё, что на нём лежит, читается напрямую, стоит только загрузиться с любой livecd. BitLocker закрывает именно эту дыру: даже если диск физически вынесли, без ключа восстановления данные — это просто шум.

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

Разберём, как включить BitLocker на серверах с TPM, настроить хранение ключей в AD через GPO и что делать, если ключ понадобился при инциденте.

Стоит сразу понимать модель угроз, которую закрывает BitLocker, и ту, которую он не закрывает. Он защищает данные, когда диск физически не в руках доверенной системы — украден, вынут для обслуживания, списан на утилизацию. Он не защищает данные от атакующего, который получил доступ к уже загруженной и разблокированной системе через сеть — там работают уже совсем другие механизмы, вроде разграничения прав и Credential Guard. Понимание этой границы помогает не переоценивать BitLocker как «решение всех проблем шифрования» и не путать шифрование диска с шифрованием канала передачи данных.

Шаг 1. Проверяем готовность сервера

Ставим компонент BitLocker (на Server Core он тоже доступен, но без графической консоли управления) и проверяем состояние TPM:

Install-WindowsFeature BitLocker -IncludeManagementTools -Restart

Get-Tpm

Смотрим на поля TpmPresent, TpmReady и TpmEnabled — все три должны быть True. Если TPM не инициализирован, инициализируем:

Initialize-Tpm

Какой метод шифрования выбрать

Enable-BitLocker принимает несколько алгоритмов шифрования, и выбор не всегда очевиден. XTS-AES256 — рекомендуемый по умолчанию режим для современных версий Windows Server, обеспечивающий защиту от манипуляций с зашифрованными секторами (в отличие от старого режима AES-CBC). Единственная причина выбрать AES128 вместо AES256 — заметная экономия ресурсов процессора на очень старом оборудовании без аппаратного ускорения AES-NI, что для современных серверов практически не встречается. Придерживайся XTS-AES256 как безопасного значения по умолчанию, если нет специфичных требований комплаенса, предписывающих иное.

Шаг 2. Расширяем схему AD и готовим права на хранение ключей

Начиная с Windows Server 2008 R2 объекты схемы для хранения ключей BitLocker уже есть в стандартной схеме AD, но нужно убедиться, что права на запись выданы правильно. Проверяем наличие атрибута msFVE-RecoveryInformation:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-FVE-RecoveryInformation"}

Если атрибута нет (актуально для очень старых лесов, не обновлявшихся со времён Windows Server 2003), нужно обновить схему AD с правами Schema Admins и дополнительно выполнить скрипт Add-TPMSelfWriteACE.vbs из состава Remote Server Administration Tools — он выдаёт компьютерам домена право самим записывать свои ключи восстановления в собственный объект в AD, без чего запись ключа будет падать с ошибкой доступа даже при формально верной схеме.

Проверить, что право self-write на атрибут уже выдано на конкретной OU, можно так:

dsacls "OU=Tier1-Servers,OU=Tier1,DC=itpages,DC=lab,DC=local" | Select-String "SELF"

Шаг 3. Настраиваем GPO для автоматического резервного копирования ключей

Создаём GPO «BitLocker-Server-Config» в Group Policy Management, привязываем к OU с серверами (например, Tier1-Servers), и идём в Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives.

Включаем политику «Choose how BitLocker-protected operating system drives can be recovered» со следующими параметрами:

• Allow data recovery agent — включено;
• Save BitLocker recovery information to AD DS — включено, для пароля восстановления и пакета ключей;
• Do not enable BitLocker until recovery information is stored in AD DS for operating system drives — включено. Это критично: без этой опции шифрование может начаться раньше, чем ключ уйдёт в AD, и при сбое связи с контроллером домена ключ просто потеряется.

Дополнительно включаем политику «Require additional authentication at startup» и разрешаем использование TPM без ввода PIN на серверах (для рабочих станций рекомендуется обратное — TPM + PIN), поскольку серверы обычно перезагружаются без физического присутствия администратора.

Шаг 4. Включаем шифрование на сервере

После применения GPO (gpupdate /force и перезагрузка для верности) включаем BitLocker на системном томе srv-fs01:

Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 `
    -TpmProtector

Enable-BitLocker -MountPoint "C:" -RecoveryPasswordProtector

$BLV = Get-BitLockerVolume -MountPoint "C:"
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId `
    ($BLV.KeyProtector | Where-Object {$_.KeyProtectorType -eq "RecoveryPassword"}).KeyProtectorId

Команда Backup-BitLockerKeyProtector явно отправляет пароль восстановления в объект компьютера в AD — даже при включённой GPO стоит выполнить её вручную сразу после включения шифрования и не полагаться только на фоновую синхронизацию.

Для дополнительных томов данных (например, диска E: с базами) используем защитник на основе пароля или ключ, разблокируемый автоматически после разблокировки системного тома:

Enable-BitLocker -MountPoint "E:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector
Enable-BitLockerAutoUnlock -MountPoint "E:"

Шаг 5. Проверяем, что ключ действительно попал в AD

Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} `
    -SearchBase "CN=SRV-FS01,OU=Tier1-Servers,OU=Tier1,DC=itpages,DC=lab,DC=local" `
    -Properties msFVE-RecoveryPassword, msFVE-RecoveryGuid |
    Select-Object Name, msFVE-RecoveryPassword

Если объект найден и в нём есть значение пароля восстановления — цепочка настроена верно. Это же место понадобится, если ключ нужно достать при реальном инциденте: через оснастку Active Directory Users and Computers (с включённым отображением вкладки BitLocker Recovery) или той же командой PowerShell, доступной только членам делегированной группы восстановления.

Особенности шифрования кластерных и виртуальных дисков

Если srv-fs01 входит в отказоустойчивый кластер или использует общие тома (Cluster Shared Volumes), обычная последовательность команд Enable-BitLocker потребует дополнительной настройки — том должен быть переведён в режим обслуживания перед включением шифрования, а после завершения операции возвращён в кластер:

Suspend-ClusterResource -Name "Cluster Disk 1"
Enable-BitLocker -MountPoint "E:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector
Resume-ClusterResource -Name "Cluster Disk 1"

Для кластерных дисков также стоит использовать защитник на основе Active Directory Domain Services вместо только TPM, чтобы разблокировка не зависела от того, на каком именно узле кластера в данный момент активен диск. Это отдельная настройка, которую стоит проверить на тестовом кластере до применения на боевых нодах — поведение при переключении узлов (failover) на зашифрованных томах не всегда очевидно и заслуживает отдельного тестового цикла перед продакшеном.

Шаг 6. Мониторим статус шифрования

Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionPercentage, ProtectionStatus

Статус ProtectionStatus On и EncryptionPercentage 100 означает, что том полностью зашифрован и защита активна. Такую проверку стоит вынести в отдельный периодический скрипт мониторинга по всем серверам домена — например, через задачу, собирающую данные с серверов в централизованный отчёт.

Шаг 7. Делегируем право восстановления узкой группе

По умолчанию читать пароли восстановления BitLocker из AD может любой администратор домена — а это, как мы уже разбирали в статье про модель Tier 0/1/2, слишком широкий круг. Делегируем право чтения атрибута msFVE-RecoveryPassword отдельной группе восстановления, не пересекающейся с общими администраторами:

New-ADGroup -Name "Tier0-BitLocker-Recovery" -GroupScope Global -GroupCategory Security `
    -Path "OU=Tier0-Admins,OU=Tier0,DC=itpages,DC=lab,DC=local"

dsacls "OU=Tier1-Servers,OU=Tier1,DC=itpages,DC=lab,DC=local" /I:S `
    /G "ITPAGES\Tier0-BitLocker-Recovery:RP;msFVE-RecoveryPassword"

После этого доступ к ключам восстановления получают только члены явно назначенной группы, а любая попытка чтения атрибута логируется как обращение к защищённому объекту, если на нём настроен SACL через расширенный аудит.

Шаг 8. Восстанавливаем доступ при реальном инциденте

Рано или поздно кто-то из команды столкнётся с экраном восстановления BitLocker — например, после неудачного обновления BIOS, замены материнской платы или срабатывания защиты при обнаружении подозрительного изменения загрузочной конфигурации. Порядок действий должен быть заранее известен всей команде, а не изобретаться на ходу в стрессовой ситуации.

Первым делом определяем идентификатор запрошенного ключа (Recovery Key ID), который система показывает на экране восстановления, и ищем по нему нужный пароль в AD:

$computer = Get-ADComputer -Identity "srv-fs01"
Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} `
    -SearchBase $computer.DistinguishedName `
    -Properties msFVE-RecoveryPassword, msFVE-RecoveryGuid |
    Where-Object { $_.Name -match "<RecoveryKeyIdFromScreen>" } |
    Select-Object msFVE-RecoveryPassword

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

Частые ошибки и как их избежать

• Ключ включён до того, как настроено сохранение в AD. Без флага «Do not enable BitLocker until recovery information is stored» сервер может уйти в шифрование, а единственная копия ключа останется только локально — и потеряется при сбое диска. Всегда проверяй Get-ADObject сразу после Enable-BitLocker, не откладывая на потом.
• Права на чтение ключей восстановления выданы слишком широко. Делегирование права читать msFVE-RecoveryPassword должно доставаться отдельной узкой группе (например, Tier0-BitLocker-Recovery), а не всем администраторам домена — это конфиденциальная информация, дающая полный доступ к данным сервера.
• TPM не прошёл Clear после смены материнской платы или прошивки. После аппаратных изменений TPM может перейти в состояние, требующее ручной очистки и повторной инициализации, иначе Enable-BitLocker будет падать с ошибкой — проверяй Get-Tpm перед каждым таким обслуживанием.
• Забыли, что виртуальные машины требуют другого подхода. На виртуальных серверах без физического TPM (или без включённого vTPM в настройках гипервизора) BitLocker либо не включится вообще, либо потребует защитник на основе пароля вместо TPM, что менее удобно и требует отдельного хранения пароля запуска. Проверяй наличие vTPM в свойствах виртуальной машины до попытки включить шифрование.

Автор — Команда IT-Pages