Konkrét példák: chatbot-lopás, rejtett bejáratok
2025 augusztusában történt meg az áttörés: a Salesloft/Drift-ügyben ismeretlenek megszerezték a Drift chatbot OAuth-tokenjeit, és több mint 700 szervezethez – köztük olyan gigászokhoz, mint a Cloudflare, a Palo Alto Networks vagy a Zscaler – jutottak be. Ezek után a támadók Amazon Web Services-kulcsokra, Snowflake-tokenekre és jelszavakra vadásztak – mindezt anélkül, hogy egyetlen kártékony szoftvert is bevetettek volna.
A helyzet komolyságát mutatja, hogy bár a vállalatok 98%-a már bevezetett valamilyen adatvesztés elleni (DLP) programot, a Proofpoint legfrissebb felmérése szerint ezek többsége csak a klasszikus, strukturált személyes adatokat szűri. A CrowdStrike szerint az interaktív behatolások 81%-a már nem is tartalmaz kártevőt, és 2025 első felében 136%-kal nőtt a felhőalapú támadások száma.
A CX-platformok téves besorolása: hatalmas támadási felület
A legtöbb informatikai biztonsági csapat egy CX-platformot egyszerű kérdőívszerkesztőként kezel – Assaf Keren, a Qualtrics vezető biztonsági szakértője szerint súlyos tévedés ez. Ezek a rendszerek ma már szorosan kapcsolódnak a HR-, bérszámfejtési vagy CRM-megoldásokhoz. Egyedül a Qualtrics több százmillió visszajelzést dolgoz fel évente, ez a szám 2023 óta megduplázódott. Amint belép az MI a folyamatba, az adatbevitel tisztasága élet-halál kérdéssé válik.
Hat vakfolt, amit senki nem ellenőriz
1. A DLP nem lát bele a strukturálatlan adatokba: A rendszer csak a megszokott név, e-mail-cím, számlaadat típusú személyes adatokra (PII) érzékeny. Ha azonban szabad szövegként érkezik egy fizetéssel, egészségi állapottal vagy vezetői kritikával kapcsolatos észrevétel, az simán átcsúszik észrevétlenül.
2. Elfelejtett, de élő API-tokenek: Egy hat hónapja lezárult marketingkampány után is működhetnek azok az OAuth-tokenek, amelyekkel a CX-platform továbbra is hozzáfér HR- vagy fizetési rendszerekhez – ezek automatikus, nyitva hagyott rések a támadók számára.
3. Nyitott csatornák botvédelem nélkül: Míg a webalkalmazás-tűzfalak elemzik az HTTP-forgalmat, senki nem szűri azokat a véleményeket vagy szöveges visszajelzéseket, amelyek a CX-platformba áramlanak. A káros, hamis input teljesen láthatatlan a hagyományos védelem számára.
4. Laterális mozgás engedélyezett kapcsolatokon át: A támadóknak nem feltétlenül kell betörniük, elég bejelentkezniük. Egy validált felhasználó – legyen ember vagy gép – hirtelen tonnányi adatot exportálhat teljesen szokatlan módon, miközben a rendszer semmit nem vesz észre belőle.
5. Áttekintetlen adminisztrátori jogosultságok: Sokszor marketingesek vagy HR-esek kapják meg a CX-integrációk admin jogait, az IT-biztonság pedig semmit nem tud erről.
6. A strukturálatlan adat azonnal adatbázisba kerül: Egy dolgozói vagy vásárlói panasz eljuthat névvel és minden személyes adattal együtt, még mielőtt bármilyen maszkolás vagy anonimizálás történhetne. Ha innen kiszivárog, kész a katasztrófa.
Kié a felelősség?
Miközben a Salesforce vagy a ServiceNow köré már kiépültek a megfelelő védelmi rétegek, a CX-platformok még mindig „gazdátlanul” működnek. Senki sem nézi át, milyen felhasználók milyen jogosultságokkal vagy beállításokkal bírnak, és a folyamatban lévő MI-alapú döntéseket sem kíséri tényleges kontroll.
A védekezés első lépése, hogy egyes vállalatok már kiterjesztették a SaaS-biztonsági eszközeiket a CX-platformok jogosultságaira és kapcsolataira is. Az API-gatewayek és az identitásalapú hozzáférés-ellenőrzések segítenek ugyan, de nem képesek valós idejű felügyeletet adni az összes veszélyes változásra.
A CrowdStrike Falcon Shield és a Qualtrics XM Platform összekapcsolása most először teremt közvetlen védelmi hidat a felhasználói tevékenység, a konfigurációk és az adathozzáférés teljes körű ellenőrzésére, amire az iparági szakértők már régóta vártak.
Közvetlen üzleti kár: az MI hibásan dönt
A következmények messzire nyúlnak: a legtöbb cég csak a technikai kár mértékét tudja felmérni, de az üzleti veszteség kimutatása hiányzik. Amikor például egy mérgezett adat hibás bérrendezést indít el, nemcsak IT-probléma keletkezik, hanem egy pillanat alatt végrehajtott rossz üzleti döntés. Ez már nemcsak az IT-vezetés, hanem az egész vállalat ügye. Senki sem vállalta még érte a teljes felelősséget.
Az első lépés a védekezés útján, hogy auditáljuk a „zombi” tokeneket, hiszen innen ered a legtöbb támadás. A validálási periódus ne legyen hosszabb 30 napnál – az MI gyorsabb, mint hinnéd.
