Capítulo 46 — Criptografia e Controles Criptográficos

46.1 Objetivo do Capítulo

Este capítulo detalha a estratégia criptográfica da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como dados em repouso, em trânsito e em processamento são protegidos por criptografia; como chaves criptográficas são geradas, armazenadas, rotacionadas e destruídas; e como a plataforma observa normas criptográficas (SP 800-38, NIST, OWASP).

A criptografia não é um complemento opcional — é um componente estrutural da segurança da plataforma. Cada categoria de dado tem requisito criptográfico definido.

46.2 Princípios Criptográficos

1. Criptografia por padrão — todo dado sensível é criptografado em repouso e em trânsito;
2. Algoritmos modernos — AES-256-GCM (repouso), TLS 1.3 (trânsito), Argon2 (senha);
3. Geração de entropia — chaves derivadas de /dev/urandom ou equivalente;
4. Rotação automática — chaves sem rotação geram alerta após 90 dias;
5. Separação de chaves — chaves de encriptação, assinatura e derivação são distintas;
6. Minimização de chaves mestras — acesso restrito a HSM ou Vault;
7. Destruição segura — overwrite multi-passada ou destruição física de mídia;
8. Auditoria de criptografia — todo acesso a chaves é registrado;
9. Recuperação com segurança — chaves backup são criptografadas com chave mestra.

46.3 Criptografia em Repouso

46.3.1 Banco de Dados Operacional

Dados sensíveis no PostgreSQL são criptografados com AES-256-GCM:

-- Coluna criptografada com pgcrypto
CREATE TABLE citizens (
  id UUID PRIMARY KEY,
  tenant_id VARCHAR NOT NULL,
  name VARCHAR ENCRYPTED WITH (algorithm = 'aes-256-gcm'),
  cpf VARCHAR ENCRYPTED WITH (algorithm = 'aes-256-gcm'),
  email VARCHAR NOT NULL
);

Chave de encriptação é derivada de chave mestra em Vault, rotacionada a cada 90 dias.

46.3.2 Volumes Persistentes em Kubernetes

PersistentVolumes armazenam dados criptografados com LUKS2 (Linux):

# Provisionamento de volume criptografado
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --size 100 \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789:key/12345678

A chave CMK (Customer Master Key) é gerenciada pela plataforma em Vault.

46.3.3 Object Storage (S3)

Documentos binários em S3 usam criptografia server-side com chave gerenciada pela plataforma:

s3://tenant-org-a-documents/
  ├── 2026-07-16/request-123/document-456.pdf
  │   └── Criptografado com KMS key tenant-org-a

Cada tenant possui CMK própria — dados de um tenant nunca são descriptografáveis com chave de outro.

46.3.4 Redis Cache

Redis não fornece criptografia nativa de dados em repouso. Dados sensíveis em cache são:

1. Não armazenados — apenas dados derivados (ex.: hash de autenticação bem-sucedida);
2. Criptografados antes do armazenamento — valores críticos são criptografados com chave antes de enviar a Redis.

Redis em repouso em mídia — utiliza criptografia de volume do hypervisor.

46.4 Criptografia em Trânsito

46.4.1 TLS 1.3 Obrigatório

Todas as conexões de rede usam TLS 1.3:

# Kubernetes Ingress com TLS obrigatório
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-gateway
spec:
  tls:
  - hosts:
    - api.platform.example.com
    secretName: api-tls-cert
  rules:
  - host: api.platform.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-gateway
            port:
              number: 443

Cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256.

46.4.2 Certificate Pinning

APIs críticas utilizam certificate pinning para prevenir MITM mesmo com CA comprometida:

// Android: Network Security Config
<domain-config cleartextTrafficPermitted="false">
  <domain includeSubdomains="true">api.platform.example.com</domain>
  <pin-set expiration="2027-12-31">
    <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</pin>
  </pin-set>
</domain-config>

46.4.3 mTLS entre Serviços

Serviços internos comunicam com mTLS:

# Istio PeerAuthentication — mTLS obrigatório
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Certificados de serviço são rotacionados automaticamente por cert-manager a cada 30 dias.

46.5 Criptografia de Senhas e Credenciais

46.5.1 Hashing de Senha

Senhas de usuários são hashadas com Argon2id:

// Spring Security
@Configuration
public class SecurityConfig {
  @Bean
  public PasswordEncoder passwordEncoder() {
    return new Argon2PasswordEncoder(
        16,  // salt length
        32,  // hash length
        1,   // parallelism
        60000, // memory (60MB)
        10   // iterations
    );
  }
}

Parâmetros: salt único por senha, iterations configurável conforme ataques evoluem.

46.5.2 Credenciais de Serviço

Credenciais técnicas (database credentials, API keys) são armazenadas em Vault, não em código:

# Vault: database dynamic credentials
path "database/creds/app-user" {
  capabilities = ["read"]
}

Aplicação solicita credencial temporária a Vault no startup, com TTL de 1 hora.

46.5.3 OAuth Tokens

Access tokens (JWT) são assinados com RS256 (chave privada em Vault):

{
  "alg": "RS256",
  "kid": "2026-07-16-key-001"
}
{
  "sub": "user-uuid",
  "aud": "api.platform.example.com",
  "iss": "https://iam.platform.example.com",
  "exp": 1689513600,
  "iat": 1689510000,
  "tenant_id": "tenant-org-a"
}

Chave privada RS256 é rotacionada a cada 180 dias; chave pública publicada em JWKS endpoint.

46.6 Gestão de Chaves Criptográficas

46.6.1 Hierarchia de Chaves

Chave Mestra (HSM ou Vault Root)
    │
    ├─ Chave de Encriptação (KEK) por tenant
    │   └─ Chaves de Dados (DEK) por recurso
    │
    ├─ Chave de Assinatura (Signing Key)
    │
    └─ Chave de Derivação (Key Derivation Key)

A chave mestra nunca sai do HSM ou do Vault.

46.6.2 Vault como Secrets Manager

Vault centraliza gestão de chaves e secrets:

# Provisionar chave de encriptação para tenant
vault write -f transit/keys/tenant-org-a-key \
  type=aes256-gcm256

# Encriptar dado
vault write transit/encrypt/tenant-org-a-key \
  plaintext=$(base64 <<< "dados sensíveis")

# Descriptografar dado
vault write transit/decrypt/tenant-org-a-key \
  ciphertext="vault:v1:..."

Vault replica credenciais em múltiplos nós com quorum de desselagem.

46.6.3 Rotação de Chaves

Rotação automática ocorre conforme política:

Rotação não requer rekeying de dados existentes — novos dados usam chave nova; antigos permanecem com chave antiga até expiração.

46.6.4 Destruição de Chaves

Chaves destruídas são sobrescritas 3 vezes (Gutmann) e registradas como deletadas:

# Vault: delete key after 7-day grace period
vault write transit/keys/tenant-org-a-key \
  deletion_allowed=true

# Agendado para deletar em 7 dias
vault delete transit/keys/tenant-org-a-key

Log de destruição: timestamp, chave, justificativa, authorized_by.

46.7 Assinatura Digital e Integridade

46.7.1 Assinatura de Documentos

Documentos críticos (contratos, declarações) são assinados digitalmente com RS256:

// Assinar documento
byte[] signature = signDocument(documentBytes, privateKey);

// Estrutura JSON com assinatura
{
  "documentId": "doc-uuid",
  "content": "base64-encoded-pdf",
  "signature": "base64-encoded-signature",
  "signedBy": "user-uuid",
  "signedAt": "2026-07-16T10:30:00Z",
  "algorithm": "RS256"
}

Verificação de assinatura é feita com chave pública armazenada no blockchain ou em Audit Store imutável.

46.7.2 Hash de Integridade

Todos os documentos são armazenados com hash SHA-256:

Documento Original
    │
    ├─ SHA-256 Hash: a3f5c2d1e9...
    │   └─ Armazenado em Audit Store (imutável)
    │
    └─ Encriptografado em S3

No acesso ao documento, hash é recalculado e comparado — alteração não-autorizada é detectada imediatamente.

46.8 Conformidade Criptográfica

46.8.1 NIST SP 800-38

Modo de operação: AES-256-GCM (Galois/Counter Mode) conforme NIST SP 800-38D.

Plaintext (P)
    │
    ├─ IV gerado aleatoriamente (96 bits)
    │
    ├─ AES-256 Encryption (chave K)
    │
    ├─ Authentication Tag (T)
    │
    └─ Ciphertext = IV || Ciphertext || AuthTag

Nenhuma reutilização de IV — cada encriptação com mesma chave usa IV novo.

46.8.2 OWASP Cryptographic Storage Cheat Sheet

Conformidade verificada:

• ✓ Algoritmos aprovados (AES-256, RSA-2048, SHA-256)
• ✓ Chaves suficientemente longas
• ✓ Random number generation com entropia suficiente
• ✓ Proteção de chaves em Vault/HSM
• ✓ Sem implementação caseira de criptografia
• ✓ Auditoria de acesso a chaves

46.9 Testes de Criptografia

46.9.1 Verificação de Algoritmos

Suite de testes valida algoritmos em cada deploy:

# Testar TLS 1.3
openssl s_client -connect api.platform.example.com:443 -tls1_3

# Testar cipher suites
nmap --script ssl-enum-ciphers -p 443 api.platform.example.com

# Testar certificate pinning
curl --cert-status https://api.platform.example.com

Falha em testes criptográficos bloqueia deploy em produção.

46.9.2 Teste de Rotação de Chaves

Simulação de rotação em staging:

# 1. Gerar nova chave
vault write -f transit/keys/tenant-org-a-key-new

# 2. Reencriptar dados (background job)
for doc in documents:
  old_ciphertext = doc.encrypted_data
  plaintext = vault.decrypt(old_ciphertext, old_key)
  new_ciphertext = vault.encrypt(plaintext, new_key)
  doc.encrypted_data = new_ciphertext
  doc.key_version = new_key.version

# 3. Validar — todos os documentos descriptografáveis
for doc in documents:
  plaintext = vault.decrypt(doc.encrypted_data, new_key)
  assert len(plaintext) > 0

# 4. Deletar chave antiga (após período de retenção)
vault delete transit/keys/tenant-org-a-key

46.10 Riscos e Mitigações

46.11 Benefícios do Controle Criptográfico

• dados sensíveis protegidos em repouso, trânsito e processamento;
• conformidade com NIST, OWASP e normas criptográficas;
• detecção imediata de alteração não-autorizada via hash;
• rotação automática reduz janela de exposição;
• multi-tenant seguro com chaves segregadas;
• auditoria completa de acesso a chaves;
• recuperação segura com chaves backup criptografadas.

46.12 Decisões Arquiteturais

46.13 Próximo Capítulo

O Capítulo 47 detalha Continuidade de Negócio e Recuperação de Desastre — como a plataforma se recupera de falhas catastróficas mantendo RTO/RPO mínimos.

46.14 Controle de Versão

46.15 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 6 — Segurança: item 6.4 — criptografia de dados.
• [ANX-IV] — Capacidades técnicas de criptografia em repouso, trânsito, assinatura digital.
• [ANX-V] Item 2.2 — Conformidade com NIST SP 800-38, OWASP Cryptographic Storage Cheat Sheet.
• [PNR] — Plataforma com proteção criptográfica completa de dados.
• [EDITAL] — Edital CP001/2026: plataforma com criptografia end-to-end conforme normas técnicas.