Seu fornecedor antigo ainda está logado na sua produção

Toda vez que a gente assume um produto que rodou com outro fornecedor, um achado se repete: chave de produção na mão de quem saiu meses atrás, segredo commitado no repositório, conta root dividida por cinco pessoas. Um relato de campo sobre a faxina de acesso que quase ninguém faz, e por que ela sai cara depois.

Terceiro dia de diagnóstico numa healthtech de agendamento, catorze pessoas no time, produto rodando fazia quase três anos com uma agência que tinha saído em janeiro. Rodei um scan de segredo no histórico do git enquanto o café esfriava. O terminal cuspiu vinte e três achados. Seis ainda válidos.

Uma chave da AWS commitada dezenove meses antes, viva. Uma credencial de gateway de pagamento que dava pra listar transação. Uma URL de banco com usuário e senha em texto puro, num arquivo de config que alguém esqueceu de tirar do versionamento. Nada disso era pegadinha de filme. Estava tudo ali, no repositório que qualquer pessoa com acesso ao GitHub da empresa conseguia clonar em trinta segundos.

E aqui vem a parte que costuma incomodar o founder mais do que o segredo em si: três ex-prestadores da agência ainda estavam no org do GitHub. Um deles tinha saído oito meses antes. Ninguém revogou nada. Ninguém lembrou de revogar.

O scan de segredo não inventa nada. Ele só lê o que já estava no histórico do repositório, esperando alguém procurar.

Ninguém arromba a porta que já está aberta

Quando founder pensa em segurança, pensa em ataque: alguém de fora, um hacker de moletom, um ransomware. Na prática, o risco mais comum que a gente encontra não tem invasor nenhum. É acesso que sobrou. Gente que entrou pra fazer um trabalho, ganhou uma chave, entregou o trabalho e foi embora, e a chave ficou.

Acesso é fácil de dar e chato de tirar. Dar acesso resolve um problema imediato de alguém, então acontece rápido. Tirar acesso não resolve problema de ninguém, não tem urgência, fica pra depois. E "depois" vira nunca.

O resultado é uma pilha de portas abertas que ninguém mapeou. Todo ex-freelancer, a agência que passou por ali, a integração de terceiro que alguém plugou num sábado à noite: qualquer um desses pode ainda estar alcançando o seu banco de dados. Já escrevi sobre o baseline mínimo de segurança que a maioria das SMBs ignora, e controle de acesso é o item que mais some da lista.

O que a gente encontra quando abre o inventário

No diagnóstico, uma das primeiras coisas que a gente faz é montar um inventário de quem alcança o quê. Não é auditoria de compliance com carimbo, é uma lista suja de tudo que tem chave na mão. Quase sempre volta com os mesmos padrões:

• Segredo no histórico do git: chave de API, senha de banco ou token de serviço que foi commitado uma vez, revertido no commit seguinte, e segue vivo no histórico pra sempre.
• Ex-prestador com acesso ativo: pessoa que saiu, mas continua no org do GitHub, no painel da AWS, no Slack com um bot que ainda lê canal privado.
• Conta root compartilhada: uma credencial de admin que cinco pessoas usam, senha num Google Doc, sem MFA, impossível saber quem fez o quê.
• Segredo hardcoded no código: em vez de variável de ambiente, a chave direto no arquivo, às vezes copiada em três serviços diferentes.
• Dashboard de terceiro esquecido: aquele SaaS que alguém contratou pra um teste em 2023, com acesso de leitura ao banco, e a fatura ainda caindo todo mês.

Montar o inventário de acesso é menos glamouroso do que parece: é abrir gaveta por gaveta e anotar quem ainda tem cópia da chave.

Nenhum desses itens exige um gênio pra explorar. Exige só que uma pessoa errada, um ex-prestador chateado ou um notebook roubado com o repositório clonado, resolva usar o que já tem na mão. E antes que alguém ache que estou dramatizando com aquele "seis segredos válidos": dois eram de ambiente de sandbox, admito, só percebi isso depois de já ter rotacionado tudo. Mas mesmo cortando pra quatro chaves de produção vivas, quatro é quatro a mais do que deveria existir.

Por que o fornecedor barato nunca faz essa faxina

Isso raramente é maldade ou incompetência crua. É o incentivo funcionando exatamente como foi desenhado. Uma agência ou um bodyshop que vende hora e entrega feature é pago pelo que aparece na tela. Rotação de segredo, revogação de acesso, cofre de credencial: nada disso vira demo bonita na reunião de sexta. É trabalho invisível, e trabalho invisível num contrato que paga por entrega visível simplesmente não acontece.

O freelancer disperso é a mesma história em escala menor. Ele configura o que precisa pra rodar hoje, hardcoda a chave porque é mais rápido, e some quando o contrato acaba deixando o rastro pra trás. O rastro não fica por má-fé; fica porque ninguém no arranjo tinha a responsabilidade de olhar o conjunto.

Acesso costuma crescer como fiação de rack: cada um puxa mais um cabo pra resolver o problema do dia, e ninguém volta pra organizar.

Um squad sênior embarcado, que é o que a gente faz na Revin, trabalha diferente por um motivo bem pouco heroico: a gente vai continuar ali no mês que vem. Quem mantém o que escreve trata acesso como problema próprio, não como chateação de outra pessoa. A conta que vaza no ano que vem é a nossa conta. Dá pra ver como isso se parece na prática nos nossos cases.

Como disciplina de acesso se parece na prática 🔑

Não tem mágica. Tem alguns hábitos chatos, aplicados sem exceção. Vou listar em prosa mesmo, porque virar bullet aqui daria a falsa impressão de checklist fechado, e a graça é justamente que eles se sustentam juntos.

Primeiro: segredo mora em cofre, nunca no código. AWS Secrets Manager, Vault, 1Password pra time, tanto faz a ferramenta, contanto que a chave não esteja no repositório. Segundo: todo acesso é nominal e mínimo. Cada pessoa entra com a própria conta, com só a permissão que o trabalho exige, sem root compartilhado. Terceiro: saída de gente dispara uma checklist de revogação no mesmo dia, não na semana seguinte, no mesmo dia. Quarto: o scan de segredo roda no CI, então um commit com chave nem chega no main.

Nada disso pesa no orçamento. O que pesa mesmo é descobrir dois anos depois, no meio de um incidente, que a chave que vazou era a mesma que abria o banco inteiro. Esse é o tipo de coisa que a gente pega logo na primeira leitura do código, durante o Diagnostic Sprint, geralmente nas duas primeiras semanas.

E sim, tem produto que não precisa de quase nada disso. Se o seu "sistema" é uma landing de cinco páginas com um formulário de contato, montar cofre de segredo é overkill: contrata um freela competente e seja feliz. A conversa muda quando existe banco de cliente, pagamento no meio, e gente entrando e saindo do time.

A pergunta que ninguém faz na saída

Quando conto essa história, o que fica pra maioria é o número: vinte e três segredos, seis válidos. Pra mim o que importa é outra coisa. Em quase três anos, ninguém tinha perguntado uma vez sequer "o que essa pessoa ainda alcança depois que ela sai?". Não era desleixo de uma pessoa. Era um buraco no processo que nenhum fornecedor tinha a responsabilidade de tapar.

Então fica a pergunta pra você, founder: da última vez que alguém saiu do seu time ou do seu fornecedor, quem conferiu o que continuou aberto? Se a resposta é "ninguém", tudo bem, é o caso mais comum que a gente vê. Só que é bem mais barato descobrir isso num diagnóstico tranquilo do que num sábado, com um e-mail de alguém avisando que baixou o seu banco de dados.

Se quiser que a gente faça essa varredura antes que ela vire notícia, marque uma conversa e a gente abre o histórico com você.