Az alkalmazáshálózat: új támadási felület
Noha sok szervezet az utóbbi években megtette a szükséges lépéseket – erősítették a felhasználói azonosítást, kötelezővé tették a többlépcsős hitelesítést, megszüntették a régi hozzáférési protokollokat –, a támadók új utat találtak: az összekapcsolt alkalmazások rendszerében rejlő réseket. Itt az OAuth jogosultságok és az API-hozzáférések jelentik a fő támadási felületet, nem pedig a klasszikus bejelentkezési pontok.
Az igazi kérdés immár az, hogy egy belépett (vagy automatikusan beléptetett) integráció mit tehet, mire jogosult a rendszerben – mert ezek a hozzáférések gyakran minden szabályt meg tudnak kerülni.
Drift/Salesloft incidens következményei
Augusztus elején egy ismert támadócsoport előbb a Salesforce-ot támadta meg ellopott tokenekkel, majd ugyanezzel a módszerrel Google Workspace postafiókokat tört fel, amelyek Drift Email integrációval voltak összekötve. A Google gyorsan reagált: visszavonta a tokeneket, lekapcsolta a problémás integrációt, de a támadók így is elérték céljukat.
Az érintett ügyfelek körében nem tört ki pánik, inkább higgadt mérlegelést és kárelhárítást láthattunk: felderítették a Drifthez kapcsolódó fiókokat, megtisztították a hozzáféréseket, kulcsokat cseréltek. Egy jól felkészített szervezetnél már nem a támadó rendszerben töltött ideje (dwell time) a döntő, hanem az, hogy az igazán érzékeny adatokat – például fontos levelezéseket – csak további, emberi ellenőrzés után lehet elérni. Ez a megközelítés abból indul ki, hogy a betörés valamikor úgyis bekövetkezik, de a célpont (érzékeny adat) soha nem lesz automatikusan hozzáférhető.
A jelenség nem egyedi – az ipari méretű adatlopások korszaka
A Salesloft és Drift-incidens egy nagyobb trend része. A támadók ma már nem a végpontokat keresik, hanem a tokeneket, amelyekkel jogosultságot szerezhetnek, és ehhez igazítják az egész folyamatot: tokenekkel tömeges adatexport, felhőben tárolt titkok felderítése, kulcsrotáció, jogosultságok újbóli meghatározása. Néhány hónappal korábban a Snowflake szolgáltatásban tapasztalt hullám is ezt mutatta, csak más cégek nevével.
Mindez arra enged következtetni, hogy a klasszikus „peremvédelem” már valóban nem működik, a támadók bejutási lehetőségei megszámlálhatatlanok – legyen szó e-mailről, fájlokról vagy felhasználói fiókokról.
1100%-os növekedés: az érzékeny fájlok számának robbanása
A Material Security elemzése szerint az e-mail fiókokban és a Drive-on tárolt érzékeny adatok mennyisége 1100%-kal nőtt az utóbbi időszakban. Jól látható, hogy a bizalmas információk nemcsak szaporodnak, hanem szinte kontrollálhatatlanul osztódnak és terjednek a felhőben, ezzel jelentősen növelve a támadási felületet.
Mit jelent a valódi védelem a Google Workspace-ben?
A mai környezetben a hatékony védekezés többrétegű. Az első lépés a hangsúly eltolása: már nemcsak a megelőzésen van a hangsúly, hanem a robusztus detektáláson és a gyors visszaállításon. A Workspace-nek önálló, kritikus infrastruktúrát kell képeznie a védelemben, három szinten: integrációk, azonosítók, tartalmak.
Az integrációk szintjén elengedhetetlen az átláthatóság és a kontroll: minden harmadik fél alkalmazást fel kell térképezni, a feleslegeseket törölni, a megmaradóknál a jogosultságokat szűkíteni, és folyamatosan figyelni minden új, kockázatos engedélyt.
Az incidensekre gyorsan kell reagálni: előbb minden gyanús hozzáférést és kulcsot törölni, és csak utána vizsgálni, mi történt pontosan. A naplófájlok elemzése alapján meghozott döntés sokszor már túl késő lehet.
Az identitás szintjén már nem elég az MFA kipipálása. Csak az adathalászat-biztos hitelesítés a megfelelő. A régi protokollok és az egyszer használatos jelszavak kizárása kötelező. Gyanús viselkedés esetén (szokatlan adatlekérés, automatikus megosztások, e-mail szabályok változása) alapos ellenőrzést kell indítani, nem csupán a bejelentkezések figyelésére szorítkozva.
A döntő réteg azonban a tartalom szintje. Ha egy tokennel minden elérhető a vezetői postafiókban, minden más intézkedés felesleges. Az üzenetszintű MFA erre ad megoldást: az érzékeny e-mailek, jogi vagy szabályozott levelezések zárolva maradnak, amíg egy valódi ember nem igazolja a hozzáférés jogosságát. Így egy ellopott token csak kellemetlenség, nem pedig katasztrófa.
Automatizált, gépi sebességű védekezés
Ezek az intézkedések csak akkor érnek valamit, ha automatikusan tudnak működni vagy a csapat gyorsan tud reagálni rájuk. Az azonnali cselekvési terv magában foglalja az apptokenek visszavonását egy gyanús beszállító esetén, fiókok felfüggesztését, fertőzött levelek karanténba helyezését, kockázatos Drive-megosztások leállítását és a jogosultságok felülvizsgálatát.
A jövő: felkészülés az elkerülhetetlenre
A tapasztalatok alapján abból kell kiindulni: az integrációkkal való visszaélés, a tokenek kiszivárgása és a kreatív támadók trükkjei kedvelt megkerülő útjai lesznek a felhő-audit rendszernek. Fontos, hogy a rendszert úgy alakítsuk ki, hogy ezekből a feltevésekből ne lehessen adatlopási botrány – csak egy apró kellemetlenség.
A konklúzió: csak akkor lehetünk nyugodtak, ha nem csupán az ajtót védjük, hanem magát a valódi célpontot is. Ha minden biztonsági intézkedés ezt a logikát követi, egy ellopott token csupán rövid ideig okoz többletmunkát, nem pedig súlyos adatvesztést.
