Criptografia de Dados em Repouso e Trânsito: 5 Camadas Essenciais

Dados são o ativo mais valioso de uma empresa, e o alvo preferido de criminosos. O relatório Cost of a Data Breach 2025 da IBM revelou que o custo médio de uma violação de dados no Brasil atingiu R$ 7,19 milhões, com tempo médio de detecção girando em torno de 276 dias. Essa lacuna de quase 10 meses oferece janelas brutais para exfiltração, criptografia maliciosa e estrago reputacional. Mas há uma camada de defesa que reduz drasticamente esse risco: criptografia de dados, tanto em repouso quanto em trânsito.

Não é suficiente escolher um padrão de criptografia e dormir tranquilo, o cenário de ameaças evoluiu. Ransomware está presente em 44% das violações documentadas (segundo Verizon DBIR 2025), e ataques contra infraestrutura de chaves criptográficas crescem exponencialmente. Profissionais de infraestrutura que ainda veem criptografia como "um recurso de TI a mais" estão expostos. Quem comanda decisões de segurança hoje precisa entender que criptografia efetiva exige cinco camadas distintas de implementação, e cada uma delas tem implicações práticas no TCO, performance e conformidade regulatória.

Este artigo dissocia o que é marketing de segurança do que funciona de verdade em produção. Vamos cobrir cada camada: algoritmos, transporte, armazenamento, gestão de chaves e recuperação. Se você gerencia infraestrutura de missão crítica no Brasil, você não pode ignorar nenhuma.

Camada 1: Criptografia em Repouso, AES-256 como Padrão Obrigatório

Dados em repouso são informações armazenadas em disco, tape, SSD ou em bancos de dados. Se um criminoso ganha acesso físico ao hardware ou explora uma vulnerabilidade de escalação de privilégio, dados não criptografados são trivialmente legíveis.

A solução de facto é AES-256 (Advanced Encryption Standard com chave de 256 bits). Não é moda. É o padrão definido pelo NIST (National Institute of Standards and Technology), adotado globalmente por instituições financeiras, setor de saúde, e agências governamentais. Em 2024-2025, o NIST lançou os primeiros padrões de criptografia pós-quântica finalizados, e AES-256 continua como a escolha recomendada para cenários onde resistência a computadores quânticos não é uma preocupação imediata (a maioria das organizações brasileiras).

Mas aqui está o detalhe que diferencia infraestrutura amadora de infraestrutura séria: onde e como você criptografa em repouso.

• Nível básico: criptografia de disco. Ferramentas como LUKS (Linux Unified Key Setup) ou BitLocker (Windows) criptografam o volume inteiro. Qualquer arquivo escrito no disco é automaticamente criptografado com a chave armazenada (idealmente) em local seguro. Benefício: simplicidade. Desvantagem: se um atacante conseguir acesso ao SO com privilégios root, a chave de descriptografia em memória pode ser extraída.

• Nível corporativo: criptografia de camada de aplicação. Bancos de dados (PostgreSQL com pgcrypto, MySQL com aplicações wrapper) criptografam dados antes de persistirem. A aplicação mantém controle das chaves. Benefício: até que a aplicação esteja comprometida, dados continuam protegidos. Desvantagem: overhead de processamento é maior, pois cada leitura e escrita passa por operações criptográficas.

• Nível crítico: Hardware Security Modules (HSMs). Um HSM é um dispositivo dedicado que realiza operações criptográficas em hardware, armazenando chaves em ambiente físicamente isolado (tamper-resistant). Bancários, fintech, operadores de infraestrutura crítica usam HSMs para manter chaves mestras longe de servidores padrão.

Servidores dedicados de missão crítica com suporte a HSM externo (via rede ou USB) oferecem o melhor compromisso: criptografia de dados em repouso com chaves gerenciadas fora do servidor. 

O fato: não é "use AES-256 e pronto". É "defina onde a chave vive, quem a acessa, e como você a rotaciona periodicamente". LGPD no Brasil (Lei nº 13.709/2018) exige que dados pessoais sejam protegidos por meio de medidas técnicas apropriadas, criptografia em repouso é o padrão esperado para informações sensíveis.

Camada 2: Criptografia em Trânsito, TLS 1.3 como Mínimo Aceitável

Dados em movimento (em trânsito) viajam entre clientes, servidores, data centers. Uma conexão desprotegida é um wiretap aberto. Um atacante na rede pode interceptar, modificar ou vender dados em tempo real. Por isso, TLS (Transport Layer Security), a tecnologia por trás de HTTPS, é mandatória.

TLS 1.2 ainda funciona, mas TLS 1.3 é o novo padrão. A migração não é opcional para infraestrutura nova.

Comparação de TLS 1.2 vs TLS 1.3:

O TLS 1.2 exige múltiplas trocas de mensagens para estabelecer uma conexão segura. Cada handshake envolve até 4 roundtrips antes de dados começarem a fluir. Em produção, times de infraestrutura relataram que latência do handshake TLS consumia até 80% da latência total em conexões individuais (Cloudflare, 2025).

TLS 1.3 reduz esse custo dramaticamente. 0-RTT (Zero Round Trip Time) permite que clientes (que já conhecem o servidor) enviem dados criptografados sem esperar confirmação. A redução de latência observada em ambientes reais é entre 25% e 40%, especialmente importante em aplicações com volume alto de conexões curtas (APIs, microserviços, webhooks).

Segurança também melhorou. TLS 1.3 removeu criptografias fracas, forçou cifradores authenticated encryption, e tornou ataques downgrade mais difíceis.

Implementação prática:

• Certificados TLS modernos (X.509v3) com Subject Alternative Names (SANs) para suportar múltiplos domínios.
• Renovação de certificados a cada 90 dias é agora padrão (automação via ACME é mandatória).
• Atenção: CA/Browser Forum aprovou redução do tempo de vida de certificados TLS para 47 dias a partir de 2029, planeje infraestrutura de rotação certificados agora.
• Usar ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) para perfect forward secrecy, se uma chave privada for comprometida amanhã, sessões de ontem permanecem seguras.

Servidores dedicados em data center Tier III com suporte a TLS 1.3 nativo (Linux kernel 4.13+, OpenSSL 1.1.1+) são obrigatórios. Evitar servidores com SO desatualizado que force TLS 1.2 ou inferior.

LGPD não menciona TLS especificamente, mas conformidade com ISO 27001 (que muitas empresas almejam para certificação) exige "criptografia apropriada em trânsito", TLS 1.3 é o benchmark atual.

Camada 3: Gestão de Chaves, O Gargalo Real da Criptografia

Você tem AES-256 e TLS 1.3 em produção. Ótimo. Mas onde estão as chaves?

Essa pergunta separa quem realmente entende criptografia de quem apenas leu slides de marketing. Gestão de chaves é o problema mais negligenciado em infraestrutura.

Existem três modelos principais:

• Modelo 1: Cloud Provider Managed Keys O provedor (AWS, Azure, GCP) armazena e rotaciona chaves por você. Benefício: simplicidade operacional, você não precisa se preocupar com backup de chaves, rotação automática. Desvantagem: o provedor tecnicamente pode acessar seus dados. Para a maioria das empresas, é um trade-off aceitável, mas violações de confiança já ocorreram.

• Modelo 2: BYOK (Bring Your Own Key) Você gera a chave mestre fora do provedor cloud e a importa. O provedor nunca vê a chave em plaintext. Você mantém controle total, mas agora é sua responsabilidade fazer backup, rotação, auditoria. AWS KMS, Azure Key Vault, GCP Cloud KMS suportam BYOK.

• Modelo 3: HYOK (Hold Your Own Key) A chave vive inteiramente dentro do seu data center. Você não passa a chave nem para o cloud. Máxima segurança, máximo overhead operacional.

Para infraestrutura brasileira de missão crítica (financeira, healthcare, energia), recomendação prática é BYOK + HSM on-prem como backup: o provedor cloud rotaciona dados usando sua chave (BYOK), mas você mantém réplica de chave em HSM on-premises para recuperação de desastres sem dependência de cloud.

Requisitos operacionais de key management:

• Rotação periódica: mude a chave ativa a cada 90 a 365 dias (depende de conformidade). Dados antigos continuam descriptáveis com versões anteriores.
• Separação de acesso: quem provisiona chaves ≠ quem acessa dados ≠ quem rotaciona chaves. Auditoria deve rastrear cada acesso.
• Redundância geográfica: backup de chaves em local geograficamente distante. Se seu data center queimar, você não perde a chave.
• Auditoria de chaves: todo acesso a chaves, tentativas falhadas, rotações, tudo registrado. LGPD exige rastreabilidade.

Gartner reportou em 2025 que 40% das brechas envolvem falha de key management, não falha do algoritmo. A criptografia é tão forte quanto o seu processo de gerenciar chaves.

Camada 4: Proteção contra Ransomware e Backup Imutável

Criptografia em repouso e trânsito protegem contra vazamento de dados. Mas e se um atacante não quer roubar: quer destruir ou criptografar tudo com sua própria chave (ransomware)?

Aqui entra backup imutável. Este não pode ser deletado ou modificado, nem mesmo pelo administrador do servidor, por um período definido (retenção). Se ransomware criptografar seu disco, você descriptografa tudo com sua chave e restaura do backup imutável.

O padrão de mercado em 2025:

• Backups com air-gapping (isolamento de rede): a réplica de backup vive em uma rede separada, inacessível mesmo se todos os servidores produtivos forem comprometidos.
• WORM (Write Once Read Many) em storage: dados gravados uma única vez, nunca modificados, apenas lidos.
• Retenção mínima de 30 a 90 dias (depende de RTO/RPO da empresa).

Verizon DBIR 2025 apontou que ransomware evoluiu: grupos criminosos agora roubam dados e depois os criptografam (duplo extorsão). Criptografia de backup é sua salvação, você pode restaurar até a data anterior ao ataque, sem pagar o resgate.

Servidores dedicados em data center Tier III devem incluir suporte a backup imutável. AWS Backup, Microsoft Azure Backup, Google Cloud Backup todos oferecem isso, assim como soluções on-premises como Veeam com integração de WORM.

Camada 5: Conformidade Regulatória e Auditoria

LGPD exige que dados pessoais sejam protegidos. Mas protegidos como? A lei é vaga intencionalmente, o padrão é "medidas técnicas apropriadas". Isso significa:

• Criptografia é esperada (não obrigatória, mas ausência dela é impossível de justificar para pessoa física de dados).
• Se você não criptografa dados pessoais, qualquer vazamento aumenta a penalidade (até R$ 50 milhões por violação).

ISO 27001 (certificação de gestão de segurança) especifica criptografia de dados em repouso e trânsito como controle obrigatório. Se sua empresa busca ISO 27001, criptografia não é negociável.

PCI DSS (Payment Card Industry Data Security Standard) exige AES-128 no mínimo para dados de cartão (AES-256 é melhor prática). Se você processa pagamento, PCI DSS é mandatório por lei.

BACEN (Banco Central do Brasil) exigirá em breve conformidade com novos padrões de segurança cibernética para instituições financeiras. Criptografia de dados críticos é parte.

Auditoria de criptografia significa:

• Inventário de chaves: você sabe quantas chaves tem em produção? Onde estão? Quem acessa?
• Ciclo de vida de chave: quando foi criada, quando foi rotacionada pela última vez, quando será decomissionada.
• Conformidade de algoritmos: você ainda usa SHA-1 ou MD5 em hash? (Ambos quebrados, use SHA-256+).
• Logs de acesso: auditoria imutável de quem acessou dados, quando, de onde.

Implementar isso sem ferramenta de gestão centralizada (como AWS KMS, HashiCorp Vault, CyberArk) é operacionalmente insustentável.

FAQ: Perguntas Comuns 

• AES-256 é quebrado?

R: AES-256 não é quebrável nem por computadores quânticos conhecidos. Você está confundindo com criptografia de chave pública (RSA, ECDSA), que sim, seriam quebrável por computadores quânticos em escala. O NIST lançou em 2024 novos padrões pós-quânticos para chave pública. AES-256 continua seguro. Use-o.

• Qual é o overhead de performance de criptografia TLS 1.3 em servidores dedicados?

R: Negligenciável em hardware moderno. Com aceleração AES-NI (disponível em processadores Intel Xeon desde 2010), criptografia é feita em hardware. Overhead é <1% de CPU. O ganho de latência (fewer roundtrips) compensa amplamente.

• Se meus dados estão criptografados, preciso fazer backup?

R: Absolutamente. Criptografia protege contra vazamento e acesso não autorizado. Não protege contra corrupção, hardware failure, ou ransomware. Backup é camada separada, obrigatória.

• HSM é obrigatório para servidores dedicados?

R: Não, mas recomendado se dados envolvem LGPD, setor financeiro, ou healthcare. Para aplicações web padrão, criptografia em disco + BYOK em cloud KMS é suficiente.

• Como rodar criptografia em repouso sem impactar performance?

R: Use AES-NI (aceleração por hardware). Escolha criptografia de disco (LUKS) em vez de aplicação, pois é transparent ao SO. Benchmark antes de ir a produção.

• Quanto custa implementar criptografia de ponta a ponta?

R: Infraestrutura técnica é barata. Custos reais estão em operações (rotação de chaves, auditoria, compliance) e treinamento de equipe. Um servidor dedicado com suporte a HSM tem cobrança mensal fixa na EVEO, a depender de especificações. A maioria do custo é na governança, não na tecnologia.

A criptografia de dados em repouso e trânsito não é um detalhe técnico, é o fundamento da confiança em infraestrutura. O custo de uma violação de dados no Brasil (R$ 7,19 milhões) é ordens de magnitude maior que o investimento em criptografia adequada.

As cinco camadas descritas aqui não são opcionais. Algoritmos fortes (AES-256, TLS 1.3) são necessários, mas insuficientes. Você precisa gestão de chaves estratégica, backup imutável contra ransomware, e auditoria contínua para conformidade.

Se sua infraestrutura ainda roda com dados não criptografados ou TLS 1.2, é hora de agir. A ANPD (Autoridade Nacional de Proteção de Dados) intensificou fiscalizações em 2025, e o custo de não estar em conformidade é penal, não só financeiro, mas reputacional.

Se você lidera infraestrutura em empresa brasileira com dados sensíveis, o próximo passo é mapear onde suas chaves vivem hoje e onde deveriam viver. A EVEO ajuda nessa transição com consultoria técnica de segurança.