Verificar recuperacao BitLocker AD: política, estado e custódia

O que significa verificar recuperacao BitLocker AD?

Verificar recuperacao BitLocker AD liga três provas independentes: a política aplicável a um computador, a proteção realmente presente em cada volume e as informações de recuperação armazenadas nos Active Directory Domain Services (AD DS) para o seu protetor de recuperação atual. Uma constatação sobre a política abre esta investigação; não consegue responder às três perguntas.

A unidade útil de análise é um computador identificado e um volume identificado num momento registado. Uma definição para todo o domínio, uma unidade encriptada localmente e um objeto de recuperação antigo no diretório podem coexistir enquanto o caminho de recuperação pretendido continua por verificar. Registe essas observações separadamente antes de decidir o que necessita de correção.

O nosso artigo sobre higiene de objetos de computador, incluindo BitLocker e custódia de informações de recuperação enquadra este trabalho na análise mais ampla do ciclo de vida dos computadores. Aqui, a tarefa é mais restrita: determinar se o registo de recuperação corresponde ao protetor atualmente presente no volume. Não deduza o estado de encriptação da presença ou ausência de um objeto no diretório.

Como funciona: política, estado do volume e custódia

Determinar o caminho de gestão e o âmbito dos volumes

Registe quais os volumes do sistema operativo, de dados fixos e amovíveis incluídos no âmbito, a que computadores pertencem e se a sua configuração vem de GPO ou CSP. Identifique explicitamente os volumes excluídos; verificar apenas a unidade do sistema operativo não permite concluir uma exigência que abrange unidades de dados.

A referência de configuração do BitLocker da Microsoft identifica ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption como uma política CSP e assinala o seu equivalente GPO como Not available. Isto não significa que o BitLocker não tenha definições GPO. As definições de recuperação para unidades do sistema operativo e de dados fixos permitem cópias de segurança em AD DS e uma opção que impede a ativação até essa cópia ser concluída com sucesso. O Windows Server utiliza GPO, em vez de CSP, para configurar o BitLocker.

Para um alvo gerido por GPO, recolha provas do Conjunto Resultante de Políticas no âmbito do computador utilizando a sintaxe gpresult documentada pela Microsoft:

gpresult /scope computer /z

Analise as definições de recuperação relevantes e as políticas que prevalecem. Para clientes geridos por CSP, obtenha os resultados correspondentes de atribuição e política do dispositivo no sistema de gestão. Um relatório GPO não comprova a aplicação de CSP. Resolva divergências de gestão mista antes de descrever a política pretendida como efetiva. A mesma distinção entre um valor recolhido e a proteção do alvo aparece no nosso artigo sobre quatro verificações de segurança GPO e a sua validação no alvo.

Ter em conta o histórico do volume

As perguntas frequentes sobre BitLocker da Microsoft explicam que as informações de recuperação de uma unidade encriptada antes da aplicação da política de cópia de segurança não são automaticamente enviadas para AD DS quando o computador entra no domínio ou recebe posteriormente essa política. AD DS também conserva entradas antigas de palavras-passe de recuperação. Um evento anterior de cópia de segurança bem-sucedida pode persistir depois de desaparecer o registo do diretório ou o protetor que o tornava útil.

Pergunte quando começou a encriptação, quando começaram a adesão ao domínio e a política de recuperação e se os protetores foram alterados. Estas respostas determinam onde procurar uma lacuna. Nem a implementação recente de uma política nem o carimbo de data/hora mais recente do diretório substitui a correspondência com o protetor atual. Quando o histórico não está disponível, registe-o como desconhecido e execute as verificações diretas abaixo.

Deteção: recolher três provas independentes

Passo 1: medir a encriptação e a proteção em cada volume

Execute localmente o comando de estado manage-bde documentado para a unidade selecionada:

manage-bde -status C:

Registe o estado de conversão, a percentagem de encriptação, o método de encriptação, o estado de proteção e o estado de bloqueio. O progresso de encriptação e a proteção ativa são campos distintos; um volume encriptado com a proteção desligada exige um seguimento diferente de um volume totalmente desencriptado. Um comando que falha não fornece nenhuma dessas observações.

O PowerShell disponibiliza o cmdlet documentado Get-BitLockerVolume. Este exemplo restringe as propriedades apresentadas utilizando Select-Object:

Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop |
    Select-Object MountPoint,VolumeType,VolumeStatus,EncryptionPercentage,EncryptionMethod,ProtectionStatus,LockStatus

Repita para cada volume selecionado. Guarde a identidade do computador, o ponto de montagem, o carimbo de data/hora e o resultado da recolha juntamente com o resultado, para que um revisor posterior consiga reproduzir o âmbito. Não transforme um endpoint inacessível num endpoint não encriptado no relatório.

Passo 2: identificar os protetores de recuperação atuais sem apresentar segredos

A referência de Backup-BitLockerKeyProtector documenta o array KeyProtector, KeyProtectorId e KeyProtectorType. Utilize essas propriedades para identificar protetores de palavra-passe de recuperação, em vez de presumir uma posição fixa no array:

(Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop).KeyProtector |
    Select-Object KeyProtectorType,KeyProtectorId

Esta projeção apresenta identificadores e tipos, não a palavra-passe de recuperação. Registe todos os protetores de palavra-passe de recuperação atuais para o volume selecionado; pode existir mais de um. Um protetor TPM não é o identificador de palavra-passe de recuperação a comparar com AD DS. Se o protetor de palavra-passe de recuperação esperado estiver ausente, classifique explicitamente essa observação, em vez de escolher outro tipo de protetor para fazer a tabela parecer completa.

Passo 3: ler os metadados de recuperação AD DS do computador correto

A Microsoft documenta a classe msFVE-RecoveryInformation como informações de recuperação associadas a um computador e msFVE-RecoveryGuid como o GUID associado a uma palavra-passe de recuperação. O próprio ObjectGUID do objeto do diretório é um identificador diferente.

Utilize o módulo ActiveDirectory a partir de uma estação de administração autorizada. A consulta delimitada seguinte concretiza os parâmetros Get-ADObject da Microsoft. Substitua o DN do computador e o DC pelos valores verificados. A consulta solicita metadados de recuperação sem solicitar msFVE-RecoveryPassword ou todas as propriedades:

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'

Os atributos GUID devolvidos podem ser arrays de bytes. Para um objeto de recuperação devolvido, o construtor .NET Guid para arrays de bytes documentado fornece um valor de comparação legível. Atribua um objeto devolvido a $recoveryObject antes de avaliar esta expressão:

[guid]::new([byte[]]$recoveryObject.'msFVE-RecoveryGuid')

Compare esse GUID completo com o ID do protetor de palavra-passe de recuperação atual, ignorando as chavetas de formatação e as diferenças entre maiúsculas e minúsculas. Utilize a associação ao computador e ao volume como contexto adicional; não estabeleça correspondência apenas pela data de criação. Trate atributos ausentes ou malformados como provas incompletas. O esquema torna msFVE-VolumeGuid opcional, pelo que a ausência desse atributo, por si só, não comprova uma falha na cópia de segurança da palavra-passe de recuperação.

O acesso ao diretório faz parte da medição. Uma consulta vazia bem-sucedida executada com uma conta que não consegue ver os objetos relevantes não é um resultado fiável de ausência. Verifique o DN, as permissões e o DC escolhido e investigue incertezas de replicação ou visibilidade antes de concluir que não existe uma entrada correspondente. A correspondência dos metadados continua sem demonstrar que o operador de recuperação autorizado consegue obter e utilizar o segredo.

Passo 4: preservar as incógnitas na matriz de provas

Utilize o seguinte como modelo de relatório, não como resultados medidos:

Mantenha distintas a não observação, a recolha falhada e um teste não realizado. Uma linha pode estar observada enquanto outra permanece por resolver. Apresente cada discrepância com as provas necessárias para a encerrar, em vez de condensar as linhas num único indicador de conformidade.

Correção: alinhar a política, os protetores atuais e a recuperação (Remediation)

Passo 1: corrigir a política pretendida para novas ativações

Confirme primeiro o caminho de gestão e cada classe de unidade. Para as políticas de recuperação AD DS aplicáveis, selecione a cópia de segurança das informações de recuperação necessárias e a opção que bloqueia a ativação até o armazenamento em AD DS ser bem-sucedido. Analise separadamente as definições do sistema operativo e de dados fixos. Estas opções estão documentadas na referência de configuração acima; não são uma versão GPO substituta de RequireDeviceEncryption.

Teste a configuração num piloto, verifique os resultados da política no alvo e preserve quaisquer falhas de implementação. A Microsoft indica que muitas políticas BitLocker são impostas na ativação inicial e que alterações às políticas não reiniciam a encriptação. Os volumes já encriptados necessitam, portanto, da reconciliação direta abaixo.

Passo 2: fazer uma cópia de segurança de um protetor de recuperação atual existente

Num volume já encriptado, identifique primeiro o protetor de palavra-passe de recuperação pelo tipo e pelo ID. Resolva a conectividade ao domínio e as permissões de cópia de segurança e utilize depois a operação manage-bde de cópia de segurança dos protetores em AD DS documentada:

manage-bde -protectors -adbackup C: -id "{CURRENT-RECOVERY-PROTECTOR-GUID}"

As chavetas contêm um marcador para o GUID completo real do protetor, não uma palavra-passe. O parâmetro -id é obrigatório. Esta operação faz uma cópia de segurança das informações de recuperação selecionadas; não encripta uma unidade não encriptada nem cria um protetor ausente. Se não existir um protetor adequado, utilize o procedimento de aprovisionamento aprovado pela organização antes de tentar a cópia de segurança.

Após a cópia de segurança, repita a consulta AD DS delimitada e compare novamente o ID. Conserve as entradas mais antigas de acordo com a política de dados de recuperação da organização; não as elimine apenas por serem antigas. Uma resposta bem-sucedida do comando deve ser seguida de uma correspondência no diretório observada de forma independente. Se esta continuar ausente, mantenha o item de custódia por resolver e investigue a falha concreta.

Passo 3: exercitar a recuperação em condições controladas

Utilize o processo de recuperação BitLocker da Microsoft para definir o acesso do operador e a obtenção das informações. O procedimento AD DS utiliza o RSAT BitLocker Recovery Password Viewer em Active Directory Users and Computers; o acesso de recuperação é atribuído por predefinição a Domain Administrators e pode ser delegado. O visualizador permite pesquisar pelo ID da palavra-passe apresentado.

Planeie um dispositivo de teste representativo ou uma janela de manutenção aprovada, um operador responsável, uma via de recuperação e um plano de reversão. Confirme o computador, o volume e o ID de recuperação apresentado antes de obter o segredo correspondente. Transfira-o apenas pelo canal de recuperação aprovado. Não provoque a recuperação em sistemas de produção apenas para preencher um campo de auditoria.

Registe se o operador pretendido obteve as informações correspondentes e se estas desbloquearam o volume pretendido. Exclua a palavra-passe do registo de provas. Após a utilização, siga o procedimento de rotação de palavras-passe de recuperação da organização, verifique qualquer protetor de substituição e a sua nova correspondência de custódia e volte a verificar o estado de proteção. Um exercício limitado à obtenção deve ser identificado como obtenção verificada; não é um teste de desbloqueio.

Como a EtcSec deteta isto

A implementação etc-collector analisada apresenta BITLOCKER_NOT_REQUIRED como uma constatação de gravidade Low. O seu Detect() lê BitLockerRequired através de FindRegistrySettingInt: um valor ausente ou qualquer valor diferente de 1 produz Count 1; um valor de 1 produz Count 0. Essa contagem é um resultado de verificação, não o número de computadores não encriptados.

A função auxiliar devolve o primeiro valor disponível da Default Domain Controllers Policy, depois da Default Domain Policy e depois de outra política recolhida. Não calcula a política efetiva por computador, incluindo precedência de ligações, filtragem e herança. Um valor aceite a partir de uma política não consegue comprovar a cobertura do parque.

O fornecedor SMB lê GptTmpl.inf e Machine/Registry.pol. O analisador Registry.pol só mapeia BitLockerRequired quando a chave contém fve e o valor é um DWORD chamado requiredeviceencryption. A distinção CSP/GPO da Microsoft acima significa que este mapeamento não consegue comprovar uma exigência geral de encriptação GPO. Ficheiros ausentes ou não lidos também não provam a ausência de uma política aplicada.

Este Detect() não recolhe o estado de encriptação do volume, o protetor de recuperação atual, o registo de recuperação AD DS correspondente ou o resultado do teste de recuperação. Qualifique tanto os resultados positivos como os de contagem zero com a matriz de provas separada. Conclua a tarefa de verificação apenas quando os volumes identificados, os protetores atuais e a via de recuperação pretendida estiverem contemplados, com responsáveis explícitos para as incógnitas restantes.