Cloud Intelligence™
Detecção de anomalias de custo na nuvem: lições de incidentes reais
A equipe da DoiT analisou seis meses de incidentes de segurança em toda a nossa base de clientes. A causa raiz raramente era inédita. Quase sempre era uma credencial que alguém esqueceu de proteger.
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
Escrito em coautoria pelas equipes de Customer Success e Forward Deployed Engineering da DoiT
About Kendall Wondergem
Senior Director of Customer and Partner Success at DoiT, leading teams that deliver continuous value and exceptional customer experience through our products and services. Over 20 years of experience in management consulting, SaaS, startups, and the cloud.
My personal pageTL;DR: Nos últimos seis meses, as equipes da DoiT trabalharam em um número crescente de incidentes de segurança em toda a nossa base de clientes e nos principais provedores de nuvem. A grande maioria remonta a uma única coisa: uma credencial vazada ou sem restrições, geralmente uma chave de API ou uma chave de acesso IAM, em algum lugar onde não deveria estar. Alguns incidentes foram detectados imediatamente, graças à Detecção de Anomalias em Tempo Real do DoiT Cloud Intelligence™ e a notificações configuradas corretamente para o stakeholder certo do cliente, no momento certo. Quando isso deu errado, os clientes viram picos de gastos de até centenas de milhares de dólares antes que alguém percebesse. Este post detalha o que vimos, quanto isso custou e as ações que você e sua equipe devem tomar hoje — tanto para prevenir esses ataques quanto para detectar incidentes em minutos, e não em dias.
Se você roda workloads na nuvem pública, já ouviu falar deste pesadelo — ou já viveu na pele: uma chave colada em um repositório público, embutida em um app mobile ou esquecida em um pipeline de CI que ninguém audita há um ano. Dias depois, alguém do financeiro pergunta por que a fatura da nuvem apareceu com um zero a mais. Isso não é hipotético. É, de longe, o incidente de segurança mais comum que atendemos.
Reunimos os dados de incidentes registrados pelos nossos Forward Deployed Engineers nos últimos seis meses para entender quais padrões se repetiam em uma base de clientes grande e variada. Este não é um relatório de fornecedor alertando sobre ataques teóricos. É o que está chegando à nossa fila — e queremos ajudar você a evitar a mesma situação no seu negócio.
Padrões de incidentes de segurança na nuvem: GCP vs. AWS
Os incidentes no Google Cloud remontam quase todos a uma única origem: a explosão do uso da API do Gemini e do Vertex AI no último ano, e a facilidade com que uma chave de API fica sem restrições quando se constrói com pressa. Publicamos sobre a correção para o abuso de chaves de API do Gemini no blog aqui. Os incidentes na AWS seguiram um padrão mais tradicional: chaves IAM vazadas virando abuso de computação, além de alguns casos diretos de tomada de controle de conta. Nas duas plataformas, a causa raiz quase nunca foi uma vulnerabilidade da plataforma. Foi quase sempre algo que um ser humano fez — ou deixou de fazer — com uma credencial.
Incidentes de segurança no GCP: chaves de API vazadas são a causa nº 1
| Causa raiz | Percentual |
|---|---|
| Chaves de API vazadas ou sem restrições (Gemini, Vertex, AI Studio) | 77% |
| Chave de service account vazada usada para mineração de criptomoedas ou frotas não autorizadas de Compute Engine | 19% |
| Sequestro de sessão ou de admin levando a manipulação de faturamento ou bloqueio de administradores | 2% |
| Exfiltração de dados via service account comprometida | 2% |
A primeira linha responde por quase tudo. 77% dos incidentes no GCP que vimos nos últimos seis meses se resumiram a uma chave de API — geralmente uma chave de navegador do Firebase ou uma chave do Maps/Gemini embutida em código client-side — sem restrição de referrer HTTP, sem restrição de IP e sem escopo de API. Atacantes varrem repositórios públicos e bundles de frontend expostos procurando exatamente esse padrão e, ao encontrar uma chave funcional, apontam scripts automatizados para a Generative Language API e deixam rodar. Vimos esses incidentes variarem de algumas centenas de dólares a mais de US$ 200.000 em cobranças não autorizadas do Gemini, geradas em questão de horas.
O segundo grupo, chaves de service account vazadas, se desenrola de forma diferente, mas começa do mesmo jeito: uma chave de longa duração parada em um repositório do GitHub, em uma configuração de CI/CD ou no laptop de um desenvolvedor. Com ela em mãos, o atacante não infla contas de API — ele sobe computação. Em um caso que atendemos, uma chave de service account de CI do GitLab vazada permitiu que um atacante lançasse mais de 10.500 VMs de mineração de criptomoedas em um único projeto GCP durante a madrugada. E as solicitações de reembolso ao provedor de nuvem nem sempre são aprovadas. Vale parar para refletir sobre isso: os provedores de nuvem estão cada vez mais rigorosos com créditos por "gastos descontrolados", especialmente em incidentes recorrentes ou evitáveis. Contenção e prevenção importam mais do que antes, porque a rede de segurança de uma contestação de fatura não é garantida.
Incidentes de segurança na AWS: chaves IAM vazadas e tomada de controle de conta
| Causa raiz | Percentual |
|---|---|
| Chave de acesso IAM vazada ou sem restrições (máquinas de dev, CI/CD, código) levando a uso não autorizado de EC2, ECS, Fargate ou Bedrock | 56% |
| Tomada de controle da conta root ou de sessão de admin levando a manipulação de faturamento ou bloqueio de administradores | 15% |
| Workload ou aplicação comprometida (serviço exposto, trust policy mal configurada) levando a movimentação lateral ou exfiltração de segredos | 15% |
| Abuso de plataforma via contas de clientes comprometidas, phishing ou spam enviados pelo Amazon SES | 7% |
| DDoS ou ataque na camada de rede sem comprometimento de credenciais | 7% |
A história na AWS se parece com o que vemos no GCP: credenciais vazadas respondem por mais da metade de tudo. Chaves de acesso IAM vazadas de máquinas de desenvolvedores ou pipelines de CI viram frotas não autorizadas de EC2 ou Fargate rodando mineradores de criptomoedas — ou, cada vez mais, chamadas não autorizadas à API do Bedrock acumulando cobranças de inferência de modelos.
Os casos de tomada de controle da conta root são os que deveriam preocupar mais os líderes de segurança, porque são os mais difíceis de reverter. Em um incidente, um atacante redefiniu a senha da conta root da AWS de um cliente, cadastrou o próprio dispositivo de MFA e bloqueou completamente os administradores legítimos. A partir daí, executou chamadas de API do Bedrock em larga escala que geraram mais de US$ 500.000 em cobranças antes de a conta ser recuperada. A recuperação exigiu trabalhar diretamente com a AWS para reverificar a titularidade e reconstruir o acesso do zero. Nenhuma detecção de anomalias consegue alertar rápido o suficiente se as pessoas que normalmente responderiam não conseguem entrar na conta.
Também vimos um grupo menor, mas real, de comprometimentos no nível de workload: um load balancer voltado à internet expondo um pod, uma trust policy OIDC mal configurada e um atacante se movendo lateralmente para exfiltrar milhares de segredos do Secrets Manager. Esses casos têm menos a ver com uma única chave vazada e mais com a dívida acumulada de uma configuração permissiva de rede e IAM.
Comprometimento de identidade: phishing, abuso de OAuth e tomada de controle de conta
Os incidentes restantes seguiram um padrão diferente, mas relacionado: campanhas de phishing que coletaram credenciais e depois foram usadas para sequestrar contas e enviar spam por meio de uma identidade de remetente comprometida, ou para pivotar em ferramentas de terceiros conectadas via OAuth. A conta de Workspace comprometida de um cliente foi usada para adicionar vínculos de gerenciador não autorizados à conta de Google Ads e acumular quase US$ 50.000 em gastos fraudulentos com anúncios. Em outro caso, o login de um funcionário foi usado para conceder acesso OAuth a ferramentas de terceiros, resultando em compras não autorizadas.
O fio condutor em todas as plataformas: o ponto fraco não era a infraestrutura do provedor de nuvem. Era a identidade.
A fatura é a fumaça, não o incêndio
É tentador tratar o pico de custo como o problema. Porém, o pico de custo costuma ser o primeiro sintoma visível de um comprometimento de credencial. Corrija a fatura e você tratou o sintoma. Corrija a higiene de credenciais e leve a detecção de anomalias a sério, e você trata a causa raiz.
Por isso, nossa recomendação tem duas metades que precisam funcionar juntas: uma revisão de postura de segurança que fecha as brechas antes que sejam exploradas, e monitoramento que detecta a exploração rapidamente se, ainda assim, alguma brecha escapar.
Como prevenir incidentes de segurança na nuvem: fechando as brechas
A recomendação em duas partes da DoiT inclui o seguinte:
Passo 1: revise sua postura de segurança na nuvem
A maioria dos incidentes acima era evitável com práticas que aparecem em qualquer revisão padrão de postura de segurança na nuvem: restringir chaves de API a referrers ou faixas de IP específicos, rotacionar e aposentar chaves de service account de longa duração, migrar de credenciais estáticas para workload identity federation ou tokens de curta duração sempre que possível, exigir MFA e limites de duração de sessão no provedor de identidade, e restringir quem pode criar ou usar vinculações IAM de nível owner. Nada disso é exótico. É o trabalho maçante e nada glamouroso de higiene de acesso — e é exatamente o trabalho que aparece como ausente em incidente após incidente.
Passo 2: configure detecção de anomalias de custo na nuvem e notificações
A Detecção de Anomalias em Tempo Real do DoiT Cloud Intelligence™ (disponível nos planos Enhanced e Enterprise) foi criada exatamente para a lacuna que aparece em quase todos os incidentes deste conjunto de dados: o intervalo entre algo dar errado e alguém descobrir. A maioria das ferramentas baseadas em faturamento detecta um pico de gastos horas ou dias depois de ele acontecer, porque lê exports que atualizam com atraso. A Detecção de Anomalias em Tempo Real lê dados de uso em runtime diretamente, combinados com padrões históricos de gastos, e pode sinalizar atividade incomum em minutos, não em dias. Cada alerta vem com pontuação de severidade e um detalhamento gerado por IA do serviço, SKU e recurso afetados, para que sua equipe não comece a investigação do zero.
Para clientes do plano Essentials, nossa Detecção de Anomalias de nuvem padrão pode e deve ser configurada, com notificações apropriadas para identificar e sinalizar anomalias. Para fazer upgrade para a Detecção de Anomalias em Tempo Real, fale com seu Account Manager da DoiT ou abra um ticket via Expert Inquiry no console da DoiT.
Para extrair o máximo da sua detecção de anomalias:
- Confirme que as notificações de detecção de anomalias estão configuradas para as pessoas certas, pelos canais certos, no momento certo. As notificações de anomalias de custo exigem a permissão de Cloud Analytics e, por padrão, vão para Admins, Power Users, Finance Users e Standard Users — mas vale verificar quem na sua equipe realmente tem isso configurado e se essas pessoas entendem a importância de responder rapidamente às notificações.
- Não pare no limite de severidade padrão. Se a sua organização roda workloads de alta velocidade (CI/CD, inferência de GenAI, frotas com autoscaling), ajuste sua cadência de revisão para que uma anomalia de severidade média às 2h da manhã ainda seja analisada antes do início do dia.
- Conte com seu Customer Success Manager da DoiT para ajudar a configurar (ou validar) sua detecção e notificações. Os CSMs da DoiT têm prazer em ajudar e podem ser os olhos especializados necessários para garantir que tudo esteja configurado corretamente.
- Configure notificações para picos de gastos e uso de novos SKUs. A detecção e notificação de anomalias de novo SKU é subutilizada, mas essencial: ela avisa no momento em que sua organização começa a usar um serviço ou SKU que nunca usou antes — exatamente o que acontece quando um atacante com uma chave roubada começa a chamar a Generative Language API ou a rodar inferência no Bedrock pela primeira vez. Um novo SKU legítimo aparece ocasionalmente quando sua equipe lança algo novo. Um SKU inexplicável surgindo em um horário inesperado merece atenção imediata.
- Considere configurar notificações de esgotamento de cota ou uso de créditos. Embora criadas para outro tipo de falha, elas completam o quadro de comportamentos inesperados nos seus gastos.
- Avalie usar automações. Configure o DoiT Cloud Intelligence™ CloudFlow para rodar com gatilhos de anomalia de custo. Você pode automatizar tarefas de mitigação de incidentes como publicar no Slack, criar tickets ou executar etapas de remediação. Não sabe por onde começar? Seu Customer Success Manager da DoiT pode coordenar uma sessão de trabalho com um Forward Deployed Engineer da DoiT para criar seus CloudFlows.
Para mais informações sobre a configuração de detecção de anomalias e notificações, consulte a documentação de ajuda da DoiT sobre detecção de anomalias e notificações, ou fale com seu Customer Success Manager da DoiT.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Conte com ajuda especializada em detecção de anomalias de custo na nuvem
Para clientes dos planos Enhanced e Enterprise: fale com seu Customer Success Manager ou Account Manager da DoiT para agendar uma revisão de postura de segurança e/ou configurar uma estratégia robusta de detecção e resposta a anomalias. Não sabe quem é seu CSM/AM? Acesse o DoiT Cloud Intelligence™, clique no ícone de engrenagem no canto superior direito e selecione "Account Managers".
Para clientes do plano Essentials: abra um ticket pelo console (vá ao menu e selecione "Get expert advice"), e um Customer Success Manager poderá ajudar a configurar ou revisar sua configuração de anomalias e notificações, além de compartilhar mais detalhes sobre uma revisão de postura de segurança autoguiada ou conduzida pela DoiT.
Checklist de resposta a incidentes de segurança na nuvem
Se algo acontecer no seu ambiente, esta é a ordem de ações que recomendamos, com base na nossa experiência com incidentes contidos rapidamente:
- Corte a credencial primeiro. Exclua ou rotacione imediatamente a chave de API ou chave de acesso IAM comprometida. Não espere entender todo o raio de impacto antes de fazer isso. Cada hora em que ela permanece ativa significa mais gastos e mais exposição.
- Estanque o sangramento no nível do recurso. Encerre VMs, instâncias ou frotas de computação criadas pelo atacante. Se os gastos estiverem subindo mais rápido do que você consegue excluir recursos com segurança, desvincular a conta de faturamento do projeto afetado é um freio de emergência legítimo.
- Preserve os logs antes de limpar tudo. Logs de auditoria e VPC Flow Logs são o que seu provedor de nuvem e sua própria equipe vão precisar depois, tanto para a análise de causa raiz quanto para qualquer contestação de fatura. Rotacionar todas as credenciais e destruir todos os recursos antes de alguém extrair os logs torna a investigação muito mais difícil.
- Abra um caso com seu provedor de nuvem. Para gastos não autorizados, a maioria dos provedores tem um processo de contestação de cobranças vinculadas a um comprometimento confirmado. Seja realista quanto às chances: os provedores ficaram mais rigorosos com esses créditos, especialmente em incidentes recorrentes ou evitáveis, então não trate a solicitação de crédito como garantida.
- Envolva a DoiT. Abra um ticket pelo console (vá ao menu e selecione "Get expert advice") ou envie um e-mail ao seu Customer Success Manager. Quanto mais cedo formos envolvidos, mais podemos ajudar com orientação de contenção, escalonamento junto ao provedor e garantia de que a mesma brecha não se reabra.
- Feche a brecha depois de conter o incidente. Um incidente é um catalisador. Use-o para agendar aquela revisão de postura que você vinha adiando.
FAQ
O que é detecção de anomalias de custo na nuvem?
Detecção de anomalias de custo na nuvem é o monitoramento que sinaliza padrões incomuns de gastos ou uso — um novo SKU, um pico inesperado, um serviço desconhecido — no momento em que acontecem, em vez de esperar que a fatura mensal os revele. A Detecção de Anomalias em Tempo Real do DoiT Cloud Intelligence™ lê dados de uso em runtime diretamente, podendo sinalizar atividade em minutos, em vez das horas ou dias que as ferramentas baseadas em exports de faturamento levam.
O que acontece se uma chave de API vazar?
Quando uma chave de API sem restrições de referrer HTTP, IP ou escopo é exposta — em um repositório público, um app mobile ou uma configuração de CI —, atacantes normalmente a encontram em poucas horas por meio de varredura automatizada e imediatamente apontam scripts para APIs faturáveis como a Generative Language API ou o Bedrock. Nos incidentes que rastreamos, isso variou de algumas centenas de dólares a mais de US$ 200.000 em cobranças não autorizadas geradas em questão de horas.
Como acontece a tomada de controle de uma conta na nuvem?
A maioria das tomadas de controle que vemos começa com uma credencial obtida por phishing ou reutilizada, não com uma vulnerabilidade da plataforma. Um atacante redefine uma senha, cadastra o próprio dispositivo de MFA e bloqueia o admin legítimo — depois usa esse acesso para acumular cobranças de computação ou inferência de modelos, ou para manipular o faturamento. É o tipo de incidente mais difícil de reverter, porque as pessoas que normalmente responderiam não conseguem entrar na conta.
A AWS ou o Google Cloud reembolsam cobranças não autorizadas de uma credencial vazada?
Não automaticamente, e nem sempre. Os dois provedores têm um processo de contestação para cobranças vinculadas a um comprometimento confirmado, mas ficaram mais rigorosos na aprovação de créditos, especialmente para incidentes recorrentes ou evitáveis. Trate o reembolso como possível, não garantido — prevenção e contenção rápida importam mais do que a rede de segurança de uma contestação de fatura.
Qual é a primeira coisa a fazer ao suspeitar de uma credencial vazada?
Rotacione ou exclua a chave comprometida imediatamente, antes mesmo de mapear todo o raio de impacto — cada hora em que ela permanece ativa significa mais exposição. Depois, estanque o sangramento no nível do recurso (encerre a computação não autorizada ou desvincule o faturamento como freio de emergência) e preserve os logs de auditoria antes de limpar qualquer coisa, pois você vai precisar deles para a análise de causa raiz e qualquer contestação de fatura.
Com que rapidez a detecção de anomalias de custo na nuvem consegue detectar uma chave comprometida?
Com detecção em tempo real ajustada para alertar sobre uso de novos SKUs e picos de gastos com pontuação de severidade, as equipes conseguem detectar uma chave comprometida em minutos após o primeiro uso. A detecção de anomalias padrão que depende de exports de faturamento costuma ter um atraso de horas a dias — exatamente a janela que transformou incidentes menores dos nossos dados em incidentes de seis dígitos.
