PT-BR - Full Disk Encryption Deep Dive: Pre-Boot e Check Point FDE vs BitLocker

jorgeluiznim — Tue, 15 Sep 2026 09:59:21 GMT

Artigo 10 da série Harmony Endpoint Deep Dives · Nota sobre a gestão: o Harmony Endpoint é gerenciado pela nuvem (Infinity Portal / Web Management) na maioria das implantações de hoje. O FDE é configurado em Policy > Data Protection > Full Disk Encryption. Quando um Management Server on-premises se comporta de forma diferente, isso é sinalizado.

Objetivo

Full Disk Encryption é o blade de maior aposta: erre e você deixa dados expostos ou tranca os usuários para fora dos próprios notebooks. Este artigo desmistifica o FDE: os dois engines (Check Point vs BitLocker), o modelo de pre-boot, a Deployment Phase de seis estágios, os algoritmos de criptografia, a criptografia por hardware SED, o gate de compatibilidade de firmware do E89.25 e os caminhos de recuperação que salvam você quando a máquina não dá boot.

Público

[x] Administradores de Endpoint
[x] Engenheiros de Segurança
[x] Iniciantes
[ ] Analistas SOC
[x] Especialistas

Pré-requisitos

Básico de política de Data Protection no console Web Management
Componente FDE instalado via pacote de client (lembre: FDE não pode ser removido durante um upgrade)

O Que o FDE Realmente Faz

O Full Disk Encryption combina duas proteções:

Componente	O que faz
Disk Encryption	Criptografa automática e totalmente todos os volumes e volumes ocultos (arquivos de sistema, temporários, até deletados) em segundo plano, sem perda perceptível de performance. O disco criptografado fica inacessível a pessoas não autorizadas.
Pre-boot Protection	Exige que os usuários se autentiquem antes de o computador dar boot, derrotando ferramentas de bypass de autenticação e mídias de boot alternativas que contornariam a segurança em nível de SO.

Você escolhe um Encryption Engine por grupo de computadores, configurado em Policy > Data Protection > Full Disk Encryption (uma regra Default Policy pré-definida já se aplica a toda a organização):

Check Point Full Disk Encryption: o engine próprio da Check Point
BitLocker Management (Windows): a Check Point gerencia o Microsoft BitLocker via o serviço Windows Check Point BitLocker Management (usa APIs do Windows)
FileVault (macOS): a Check Point gerencia a criptografia Apple FileVault nos clients Mac

A Deployment Phase: da Instalação ao Enforcement

A Deployment Phase é a janela entre instalar um pacote FDE e o Pre-boot efetivamente abrir. Para passar de deployment a enforcement, sete requisitos precisam ser atendidos, e se o client conseguir falar com o servidor e atender aos requisitos, eles são completados automaticamente:

Comunicação client para servidor existe
Client recebe as políticas de FDE e de usuário
Usuários são adquiridos conforme a política
Ao menos uma conta de usuário está configurada
Client envia um arquivo de recovery ao servidor
A System Area é criada e os boot records atualizados (Pre-boot ativado)
O dispositivo atende aos requisitos de client do FDE

O client mostra seis status em ordem na sua Main Page:

Nota: com Check Point FDE os usuários reiniciam duas vezes (uma para subir o Pre-boot antes da criptografia, uma para validar as credenciais). Com BitLocker, reiniciam uma vez na instalação.

O User Acquisition é o passo que as pessoas esquecem: os usuários são adquiridos quando fazem logon no Windows da máquina FDE, e suas contas precisam ter senhas que satisfaçam as regras de senha. O FDE só ativa depois que o número exigido de usuários é adquirido.

Algoritmos de Criptografia & SED

Para o Check Point FDE, a política cloud oferece três algoritmos de criptografia de volume:

Algoritmo	Observações
AES-CBC (256-bit)	Padrão
XTS-AES (256-bit)	Moderno, forte
XTS-AES (128-bit)

Nota: o FDE on-premises antigo oferecia algoritmos legados adicionais (Blowfish, Cast, 3DES). A política cloud atual padroniza na família AES acima.

Por padrão, todos os drives detectados e volumes visíveis são criptografados. Também é possível usar Self-Encrypting Drives (SED), drives padrão OPAL que criptografam e descriptografam em hardware:

Vá em Advanced Settings > Encryption > Allow Self-Encrypting Drives (SED) hardware functionality
Se um sistema e disco compatíveis forem detectados, o FDE usa a criptografia por hardware do disco em vez da criptografia por software
O nome do volume mostra SED na UI do client e na view Computers (detalhes de Full Disk Encryption)

Pre-Boot: Exigido, Condicional ou Bypassado

É no Pre-boot que moram a maioria das dúvidas reais de FDE. A escolha base:

Authenticate user before OS loads (Pre-boot): o padrão seguro
Do not authenticate user before OS loads (Not recommended): desabilita o Pre-boot; a segurança cai abaixo da força da criptografia

Mas raramente você quer um binário rígido. O FDE oferece modelos de bypass temporário e condicional:

Recurso	Comportamento
Allow bypass when connected to LAN	Numa máquina que alcança um servidor Endpoint por Ethernet, o client se autentica com segurança pela rede, sem Pre-boot manual. Cai para Pre-boot manual se a autenticação de rede não for possível. UEFI + Mac suportados
Unlock Pre-boot user on successful OS login	Um usuário trancado no Pre-boot (logons errados) é destravado no próximo logon de SO em LAN
Temporary Pre-boot Bypass (antigo Wake on LAN)	Admin desabilita o Pre-boot temporariamente (on demand, uma vez, semanalmente ou via script), por exemplo para manutenção ou patching

Bypass por script (SCCM / janelas de patch)

:: No seu script (ex.: SCCM), antes de um reboot que precisa pular o Pre-boot:
FDEControl.exe set-wol-on
:: ... o reboot acontece; o Pre-boot é pulado, o script continua ...
FDEControl.exe set-wol-off

Atenção: o script de Temporary Pre-boot Bypass só roda durante a janela configurada nas Temporary Pre-boot Bypass Settings. A janela de bypass é governada por política, não é liberada geral.

Hardening extra disponível: medição de integridade do Pre-boot via TPM, autenticação de dois fatores e um Hardware Hash (derivado de BIOS + CPU) que detecta se o disco foi movido para outro computador.

Smart Pre-boot (E89.05 em diante)

O Smart Pre-boot é a experiência moderna de pre-boot, GA desde o E89.05. Ele adiciona Self-Unlock e Mobile Login com MFA simples pelo smartphone, além de instruções de login mais claras e orientação de Wi-Fi quando o pre-boot precisa de rede para se comunicar com o servidor. Duas limitações documentadas para planejar: autenticação por SmartCard não é suportada no Smart Pre-boot, e o display externo secundário via docking station é experimental e depende de hardware e firmware. A transição do Classic Pre-boot para o Smart Pre-boot pode exigir um restart.

Compatibilidade de Firmware do FDE (E89.25 em diante)

A partir do E89.25, o Check Point FDE suporta apenas dispositivos que dão boot no Windows pelo UEFI boot order padrão. Dispositivos que carregam o Windows Boot Manager diretamente não são suportados até a fabricante fornecer um update de BIOS/UEFI. Isso tem impacto real de deploy, então trate como um gate antes de qualquer rollout do E89.25 em máquinas criptografadas.

Impacto nos dispositivos afetados:

Upgrades de FDE são bloqueados e novas instalações não criptografam o disco.
Uma mensagem de Blade Status notifica funcionalidade limitada e pede o consentimento do administrador para trocar automaticamente a política de Check Point Encryption para BitLocker Management nessas máquinas específicas, até o firmware ficar compatível.
Instalar o FDE em modo FAST_INSTALL ou ATM (isATM=1) pode deixar o dispositivo não inicializável e exigir o procedimento de recuperação por USB do FDE.

Ações requeridas antes de atualizar para o E89.25:

Verifique a compatibilidade dos dispositivos com o BootModeReport.ps1 (sk185123).
Desabilite a hibernação nos dispositivos FDE afetados para evitar corrupção da EFI System Partition durante o processo de Microsoft Secure Boot Update.

Recuperação: Quando a Máquina Não Dá Boot

FDE sem plano de recuperação é passivo. Três ferramentas:

Ferramenta	Uso
Full Recovery com Recovery Media	Dá boot na máquina falha por CD/DVD/USB/REC, autentica com usuário + senha, o disco descriptografa usando as partition keys da Recovery Media
Drive Slaving Utility	Acessar um drive criptografado conectado a outra máquina
Dynamic Mount Utility	Montar um volume criptografado para acesso aos dados

Fluxo da Recovery Media: o client envia os arquivos de recovery ao serviço de gestão uma vez no deployment inicial, o admin cria a mídia de recovery quando necessário, dá boot na máquina falha, autentica, o disco descriptografa e os arquivos são restaurados descriptografados (o SO passa a rodar sem Pre-boot). Depois, o admin precisa reinstalar o FDE naquela máquina.

Para usuários trancados na estrada, o Remote Help oferece recuperação por challenge-response, e o Self-Help Portal permite que usuários do Active Directory redefinam a própria senha.

Trocando de Engine: Check Point FDE e BitLocker

Você pode trocar de engine por política. O client descriptografa com o antigo e recriptografa com o novo:

Check Point FDE para BitLocker: mude a ação de Encryption Engine para Use BitLocker Management, depois Save e Install Policy. O client mostra uma mensagem, o usuário clica Reboot e a descriptografia começa, depois a mensagem aparece de novo e o usuário clica Reboot para iniciar a criptografia do BitLocker.

BitLocker para Check Point FDE: mude para Use Check Point Full Disk Encryption, depois Save e Install. O BitLocker descriptografa, depois o Check Point FDE criptografa, e o usuário clica Lock para o FDE coletar as credenciais.

Boas Práticas

Boa prática: mantenha o padrão AES-CBC 256-bit (ou XTS-AES 256-bit) salvo requisito específico. A política cloud já padroniza na família AES.

Boa prática: confirme que sua política de senhas é aplicável antes do rollout. O User Acquisition trava silenciosamente se as contas não atenderem às regras de senha.

Boa prática: antes de um rollout do E89.25 em máquinas criptografadas, rode o BootModeReport.ps1 (sk185123) para pegar dispositivos com firmware incompatível, e desabilite a hibernação nos dispositivos FDE afetados.

Boa prática: teste o fluxo de Full Recovery (e guarde a mídia de recovery com segurança) antes de precisar. A recuperação é a diferença entre um reimage e um incidente de perda de dados.

Boa prática: para automação de patch em frotas criptografadas, use o Temporary Pre-boot Bypass por script dentro de uma janela definida por política, em vez de desabilitar o Pre-boot de vez.

Erros Comuns

Erro	Impacto	Solução
Desabilitar o Pre-boot por "conveniência"	Segurança cai abaixo da força da criptografia	Use LAN bypass / SSO em vez de desligar o Pre-boot
Rollout de FDE com regras de senha fracas/incompatíveis	User Acquisition nunca completa; FDE nunca ativa	Alinhe a política de senhas primeiro
Atualizar para o E89.25 num dispositivo que carrega o Windows Boot Manager diretamente	Upgrade de FDE bloqueado ou disco não criptografado	Rode o BootModeReport.ps1 (sk185123) antes; atualize a BIOS ou troque essa máquina para BitLocker Management
Instalar FDE em modo FAST_INSTALL / ATM em hardware afetado pelo E89.25	Dispositivo pode ficar não inicializável	Verifique a compatibilidade de firmware primeiro; deixe o procedimento de recuperação por USB do FDE à mão
Sem mídia de recovery testada	Um disco criptografado que não dá boot fica irrecuperável	Crie + teste a mídia; confirme que o recovery file chegou ao servidor
Tentar custom volume encryption em SED	Silenciosamente sobrescrito pelo client	Aceite AES + settings de volume completo em SED
Esperar remover FDE durante upgrade	Não suportado	Planeje a remoção como mudança separada
`FDEControl.exe` bypass fora da janela	Falha com código 13	Execute dentro da janela permitida pela política

Troubleshooting

Sintoma: O FDE fica na Deployment Phase e nunca começa a criptografar Ambiente: Client Windows, engine Check Point FDE Causas-raiz e verificações:

User Acquisition incompleto: o número exigido de usuários não fez logon, ou as contas não atendem às regras de senha
Sem comunicação client para serviço: o recovery file não chega ao serviço de gestão (passo 5). Verifique a conectividade
Requisitos de client não atendidos: verifique se o dispositivo atende aos requisitos de client do FDE
Gate de firmware no E89.25: se os upgrades pararam de criptografar após migrar para o E89.25, procure a mensagem de firmware no Blade Status e rode o BootModeReport.ps1 (sk185123)
No client: ícone de cadeado na bandeja > Display Overview > Full Disk Encryption > compare o status atual com a lista de seis estágios

FAQ

P: Qual o algoritmo de criptografia padrão? R: AES-CBC (256-bit). A política cloud também oferece XTS-AES (256/128).

P: Quantos reboots durante o deployment? R: Check Point FDE = dois; BitLocker = um.

P: Posso pular o Pre-boot em máquinas dentro do escritório? R: Sim. O Allow bypass when connected to LAN autentica com segurança por Ethernet sem Pre-boot manual (UEFI + Mac suportados), caindo para Pre-boot manual se necessário.

P: Um disco foi movido para outro computador, isso é detectado? R: Sim. O Hardware Hash (de BIOS + CPU) detecta a troca.

P: Atualizamos para o E89.25 e algumas máquinas pararam de criptografar com Check Point FDE. Por quê? R: O E89.25 exige o UEFI boot order padrão. Dispositivos que carregam o Windows Boot Manager diretamente ficam bloqueados até um update de BIOS. Você pode consentir a troca dessas máquinas para BitLocker Management no intervalo, e deve verificar o hardware com o BootModeReport.ps1 (sk185123).

P: O que acontece após um Full Recovery? R: O disco fica descriptografado e o SO roda sem Pre-boot, então o admin precisa reinstalar o FDE naquela máquina.

Referências

Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal), Configuring the Data Protection Policy > Full Disk Encryption (engines, algoritmos, Pre-boot, Temporary Pre-boot Bypass, SED, recuperação)
Check Point SecureKnowledge sk184929, Enterprise Endpoint Security E89.25 Windows Clients (compatibilidade de firmware do FDE, EPS-63819; limitações do Smart Pre-boot)
Check Point SecureKnowledge sk185123 (BootModeReport para compatibilidade de firmware do FDE)

Histórico de Revisões

Data	Versão	Autor	Mudanças
2026-07-16	1.0	Jorge Luiz	Versão inicial
2026-07-30	2.0	Jorge Luiz	Revalidação cloud-first do caminho de configuração do FDE, engines, algoritmos, SED e recuperação
2026-09-15	2.1	Jorge Luiz	Adicionado o gate de Compatibilidade de Firmware do FDE do E89.25 (EPS-63819) e uma nota de Smart Pre-boot (E89.05 GA); Erros Comuns, Troubleshooting, FAQ e Referências relacionados; removidos emoji e travessões para leitura mais limpa

Versões Suportadas: Harmony Endpoint gerenciado na nuvem (Infinity Portal / Web Management); Check Point FDE / BitLocker (Windows) / FileVault (macOS); gate de compatibilidade de firmware do FDE vale a partir do E89.25 Última Atualização: 2026-09-15

topic PT-BR - Full Disk Encryption Deep Dive: Pre-Boot e Check Point FDE vs BitLocker in Endpoint