Proteger dados na nuvem passa quase sempre por uma pergunta prática: onde e como aplicar criptografia. A resposta muda conforme o dado está parado em um disco ou banco de dados, ou viajando entre sistemas pela rede. Neste artigo, explicamos a diferença entre criptografia em repouso e em trânsito, como funciona a gestão de chaves nos três grandes provedores de nuvem e o que normas como LGPD, ISO 27001 e NIST realmente pedem.
Criptografia em repouso e em trânsito: qual a diferença
Criptografia em repouso protege dados armazenados: arquivos em um bucket de armazenamento de objetos, volumes de disco, backups, bancos de dados. O objetivo é garantir que, mesmo que alguém tenha acesso físico ou lógico ao meio de armazenamento, os dados permaneçam ilegíveis sem a chave correta.
Criptografia em trânsito protege dados enquanto trafegam pela rede, entre um cliente e um servidor, entre serviços dentro da nuvem, ou entre regiões diferentes de um mesmo provedor. Aqui entram protocolos como TLS para conexões HTTPS e VPNs para tráfego interno.
Na prática, os dois tipos são complementares: um não substitui o outro. Um dado pode estar bem protegido em repouso e ainda assim vazar se a conexão que o transporta não usar TLS. Da mesma forma, uma API bem protegida por HTTPS não impede que um volume de disco desprotegido seja acessado diretamente por alguém com privilégios indevidos.
Nos três grandes provedores, boa parte da criptografia em trânsito entre a infraestrutura interna já é tratada pelo próprio provedor. Mas, sob o modelo de responsabilidade compartilhada, cabe ao cliente habilitar a criptografia em repouso em serviços como discos (EBS), bancos gerenciados (RDS) e buckets de armazenamento, além de impor HTTPS em suas próprias aplicações e escolher a estratégia de chaves adequada.
Como funciona o envelope encryption
AWS, Azure e Google Cloud adotam um padrão semelhante para gestão de chaves conhecido como envelope encryption. A ideia é simples: em vez de usar diretamente a chave mestra para cifrar grandes volumes de dados, o sistema gera uma chave local, chamada Data Encryption Key (DEK), que cifra os dados de fato.
Essa DEK, por sua vez, é protegida por uma Key Encryption Key (KEK), que nunca sai do serviço de gerenciamento de chaves (KMS). Esse desenho reduz o número de chamadas ao KMS em operações em massa, o que ajuda em custo e latência, sem abrir mão da segurança da chave mestra.
Boas práticas recomendadas pelo Google Cloud incluem usar AES-256-GCM para as DEKs, nunca armazenar a DEK em texto plano e rotacionar as KEKs com regularidade. Esses princípios valem, com pequenas variações, para qualquer provedor que siga o mesmo padrão.
Gestão de chaves: AWS KMS, Azure Key Vault e Google Cloud KMS
Os três serviços resolvem o mesmo problema com ênfases diferentes:
- AWS KMS: opera dentro do modelo de responsabilidade compartilhada. A AWS cuida da criptografia em trânsito entre os componentes de sua própria infraestrutura, mas o cliente decide entre usar uma chave gerenciada pela própria AWS (AWS-owned key) ou uma chave gerenciada pelo cliente (customer-managed key, CMK), com mais controle sobre rotação e políticas de acesso.
- Azure Key Vault: unifica a gestão de secrets, certificados e chaves criptográficas em um único serviço, o que é particularmente útil em cenários híbridos, com cargas de trabalho on-premises e na nuvem convivendo.
- Google Cloud KMS: se destaca pela distribuição global de chaves e por uma integração robusta com o IAM, suportando tanto chaves gerenciadas pelo cliente (CMEK) quanto chaves fornecidas pelo cliente (CSEK).
Se a estratégia envolver um serviço de KMS externo ou de terceiros, vale verificar se ele possui validação FIPS 140-3, consultando a lista pública do CMVP mantida pelo NIST.
O que a LGPD realmente exige (e o que não exige)
Um ponto de confusão comum é achar que a LGPD (Lei 13.709/2018) obriga o uso de criptografia. Não é bem assim. O artigo 46 da lei exige que agentes de tratamento adotem "medidas de segurança, técnicas e administrativas" para proteger dados pessoais, mas o texto não cita criptografia de forma explícita como obrigação.
O que a lei prevê, no §1º do artigo 46, é que a Autoridade Nacional de Proteção de Dados (ANPD) pode vir a estabelecer padrões técnicos mínimos, levando em conta o "estado atual da tecnologia". Até o momento, isso significa que a criptografia é uma prática recomendada e amplamente adotada pelo mercado, não uma exigência literal da lei.
O §2º do mesmo artigo reforça o conceito de privacy by design: as medidas de segurança devem ser consideradas desde a concepção do produto ou serviço, não apenas quando ele já está em produção. Na prática, isso significa que decisões sobre onde e como cifrar dados devem entrar na arquitetura desde o início, e não como um remendo posterior.
Checklist de conformidade: ISO 27001, ISO 27017, ISO 27018 e CIS Benchmarks
Para times técnicos que buscam uma referência mais objetiva do que a LGPD, vale olhar para normas internacionais amplamente reconhecidas:
- ISO/IEC 27001:2022, no controle 8.24 do Anexo A ("Uso de criptografia"), exige uma política formal cobrindo padrões de cifragem, gestão de chaves e aspectos legais aplicáveis.
- ISO/IEC 27017:2015 complementa o ISO 27002 com controles específicos para serviços em nuvem, incluindo segregação de dados entre clientes e segurança de rede.
- ISO/IEC 27018:2019 foca na proteção de dados pessoais (PII) em nuvem pública quando o provedor atua como operador, orientando a criptografia de PII tanto em repouso quanto em trânsito.
- CIS Benchmarks para AWS, Azure e GCP trazem recomendações práticas de nível 1 e 2, incluindo o uso de chaves gerenciadas pelo cliente (CMK) para volumes de disco.
Do lado da gestão de chaves em si, o NIST SP 800-57 Parte 1 Revisão 5 segue sendo a referência vigente. Uma Revisão 6 está em consulta pública desde o fim de 2025, mas ainda não é a versão oficial, então vale manter a Rev. 5 como base até que isso mude. Já o NIST SP 800-53 Rev. 5 traz os controles SC-13 e SC-28, referenciados por ferramentas como o AWS Security Hub para cobrar o uso de chaves KMS gerenciadas pelo cliente em criptografia em repouso.
Erros comuns que enfraquecem a criptografia
Ter criptografia habilitada não é garantia de proteção se a gestão em volta dela for frágil. Os erros mais recorrentes incluem:
- Deixar buckets ou volumes com configuração padrão, sem revisar se a criptografia em repouso está de fato ativa.
- Usar sempre a chave padrão do provedor quando o caso pedia uma chave gerenciada pelo cliente, com controle próprio de rotação e revogação.
- Não rotacionar chaves com regularidade, mesmo quando o provedor oferece rotação automática.
- Confiar apenas na criptografia sem cuidar da autenticação do material de chave, o que pode permitir que um atacante substitua a chave e burle a proteção mesmo com a cifragem ativa.
Falhas identificadas entre 2024 e 2025 em algumas plataformas de armazenamento com criptografia ponta a ponta ilustram exatamente esse risco: sem autenticação adequada da chave, atacantes conseguiram substituí-la sem que a vítima percebesse. A lição prática é que a gestão de chaves precisa ser tão robusta quanto o próprio algoritmo de criptografia.
Conclusão
Criptografia em nuvem funciona melhor como uma combinação de decisões bem pensadas: proteger dados em repouso e em trânsito, adotar o padrão de envelope encryption, escolher entre chaves gerenciadas pelo provedor ou pelo cliente de forma consciente, e alinhar tudo isso às normas relevantes, como LGPD, ISO 27001 e as diretrizes do NIST. Nenhuma dessas escolhas precisa ser feita isoladamente ou sob pressão.
Se sua empresa quer revisar a estratégia de criptografia e gestão de chaves na nuvem, a Cloud Minds Trusted pode ajudar a mapear o cenário atual e priorizar os próximos passos.