Gestão de Segredos: HashiCorp Vault e AWS Secrets Manager

Segredos expostos — chaves de API em código, senhas em arquivos .env versionados, tokens hardcoded em imagens Docker — são a causa raiz de uma parcela significativa das violações de dados em ambientes cloud. Este artigo explica como um cofre de segredos funciona, compara as duas soluções mais adotadas no mercado (HashiCorp Vault e AWS Secrets Manager) e descreve o modelo operacional correto para ambientes de produção, CI/CD e Kubernetes.

O problema: onde os segredos realmente moram hoje

Em organizações sem uma estratégia formal de gestão de segredos, credenciais tendem a se acumular em lugares improváveis: hardcoded diretamente no código-fonte, em arquivos .env que "nunca deveriam ter sido commitados", em variáveis de ambiente de instâncias EC2 criadas manualmente, em planilhas de acesso compartilhadas ou em mensagens de Slack de três anos atrás. O problema não é apenas que o segredo está no lugar errado — é que não existe inventário, não existe rotação e não existe auditoria de quem acessou o quê.

O OWASP Top 10 2021 lista Cryptographic Failures (A02) como a segunda categoria mais crítica, e a exposição de segredos é um dos vetores principais. O relatório State of Secrets Sprawl da GitGuardian encontrou, em média, mais de 3 segredos válidos por repositório público no GitHub — incluindo repositórios de organizações que acreditavam ter controles adequados. A superfície de ataque não é teórica.

O que é um cofre de segredos

Um cofre de segredos (secrets vault) é um sistema centralizado que armazena, distribui e rotaciona credenciais de forma segura, com controle de acesso granular e trilha de auditoria completa. Ao contrário de um gerenciador de senhas pessoal, um cofre de segredos é projetado para ser consumido programaticamente por aplicações, pipelines e operadores de infraestrutura — não por humanos digitando senhas.

Os princípios fundamentais de qualquer solução madura são: (1) criptografia em repouso e em trânsito — o segredo nunca trafega ou é armazenado em texto claro; (2) autenticação de identidade — apenas entidades autorizadas conseguem ler um segredo específico; (3) auditoria imutável — cada acesso é registrado com timestamp, identidade e resultado; (4) rotação automática — credenciais têm ciclo de vida definido e são substituídas sem intervenção manual.

HashiCorp Vault

O Vault é a solução open-source de referência para gestão de segredos em ambientes heterogêneos. Sua arquitetura é baseada em secrets engines — plugins que entendem como se comunicar com sistemas externos para gerar, ler ou revogar credenciais.

O KV Secrets Engine é o mais simples: armazena pares chave-valor criptografados, com versionamento (KV v2). O Database Secrets Engine é onde o conceito de dynamic secrets se torna concreto: ao invés de armazenar um usuário fixo do PostgreSQL, o Vault conecta ao banco e gera um par usuário/senha único para cada requisição, com TTL configurável — quando o TTL expira, o Vault revoga a credencial automaticamente. O PKI Secrets Engine opera como uma CA interna, emitindo certificados TLS de curta duração. O Transit Secrets Engine expõe operações criptográficas (cifrar, decifrar, assinar) como API, sem que a aplicação precise gerenciar chaves.

A autenticação no Vault é feita por auth methods: Kubernetes (via ServiceAccount JWT), AWS IAM (via STS), GitHub (via token de personal access), LDAP, OIDC, entre outros. A identidade autenticada recebe policies escritas em HCL que definem exatamente quais paths do Vault a entidade pode ler, escrever ou listar. O modelo é aditivo — acesso negado por padrão, concedido por política explícita.

O Vault registra cada operação em um audit device configurável (arquivo, syslog, socket). Os logs incluem o token usado, o path acessado, o resultado e o timestamp. Em ambientes regulados (PCI-DSS, ISO 27001, SOC 2), essa trilha é requisito de conformidade.

AWS Secrets Manager

O AWS Secrets Manager é o serviço gerenciado da Amazon para armazenamento e rotação de segredos. Integra-se nativamente ao IAM (políticas de acesso por resource ARN), ao KMS (criptografia com chaves CMK gerenciadas pelo cliente), ao CloudTrail (auditoria de todos os eventos da API) e ao Lambda (funções de rotação).

A configuração de rotação automática é o diferencial operacional do Secrets Manager: para bancos de dados gerenciados pela AWS (RDS, Aurora, Redshift, DocumentDB), a AWS fornece funções Lambda de rotação pré-construídas. Basta associar a função ao segredo e definir a janela de rotação. O serviço cuida de gerar a nova credencial, atualizá-la no banco e no cofre, e verificar que a rotação foi bem-sucedida antes de invalidar a credencial anterior.

O modelo de preço é por segredo armazenado (USD 0,40/segredo/mês) mais por chamada de API (USD 0,05 por 10.000 requisições). Para arquiteturas com muitos microserviços lendo segredos frequentemente, o custo pode ser relevante e justifica o uso de cache local com TTL curto via SDK.

Uma limitação em relação ao Vault: o Secrets Manager não suporta dynamic secrets nativamente para bancos de dados externos ao ecossistema AWS. Credenciais são armazenadas e rotacionadas, mas não geradas sob demanda com TTL individual por requisição — essa distinção é importante para arquiteturas de alta segurança.

Comparativo: Vault, AWS Secrets Manager e alternativas

Critério HashiCorp Vault AWS Secrets Manager Azure Key Vault GCP Secret Manager
Dynamic secrets Sim (nativo) Não (rotação periódica) Não Não
Multi-cloud / on-prem Sim Apenas AWS Apenas Azure Apenas GCP
PKI/CA interna Sim (PKI Engine) Não (usa ACM) Sim (Certificate service) Não
Operação Self-managed ou HCP Vault Fully managed Fully managed Fully managed
Integração Kubernetes Vault Agent, CSI Driver, ESO ESO, ASCP ESO, CSI Driver ESO, CSI Driver
Rotação automática Via Dynamic Secrets + TTL Lambda nativa (RDS/Aurora) Lambda / runbooks Requer automação manual
Auditoria Audit Device (file/syslog) CloudTrail Azure Monitor / Diagnostic logs Cloud Audit Logs
Custo base Gratuito (OSS) / USD 0,03/hora (HCP) USD 0,40/segredo/mês USD 0,004/10k operações USD 0,06/10k acessos

Secrets em pipelines CI/CD

Pipelines de CI/CD são um vetor crítico de exposição de segredos. A prática incorreta mais comum é armazenar credenciais como variáveis de ambiente estáticas no repositório ou na configuração do sistema de CI — o que significa que qualquer desenvolvedor com acesso ao repositório pode ler o segredo, e que o segredo nunca muda.

O modelo correto usa autenticação OIDC efêmera: o GitHub Actions e o GitLab CI suportam a emissão de tokens OIDC por job, que identificam o repositório, a branch e o workflow que está executando. Esses tokens podem ser trocados por credenciais temporárias no Vault (via JWT auth method) ou na AWS (via AssumeRoleWithWebIdentity). O pipeline recebe um token válido por minutos — nunca uma credencial de longa duração. Se o log do pipeline vazar, o segredo já expirou.

Para GitHub Actions com Vault: a action oficial hashicorp/vault-action autentica via OIDC e exporta segredos como variáveis de ambiente do step. Para AWS Secrets Manager: aws-actions/configure-aws-credentials com role-to-assume faz o mesmo. Em ambos os casos, o segredo não deve ser printado nos logs — configurar add_mask: true ou equivalente.

Secrets em Kubernetes

O Kubernetes armazena objetos Secret no etcd com codificação base64 — que é encoding, não criptografia. Por padrão, qualquer pod com acesso ao namespace pode ler o segredo. Para ambientes de produção, existem dois padrões consolidados para integrar um cofre externo:

O External Secrets Operator (ESO) é um controller Kubernetes que observa objetos ExternalSecret (CRD) e os reconcilia periodicamente com o cofre externo, criando ou atualizando objetos Secret nativos. Suporta Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager e outros. A reconciliação garante que se o segredo rotacionar no cofre, o Secret do cluster será atualizado sem restart manual — desde que a aplicação monitore mudanças ou tenha um mecanismo de reload.

O Secrets Store CSI Driver com o provider adequado (Vault Provider, AWS Provider) monta segredos diretamente como volumes nos pods em runtime, sem criar objetos Secret no etcd. É a abordagem mais segura para segredos que não devem existir no cluster — útil para certificados TLS e chaves criptográficas que só o pod que precisa deve ver.

Independentemente do método, habilitar Encryption at Rest no etcd é recomendado para qualquer cluster de produção — disponível no EKS via envelope encryption com KMS.

O que não fazer

  • Não commitar arquivos .env, mesmo que pareçam de desenvolvimento. Configurar .gitignore não é suficiente — use hooks de pre-commit (detect-secrets, gitleaks) que bloqueiam o commit se encontrarem padrões de segredo.
  • Não usar variáveis de ambiente de longa duração em containers de produção. Variáveis de ambiente são visíveis para qualquer processo filho e podem aparecer em dumps de memória e logs de debug.
  • Não criar IAM users com chaves de acesso estáticas para serviços na AWS. IAM roles com STS e credenciais temporárias são o padrão correto desde 2018 — não há justificativa técnica para IAM users em workloads automatizadas.
  • Não compartilhar segredos entre ambientes (dev/staging/prod). Cada ambiente deve ter suas próprias credenciais, com políticas de acesso separadas.
  • Não ignorar a auditoria. Habilitar logs sem revisão periódica é teatro de segurança. Configure alertas para padrões anômalos: picos de leitura, acessos de IPs inesperados, negações repetidas.
  • Não usar o segredo diretamente no código mesmo depois de buscá-lo do cofre. Prefer passar como parâmetro de função em vez de variável global — limitar o escopo de vida do valor em memória.

Conceitos fundamentais

Least privilege: cada identidade (aplicação, pipeline, operador) deve ter acesso apenas aos segredos que precisa, no momento em que precisa. No Vault, isso se traduz em políticas HCL por path. No Secrets Manager, em políticas IAM por resource ARN com condições de contexto.

Criptografia em repouso: o Vault criptografa todo o storage backend com AES-256-GCM antes de gravar (barrier encryption). O Secrets Manager usa KMS com opção de CMK gerenciada pelo cliente. Em ambos os casos, o banco de dados ou bucket que guarda os dados criptografados é inútil sem as chaves de criptografia.

Criptografia em trânsito: toda comunicação com o Vault e com o Secrets Manager ocorre via TLS 1.2+. Em clusters Kubernetes, considerar mTLS entre pods via service mesh (Istio, Linkerd) para evitar que segredos injetados como variáveis de ambiente sejam interceptados em trânsito interno.

Leasing e revogação: no Vault, cada segredo dinâmico tem um lease — um contrato de validade. A aplicação pode renovar o lease enquanto precisar da credencial ou deixá-lo expirar. Em caso de comprometimento, o operador revoga todos os leases de uma família com um único comando, invalidando imediatamente todas as credenciais emitidas.

Perguntas frequentes

Qual a diferença entre HashiCorp Vault e AWS Secrets Manager?

O Vault é uma solução open-source multi-cloud com suporte a dynamic secrets, múltiplos backends de autenticação (LDAP, Kubernetes, JWT, AWS IAM) e engines especializados (PKI, SSH, Transit). O AWS Secrets Manager é um serviço gerenciado nativamente integrado ao ecossistema AWS (IAM, KMS, Lambda), com rotação automática facilitada e cobrança por segredo armazenado. Para workloads 100% na AWS, o Secrets Manager reduz overhead operacional. Para ambientes híbridos ou multi-cloud, o Vault oferece portabilidade e controle granular.

O que são dynamic secrets e por que eles importam?

Dynamic secrets são credenciais geradas sob demanda e com tempo de vida (TTL) definido — válidas apenas para uma sessão específica. O Vault, por exemplo, pode gerar um par usuário/senha PostgreSQL único para cada deploy, que expira automaticamente após 1 hora. Isso elimina credenciais compartilhadas e permanentes: se um segredo vazar, ele já não existe mais. É a diferença entre uma chave mestra que nunca muda e um crachá de visitante que expira ao fim do dia.

Guardar segredos em variáveis de ambiente (.env) é seguro?

Não inteiramente. Arquivos .env resolvem o problema de hardcoding no código-fonte, mas criam outros: são copiados para imagens Docker, aparecem em logs de debug, ficam no histórico de shells e frequentemente terminam em repositórios acidentalmente. A abordagem correta é usar um cofre de segredos como referência canônica e injetar variáveis em runtime via sidecar, CSI driver ou SDK — nunca persistir o valor em disco ou em variáveis de ambiente do sistema operacional de longa duração.

Como integrar gestão de segredos em pipelines CI/CD?

A prática recomendada envolve três passos: (1) autenticar o pipeline no cofre usando uma identidade efêmera (OIDC token do GitHub Actions ou GitLab CI, nunca credenciais estáticas); (2) solicitar ao cofre apenas os segredos necessários para aquela etapa específica do pipeline com escopo mínimo; (3) não exportar os valores para logs ou artefatos. O HashiCorp Vault tem a action hashicorp/vault-action; o AWS Secrets Manager se integra via aws-actions/aws-secretsmanager-get-secrets. Em ambos os casos, o pipeline nunca deve armazenar o segredo além do tempo de execução do job.

O que é rotação automática de segredos e como configurar?

Rotação automática é o processo de substituir uma credencial por uma nova de forma programática, sem intervenção humana e sem indisponibilidade. No AWS Secrets Manager, basta associar uma função Lambda ao segredo e definir a janela de rotação (ex.: a cada 30 dias); a AWS fornece templates prontos para RDS, Redshift e outros serviços. No Vault, o Dynamic Secrets Engine cobre banco de dados, cloud credentials e PKI com TTL configurável. A rotação não é opcional em ambientes de produção — NIST SP 800-63B e OWASP ASVS nível 2 exigem rotação periódica de credenciais privilegiadas.

Como usar gestão de segredos em Kubernetes?

Existem dois padrões consolidados: o External Secrets Operator (ESO), que sincroniza segredos do Vault ou AWS Secrets Manager para objetos Secret nativos do Kubernetes em tempo real; e o Secrets Store CSI Driver, que monta segredos diretamente como volumes nos pods sem persistência em etcd. O ESO é preferível quando você precisa de reconciliação contínua; o CSI driver é indicado quando o requisito é não armazenar o segredo no cluster. Em ambos os casos, evite criar Kubernetes Secrets manualmente — eles são armazenados em etcd com codificação base64, não criptografados por padrão, a menos que você habilite Encryption at Rest no cluster.

Referências

Como a Decripte implementa gestão de segredos

A Decripte projeta e implementa arquiteturas de gestão de segredos para organizações de qualquer porte — de startups com um único ambiente na AWS a empresas com mais de 100.000 colaboradores operando em múltiplas nuvens e datacenters on-premises. O trabalho cobre desde o inventário inicial de segredos espalhados pelo ambiente até a implementação completa de Vault ou AWS Secrets Manager, integração com pipelines CI/CD, Kubernetes e revisão de postura de segurança DevSecOps.

O plano de Gestão de Ameaças inclui avaliação de exposição de credenciais e recomendações práticas de remediação. Para implementações mais profundas — onboarding de cofre, dynamic secrets, PKI interna, integração SIEM — os planos de Resposta a Incidentes e Compliance cobrem o escopo completo com acompanhamento contínuo.

Comece pelo diagnóstico gratuito: em minutos você tem uma visão do estado atual de exposição de credenciais no seu ambiente.