2026 tavaszán két cég is ugyanannak a támadási típusnak esett áldozatul: ellopott hitelesítő adatok, idegen API-kulcsok és egy hatalmas Gemini-fogyasztást tartalmazó számla. Az első incidens félmillió eurós számlával zárult. A második, két hónappal később, egy már a monitoringunk alatt álló környezetet ért, és néhány órán belül megállítottuk. Ez az írás arról szól, mit építettünk e két dátum között, és miért nem az anomáliák felismerése volt a legnehezebb, hanem annak eldöntése, mikor kell valóban riasztani.
Félmillió euró három nap alatt
2026 májusa. Egy nagy technológiai cégcsoport, amely többek között e-kereskedelmi és streaming platformokat üzemeltet, szinte csak jelképes mértékben használja a Google Cloudot. A fő infrastruktúrájuk máshol működik; a GCP csupán periférikus rendszereknek ad otthont, amelyek havonta nagyjából 500 dolláros költséget jelentenek.
A hónap közepén a cég társszervezője egy óriási, széles körben beharangozott tech-eseménynek. A teljes mérnöki csapat a helyszínen van, és nyakig ülnek a munkában.Pontosan ezekben a napokban csap le valaki egy régi szolgáltatási fiók kiszivárgott kulcsára: az egyik projektben Editor szintre emeli a jogosultságait, bekapcsolja a Vertex AI-t, és elindítja a modellfuttatásokat a Gemini 1.5 Pro-n. Nem teszt jellegről van szó, hanem ipari léptékű használatról.
A május 14. és 16. közötti GCP-használat számlája eléri az 500 960 eurót. A cég havi költségvetésének ezerszerese pörgött el mindössze három nap alatt.
A dolog legfájdalmasabb pontja, hogy a riasztások papíron működtek. A Google már május 14-én értesítést küldött a gyanús használatról és az átlag feletti költésről. Csakhogy az első költségkeret-riasztás – az 500 dolláros átlaghoz képest – abszolút értékben még ártalmatlannak tűnő összegről szólt. Azok az emberek pedig, akiknek el kellett volna olvasniuk, éppen a színpadon álltak.
A reakció május 17-én indult el teljes gőzzel, és tankönyvbe illő volt: a fiókokat leállították, a kártékony IAM-beállításokat törölték, a projektet írásvédett módba üzemmódba zárolták az incidenselemzéshez, a teljes szervezetben pedig új biztonsági szabályzatokat léptettek életbe. A vizsgálat megerősítette, hogy adat nem szivárgott ki, és a kár egyetlen projektre korlátozódott. Ám a számláló így is félmillió eurónál állt meg.
Egy átlagos nap ezen a fiókon tizen-egynéhány euró, így ezen a skálán ezek az oszlopok egyszerűen láthatatlanok. Ez nem egy valódi konzol képernyőképe.
A diagram adatai (táblázat)
| Nap | tipikus | május 14. | május 15. | május 16. |
|---|---|---|---|---|
| Költség | ≈ €16 | ≈ €292 000 | ≈ €168 000 | ≈ €41 000 |
Az eset megfigyelése alapján három kulcsproblémát azonosítottunk, amelyek egyenesen a backlogunkba kerültek:
- A statikus költségkeret-riasztások vakok az alacsony költésű környezetekben, mert a százalékosan gigantikus növekedés kezdetben elhanyagolható összegnek tűnik.
- A visszaélésekről szóló értesítések kizárólag a környezet tulajdonosához jutnak el. Az alapbeállítások mellett a számlázási partner ebből semmit sem lát, amíg az ügyfél maga nem jelentkezik.
- Ebben az esetben nem létezett semmilyen automatikus biztosíték, amely megakadályozta volna ezt a fogyasztást.
Elhatároztuk, hogy ügyfeleinknél az ilyen incidenseket elsőként mi vesszük észre, nem a számla. Így született a Cloud Cost Sentinel.
A költség biztonsági jelzés
A szakma már el is nevezte a jelenséget: ez az LLMjacking. Az ellopott felhő-hitelesítő adatok nem adatlopásra szolgálnak, hanem a drága nyelvi modell-API-k tömeges, gyakran továbbértékesített fogyasztására. A számla az áldozatnál marad. A nyilvánosan dokumentált esetek a pár tucat dollártól a több tízezer dolláros kárig terjednek egyéni fejlesztők és kisebb csapatok esetében. Az itt leírt vállalatok nem egyedi áldozatok voltak, csak a következő célpontok egy profin kiépített gépezetben.
Ezért kezeljük az FOTC-nél a folyamatosan érkező használati és költségadatokat ugyanúgy, ahogyan a SecOps a logokat: folyamatos elemzés alatt álló adatfolyamként. A hirtelen költségnövekedésnek szinte mindig technikai oka van, és ezen okok jelentős része konkrét biztonsági incidens:
Architektúra: a számlázási exporttól a PagerDutyig
Több száz Google Cloud számlázási fiókot kezelünk. Mindegyikről teljes számlázási adatexport készül egy particionált BigQuery-táblába. Egyébként ez az egyetlen dolog, amit a rendszer megkövetel egy adott környezettől. Ezen az alapon működik a detektor: egy kis erőforrás-igényű Cloud Run alkalmazás, amit egy automatikus időzítő kapcsol be sűrű időközönként.
Adatok
Detektálás
Döntés
Reakció
Minden komponens állapotmentes. A rendszer egyetlen állapota a BigQuerybe visszaírt detektálási előzmény. Ez hajtja a dashboardot és az újraértesítési döntéseket. A riasztások hozzánk is befutnak, nem csak az ügyfélhez.
Négy kérdés, amelyet minden elemzési ciklusban felteszünk az adatoknak
Minden anomáliatípus más kérdés, más referenciaablakkal. A közös nevező itt az, hogy minden fiókot kizárólag a saját előzményeivel vetünk össze. A konkrét határértékek, az időablakok hossza és a minimális összeghatárok környezetenként egyedileg állítható paraméterek – ezért sem részletezzük őket itt számszerűen.
| Detektor | Kérdés | Referenciapont |
|---|---|---|
| Napi (z-score) | Eltér-e a tegnapi vagy a mai költség a normától? | Az elmúlt napok gördülő időablaka, az aktuális nap figyelmen kívül hagyásával; riasztás a statisztikailag jelentős eltérésről egy minimális összeghatár felett. |
| Óránkénti kiugrás | Drasztikusan drágább-e ez az óra a szokásosnál? | A fiók óránkénti profilja az utóbbi napokból; riasztás az adott óra tipikus költségének többszörösénél |
| Új fiók | Sokat költ-e azonnal egy frissen létrehozott fiók? | Előzmény nélküli fiók, amely azonnal magas költést generál; a visszaélés egyik legerősebb jele |
| Havi előrejelzés | Merre tart ez a hónap? | Hónap eleji extrapoláció az előző hónapok tükrében; riasztás, ha az előrejelzés láthatóan elszalad |
A napi detektor szíve egyetlen ablakos BigQuery-lekérdezés, és a megvalósításnak épp ez a része a legegyszerűbb. Az igazi összetettség a részletekben rejlik: az aktuális nap szándékosan kimarad a baseline-ból (Hogy miért? Mindjárt kiderül…), az ablakokat és küszöböket valós adatokhoz kell hangolni, magukban az adatokban pedig sosem szabad vakon megbízni, sem a teljességükben, sem a szerkezetükben. Elsőre talán szőrszálhasogatásnak tűnik, de korábban mindegyikbe belefutottunk már.
Július: ugyanaz a támadástípus, más befejezés
Két hónappal a májusi incidens után ugyanez a támadási forgatókönyv csapott le az egyik ügyfelünkre, egy kis mobilalkalmazás-stúdióra. Ez a környezet ekkor már a Cloud Cost Sentinel felügyelete alatt állt. A történet szinte közhelyesen indult: az egyik fejlesztő le akart tölteni egy népszerű eszközt, és rákattintott egy szponzorált keresési találatra. A weboldal hitelesnek tűnt, ahogyan maga a telepítőprogram is. A háttérben viszont egy olyan adatlopó (stealer) kártevő rejtőzött, amelyet többek között a Bitdefender és a Trend Micro nyilvánosan dokumentált. Hiába volt a fiókon MFA, semmit sem ért, mert ez a malware-típus egy már bejelentkezett gép belsejéből dolgozik. Olyan munkamenetet térít el, ahol az azonosítás már korábban sikeresen megtörtént.
Július 4-én este az ellopott hitelesítő adatokkal egy szkript jelentkezett be egy németországi hosting-szerverről. A több éves Firebase-együttműködés után a fióknak tucatnyi projektben volt Editor szerepköre, ami a Google Cloudban többek között API-k engedélyezésének és kulcsok létrehozásának jogát jelenti. Az automatizmusnak 3 perc 16 másodpercre volt szüksége, hogy végigmenjen a projekteken, és 16 engedélyezett API-t, 9 szolgáltatásfiókot és 28 kulcsot hagyjon maga után. Aztán tizenkét napra csend lett. A kulcsok ott lapultak és kivártak.
Július 16-án 13:45-kor a kulcsok életre keltek, és az összes projektben egyszerre indult be a tömeges Gemini-fogyasztás. Hajnali 4:30-kor, amint a nap első adatai beértek a számlázási exportba, a rendszer azonnal riasztott. A CRITICAL kártya így nézett ki: jóval ötszáz feletti z-score, tízezrelékek helyett tízezer százalékokban mért növekedés, a szolgáltatásonkénti bontásban pedig gyakorlatilag a teljes növekmény egyetlen tételből származott: a Gemini API-ból, egy ezen a fiókon korábban egyáltalán nem használt szolgáltatásból. Az eszkaláció kiment.
Ez az ügyfél nem vette igénybe állandó támogatásunkat, és nem adott jogosultságokat a környezetéhez, így a szerepünk a riasztásnál és az eszkalációnál véget ért. A visszaélést csak ő maga tudta blokkolni. Az ügyfél csapata a nap elején vette fel a fonalat: 08:20 körül a forgalom visszatért a baseline-hoz, 12:40-re pedig az idegen kulcsok és szolgáltatásfiókok eltűntek az összes projektből.
A fiók baseline-ja napi körülbelül 20 dollár. Egyetlen nap aktív visszaélés elég volt ahhoz, hogy többszörösen túllépje a fiók egész éves összköltését. Ez nem az ügyfél konzoljának képernyőképe.
A diagram adatai (táblázat)
| Nap | tipikus | július 16. | július 17. |
|---|---|---|---|
| Költség | ≈ $20 | ≈ $33 250 | ≈ $650 |
Amikor az export lezárta a napot, a számláló harmincháromezer dollárnál állt meg, az eltérés pedig 842 sigmára nőtt. A nap a fiók normális értékének 906-szorosával zárult. Az idővonalon ez így néz ki: a fogyasztás 13:45 után indult, a riasztás 4:30-kor ment ki, mert ennyi időbe telt, míg az adatok beértek a számlázási exportba, a többi pedig a kliens reakcióideje volt. Péntek volt. A májusi történet elég pontosan megmutatja, mi történt volna, ha ez a fogyasztás csendben végigdolgozza a hétvégét. Ahol nemcsak eszkalációs felhatalmazásunk, hanem reagálási jogosultságunk is van, ez a néhány óra percekre zsugorodhat.
A riasztás, amely önmagát oltotta ki
A júliusi incidens második napján a fiók még mindig 14,2 ezer dollárt égetett naponta. A mi z-score-unk pedig erre a napra… 1,1 lett. Statisztikailag? Semmi érdekes, lehet továbbmenni.
Az ok: a gördülő időablaknak volt ideje beépíteni a csúcsnapot a saját baseline-jába. A gördülő átlag 20 dollárról több ezerre ugrott, a szórás az egekbe szállt, és a folyamatban lévő incidens kezdett az új normálisnak tűnni. Egy kritikus riasztás figyelmeztetéssé degradálta magát, miközben a költés egyetlen centtel sem csökkent.
Az első javítás statisztikai volt: ki kell zárni az anomáliás napokat a baseline-ból, két lépésben számolva azt. Nem működött. Az incidens második napja már alacsony z-score-ral rendelkezett, így megmenekült az outlier zászlótól, a harmadik naptól kezdve pedig újból megfertőzte a teljes időablakot. Csak a visszavonás után értettük meg, hogy nem a megfelelő ellenféllel harcolunk: ez nem statisztikai probléma, hanem a riasztás életciklusának problémája. A riasztás egy állapot, nem egyetlen esemény.
Az incidens bejelez. Kártya a Chatben, feladat a CRM-ben, a kritikusoknál PagerDuty is. Zárás a detektálási előzményekbe.
A severity az alsó korlát. A megmérgezett z-score nem tudja degradálni a riasztást vagy duplikátumot indítani. Csend, kivéve ha az incidens valóban eszkalálódik.
AAz incidens elül. Néhány riasztásmentes nap után a kártya eltűnik a dashboardról. Egy újabb eszkaláció új incidenst nyit, saját idővonallal.
Nem minden anomália támadás
Ne feledjük azonban, hogy a rendszer nem kizárólag biztonsági incidenseken él. Egy nap az egyik általunk monitorozott fiók napi költsége a norma 7,6-szorosára nőtt. A riasztás kiment, a CRM-feladat eljutott az ügyfélmenedzserhez, ő pedig tizen-egynéhány percen belül megerősítette az ügyféllel, hogy ez egy tervezett modelltanítás volt a Vertex AI-on. Az epizódot egyetlen kattintással elnémították a nap végéig, megtartva a kritikus eszkalációt. Az ügyfél a tény után egy órával kapott egy „Ez a tietek?” kérdést, a következő havi számlán szereplő meglepetés helyett. Egy olyan rendszer, amely nem tudja gyorsan megkülönböztetni a várhatót a rosszindulatótól, arra tanítja az embereket, hogy figyelmen kívül hagyják a riasztásokat, ez pedig egyenes út a májusi eset megismétlődéséhez.
Apróságok, amik csak éles környezetben jönnek elő
A kontextus nélküli számok hazudnak
Ugyanaz az összeg az egyik környezetben zaj, a másikban a hónap incidense. A nyers számmal összehasonlított küszöb a gyakorlatban „1000 bármit” jelent. Ezért minden értéket az adott fiók, annak léptéke és előzményei kontextusába helyezünk, és az embereknek az összegeket abban a formában mutatjuk meg, ahogyan a számlákról ismerik.
Az adatok csendben romlanak el
A különböző forrásokból és időszakokból származó számlázási adatok elrendezésükben és típusaikban eltérhetnek. Az a kód, amely feltételezi, hogy mindenhol ugyanaz, nem omlik össze semmilyen hibával, csak csendben felcseréli a számokat. Egy olyan rendszerben, amelyben az embereknek bízniuk kell, ez a legrosszabb hibatípus, így nálunk semmilyen feltételezés nem alapértelmezett az adatokról.
A riasztási fáradtság is egyfajta adósság
Minden felesleges riasztás csökkenti az összes következőkbe vetett bizalmat. Ezért a rendszer a spam elleni biztosítékok egész sorát tartalmazza: deduplikációt, cooldownokat, némítást és az epizódok automatikus lejárati idejét. Jelekre tervezünk, nem volumenre.
A számlázási adatok késve érkeznek
Az export sok órán át „töltheti fel” a napot. A júliusi kártya 4:30-kor a nap végső zárásánál többszörösen alacsonyabb összeget mutatott, a számláló pedig még jóval a forgalom blokkolása után is emelkedett. A rendszernek tudnia kell ezt, különben a késve érkező adatokat eszkalációnak tekintené, és ok nélkül riasztaná az embereket.
Egy motor, két működési mód
Ugyanaz az architektúra ma két működési módban fut.
Az első a menedzselt szolgáltatás. Az ügyfél környezetét bevonjuk a monitoringunkba, a riasztások párhuzamosan jutnak el a mi csapatunkhoz és az ügyfélhez, az anomáliát egy adott ügyfélmenedzser osztályozza és kezeli, és ahol jogosultságunk van, közvetlenül reagálunk az egyszerű eszkaláció helyett. A júliusi történet megmutatja, hol húzódik ez a határ: jogosultságok nélkül még a legjobb detektálás is a környezet tulajdonosának felhívásával végződik.
A második mód közvetlenül a felépítésből következik. Mivel a motor állapotmentes és kizárólag a BigQuerybe történő szabványos számlázási exportra támaszkodik, bármilyen Google Cloud környezetben felállítható, még olyanban is, amelyet napi szinten nem mi üzemeltetünk. Egy ilyen telepítésnél a riasztások körét a teljes számlázási fiókról a projektek nézetére szűkítjük. Minden csapat a saját projektjeinek anomáliáit látja, saját küszöbökkel és értesítési csatornákkal. A Chat, az e-mail vagy a webhook a rendszer szemszögéből cserélhető adapterek. Minden más, az SQL-ablakoktól az epizód életciklusáig, mindkét módban azonos módon működik.
Mit jelent ez az Ön környezetére nézve
Akár saját megoldást fejleszt, akár nem, néhány alapelv közvetlenül alkalmazható. A kiindulási alapnak a tényleges használati mintázatokon kell alapulnia, és fiókonként külön kell meghatározni, hiszen egy univerzális határérték minden környezetre csupán illúzió. A riasztásoknak teljes életciklust kell lefedniük: a várakoztatás, a duplikációmentesítés és az automatikus lezárás hiányában a rendszer hetek alatt elveszíti a hitelességét. A statisztika csupán felderít, a döntés a kontextus – vagyis az anomália adott ügyfélhez, felelőshöz és szolgáltatáshoz rendelése – alapján születik meg. Végül a legegyszerűbb, mégis legfontosabb igazság: a költség valójában biztonsági adat. A pénzügy havonta egyszer néz rá, a felügyeletnek viszont megállás nélkül futnia kell.