Atualizado em
Criptografia em cloud protege seus dados tornando-os ilegíveis para quem não tem as chaves de acesso — seja durante o armazenamento (em repouso) ou durante a transmissão (em trânsito). Entender como cada tipo funciona, quem gerencia as chaves e o que está nos contratos é o que separa uma proteção real de uma sensação falsa de segurança.
Criptografia em repouso — protegendo dados armazenados
Imagine que um atacante consegue acesso físico a um disco rígido de servidor — seja roubando um HD, aproveitando um descarte incorreto ou explorando uma vulnerabilidade de acesso ao storage. Sem criptografia em repouso, os dados estão lá, legíveis. Com criptografia, o que ele encontra é texto cifrado inútil sem a chave correspondente.
AES-256 é o algoritmo padrão para criptografia em repouso em ambientes cloud. É o mesmo usado por bancos, agências de segurança e praticamente todo provedor de cloud sério. A força matemática do AES-256 não é o ponto de falha — o ponto de falha geralmente está no gerenciamento das chaves, não no algoritmo em si.
Full Disk Encryption (FDE) criptografa todo o conteúdo de um disco — sistema operacional, aplicações e dados. Se o disco for removido sem a chave, os dados são inacessíveis. É o controle mínimo para qualquer servidor ou estação de trabalho corporativa.
Volume Encryption criptografa volumes ou partições específicas — útil quando você quer criptografar apenas os dados, não o sistema operacional inteiro, ou quando gerencia volumes de armazenamento em cloud. A Adentro oferece criptografia de volumes para workloads em cloud privada, com opção de gestão de chaves pelo cliente.
O que criptografia em repouso não protege: dados em uso (quando estão sendo processados na memória), acesso via aplicações comprometidas com credenciais válidas, ou qualquer acesso que aconteça com as chaves disponíveis — que é o cenário de ataque mais comum. Proteger a cópia de segurança contra esse cenário é o assunto de como garantir que seu backup seja realmente seguro.
Criptografia em trânsito — protegendo dados que se movem
Imagine que você envia dados de um servidor para outro dentro do ambiente cloud sem criptografia. Qualquer sistema com acesso ao tráfego de rede — seja por posição privilegiada na infraestrutura, por um ataque man-in-the-middle ou por captura de tráfego em um switch comprometido — pode ler esses dados em texto claro.
TLS (Transport Layer Security) é o protocolo padrão para criptografia de dados em trânsito. A versão atual é TLS 1.3; TLS 1.2 ainda é amplamente suportado e aceitável. TLS 1.0 e 1.1 são considerados obsoletos e inseguros — qualquer sistema que ainda os suporte precisa de atualização, o que é um caso clássico para o processo de gestão de vulnerabilidades.
HTTPS nada mais é que HTTP sobre TLS. Toda comunicação entre clientes e servidores web corporativos deve usar HTTPS. Certificados SSL/TLS precisam ser válidos, com algoritmos modernos, e gerenciados com renovação antes do vencimento — certificados expirados causam indisponibilidade e alertam navegadores sobre risco.
A criptografia em trânsito deve ser aplicada não apenas na comunicação externa (cliente-servidor), mas também internamente: entre servidores de aplicação e bancos de dados, entre microserviços, entre o agente de backup e o servidor de backup. Comunicação interna não criptografada é frequentemente ignorada e explorada por ataques de movimento lateral.
Gerenciamento de chaves — onde está o nervo do problema
O problema real aqui é que muitas empresas ativam criptografia e consideram o assunto encerrado. Mas criptografia sem gerenciamento adequado de chaves é como trancar a casa e deixar a chave na fechadura.
Chaves gerenciadas pelo provedor: O caso mais simples. O provedor gerencia as chaves de criptografia, normalmente em um HSM (Hardware Security Module). Seus dados estão criptografados, mas o provedor tem acesso às chaves — o que pode ser um problema para compliance em setores regulados ou para dados de alta sensibilidade.
BYOK — Bring Your Own Key: Você gera e controla as chaves de criptografia, e as entrega ao provedor para uso na criptografia dos seus dados. O provedor usa suas chaves mas não pode acessar os dados sem elas. Se você revogar as chaves, os dados ficam inacessíveis — inclusive para você mesmo, se não tiver backup da chave. BYOK é recomendado para dados altamente sensíveis ou quando compliance exige que o cliente controle as chaves.
HYOK — Hold Your Own Key: Você mantém as chaves em infraestrutura própria e as chaves nunca saem do seu controle. O provedor realiza as operações de criptografia/decriptografia passando pelos seus sistemas de gerenciamento de chaves. Mais complexo, mas máximo controle. Usado em cenários de compliance muito rigorosos.
Gerenciamento de chaves inclui: rotação periódica de chaves (chaves antigas devem ser substituídas regularmente), backup seguro das chaves (perder as chaves significa perder o acesso aos dados), controle de quem pode acessar e usar cada chave, e auditoria de uso de chaves.
Criptografia em cloud pública versus cloud privada
Em cloud pública, você compartilha infraestrutura com outros clientes. A criptografia garante que os dados de um cliente não sejam acessíveis a outro, mesmo compartilhando storage físico. O provedor gerencia a infraestrutura de criptografia, e você pode usar BYOK para controlar suas chaves.
Em cloud privada — como a oferecida pela Adentro — a infraestrutura é dedicada à sua empresa. Isso simplifica alguns aspectos do modelo de criptografia: você não precisa se preocupar com isolamento de dados entre inquilinos (tenants), e a estrutura de gerenciamento de chaves pode ser desenhada em conjunto com o provedor. Dados ficam no Brasil, faturados em Real, com suporte 24/7 em português — o que facilita compliance com LGPD e outras regulações brasileiras, além de endereçar a questão de soberania de dados.
O que verificar nos contratos sobre criptografia
Quando você assina um contrato de cloud, esses pontos sobre criptografia precisam estar explícitos.
Algoritmos e versões: O contrato ou a documentação técnica deve especificar quais algoritmos são usados (AES-256, TLS 1.2/1.3) — não apenas “criptografia habilitada”. Criptografia com algoritmos obsoletos (RC4, DES, 3DES, MD5 para integridade) não é aceitável.
Quem gerencia as chaves: Provedor, cliente (BYOK) ou modelo híbrido? Onde as chaves ficam fisicamente? Em HSM dedicado? Que proteções existem contra acesso indevido pelo time do provedor?
Criptografia em trânsito interno: Os dados são criptografados apenas na comunicação externa, ou também internamente entre componentes da infraestrutura?
Destruição de dados: Quando você encerra o contrato ou deleta dados, como as chaves são destruídas? Como você garante que os dados são efetivamente inacessíveis após o encerramento? Esse ponto normalmente é tratado no DPA (Data Processing Agreement) do contrato.
O erro mais comum — ativar criptografia sem gerenciar as chaves
Na prática, o erro mais frequente é ativar a criptografia — check na lista de compliance — sem estruturar o gerenciamento de chaves. Chaves sem política de rotação, sem backup, sem controle de acesso documentado. E quando uma chave é perdida ou comprometida, o impacto é catastrófico: perda permanente de dados (se a chave se perde) ou exposição total (se a chave é comprometida).
Criptografia bem feita exige: política de rotação de chaves, backup seguro e testado das chaves, controle de quem pode acessar quais chaves, auditoria de uso, e plano para revogação de acesso quando necessário.
A Adentro pode detalhar as práticas de criptografia aplicadas ao ambiente de cloud privada. Fale com nosso time técnico para uma revisão das configurações do seu ambiente.