Key management: rotação, revogação e backup de chaves criptográficas

1. Fundamentos do Ciclo de Vida de Chaves Criptográficas

1.1. Geração segura

A base de qualquer sistema criptográfico seguro começa com a geração adequada de chaves. Fontes de entropia insuficientes ou algoritmos fracos comprometem todo o sistema. Para ambientes de produção, utilize:

  • AES-256: chave simétrica com 256 bits gerada a partir de CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
  • RSA-2048/4096: chaves assimétricas com no mínimo 2048 bits
  • ECDSA: curvas como P-256 ou P-384 (secp256r1, secp384r1)
# Exemplo de geração segura com OpenSSL
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out chave_privada.pem
openssl pkey -in chave_privada.pem -pubout -out chave_publica.pem

# Geração de chave AES-256 com /dev/urandom
dd if=/dev/urandom bs=32 count=1 | base64 > chave_aes256.b64

1.2. Armazenamento inicial

Nunca armazene chaves em código-fonte, variáveis de ambiente não criptografadas ou arquivos de configuração versionados. Utilize cofres de chaves dedicados:

  • HSM (Hardware Security Module): dispositivos físicos certificados FIPS 140-2 Level 3
  • KMS (Key Management Service): AWS KMS, Azure Key Vault, GCP Cloud KMS
  • Vaults: HashiCorp Vault, CyberArk Conjur
# Exemplo: armazenando chave no AWS KMS via AWS CLI
aws kms create-key --description "Chave de criptografia de dados" --key-usage ENCRYPT_DECRYPT
aws kms create-alias --alias-name alias/minha-chave-prod --target-key-id <key-id>

1.3. Distribuição controlada

Toda distribuição de chaves deve ocorrer por canais autenticados e criptografados. Aplique o princípio do menor privilégio: cada serviço ou usuário deve ter acesso apenas às chaves estritamente necessárias.

# Política de acesso restrito no AWS KMS (JSON)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["kms:Encrypt", "kms:Decrypt"],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/abc123",
      "Condition": {
        "StringEquals": {"aws:SourceVpc": "vpc-12345678"}
      }
    }
  ]
}

2. Rotação de Chaves: Quando, Como e Por Que

2.1. Motivações

A rotação periódica de chaves reduz o impacto de um eventual vazamento e atende requisitos de compliance como PCI-DSS (troca anual) e GDPR (minimização de dados). Cenários comuns:

  • Expiração de certificados TLS
  • Suspeita de comprometimento
  • Mudança de equipe com acesso privilegiado
  • Requisitos regulatórios (renovação a cada 12 meses)

2.2. Estratégias de rotação

Rotação manual: adequada para ambientes de baixa criticidade, mas propensa a erros humanos.

Rotação automática: serviços gerenciados como AWS KMS oferecem rotação automática anual. HashiCorp Vault permite agendamento dinâmico.

# Habilitando rotação automática no AWS KMS
aws kms enable-key-rotation --key-id <key-id>

# Verificando status da rotação
aws kms get-key-rotation-status --key-id <key-id>

2.3. Rotação com zero downtime

Para evitar interrupções, implemente versionamento de chaves com estratégia de dual-write:

# Pseudocódigo para criptografia com versionamento
1. Ao criptografar dados:
   - Usar sempre a versão ativa da chave (latest)
   - Armazenar metadados: {versao: 3, dados_cripto: "base64..."}

2. Ao descriptografar:
   - Ler versão dos metadados
   - Selecionar chave correspondente no KMS
   - Descriptografar com essa chave

3. Re-criptografia assíncrona:
   - Job noturno lê dados com versão antiga
   - Descriptografa com chave antiga
   - Re-criptografa com chave nova
   - Atualiza metadados da versão

3. Revogação de Chaves: Interrompendo o Uso Imediato

3.1. Cenários de revogação

  • Comprometimento confirmado de chave
  • Desligamento de funcionário com acesso
  • Encerramento de serviço ou aplicação
  • Violação de política de segurança

3.2. Mecanismos de revogação

Para certificados digitais, utilize CRL (Certificate Revocation List) ou OCSP (Online Certificate Status Protocol). Para chaves gerenciadas em KMS, APIs específicas permitem desabilitar ou excluir chaves.

# Desabilitando chave no AWS KMS (revogação temporária)
aws kms disable-key --key-id <key-id>

# Agendando exclusão (período de carência de 7 a 30 dias)
aws kms schedule-key-deletion --key-id <key-id> --pending-window-in-days 7

3.3. Propagação da revogação

A revogação deve ser propagada a todos os sistemas dependentes:

# Fluxo de propagação
1. Detectar comprometimento → acionar playbook de incidentes
2. Desabilitar chave no KMS (impede novas operações)
3. Invalidar cache em aplicações (Redis, CDN, proxies)
4. Notificar sistemas downstream via webhook ou fila SQS
5. Registrar evento em log imutável (CloudTrail, ELK)
6. Iniciar processo de re-criptografia com nova chave

4. Backup de Chaves: Proteção Contra Perda e Desastres

4.1. Backup seguro

Chaves criptográficas perdidas podem significar dados permanentemente inacessíveis. O backup deve ser:

  • Criptografado em repouso com chave mestra diferente
  • Distribuído usando split knowledge (Shamir's Secret Sharing)
  • Armazenado em múltiplas regiões geográficas
# Backup de chave do AWS KMS para outra região
aws kms create-key --region us-west-2 --policy file://politica-backup.json

# Exportando chave (apenas para chaves com material exportável)
aws kms get-parameters-for-export --key-id <key-id> --wrapping-algorithm RSAES_OAEP_SHA_256

4.2. Armazenamento e custódia

Utilize serviços gerenciados de backup com rotação automática:

  • AWS Backup: backup centralizado com retenção configurável
  • Azure Key Vault: soft-delete com período de recuperação
  • HSMs de backup: dispositivos físicos em localizações distintas

4.3. Testes de restauração

Realize simulações de Disaster Recovery (DR) trimestralmente:

# Roteiro de teste de restauração
1. Criar ambiente isolado (sandbox)
2. Restaurar backup da chave do cofre secundário
3. Descriptografar dados de teste previamente criptografados
4. Verificar integridade via hash checksum
5. Re-criptografar dados com chave restaurada
6. Validar logs de auditoria da operação

5. Governança e Auditoria no Gerenciamento de Chaves

5.1. Políticas de acesso

Implemente RBAC com segregação de funções: quem gera chaves não deve ser o mesmo que as utiliza em produção.

# Exemplo de política RBAC no HashiCorp Vault
path "transit/keys/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "transit/encrypt/minha-chave" {
  capabilities = ["create", "update"]
}

path "transit/decrypt/minha-chave" {
  capabilities = ["create", "update"]
}

5.2. Logs imutáveis de operações

Toda operação com chaves deve ser registrada: quem fez, o quê, quando e de onde.

# Habilitando logging no AWS KMS via CloudTrail
aws cloudtrail create-trail --name kms-trail --s3-bucket-name meu-bucket-logs
aws cloudtrail start-logging --name kms-trail

# Exemplo de log capturado
{
  "eventTime": "2024-01-15T14:30:00Z",
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "userIdentity": {"arn": "arn:aws:iam::123456789012:user/joao.silva"},
  "requestParameters": {"keyId": "arn:aws:kms:us-east-1:123456789012:key/abc123"},
  "sourceIPAddress": "203.0.113.42"
}

5.3. Compliance e certificações

As principais certificações exigem controles específicos:

  • ISO 27001: A.10.1 — Políticas de uso de controles criptográficos
  • SOC 2: Critérios de segurança e confidencialidade
  • FIPS 140-2: Módulos criptográficos validados (HSMs)

6. Armadilhas Comuns e Anti-Padrões

6.1. Chaves hardcoded em código-fonte

Detecte vazamentos com ferramentas SAST e pre-commit hooks:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/awslabs/git-secrets
    rev: v1.3.0
    hooks:
      - id: git-secrets
        args: ['--scan', '--recursive']

6.2. Rotação sem planejamento de dependências

Rotacionar uma chave sem re-criptografar dados existentes causa falhas silenciosas. Sempre mapeie dependências antes de iniciar a rotação.

6.3. Backup único e sem testes

Backup corrompido não detectado = dados perdidos. Implemente verificações de integridade automatizadas:

# Script de validação de backup
#!/bin/bash
BACKUP_FILE="/backup/chave_criptografada.bin"
EXPECTED_HASH="a1b2c3d4e5f6..."

CALCULATED_HASH=$(sha256sum "$BACKUP_FILE" | awk '{print $1}')

if [ "$CALCULATED_HASH" != "$EXPECTED_HASH" ]; then
    echo "ERRO: Backup corrompido ou adulterado!"
    exit 1
fi
echo "Backup íntegro."

7. Ferramentas e Práticas Recomendadas para Devs

7.1. Serviços gerenciados

Serviço Diferencial
AWS KMS Rotação automática, integração nativa com serviços AWS
Azure Key Vault Soft-delete, RBAC integrado ao Azure AD
GCP Cloud KMS Chaves globais, CMEK para serviços GCP
HashiCorp Vault Dynamic secrets, multi-cloud, open source

7.2. Bibliotecas e SDKs

# Python com boto3 (AWS KMS)
import boto3
from base64 import b64decode

kms = boto3.client('kms', region_name='us-east-1')

def descriptografar(texto_cifrado_b64):
    ciphertext = b64decode(texto_cifrado_b64)
    response = kms.decrypt(CiphertextBlob=ciphertext)
    return response['Plaintext'].decode('utf-8')

7.3. Automação com CI/CD

Integre rotação e revogação em pipelines usando Terraform ou Ansible:

# Terraform para rotação de chave AWS KMS
resource "aws_kms_key" "minha_chave" {
  description             = "Chave rotacionada automaticamente"
  deletion_window_in_days = 7
  enable_key_rotation     = true
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["kms:*"]
        Resource = "*"
      }
    ]
  })
}

Referências