Secret Management: nunca deixe senhas e tokens espalhados no código

O problema de secrets no código e no git

Por que credenciais hardcoded são uma das maiores ameaças à segurança

Secrets hardcoded no código-fonte são expostos a qualquer pessoa com acesso ao repositório, incluindo colaboradores externos, ferramentas de análise de código e, no caso de repos públicos, qualquer pessoa na internet. O histórico do Git torna a situação ainda pior: mesmo que a credencial seja removida em um commit posterior, ela permanece acessível via git log ou ferramentas como git reflog, exigindo uma reescrita completa do histórico para eliminação definitiva. Estudos recorrentes de segurança encontram centenas de milhares de credentials expostas em repositórios GitHub públicos, incluindo chaves AWS, tokens de banco de dados e API keys de pagamento com acesso à conta real. A gravidade do problema é que a janela entre o commit e a exploração por atores maliciosos pode ser de minutos, pois bots escaneiam repositórios continuamente em busca de padrões de credenciais conhecidos.

Variáveis de ambiente — a solução mínima

Separando configuração do código para diferentes ambientes

Variáveis de ambiente injetam configuração no processo da aplicação sem que ela precise saber de onde os valores vêm, permitindo que o mesmo código rode em desenvolvimento, staging e produção com diferentes credenciais. O arquivo .env é convencionalmente usado para definir variáveis de ambiente localmente em desenvolvimento, mas nunca deve ser commitado no Git, sendo obrigatória sua presença no .gitignore desde o primeiro commit do projeto. Em produção, variáveis de ambiente são configuradas no sistema operacional, no container runtime ou no serviço gerenciado de deploy, garantindo que segredos nunca persistam em disco dentro do repositório ou do artefato de build. A principal limitação de variáveis de ambiente é a ausência de auditoria, rotação automática e controle de acesso granular, tornando-as insuficientes para sistemas com muitos segredos ou requisitos de compliance rigorosos.

Secret managers — AWS Secrets Manager, GCP Secret Manager

Centralizando e controlando acesso a segredos em produção

Secret managers são serviços especializados no armazenamento seguro, controle de acesso e ciclo de vida de credenciais, oferecendo APIs para que aplicações recuperem segredos em runtime sem precisar tê-los na configuração estática. O AWS Secrets Manager armazena segredos criptografados com KMS, controla acesso via IAM policies, registra todo acesso no CloudTrail e suporta rotação automática de credenciais de bancos RDS e outros serviços AWS. O Google Cloud Secret Manager oferece controle de acesso por versão de secret, integração com Cloud Audit Logs e suporte a replicação regional para alta disponibilidade. Além de segurança aprimorada, secret managers centralizados permitem auditoria de quem acessou qual segredo quando, facilitando resposta a incidentes e conformidade com regulações como PCI-DSS e SOC 2.

Rotação automática de secrets

Reduzindo o impacto de credenciais comprometidas com renovação periódica

Rotação de secrets é a prática de substituir credenciais periodicamente, limitando a janela de exposição caso uma credencial seja comprometida sem o conhecimento do time de segurança. O AWS Secrets Manager suporta rotação automática de senhas de banco de dados RDS com zero downtime, usando uma função Lambda que atualiza a senha no banco e no secret simultaneamente. A rotação deve ser implementada de forma que a aplicação consiga obter o novo secret sem restart, seja via recarregamento periódico do cache de secrets ou via sidecar como Vault Agent que atualiza automaticamente arquivos de configuração. Credentials dinâmicas, disponíveis no HashiCorp Vault, vão além da rotação: o segredo é gerado on-demand com TTL curto e nunca existe de forma estática, sendo o modelo mais seguro possível para credenciais de banco de dados e serviços de nuvem.

Secrets em Kubernetes — como usar corretamente

Evitando armadilhas comuns no gerenciamento de segredos em clusters

Kubernetes Secrets são objetos nativos do cluster que armazenam dados sensíveis codificados em base64, o que não é criptografia e não oferece proteção real sem configuração adicional. A criptografia em repouso de Secrets no etcd deve ser habilitada explicitamente no apiserver com um encryption provider como AES-CBC ou KMS, pois por padrão os Secrets são armazenados em texto plano no etcd. External Secrets Operator sincroniza segredos de fontes externas como AWS Secrets Manager, Vault ou GCP Secret Manager para Kubernetes Secrets nativos, mantendo a fonte da verdade fora do cluster. Pods devem consumir Secrets como variáveis de ambiente ou volumes montados, e o acesso deve ser restrito pelo RBAC do Kubernetes ao mínimo necessário de ServiceAccounts, evitando que qualquer pod no cluster possa listar ou ler todos os segredos.

.env files — boas práticas e riscos

Usando arquivos .env com segurança em projetos locais e de equipe

Arquivos .env devem ser adicionados ao .gitignore antes do primeiro commit do projeto, prevenindo sua inclusão acidental no repositório. A prática recomendada é manter um arquivo .env.example com todas as variáveis necessárias mas com valores placeholder, que é commitado no repositório para documentar a configuração necessária sem expor valores reais. Em projetos com equipe, um repositório privado de segredos ou um password manager compartilhado como 1Password Teams ou Bitwarden distribui os valores reais sem expô-los em sistemas de versão. Ferramentas como dotenv-vault e Doppler oferecem sincronização segura de .env entre membros da equipe e ambientes, com controle de acesso e histórico de mudanças, sendo uma alternativa mais robusta que compartilhamento manual.

Scanning de secrets no git — git-secrets e TruffleHog

Detectando credenciais acidentalmente adicionadas antes de chegarem ao remoto

git-secrets é um hook de pre-commit desenvolvido pela AWS que escaneia o diff de cada commit em busca de padrões de credenciais AWS e permite adicionar padrões customizados, bloqueando o commit se encontrar algo suspeito. TruffleHog analisa o histórico completo de um repositório Git em busca de strings de alta entropia e padrões conhecidos de API keys, podendo ser executado tanto localmente quanto em pipelines de CI. Gitleaks é uma alternativa mais recente ao TruffleHog com melhor performance e suporte a mais de 150 tipos de secrets pré-configurados, disponível como action no GitHub Actions para bloquear PRs que introduzam credenciais. A integração de scanning no pipeline de CI como gate obrigatório garante que mesmo desenvolvedores que esquecem de configurar hooks locais não consigam mergear código com credenciais expostas.

Secrets em CI/CD — GitHub Actions, GitLab

Protegendo credenciais nos pipelines de build e deploy

GitHub Actions permite armazenar segredos no repositório ou na organização via Settings > Secrets, injetando-os como variáveis de ambiente nos workflows sem que sejam visíveis nos logs ou no código. Segredos no GitHub Actions são mascarados automaticamente nos logs — se o valor aparecer acidentalmente impresso, aparece como asteriscos — mas isso não protege contra exfiltração por código malicioso no workflow. GitLab CI/CD possui o conceito de Variables com opção masked e protected, onde protected variables só estão disponíveis em branches e tags protegidas, reduzindo a superfície de exposição em projetos com contribuidores externos. OIDC (OpenID Connect) integration entre CI/CD e provedores de nuvem elimina a necessidade de credenciais estáticas de longa vida em pipelines, usando tokens temporários gerados por confiança federada entre o CI e a nuvem.

Princípio de menor privilégio em secrets

Concedendo apenas o acesso necessário a cada aplicação e ambiente

Cada aplicação deve ter seu próprio conjunto de credenciais com acesso limitado estritamente às operações que ela realiza, em vez de compartilhar uma única credencial administrativa entre múltiplos serviços. Um serviço de leitura de catálogo de produtos não precisa de permissão de escrita no banco de dados, assim como um microserviço de relatórios não precisa de acesso à API de pagamentos. Ambientes de desenvolvimento, staging e produção devem usar credenciais completamente independentes, prevenindo que um incidente em desenvolvimento possa afetar dados de produção. A revisão periódica de permissões concedidas — rotação de acesso não apenas de valor mas de escopo — garante que credenciais obsoletas de serviços desativados ou de integrações não mais utilizadas sejam revogadas oportunamente.

Conclusão — secrets bem gerenciados são a base da segurança operacional

Da variável de ambiente ao secret manager: evolua conforme cresce a complexidade

O gerenciamento de secrets é uma prática que deve evoluir junto com o sistema: projetos pequenos podem começar com variáveis de ambiente bem organizadas, mas aplicações em produção com equipes e conformidade regulatória exigem secret managers, rotação automática e auditoria. O princípio fundamental nunca muda: credenciais não pertencem ao código, não pertencem ao repositório e não devem ser compartilhadas entre ambientes ou serviços. Continue em: Fundamentos obrigatórios antes de produção.