Criptografia em repouso (encryption at rest) é o conjunto de técnicas e controles usados para proteger dados quando eles estão armazenados: em discos, volumes, bancos de dados, snapshots, backups, objetos em storage e até em mídias removíveis. O objetivo prático é reduzir o impacto de incidentes em que um atacante obtém acesso ao meio de armazenamento (roubo de disco, cópia de snapshot, acesso indevido ao bucket, vazamento de backup, descarte inadequado de hardware) ou consegue ler arquivos diretamente no sistema (por permissões erradas, exploração local, acesso físico). Diferente de controles de acesso, a criptografia em repouso continua protegendo o conteúdo mesmo quando o armazenamento é copiado para fora do ambiente.
Na prática, “criptografar em repouso” não é uma solução única: você escolhe o nível (disco/volume, arquivo, coluna/campo, objeto) e combina com gestão de chaves, controles de acesso, auditoria e processos operacionais. A decisão principal é: em que ponto do caminho o dado vira texto cifrado e em que ponto ele volta a ser legível. Isso define o que fica protegido contra quais ameaças e quem consegue descriptografar.
Modelos de implantação: onde criptografar
1) Criptografia de disco/volume (full-disk / volume encryption)
Criptografar o disco ou volume protege blocos de armazenamento. É transparente para aplicações: o sistema operacional lê e escreve normalmente, e o driver de criptografia cifra/decifra em tempo real. É muito útil para proteger contra perda/roubo de mídia, descarte de hardware e cópia “a frio” de discos.
Limitações importantes: se o sistema estiver ligado e o volume montado, um atacante com acesso ao sistema (por credenciais, exploração ou permissões) pode ler os dados já decifrados. Portanto, criptografia de volume é excelente para “mídia fora do ambiente”, mas não substitui controles de acesso e segmentação.
2) Criptografia em nível de arquivo
Criptografar arquivos específicos (por exemplo, arquivos de exportação, relatórios, dumps, anexos) permite granularidade maior e facilita compartilhar apenas alguns artefatos de forma segura. Pode ser feito pela aplicação, por uma biblioteca, por ferramentas de linha de comando ou por mecanismos do sistema de arquivos.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
É especialmente útil quando arquivos transitam por pipelines internos (ex.: geração de relatórios e envio para um storage) e você quer que o storage armazene apenas conteúdo cifrado, reduzindo o impacto de permissões erradas no bucket.
3) Criptografia em nível de banco de dados (TDE) e em nível de coluna/campo
Em bancos de dados, há duas abordagens comuns:
Criptografia transparente (TDE): cifra páginas/arquivos do banco no disco. É semelhante à criptografia de volume, mas aplicada pelo próprio motor do banco. Protege contra cópia de arquivos do banco e backups gerados pelo motor (dependendo da configuração). É fácil de adotar e costuma ter baixo impacto na aplicação.
Criptografia em nível de coluna/campo (application-level): a aplicação cifra valores sensíveis antes de gravar no banco e decifra ao ler. Isso reduz o risco de exposição por usuários do banco, dumps, ferramentas de administração e consultas indevidas. Em troca, aumenta complexidade: indexação, busca, ordenação e agregações ficam limitadas ou exigem estratégias específicas.
Uma regra prática: TDE é um “padrão mínimo” para reduzir risco de vazamento por cópia de arquivos e backups; criptografia por campo é indicada quando você precisa reduzir o impacto de acesso indevido ao próprio banco (por exemplo, credenciais vazadas de leitura, acesso de operadores, ambientes de analytics, ou replicações para terceiros).
4) Criptografia em storage de objetos e backups
Storages de objetos (buckets) e sistemas de backup frequentemente oferecem criptografia “do lado do servidor” (o serviço cifra ao gravar) e “do lado do cliente” (você cifra antes de enviar). A diferença é crucial: na criptografia do lado do servidor, o provedor/serviço controla o processo de cifrar/decifrar e aplica políticas; na do lado do cliente, o serviço armazena apenas ciphertext e não consegue decifrar sem suas chaves.
Para backups, a recomendação operacional é tratar backup como um dos ativos mais sensíveis do ambiente: ele concentra dados e frequentemente tem retenção longa. Se um atacante obtém o backup, ele pode restaurar em outro lugar e explorar com calma. Por isso, criptografia forte e controle rigoroso de chaves e acessos são essenciais.
O que a criptografia em repouso protege (e o que não protege)
Protege bem contra:
Roubo/perda de discos, SSDs, fitas, mídias removíveis.
Cópia não autorizada de snapshots/volumes e imagens de máquina.
Exposição de arquivos de banco e arquivos de backup fora do ambiente.
Leitura direta de objetos em storage quando o atacante só tem acesso ao armazenamento, mas não às chaves.
Não resolve sozinha:
Comprometimento do sistema em execução (malware, RCE, credenciais válidas): o dado pode ser lido já decifrado.
Exfiltração via aplicação (SQL injection, endpoints indevidos): a aplicação pode devolver dados em claro.
Vazamento por logs, caches, dumps de memória e arquivos temporários: você precisa tratar esses caminhos.
Erros de autorização: criptografia não substitui RBAC/ABAC, segregação e auditoria.
Decisões de arquitetura: escolher o nível certo
Critérios práticos
Transparência vs. controle: criptografia de volume/TDE é transparente e rápida de adotar; criptografia por campo dá mais controle sobre quem vê o quê.
Impacto em funcionalidades: criptografia por campo pode impedir buscas e índices tradicionais. Se você precisa filtrar por CPF, e-mail ou número de cartão, planeje como fará consultas sem expor o valor.
Superfície de acesso: se muitos sistemas e pessoas têm acesso ao banco, criptografia por campo reduz o impacto de um acesso indevido. Se o risco principal é roubo de mídia e backups, TDE/volume pode ser suficiente.
Operação e incidentes: quanto mais camadas, mais pontos de falha (chave indisponível, rotação mal feita, restauração de backup sem chave). Planeje runbooks.
Exemplo de combinação comum
Uma arquitetura frequente em ambientes corporativos:
Criptografia de volume em todos os servidores e volumes de dados.
TDE no banco de dados para proteger arquivos e backups gerados pelo motor.
Criptografia por campo apenas para dados de alto impacto (ex.: identificadores nacionais, dados financeiros, segredos de API de clientes, tokens de sessão persistidos).
Backups cifrados com chaves separadas das chaves do ambiente de produção, com acesso altamente restrito.
Passo a passo: criptografia de disco/volume com boas práticas operacionais
O passo a passo abaixo é conceitual e aplicável tanto a servidores físicos quanto virtuais e estações, independentemente da ferramenta específica.
1) Inventariar volumes e classificar dados
Liste volumes: sistema, dados, logs, temporários, volumes anexados, volumes de containers.
Identifique onde ficam dados sensíveis e onde ficam artefatos derivados (logs, exports, caches).
2) Definir o modo de desbloqueio (boot/attach)
Para servidores: prefira desbloqueio automatizado com identidade da máquina e política de autorização (por exemplo, via serviço de chaves), evitando senhas manuais em produção.
Para endpoints: use desbloqueio por credencial do usuário e, quando possível, proteção por hardware (TPM/secure enclave), porque o risco de perda física é alto.
3) Separar chaves por ambiente e por finalidade
Não reutilize a mesma chave para volumes de produção e de homologação.
Evite usar a mesma chave para volume e para backups; isso reduz o “raio de explosão” se uma chave vazar.
4) Automatizar verificação de conformidade
Crie checagens: “todo volume anexado deve estar cifrado”, “snapshots devem herdar criptografia”, “imagens base devem estar cifradas”.
Bloqueie provisionamento fora do padrão (políticas de infraestrutura como código).
5) Testar cenários de recuperação
Simule restauração de volume e boot em ambiente isolado.
Valide que a chave correta é acessível no momento certo e que a rotação não quebrou volumes antigos.
Passo a passo: criptografia de backups com separação de responsabilidades
1) Definir o que é “backup” e onde ele vive
Inclua: dumps do banco, snapshots, exports, cópias de objetos, backups de configuração, e também metadados necessários para restaurar (catálogo, manifests, checksums).
2) Escolher o modelo de criptografia do backup
Criptografia no cliente: o agente de backup cifra antes de enviar. Vantagem: o destino armazena apenas ciphertext. Desvantagem: você precisa gerenciar chaves e rotação com cuidado e garantir que restaurações tenham acesso às chaves.
Criptografia no servidor: o repositório cifra ao receber. Vantagem: operação mais simples. Desvantagem: um comprometimento do repositório e das permissões pode permitir restauração/decifragem se as chaves estiverem no mesmo domínio de controle.
3) Isolar chaves e acessos do backup
Separe identidades: quem pode criar backup não deve necessariamente poder restaurar backup.
Restrinja restauração a um conjunto mínimo de operadores e a ambientes controlados.
Use chaves diferentes das usadas em produção para reduzir impacto de comprometimento do runtime.
4) Proteger contra ransomware e exclusão maliciosa
Ative retenção imutável (WORM) quando disponível.
Implemente cópias offline ou em conta/projeto separado.
Monitore padrões anômalos: picos de deleção, restaurações fora de janela, alterações de política.
5) Ensaiar restauração completa
Criptografia só é “bem-sucedida” se você consegue restaurar sob pressão. Faça exercícios periódicos: restaurar banco, restaurar objetos, restaurar configurações, e validar integridade do dado restaurado.
Criptografia em bancos de dados: TDE vs. criptografia por campo
TDE: onde ajuda e onde não ajuda
TDE é indicada quando você quer proteger arquivos do banco, tablespaces e, em muitos casos, backups gerados pelo motor. Ela reduz risco de alguém copiar arquivos do banco e abrir em outro lugar. Porém, usuários com permissão de leitura no banco continuam vendo dados em claro via SQL, porque o banco decifra para responder consultas.
Use TDE como base quando: você tem requisitos de compliance, usa snapshots/replicações, ou precisa reduzir risco de vazamento por cópia de disco/arquivo.
Criptografia por campo: quando vale a complexidade
Criptografia por campo é útil quando você precisa que nem todo mundo com acesso ao banco consiga ler determinados valores. Exemplos: dados pessoais altamente sensíveis, segredos de integração de clientes, chaves de API de terceiros armazenadas para uso do sistema, ou campos que aparecem em dumps e replicações para analytics.
Desafios típicos:
Busca e indexação: não dá para fazer LIKE/ORDER BY em ciphertext de forma direta. Uma estratégia comum é manter um campo auxiliar para busca, como um “token de busca” derivado do valor (por exemplo, um hash normalizado para igualdade), aceitando limitações e avaliando risco de enumeração.
Rotação: você precisa recriptografar dados ou usar envelopes de chave (uma chave de dados por registro/objeto protegida por uma chave mestra) para facilitar rotação.
Operação: migrações, ETL e jobs precisam de acesso controlado às chaves.
Exemplo prático: armazenar um campo sensível com token de busca
Suponha que você precise armazenar um identificador (ex.: documento) e permitir busca por igualdade. Uma abordagem prática é armazenar:
O valor cifrado (para confidencialidade).
Um token de busca (para igualdade), calculado sobre uma versão normalizada do valor (por exemplo, removendo pontuação e espaços), com uma chave separada e controles de acesso rigorosos.
// Pseudocódigo conceitual (não específico de linguagem) normalized = normalize(documento) token_busca = HMAC(chave_token, normalized) valor_cifrado = Encrypt(chave_dados, documento) INSERT INTO clientes(documento_enc, documento_token) VALUES(valor_cifrado, token_busca) // Para buscar: token = HMAC(chave_token, normalize(entrada)) SELECT * FROM clientes WHERE documento_token = tokenCuidados: tokens de busca podem permitir ataques por tentativa se o espaço de valores for pequeno (por exemplo, CEP). Para esses casos, avalie se a funcionalidade de busca é realmente necessária, se dá para limitar tentativas, e se é melhor usar outro identificador interno para consultas.
Criptografia em storage de objetos: padrões seguros
Riscos comuns em objetos
Bucket público por engano ou políticas permissivas.
Credenciais de aplicação vazadas com permissão ampla.
Objetos com dados sensíveis em caminhos previsíveis.
Logs e exports armazenados sem proteção.
Boas práticas
Criptografia padrão no bucket: configure para que todo objeto gravado seja cifrado automaticamente.
Negar uploads sem criptografia: políticas que rejeitam PUT sem os cabeçalhos/flags esperados (quando aplicável).
Chaves por domínio: separe chaves por tipo de dado (ex.: anexos de clientes vs. logs internos) e por ambiente.
Controle de acesso mínimo: aplicações devem ter permissão apenas para prefixos necessários e operações necessárias (ler/gravar/listar).
Auditoria: registre acessos e mudanças de política; alerte para downloads massivos e listagens incomuns.
Armadilhas frequentes (e como evitar)
1) “Está cifrado, então posso relaxar permissões”
Não. Se o mesmo principal (usuário/serviço) que lê o dado também tem permissão de usar a chave para decifrar, um vazamento de credenciais pode expor tudo. Criptografia em repouso reduz impacto de cópia do armazenamento, mas não substitui autorização.
2) Chaves e dados no mesmo domínio de comprometimento
Um erro comum é armazenar chaves (ou credenciais para obtê-las) no mesmo servidor que guarda os dados, com permissões amplas. Um atacante que compromete o servidor leva dados e chaves. Mitigue com segregação: serviço de chaves separado, políticas restritivas, identidades de workload e logs de uso de chave.
3) Backups esquecidos
É comum criptografar o banco e o disco, mas deixar dumps manuais, exports e backups antigos sem criptografia, em diretórios compartilhados ou buckets. Trate “artefatos derivados” como parte do escopo: dumps, CSVs, relatórios, anexos, snapshots e replicações.
4) Rotação sem plano de migração
Rotacionar chaves pode quebrar restaurações e leituras históricas se você não mantiver a capacidade de decifrar dados antigos durante uma janela controlada. Planeje: versionamento de chaves, metadados indicando qual chave foi usada, e testes de restauração.
5) Vazamento por logs e observabilidade
Mesmo com criptografia em repouso, dados sensíveis podem aparecer em logs de aplicação, traces, mensagens de erro, payloads de fila e métricas. Defina padrões: mascaramento, redaction, e proibição de logar campos sensíveis.
Checklist operacional para adoção consistente
Todo volume/disco com dados deve estar cifrado por padrão; provisionamento sem criptografia deve ser bloqueado.
Banco de dados com TDE habilitado quando suportado; backups do motor verificados quanto a criptografia.
Backups com criptografia e retenção protegida; restauração testada periodicamente.
Storage de objetos com criptografia padrão e políticas que evitem gravação fora do padrão.
Separação de chaves por ambiente e por domínio de dados; acesso às chaves com menor privilégio.
Monitoramento de uso de chaves e de acessos a backups/objetos; alertas para anomalias.
Inventário de onde dados sensíveis aparecem (inclusive exports, logs e caches) e tratamento consistente.
