HashiCorp Vault 2026: Gestão de Segredos para PME

SCHEMA MARKUP JSON-LD  |  ✎ Duarte Spínola  |  Tags:

Senhas de bases de dados, API keys, certificados TLS, chaves SSH — tudo espalhado em ficheiros .env, scripts, variáveis de ambiente e post-its digitais. Quando um developer sai da empresa, quantos segredos tem acesso? A resposta, sem Vault, é sempre “não sei”. O HashiCorp Vault centraliza segredos com rotação automática, auditoria completa e controlo de acesso granular. Este artigo configura Vault para PME com armazenamento em ficheiro, policies por equipa, rotação de credenciais de BD e integração com Ansible (Vault docs).

Neste artigo

1. Entender Vault e Gestão Centralizada de Segredos
2. Pré-requisitos e Instalação
3. Passo 1 — Iniciar Vault em Modo Dev e Produção
4. Passo 2 — Habilitar Secret Engines
5. Passo 3 — Policies de Acesso por Equipa
6. Passo 4 — Rotação de Credenciais de Base de Dados
7. Passo 5 — Integração com Ansible
8. Passo 6 — Auditoria e Logs
9. Vault vs Alternativas — Comparação
10. Erros Comuns
11. Checklist Rápido de Verificação

1. Entender Vault e Gestão Centralizada de Segredos

Vault é um cofre digital para segredos. Segredos são passwords, API keys, certificados, chaves privadas — qualquer informação que dê acesso a algo. O Vault guarda estes segredos encriptados, controla quem pode aceder a cada um, regista cada acesso em log, e roda rotação automática de credenciais.

Analogia: Vault é como um cofre de banco com registo de acessos. Cada segredo está numa gaveta. Cada pessoa tem uma chave que abre apenas as gavetas autorizadas. Cada vez que alguém abre uma gaveta, o cofre regista quem, quando e qual gaveta. Se uma pessoa sai da empresa, revogas a chave — sem caçar segredos espalhados por ficheiros.

O problema que Vault resolve: segredos espalhados. Sem Vault, uma PME típica tem:

• 15 ficheiros .env em 10 servidores
• 30 API keys hardcoded em scripts
• 5 passwords de BD em ficheiros de config plain text
• Certificados TLS em 5 sítios diferentes
• Zero auditoria de quem acedeu ao quê

Com Vault: tudo num só sítio, encriptado, com auditoria (Vault getting started).

2. Pré-requisitos e Instalação

Instalar Vault:

Ubuntu/Debian:

Se não tiveres wget, usar curl -fsSL URL | sudo gpg --dearmor como alternativa.

Outros OS:

Se unzip não estiver instalado: apt install unzip ou dnf install unzip.

Verificar instalação:

3. Passo 1 — Iniciar Vault em Modo Dev e Produção

Modo Dev (apenas para testes)

O modo dev é para experimentar — tudo em memória, sem persistência, sem TLS:

O que cada flag faz:

• -dev — modo desenvolvimento (in-memory, sem persistência)
• -dev-root-token-id — define o token root explicitamente (apenas para dev)

Modo Produção (com persistência em ficheiro)

Criar ficheiro de configuração:

O que cada bloco faz:

• storage "file" — guarda segredos encriptados em /var/lib/vault. Para HA, usar Raft ou Consul
• listener "tcp" — escuta na porta 8200. tls_disable = 1 para lab — em produção usar TLS
• ui = true — ativa interface web em http://servidor:8200/ui

Iniciar Vault:

Inicializar o Vault (apenas na primeira vez):

O que cada parâmetro faz:

• -key-shares=3 — gera 3 unseal keys (chaves para destrancar o Vault)
• -key-threshold=2 — precisa de 2 das 3 chaves para destrancar

Guardar as unseal keys e o root token em local seguro (password manager, cofre físico). Depois destrancar:

O Vault precisa de 2 chaves (threshold) para destrancar. Nenhuma pessoa sozinha tem todas as chaves — separação de poderes (Vault init).

4. Passo 2 — Habilitar Secret Engines

O Vault tem múltiplas “secret engines” — cada uma gere um tipo de segredo:

O que cada engine faz:

• kv-v2 — key-value store versionado. Guarda pares chave-valor encriptados com histórico de versões
• database — gere credenciais de BD dinâmicas. Cria users na BD com TTL, roda rotação automática
• pki — autoridade certificadora interna. Emite certificados TLS com TTL curto
• ssh-client-signer — assina chaves SSH públicas. Clientes usam a chave assinada para SSH sem passwords

Guardar um segredo no KV:

Ler um segredo:

5. Passo 3 — Policies de Acesso por Equipa

As policies controlam quem pode aceder a quê. Cada policy é um ficheiro HCL:

O que cada regra faz:

• path — endereço do segredo no Vault (wildcard * suportado)
• capabilities — read, list, create, update, delete, deny. deny sobrepõe-se a tudo
• secret/data/ — prefixo do KV v2 (a engine KV v2 usa /data/ internamente)

Aplicar as policies:

Criar tokens para cada equipa:

O -ttl=24h define que o token expira em 24 horas — boa prática para limitar exposição (Vault policies).

6. Passo 4 — Rotação de Credenciais de Base de Dados

A killer feature do Vault é a rotação automática de credenciais de BD. Em vez de uma password estática partilhada por 10 aplicações, o Vault cria credenciais únicas por aplicação com TTL.

Configurar conexão PostgreSQL:

O que cada parâmetro faz:

• plugin_name — driver da BD (PostgreSQL, MySQL, MSSQL, etc.)
• connection_url — string de conexão com placeholders {{username}} e {{password}}
• allowed_roles — quais roles podem usar esta conexão
• username/password — credenciais admin que o Vault usa para criar/revogar users na BD

Criar uma role que gera credenciais dinâmicas:

O que cada parâmetro faz:

• creation_statements — SQL que cria o user na BD. {{name}} e {{password}} são gerados pelo Vault
• default_ttl="1h" — credencial válida por 1 hora. Renovada automaticamente se a app pedir renew
• max_ttl="24h" — máximo 24h, depois é revogada automaticamente

Quando a aplicação precisa de uma credencial:

Output:

A aplicação usa este user/password. Ao fim de 1h, o Vault revoga o user na BD automaticamente (Vault database secrets).

7. Passo 5 — Integração com Ansible

O Ansible pode obter segredos do Vault em runtime em vez de os ter hardcoded em group_vars:

Instalar a collection do Vault:

No playbook, obter segredos do Vault:

O que cada parâmetro faz:

• vault_read — lê um segredo do Vault via API
• auth_method: token — autentica com token (alternativas: AppRole, LDAP)
• no_log: true — CRÍTICO: impede que o Ansible mostre o segredo no output
• stripe_key.secret.data.key — navega na estrutura de resposta do Vault

8. Passo 6 — Auditoria e Logs

ativar audit log em ficheiro:

A partir de agora, todas as operações são registadas:

O log mostra: quando, quem (entity), o quê (path), de onde (IP). O conteúdo dos segredos é hmac-only — o log regista o hash, não o valor real. Isto permite auditoria sem expor segredos (Vault audit).

Para procurar acessos a um segredo específico:

9. Vault vs Alternativas — Comparação

Recomendação para PME: Vault OSS (gratuito) se tens infra própria e queres controlo total. AWS Secrets Manager se estás 100% em AWS. Doppler se queres simplicidade SaaS sem gerir infra.

10. Erros Comuns

11. Checklist Rápido de Verificação

• [ ] Vault instalado e a correr em modo produção (systemctl status vault)
• [ ] Vault inicializado com 3 unseal keys guardadas em local seguro
• [ ] Vault destrancado (unsealed)
• [ ] Secret engine KV v2 habilitada em secret/
• [ ] Secret engine Database habilitada (se usas rotação BD)
• [ ] Policies criadas por equipa (dev-team, ops-team)
• [ ] Tokens com TTL curto (24h ou menos)
• [ ] Rotação de credenciais BD testada (vault read database/creds/...)
• [ ] Audit log ativo em ficheiro
• [ ] Integração Ansible com no_log: true em todas as tasks de segredos

Artigos Relacionados

• Ansible: Automatização de PME em 2026 — Usar Vault como fonte de segredos para playbooks
• Linux Server Hardening Checklist 2026 — Hardening complementar à gestão de segredos
• ISO 27001 para PME: Anexo A 2026 — Vault ajuda com controlos A.9 (access control)
• SIEM para PME 2026: Graylog + Sentinel — Enviar audit logs do Vault para SIEM
• Zero Trust para PMEs 2026 — Vault como componente de gestão de credenciais Zero Trust

← Voltar ao Índice