Quando um provedor invadido armazenava suas chaves de API: contenção, substituição e conferência de cobranças

Objetivo

Situação em 25 de outubro de 2026. Conter chaves de API potencialmente expostas por um serviço que as armazenava, depois restabelecer o acesso autorizado e conciliar o uso. Confira novamente o aviso mais recente desse serviço e a documentação de revogação, rotação e cobrança de cada emissor. Este protocolo não comprova que uma violação específica ocorreu.

Pré-requisitos

Use um ambiente de administração confiável, com controles de credenciais no emissor, os identificadores dos projetos afetados, os responsáveis pelas aplicações e acesso aos registros de auditoria e cobrança. Registre a revisão do aviso e a janela de exposição, incluindo o fuso horário; se o início for desconhecido, registre-o como desconhecido. Não inclua os valores das credenciais no chamado do incidente.

Passos

1. Mapeie a exposição. Identifique quais chaves estavam em poder do provedor e todos os consumidores legítimos que as compartilhavam. Registre identificadores, permissões e responsáveis. No Google Cloud, o comando documentado para o inventário é gcloud services api-keys list --project=PROJECT_ID; substitua o marcador pelo identificador do seu projeto. Um inventário de chaves identifica possíveis chaves afetadas, mas não comprova roubo. Referência da CLI.

2. Faça a contenção antes de restabelecer o acesso. Suspenda a integração afetada e revogue as chaves expostas no emissor. Remover uma cópia salva não equivale a revogá-la no emissor. O procedimento de incidentes da OWASP prioriza a revogação imediata, seguida de substituição e limpeza. Aceite uma interrupção controlada em vez de continuar usando uma credencial exposta. Impeça que o serviço afetado receba segredos substitutos até que sua recuperação seja comprovada. Resposta da OWASP a incidentes com segredos.

3. Substitua por caminhos confiáveis. Emita chaves substitutas e atualize cada consumidor autorizado. O Google Cloud também documenta a rotação de chaves de API em etapas: criar a substituta, atualizar as aplicações e depois excluir a chave anterior. Se usar essa sobreposição para preservar a disponibilidade, leve explicitamente em conta o período em que a chave exposta continua utilizável. Não trate silenciosamente a criação de uma nova chave como revogação da antiga. Procedimento do emissor.

4. Investigue a conta. Pesquise os registros de auditoria disponíveis desde o primeiro momento plausível de exposição até a contenção. Procure chamadas inesperadas, novas credenciais, novas identidades e alterações de recursos; o Google Cloud direciona essa investigação ao Cloud Logging e ao Security Command Center. Preserve as evidências pertinentes antes de remover o acesso não autorizado. Compare separadamente o uso e a cobrança com as cargas de trabalho esperadas e envie, por meio do suporte autenticado, os identificadores das requisições contestadas, os timestamps e os registros de cobrança. Não presuma que haverá reembolso. Orientações de investigação.

5. Restrinja o acesso futuro. Separe integrações e ambientes, conceda apenas as permissões necessárias e prefira credenciais de curta duração onde houver suporte. O Google Cloud recomenda restrições de API e aplicação para reduzir o uso indevido de chaves. Ajuste as restrições ao consumidor legítimo e verifique se ele continua funcionando. Restrições de chaves, ciclo de vida de segredos.

6. Defina e diferencie os controles de custo. Configure limites de gastos ou cotas aplicados pelo emissor, quando disponíveis, além de alertas enviados a um canal monitorado. Confirme quais configurações realmente interrompem as requisições. O AWS Budgets alerta explicitamente que atrasos na contabilização das cobranças e nas notificações podem permitir gastos acima do limite de alerta. Teste a entrega dos alertas sem gerar cobranças excedentes deliberadamente. Limitações dos orçamentos.

7. Verifique o encerramento. Confirme a invalidação no emissor, o uso autorizado bem-sucedido das substitutas e a continuidade da análise de uso enquanto os dados de cobrança são atualizados. Registre lacunas nos logs ainda não resolvidas e alterações suspeitas na conta. Encaminhe evidências de comprometimento do host para uma investigação de recuperação separada antes de reinstalar credenciais nele.

Resultado esperado

As credenciais expostas estão inválidas, os consumidores legítimos usam substitutas com acesso restrito e a análise de uso, sustentada por evidências, tem um responsável e constatações registradas.

Limites e base de verificação

Esta é uma síntese operacional proposta, e não uma recuperação testada. A falta de logs não comprova ausência de abuso. O Google Cloud alerta que tokens de contas de serviço já emitidos têm prazos de validade próprios: investigue o acesso derivado, em vez de presumir que a substituição da chave de origem o invalida. Não se afirma que haja uma versão de software afetada ou uma versão com correção.