Claves de recuperación de BitLocker: custodia y rotación

BitLocker solo protege los datos mientras la clave de recuperación esté a la vez disponible para las personas adecuadas y fuera del alcance de todas las demás. Las organizaciones suelen acertar solo en una mitad: las claves están custodiadas pero las pueden leer cientos de administradores, o el acceso está bien restringido pero una cuarta parte del parque no tiene ninguna clave custodiada y la primera actualización de firmware fallida se convierte en un incidente de pérdida de datos.

El pilar de endurecimiento de BitLocker cubre la directiva de cifrado en sí, incluida la opción de GPO que bloquea el cifrado hasta que se ha hecho la copia de seguridad de la clave. Esta guía cubre la vida de la clave a partir de ahí: dónde reside, cómo demostrar que cada dispositivo tiene una, quién puede leerla, cómo se auditan las lecturas y cómo se rotan las claves. El tema BitLocker y seguridad del arranque enumera el resto de la serie.

Dónde residen las claves

Microsoft BitLocker Administration and Monitoring (MBAM), parte de MDOP, ha llegado al final del soporte extendido; si todavía lo usa, migre a la administración de BitLocker de Configuration Manager o a Intune en lugar de prolongarlo.

Cada volumen puede tener varios protectores de contraseña de recuperación a lo largo del tiempo. El identificador del protector de clave que aparece en la pantalla de recuperación («Recovery key ID»; los 8 primeros caracteres bastan para buscar) identifica cuál necesita el usuario.

Paso 1: demostrar que cada dispositivo tiene una clave custodiada

La opción del pilar «Do not enable BitLocker until recovery information is stored» protege los cifrados nuevos. No cubre los dispositivos cifrados antes, los que se cifraron automáticamente antes de aplicarse la directiva ni las claves perdidas al recrear un objeto de equipo. Mida la cobertura.

En el dispositivo, compare los protectores locales con lo que contiene el directorio:

(Get-BitLockerVolume -MountPoint C:).KeyProtector |
  Where-Object KeyProtectorType -eq 'RecoveryPassword' |
  Select-Object KeyProtectorId

En Active Directory, enumere los equipos que tienen al menos un objeto de recuperación:

$withKeys = Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  ForEach-Object { ($_.DistinguishedName -split ',',2)[1] } | Sort-Object -Unique
Get-ADComputer -Filter * -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  Where-Object { $_.DistinguishedName -notin $withKeys } |
  Select-Object Name

Ejecútelo con una cuenta que pueda leer los objetos de recuperación; de lo contrario, todos los equipos parecerán desprotegidos. Para Entra ID, enumere los metadatos de las claves (no las claves) con Microsoft Graph PowerShell y compare los valores de DeviceId con su inventario de dispositivos de Intune:

Connect-MgGraph -Scopes 'BitLockerKey.ReadBasic.All'
Get-MgInformationProtectionBitlockerRecoveryKey -All |
  Select-Object Id, DeviceId, CreatedDateTime, VolumeType

El informe de cifrado de Intune también muestra el estado de cifrado por dispositivo. Para las lagunas, haga la copia de seguridad del protector existente con Backup-BitLockerKeyProtector (AD) o BackupToAAD-BitLockerKeyProtector (Entra ID), como se muestra en el pilar, mediante un script de corrección. El registro de eventos Microsoft > Windows > BitLocker-API > Management del dispositivo registra cada intento de copia de seguridad y su resultado; alerte sobre los errores.

Paso 2: restringir quién puede leer las claves en Active Directory

msFVE-RecoveryPassword es un atributo confidencial: para leerlo hace falta el derecho Control Access sobre el atributo, además del permiso de lectura normal. Por defecto, eso significa los Domain Admins y cualquiera con Control total sobre los objetos de equipo, lo que en muchos dominios incluye cuentas de servicio y grupos de soporte con delegaciones excesivas.

1. Cree un grupo como BitLocker-Recovery-Readers para las personas que realmente realizan recuperaciones.
2. Delegue a ese grupo el acceso de lectura a los objetos de recuperación de las OU de puestos de trabajo:

dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:RP;;msFVE-RecoveryInformation"
dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:CA;msFVE-RecoveryPassword;msFVE-RecoveryInformation"

3. Revise quién más tiene Control total o All extended rights sobre esas OU y objetos de equipo, y retírelo donde no sea necesario. Aquí se aplica la misma revisión que hizo para los lectores de contraseñas de Windows LAPS, y a menudo ambos grupos son las mismas personas.

Pruebe primero la delegación en un laboratorio. Instale la característica RSAT BitLocker Recovery Password Viewer en los puestos de administración del soporte técnico; añade una pestaña BitLocker Recovery a los objetos de equipo y una búsqueda por identificador de clave.

Paso 3: restringir quién puede leer las claves en Entra ID

En Entra ID, leer la clave en sí requiere el permiso microsoft.directory/bitlockerKeys/key/read. Varios roles integrados lo incluyen, entre ellos Cloud Device Administrator, Helpdesk Administrator, Intune Administrator y Security Administrator; consulte la referencia de roles actual antes de asignarlos. Recomendaciones:

• Asigne uno de estos roles, o un rol personalizado con solo el permiso de clave de BitLocker, al equipo de recuperación, y hágalo elegible mediante Privileged Identity Management en lugar de permanente.
• Limite el acceso del soporte con unidades administrativas donde su licencia lo permita.
• Decida sobre el autoservicio de los usuarios. Por defecto, el propietario registrado de un dispositivo puede ver su clave de recuperación en el portal de su cuenta. En los dispositivos de la empresa puede desactivarlo en Entra admin center > Devices > Device settings con la opción que impide a los usuarios no administradores recuperar las claves de BitLocker de sus propios dispositivos.
• Para la automatización, use BitLockerKey.ReadBasic.All (solo metadatos) siempre que sea posible; conceda BitLockerKey.Read.All únicamente a la herramienta que deba leer claves.

Paso 4: auditar cada lectura de clave

Active Directory. En los controladores de dominio, habilite Audit Directory Service Access (Success) en Advanced Audit Policy Configuration > Audit Policies > DS Access y añada una SACL en las OU de puestos de trabajo: entidad de seguridad Everyone, acierto, Read msFVE-RecoveryPassword, aplicada a los objetos msFVE-RecoveryInformation descendientes. Cada lectura produce entonces un evento 4662 en el DC que la atendió, con la cuenta del sujeto y el GUID de esquema del atributo en el campo Properties. Obtenga el GUID por el que filtrar:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -LDAPFilter '(lDAPDisplayName=msFVE-RecoveryPassword)' -Properties schemaIDGUID |
  ForEach-Object { [guid]$_.schemaIDGUID }

Entra ID. Cada lectura de clave queda registrada en el registro de auditoría de Entra, en la categoría KeyManagement, como Read BitLocker key, con el actor y el dispositivo. Envíe los registros de auditoría a su SIEM y alerte sobre las lecturas fuera del equipo de recuperación, las lecturas masivas y las lecturas realizadas por aplicaciones.

Correlacione las lecturas con los tickets. Una lectura de clave sin el ticket de recuperación correspondiente merece una pregunta.

Paso 5: rotar las claves después de usarlas

Intune (unidos a Entra y unidos de forma híbrida). En su directiva de BitLocker (Endpoint security > Disk encryption, o el catálogo de configuración), establezca Configure Recovery Password Rotation para activar la renovación en los dispositivos unidos a Entra, o en los unidos a Entra y los unidos de forma híbrida (BitLocker CSP ConfigureRecoveryPasswordRotation, valores 1 y 2). Cuando se usa una contraseña de recuperación para desbloquear la unidad del sistema operativo, el dispositivo genera una nueva y la custodia. Para una clave divulgada sin haberse usado, por ejemplo leída por teléfono a la persona equivocada, ejecute la acción de dispositivo BitLocker key rotation desde la página del dispositivo en Intune.

Active Directory. No existe una rotación integrada iniciada por el cliente. Ejecute un script (mediante su herramienta de gestión o una corrección programada) que añada una nueva contraseña de recuperación, la custodie y solo entonces elimine el protector antiguo:

$old = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
$new = Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector -WarningAction SilentlyContinue
$newId = ($new.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $old.KeyProtectorId }).KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $newId
foreach ($p in $old) { Remove-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $p.KeyProtectorId }

Compruebe que la copia de seguridad se ha completado (el cmdlet lanza una excepción si falla) antes de eliminar nada. Los objetos de recuperación antiguos se quedan en AD; no es un problema, porque el protector correspondiente ya no existe en la unidad.

Qué se rompe

• Una delegación demasiado estricta deja al soporte técnico sin poder recuperar un dispositivo a las 7 de la mañana. Mantenga una vía de emergencia documentada a través de los administradores Tier 0.
• Los scripts de limpieza de dispositivos que eliminan objetos de equipo o de dispositivo de Entra obsoletos también eliminan las claves de unidades que quizá sigan en un cajón. Compruebe primero la fecha de la última clave de recuperación y el estado de cifrado, y mantenga habilitada la Papelera de reciclaje de AD.
• Los dispositivos reinstalados reutilizan el nombre pero crean claves nuevas; los usuarios que leen un identificador de clave equivocado pierden tiempo. Forme al soporte para que compruebe siempre el identificador de clave.
• Desactivar el autoservicio en Entra ID aumenta las llamadas al soporte; planifique la plantilla.

Comprobarlo

• Informe de cobertura: ningún dispositivo cifrado sin clave custodiada, ni en AD ni en Entra ID.
• dsacls o la vista Advanced Security de las OU de puestos de trabajo muestran solo los grupos previstos con Control Access sobre msFVE-RecoveryPassword.
• Una lectura de prueba con una cuenta del soporte produce en pocos minutos un evento 4662 o una entrada de auditoría Read BitLocker key de Entra en el SIEM.
• Tras una recuperación de prueba en un dispositivo de Intune, el identificador de clave cambia en Entra ID y la contraseña antigua ya no desbloquea la unidad.

Lista de comprobación

• Todo dispositivo cifrado tiene una clave custodiada en AD DS o Entra ID; lagunas corregidas
• Acceso de lectura de AD a msFVE-RecoveryPassword delegado solo a un grupo dedicado
• Roles de lectura de claves de Entra asignados mediante PIM; autoservicio decidido de forma deliberada
• Lecturas de claves en AD auditadas con 4662; lecturas en Entra enviadas desde el registro de auditoría
• Lecturas correlacionadas con los tickets de recuperación
• Rotación de la contraseña de recuperación habilitada en Intune; rotación por script en los dispositivos solo de AD
• Los procesos de limpieza de dispositivos protegen las claves custodiadas

Las claves de recuperación se necesitan sobre todo tras cambios en la cadena de arranque. La guía de Secure Boot y UEFI explica qué actualizaciones pueden desencadenar una recuperación y cómo prepararse, y la entrada del glosario sobre el TPM explica por qué el TPM solo libera la clave cuando las mediciones coinciden.