O gerenciamento de segredos é uma área crítica em DevOps, pois envolve a proteção de credenciais, chaves de API, tokens e outras informações sensíveis utilizadas por aplicações e infraestrutura. Em um ambiente moderno, onde a automação e a escalabilidade são essenciais, gerenciar segredos de forma eficaz e segura é fundamental para evitar vazamentos e ataques.

Nesta aula, vamos explorar conceitos avançados de gerenciamento de segredos, incluindo a utilização de vaults (cofres), estratégias de rotação automática, técnicas de injeção segura em aplicações e a importância da auditoria para rastrear o acesso e o uso de segredos. Você verá exemplos práticos e ferramentas como HashiCorp Vault, AWS Secrets Manager e Kubernetes Secrets, além de boas práticas para implementar em seus projetos.

Vaults

Um vault (cofre) é um sistema centralizado para armazenar, acessar e gerenciar segredos de forma segura. Ele fornece uma interface unificada para armazenar credenciais, chaves, tokens e outros dados sensíveis, com controle de acesso baseado em políticas e criptografia forte em repouso e em trânsito. Ao contrário de armazenar segredos em variáveis de ambiente ou arquivos de configuração, um vault permite que você centralize a gestão, reduza a exposição e implemente práticas como rotação e auditoria.

Uma das ferramentas mais populares é o HashiCorp Vault, que oferece recursos como segredos dinâmicos, criptografia como serviço, e integração com diferentes backends de armazenamento. Outros exemplos incluem AWS Secrets Manager, Azure Key Vault e Google Cloud Secret Manager. A escolha do vault depende do seu ambiente e necessidades, mas os princípios são semelhantes.

Exemplo de configuração do Vault para armazenar um segredo estático:

# Inicializar o Vault (primeira vez)
vault operator init

# Desbloquear o Vault (com as chaves geradas)
vault operator unseal <chave1>
vault operator unseal <chave2>
vault operator unseal <chave3>

# Autenticar (com token root)
vault login <token_root>

# Habilitar o KV (Key-Value) secrets engine
vault secrets enable -path=secret kv-v2

# Armazenar um segredo
vault kv put secret/minha-aplicacao DATABASE_PASSWORD="senha_super_secreta"

# Ler o segredo
vault kv get secret/minha-aplicacao

Com o Vault, você pode criar políticas de acesso granulares, como permitir que apenas determinados serviços leiam certos segredos. Isso é feito através de arquivos de política em HCL:

# política.hcl
path "secret/data/minha-aplicacao" {
  capabilities = ["read"]
}

E aplicar com:

vault policy write minha-politica politica.hcl

Rotação automática

Rotação automática é o processo de substituir segredos periodicamente ou sob demanda, sem intervenção manual. Isso reduz o risco de comprometimento, pois mesmo que um segredo vaze, ele tem validade curta. Em ambientes DevOps, a rotação pode ser integrada ao ciclo de vida da aplicação, garantindo que as credenciais sejam atualizadas automaticamente.

Ferramentas como Vault oferecem segredos dinâmicos, como credenciais de banco de dados geradas sob demanda com TTL (time-to-live). Quando o TTL expira, o segredo é revogado automaticamente. Exemplo com Vault e PostgreSQL:

# Configurar o backend de banco de dados no Vault
vault secrets enable database

vault write database/config/minha-db \
    plugin_name=postgresql-database-plugin \
    allowed_roles="meu-role" \
    connection_url="postgresql://{{username}}:{{password}}@localhost:5432/mydb" \
    username="vault" \
    password="senha_vault"

# Criar um role que gera credenciais com TTL
vault write database/roles/meu-role \
    db_name=minha-db \
    creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';" \
    default_ttl="1h" \
    max_ttl="24h"

# Gerar credenciais dinâmicas
vault read database/creds/meu-role

Para segredos estáticos, a rotação pode ser feita via scripts ou ferramentas de automação (como Ansible, Terraform). Por exemplo, no AWS Secrets Manager, você pode configurar a rotação automática com uma função Lambda:

# Exemplo de CLI da AWS para listar rotação
aws secretsmanager describe-secret --secret-id minha-senha

É importante definir políticas de rotação adequadas: frequência, janelas de manutenção e integração com os consumidores para que eles busquem o novo valor.

Injeção segura

Injeção segura refere-se à forma como os segredos são entregues às aplicações em tempo de execução, sem expô-los em logs, código-fonte ou imagens de contêiner. O objetivo é fornecer segredos apenas quando necessário e de forma controlada, minimizando a superfície de ataque.

Existem várias técnicas de injeção:

  • Variáveis de ambiente: embora comum, não é a mais segura, pois podem ser visíveis em processos e logs.
  • Arquivos montados em volumes: segredos são montados como arquivos em contêineres, com permissões restritas.
  • Agentes sidecar: um contêiner auxiliar que busca segredos do vault e os injeta na aplicação principal.
  • APIs de segredos: a aplicação consulta o vault diretamente, usando autenticação mútua.

No Kubernetes, você pode usar volumes de segredos ou a integração com o Vault via CSI (Container Storage Interface). Exemplo de pod com volume de segredos:

apiVersion: v1
kind: Pod
metadata:
  name: minha-app
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: minha-senha

Com o Vault Agent Injector (sidecar), você pode anotar o pod e o agente cuida da injeção:

# Anotação no deployment
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "minha-politica"
    vault.hashicorp.com/agent-inject-secret-database-password: "secret/data/minha-aplicacao"

Essas técnicas garantem que os segredos não fiquem expostos no sistema de arquivos da imagem ou em logs.

Auditoria

Auditoria é o registro e monitoramento de todas as operações relacionadas a segredos: quem acessou, quando, de onde, e o que foi feito. Isso é essencial para conformidade (como SOC 2, GDPR) e para detectar atividades suspeitas.

O Vault possui um dispositivo de auditoria que registra eventos. Você pode habilitar múltiplos backends, como arquivo, syslog ou socket.

# Habilitar auditoria em arquivo
vault audit enable file file_path=/var/log/vault-audit.log

# Habilitar auditoria em syslog
vault audit enable syslog tag="vault"

Os logs de auditoria incluem informações como:

  • Data e hora
  • Token de autenticação (ou entidade)
  • Operação (read, write, delete)
  • Caminho do segredo
  • Endereço IP de origem

No AWS Secrets Manager, você pode usar o CloudTrail para auditar chamadas de API. Exemplo de consulta:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue

É recomendável centralizar os logs de auditoria em um SIEM (como Splunk, ELK) e configurar alertas para comportamentos anômalos, como acessos fora do horário comercial ou múltiplas tentativas falhas.

Boas práticas e observações finais

Ao implementar gerenciamento avançado de segredos, considere:

  • Princípio do menor privilégio: conceda apenas as permissões necessárias.
  • Criptografe segredos em repouso e em trânsito.
  • Automatize a rotação sempre que possível.
  • Evite segredos no código-fonte ou em imagens de contêiner.
  • Monitore e audite continuamente.
  • Tenha um plano de resposta a incidentes para vazamento de segredos.
  • Use ferramentas de varredura de segredos (como git-secrets, truffleHog) no CI/CD.

Lembre-se de que o gerenciamento de segredos é um processo contínuo, não uma configuração única. Revise e atualize suas políticas regularmente.

Referências

Exercícios

  1. Explique a diferença entre um segredo estático e um segredo dinâmico em um vault. Dê um exemplo de quando cada um é apropriado.

✓ Resposta: Um segredo estático é um valor fixo que permanece o mesmo até ser alterado manualmente, como uma senha de banco de dados que não expira. É apropriado para credenciais de longa duração, como chaves de API de terceiros que não suportam rotação automática. Um segredo dinâmico é gerado sob demanda com um TTL, como credenciais de banco de dados criadas pelo Vault que expiram automaticamente. É apropriado para dar acesso temporário a serviços, reduzindo o risco se o segredo for comprometido.
  1. Como você implementaria a rotação automática de segredos em uma aplicação que roda em Kubernetes usando o Vault? Descreva os passos e componentes envolvidos.

✓ Resposta: Para implementar rotação automática no Kubernetes com Vault, você pode usar o Vault Agent Injector. Passos: 1) Configurar o Vault com um backend de segredos dinâmicos (ex: banco de dados) e um role com TTL. 2) Instalar o Vault Agent Injector no cluster. 3) Anotar os pods com as anotações de injeção, especificando o caminho do segredo e o role. 4) O sidecar do Vault Agent renova o segredo antes de expirar e o grava em um arquivo no pod. 5) A aplicação lê o segredo do arquivo montado. Quando o TTL expira, o agente renova automaticamente, garantindo que a aplicação sempre tenha credenciais válidas.
  1. Qual é a diferença entre injetar segredos via variáveis de ambiente e via arquivos montados? Quais são as vantagens e desvantagens de cada método?

✓ Resposta: Variáveis de ambiente são fáceis de configurar e amplamente suportadas, mas podem ser expostas em logs, processos (via /proc/<pid>/environ) e em imagens de contêiner. Arquivos montados permitem definir permissões específicas (somente leitura) e podem ser atualizados sem reiniciar o contêiner, além de serem mais seguros se o sistema de arquivos for criptografado. A desvantagem é que exigem configuração adicional e a aplicação precisa saber o caminho do arquivo. Em geral, arquivos são preferíveis em ambientes mais rigorosos de segurança.
  1. Descreva um cenário em que a auditoria de segredos ajudou a detectar uma violação de segurança. Como você configuraria alertas para esse cenário?

✓ Resposta: Um cenário comum é quando um token de acesso é usado fora do horário comercial ou de um IP não autorizado. Com auditoria, você pode detectar esse acesso anômalo nos logs. Para configurar alertas, você pode usar ferramentas como o Prometheus com Alertmanager ou um SIEM. Por exemplo, no Vault, você pode monitorar os logs de auditoria com uma consulta que procura eventos de leitura de um segredo específico fora de um horário permitido e disparar um alerta via Slack ou e-mail. No AWS, você pode usar CloudWatch Events para detectar chamadas de API incomuns e acionar uma função Lambda que notifica a equipe de segurança.
  1. Implemente um script em bash que use o Vault CLI para criar uma política que permita leitura apenas de um caminho específico e, em seguida, gere um token com essa política. Explique cada comando.

✓ Resposta: Script: 
#!/bin/bash

# Define a política em um arquivo temporário
cat > /tmp/politica.hcl <<EOF
path "secret/data/minha-aplicacao" {
  capabilities = ["read"]
}
EOF

# Cria a política no Vault
vault policy write minha-politica /tmp/politica.hcl

# Gera um token com essa política
vault token create -policy=minha-politica
Explicação: O primeiro bloco cria um arquivo de política com permissão de leitura para o caminho especificado. O comando `vault policy write` carrega essa política no Vault. O comando `vault token create` gera um novo token associado a essa política, que pode ser usado por uma aplicação para ler o segredo.