GitHub

HashiCorp Vault é a solução padrão para armazenamento, controle de acesso e auditoria de segredos, senhas, tokens, chaves SSH, certificados. Em 2025, o Vault se integra a pipelines CI/CD, clusters Kubernetes e plataformas serverless, oferecendo um modelo de segurança centrado em políticas. Para quem lidera infraestrutura, a decisão de adotá-lo é, no fundo, a decisão de tirar credenciais de arquivos de configuração e variáveis de ambiente espalhadas e colocá-las sob um regime único de controle e auditoria.

Por que usar Vault?

Cinco propriedades sustentam o caso de adoção. A centralização estabelece um único ponto de verdade para todos os segredos, eliminando cópias dispersas. A criptografia em repouso e em trânsito, com chaves gerenciadas pelo próprio Vault, garante que o dado permaneça inutilizável fora do contexto autorizado. As políticas de acesso granulares controlam quem acessa o quê, por qual caminho e por quanto tempo. A rotação automática gera credenciais temporárias para bancos, nuvem e serviços, encurtando a janela de exposição de qualquer credencial. E a auditoria completa registra cada leitura e escrita com data, hora e identidade, condição indispensável para investigar incidentes e comprovar conformidade.

Arquitetura típica

Uma implantação típica organiza-se em quatro elementos. O servidor Vault opera em modo de alta disponibilidade, apoiado em armazenamento integrado ou no Consul, para que a indisponibilidade do gerenciador de segredos nunca derrube as aplicações que dependem dele. Os métodos de autenticação definem como cada cliente prova quem é, AppRole para aplicações, autenticação nativa do Kubernetes para cargas em cluster, além de opções como GitHub e TLS. Os secrets engines determinam como os segredos são armazenados ou gerados: o engine de chave-valor para segredos estáticos, e engines dinâmicos para bancos de dados, AWS, SSH e PKI. E as políticas, escritas em HCL, são aplicadas a tokens ou entidades, traduzindo o princípio de mínimo privilégio em regras concretas.

O fluxo geral é o seguinte: uma aplicação se autentica no Vault (por exemplo, via AppRole) e recebe um token de curto prazo; com esse token, lê os segredos a que tem direito, credenciais de banco, chaves de nuvem, sempre dentro dos limites de sua política. Cargas rodando em Kubernetes autenticam-se pelo método nativo do cluster. Toda interação gera registro de auditoria, que pode ser encaminhado a um SIEM para correlação. Em vez de credenciais embutidas no código, as aplicações passam a obtê-las sob demanda, com prazo de validade e rastreabilidade.

Configurando o Vault

Em ambiente de teste, o Vault pode rodar em modo de desenvolvimento, que sobe um servidor efêmero com um token de root já disponível e o engine de chave-valor pronto para uso, útil para experimentação rápida, jamais para produção. Em produção, a inicialização é feita de forma deliberada, com o processo de operator init gerando as chaves de unseal e o token de root inicial, e com o armazenamento configurado em modo de alta disponibilidade. A diferença entre os dois modos é, essencialmente, a diferença entre conveniência e segurança real.

Autenticação via AppRole

O AppRole é o método recomendado para autenticar aplicações. A ideia é criar um papel (role) associado a uma política e a limites de validade, tempo de vida do token, tempo máximo, validade do identificador secreto. A aplicação recebe dois fatores: um RoleID, que identifica o papel, e um SecretID, gerado dinamicamente, que funciona como credencial de uso. Com esse par, a aplicação obtém um token de curto prazo para operar. A separação entre os dois fatores permite distribuí-los por canais distintos, reduzindo o risco de comprometimento simultâneo.

Leitura de segredos

Uma vez autenticada, a aplicação aponta para o endereço do servidor Vault e lê o segredo no caminho a que tem acesso, recebendo, por exemplo, o conjunto de chaves de configuração armazenado para aquele serviço. A simplicidade da leitura é proposital: a complexidade fica concentrada na política e na autenticação, não no consumo do segredo.

Integração com Kubernetes

No Kubernetes, o padrão mais usado é o Vault Agent Injector, que injeta segredos como containers auxiliares (sidecar). A configuração se dá por anotações no manifesto do pod, especificando que a injeção está habilitada, qual papel usar e quais segredos montar. O injector cria, dentro do pod, arquivos temporários com os segredos solicitados, que a aplicação lê como se fossem arquivos locais. O desenvolvedor não precisa embutir lógica de autenticação no código da aplicação, a plataforma cuida disso de forma transparente.

Políticas de acesso

As políticas são o coração do modelo de segurança do Vault. Escritas em HCL, elas concedem capacidades específicas a caminhos específicos. Uma política bem desenhada para uma aplicação concede, por exemplo, apenas leitura sobre os segredos daquele app e a capacidade de consultar o próprio token, nada além. Esse rigor é a tradução prática do mínimo privilégio: cada identidade enxerga somente o estritamente necessário para sua função, e qualquer tentativa de acesso fora desse escopo é negada e registrada.

Rotação automática de credenciais de banco de dados

Um dos recursos mais valiosos do Vault é gerar credenciais de banco sob demanda, com validade curta. Configura-se a conexão com o banco e define-se um papel que descreve como criar usuários temporários, com tempo de vida padrão e máximo. Quando uma aplicação pede acesso, o Vault cria um usuário no banco válido por aquele período e o descarta ao expirar. O resultado é que não existem mais credenciais de banco estáticas circulando, cada acesso usa uma credencial efêmera, o que reduz drasticamente o impacto de um eventual vazamento.

Auditoria e logging

A auditoria é habilitada por meio de um audit device, que pode registrar em arquivo ou enviar para syslog. Cada registro contém o identificador da requisição, os dados de autenticação, o caminho acessado e eventuais erros. Esses logs são a base para investigação de incidentes e para demonstrar conformidade, sem auditoria confiável, o controle de acesso vira promessa não verificável.

Boas práticas de segurança

Cinco práticas sustentam uma operação segura do Vault. A primeira é exigir TLS mútuo entre clientes e servidor, garantindo autenticidade nas duas pontas. A segunda é segregar namespaces por ambiente, isolando desenvolvimento de produção. A terceira é aplicar mínimo privilégio em todas as políticas, sem exceções de conveniência. A quarta é rotacionar periodicamente o token de root, tratando-o como credencial de altíssimo risco. E a quinta é manter backups consistentes do armazenamento, para que a perda do gerenciador de segredos não se torne um incidente catastrófico.

Checklist de implantação

Uma implantação bem conduzida costuma seguir esta ordem: instalar o Vault em modo de alta disponibilidade; configurar TLS e certificados; habilitar os métodos de autenticação necessários (AppRole, Kubernetes); criar os secrets engines (chave-valor, banco de dados, AWS); definir políticas de acesso granulares; ativar o audit device; testar a rotação automática de credenciais; documentar o fluxo de obtenção de token; e integrar o Vault ao pipeline de CI/CD.

Conclusão

HashiCorp Vault fornece um framework robusto para gerenciamento de segredos, reduzindo a superfície de ataque e facilitando a conformidade. Ao adotar autenticação forte, políticas de mínimo privilégio e auditoria completa, a organização protege credenciais críticas e automatiza a rotação de segredos em ambientes modernos, transformando o gerenciamento de segredos de ponto cego em controle auditável.

Já utiliza Vault em sua stack? Compartilhe suas dicas e desafios nos comentários!

HashiCorp Vault: Gerenciamento Seguro de Segredos em Aplicações