Boas práticas de gestão de secrets em produção

1. Fundamentos da Gestão de Secrets

No contexto de "Temas — Lista Final (1200 temas)", a gestão de secrets é um pilar essencial para garantir a segurança de aplicações em produção. Secrets são informações sensíveis como senhas, chaves de API, tokens de autenticação, certificados TLS e chaves de criptografia. Quando mal gerenciados, eles se tornam o principal vetor de ataques cibernéticos.

Os riscos mais comuns incluem:

  • Vazamento acidental em repositórios Git, logs ou artefatos de build
  • Rotação inadequada que deixa sistemas vulneráveis ou quebra funcionalidades
  • Hardcoding em código-fonte, configurações ou variáveis de ambiente

Os princípios fundamentais que regem a gestão de secrets são:

  • Mínimo privilégio: cada serviço ou pessoa deve ter acesso apenas aos secrets necessários
  • Criptografia: todos os secrets devem ser criptografados em repouso e em trânsito
  • Auditoria: todo acesso a secrets deve ser registrado e monitorado

2. Ferramentas e Plataformas Especializadas

HashiCorp Vault

O Vault é a ferramenta mais completa para gerenciamento centralizado de secrets. Ele oferece:

  • Secrets dinâmicos que expiram automaticamente
  • Suporte a múltiplos backends de armazenamento
  • Integração com sistemas de identidade existentes

Exemplo de configuração básica do Vault:

# Habilitar o motor de secrets KV (Key-Value)
vault secrets enable -path=secret kv-v2

# Criar um secret
vault kv put secret/database/producao \
  username=admin \
  password=super-seguro-123

# Ler o secret
vault kv get secret/database/producao

AWS Secrets Manager e Azure Key Vault

Para ambientes nativos de nuvem, as soluções gerenciadas oferecem integração profunda com o ecossistema:

AWS Secrets Manager:

# Criar um secret via AWS CLI
aws secretsmanager create-secret \
  --name production/db-password \
  --secret-string '{"username":"admin","password":"supersecreto"}'

# Rotação automática configurada
aws secretsmanager rotate-secret \
  --secret-id production/db-password \
  --rotation-lambda-arn arn:aws:lambda:us-east-1:123456789012:function:rotate-db-password

Azure Key Vault:

# Criar um secret no Azure Key Vault
az keyvault secret set \
  --vault-name MeuCofreSeguro \
  --name "db-password" \
  --value "supersecreto"

# Recuperar o secret em uma aplicação
az keyvault secret show \
  --vault-name MeuCofreSeguro \
  --name "db-password" \
  --query "value" \
  --output tsv

Comparação entre Ferramentas

Característica HashiCorp Vault AWS Secrets Manager Azure Key Vault
Modelo Open Source / Enterprise SaaS SaaS
Secrets dinâmicos Sim Limitado Limitado
Rotação automática Sim Sim Sim
Custo Autogerenciado Por secret/mês Por transação

3. Criptografia e Armazenamento Seguro

A proteção de secrets exige criptografia em duas camadas:

Criptografia em repouso: todos os secrets armazenados em disco devem estar criptografados usando AES-256 ou superior.

Criptografia em trânsito: todas as comunicações entre aplicações e o cofre de secrets devem usar TLS 1.2+.

O padrão de envelope de criptografia é amplamente adotado:

# Exemplo conceitual de envelope de criptografia
Chave Mestra (KMS) -> Criptografa -> Chave de Dados (DEK)
Chave de Dados (DEK) -> Criptografa -> Secret propriamente dito
Armazenamento: [DEK criptografada pela KMS] + [Secret criptografado pela DEK]

Para armazenamento temporário, prefira memória volátil controlada (como tmpfs montado com permissões restritas) em vez de arquivos em disco.

4. Ciclo de Vida dos Secrets

Políticas de Rotação

A rotação automática deve ser configurada para todos os secrets críticos:

# Configuração de rotação no Vault (a cada 24 horas)
vault write database/roles/producao \
  db_name=mysql-producao \
  creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
  default_ttl=24h \
  max_ttl=72h

Estratégias de Expiração

Para evitar downtime durante a renovação:

# Estratégia de janela de validade sobreposta
Período 1: Secret A válido (00:00 - 02:00)
Período 2: Secret B válido (01:00 - 03:00)
Transição: Ambos válidos por 1 hora

Versionamento

Mantenha versões anteriores para rollback rápido:

# No Vault, cada escrita gera uma nova versão
vault kv put secret/api-key key=versao1
vault kv put secret/api-key key=versao2

# Rollback para versão anterior
vault kv rollback -version=1 secret/api-key

5. Integração com CI/CD e Deploy

GitHub Actions

name: Deploy com secrets seguros
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Obter secrets do Vault
        uses: hashicorp/vault-action@v2
        with:
          url: https://vault.exemplo.com
          token: ${{ secrets.VAULT_TOKEN }}
          secrets: |
            secret/data/database/producao username | DB_USERNAME ;
            secret/data/database/producao password | DB_PASSWORD

      - name: Deploy da aplicação
        run: |
          echo "Usando DB_USERNAME=$DB_USERNAME"
          # O secret nunca aparece nos logs

GitLab CI

variables:
  VAULT_ADDR: "https://vault.exemplo.com"

deploy:
  stage: deploy
  id_tokens:
    VAULT_TOKEN:
      aud: https://vault.exemplo.com
  secrets:
    DB_PASSWORD:
      vault: secret/data/database/producao password
      file: false
  script:
    - echo "Deploy realizado com secret seguro"

Sidecars em Kubernetes

# Pod com sidecar para injeção de secrets
apiVersion: v1
kind: Pod
metadata:
  name: app-com-secrets
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "app-role"
    vault.hashicorp.com/agent-inject-secret-db-config: "secret/data/database/producao"
spec:
  containers:
    - name: app
      image: minha-app:latest
      volumeMounts:
        - name: secrets
          mountPath: /etc/secrets
          readOnly: true
    - name: vault-agent
      image: hashicorp/vault:latest
      args:
        - agent
        - -config=/etc/vault/config.hcl
  volumes:
    - name: secrets
      emptyDir:
        medium: Memory

6. Controle de Acesso e Auditoria

RBAC no Vault

# Política de acesso restrito
path "secret/data/database/producao" {
  capabilities = ["read"]
}

path "secret/metadata/database/producao" {
  capabilities = ["list"]
}

# Aplicar a política a um grupo
vault policy write db-read-only db-policy.hcl
vault write identity/group name=developers policies=db-read-only

Logs de Acesso

Configure auditoria detalhada:

# Habilitar auditoria no Vault
vault audit enable file file_path=/var/log/vault/audit.log

# Exemplo de log gerado
{
  "time": "2024-01-15T10:30:00Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "policies": ["db-read-only"]
  },
  "path": "secret/data/database/producao",
  "response": {
    "data": {
      "data": {
        "username": "admin"
      }
    }
  }
}

7. Boas Práticas para Times Pequenos e Médios

Automatização com Terraform

# Gerenciamento de secrets com Terraform
resource "vault_kv_secret_v2" "database" {
  mount = "secret"
  name  = "database/producao"
  data_json = jsonencode({
    username = "admin"
    password = random_password.db.result
  })
}

resource "random_password" "db" {
  length  = 32
  special = true
}

Estratégias de Fallback

# Script de fallback para emergências
#!/bin/bash
VAULT_ADDR="https://vault.exemplo.com"

# Tentar obter do Vault
if secret=$(vault kv get -field=password secret/database/producao 2>/dev/null); then
  echo "$secret"
else
  # Fallback para backup criptografado local
  gpg --decrypt /backup/secrets/db.gpg 2>/dev/null || {
    echo "ERRO CRÍTICO: Impossível recuperar secret" >&2
    exit 1
  }
fi

Documentação e Treinamento

Crie um runbook claro com:

  1. Procedimentos para criar novos secrets
  2. Políticas de rotação e expiração
  3. Procedimentos de emergência para vazamentos
  4. Checklist de segurança para deploy

A gestão de secrets em produção não é opcional — é uma necessidade crítica para qualquer organização que leva segurança a sério. Comece pequeno, automatize gradualmente e nunca comprometa a segurança por conveniência.

Referências