Gerenciamento de Segredos (Secrets Manager, Vault)

Gerenciamento de segredos é a disciplina de armazenar, distribuir, rotacionar e auditar credenciais sensíveis, como senhas de banco, chaves de API, tokens e certificados, fora do código e fora das superfícies de configuração comuns. Ferramentas como HashiCorp Vault e AWS Secrets Manager centralizam esse controle em cofres com autenticação forte, autorização granular, criptografia em repouso e trilha de acesso completa. Em produção, a relevância é direta: segredos vazados são um dos caminhos mais curtos entre um repositório comprometido e um incidente grave, porque concedem acesso autenticado a quem não deveria ter. A escolha entre cofres não é apenas ferramental, é uma decisão de arquitetura de confiança, que define quem pode ler o quê, por quanto tempo e com que rastreabilidade. Um sistema de segredos bem implantado reduz o raio de dano de qualquer comprometimento, e um mal implantado concentra todos os riscos em um único ponto.

O problema dos segredos em código e variáveis de ambiente

A prática de gravar credenciais em arquivos de configuração versionados é o caso mais grave, porque o repositório se torna um cofre público interno: qualquer pessoa com acesso ao código, e qualquer backup, cópia ou fork, carrega o segredo para sempre. Variáveis de ambiente melhoram pouco e criam problemas próprios: elas aparecem em arquivos de composição de contêineres, em definições de pipeline, em painéis de orquestração e em dumps de processo, e escalam mal conforme o número de serviços cresce. O problema estrutural é que nenhum desses mecanismos responde três perguntas essenciais: quem leu o segredo, quando leu e com qual finalidade. Sem trilha de acesso, não é possível auditar nem revogar de forma confiável, e a rotação manual acaba nunca acontecendo, produzindo credenciais com anos de vida e centenas de cópias.

Funcionamento interno de um cofre

Um cofre moderno segue um modelo de confiança em camadas. A autenticação de clientes acontece por identidade, via IAM da nuvem, certificados, tokens de plataforma Kubernetes ou identidade de workload, e nunca por segredo estático embutido. A autorização aplica políticas granulares por caminho, no formato de escopo por recurso, permitindo por exemplo que um serviço leia apenas a credencial de seu próprio banco. A criptografia dos valores é feita com chaves mestras protegidas por KMS ou HSM, e o desbloqueio do cofre, a chamada operação de unseal, exige quórum de compartimentos distribuídos, garantindo que nem a própria operação do cofre dependa de uma única pessoa. Toda leitura e escrita é registrada em log de auditoria imutável, que é a base de qualquer investigação posterior. Esse modelo inverte a lógica tradicional: em vez de distribuir cópias de segredos, distribui-se permissão de acesso de curta duração a um ponto único.

Dynamic secrets

Dynamic secrets são credenciais geradas na hora do pedido e destruídas após o tempo de vida combinado, eliminando o conceito de senha permanente para a maioria dos acessos. O exemplo clássico é o acesso a banco de dados: em vez de uma senha fixa compartilhada entre todas as réplicas do serviço, o cofre cria um usuário de banco com permissões restritas, devolve credenciais válidas por uma hora e revoga o usuário ao expirar. O ganho de segurança é enorme, porque um segredo vazado tem validade limitada e está vinculado ao serviço que o pediu, o que identifica a origem do vazamento na auditoria. Vault implementa esse modelo com engines específicos para PostgreSQL, MySQL, MongoDB, Redis e provedores de nuvem, e o mesmo princípio se aplica a certificados, com autoridade de certificação interna emitindo certificados de vida curta sob demanda.

# Vault: habilita o engine de dynamic secrets para PostgreSQL
vault secrets enable -path=database database

# Configura a conexão com o banco usando usuário administrador
vault write database/config/checkout-db \
    plugin_name=postgresql-database-plugin \
    connection_url="postgresql://{{username}}:{{password}}@db-prod:5432/checkout" \
    allowed_roles="checkout-readonly"

# Define a role: SQL de criação, TTL de uma hora e permissões limitadas
vault write database/roles/checkout-readonly \
    db_name=checkout-db \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
      VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

# O serviço pede credenciais novas e recebe usuário e senha temporários
vault read database/creds/checkout-readonly

Além dos dynamic secrets, o Vault oferece o engine transit, que expõe criptografia como serviço: a aplicação envia o dado sensível, o cofre cifra ou decifra sem nunca revelar a chave, e o segredo em si nunca sai da aplicação de chaves. Esse modelo é ideal para criptografia de campos sensíveis em banco, como números de documento, sem que o código da aplicação precise gerenciar material criptográfico.

Rotação automática

Rotação é o processo de trocar periodicamente o valor de um segredo sem interrupção do serviço, e é o critério que separa cofres decorativos de cofres efetivos. AWS Secrets Manager automatiza o ciclo completo para serviços nativos: para RDS, por exemplo, ele cria o novo usuário ou altera a senha, aplica em duas etapas com janelas de teste e atualiza o valor no cofre, enquanto a aplicação busca o valor no momento do uso ou acompanha a versão etiquetada como atual. Em aplicações que mantêm conexões de longa duração, a rotação exige suporte no código, com reconexão ao receber falha de autenticação, e é por isso que a leitura dinâmica do segredo na criação da conexão é preferível a leitura única no bootstrap do processo. O princípio geral é simples: segredo que não rotaciona é senha eterna disfarçada de cofre, e quanto menor o TTL, menor o impacto de cada comprometimento.

A cadência de rotação deve ser proporcional ao risco do segredo, e não a uma política única para todos. Credenciais de acesso a dados pessoais e a serviços de pagamento pedem TTLs de horas, chaves de integração com parceiros externos pedem rotação mensal combinada em contrato, e certificados de TLS seguem o ciclo de renovação automática descrito em outro arquivo desta biblioteca. O catálogo de segredos deve registrar dono, cadência e procedimento de rotação de cada item, transformando rotação em processo auditável e não em exceção heroica.

Vault versus AWS Secrets Manager

As duas ferramentas resolvem o mesmo problema com escopos diferentes, e a tabela abaixo resume os pontos de decisão.

A escolha típica segue a topologia da empresa: organizações multi-nuvem ou com cargas on-premises tendem ao Vault pela neutralidade e pela riqueza de engines, enquanto cargas exclusivamente AWS se beneficiam da simplicidade do Secrets Manager, com IAM autenticando naturalmente cada workload. Ambos podem coexistir, com o Vault como autoridade central e espelhamento seletivo para o Secrets Manager.

Integração com ECS e Kubernetes

Em plataformas de contêineres, o padrão é o cofre alimentar o ambiente de execução sem que o valor toque em código ou em definição de pipeline. No ECS, a task definition referencia o segredo do Secrets Manager ou do Parameter Store por ARN, e o agente do ECS injeta o valor no contêiner no momento do boot, com a função de execução autorizada a ler o recurso. No Kubernetes, o padrão dominante é o External Secrets Operator, que sincroniza segredos do cofre para recursos Secret nativos, mantendo a autoridade no cofre externo e a sincronização declarativa via CRDs.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: checkout-db-credentials
  namespace: checkout
spec:
  # Intervalo de sincronização com o cofre externo
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: checkout-db-credentials   # Secret nativo criado no cluster
    creationPolicy: Owner
  data:
    # Chave dentro do cofre e campo correspondente no Secret
    - secretKey: username
      remoteRef:
        key: database/creds/checkout-readonly
        property: username
    - secretKey: password
      remoteRef:
        key: database/creds/checkout-readonly
        property: password

A alternativa mais recente e mais segura é a identidade de workload com injeção direta, onde o pod autentica no cofre via service account do Kubernetes e monta o segredo como arquivo ou recebe como variável sem passar por Secret intermediário. Em qualquer variante, o princípio é o mesmo: o cluster deve autenticar-se pelo que é, e não por um segredo estático gravado nele.

Um detalhe operacional importante é o comportamento da plataforma diante de rotação. O Secret sincronizado pelo External Secrets não atualiza automaticamente os contêineres em execução, que só leem a variável no boot, por isso serviços sensíveis devem combinar sincronização com reinício controlado ou leitura de arquivo montado, que o Kubernetes atualiza em disco com atraso pequeno. Projetar esse comportamento de antemão evita a armadilha de um segredo rotacionado no cofre e antigo ainda em memória nas réplicas.

Princípios de arquitetura

Cinco princípios orientam a implantação madura de um sistema de segredos.

• Menor privilégio por workload, com cada serviço autorizado a ler apenas os segredos de que precisa, nunca uma política ampla compartilhada.
• Vida curta por padrão, priorizando dynamic secrets e certificados de duração limitada em vez de credenciais permanentes.
• Rastreabilidade total, com log de auditoria de leituras encaminhado para o sistema de logs centralizado e alertas de acesso anômalo.
• Segregação de ambientes, com cofres ou caminhos distintos por ambiente, impedindo que produção seja acessível com identidade de desenvolvimento.
• Preparação para revogação, com procedimento testado de revogação em massa e rotação de emergência, exercitado em game days.

Erros comuns

Os deslizes abaixo comprometem o cofre mesmo depois de adotado.

• Bootstrap paradoxal, quando o token de acesso ao cofre é gravado em variável de ambiente versionada, transferindo o problema de lugar em vez de resolvê-lo.
• Segredos copiados de volta para arquivos de configuração locais durante depurações, recriando cópias não rastreadas em estações de trabalho.
• Falta de unseal automático bem configurado em Vault, gerando indisponibilidade de todos os serviços após reinício do cofre.
• Segredos com nome genérico e compartilhados entre serviços, o que impede rotação seletiva e amplia o impacto de qualquer troca.
• Auditoria habilitada mas não monitorada, com tentativas de acesso negadas que ninguém revisa até depois de um incidente.

Boas práticas

As práticas abaixo consolidam a operação madura do gerenciamento de segredos.

• Elimine segredos de repositórios com varredura automática em CI, invalidando e rotacionando toda credencial encontrada, inclusive em histórico antigo de commits.
• Prefira dynamic secrets para acessos a banco e identidades de curta duração para acesso a nuvem, reservando segredos estáticos apenas para integrações externas que não suportam rotação.
• Leia o segredo no momento do uso, com reconexão em falha de autenticação, em vez de fixar o valor no bootstrap do processo.
• Versione a configuração do cofre como código, incluindo políticas e roles, com revisão obrigatória para qualquer ampliação de permissão.
• Treine o time em rotação de emergência, medindo o tempo entre detecção de vazamento e revogação completa, e reduza esse tempo em cada exercício.