Quem responde por dados de clientes, transações Pix e informações estratégicas sabe que a pergunta não é mais se a empresa vai criptografar seus dados, mas como fazer isso de forma consistente, sem travar a operação. A LGPD tornou a proteção técnica uma expectativa concreta sobre agentes de tratamento, e incidentes com dados em texto puro costumam sair caro em multas, notificações e reputação. Entender como criptografar dados sensíveis da empresa deixou de ser projeto isolado de segurança e passou a integrar a agenda de compliance e de gestão de risco.
Este guia foi pensado para decisores de TI, segurança da informação e compliance que precisam sair do discurso genérico e chegar a decisões técnicas defensáveis. O texto percorre o que caracteriza um dado sensível sob a ótica da LGPD, os tipos de criptografia (simétrica, assimétrica e hashing), os três estados em que o dado precisa ser protegido — em repouso, em trânsito e em uso —, um passo a passo de implantação e os pontos críticos de gestão de chaves, incluindo ferramentas Microsoft como BitLocker, Azure Key Vault e Purview.
Ao final, você terá um roteiro para classificar ativos, escolher controles por tipo de dado e reduzir risco de exposição sem comprometer a disponibilidade dos sistemas. Nenhuma abordagem elimina todos os riscos, mas a combinação correta de criptografia, custódia de chaves e conformidade torna o ambiente substancialmente mais difícil de explorar.
O que são dados sensíveis na empresa (e o que a LGPD exige)
Dados sensíveis são qualquer informação que, se exposta, alterada ou destruída sem autorização, gera dano material ou reputacional à empresa, a clientes ou a terceiros. Na prática, isso inclui dados pessoais de titulares (CPF, RG, biometria, saúde, orientação política ou religiosa), segredos comerciais, propriedade intelectual, credenciais de acesso, chaves de API, dados bancários e registros de transações financeiras — como as que envolvem Pix, em que o vazamento de uma chave ou de um comprovante pode viabilizar fraude direcionada.
A LGPD (Lei nº 13.709/2018) não determina textualmente "use AES-256", mas impõe obrigações que tornam a criptografia uma medida técnica esperada. O artigo 46 exige que agentes de tratamento adotem medidas de segurança capazes de proteger os dados de acessos não autorizados e de situações acidentais ou ilícitas. A criptografia não isenta a empresa de notificar incidentes, mas reduz a probabilidade de dano — e a ANPD já sinaliza, em guias e decisões, que dados criptografados com chave íntegra e fora do alcance do atacante tendem a ser tratados como de menor risco em análises de incidentes.
Existe ainda uma distinção operacional importante: dado pessoal sensível (art. 5º, II, da LGPD) tem regime jurídico mais rígido que dado pessoal comum, com base legal restrita e exigência de consentimento específico em vários cenários. Para o time de segurança, isso muda o inventário: um campo de "observações médicas" em um sistema de RH exige classificação e proteção diferentes de um campo de "cargo". O primeiro passo de qualquer projeto de criptografia é, portanto, saber exatamente quais dados se enquadram em cada categoria — tema que será detalhado no passo a passo.
Como funciona a criptografia: simétrica, assimétrica e hashing
Criptografia é a transformação de um texto legível (plaintext) em uma sequência ilegível (ciphertext) por meio de um algoritmo e de uma chave. A reversão só é possível com a chave correta. Os três pilares técnicos que sustentam a proteção de dados corporativos são a criptografia simétrica, a assimétrica e o hashing — cada um resolve um problema diferente e tem custo computacional distinto.
Criptografia simétrica (AES)
Na criptografia simétrica, a mesma chave cifra e decifra o dado. O padrão de mercado é o AES (Advanced Encryption Standard), adotado pelo NIST e usado em BitLocker, TLS, VPNs e bancos de dados. Os tamanhos de chave usuais são 128, 192 e 256 bits; para dados corporativos sensíveis, AES-256 é a escolha recomendada, pois resiste a ataques de força bruta com a capacidade computacional conhecida hoje.
A vantagem do AES é a velocidade: cifrar gigabytes de dados em disco ou em trânsito é viável sem degradação perceptível, porque os processadores modernos (Intel AES-NI, AMD e ARM) têm instruções nativas para acelerar o algoritmo. A desvantagem é a logística da chave: quem cifra e quem decifra precisam da mesma chave, e distribuí-la de forma segura é o problema clássico que a criptografia assimétrica resolve.
Criptografia assimétrica (RSA, ECC)
A criptografia assimétrica usa um par de chaves: a pública, que pode ser compartilhada livremente, e a privada, que fica sob custódia exclusiva do titular. O que a chave pública cifra, apenas a privada decifra — e vice-versa, o que também habilita assinaturas digitais. Os algoritmos mais comuns são RSA (baseado em fatoração de números primos grandes) e ECC (Elliptic Curve Cryptography, baseado em curvas elípticas).
O RSA ainda é amplamente suportado, com chaves de 2048 ou 3072 bits consideradas seguras em 2026. O ECC entrega o mesmo nível de segurança com chaves muito menores — uma chave ECC de 256 bits equivale, em resistência estimada, a uma RSA de 3072 bits — e por isso é preferido em dispositivos móveis, certificados digitais e cenários de alta concorrência. Na prática corporativa, a criptografia assimétrica raramente cifra grandes volumes de dados: ela é usada para trocar chaves de sessão, assinar atualizações e autenticar servidores, enquanto o AES faz o trabalho pesado.
Hashing e salting para senhas
Hash é uma função unidirecional: transforma qualquer entrada em uma sequência de tamanho fixo, sem caminho prático de reversão. Senhas nunca devem ser armazenadas em texto puro nem cifradas (que seria reversível); devem ser armazenadas como hash. Os algoritmos recomendados para senhas são os projetados para serem lentos e custosos, como Argon2id, bcrypt e scrypt — não SHA-256 ou MD5, que são rápidos demais e facilitam ataques de dicionário e rainbow tables.
O salting adiciona uma sequência aleatória única a cada senha antes do hash, garantindo que duas pessoas com a mesma senha produzam hashes diferentes e inviabilizando tabelas pré-computadas. Em ambientes Microsoft, o Azure AD (Entra ID) aplica hash com salt e políticas de lockout; em aplicações próprias, a recomendação é Argon2id com parâmetros calibrados para o hardware da empresa. Vale lembrar: hashing não é criptografia reversível, e tentar "descriptografar" um hash é um erro conceitual comum em times que estão começando a estruturar autenticação.
Onde criptografar: em repouso, em trânsito e em uso
Os dados corporativos existem em três estados, e cada um exige controles diferentes. Dados em repouso são aqueles armazenados em disco, banco de dados, backup ou fita. Dados em trânsito são os que trafegam entre servidores, entre cliente e servidor, ou entre regiões de nuvem. Dados em uso são os que estão sendo processados na memória de um servidor — o estado historicamente mais difícil de proteger e onde a computação confidencial entra.
Para dados em repouso, as ferramentas centrais são criptografia de disco completo (BitLocker em Windows, dm-crypt/LUKS em Linux), criptografia de volume em nuvem (Azure Disk Encryption, discos gerenciados com chaves gerenciadas pela plataforma ou pelo cliente) e criptografia em nível de banco de dados (Transparent Data Encryption no SQL Server, Always Encrypted para colunas específicas). Para dados em trânsito, o padrão é TLS 1.2 ou 1.3 — o TLS 1.0 e 1.1 estão obsoletos e devem ser desabilitados —, além de VPNs e links privados como o ExpressRoute na migração, que mantém o tráfego fora da internet pública.
Para dados em uso, a computação confidencial (confidential computing) usa enclaves de hardware — como Intel SGX, AMD SEV-SNP e, no Azure, as Confidential VMs e os contêineres confidenciais — para processar dados em uma região isolada da memória, protegida até mesmo do hipervisor e do provedor de nuvem. É um recurso relevante para instituições financeiras que processam transações Pix e precisam demonstrar que nem o operador da infraestrutura consegue inspecionar a memória durante o processamento.
Passo a passo: como criptografar os dados da sua empresa
Implementar criptografia sem um plano costuma gerar dois resultados: proteção inconsistente (dados críticos ficam de fora) ou bloqueio operacional (usuários perdem acesso a sistemas legados). O roteiro abaixo organiza a implantação em quatro etapas, da classificação à aplicação por tipo de ativo.
Mapeamento e classificação dos dados
Antes de escolher algoritmo ou ferramenta, é preciso saber onde estão os dados sensíveis. O inventário deve cobrir bancos de dados, servidores de arquivos, notebooks, e-mails, backups, ambientes de nuvem e integrações com terceiros. Uma abordagem eficiente combina ferramentas de descoberta de dados (Microsoft Purview, por exemplo) com entrevistas aos donos de cada sistema, porque nem todo dado sensível está em um campo estruturado — há muito dado crítico em planilhas soltas, anexos de e-mail e pastas compartilhadas.
A classificação deve seguir níveis simples e acionáveis, como público, interno, confidencial e restrito. O nível restrito inclui dados pessoais sensíveis, credenciais, chaves de API, segredos comerciais e registros financeiros. Essa classificação vira o critério para decidir o que recebe criptografia forte, o que recebe proteção padrão e o que pode ficar sem criptografia adicional. Sem esse mapa, o time tende a criptografar tudo (gastando recursos e degradando performance) ou nada (deixando lacunas).
Escolha de algoritmos e tamanhos de chave
A regra prática para 2026 é direta:
- Dados em repouso e em trânsito: AES-256 (simétrico)
- Troca de chaves e assinaturas: ECC P-256 ou RSA 3072 (assimétrico)
- Senhas: Argon2id, bcrypt ou scrypt com salt único
- Integridade e autenticação: HMAC-SHA256 ou SHA-3
- Evitar: DES, 3DES, RC4, MD5, SHA-1, chaves RSA abaixo de 2048 bits
O tamanho da chave precisa ser definido junto com a política de ciclo de vida: uma chave AES-256 tem vida útil longa, mas deve ser rotacionada periodicamente, e chaves assimétricas de certificados digitais costumam ter validade de 1 a 2 anos. A escolha do algoritmo também precisa considerar interoperabilidade: sistemas legados que só falam TLS 1.0 ou que dependem de cifras antigas devem ser isolados ou atualizados antes da criptografia ser estendida a eles.
Criptografia de disco e banco de dados
Para discos, o BitLocker é a opção nativa do ecossistema Windows e pode ser gerenciado via Intune ou GPO, com recuperação de chave integrada ao Microsoft Entra ID. Em servidores Linux, LUKS cumpre papel equivalente. Na nuvem Azure, discos gerenciados já vêm com criptografia em repouso habilitada por padrão usando chaves gerenciadas pela Microsoft; empresas com exigência de controle total podem migrar para chaves gerenciadas pelo cliente (Customer-Managed Keys) via Azure Key Vault.
Em bancos de dados, há duas camadas: a criptografia do arquivo de dados (Transparent Data Encryption no SQL Server e no Azure SQL, que protege contra roubo de mídia física, mas não contra quem tem acesso legítimo ao banco) e a criptografia de colunas (Always Encrypted, que mantém dados cifrados até na memória do servidor, permitindo que a aplicação processe campos como CPF e número de conta sem que o DBA ou um invasor com acesso ao SQL consiga lê-los). Para ambientes de alta sensibilidade, essa segunda camada é o que diferencia conformidade real de checklist superficial.
Criptografia de arquivos, backups e e-mails
Arquivos avulsos e pastas compartilhadas podem ser protegidos com EFS (Encrypting File System) em Windows ou com ferramentas de criptografia de arquivos em nível de aplicação. No Microsoft 365, o Azure Information Protection (parte do Microsoft Purview) aplica rótulos de confidencialidade que podem criptografar automaticamente documentos do Word, Excel e PDFs, restringindo leitura, edição e impressão mesmo depois que o arquivo sai da empresa.
Backups são um vetor frequentemente esquecido: um backup em fita ou em nuvem sem criptografia equivale a deixar uma cópia completa dos dados sensíveis em um formato legível por qualquer um que acesse a mídia. Soluções como Acronis e Azure Backup aplicam criptografia AES-256 no destino, com chave controlada pelo cliente. E-mails com dados sensíveis devem usar criptografia de mensagem do Microsoft 365 (OME), que protege o conteúdo em trânsito e em repouso na caixa do destinatário, além de políticas de DLP para bloquear o envio de dados classificados para domínios externos não autorizados.
Gestão de chaves: o ponto onde a maioria das empresas falha
Um erro recorrente em implantações de criptografia é tratar a chave como um detalhe operacional. Na prática, a chave é o ativo mais valioso do sistema: quem controla a chave controla o dado, independentemente da força do algoritmo. Uma chave AES-256 armazenada em um arquivo de texto no mesmo servidor que ela protege anula todo o investimento em criptografia.
Os princípios de gestão de chaves que precisam estar documentados em política formal incluem:
- Custódia separada: a chave nunca fica no mesmo sistema que o dado cifrado
- Rotação programada: chaves de dados rotacionadas em ciclos definidos, chaves mestras com ciclo mais longo
- Acesso mínimo: apenas identidades e aplicações autorizadas podem usar ou gerenciar chaves
- Auditoria integral: todo uso, rotação e tentativa de acesso à chave gera log
- Recuperação de desastre: plano de contingência para perda ou comprometimento da chave, incluindo backup seguro
No ecossistema Azure, o Key Vault centraliza essa gestão com HSM (Hardware Security Module) gerenciado ou dedicado, controle de acesso via RBAC, rotação automática e registro de auditoria integrado ao Azure Monitor. Para quem opera em ambiente híbrido, o mesmo padrão se aplica: chaves de BitLocker em servidores locais devem ser custodiadas em um cofre separado, não em uma planilha de TI. A ISO 27001 dedica controles específicos (A.8.24, A.10.1) à gestão de chaves criptográficas, e auditores costumam verificar a existência de política, rotação e segregação de funções.
Criptografia na nuvem: responsabilidade compartilhada e BYOK
No modelo de responsabilidade compartilhada, o provedor de nuvem é responsável pela segurança da infraestrutura — incluindo a criptografia física dos datacenters e a criptografia base da camada de armazenamento —, mas o cliente é responsável por configurar e gerenciar a criptografia dos seus dados, das suas chaves e dos seus acessos. Muitos incidentes de exposição em nuvem não decorrem de falha do provedor, mas de buckets de armazenamento abertos, chaves embutidas em código ou permissões excessivas.
O BYOK (Bring Your Own Key) permite que a empresa forneça sua própria chave criptográfica para o provedor usar na proteção dos dados, em vez de aceitar apenas a chave gerenciada pela plataforma. No Azure, isso se materializa com o Key Vault e com o Azure Key Vault Managed HSM, em que a chave pode ser gerada em um HSM dedicado e nunca sair do cofre. O nível máximo de controle é o HYOK (Hold Your Own Key), em que a chave permanece em um HSM on-premises — usado por instituições financeiras que precisam garantir que nem o provedor de nuvem consiga descriptografar determinados conjuntos de dados, um requisito comum em ambientes que processam transações Pix e dados bancários.
Para empresas que estão planejando mover cargas de trabalho para a nuvem, a criptografia precisa entrar no desenho da migração, não ser um remendo posterior. O artigo sobre como planejar a migração detalha como segurança e identidade devem ser tratadas como pré-requisitos do projeto, não como fases finais.
Erros comuns ao criptografar dados corporativos
Os erros mais frequentes em projetos de criptografia não são técnicos, mas de governança e de escopo. O primeiro é criptografar sem classificar: a empresa aplica BitLocker em todos os discos e acredita que resolveu o problema, enquanto bancos de dados com CPF e número de conta seguem acessíveis em texto puro para qualquer aplicação que tenha credencial de leitura. O segundo é ignorar a gestão de chaves, armazenando chaves no mesmo servidor ou em repositórios de código — um único commit com chave exposta em um repositório público já foi vetor de incidentes graves em empresas de tecnologia.
Outros erros recorrentes incluem:
- Usar algoritmos obsoletos (DES, 3DES, RC4, MD5, SHA-1) por compatibilidade com sistemas legados
- Criptografar apenas o disco e esquecer backups, que muitas vezes circulam em mídias removíveis sem proteção
- Não proteger o e-mail, principal canal de vazamento de dados sensíveis em empresas
- Aplicar criptografia sem testar recuperação de desastre, descobrindo na crise que ninguém sabe onde está a chave de recuperação
- Tratar criptografia como projeto pontual, sem revisão periódica de algoritmos, chaves e acessos
Há ainda o erro de acreditar que criptografia substitui os demais controles. Um atacante com credencial válida de um usuário legítimo não precisa quebrar criptografia nenhuma — ele se autentica e lê os dados já decifrados pelo sistema. Por isso, a criptografia precisa andar junto com autenticação multifator, gestão de identidade, privilégio mínimo e monitoramento. Um teste de ethical hacking ajuda a validar se a criptografia está cobrindo os vetores reais de ataque, e não apenas os cenários teóricos.
Ferramentas e custos: o que usar em cada cenário
O custo de criptografar dados corporativos varia muito conforme o cenário, o volume e o nível de controle exigido. A tabela abaixo organiza as ferramentas mais comuns por necessidade, com faixas de custo estimadas para o mercado brasileiro em 2026 — valores que devem ser validados em orçamento, pois licenciamento Microsoft varia por acordo e região.
- Disco de notebooks e desktops: BitLocker (incluso no Windows Pro/Enterprise) — custo direto zero, gestão via Intune no Microsoft 365
- Discos e volumes em servidores Azure: criptografia padrão com chave gerenciada pela Microsoft (inclusa); chaves gerenciadas pelo cliente via Key Vault (custo por operação de chave, na faixa de centavos de dólar por 10 mil operações)
- Colunas sensíveis em banco de dados: Always Encrypted no SQL Server (incluso na licença) ou Azure SQL (incluso no serviço)
- Arquivos e documentos no Microsoft 365: Azure Information Protection / Purview (requer plano E3 ou E5, ou licença avulsa de Proteção de Informação)
- E-mails confidenciais: Microsoft 365 Message Encryption (incluso no E3/E5)
- Backups: Acronis Cyber Protect e Azure Backup (faixa típica de R$ 30 a R$ 120 por workload/mês, dependendo de retenção e recursos)
- Gestão de chaves com HSM: Azure Key Vault (camada standard, custo por operação) ou Azure Key Vault Managed HSM (faixa de centenas de dólares por mês por HSM dedicado)
- Computação confidencial: Azure Confidential VMs (custo premium sobre a VM padrão, variável por região e série)
Para PMEs, o caminho de menor custo costuma ser BitLocker + Purview (se já tiverem Microsoft 365 E3) + Key Vault na camada standard. Para médias e grandes empresas do setor financeiro, o investimento em HSM dedicado e computação confidencial se justifica quando há exigência regulatória ou contratual de demonstrar controle exclusivo das chaves. A decisão de lift and shift para Azure também influencia o custo: cargas migradas sem refatoração tendem a usar criptografia de disco padrão, enquanto aplicações modernizadas podem aproveitar criptografia em nível de coluna e confidential computing.
Checklist de implantação e conformidade com a LGPD
O checklist abaixo consolida as etapas essenciais para implantar criptografia com aderência à LGPD e a boas práticas de segurança. Ele serve como roteiro de validação para o time de TI e como evidência para auditorias e respostas a incidentes.
- Inventário de dados sensíveis concluído e classificado por nível (público, interno, confidencial, restrito)
- Base legal de tratamento documentada para cada conjunto de dados pessoais sensíveis (art. 7º e art. 11º da LGPD)
- Algoritmos aprovados em política formal: AES-256, ECC P-256/RSA 3072, Argon2id/bcrypt para senhas
- Criptografia em repouso habilitada em todos os discos, bancos de dados e backups que contenham dados confidenciais ou restritos
- TLS 1.2/1.3 obrigatório em todas as comunicações; TLS 1.0/1.1 e cifras fracas desabilitados
- Gestão de chaves centralizada em cofre (Key Vault, HSM), com custódia separada do dado cifrado
- Política de rotação de chaves definida e automatizada onde possível
- Recuperação de desastre testada: chaves de recuperação acessíveis, backup seguro e processo documentado
- Controle de acesso às chaves com privilégio mínimo e registro de auditoria de todo uso
- Criptografia de e-mails e documentos com dados sensíveis via Purview/OME
- Plano de resposta a incidentes que considere cenário de perda ou comprometimento de chave
- Revisão periódica (semestral ou anual) de algoritmos, chaves, acessos e cobertura de novos sistemas
A criptografia é uma das poucas medidas técnicas que a LGPD cita explicitamente como exemplo de boa prática, e sua presença consistente no ambiente reduz de forma mensurável o risco em caso de incidente. O que nenhuma ferramenta resolve sozinha é a governança: sem política de chaves, classificação de dados e integração com identidade e monitoramento, a criptografia vira um selo formal que não resiste a um ataque real. Empresas que processam transações Pix e dados bancários devem tratar esse tema como parte da rotina de conformidade, com revisão contínua e validação independente — inclusive por meio de testes de invasão que verifiquem se os controles criptográficos estão de fato cobrindo os vetores de exposição.
