Onde guardar configurações e segredos

Trate de forma diferente configurações não sensíveis, como URLs de serviços e opções de recursos, e credenciais, como senhas, chaves de API e chaves privadas. Não inclua credenciais reais no código nem envie arquivos com esses dados para um repositório compartilhado. Primeiro, confira quais mecanismos de configuração o aplicativo aceita.

Se as ferramentas aceitarem, guarde os valores locais de cada pessoa em um arquivo .env e compartilhe um .env.example com apenas nomes de variáveis e valores fictícios. Inclua o .env real no .gitignore e confirme que o Git já não o está rastreando. Uma regra de exclusão do Git não é um armazenamento seguro e não remove valores do histórico existente.

Em sistemas de CI, como o GitHub Actions, cadastre credenciais pelo recurso de segredos do provedor, em vez de colocá-las nos arquivos de workflow. Restrinja o acesso aos repositórios, ambientes e tarefas que precisam delas, conceda aos tokens apenas as permissões necessárias e evite imprimir os valores. A ocultação nos logs não garante que todo valor transformado ou saída de comando ficará escondido.

Em produção, prefira o armazenamento de segredos do provedor de hospedagem ou da nuvem e limite quais implantações e serviços podem ler cada valor. O Docker Compose pode montar segredos como arquivos para serviços autorizados explicitamente; recursos e limitações variam conforme a plataforma, então consulte a documentação do ambiente usado. Quando houver suporte, considere credenciais de curta duração, como OIDC, em vez de chaves válidas por muito tempo.

Se um segredo pode ter aparecido em um commit, log de CI ou conversa, apagar a cópia visível não é suficiente. Primeiro, revogue ou troque a chave ou o token afetado; depois, examine os logs de acesso e os possíveis usos. Em seguida, trate o histórico do repositório e os logs conforme necessário e reforce os controles de acesso para evitar que aconteça de novo.