
Egyre gyűlnek azok a felhasználók, akik fórumokon arra panaszkodnak, hogy kis összegű Google Cloud-előfizetésük egyik pillanatról a másikra több tízezer dollárra ugrott. Egy felhasználó például 25 ezres számlára ébredt. Olyan is van a károsultak között, aki költségkorlátot állított be, azaz bizonyos összeghatár fölött a szolgáltatónak (elvileg) le kellett volna tiltania minden további API-hívást. A károsultak jellemzően a Google Mapset használták.
A probléma valószínűsíthető oka, hogy kiberbűnözők kompromittálták a felhasználó API-kulcsát, és drága MI-modellek futtatására használták.
A The Register megkereste a Google-t. A cég válasza szerint ez iparágszintű probléma, és nem Google-specifikus biztonsági rés. Az incidensek túlnyomó többségét a nyilvános repositorykon, például a GitHub-on keresztül véletlenül kiszivárgott, sérült felhasználói hitelesítő adatok okozzák. Ezért a Google minden ügyfelét robusztus biztonsági gyakorlatok, például a többtényezős hitelesítés bevezetésére és az API-kulcsok rendszeres ellenőrzésére ösztönöz, valamint azt javasolja, hogy a felhasználók soha ne tároljanak hitelesítő adatokat nyilvános repositorykban.
Tízezer lett. Maradhat?
A szolgáltató magyarázata azonban sovány vigasz a károsultaknak, akik azért küzdenek, hogy a Google térítse vissza a szerintük jogtalanul levont összegeket. Egy cég, amely a Google Mapset használta API-n keresztül kb. havi 50 dollárt értékben, egyszer 10 ezer dollárt meghaladó számlát kapott annak ellenére, hogy be volt állítva költési korlát. Mint kiderült, cég által használt nyilvános API-n keresztül a Google videó- és képgeneráló MI-modelljein futtattak műveleteket.
Mivel a Google nem talált csalásra utaló bizonyítékot, egyelőre elzárkózik a visszatérítéstől. A probléma csak az, hogy a cég vezetője szerint a Google tanácsát követve tették nyilvánossá az API-kulcsot. Ez fejlesztők és a biztonsági kutatók szerint is így van, és emiatt több ezer olyan Google Cloud-fiók lehet, amely a Google saját webhelykonfigurációs szabályait követve API-jait nyilvános kliensbe helyezte.
A károsult cég szerint a sokak által használt a Maps API-kulcsát a Google az ügyfelei értesítése nélkül módosította úgy, hogy az használható legyen a Geminihez is. Legtöbb esetben a számlakorlátozás sem segít: ha egy Google Cloud-fiók legalább egy hónapja működik, és élettartama alatt az összes költése elérte az 1000 dollárt, számlakorlátja automatikusan 100 ezer dollárra emelhető – felhasználói beavatkozás nélkül.
Biztonsági kutatók jelezték: baj lesz
Pár hónapja jelent meg egy elemzés a Truffle Security oldalán, amelyben a cég kutatói figyelmeztetnek: bár a Google több mint egy évtizede mondja, hogy a Google API-kulcsok nem titkok, ez már nem igaz, mert ugyanezeket a kulcsokat a Geminihez is lehet használni a privát adatok eléréséhez. Több millió weboldalt átvizsgáltak, és közel háromezer problémás kulcsot találtak.
A Google a The Registernek küldött válaszaiban az alábbiakat javasolja a felhasználóknak: (1) ne használják ugyanazt az API-kulcsot több API-hoz, különösen az olyan API-kulcsok esetében, amelyek kliensoldaliak lehetnek (böngészőkulcsok); (2) mindig alkalmazzanak API-klienskorlátozásokat – például korlátozzák a kulcsot egy adott szolgáltatásra; és (3) alkalmazzanak kliensalkalmazás-korlátozásokat. Mostantól kötelező is lesz az API-korlátozások konfigurálása az API-kulcsok létrehozásakor, és nem lehet létrehozni olyan kulcsot, amely a Geminihez és a Mapshez is hozzáfér.
Költségcsökkenésből finanszírozott modernizáció
A cloud-native alkalmazások megkövetelik az adatközpontok modernizációját, amihez a SUSE többek között a virtualizációs költségek csökkentésével szabadítana fel jelentős forrásokat.
CIO kutatás
Merre tart a vállalati IT és annak irányítója?
Hiánypótló nagykép a hazai nagyvállalati informatikáról és az IT-vezetőkről: skillek, felelősségek, feladatkörök a múltban, a jelenben és a jövőben.
Töltse ki Ön is, hogy tisztábban lássa, hogyan építse vállalata IT-ját és saját karrierjét!
Az eredményeket május 8-án ismertetjük a 17. CIO Hungary konferencián.
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?