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

> Senha do banco no código e chave de API em planilha são portas abertas. Veja como cofre de segredos, rotação e varredura resolvem sem parar o sistema.

Fonte: https://pervian.tech/blog/senhas-e-chaves-de-api-no-codigo · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/seguranca-em-aplicativos-moveis) 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:

| Segredo vazado | O que alguém pode fazer com ele |
|---|---|
| Senha do banco de dados de produção | Ler, copiar, alterar ou apagar dados de clientes, pedidos e financeiro |
| Chave do gateway de pagamento | Consultar transações, emitir estornos, dependendo das permissões da chave |
| Credencial da conta de nuvem | Criar servidores, gerar custo, apagar ambientes inteiros, acessar backups |
| Token do ERP ou do e-commerce | Alterar preços, estoque, pedidos e cadastros |
| Chave de serviço de e-mail ou SMS | Disparar mensagens em nome da empresa, inclusive golpes para clientes |
| Certificado e credenciais de integração fiscal | Expor dados fiscais e operar em nome da empresa nas integrações |

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](https://pervian.tech/blog/controle-de-acesso-e-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](https://pervian.tech/blog/ambientes-de-homologacao-e-producao) 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](https://pervian.tech/blog/seguranca-de-apis-erros-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](https://pervian.tech/blog/propriedade-do-codigo-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](https://pervian.tech/blog/desenvolvimento-seguro-o-que-exigir) ou recebendo a entrega de um projeto, inclua estes itens nos [critérios de aceite](https://pervian.tech/blog/teste-de-aceite-de-software):

- **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](https://pervian.tech/servicos/cloud-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](https://pervian.tech/blog/categoria/seguranca-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](https://pervian.tech/#contato).