Criptografia em repouso e em trânsito — o que é e como ativar no Postgres e no MongoDB

Outro dia, revisando a documentação de infraestrutura de um banco, encontrei esta linha sobre uma réplica de leitura:

Criptografada em repouso com KMS (StorageEncrypted=true), como a primária.

É o tipo de frase que aparece em todo documento de arquitetura, checklist de auditoria e questionário de segurança. Todo mundo marca “sim” e segue em frente. Mas vale entender o que ela garante, o que ela não garante e qual é a irmã dela, a criptografia em trânsito.

Neste post vou passar pelos dois conceitos e mostrar como ativar cada um no PostgreSQL (no RDS e fora dele) e no MongoDB (no Atlas e fora dele). No final, falo rapidamente de um terceiro tipo, bem menos comum: a criptografia em uso.

De onde vem o termo

“Criptografia em repouso” é a tradução literal de encryption at rest. Em segurança da informação, é comum separar o dado em três estados, porque cada um tem riscos diferentes e pede proteções diferentes:

“Repouso” é o dado descansando: gravado em algum lugar, esperando ser lido. Em português o termo soa um pouco estranho no começo, mas é o que aparece em normas e documentações traduzidas.

Criptografia em repouso

Na maioria das implementações ela é transparente: o banco (ou o storage por baixo dele) cifra ao gravar e decifra ao ler, e a aplicação não percebe nada. Não muda query, não muda driver. Quando é o próprio banco que cifra os arquivos, o recurso costuma se chamar TDE, de Transparent Data Encryption, como no Oracle e no SQL Server. No RDS, a criptografia acontece no storage, e a AWS não a chama de TDE (nota: é no storage, não no banco).

Onde entra o KMS

A frase do começo fala em KMS. O KMS (Key Management Service) é o cofre de chaves, e o esquema usado quase sempre é o de envelope encryption.

Na figura, o KMS, o banco e o disco ficam lado a lado, e os números seguem a ordem do que acontece: a chave de dados cifra o dado, a chave mestra cifra a chave de dados e, para ler, o banco pede ao KMS para abrir a chave. Em Passo a passo, a figura se monta um passo por vez, e o traço embaixo dela mostra quando cada passo terminou.

O ganho é que o acesso ao dado passa a depender também de quem pode usar a chave. Se a chave for desativada ou apagada, os dados ficam ilegíveis, inclusive os backups. Tirar a permissão de um usuário não basta: no RDS, o banco guarda uma autorização própria na chave (um grant), criada junto com a instância.

O que ela protege e o que não protege

Ela protege contra:

• roubo ou descarte indevido de disco;
• acesso a snapshots e backups por quem não tem permissão na chave;
• parte das exigências de auditoria: as normas do Banco Central (Resolução CMN 4.893) põem a criptografia entre os controles mínimos de segurança cibernética, e a LGPD, que pede medidas de segurança sem citar a criptografia, leva em conta, num incidente, se os dados vazados estavam ininteligíveis. Para número de cartão ela ajuda, mas não basta: desde a versão 4.0, o PCI DSS (requisito 3.5.1.2 (nota: vale desde 31/03/2025)) não aceita a criptografia de disco como única proteção do número do cartão, e é preciso também tokenizar, truncar ou cifrar o campo.

Ela não protege contra:

O primeiro item é o mais mal-entendido.

Criptografia em repouso não é controle de acesso.

Ela protege o meio onde o dado está gravado, e não o dado contra quem pode consultá-lo.

Criptografia em trânsito

Aqui o dado está saindo da aplicação e indo para o banco, voltando, ou indo de um nó do cluster para outro. A proteção é o TLS, o mesmo protocolo do HTTPS, e ele resolve dois problemas:

• Sigilo: quem intercepta o tráfego não consegue ler.
• Autenticidade: quando o cliente valida o certificado, ele tem certeza de que está falando com o banco certo, e não com alguém no meio do caminho.

Na figura, as duas linhas mostram a mesma conexão, com alguém no meio do caminho: em cima, com require; embaixo, com verify-full. Em Passo a passo, primeiro se vê o que acontece com require e depois com verify-full.

A própria documentação do PostgreSQL resume isso numa tabela: com require, a coluna de proteção contra man-in-the-middle diz “No”; só com verify-full ela diz “Yes”.

PostgreSQL no Amazon RDS

Em repouso

No RDS, a criptografia em repouso é ligada na criação da instância e usa uma chave do AWS KMS. Ela cobre o storage, os backups automáticos, os snapshots, os logs e as réplicas de leitura. No console é a opção Enable encryption. Na API, na CLI e no CloudFormation é o StorageEncrypted.

Pela CLI:

aws rds create-db-instance \
  --db-instance-identifier pedidos-db \
  --engine postgres \
  --db-instance-class db.t4g.medium \
  --allocated-storage 50 \
  --master-username pgadmin \
  --manage-master-user-password \
  --storage-encrypted \ (nota: é isto que liga)
  --kms-key-id alias/rds-pedidos

Com Terraform:

resource "aws_kms_key" "rds" {
  description = "Chave do RDS de pedidos"
}

resource "aws_db_instance" "pedidos" {
  identifier                  = "pedidos-db"
  engine                      = "postgres"
  instance_class              = "db.t4g.medium"
  allocated_storage           = 50
  username                    = "pgadmin"
  manage_master_user_password = true

  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn (nota: liga e escolhe a chave)
}

Para conferir as instâncias que você já tem:

aws rds describe-db-instances \
  --query "DBInstances[].{instancia:DBInstanceIdentifier,criptografada:StorageEncrypted,chave:KmsKeyId}" \
  --output table

Três pontos de atenção:

aws rds create-db-snapshot \
  --db-instance-identifier pedidos-db \
  --db-snapshot-identifier pedidos-sem-cripto

aws rds wait db-snapshot-available --db-snapshot-identifier pedidos-sem-cripto

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier pedidos-sem-cripto \
  --target-db-snapshot-identifier pedidos-cripto \
  --kms-key-id alias/rds-pedidos

aws rds wait db-snapshot-available --db-snapshot-identifier pedidos-cripto

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier pedidos-db-v2 \
  --db-snapshot-identifier pedidos-cripto

Réplicas herdam a criptografia. Uma réplica de uma primária criptografada é obrigatoriamente criptografada, e é daí que vem o “como a primária” da frase do começo. Uma réplica em outra região usa uma chave KMS daquela região.

Em trânsito

O RDS já cria o certificado da instância. Faltam duas coisas: o servidor exigir TLS e o cliente validar o certificado.

No servidor, quem manda é o parâmetro rds.force_ssl. A partir do PostgreSQL 15 ele já vem ligado (1) por padrão. Nas versões anteriores ele vem desligado, e você precisa criar um parameter group customizado com rds.force_ssl = 1 e associá-lo à instância (com reboot, se ela já estiver rodando).

No cliente, baixe o pacote de certificados da AWS e use verify-full:

curl -o global-bundle.pem https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

psql "host=pedidos-db.xxxx.sa-east-1.rds.amazonaws.com port=5432 dbname=pedidos \
      user=app sslmode=verify-full sslrootcert=global-bundle.pem"

Em Java, pela URL do JDBC:

jdbc:postgresql://pedidos-db.xxxx.sa-east-1.rds.amazonaws.com:5432/pedidos?sslmode=verify-full&sslrootcert=/etc/certs/global-bundle.pem

Por que não confiar no padrão? Porque tanto o psql quanto o driver JDBC usam sslmode=prefer (nota: aceita conexão sem TLS): tentam TLS, aceitam cair para uma conexão sem criptografia e não validam o certificado.

Para ver quem está conectado com TLS (com o usuário mestre ou um usuário com pg_monitor, porque um usuário comum só vê as próprias sessões):

SELECT a.usename, a.client_addr, s.ssl, s.version
FROM pg_stat_ssl s (nota: uma linha por conexão)
JOIN pg_stat_activity a ON a.pid = s.pid
WHERE a.backend_type = 'client backend';

PostgreSQL fora do RDS

Em trânsito

O TLS é nativo no Postgres. Com o certificado e a chave do servidor em mãos (de uma CA interna ou pública), é só configuração.

No postgresql.conf:

ssl = on
ssl_cert_file = '/etc/postgresql/tls/server.crt'
ssl_key_file  = '/etc/postgresql/tls/server.key'
ssl_min_protocol_version = 'TLSv1.2'

No pg_hba.conf, aceite conexões remotas só com TLS. Essas linhas entram no lugar das linhas host que já existem, porque vale a primeira linha que casar:

# TYPE     DATABASE  USER  ADDRESS     METHOD
hostssl    all       all   0.0.0.0/0   scram-sha-256
hostssl    all       all   ::/0        scram-sha-256
hostnossl  all       all   0.0.0.0/0   reject
hostnossl  all       all   ::/0        reject (nota: sem TLS, recusado)

Em repouso

1. Criptografar o volume. LUKS (dm-crypt) em servidor próprio, ou um volume criptografado na nuvem, como um EBS criptografado numa EC2. É o caminho mais comum, e protege contra roubo do disco e de snapshots do volume.

# Atenção: apaga o disco. Use um disco dedicado aos dados.
cryptsetup luksFormat /dev/nvme1n1
cryptsetup open /dev/nvme1n1 pgdata
mkfs.xfs /dev/mapper/pgdata
mount /dev/mapper/pgdata /var/lib/postgresql
# depois: chown postgres:postgres /var/lib/postgresql e as entradas no /etc/crypttab e no /etc/fstab

A limitação é que, com o volume montado, o sistema de arquivos já enxerga tudo decifrado. Quem tem acesso ao servidor ligado lê os arquivos normalmente. Também é preciso decidir como o volume é destravado no boot (senha manual, TPM, Clevis/Tang), e essa é a parte que dá trabalho.

2. Usar TDE de uma distribuição. O Percona Distribution for PostgreSQL tem a extensão open source pg_tde, que cifra dentro do próprio banco as tabelas criadas com tde_heap (com os índices delas e, se você ligar, o WAL), com as chaves guardadas num Vault, OpenBao ou servidor KMIP. Ela depende do Percona Server for PostgreSQL, uma versão do Postgres modificada pela Percona, e não roda no Postgres da comunidade. Há também opções comerciais, como o EDB Postgres Advanced Server.

-- postgresql.conf: shared_preload_libraries = 'pg_tde' (e reinicie o servidor)
CREATE EXTENSION pg_tde;

-- configure o provedor de chaves (Vault, OpenBao ou KMIP) e a chave principal;
-- as funções mudam entre versões, então siga a documentação da versão instalada

CREATE TABLE cartao (
  id     bigint PRIMARY KEY,
  numero text NOT NULL
) USING tde_heap; (nota: só estas tabelas são cifradas)

3. Não esquecer dos backups. Um banco criptografado com backups em texto claro num bucket qualquer não resolve nada. O pgBackRest, por exemplo, cifra o repositório de backups com repo1-cipher-type=aes-256-cbc e repo1-cipher-pass.

MongoDB Atlas

Em repouso

No Atlas, a criptografia em repouso já vem ligada em todos os clusters, sem configuração. O Atlas usa a criptografia de volume do provedor de nuvem (na AWS, EBS criptografado).

Se você precisa controlar a chave para rotacionar, revogar e auditar o uso, existe a opção Encryption at Rest using Customer Key Management, também chamada de BYOK (bring your own key). Com ela, o Atlas cifra os dados uma segunda vez, no Encrypted Storage Engine do MongoDB, usando uma chave sua no AWS KMS, no Azure Key Vault ou no Google Cloud KMS. Ela só está disponível em clusters dedicados, do M10 para cima.

Na AWS, os passos são:

1. 1Criar uma chave simétrica no AWS KMS.
2. 2Criar um IAM role que o Atlas possa assumir, com permissão de kms:Encrypt, kms:Decrypt e kms:DescribeKey nessa chave.
3. 3No projeto do Atlas, configurar o Encryption at Rest com o AWS KMS, informando a chave, a região e o role.
4. 4Ligar a opção em cada cluster que deve usar a chave.

Com Terraform:

resource "mongodbatlas_encryption_at_rest" "this" {
  project_id = var.atlas_project_id

  aws_kms_config {
    enabled                = true
    customer_master_key_id = aws_kms_key.atlas.id
    region                 = "SA_EAST_1"
    role_id                = mongodbatlas_cloud_provider_access_authorization.atlas.role_id
  }
}

resource "mongodbatlas_advanced_cluster" "pedidos" {
  # o project_id vem do recurso acima, para o cluster esperar a criptografia estar configurada
  project_id                  = mongodbatlas_encryption_at_rest.this.project_id
  encryption_at_rest_provider = "AWS" (nota: o cluster espera a chave)
  # ... demais configurações do cluster
}

Em trânsito

conferido em set/2026

MongoDB fora do Atlas

Em trânsito

No mongod.conf:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.1.15
  tls:
    mode: requireTLS (nota: recusa conexão sem TLS)
    certificateKeyFile: /etc/mongodb/tls/mongod.pem   # certificado + chave privada
    CAFile: /etc/mongodb/tls/ca.pem
    # clientes sem certificado autenticam com usuário e senha (security.authorization ligado)
    allowConnectionsWithoutCertificates: true
    disabledProtocols: TLS1_0,TLS1_1

Com requireTLS, a comunicação entre os membros do replica set também passa a exigir TLS. Se o certificado não tiver o uso clientAuth, os membros não conseguem conversar entre si. Gere-o com clientAuth ou use setParameter: tlsWithholdClientCertificate: true com autenticação interna por keyFile.

Para migrar um ambiente que já está no ar sem derrubar tudo, reinicie os membros um de cada vez com allowTLS, passe os clientes para TLS e só então troque todos para preferTLS e, por fim, para requireTLS (com setParameter, sem reiniciar). Cada etapa precisa chegar a todos os membros (nota: senão, o primário cai) antes da próxima, e no fim o mongod.conf fica com requireTLS.

No cliente:

mongodb://app:<senha>@mongo1.interno:27017,mongo2.interno:27017/?replicaSet=rs0&tls=true&tlsCAFile=/etc/certs/ca.pem

Em repouso

Aqui depende da edição do MongoDB.

Community: não tem criptografia em repouso nativa. O caminho é o mesmo do Postgres autogerenciado: volume criptografado (LUKS, EBS criptografado e afins).

Enterprise: tem o Encrypted Storage Engine, que cifra os arquivos do WiredTiger. O recomendado é que a chave mestra venha de um servidor KMIP:

security:
  enableEncryption: true
  kmip:
    serverName: kmip.interno
    port: 5696
    serverCAFile: /etc/mongodb/kmip/ca.pem
    clientCertificateFile: /etc/mongodb/kmip/mongod-client.pem

Percona Server for MongoDB: alternativa gratuita e compatível com o MongoDB, de código-fonte disponível (source available (entre aspas), pela licença SSPL), que também tem criptografia em repouso, com as chaves num Vault (ou OpenBao) ou num servidor KMIP.

E a criptografia em uso?

Existe um terceiro estado, bem menos comum no dia a dia: o dado em uso, enquanto está na memória sendo processado.

Repare que as duas proteções anteriores têm um ponto cego em comum: dentro do servidor do banco, o dado fica aberto. Um DBA, um backup lógico (pg_dump, mongodump) ou alguém que invadiu o servidor enxerga tudo.

A criptografia em uso tenta fechar esse buraco. Um bom exemplo é o Queryable Encryption do MongoDB. A aplicação cifra os campos sensíveis no próprio driver, antes de enviar, e o servidor guarda e consulta o dado sem nunca ver o valor original. A chave mestra fica num KMS que só a aplicação acessa. O banco guarda apenas as chaves de dados, cifradas por ela, e nunca consegue abri-las.

A figura põe as proteções lado a lado. Cada linha é uma proteção, e cada coluna, um lugar por onde o dado passa, da aplicação ao disco. O cadeado fechado, na cor da proteção, é onde o dado está cifrado; o aberto, em vermelho, é onde ele aparece em texto claro. Com repouso e trânsito juntos, o servidor do banco continua aberto (o quadro que pisca); com a criptografia em uso, só a aplicação vê o valor. Com o mouse numa cor da legenda, a figura destaca só aquela proteção.

Imagine uma coleção de portadores de cartão com o CPF cifrado. A aplicação, que tem acesso à chave, consulta normalmente:

db.portadores.find({ cpf: "123.456.789-09" })
// { nome: 'Maria Souza', cpf: '123.456.789-09', ... }

Um DBA conectado direto no banco, sem a chave, vê isto:

db.portadores.findOne()
// { nome: 'Maria Souza', cpf: Binary.createFromBase64('DkH2...', 6), __safeContent__: [ ... ], ... } (nota: o CPF, cifrado)

O subtipo 6 é o formato de dado cifrado do MongoDB. O banco não consegue ler o CPF e, mesmo assim, consegue responder à consulta de igualdade. A cifragem automática do exemplo exige MongoDB Enterprise ou Atlas (7.0 ou mais novo) num replica set. Na Community, só com cifragem explícita no código.

Outro exemplo é a computação confidencial, que protege o dado de quem controla a máquina (o host, o hypervisor, o operador da nuvem). Nas VMs com AMD SEV-SNP ou Intel TDX (quer dizer: memória cifrada), o processador cifra a memória da VM com uma chave que nem o hypervisor acessa. Nos AWS Nitro Enclaves, a proteção vem do isolamento: uma VM à parte, sem rede externa, sem disco e sem acesso interativo. Nenhuma das duas impede quem tem credencial do banco de consultar o dado.

No Postgres, o pgcrypto pode parecer a mesma coisa, mas não é. A chave e o valor aberto passam pelo servidor na própria query e podem acabar em logs. Para ter o efeito de “em uso”, a criptografia precisa acontecer na aplicação.

Por que é pouco usado? Porque cobra caro:

Resumo

Se for para guardar uma coisa deste post: criptografia em repouso e em trânsito são o mínimo, e hoje custam quase nada para ligar. Mas nenhuma das duas impede quem tem credencial de ler o dado. Para isso você precisa de controle de acesso bem feito, auditoria e, nos casos mais sensíveis, criptografia em uso ou tokenização.

Fontes

• AWS — Encrypting Amazon RDS resources (o que é cifrado, só na criação, o grant na chave e o TDE do Oracle e do SQL Server como recurso à parte)
• AWS — Copying a DB snapshot for Amazon RDS e Sharing encrypted snapshots (a cópia cifrada e a chave padrão que não se compartilha)
• AWS — Renaming a DB instance e Associating a DB parameter group with a DB instance
• AWS Prescriptive Guidance — Encrypt an existing Amazon RDS for PostgreSQL DB instance
• AWS — Amazon Aurora now supports Server-Side Encryption by default e Use default encryption at rest for new Amazon Aurora clusters
• AWS — Using SSL with a PostgreSQL DB instance (rds.force_ssl) e Using SSL/TLS to encrypt a connection to a DB instance or cluster (o global-bundle.pem)
• AWS KMS — AWS KMS cryptography essentials (envelope encryption) e Delete an AWS KMS key
• Terraform — aws_db_instance e mongodbatlas_encryption_at_rest
• Microsoft — Transparent Data Encryption (TDE) e Oracle — Introduction to Transparent Data Encryption
• PCI SSC — PCI DSS: Summary of Changes from v3.2.1 to v4.0 (requisito 3.5.1.2)
• Presidência da República — Lei nº 13.709/2018, a LGPD (arts. 46 e 48)
• Banco Central — Resolução CMN 4.893/2021 (art. 3º, versão oficial em inglês)
• PostgreSQL — SSL Support (libpq) e sslmode
• PostgreSQL — Secure TCP/IP Connections with SSL, parâmetros de SSL e The pg_hba.conf File
• PostgreSQL — pg_stat_ssl, Encryption Options e pgcrypto: Security Limitations
• pgJDBC — Initializing the Driver (o sslmode padrão) e Using SSL
• Percona — pg_tde, provedores de chaves e limitações
• EDB — Transparent Data Encryption
• pgBackRest — Configuration Reference (repo-cipher-type e repo-cipher-pass)
• cryptsetup (LUKS) e Clevis
• MongoDB Atlas — Encryption at Rest using Customer Key Management, Manage Customer Keys with AWS KMS e FAQ: Security (TLS obrigatório, só 1.2 e 1.3)
• MongoDB — Connection String Formats, Configure MongoDB Instances for TLS/SSL Encryption e Upgrade a Cluster to Use TLS/SSL
• MongoDB — Encryption at Rest e Configure Encryption
• Percona — Percona Server for MongoDB: data at rest encryption
• MongoDB — Queryable Encryption, compatibilidade e BinData (subtipos)
• AWS — What is Nitro Enclaves? e AMD SEV-SNP for Amazon EC2 instances
• Intel — Intel Trust Domain Extensions (white paper)