Gestão de segredos: senhas e chaves de API fora do código

O desenvolvedor que saiu da empresa há oito meses ainda consegue entrar no banco de dados de produção. Ninguém fez isso de propósito: a senha do banco está escrita dentro do código do sistema, a mesma desde a primeira versão, e ninguém trocou porque "se trocar, o sistema para". A chave da API do gateway de pagamento está numa planilha compartilhada chamada "acessos", e o token do ERP circulou por e-mail entre três fornecedores.

Esse cenário é comum em empresas de todos os tamanhos e não tem nada de exótico. Senhas de banco, tokens de integração e chaves de API são segredos: dão acesso direto a dados de clientes, a dinheiro e a operações. Quando ficam espalhados no código, em planilhas ou em mensagens, qualquer cópia vira uma porta aberta, e a empresa não sabe quantas cópias existem.

Gestão de segredos é o conjunto de práticas que define onde essas credenciais ficam, quem pode usá-las e quando são trocadas. A resposta curta para quem pesquisa como fazer isso: tire os segredos do código, guarde-os num cofre de segredos com controle de acesso e registro de uso, e crie uma rotina de rotação para que cada chave tenha prazo de validade e possa ser trocada sem derrubar nada. O resto deste texto explica cada parte em linguagem de gestão e termina com um checklist para cobrar da equipe ou do fornecedor.

Onde as senhas dos sistemas costumam estar

Antes de resolver, vale saber onde procurar. Os lugares mais frequentes:

• Dentro do código-fonte. A senha do banco aparece num arquivo de configuração versionado junto com o resto do sistema. Quem tem acesso ao repositório tem acesso à produção.
• No histórico do repositório. Alguém percebeu o erro, apagou a senha do arquivo e seguiu em frente. Só que o histórico de versões guarda tudo. Apagar da versão atual não remove das anteriores.
• Em planilhas e documentos compartilhados. A famosa planilha de acessos, com login e senha de cada serviço, compartilhada com "todo mundo do TI" e com fornecedores que já foram embora.
• Em mensagens e e-mails. Token colado no WhatsApp para "testar rapidinho", chave de API enviada por e-mail para a agência de marketing.
• No aplicativo do celular ou no site. Chaves embutidas no app ou no código que roda no navegador podem ser extraídas por qualquer pessoa com um pouco de conhecimento técnico.
• Em servidores e scripts antigos. Rotinas de backup, scripts de importação e tarefas agendadas com a senha escrita no próprio arquivo.

O problema não é só o vazamento. É que, com os segredos espalhados, ninguém consegue responder quem tem acesso a quê, e sem essa resposta não existe controle.

O que acontece quando uma chave vaza

Uma chave de API vazada não é um risco abstrato. O dano depende do que a chave permite fazer:

Além do dano direto, há a parte legal. Se o vazamento expõe dados pessoais, a LGPD entra em cena: a empresa precisa avaliar o incidente, e em certos casos comunicar a autoridade e os titulares. A análise de quando comunicar e como cabe ao jurídico, mas o sistema precisa permitir responder às perguntas básicas: o que vazou, desde quando, quem usou e o que foi acessado.

E há o custo silencioso: depois de um vazamento, trocar uma senha que está escrita em vinte lugares diferentes leva dias, e cada lugar esquecido quebra uma integração.

Cofre de segredos em linguagem simples

Um cofre de segredos é um serviço próprio para guardar senhas, tokens e chaves de forma centralizada e controlada. Os provedores de nuvem oferecem o seu, e existem também ferramentas independentes que funcionam em qualquer infraestrutura. A escolha da ferramenta importa menos do que o modelo de funcionamento:

1. O segredo sai do código. O sistema não tem mais a senha escrita em lugar nenhum. Quando sobe, ele pede ao cofre a senha de que precisa.
2. Cada sistema tem a sua identidade. O cofre só entrega o segredo para quem tem permissão. O sistema de pedidos recebe a senha do banco de pedidos, não a do financeiro.
3. Pessoas acessam pouco ou nada. Em produção, o ideal é que nenhum desenvolvedor precise ver a senha do banco. O sistema usa, a pessoa não.
4. Todo acesso fica registrado. O cofre mantém um histórico de quem leu cada segredo e quando. É a mesma lógica de trilha de auditoria que se aplica aos usuários do sistema, agora aplicada às credenciais.
5. Os segredos são criptografados. Guardados cifrados, com chaves controladas, e não em texto puro num arquivo.

Separar ambientes também é gestão de segredos

Desenvolvimento, homologação e produção devem ter segredos diferentes. Se a senha do banco de testes é igual à de produção, qualquer vazamento no ambiente de teste, que costuma ser menos protegido, vira vazamento de produção. Com cofre, cada ambiente tem seu conjunto de credenciais, e o desenvolvedor trabalha só com as de teste.

Rotação de chaves sem derrubar integrações

Rotação é trocar um segredo periodicamente, ou imediatamente quando há suspeita de vazamento. A objeção mais comum é: "se trocar a senha, a integração para". Essa objeção é um sintoma: ela significa que a senha está escrita em lugares que ninguém conhece.

Com os segredos no cofre, a rotação segue um roteiro previsível:

1. Gerar a credencial nova sem desativar a antiga. Muitos serviços permitem duas chaves ativas ao mesmo tempo justamente para isso.
2. Atualizar o cofre com a credencial nova.
3. Fazer os sistemas pegarem a nova versão, seja reiniciando de forma controlada, seja lendo o cofre periodicamente.
4. Confirmar que tudo funciona com a credencial nova, olhando logs e monitoramento.
5. Revogar a credencial antiga. Só depois da confirmação.

Alguns cuidados que evitam surpresa:

• Defina a frequência por risco. Credenciais de produção com acesso a dados sensíveis pedem rotação mais frequente do que uma chave de leitura de um serviço interno. A frequência certa é uma decisão de risco, não uma regra única.
• Prefira credenciais temporárias quando existir a opção. Vários serviços de nuvem e bancos de dados permitem credenciais geradas sob demanda que expiram sozinhas em pouco tempo. Uma credencial que vence logo vaza com dano menor.
• Automatize o que dá. Rotação manual depende de lembrança e costuma ser esquecida. Rotação automatizada vira rotina.
• Tenha um roteiro de emergência. Quando uma chave vaza, a troca precisa acontecer em horas, não em dias. Isso só é possível se o roteiro já foi testado antes.

Integrações com terceiros merecem atenção especial, porque nem todo parceiro permite duas chaves ativas. Nesses casos, a troca é combinada com antecedência e feita numa janela de menor movimento. Os demais cuidados com integrações expostas estão em segurança de APIs: os erros mais comuns.

Acesso de fornecedores e ex-funcionários

Aqui está boa parte do risco real. Toda pessoa que já viu uma senha de produção pode, em tese, ainda usá-la. Isso inclui ex-funcionários, freelancers de projetos antigos, agências e fornecedores que trocaram de equipe.

O que muda com uma gestão de segredos organizada:

• Fornecedor acessa com credencial própria, nunca com a do sistema ou a de outra pessoa. Quando o contrato termina, revoga-se a credencial dele, e só ela.
• Saída de pessoa dispara revisão. O desligamento de alguém com acesso técnico entra num checklist: quais segredos essa pessoa viu e quais precisam ser rotacionados.
• Permissão mínima. A agência que cuida do site não precisa da chave do ERP. O fornecedor do aplicativo não precisa da credencial da conta de nuvem inteira.
• A conta principal é da empresa. Conta de nuvem, domínio, repositório de código e cofre de segredos devem estar em nome da empresa, com o fornecedor como convidado. O contrário cria dependência difícil de desfazer. Esse ponto conversa diretamente com a propriedade do código-fonte no contrato: de pouco adianta ser dono do código se as chaves que o fazem funcionar estão na conta de outra pessoa.

Como verificar se há segredos no seu código

Você não precisa ler código para saber se há um problema. Peça à equipe técnica ou ao fornecedor que responda, por escrito:

1. Existe alguma senha, token ou chave escrita no código ou em arquivos versionados? A resposta deve vir de uma varredura automática, não de memória. Existem ferramentas que procuram padrões de segredos no código e em todo o histórico do repositório.
2. A varredura roda automaticamente a cada mudança? O ideal é que o próprio processo de publicação bloqueie a entrada de um segredo novo no código, antes que ele chegue ao repositório.
3. Onde os segredos de produção estão guardados hoje? Se a resposta envolve planilha, documento ou "no servidor", há trabalho a fazer.
4. Quem consegue ver a senha do banco de produção? Uma lista de nomes, não "o pessoal do TI".
5. Quando foi a última troca das credenciais principais? Se a resposta é "nunca" ou "não sei", trate como se estivessem vazadas.
6. Os ambientes de teste usam credenciais diferentes das de produção?
7. O app ou o site carrega alguma chave que deveria ser secreta? Chaves que vão para o navegador ou para o celular devem ser só as públicas, com permissões limitadas.

Se a varredura encontrar segredos no histórico, a correção não é apenas limpar o histórico. O segredo encontrado deve ser considerado comprometido e rotacionado, porque não há como saber quem copiou o repositório antes da limpeza.

Por onde começar se o problema é grande

Quando o diagnóstico mostra segredos espalhados em todo lugar, uma sequência que funciona:

1. Inventariar os segredos: quais existem, para que servem, onde estão.
2. Priorizar pelos de maior impacto: banco de produção, conta de nuvem, pagamentos.
3. Colocar esses no cofre e trocar o sistema para lê-los de lá.
4. Rotacionar cada um logo depois da migração, porque o valor antigo já circulou.
5. Ativar a varredura automática para impedir que o problema volte.
6. Repetir para os segredos de menor impacto.

Em sistemas pequenos, as primeiras etapas costumam caber em poucas semanas; em sistemas com muitas integrações, leva mais. A estimativa real só sai depois do inventário.

O que exigir na entrega do sistema

Se você está contratando um sistema novo ou recebendo a entrega de um projeto, inclua estes itens nos critérios de aceite:

• Nenhum segredo no código ou no histórico do repositório, comprovado por varredura automática.
• Segredos de produção num cofre, em conta da empresa, com acesso registrado.
• Credenciais separadas por ambiente e por sistema.
• Roteiro de rotação documentado para cada credencial crítica, incluindo as de integrações com terceiros.
• Lista de quem tem acesso a quê, entregue junto com a documentação.
• Transferência formal dos acessos ao fim do projeto: contas de nuvem, repositório, domínio e cofre em nome da empresa, com as credenciais do fornecedor revogadas ou reduzidas ao necessário para a manutenção contratada.
• Varredura de segredos no processo de publicação, para que o padrão se mantenha depois da entrega.

Esses itens custam pouco quando são previstos no início do projeto e custam muito quando precisam ser encaixados depois, num sistema que já está em produção.

Erros comuns na gestão de segredos

• Achar que repositório privado resolve. Repositório privado reduz a exposição, mas qualquer pessoa com acesso a ele, hoje ou no passado, tem a senha de produção.
• Confundir gerenciador de senhas com cofre de segredos. O gerenciador de senhas resolve bem o problema das pessoas guardarem e compartilharem seus logins. Para os sistemas lerem credenciais de forma automatizada, com permissão por sistema e registro de cada leitura, o que se precisa é de um cofre de segredos, ou de um gerenciador que ofereça esse recurso de forma explícita.
• Mover o problema em vez de resolver. Tirar a senha do código e colocá-la num arquivo no servidor, sem controle de acesso nem registro, só muda o endereço do risco.
• Nunca testar a rotação. Roteiro que nunca foi executado falha justamente no dia do incidente.

Perguntas frequentes

O que é um cofre de segredos?

Um cofre de segredos é um serviço que guarda senhas, tokens e chaves de API de forma centralizada, criptografada e com controle de acesso. O sistema pede ao cofre a credencial de que precisa, cada sistema recebe só os segredos permitidos e todo acesso fica registrado. Os provedores de nuvem oferecem cofres próprios.

Qual a diferença entre gerenciador de senhas e cofre de segredos?

O gerenciador de senhas resolve o problema das pessoas guardarem e compartilharem seus logins. O cofre de segredos atende os sistemas, que leem credenciais de forma automatizada, com permissão por sistema e registro de cada leitura. Alguns gerenciadores oferecem os dois recursos, mas a diferença precisa estar explícita na escolha da ferramenta.

Apagar a senha do código resolve o vazamento?

Não. O histórico do repositório guarda as versões anteriores, então a senha apagada continua acessível a quem tem ou teve acesso ao código. Qualquer segredo encontrado no código ou no histórico deve ser considerado comprometido e rotacionado, porque não há como saber quem copiou o repositório antes da limpeza.

De quanto em quanto tempo trocar senhas e chaves de API?

Depende do risco de cada credencial. Senhas de produção com acesso a dados sensíveis pedem rotação mais frequente do que uma chave de leitura de serviço interno, e qualquer suspeita de vazamento exige troca imediata. Sempre que possível, credenciais temporárias, que expiram sozinhas em pouco tempo, reduzem o dano de um vazamento.

Como a Pervian Tech trabalha gestão de segredos

Na Pervian Tech, gestão de segredos faz parte do trabalho de cloud e DevOps. Começamos por um inventário: varremos o código e o histórico, mapeamos onde cada credencial está, quem tem acesso e quais integrações dependem dela. A partir disso, montamos um plano em linguagem de gestão, com o que migrar primeiro para o cofre, quais chaves precisam de rotação imediata e como deixar a varredura automática no processo de publicação, para o problema não voltar.

Em sistemas que desenvolvemos, esse cuidado vem desde o primeiro dia: segredos fora do código, contas em nome do cliente e roteiro de rotação na documentação de entrega. Em sistemas existentes, o trabalho é incremental e sem derrubar operação. Outros temas do assunto estão na categoria Segurança e LGPD.

Cada projeto é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você suspeita que as senhas dos seus sistemas estão em lugares onde não deveriam, fale com a gente.