Como evoluir a gestão de senhas de bancos e APIs com mais gente programando — sem que "vazar a chave do cofre" vire um risco catastrófico. Análise das opções e a arquitetura recomendada para quem já roda na AWS.
Sua nuvem, seu cofreSeparem credenciais de pessoas de credenciais de aplicação. O Passbolt continua sendo o cofre das pessoas. Para o que o código consome — bancos, APIs de terceiros, CI/CD — adotem um secrets manager dedicado.
Como vocês já rodam na AWS, o caminho mais seguro e econômico para os segredos de aplicação é o AWS Secrets Manager com autenticação por IAM. Ele resolve o medo de "vazar a chave do cofre" na raiz quando o workload roda na AWS: a aplicação se autentica pela própria identidade da infra, com credenciais temporárias, sem token de longa duração guardado no ambiente. Avaliamos também o Doppler — que é excelente e usamos no dia a dia —, mas a vantagem dele aparece principalmente fora da AWS.
A prática atual de vocês — injetar a credencial em tempo de execução por variável de ambiente, nunca no código — está correta. É a base certa. O ponto a evoluir não é como a credencial chega no processo, e sim qual é a fonte da verdade e como ela é distribuída conforme o time cresce. Usar a API do Passbolt para alimentar aplicações é justamente onde mora a fricção — e o ponto único de falha que vocês temem. Ele foi feito para pessoas, não para máquinas. Para uso com agentes de código, a regra extra é: o agente nunca deve receber uma credencial ampla; ele deve trabalhar com datasets mínimos, ambientes isolados e permissões temporárias ou read-only.
Olhamos cinco caminhos antes de fechar a recomendação. O resumo honesto de cada um:
Forçá-lo a servir secrets de aplicação concentra tudo numa chave só — exatamente o cenário catastrófico que vocês descreveram. Mantenham o Passbolt no que ele faz bem.
Centraliza secrets por projeto/ambiente com ótima experiência de uso (doppler run -- injeta tudo em memória). Mas é SaaS fechado, hospedado fora do Brasil.
Mesma pegada, licença MIT, roda em nuvem ou na infra de vocês. A versão self-host endereça o medo do cofre central — mas adiciona carga operacional de manter um sistema crítico.
O padrão-ouro para credenciais de banco com prazo de validade e revogação automática. Poder máximo, custo operacional alto — provavelmente além do necessário agora.
Integra por IAM (sem token a vazar), criptografa com KMS, rotaciona a senha do RDS sozinho, audita por CloudTrail e os dados ficam na sua conta e região. Encaixa no perímetro que vocês já confiam.
Tudo dentro do retângulo é a sua conta AWS, na região que vocês escolherem (ex.: sa-east-1, São Paulo). A aplicação não guarda senha: autentica pela própria IAM Role e recebe o segredo em runtime. O cofre rotaciona a senha do banco sozinho e o CloudTrail registra cada acesso. O Passbolt segue como cofre das pessoas, à parte.
O receio de vocês é legítimo e tem nome técnico: o secret zero problem. Todo cofre central precisa de uma credencial-raiz para ser destravado — então, se você não tomar cuidado, apenas move o problema em vez de resolvê-lo. A resposta moderna ataca em duas frentes.
Em vez de uma chave que destrava tudo, vários acessos pequenos e isolados:
Com isso, um vazamento deixa de ser "catástrofe total" e vira "incidente contido, revogável e auditável". O estrago é uma fatia, não o cofre inteiro.
O degrau seguinte é não ter segredo de longa duração para vazar. É aqui que estar na AWS vira vantagem de graça:
Quando não há chave permanente, "perder a chave do cofre" simplesmente não é mais um cenário possível.
| AWS Secrets Manager | Doppler | Infisical | |
|---|---|---|---|
| Hospedagem | Dentro da sua conta AWS | SaaS (EUA), fechado | SaaS ou self-host (open-source, MIT) |
| Auth da aplicação | IAM Role — sem token armazenado | Service token (credencial de longa duração) | Machine identity / token |
| Rotação de banco | Nativa p/ RDS/Aurora/Redshift (Lambda pronta) | Rotação no plano Team; dynamic no Enterprise | Rotação e dynamic secrets (planos pagos) |
| Auditoria | CloudTrail nativo | Access logs | Audit logs |
| Residência de dados (LGPD) | Na sua região (ex.: sa-east-1) | Servidores nos EUA | Cloud (EUA) ou na sua infra (self-host) |
| Custo | US$ 0,40 / secret·mês + US$ 0,05 / 10k chamadas | ~US$ 12–15 / usuário·mês (Team) | Free tier; pago por usuário (cloud) ou só operar (self-host) |
| DevEx local / multi-cloud | Mais cru localmente; preso à AWS | Excelente p/ dev local e multi-cloud | Boa DevEx; multi-cloud; CLI estilo Doppler |
| Melhor quando… | Os workloads já rodam na AWS | Stack multi-cloud / foco em DevEx | Quer open-source ou dados em casa |
Preços de referência (mai/2026), sujeitos a mudança — confira nas páginas oficiais. Para secrets que não precisam rotacionar (configs, chaves estáticas), o AWS Parameter Store é gratuito no tier padrão e derruba o custo ainda mais.
O argumento decisivo é técnico: autenticação por IAM. O Doppler e similares normalmente precisam de um service token — uma credencial que vive no ambiente e pode vazar, ainda que esteja bem escopada e revogável. O AWS Secrets Manager não precisa desse token quando a aplicação roda dentro da AWS: ela se autentica pela IAM Role da própria instância, task ou função. A infra é a identidade. Não há token de cofre armazenado para vazar — que é, no fim, a tradução técnica do medo de vocês.
Os dois cobram em eixos diferentes — e isso decide a favor do nativo conforme o time cresce:
Mais gente programando (que é o gatilho de vocês) encarece o Doppler e não mexe no AWS. Só se o cenário invertesse — pouquíssimas pessoas e milhares de secrets — o Doppler ganharia.
São dois ajustes simples. Primeiro, uma policy IAM de menor privilégio — a role da aplicação só lê os segredos do próprio ambiente:
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:sa-east-1:<conta>:secret:prod/api/*"
}
Depois, a aplicação lê o segredo em runtime — sem guardar senha, usando a IAM Role da própria task:
# Nenhuma credencial no .env: a identidade vem da IAM Role aws secretsmanager get-secret-value \ --secret-id prod/api/db \ --query SecretString --output text
Para o banco, ative a rotação gerenciada: o Secrets Manager troca a senha do RDS em intervalos definidos (ex.: a cada 30 dias) com uma função Lambda pronta da AWS e atualiza o segredo. A aplicação nem percebe, porque sempre lê a versão atual — e a credencial deixa de ser "eterna".
O argumento do IAM é imbatível se os workloads rodam mesmo na AWS (ECS, Lambda, EC2, EKS). Se boa parte roda fora — Vercel, máquinas de dev, on-prem —, o IAM nativo não alcança esses pontos, e aí o Doppler (ou o Infisical, se quiserem open-source) recupera vantagem pela experiência de desenvolvimento e pelo alcance multi-cloud. Vale combinar os dois: AWS como fonte da verdade de produção, e um secrets manager de DevEx só onde a dor local for real.
Vocês já fazem o básico certo. O salto é mover a fonte da verdade dos secrets para um cofre desenhado para máquinas — e, como estão na AWS, o nativo entrega isso com a identidade IAM no lugar de um token de cofre. Sugerimos um piloto: migrar um serviço e seu banco para o Secrets Manager com rotação ligada, definir o padrão de acesso read-only para agentes de código, medir e então padronizar. Ficamos à disposição para desenhar as policies de menor privilégio e o plano de rotação.