
Két nagy Copilot-fiaskó nyolc hónapon belül
Úgy tűnik, hogy ez a mostani botlás már a második, amely során az MI-asszisztens megszegte saját védelmi határait, és hozzáfért, illetve továbbított korlátozott adatokat. Az első, súlyosabb incidens 2025 júniusában történt, amikor a Microsoft egy kritikus hibát foltozott be (EchoLeak), amely lehetővé tette, hogy egy trükkösen szerkesztett levél minden kontroll nélkül szivárogtasson ki céges adatokat – bármiféle kattintás vagy felhasználói beavatkozás nélkül.
A két incidens hátterében különböző hibák álltak: kódhiba az egyiknél, kifinomult exploit-lánc a másiknál, de a végeredmény ugyanaz lett: a Copilot olyan adatokkal dolgozott, amelyeket tilos lett volna elérnie, a biztonsági rendszer pedig vak maradt.
Miért nem látják ezt a hagyományos biztonsági rendszerek?
Az olyan eszközök, mint a végponti védelem (EDR) vagy a webalkalmazás-tűzfal (WAF), eddig főleg fájl- és folyamatműködést, illetve HTTP-forgalmat figyeltek. Ezek viszont teljesen vakok, ha az MI-asszisztensek a saját rendszerükön belül szegnek meg tiltásokat. Például a Copilot a szerveren belül szolgálja ki a lekérést a retriever és a generátor között: nincs lementett állomány, nincs szokatlan hálózati aktivitás, semmi sem jut el azokhoz a komponensekhez, amelyek detektálhatnák a szabálysértést.
Az aktuális hibát (CW1226324) egy kódhiba okozta, amely lehetővé tette, hogy a Sent Items és Drafts mappákban lévő, érzékenynek jelölt levelek bejussanak a Copilot amúgy letiltott keresési eredményei közé. Az EchoLeak exploit pedig manipulatívan megfogalmazott e-maillel tudta befolyásolni az MI-asszisztens működését, és belső adatokat továbbított egy támadók által vezérelt szerverre.
Az Aim Security kutatói szerint az MI-asszisztensek „egy gondolati folyamattal” kezelik a megbízható és nem megbízható adatokat, ezért mindig támadhatóak maradnak az ilyen jellegű problémákkal.
Ötpontos audit, amivel minden szervezet csökkentheti a kockázatot
Ezeket a hiányosságokat egyik biztonsági eszköz sem jelezte, mindkét hibát a Microsoft belső tanácsadói csatornáin keresztül ismerték fel.
1. Rendszeresen teszteld, hogy a Copilot ténylegesen figyelembe veszi-e az érzékenységi címkéket. Hozz létre tesztüzeneteket kontrollált mappákban, és győződj meg róla, hogy a Copilot nem jeleníti meg ezeket lekérdezéskor. Nem a konfiguráció számít, hanem a tényleges működés.
2. Zárd ki, hogy külső tartalom bekerülhessen a Copilot kontextusablakába. Az EchoLeak azért tudott sikeres lenni, mert egy kívülről érkező e-mail elérte a Copilotot. Kezdd azzal, hogy megtiltod a külső e-mail-kontextus használatát, és korlátozod a Markdown-megjelenítést.
3. Ellenőrizd a Purview-naplókat, hogy volt-e a kérdéses időszakban szokatlan Copilot-interakció érzékeny tartalommal. Ha nincs bizonyítékod arról, mire jutott az MI, akkor a megfelelőséget is veszélyeztetheted, főleg szabályozott területen.
4. Kapcsold be a SharePoint érzékeny webhelyein a Restricted Content Discovery-t: így ezek az adatok egyáltalán nem fognak felbukkanni a Copilot keresésében, bármilyen hiba is legyen máshol.
5. Készítsd el az incidenskezelési forgatókönyvet MI-alapú hibaesetekre: legyen benne, hogy kihez kerül az ügy, hogyan értesülsz a szállítói figyelmeztetésekről, és mit kell tenned, ha a következő, hasonló hiba felbukkan.
Az MI-rendszerek szerkezeti hibái
Egy friss felmérés szerint a vezető infobiztonsági szakemberek 47%-a már most is tapasztalt váratlan vagy engedély nélkül végrehajtott műveleteket, pedig a legtöbb cég gyorsabban vezeti be ezeket, mintsem hogy hatékony kontrollt építene ki hozzájuk.
Az MI-kontextus-specifikus hozzáférési hibák nemcsak a Copilot sajátosságai. Bármely RAG (Retrieval-Augmented Generation) alapú belső kereső és asszisztens ugyanebbe a problémába ütközik: ha a biztonsági réteg hibázik, a rendszer bármit továbbít a lekérdezőnek, a biztonsági stack pedig erről nem is szerez tudomást.
Mit mondhat a vezetésnek a biztonsági vezető?
A tanács: havonta futtasd le az ötpontos ellenőrzést. Ha a Copilot mégis elér érzékeny, korlátozott tartalmat, akkor minden alatta fekvő szabály csak látszatbiztonság. A szervezeteknek egyre inkább maguknak kell kialakítaniuk a szükséges kontrollokat – mert a következő adatvédelmi incidens sem fog riasztást küldeni.
