Proponha uma correção, faça uma sugestão
Programador deixou alerta de 6€ na Google Cloud. Acordou com uma dívida de 15 mil
A gestão de custos em serviços na nuvem pode ser extremamente traiçoeira, especialmente quando a segurança falha. Este programador confiou cegamente nos alertas de orçamento da Google Cloud... E acordou com uma dívida de 15.000 euros.
O choque de acordar com uma conta inesperada
Este foi o cenário relatado por venturaxi, um utilizador da plataforma Reddit. Segundo o seu testemunho, o programador foi dormir descansado com um alerta de orçamento configurado para 10 dólares australianos (cerca de 6 euros). Ao acordar, deparou-se com uma fatura de 25.672,86 dólares australianos na Google Cloud, o que equivale a mais de 15.000 euros.
O utilizador afirma que, durante o período noturno, foram realizadas cerca de 60.000 pedidos não autorizados através de uma chave de API que, inicialmente, ele não conseguia identificar no seu painel de controlo.
O cerne da questão reside num detalhe que a Google esclarece na sua própria documentação: um alerta de orçamento não interrompe o consumo de recursos, apenas envia notificações por correio eletrónico quando certos limites são atingidos.
Por outras palavras, o sistema avisa que o gasto está a aumentar, mas não funciona como um interruptor automático que corta o serviço. Num contexto de utilização normal, isto pode ser suficiente. Contudo, perante um ataque automatizado com chaves comprometidas, os custos acumulam-se a uma velocidade superior à capacidade de reação do utilizador.
Went to bed with a $10 budget alert. Woke up to $25,672.86 in debt to Google Cloud. by u/venturaxi in googlecloud
O perigo das chaves de API esquecidas e expostas
Para compreender a gravidade da situação, é necessário olhar para o funcionamento das chaves de API. Estas funcionam como uma chave mestra que permite a uma aplicação identificar-se perante um serviço. Se esta chave for exposta, qualquer pessoa pode utilizá-la para gerar pedidos que serão debitados na conta do proprietário original.
No caso de venturaxi, a chave pertencia a uma aplicação antiga de jardinagem desenvolvida para a sua mãe através do Cloud Run. A localização desta credencial foi particularmente difícil, pois não aparecia na lista habitual do AI Studio, tendo sido encontrada apenas com a ajuda de outros utilizadores noutra secção do painel da Google Cloud.
O relato torna-se ainda mais crítico ao abordar a assistência recebida. O programador afirma ter passado dias a lidar com agentes automáticos e diversos membros do suporte sem que houvesse uma figura central a acompanhar o processo.
Outro ponto polémico tem que ver com o nível da conta de faturação: o utilizador alega que o seu limite de crédito foi elevado automaticamente pela Google devido à sua antiguidade e bom historial de pagamentos. Esta confiança depositada na conta permitiu que o sistema processasse um volume de gastos muito superior ao esperado, sem que fosse solicitada uma autorização específica.
Embora casos como este gerem grande apreensão na comunidade de programadores, o desfecho para venturaxi acabou por ser positivo. A Google anulou a fatura exorbitante e devolveu os valores que já tinham sido alvo de tentativas de cobrança. No entanto, o utilizador ressalva que ainda não obteve respostas claras sobre como a chave foi exposta ou a origem exata do tráfego malicioso.
Leia também:
Loading ...
Noob, quem tem de proteger as chaves é ele, quem tem de implementar guardrails é ele, mexem sem saber e culpam os outros
Zé, não sejas assim.
Todos erramos. Só não erra, quem nada faz.
O que aconteceu com ele, pode acontecer com qualquer um. Principalmente, em serviços Cloud.
Fala-se tanto em segurança, mas não me parece que uma única etapa de autenticação de API’s, seja de todo seguro. Através de reverse engineering, pode-se conseguir a chave.
É tão básico quanto definir usage caps ou hard limits, até podes ter playbooks para desligarem o billing project, fácil, so alguém muito noob para comentar tais falhas.
Não tem nada de mal as APIs e suas private keys, tem mal ma engenharia que não sabem definir ao que as duas APIs devem ter acesso, não sabem definir APIs diferentes para front ends e para back ends sendo que o front end é que invoca a API de back end, além disso não sabem definir rotação de private keys e secrets e sua monitorização.
É tudo seguro para quem sabe o que está a fazer
Grande Zé que nunca falhou na vida. Tiravas sempre 20 quando estudavas?
Fica-te mal esse comentário, sabias? Também és daqueles que diz que, em certas situações, a culpa é da mulher por causa da roupa que veste? Se uma casa ou um carro tiver uma porta ou janela aberta, também és dos que dizem “bem feito” aos donos? Nesse caso deixa de ser crime e passas a culpar as pessoas, ilibando quem faz mal. No fim do dia, a porta estava aberta, logo foi um pedido explícito para entrar e roubar?
É dever do developer salvaguardar as chaves, isso é um facto. Mas a Google, Azure, AWS e todos os serviços on demand deviam implementar mais medidas para prevenir estas situações. Num mundo onde temos IA, não faz sentido não existir uma ferramenta que analise o histórico de pedidos e e detete comportamentos anómalos, seja pelo volume de pedidos, seja pelos IPs. Ainda por cima havia um alerta, e sim, era só um alerta, mas de 10 para 15k vai uma diferença enorme, claramente uma red flag.
O programador tem culpa, sem dúvida. Mas podia ser feito muito mais ao nível do serviço para prevenir estas situações. Eles podem fazê-lo, mas também ganham com isto, por isso é mais fácil passar o ónus para o developer do que investir em prevenção. Se ele falhar, alguém lucra com isso.
Mas agora a sério, põe a mão na consciência e pensa no que disseste. Deixa essa postura mesquinha. Não sei o que fazes da vida e nem interessa, mas de certeza que há áreas que não dominas e onde achas que estás a fazer tudo bem, quando na realidade podes estar a cometer erros graves aos olhos de quem sabe mais. E de certeza que ninguém te trata assim quando tens um problema.
Empatia precisa-se. Já chegam os conflitos artificiais que criamos no dia a dia.
Olha este agora também trabalha para a cp
Para cenas de cloud uso sempre cartões virtuais com plafond limitado ao que estou disposto a pagar mensalmente. Assim não há abusos externos ou esquecimentos
isso não impede de de gerar dívida