Secrets management: nunca mais comite credencial no repositório

1. O Problema das Credenciais no Código-Fonte

1.1. Riscos de segurança

Comitar credenciais diretamente no repositório é um dos erros mais comuns e perigosos no desenvolvimento de software. Uma chave de API, senha de banco de dados ou token de serviço exposto no GitHub pode ser descoberta por bots de varredura em minutos. As consequências incluem:

  • Acesso não autorizado a bancos de dados e serviços cloud
  • Exploração de contas de terceiros (AWS, Stripe, Twilio)
  • Escalada de privilégios dentro da infraestrutura
  • Roubo de dados sensíveis de clientes

1.2. Casos reais de incidentes

Em 2022, a Uber sofreu um vazamento massivo quando credenciais AWS foram encontradas em um script compartilhado internamente. A Twilio também teve tokens expostos em um repositório público, resultando em acesso não autorizado a contas de clientes. Startups menores são alvos frequentes: bots como gitdorker e truffleHog escaneiam repositórios públicos em busca de padrões de secrets.

1.3. Por que desenvolvedores ainda cometem esse erro

Três fatores principais contribuem:

  • Pressa: durante sprints apertados, o desenvolvedor cola uma chave direto no código para "testar rápido" e esquece de removê-la
  • Falta de ferramentas: sem hooks de pré-commit ou scanners automáticos, o erro passa despercebido
  • Cultura deficiente: equipes sem políticas claras de secrets management tratam credenciais como "dados normais"

2. Fundamentos de Secrets Management

2.1. O que são secrets

Secrets são informações sensíveis que concedem acesso a sistemas ou dados protegidos:

Senhas de banco de dados
Tokens de autenticação OAuth
Chaves de API (Stripe, AWS, Google)
Certificados TLS/SSL
Chaves SSH privadas
Strings de conexão com serviços cloud

2.2. Ciclo de vida de um secret

Todo secret deve seguir um ciclo controlado:

  1. Criação: gerado com entropia suficiente (ex.: openssl rand -base64 32)
  2. Armazenamento: em cofre seguro, nunca em texto plano
  3. Distribuição: injetado apenas em runtime, nunca em imagem ou código
  4. Uso: consumido pela aplicação com mínimo privilégio
  5. Rotação: substituído periodicamente ou sob demanda
  6. Revogação: invalidado imediatamente se comprometido

2.3. Princípios básicos

  • Least privilege: cada serviço recebe apenas os secrets necessários para sua função
  • Separação de ambientes: secrets de produção nunca são usados em desenvolvimento
  • Criptografia: secrets devem ser criptografados em repouso (no cofre) e em trânsito (TLS)

3. Ferramentas de Secrets Management no Mercado

3.1. HashiCorp Vault

O Vault é a ferramenta mais completa para gerenciamento centralizado de secrets. Recursos principais:

  • Dynamic secrets: gera credenciais temporárias sob demanda (ex.: banco de dados com TTL de 1 hora)
  • Integração com Kubernetes: via CSI driver ou sidecar injector
  • Múltiplos backends: AWS, GCP, bancos SQL, PKI

Exemplo de comando para criar um secret estático:

vault kv put secret/minha-app/database \
    username=admin \
    password=$(openssl rand -base64 24)

3.2. AWS Secrets Manager

Serviço gerenciado da AWS com rotação automática integrada para RDS, Redshift e DocumentDB. Custo por secret armazenado (~$0.40/mês) e por rotação.

3.3. Alternativas open source e cloud-native

Ferramenta Tipo Diferencial
CyberArk Conjur Open source Foco em automação CI/CD
Azure Key Vault Cloud Integração nativa com Azure
Google Secret Manager Cloud Versionamento automático
Mozilla SOPS Open source Criptografia de arquivos YAML/JSON

4. Boas Práticas para Evitar Commit de Credenciais

4.1. Uso de arquivos .env e .gitignore

Crie um template documentado e nunca comite o arquivo real:

# .env.example (comite no repositório)
DATABASE_URL=postgresql://usuario:senha@localhost:5432/meubanco
API_KEY=sua_chave_aqui
JWT_SECRET=altere_para_um_valor_seguro

# .gitignore
.env
*.key
*.pem
credenciais.json

4.2. Hooks de pré-commit com detecção automática

Ferramentas como gitleaks podem ser integradas como hooks do Git:

# Instalar gitleaks
brew install gitleaks

# Adicionar ao .git/hooks/pre-commit
#!/bin/bash
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
    echo "⚠️  Credenciais detectadas! Commit bloqueado."
    exit 1
fi

4.3. Scanning contínuo em pipelines

Configure scanners automáticos no CI/CD e em repositórios históricos:

  • GitHub Secret Scanning: nativo para repositórios públicos e habilitável em privados
  • GitLab Secret Detection: parte do Ultimate tier
  • truffleHog: ferramenta open source para escanear commits antigos

5. Integração de Secrets em Pipelines de Deploy

5.1. Injeção via variáveis de ambiente em Kubernetes

Use o External Secrets Operator para sincronizar secrets do Vault ou AWS com o Kubernetes:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: app-database-secret
    creationPolicy: Owner
  data:
  - secretKey: password
    remoteRef:
      key: secret/data/minha-app/database
      property: password

5.2. Sidecar para consumo de secrets

No Vault, use o injector automático para sidecars:

kind: Deployment
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "minha-app"
    vault.hashicorp.com/agent-inject-secret-database: "secret/data/minha-app/database"

5.3. Exemplo prático: Node.js com Vault

Aplicação que consome secrets do Vault em runtime:

const vault = require("node-vault")({
  apiVersion: 'v1',
  endpoint: process.env.VAULT_ADDR,
  token: process.env.VAULT_TOKEN
});

async function startApp() {
  const { data } = await vault.read('secret/data/minha-app/database');
  const dbPassword = data.data.password;

  // Conecta ao banco usando a senha recém-obtida
  const db = await connectToDatabase({
    user: 'admin',
    password: dbPassword,
    host: 'meu-db.amazonaws.com'
  });
}

6. Rotação e Revogação de Secrets

6.1. Estratégias de rotação automática

  • Baseada em tempo: a cada 30 dias (ex.: senhas de banco)
  • Sob demanda: quando um secret é comprometido
  • Event-driven: após deploy de nova versão

No AWS Secrets Manager, configure rotação automática com Lambda:

aws secretsmanager rotate-secret \
    --secret-id minhachaveapi \
    --rotation-lambda-arn arn:aws:lambda:us-east-1:123456:function:rotate-secret

6.2. Revogação imediata

Mantenha um procedimento documentado para revogação emergencial:

# AWS IAM: invalidar chave de acesso
aws iam update-access-key \
    --access-key-id AKIAIOSFODNN7EXAMPLE \
    --status Inactive

# Vault: revogar lease de dynamic secret
vault lease revoke aws/creds/minha-role/abc123

6.3. Monitoramento e auditoria

Configure alertas para acesso suspeito a secrets:

  • CloudTrail (AWS) ou Audit Device (Vault) para logs de leitura
  • Alertas no Slack/PagerDuty quando um secret é acessado fora do horário comercial
  • Dashboards no Grafana com métricas de rotação e revogação

7. Cultura e Governança de Secrets na Equipe

7.1. Treinamento de desenvolvedores

Crie um checklist de segurança que todo PR deve passar:

Checklist de Secrets (pré-merge)
[ ] Nenhuma senha ou token aparece no código
[ ] Arquivos .env estão no .gitignore
[ ] Hooks de pré-commit estão ativos
[ ] Secrets de produção não são usados em staging
[ ] Variáveis de ambiente de CI/CD estão criptografadas

7.2. Políticas de acesso com RBAC

Implemente approval workflows para acesso a secrets críticos:

  • Desenvolvedores: acesso apenas a secrets de desenvolvimento
  • SRE/DevOps: acesso a secrets de staging e produção
  • Auditoria: logs de quem acessou o quê e quando

7.3. Ferramentas de compliance

Para demonstrar conformidade com SOC 2, ISO 27001 e GDPR:

  • Vault Enterprise oferece namespaces e control groups para multi-tenancy
  • AWS Secrets Manager gera relatórios de auditoria via CloudTrail
  • HashiCorp Sentinel permite políticas de governança como código

Referências