Gerenciamento Seguro de Segredos e Variáveis de Ambiente

Secrets codificados diretamente no código — chaves de API, senhas de banco de dados, chaves privadas TLS e tokens OAuth incorporados diretamente no código-fonte — estão entre as vulnerabilidades de segurança mais comuns e evitáveis. Os Secrets no código-fonte ficam expostos no histórico do controle de versão (mesmo após serem excluídos), visíveis para todos os desenvolvedores com acesso ao repositório e frequentemente são vazados quando os repositórios são acidentalmente tornados públicos. Ferramentas como o GitGuardian e o truffleHog verificam continuamente a existência de Secrets vazados em plataformas como o GitHub.

As variáveis de ambiente removem os Secrets do código-fonte ao injetá-los em tempo de execução por meio do sistema operacional do host ou do orquestrador de contêineres. A aplicação lê os.environ['DB_PASSWORD'] em vez de um valor codificado diretamente no código. Isso é melhor do que codificar o valor diretamente, mas as variáveis de ambiente têm pontos fracos: aparecem nas listas de processos, são herdadas por processos filhos, frequentemente acabam em dumps de falhas e logs de depuração e exigem rotação manual. Elas são apropriadas para desenvolvimento, mas não são suficientes por si só para o gerenciamento de Secrets em produção.

Os gerenciadores de Secrets são sistemas desenvolvidos especificamente para armazenar, fazer a rotação e auditar o acesso a Secrets. Entre as principais soluções estão o HashiCorp Vault (de código aberto e empresarial), o AWS Secrets Manager, o Azure Key Vault e o Google Cloud Secret Manager. As aplicações se autenticam no gerenciador de Secrets em tempo de execução, recuperam o Secret e o utilizam — nenhum Secret é armazenado em disco ou em variáveis de ambiente. Todo acesso é registrado, permitindo auditar quem acessou qual Secret e quando.

Uma vantagem importante dos gerenciadores de Secrets em relação às variáveis de ambiente é a rotação automática. O AWS Secrets Manager pode fazer automaticamente a rotação das senhas de bancos de dados RDS em uma programação definida (por exemplo, a cada 30 dias), sem exigir a reimplantação da aplicação. O gerenciador de Secrets atualiza a senha no banco de dados e o Secret armazenado simultaneamente. As aplicações que recuperam Secrets a cada conexão recebem automaticamente a nova credencial. Isso elimina a prática comum de usar senhas de contas de serviço “permanentes” que nunca sofrem rotação.

A primeira linha de defesa contra segredos enviados ao repositório é um arquivo .gitignore mantido corretamente, que exclua todos os arquivos que possam conter segredos. No entanto, o .gitignore apenas impede envios futuros — os segredos já enviados continuam no histórico do git. Se segredos forem enviados acidentalmente, eles deverão ser considerados comprometidos imediatamente: faça a rotação do segredo e, opcionalmente, use ferramentas como git filter-repo para reescrever o histórico (necessário para conformidade, mas insuficiente por si só, pois o segredo já pode ter sido extraído).

Arquivos de Infrastructure as Code (IaC) (Terraform, CloudFormation e manifestos do Kubernetes) frequentemente contêm segredos — strings de conexão com bancos de dados, chaves de API em declarações de variáveis de ambiente e certificados TLS. Esses arquivos costumam ser enviados ao controle de versão, criando risco de exposição de segredos. As soluções incluem segredos dinâmicos do Vault (Vault gera uma credencial de curta duração especificamente para cada execução do Terraform), Kubernetes Secrets (armazenados no etcd, devem ser criptografados em repouso) e o external-secrets-operator, que sincroniza dados de um gerenciador de segredos com o Kubernetes durante a execução.

Cada aplicação ou serviço deve acessar apenas os segredos de que necessita especificamente — o princípio do menor privilégio aplicado a segredos. Uma aplicação Web precisa da senha do banco de dados, mas não da chave privada da CA. Uma tarefa de geração de relatórios precisa de credenciais de banco de dados somente leitura, não de acesso para gravação. Os gerenciadores de segredos aplicam isso por meio de políticas de acesso que especificam quais identidades (funções do IAM, contas de serviço e AppRoles) podem ler quais segredos, com todo acesso registrado para auditoria.

Segredos dinâmicos são gerados sob demanda para um solicitante específico e expiram automaticamente. O Vault pode gerar uma credencial temporária de banco de dados válida por 1 hora e associada ao serviço específico que a solicitou. Após a expiração, a credencial é revogada automaticamente pelo banco de dados. Essa abordagem elimina credenciais estáticas de longa duração que possam ser roubadas — mesmo que um atacante capture uma credencial dinâmica, ela expirará rapidamente e ficará vinculada à identidade solicitante nos registros de auditoria.

Os pipelines de CI/CD frequentemente exigem segredos — credenciais de provedores de nuvem para implantação, tokens de registro do Docker e chaves de assinatura. Nunca armazene segredos em scripts de pipeline ou arquivos de configuração. Em vez disso, use o armazenamento de segredos integrado à plataforma de pipeline (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) ou busque os segredos de um cofre central durante a execução, usando uma identidade de máquina. Marque as variáveis secretas como mascaradas nos registros para evitar exposição acidental na saída da compilação.

Os gerenciadores de segredos fornecem registros de auditoria abrangentes de cada evento de acesso a um segredo: qual identidade acessou qual segredo, a partir de qual IP, em que horário e se o acesso foi bem-sucedido ou negado. Esses registros são essenciais para a conformidade (SOC 2, PCI-DSS) e para a resposta a incidentes. Quando há suspeita de comprometimento de uma credencial, os registros de auditoria revelam quais sistemas a acessaram e quando — permitindo identificar rapidamente os sistemas potencialmente afetados e tomar decisões de contenção.

Hooks de pré-commit são scripts executados automaticamente antes que cada commit do git seja finalizado, permitindo detectar segredos antes que entrem no histórico do controle de versão. Ferramentas como detect-secrets (Yelp), GitLeaks e git-secrets (AWS) integram-se como hooks de pré-commit e analisam arquivos preparados para encontrar padrões correspondentes a chaves de API, strings de conexão, chaves privadas e tokens JWT. Se um segredo for detectado, o commit será rejeitado e o desenvolvedor será orientado a remover a credencial. O pre-commit framework facilita a adição e o compartilhamento de configurações de hooks entre equipes.

Nesta lição, você aprendeu que: segredos codificados diretamente no código-fonte devem ser eliminados e substituídos por gerenciadores de segredos, como o Vault ou o AWS Secrets Manager; a rotação automática remove credenciais de longa duração que atacantes poderiam explorar mesmo após o comprometimento inicial; e segredos dinâmicos e políticas de acesso com menor privilégio minimizam o valor de qualquer segredo individual que seja exposto. A seguir, exploraremos a segurança de dependencies e a análise de composição de software.