HashiCorp Vault: gerenciamento de segredos em ambientes distribuídos

1. Introdução ao HashiCorp Vault e sua Relevância na Segurança Moderna

Em arquiteturas distribuídas modernas, segredos — como senhas, chaves de API, tokens de autenticação e certificados TLS — são o calcanhar de Aquiles da segurança. O gerenciamento tradicional, com credenciais hardcoded em arquivos de configuração ou variáveis de ambiente, expõe as organizações a riscos críticos: vazamento em repositórios Git, acesso não autorizado por funcionários, ausência de rotação automática e dificuldade de auditoria.

O HashiCorp Vault surge como uma solução unificada que oferece "secrets as a service": um sistema centralizado para armazenar, acessar e gerenciar segredos de forma dinâmica e auditável. Integrado ao ecossistema de segurança (como as recomendações do OWASP Top 10 para proteção de dados sensíveis), o Vault permite que aplicações obtenham credenciais sob demanda, com expiração automática e sem exposição direta.

2. Arquitetura e Componentes Principais do Vault

A arquitetura do Vault é composta por três camadas principais:

  • Servidor Vault: responsável por gerenciar requisições de leitura/escrita de segredos, autenticação e autorização.
  • Storage Backend: armazenamento persistente dos dados criptografados (Consul, Raft, AWS S3, etc.). Em produção, o Raft fornece HA nativa.
  • Barreira de Criptografia (Seal/Unseal): todo dado é criptografado em repouso usando uma chave de mestre. O servidor inicia no estado "selado" (sealed) e precisa ser "deselado" (unsealed) para operar.

O Vault oferece dois modos de operação:

  • Modo dev: auto-unseal, sem persistência, ideal para testes locais.
  • Modo produção: requer unseal manual ou automático (via KMS), com HA e replicação entre datacenters.

3. Modelos de Autenticação e Autorização

O Vault suporta múltiplos métodos de autenticação (auth methods):

  • Token: método padrão, com tokens de acesso temporários.
  • AppRole: ideal para máquinas e serviços, com role_id e secret_id.
  • Kubernetes: autenticação via service account do cluster.
  • AWS IAM, Azure MSI, GCP IAM: para workloads em cloud.
  • LDAP, OIDC/JWT: integração com provedores de identidade federada.

As políticas (policies) são escritas em HCL e definem permissões granulares:

path "secret/data/{{identity.entity.name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "database/creds/my-role" {
  capabilities = ["read"]
}

4. Gerenciamento Dinâmico de Segredos

A principal inovação do Vault são os segredos dinâmicos: credenciais geradas sob demanda, com tempo de vida limitado (TTL). Exemplos práticos:

PostgreSQL

# Habilitar o secrets engine de banco de dados
vault secrets enable database

# Configurar conexão com PostgreSQL
vault write database/config/my-postgres \
    plugin_name=postgresql-database-plugin \
    allowed_roles="my-role" \
    connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
    username="vault_admin" \
    password="super_secret"

# Criar role que gera credenciais dinâmicas
vault write database/roles/my-role \
    db_name=my-postgres \
    creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Para obter credenciais:

vault read database/creds/my-role
# Saída:
# Key                Value
# ---                -----
# lease_id           database/creds/my-role/abc123
# lease_duration     1h
# password           aB3xYz...
# username           v-token-my-role-abc123

Vantagens: rotação automática, expiração programada e revogação imediata do lease.

5. Encryption as a Service e Proteção de Dados

O Transit Secrets Engine permite que aplicações criptografem/descriptografem dados sem expor as chaves. A aplicação envia dados para o Vault, que retorna o ciphertext.

# Habilitar transit
vault secrets enable transit

# Criar chave de criptografia
vault write -f transit/keys/my-app-key

# Criptografar dados
vault write transit/encrypt/my-app-key plaintext=$(echo -n "dados_sensiveis" | base64)

# Descriptografar
vault write transit/decrypt/my-app-key ciphertext="vault:v1:abc123..."

Isso permite BYOK (Bring Your Own Key): a organização mantém o controle das chaves mestras, mesmo usando serviços cloud.

6. Integração com Ambientes Distribuídos e DevOps

Kubernetes

O Vault se integra nativamente com Kubernetes via:

  • CSI Driver: monta segredos como volumes em pods.
  • Sidecar Injector: injeta o Vault Agent como sidecar para renovação automática de tokens.
  • Vault Agent: modo standalone que gerencia autenticação e renovação.

Exemplo de deployment com sidecar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "my-app-role"
        vault.hashicorp.com/agent-inject-secret-database: "database/creds/my-role"
    spec:
      serviceAccountName: my-app-sa
      containers:
      - name: my-app
        image: my-app:latest

Pipeline CI/CD (GitHub Actions)

- name: Authenticate with Vault
  run: |
    curl -s --header "X-Vault-Token: ${{ secrets.VAULT_TOKEN }}" \
      https://vault.example.com/v1/secret/data/ci-cd \
      | jq -r '.data.data' > secrets.json

- name: Use secrets
  run: |
    export DB_PASSWORD=$(cat secrets.json | jq -r '.db_password')
    ./deploy.sh

7. Boas Práticas, Segurança e Monitoramento

Estratégias de Unseal

  • Shamir Secrets: divide a chave mestre em N partes, exigindo K delas para unseal.
  • Auto-unseal: integração com KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) — mais seguro e automatizado.

Auditoria e Logging

# Configurar audit device para arquivo
vault audit enable file file_path=/var/log/vault/audit.log

# Configurar syslog
vault audit enable syslog facility=AUTH

Para monitoramento, o Vault expõe métricas no formato Prometheus:

vault audit enable syslog facility=AUTH
# Em produção, use Prometheus + Grafana para dashboards de:
# - Requests por segundo
# - Taxa de erros de autenticação
# - Tempo de resposta das APIs

Hardening

  • TLS mutual (mTLS) entre clientes e servidor.
  • Criptografia de tráfego com certificados assinados por CA interna.
  • Políticas de rotação de chaves (key rotation) para Transit e PKI.
  • Atualização regular do Vault e plugins.

8. Cenários de Uso e Estudos de Caso

Microsserviços

Cada microsserviço obtém credenciais de banco de dados dinâmicas, com TTL de 1 hora. Ao expirar, o lease é renovado automaticamente pelo Vault Agent. Se um container for comprometido, as credenciais expiram em minutos.

Infraestrutura como Código (IaC)

Com Terraform e o Vault Provider, é possível provisionar recursos cloud e injetar segredos dinamicamente:

resource "vault_database_secret_backend_role" "postgres" {
  backend = vault_mount.database.path
  name    = "my-role"
  db_name = vault_database_secret_backend_connection.postgres.name
  creation_statements = [
    "CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';"
  ]
  default_ttl = 3600
  max_ttl     = 86400
}

Casos Reais

  • Fintechs: usam Vault para gerenciar chaves de API de processamento de pagamentos, com rotação a cada 15 minutos.
  • Healthtech: compliance com HIPAA usando Transit Secrets Engine para criptografar dados de pacientes, mantendo chaves on-premises (BYOK).

Referências