Criptografia em Repouso (KMS, AES)

Criptografia em repouso é a proteção aplicada aos dados enquanto armazenados, em discos, objetos, snapshots, backups e arquivos de log. O objetivo é que a mídia comprometida, um volume perdido, um snapshot compartilhado por engano ou um backup esquecido em storage legado, não revele conteúdo legível sem a chave correta. O algoritmo dominante é o AES, na prática AES-256 com modos de operação que unem confidencialidade e integridade, e a gestão de chaves fica tipicamente em um serviço como o AWS KMS. Em produção o tema é linha de base: contratos corporativos, auditorias e frameworks de compliance tratam criptografia em repouso como requisito obrigatório, não opcional. Este arquivo cobre as camadas de implementação, o envelope encryption, as opções de S3 e RDS e os trade-offs de custo e latência.

Conceito e fronteira com o trânsito

A criptografia em repouso protege o dado parado; a criptografia em trânsito protege o dado em movimento; os dois controles são complementares e a ausência de um invalida parte do valor do outro. Em repouso, a definição operacional é cifrar os bytes gravados no meio de armazenamento com uma chave que não vive junto do dado, de modo que acesso ao meio não equivalha a acesso ao conteúdo. Essa separação entre dado e chave é o que cria o valor de segurança: o invasor que copia um volume cifrado obtém material inútil, e a chave permanece sob política própria no serviço de chaves. A separação também viabiliza controles administrativos potentes, como revogar a chave para tornar uma cópia indecifrável de imediato.

O conceito inclui todos os lugares onde o dado persiste, e é aí que arquitetos erram por omissão. Volume de banco é o caso óbvio; snapshots, backups, réplicas de leitura, filas com persistência, logs, exports em data lake e repositórios de objetos são o resto. Cada novo lugar de persistência precisa herdar criptografia por padrão, garantida por política e não por lembrança de quem criou o recurso.

O problema que resolve

O vetor de ataque clássico é a cópia silenciosa da mídia: um snapshot publicado na conta errada, um disco descartado sem sanitização, um backup replicado para storage sem controle de acesso. Sem criptografia em repouso, cada cópia do dado é um dado novo em texto claro, e o controle de acesso de cada cópia precisa ser perfeito para sempre. Com criptografia, a cópia vira material cifrado cujo uso depende de uma chamada auditável ao serviço de chaves, o que desloca o ponto de controle para um lugar centralizável.

A última linha da tabela merece nuance: quem tem permissão de leitura pela aplicação continua lendo o dado, porque a criptografia em repouso não substitui autorização. O que ela impede é o acesso bruto ao meio, que é uma classe de incidente completamente diferente do acesso via aplicação.

AES-256 e modos de operação

O AES é uma cifra de bloco que processa dados em blocos de 128 bits com chaves de 128, 192 ou 256 bits, e o padrão de mercado para dados em repouso é AES-256. O tamanho da chave, porém, importa menos que o modo de operação: o mesmo AES em modo fraco vira superfície de ataque. Os modos relevantes em produção são o GCM, que fornece confidencialidade e integridade na mesma operação, categoria conhecida como AEAD, e o XTS, usado em cifragem de disco porque suporta acesso aleatório por setor sem quebrar o layout. Modos legacy como CBC e ECB aparecem apenas em sistemas antigos e não devem ser escolhidos para implementações novas.

Dois detalhes práticos definem a segurança real de uma implementação. O vetor de inicialização precisa ser único por operação, pois reuso de IV em GCM quebra o sigilo de forma catastrófica e silenciosa. E o custo computacional do AES é irrelevante em hardware moderno: processadores x86 e ARM executam a cifra em instruções dedicadas, então a decisão de cifrar não deve ser travada por medo de performance.

Camadas de implementação: bloco, objeto e aplicação

A criptografia em repouso pode ser aplicada em diferentes alturas do stack, e cada altura resolve um problema distinto. A tabela resume as camadas usuais com exemplos e limitações, e a leitura correta é de combinação, não de escolha exclusiva.

As camadas atendem ameaças diferentes. Bloco e objeto protegem a mídia; criptografia em nível de aplicação protege o dado até contra administradores do banco e operadores da plataforma, que é a separação de funções mais profunda. Sistemas com dados sensíveis costumam combinar cifra de storage como linha de base e cifra de campo para o conjunto pequeno de atributos realmente críticos.

Envelope encryption

O envelope encryption é o padrão que resolve um problema físico: serviços de chave como o KMS não foram projetados para cifrar payloads grandes, apenas chaves. O fluxo funciona assim: a aplicação solicita ao KMS uma chave de dados de 256 bits; o KMS devolve duas versões, a chave em texto claro e a mesma chave cifrada pela CMK; a aplicação cifra o payload localmente com a chave clara e descarta-a em seguida; a chave cifrada é armazenada ao lado do dado. Para ler, a aplicação envia a chave cifrada ao KMS, recebe a chave clara e decifra o payload. O resultado é cifragem local em qualquer volume, com toda a decisão de uso da CMK passando pelo KMS e ficando registrada em trilha de auditoria.

# Gera a chave de dados: a versão plana cifra o payload localmente
# e a versão cifrada pela CMK é guardada junto do dado
aws kms generate-data-key \
    --key-id alias/financeiro-dados \
    --key-spec AES_256 \
    --output json

# Plaintext: use, cifre o conteúdo e descarte imediatamente da memória
# CiphertextBlob: persista ao lado do arquivo ou campo cifrado

A otimização que acompanha o padrão é o cache de chaves de dados, o Data Key Caching do KMS, que reutiliza chaves dentro de um TTL e de um limite de uso. Sem cache, workloads de alto throughput pagam uma chamada ao KMS por objeto, o que aparece tanto em latência quanto em fatura.

S3: SSE-S3, SSE-KMS e SSE-C

O S3 oferece três modos de criptografia no lado do serviço, e a escolha define quem controla a chave e quão fina é a auditoria.

O SSE-KMS é a escolha padrão para dados regulados porque cada leitura e escrita passa pelo KMS e gera log individual, permitindo responder quem acessou o quê e quando. O custo disso é uma chamada por operação, o que em buckets de altíssimo throughput exige planejamento de quota. O SSE-S3 permanece adequado para dados não sensíveis, e o SSE-C é nicho, reservado a integrações em que o cliente se recusa a delegar a chave.

O S3 aplica hoje criptografia por padrão em todos os novos objetos, o que eliminou o bucket sem cifra por desatenção. O padrão, porém, usa chave da AWS e não resolve controle granular: para dados regulados, a política de exigir SSE-KMS permanece necessária, porque define não apenas que haverá cifra, mas qual chave e quem audita o uso dela.

A garantia de que nada entra sem cifra não vem da configuração padrão, e sim de política. A policy abaixo nega qualquer PUT que não use SSE-KMS, transformando a criptografia em regra do bucket.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ExigirCriptografiaComKMS",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::dados-financeiros-prod/*",
    "Condition": {
      "StringNotEquals": {
        "s3:x-amz-server-side-encryption": "aws:kms"
      }
    }
  }]
}

RDS, TDE e bancos relacionais

No RDS, a criptografia em repouso é habilitada na criação da instância e cobre armazenamento, snapshots, réplicas e backups automáticos, com a chave residindo no KMS. A limitação operacional relevante é que instâncias criadas sem cifra não podem ser cifradas in place: o caminho é copiar o snapshot com criptografia e restaurar, com janela de indisponibilidade planejada. Bancos com TDE nativo, como SQL Server e Oracle, movem a cifra para o próprio motor e exigem gestão da chave mestra, frequentemente integrada ao KMS ou a um HSM. PostgreSQL e MySQL gerenciados não têm TDE equivalente e dependem da cifra de storage, o que cobre o mesmo requisito com fronteira um pouco diferente.

O custo de performance de cifra de storage em bancos gerenciados fica em poucos por cento na prática, com o hardware acelerando AES. O ponto de atenção real é a chave: cada réplica e cada snapshot herdam a CMK da origem, então a política de acesso à chave define quem pode restaurar o banco em outra conta, e essa análise precisa existir antes de compartilhar qualquer snapshot.

Criptografia nos demais serviços gerenciados

A linha de base precisa cobrir todo o ecossistema de persistência, e os serviços gerenciados variam entre cifra por padrão e cifra opt-in.

O padrão de decisão é uniforme: cifra por padrão com chave da AWS para dados sem sensibilidade, e CMK dedicada com política restrita para tudo que é regulado. O inventário deve ser verificado por ferramenta de IaC, porque um único recurso criado fora do padrão já é achado de auditoria.

Custo e latência

Os custos de criptografia em repouso se dividem em três linhas: o custo computacional da cifra, hoje desprezível com aceleração de hardware; o custo por requisição ao KMS, cobrado por milhares de chamadas, que cresce com o throughput do workload; e o custo de latência, percebido quando cada operação depende de uma ida ao serviço de chaves. Em cargas com milhões de objetos por hora, o item dominante é a requisição de KMS, não a cifra. As mitigações são conhecidas: cache de chaves de dados com TTL curto, chave por domínio em vez de chave por objeto e reserva de throughput quando o padrão de acesso justifica.

A latência adicionada pelo KMS é de milissegundos por chamada, invisível na maioria dos casos e perceptível em hot paths de objetos pequenos. A decisão de engenharia é medir o p95 do caminho real e otimizar apenas onde a medição apontar, evitando ajustes prematuros que enfraquecem a trilha de auditoria.

Quando a criptografia no nível de aplicação faz sentido

A cifra no nível da aplicação entra quando a ameaça muda de qualidade: o risco não é mais a mídia roubada, e sim alguém com acesso legítimo à infraestrutura de dados, como um operador do banco, um administrador do data warehouse ou um pipeline de analytics. Nesse desenho, campos sensíveis como documento, dados financeiros e credenciais de pagamento são cifrados pela aplicação antes de persistir, com chave que o banco jamais vê. O benefício é a separação de funções máxima: quem administra o armazenamento não lê o conteúdo, mesmo com acesso total às tabelas.

O custo é arquitetural e deve ser aceito com consciência. Consultas sobre campos cifrados perdem índice e busca nativa, exigindo padrões como cifragem determinística ou índice cego, o blind index, para lookup por igualdade. A rotação de chaves passa a ser código da aplicação, e qualquer vazamento da chave no serviço anula o esquema. Por isso a recomendação é seletiva: cifra de campo para o conjunto pequeno de atributos que justificam o custo, e cifra de storage para o volume restante.

Erros comuns

• Cifrar o volume e esquecer snapshots, backups e exports: cada cópia sem cifra reabre a exposição que o controle pretendia fechar.
• Usar uma única CMK para tudo: a chave onipresente destrói granularidade de auditoria e amplia o raio de comprometimento.
• Criar o RDS sem cifra e descobrir depois: habilitar exige cópia e restauração, então a cifra desde a criação é decisão de projeto.
• Tratar criptografia como substituto de autorização: quem tem permissão de leitura pela aplicação lê o dado, cifra não corrige permissão.
• Cachear chaves de dados sem TTL: cache eterno anula revogação e mantém material sensível vivo além do necessário.
• Ignorar a quota de requisições do KMS: picos de escrita em buckets com SSE-KMS podem sofrer throttling em horário crítico.

Boas práticas

• Adotar SSE-KMS com CMK dedicada por domínio de dados, usando o CloudTrail como trilha de acesso ao conteúdo sensível.
• Garantir criptografia por política, com denial de PUT sem cifra no S3 e SCPs que exigem EBS cifrado, em vez de confiar no padrão do serviço.
• Habilitar criptografia na criação de qualquer recurso com storage, tratando recurso sem cifra como desvio de IaC no review.
• Aplicar envelope encryption com cache de chave de dados dimensionado por TTL e limite de uso para workloads de alto throughput.
• Reservar cifragem em nível de aplicação para campos de alta sensibilidade, com índice cego quando o lookup por igualdade for requisito.
• Medir p95 e custo de requisições KMS desde o piloto, para escalar a solução sem surpresa de latência ou fatura.