O gerenciamento de segredos é uma das práticas mais críticas em DevOps. Segredos — como senhas, chaves de API, tokens e certificados — são as chaves do reino digital. Se caírem em mãos erradas, podem comprometer sistemas inteiros, causar vazamentos de dados e danos financeiros e de reputação. Nesta aula, vamos explorar por que não devemos versionar segredos, o que são vaults, como usar variáveis de ambiente com segurança e como implementar rotação de segredos.

Você aprenderá a diferença entre configuração e segredo, verá exemplos de ferramentas como HashiCorp Vault, AWS Secrets Manager e Kubernetes Secrets, e entenderá as melhores práticas para proteger informações sensíveis no ciclo de vida do desenvolvimento. Ao final, terá uma base sólida para implementar uma estratégia robusta de gerenciamento de segredos em seus projetos.

Por que não versionar segredos

Versionar segredos em sistemas de controle de versão como Git é um erro comum e perigoso. Uma vez que um segredo é commitado, ele fica no histórico do repositório para sempre, mesmo que seja removido em um commit posterior. Isso significa que qualquer pessoa com acesso ao repositório (ou a um clone antigo) pode recuperar o segredo. Além disso, ferramentas de CI/CD frequentemente têm acesso ao repositório, e logs de build podem expor segredos acidentalmente.

Os riscos incluem: exposição a terceiros se o repositório for público; comprometimento de contas e serviços; violação de políticas de segurança; e dificuldade de revogação, pois o segredo pode ter sido copiado por muitos. Mesmo em repositórios privados, a prática de versionar segredos é arriscada porque aumenta a superfície de ataque e dificulta a auditoria.

Em vez de versionar segredos, devemos armazená-los em locais seguros, como vaults, e referenciá-los em configuração. O código-fonte deve conter apenas referências a variáveis de ambiente ou a serviços de gerenciamento de segredos. Por exemplo, em vez de:

DB_PASSWORD="senha123"

devemos usar:

DB_PASSWORD=${DB_PASSWORD}

e definir a variável no ambiente de execução.

Vaults (visão geral)

Um vault é um sistema centralizado para armazenar e gerenciar segredos de forma segura. Ele permite que você armazene segredos em um local criptografado, controle acesso por políticas e audite quem acessou o quê. Vaults oferecem recursos como revogação, rotação, geração dinâmica de credenciais e integração com sistemas de autenticação.

Ferramentas populares incluem:

  • HashiCorp Vault: uma das mais completas, suporta múltiplos backends (como AWS, Kubernetes, bancos de dados), geração dinâmica de credenciais e rotação automática.
  • AWS Secrets Manager: serviço gerenciado da AWS, integrado com IAM, suporta rotação automática para serviços como RDS.
  • Kubernetes Secrets: nativo do Kubernetes, mas com limitações (não criptografa por padrão em etcd, sem rotação automática).
  • Azure Key Vault: serviço da Azure com integração com Azure AD.
  • Google Cloud Secret Manager: serviço da GCP.

Um vault funciona como uma API: você autentica, solicita um segredo e recebe-o temporariamente. Por exemplo, com o Vault CLI:

vault kv get secret/myapp/dbpassword

Isso retorna o segredo apenas se a política de acesso permitir. O acesso pode ser revogado a qualquer momento, e os logs de auditoria registram cada acesso.

Variáveis de ambiente

Variáveis de ambiente são uma forma comum de passar segredos para aplicações sem hardcodá-los no código. Elas são definidas no ambiente de execução e podem ser lidas pelo processo. No entanto, usá-las de forma segura exige cuidados:

  • Nunca coloque segredos em arquivos versionados como .env commitado; em vez disso, use .env.example com placeholders e carregue o .env real localmente.
  • Em produção, defina variáveis de ambiente diretamente na infraestrutura (como no sistema operacional, Kubernetes, ou plataformas de nuvem).
  • Evite imprimir variáveis de ambiente em logs ou saídas de depuração.
  • Use mecanismos de injeção de segredos, como o Kubernetes Secrets ou o Vault Agent, para injetar segredos como variáveis de ambiente no momento da execução.

Um exemplo de uso em bash:

export DB_PASSWORD="$(vault kv get -field=value secret/myapp/dbpassword)"
./meu_app

Isso busca o segredo dinamicamente e o define como variável de ambiente. Em aplicações, você lê a variável normalmente:

echo $DB_PASSWORD

Mas tenha cuidado: expor variáveis de ambiente em processos filhos pode ser um risco se não for controlado. Use princípios de privilégio mínimo.

Rotação

Rotação de segredos é o processo de substituir segredos periodicamente ou após um incidente. Isso reduz a janela de exposição caso um segredo seja comprometido. A rotação pode ser manual ou automática, e deve ser planejada para minimizar interrupções.

Boas práticas incluem:

  • Defina uma política de rotação baseada na sensibilidade do segredo (ex.: chaves de banco a cada 30 dias, tokens de API a cada 90 dias).
  • Automatize a rotação sempre que possível. Ferramentas como Vault podem gerar credenciais dinâmicas com TTL (time-to-live) e revogá-las automaticamente.
  • Para segredos estáticos, use APIs de rotação (ex.: AWS Secrets Manager pode rotacionar automaticamente o RDS).
  • Teste a rotação em ambientes de staging antes de produção.

Um exemplo de rotação manual com Vault:

# Gerar nova senha aleatória
export NEW_PASSWORD=$(openssl rand -base64 24)

# Atualizar no Vault
vault kv put secret/myapp/dbpassword value=$NEW_PASSWORD

# Atualizar no banco de dados
mysql -u root -p -e "ALTER USER 'app'@'%' IDENTIFIED BY '$NEW_PASSWORD';"

Em ambientes automatizados, você pode usar scripts ou ferramentas de CI/CD para executar esses passos com segurança.

Boas práticas e observações finais

Além do que foi visto, considere as seguintes boas práticas:

  • Use criptografia em trânsito e em repouso para segredos.
  • Implemente autenticação forte para acessar o vault, como MFA.
  • Monitore e audite o acesso a segredos.
  • Evite compartilhar segredos por canais inseguros (e-mail, chat).
  • Use ferramentas de varredura de segredos no código (como git-secrets, trufflehog) para detectar segredos acidentalmente commitados.

O gerenciamento de segredos é uma jornada contínua. Comece com o básico: nunca versionar segredos, use vaults, injete segredos como variáveis de ambiente e implemente rotação. Com isso, você reduzirá drasticamente o risco de vazamentos.

Referências

Exercícios

  1. Explique por que não se deve versionar segredos e cite dois riscos concretos.

    ✓ Resposta: Versionar segredos é perigoso porque eles ficam no histórico do repositório, podendo ser acessados por qualquer pessoa com acesso ao repositório ou a um clone antigo. Dois riscos concretos: 1) Se o repositório for público, qualquer pessoa pode encontrar o segredo e usá-lo para acessar sistemas. 2) Mesmo em repositório privado, um ex-funcionário com acesso anterior pode ter cópia do histórico e extrair o segredo.
  2. Diferencie variáveis de ambiente de vaults. Quando cada um é mais adequado?

    ✓ Resposta: Variáveis de ambiente são adequadas para configuração não sensível ou para segredos em ambientes de desenvolvimento local, onde a segurança é menos crítica. Vaults são adequados para produção, onde há necessidade de controle de acesso, auditoria, revogação e rotação automática. Vaults oferecem centralização e políticas, enquanto variáveis de ambiente são simples, mas difíceis de gerenciar em escala.
  3. Escreva um comando bash para buscar um segredo do Vault e usá-lo como variável de ambiente em um processo.

    ✓ Resposta: 
    export DB_PASSWORD="$(vault kv get -field=value secret/myapp/dbpassword)"
./meu_app
  4. Quais são os benefícios da rotação automática de segredos? Cite dois.

    ✓ Resposta: 1) Reduz a janela de exposição: se um segredo for comprometido, ele será trocado rapidamente, limitando o tempo que o atacante pode usá-lo. 2) Elimina a intervenção manual, reduzindo erros humanos e melhorando a eficiência operacional.
  5. Descreva um cenário onde você usaria Kubernetes Secrets e onde usaria um Vault externo.

    ✓ Resposta: Usaria Kubernetes Secrets para segredos simples em um cluster pequeno, onde a simplicidade é mais importante e a segurança não é crítica. Usaria um Vault externo (como HashiCorp Vault) em ambientes maiores, com requisitos de auditoria, rotação dinâmica e políticas de acesso centralizadas, especialmente se houver múltiplos clusters ou integração com outros serviços.