¿Qué es el control BitLocker AD para la recuperación?
El control BitLocker AD para la recuperación relaciona tres pruebas independientes: la política aplicable a un equipo, la protección realmente presente en cada volumen y la información de recuperación almacenada en los servicios de dominio de Active Directory (AD DS) para su protector de recuperación actual. Un hallazgo sobre la política inicia esta investigación; no puede responder a las tres preguntas.
La unidad útil de revisión es un equipo identificado y un volumen identificado, en un momento registrado. Una configuración para todo el dominio, una unidad cifrada localmente y un objeto antiguo de recuperación en el directorio pueden existir a la vez mientras la vía de recuperación prevista sigue sin verificarse. Registre estas observaciones por separado antes de decidir qué debe corregirse.
Nuestro artículo sobre la higiene de los objetos de equipo, incluidos BitLocker y el depósito de información de recuperación sitúa este trabajo en la revisión más amplia del ciclo de vida de los equipos. Aquí, la tarea es más concreta: establecer si el registro de recuperación corresponde al protector que está presente actualmente en el volumen. No deduzca el estado de cifrado de la presencia o ausencia de un objeto en el directorio.
Cómo funciona: política, estado del volumen y depósito de información de recuperación
Establecer la vía de administración y el alcance de los volúmenes
Anote qué volúmenes del sistema operativo, de datos fijos y extraíbles están dentro del alcance, a qué equipos pertenecen y si su configuración procede de GPO o CSP. Indique explícitamente los volúmenes excluidos; comprobar solo la unidad del sistema operativo no permite dar por cumplido un requisito que abarca las unidades de datos.
La referencia de configuración de BitLocker de Microsoft identifica ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption como una política CSP e indica Not available para su equivalente GPO. Esto no significa que BitLocker no tenga ajustes GPO. Los ajustes de recuperación de las unidades del sistema operativo y de datos fijos ofrecen una copia de seguridad en AD DS y una opción que impide la activación hasta que esa copia se complete correctamente. Windows Server utiliza GPO en lugar de CSP para configurar BitLocker.
Para un destino administrado por GPO, recopile pruebas del conjunto resultante de directivas con alcance de equipo utilizando la sintaxis de gpresult documentada por Microsoft:
gpresult /scope computer /z
Revise los ajustes de recuperación pertinentes y las políticas que prevalecen. Para los clientes administrados por CSP, obtenga la asignación correspondiente y los resultados de políticas del dispositivo desde el sistema de administración. Un informe GPO no demuestra la aplicación de CSP. Resuelva los desacuerdos de la administración mixta antes de describir la política prevista como efectiva. La misma distinción entre un valor recopilado y la protección del destino aparece en nuestros cuatro controles de seguridad GPO y su verificación en el destino.
Tener en cuenta el historial del volumen
Las preguntas frecuentes de BitLocker de Microsoft explican que la información de recuperación de una unidad cifrada antes de que se aplicara la política de copia de seguridad no se carga automáticamente en AD DS cuando el equipo se une al dominio o recibe después esa política. AD DS también conserva entradas antiguas de contraseñas de recuperación. Un evento pasado de copia de seguridad correcta puede perdurar más que el registro del directorio o el protector que lo hacía útil.
Pregunte cuándo comenzó el cifrado, cuándo comenzaron la pertenencia al dominio y la política de recuperación, y si los protectores han cambiado. Estas respuestas determinan dónde buscar una carencia. Ni un despliegue reciente de políticas ni la marca de tiempo más reciente del directorio sustituyen la correspondencia con el protector actual. Cuando el historial no esté disponible, regístrelo como desconocido y realice las comprobaciones directas siguientes.
Detección: recopilar tres pruebas independientes
Paso 1: medir el cifrado y la protección de cada volumen
Ejecute localmente el comando de estado de manage-bde documentado para la unidad seleccionada:
manage-bde -status C:
Registre el estado de conversión, el porcentaje de cifrado, el método de cifrado, el estado de protección y el estado de bloqueo. El progreso del cifrado y la protección activa son campos separados; un volumen cifrado con la protección desactivada requiere un seguimiento distinto al de un volumen totalmente descifrado. Un comando que falla no puede aportar ninguna de estas observaciones.
PowerShell ofrece el cmdlet documentado Get-BitLockerVolume. Este ejemplo restringe las propiedades mostradas mediante Select-Object:
Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop |
Select-Object MountPoint,VolumeType,VolumeStatus,EncryptionPercentage,EncryptionMethod,ProtectionStatus,LockStatus
Repita el proceso para cada volumen seleccionado. Guarde la identidad del equipo, el punto de montaje, la marca de tiempo y el resultado de la recopilación junto con el resultado, de modo que un revisor posterior pueda reproducir el alcance. No convierta un equipo inaccesible en un equipo sin cifrar en el informe.
Paso 2: identificar los protectores de recuperación actuales sin mostrar secretos
La referencia de Backup-BitLockerKeyProtector documenta la matriz KeyProtector, KeyProtectorId y KeyProtectorType. Utilice esas propiedades para identificar los protectores de contraseña de recuperación, en lugar de suponer una posición fija en la matriz:
(Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop).KeyProtector |
Select-Object KeyProtectorType,KeyProtectorId
Esta proyección muestra identificadores y tipos, no la contraseña de recuperación. Registre todos los protectores actuales de contraseña de recuperación del volumen seleccionado; puede haber más de uno. Un protector TPM no es el identificador de contraseña de recuperación que debe relacionarse con AD DS. Si falta el protector de contraseña de recuperación esperado, clasifique explícitamente esa observación en vez de elegir otro tipo de protector para que la tabla parezca completa.
Paso 3: leer los metadatos de recuperación AD DS del equipo correcto
Microsoft documenta la clase msFVE-RecoveryInformation como información de recuperación asociada a un equipo, y msFVE-RecoveryGuid como el GUID asociado a una contraseña de recuperación. El ObjectGUID del propio objeto del directorio es un identificador diferente.
Utilice el módulo ActiveDirectory desde una estación de administración autorizada. La siguiente consulta acotada utiliza los parámetros de Get-ADObject de Microsoft. Sustituya el DN del equipo y el DC por los valores verificados. Solicita metadatos de recuperación sin solicitar msFVE-RecoveryPassword ni todas las propiedades:
Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'CN=PC01,OU=Workstations,DC=contoso,DC=com' -SearchScope OneLevel -Server 'dc01.contoso.com' -Properties whenCreated,msFVE-RecoveryGuid,msFVE-VolumeGuid -ErrorAction Stop |
Select-Object DistinguishedName,whenCreated,'msFVE-RecoveryGuid','msFVE-VolumeGuid'
Los atributos GUID devueltos pueden ser matrices de bytes. Para un objeto de recuperación devuelto, el constructor .NET Guid a partir de una matriz de bytes documentado proporciona un valor legible para la comparación. Asigne un objeto devuelto a $recoveryObject antes de evaluar esta expresión:
[guid]::new([byte[]]$recoveryObject.'msFVE-RecoveryGuid')
Compare ese GUID completo con el identificador del protector actual de contraseña de recuperación, ignorando las llaves de formato y las diferencias entre mayúsculas y minúsculas. Utilice la asociación con el equipo y el volumen como contexto adicional; no establezca la correspondencia solo por la fecha de creación. Trate los atributos ausentes o mal formados como pruebas incompletas. El esquema hace que msFVE-VolumeGuid sea opcional, por lo que la ausencia de ese atributo por sí sola no demuestra un fallo de la copia de seguridad de la contraseña de recuperación.
El acceso al directorio forma parte de la medición. Una consulta correcta pero vacía realizada con una cuenta que no puede ver los objetos pertinentes no es un resultado fiable de ausencia. Verifique el DN, los permisos y el DC elegido, e investigue las incertidumbres sobre replicación o visibilidad antes de concluir que no existe una entrada correspondiente. La correspondencia de metadatos sigue sin demostrar que el operador de recuperación autorizado pueda obtener y utilizar el secreto.
Paso 4: conservar las incógnitas en la matriz de pruebas
Utilice lo siguiente como plantilla de informe, no como resultados medidos:
| Prueba | Observada | No observada tras una comprobación válida | Recopilación fallida o incompleta |
|---|---|---|---|
| Política aplicable | El resultado de políticas del destino identifica ajustes, vía de administración y alcance | Falta el ajuste esperado en una revisión completa del destino | Informe de políticas no disponible, asignación sin resolver o alcance incierto |
| Protección del volumen | El estado local registra el cifrado y la protección del volumen identificado | Falta el estado cifrado/protegido esperado | Equipo inaccesible, acceso denegado o comando fallido |
| Protector de recuperación actual | Tipo de contraseña de recuperación e identificador completo registrados | Falta el protector esperado en una enumeración completa | Enumeración de protectores fallida |
| Entrada AD DS correspondiente | El GUID de recuperación coincide con el protector actual bajo el equipo correcto | Ninguna entrada coincidente en una consulta con visibilidad verificada | Consulta fallida, visibilidad sin verificar o atributos ilegibles |
| Ejercicio de recuperación | Un ejercicio aprobado utilizó correctamente la vía de recuperación prevista | Ejercicio completado, pero la vía prevista falló | Ejercicio no realizado o interrumpido |
Mantenga diferenciadas la no observación, la recopilación fallida y una prueba no realizada. Una fila puede estar observada mientras otra sigue sin resolverse. Informe de cada discrepancia con las pruebas necesarias para cerrarla, en lugar de reducir las filas a un único indicador de cumplimiento.
Corrección: alinear política, protectores actuales y recuperación (Remediation)
Paso 1: corregir la política prevista para nuevas activaciones
Confirme primero la vía de administración y cada clase de unidad. Para las políticas de recuperación AD DS aplicables, seleccione la copia de seguridad de la información de recuperación requerida y la opción que bloquea la activación hasta que el almacenamiento en AD DS se complete correctamente. Revise por separado los ajustes del sistema operativo y de datos fijos. Estas opciones están documentadas en la referencia de configuración anterior; no son una versión GPO que sustituya a RequireDeviceEncryption.
Pruebe la configuración en un despliegue piloto, compruebe los resultados de políticas del destino y conserve cualquier fallo del despliegue. Microsoft señala que muchas políticas BitLocker se aplican en la activación inicial y que los cambios de políticas no reinician el cifrado. Por tanto, los volúmenes ya cifrados necesitan la conciliación directa siguiente.
Paso 2: hacer una copia de seguridad de un protector de recuperación actual existente
En un volumen ya cifrado, identifique primero el protector de contraseña de recuperación por tipo e identificador. Resuelva la conectividad con el dominio y los permisos de copia de seguridad, y utilice después la operación manage-bde de copia de seguridad de protectores en AD DS documentada:
manage-bde -protectors -adbackup C: -id "{CURRENT-RECOVERY-PROTECTOR-GUID}"
Las llaves contienen un marcador que debe sustituirse por el GUID completo real del protector, no una contraseña. El parámetro -id es obligatorio. Esta operación copia la información de recuperación seleccionada; no cifra una unidad sin cifrar ni crea un protector ausente. Si no existe un protector adecuado, utilice el procedimiento de aprovisionamiento aprobado por la organización antes de intentar la copia de seguridad.
Después de la copia, repita la consulta acotada a AD DS y vuelva a comparar el identificador. Conserve las entradas antiguas según la política de datos de recuperación de la organización; no las elimine simplemente porque sean más antiguas. Una respuesta correcta del comando debe ir seguida de una correspondencia observada de forma independiente en el directorio. Si sigue faltando, deje sin resolver el punto relativo al depósito de recuperación e investigue el fallo concreto.
Paso 3: ejercitar la recuperación en condiciones controladas
Utilice el proceso de recuperación BitLocker de Microsoft para definir el acceso del operador y la obtención de la información. Su procedimiento AD DS utiliza RSAT BitLocker Recovery Password Viewer en Active Directory Users and Computers; el acceso a la recuperación corresponde por defecto a Domain Administrators y puede delegarse. El visor puede buscar por el identificador de contraseña mostrado.
Planifique un dispositivo de prueba representativo o una ventana de mantenimiento aprobada, un operador responsable, una ruta de recuperación y un plan de reversión. Confirme el equipo, el volumen y el identificador de recuperación mostrado antes de obtener el secreto correspondiente. Transfiéralo únicamente mediante el canal de recuperación aprobado. No provoque la recuperación en sistemas de producción simplemente para rellenar un campo de auditoría.
Registre si el operador previsto obtuvo la información correspondiente y si esta desbloqueó el volumen previsto. Mantenga la contraseña fuera del registro de pruebas. Tras su uso, siga el procedimiento de rotación de contraseñas de recuperación de la organización, verifique cualquier protector sustituto y su nueva correspondencia en el depósito, y vuelva a comprobar el estado de protección. Un ejercicio limitado a obtener la información debe etiquetarse como obtención verificada; no es una prueba de desbloqueo.
Cómo detecta EtcSec esta situación
La implementación revisada de etc-collector expone BITLOCKER_NOT_REQUIRED como un hallazgo de severidad Low. Su Detect() lee BitLockerRequired mediante FindRegistrySettingInt: un valor ausente o cualquier valor distinto de 1 da Count 1; un valor de 1 da Count 0. Ese recuento es el resultado de una comprobación, no el número de equipos sin cifrar.
La función auxiliar devuelve el primer valor disponible de Default Domain Controllers Policy, después de Default Domain Policy y después de otra política recopilada. No calcula la política efectiva por equipo, incluidas la precedencia de vínculos, el filtrado y la herencia. Un valor aceptado de una política no puede demostrar la cobertura del parque.
El proveedor SMB lee GptTmpl.inf y Machine/Registry.pol. El analizador Registry.pol asigna BitLockerRequired solo cuando la clave contiene fve y el valor es un DWORD llamado requiredeviceencryption. La distinción CSP/GPO de Microsoft explicada arriba significa que esta asignación no puede demostrar un requisito general de cifrado mediante GPO. Los archivos ausentes o no leídos tampoco prueban la ausencia de una política aplicada.
Este Detect() no recopila ningún estado de cifrado de volumen, protector de recuperación actual, registro de recuperación AD DS correspondiente ni resultado de prueba de recuperación. Matice tanto los resultados positivos como los de recuento cero con la matriz de pruebas independiente. Cierre la tarea de verificación únicamente cuando se hayan tenido en cuenta los volúmenes identificados, los protectores actuales y la vía de recuperación prevista, con responsables explícitos para las incógnitas restantes.
Explore las páginas de identidad que apoyan este tema