O vazamento na Railway: como rotacionar os segredos do seu app sem downtime

Em 21 de outubro, a Railway revelou que um terceiro não autorizado havia acessado sistemas que armazenam variáveis de ambiente de clientes e que, em alguns casos, o atacante pode ter obtido o conteúdo descriptografado. A Railway pausou todos os deploys, avisou os provedores envolvidos para revogarem chaves e pediu a todos os usuários que rotacionassem suas variáveis de ambiente, incluindo credenciais de registries privados.

O relatório preliminar traz mais detalhes:

O TechCrunch informa que a Railway acredita que isso fez parte de uma campanha mais ampla contra plataformas, com o objetivo de comprometer provedores de inferência de IA. Na mesma semana, a ferramenta de programação com IA OpenCode revelou que hackers haviam levado API keys e outros segredos de mais de 1% de seus clientes.

Chaves de IA roubadas valem dinheiro de verdade. Os atacantes revendem o acesso ou queimam sua cota com as próprias cargas de trabalho, um padrão que os pesquisadores chamam de LLMjacking. Uma plataforma de hospedagem é um lugar eficiente para coletá-las, porque milhares de apps guardam num só lugar as chaves da OpenAI, da Anthropic, do Stripe e do banco de dados.

Há um detalhe desconfortável no relatório da Railway. As variáveis eram criptografadas, mas a plataforma precisa conseguir descriptografá-las para injetá-las nos seus builds e serviços em execução. Assim que o atacante obteve o acesso interno certo, a criptografia em repouso não o impediu. Isso não é exclusividade da Railway. Qualquer host que roda seu código consegue ler seus segredos.

Então a pergunta não é "meu host é seguro?", e sim "se os segredos do meu host vazassem amanhã, qual seria o tamanho do estrago e em quanto tempo eu me recuperaria?"

Reserve 20 minutos para isso, mesmo que você já tenha clicado em "rotacionar" em algumas coisas.

1. Faça um inventário de todos os segredos. Liste os nomes das variáveis de cada projeto e ambiente, incluindo staging e ambientes de preview. Se você mantém um .env.example, ele é um bom ponto de partida:

Para cada um, anote o que ele libera: um banco de dados, um provedor de pagamentos, um provedor de IA, email, um bucket de armazenamento, um token do GitHub.

2. Verifique o uso e o faturamento do seu provedor de IA. Procure picos de uso, modelos desconhecidos ou requisições em horários estranhos desde 20 de outubro. É onde o abuso tem mais chance de aparecer primeiro.

3. Verifique os logs de auditoria que você tem. A Railway recomenda especificamente revisar os logs de auditoria do GitHub e o acesso dos apps instalados, além dos logs de registries como o Docker Hub. Olhe também os logs de API do seu provedor de pagamentos e os logs de conexão do seu banco de dados.

4. Verifique se o seu banco de dados está acessível pela internet. O relatório da Railway recomenda remover o acesso de rede público aos bancos de dados. Se uma connection string vazada aponta para um banco ao qual qualquer pessoa pode se conectar, o vazamento pode ser explorado na hora:

5. Veja o que o seu frontend já entrega de bandeja. Vazamentos como este lembram que é preciso separar segredos de verdade de valores que são públicos por design. Uma chave que vai no seu bundle de JavaScript nunca foi secreta.

O erro comum sob pressão é revogar primeiro a chave antiga e depois correr para fazer deploy da nova enquanto o app retorna erros. Faça nesta ordem:

Percorra sua lista começando pelo que causaria mais estrago: chaves de pagamento, credenciais de banco de dados, chaves de cloud e armazenamento, chaves de provedores de IA, tokens do GitHub e de registries, e depois todo o resto. As orientações da Railway se concentram nas variáveis definidas antes de 21 de outubro, e as recomendações seguintes incluem reconectar o GitHub e recriar as credenciais da CLI e do CI.

Alguns segredos exigem cuidado extra:

Você não consegue impedir que seu host seja invadido. Mas consegue fazer com que um segredo vazado valha menos.

Restrinja o escopo das chaves. Use chaves restritas quando os provedores oferecerem. Uma chave restrita do Stripe que só consegue criar sessões de checkout é muito menos útil para um atacante do que uma secret key completa.

Limite os gastos. Configure orçamentos mensais e alertas de uso em todos os provedores de IA. Assim, uma surpresa de cinco dígitos vira só um email.

Separe os ambientes. Não reutilize chaves de produção em staging nem em deploys de preview. Cada ambiente deve ter as próprias credenciais, para que um vazamento em um não entregue o outro.

Mantenha os bancos de dados privados. Use a rede privada da sua plataforma e, se você usa Supabase, garanta que o Row Level Security esteja ativado para que uma anon key vazada não exponha suas tabelas.

Nunca guarde segredos em arquivos acessíveis. Um arquivo .env publicado no web root vaza sem precisar de vazamento nenhum na plataforma.

Escreva agora o seu runbook de rotação. A lista do passo 1, a ordem acima e onde cada chave é gerenciada. Na próxima vez, rotacionar leva uma hora em vez de um fim de semana.

Passe por isto em cada app que você publica:

A Railway fez a coisa certa ao divulgar rápido e insistir na rotação. Mas isso continua acontecendo com plataformas de hospedagem e de desenvolvimento, porque é lá que as chaves estão. Quem atravessa isso com calma é quem sabe quais segredos tem e consegue trocá-los em uma tarde.

Já que você está fazendo a limpeza, vale verificar também o que o seu app expõe de fora. O AppSafe escaneia seu site em produção em busca de problemas comuns como API keys em bundles de JavaScript, arquivos .env e .git expostos e cabeçalhos de segurança ausentes, com correções em linguagem simples. Nosso checklist de lançamento para apps feitos com IA cobre o resto do básico.

Depois de rotacionar tudo, rode um scan gratuito do AppSafe para garantir que nada mais está vazando.