Tema: secrets
-
Um segredo foi commitado: por que apagar o arquivo não basta e qual é a ordem de resposta
Uma credencial enviada a um repositório Git permanece no histórico, em forks, clones, caches e logs de CI. Reescrever o histórico reduz a exposição futura, mas não recolhe as cópias já feitas; por isso, primeiro revogue e troque a credencial, depois limpe o histórico e, por fim, verifique se ela foi usada.
-
Logging em scripts de administração: logger e systemd-cat no Linux, Write-EventLog/New-WinEvent e Start-Transcript no Windows
Cada plataforma oferece um meio de enviar a saída de um script de administração para um local onde uma pessoa ou outra ferramenta a encontre depois, diferente de escrever em stdout: logger(1) ou systemd-cat no log do sistema no Linux; o Event Log do Windows via Write-EventLog (apenas no Windows PowerShell 5.1) ou New-WinEvent; e Start-Transcript para uma captura bruta da sessão. Nenhum deles deve jamais receber um segredo.
-
Onde ficam, numa máquina de desenvolvimento, as credenciais que um processo de agente consegue ler
Um agente executado com a conta do usuário consegue ler tudo o que esse usuário consegue ler: variáveis de ambiente, arquivos de credenciais de CLIs, logins de registries de contêineres, chaves SSH, histórico do shell e repositórios de dados próximos ao navegador. Conhecer esses locais permite ao operador decidir o que manter fora do alcance do agente e o que rotacionar após um incidente.
-
ConfigMaps e Secrets no Kubernetes: limites de tamanho, propagação de atualizações e o que um Secret não protege
ConfigMaps e Secrets são objetos chave-valor limitados a 1 MiB; as chaves montadas como volume são atualizadas após um atraso de sincronização do kubelet, as variáveis de ambiente nunca, e montagens com subPath também nunca. Um Secret é apenas codificado em base64 e fica sem criptografia no etcd, a menos que criptografia em repouso e RBAC sejam configurados.
-
Armazenar segredos para scripts não supervisionados: systemd credentials, DPAPI, keychain do macOS — e o que não fazer
Cada sistema operacional tem um mecanismo para entregar um segredo a um script sem usar variável de ambiente nem argumento de linha de comando, que qualquer processo vizinho ou log pode ler: LoadCredential= no systemd, DPAPI no Windows (via Export-Clixml ou SecretManagement) e o keychain do macOS com security find-generic-password.
-
Oculte segredos antes de gravar logs
Grave nos logs um registro de diagnóstico restrito a uma allowlist, em vez das requisições brutas de ferramentas, e verifique a ocultação em cada destino de saída.
-
Gerenciar segredos fora do repositório
Credenciais devem ficar em configuração protegida, injetada em tempo de execução, nunca no controle de versão, em imagens ou em logs; cada serviço recebe credenciais próprias e restritas, e a rotação é um procedimento praticado, não uma emergência. Os passos seguem o cheat sheet da OWASP sobre gestão de segredos e a separação entre configuração e código do Twelve-Factor.
-
A rotação programada de segredos revela consumidores não documentados de credenciais antes que um incidente o faça
Hipótese: equipes que rotacionam segredos compartilhados de longa duração em um cronograma fixo descobrem, durante as rotações planejadas, os scripts, jobs e integrações que dependem deles sem que ninguém saiba; por isso, uma rotação de emergência após um vazamento é concluída mais rápido e quebra menos do que em equipes que só rotacionam sob suspeita. A cheat sheet da OWASP recomenda a rotação regular, mas esse ganho operacional não foi medido.
Legível por máquina: JSON