Az AI-szolgáltatások használatával új adatáramlások jelennek meg a vállalati környezetben. A kérdés az, hogy ezekből mit képes felismerni, ellenőrizni és megakadályozni egy DLP-rendszer.

A Shadow AI egyik legfontosabb információbiztonsági kérdése, hogy a vállalat képes-e érzékelni, milyen adatokat továbbítanak a munkatársak a különböző AI-szolgáltatások felé.

Ez elsőre egyszerű DLP-feladatnak tűnhet. A gyakorlatban azonban az AI használata többféle adatmozgást jelent, amelyek eltérő módon figyelhetők meg és kontrollálhatók.

Más biztonsági kihívást jelent, ha egy munkatárs bizalmas dokumentumot tölt fel egy nyilvános chatbotba, és mást, ha egy saját fejlesztésű alkalmazás automatikusan továbbít adatokat egy külső AI API-nak.

A két esetben közös, hogy érzékeny vállalati információ kerülhet olyan környezetbe, amely felett a szervezetnek korlátozott rálátása vagy kontrollja van.

Ezért nem elegendő azt vizsgálni, hogy rendelkezik-e a vállalat DLP-megoldással. Azt is meg kell érteni, hogy hol helyezkedik el a kontroll, milyen adatokat képes vizsgálni, és mely adatáramlások maradnak kívül a látóterén.

1. A legegyszerűbb eset: amikor a felhasználó adatot másol be

A legismertebb Shadow AI-helyzet, amikor egy munkatárs megnyit egy nyilvános AI-szolgáltatást, és bemásol egy vállalati dokumentumból származó szöveget.

Például egy szerződés elemzését kéri, összefoglaltat egy incidensjelentést, vagy segítséget kér egy forráskód hibájának javításához.

A felhasználó számára ez egy egyszerű munkafolyamat. Biztonsági szempontból azonban adatátadás történik egy külső szolgáltatás felé.

Ha a DLP megfelelő ponton képes ellenőrizni a műveletet, felismerheti, hogy az elküldeni kívánt tartalom érzékeny információt tartalmaz-e. A megoldás konfigurációjától és támogatott funkcióitól függően akár meg is akadályozhatja az adatátadást.

A Microsoft Purview dokumentációja például külön foglalkozik a harmadik fél generatív AI-szolgáltatásaiba történő szövegbeillesztés és fájlfeltöltés szabályozásával.

Fontos különbség van azonban aközött, hogy a vállalat látja egy AI-szolgáltatás használatát, és aközött, hogy képes megvizsgálni az oda küldött tartalmat.

Az alkalmazás felismerése önmagában nem jelenti az adatvesztés kontrollálását.

2. A fájlfeltöltés külön kontrollt igényelhet

Nem minden esetben másolja be a felhasználó a dokumentum tartalmát. Gyakran egyszerűbb feltölteni egy teljes PDF-et, Excel-táblázatot vagy forráskódfájlt.

Ilyenkor a DLP-nek a fájl tartalmát, típusát és az adatátadás körülményeit is figyelembe kell vennie.

A vizsgálat eredményességét befolyásolhatja például a fájl formátuma, mérete, titkosítása, valamint az, hogy az adatátadás milyen böngészőn vagy alkalmazáson keresztül történik.

Egy megfelelően kialakított kontrollrendszernek ezért nem pusztán azt kell rögzítenie, hogy a munkatárs AI-t használt. Lehetőség szerint azt is meg kell állapítania, hogy történt-e fájlfeltöltés, és a feltöltött tartalom sért-e valamely adatvédelmi vagy információbiztonsági szabályt.

A különbség jelentős: egy AI-szolgáltatás használata önmagában nem feltétlenül kockázatos, egy bizalmas ügyféllista feltöltése viszont már konkrét biztonsági esemény lehet.

3. Miért nem elég az AI-szolgáltatások listázása?

A Shadow AI felderítésének egyik lehetséges kiindulópontja a vállalati környezetből elérhető AI-szolgáltatások azonosítása.

Ez segít feltérképezni, milyen szolgáltatásokat használnak a munkatársak, és melyek igényelnek további vizsgálatot. Önmagában azonban nem ad teljes képet az adatmozgásokról.

Egy alkalmazott például nem közvetlenül egy chatbot weboldalán dolgozik, hanem egy böngészőbővítményt használ. Egy fejlesztő saját programot készít, amely külső AI API-val kommunikál. Az is előfordulhat, hogy egy vállalati alkalmazás integrál valamilyen AI-szolgáltatást a háttérben.

Ezek a helyzetek eltérő hálózati és alkalmazásszintű adatáramlásokat eredményeznek.

A vállalatnak ezért nemcsak az AI-szolgáltatások használatát érdemes felderítenie, hanem azt is, hogy milyen alkalmazásokon keresztül, milyen adatokkal és milyen célállomások felé történik adatátadás.

4. Az API-használat a DLP egyik fontos vakfoltja lehet

A fejlesztők és az automatizációk esetében az adatátadás gyakran nem böngészőn keresztül történik.

Egy saját alkalmazás például vállalati adatbázisból olvas adatokat, feldolgozza azokat, majd egy külső AI API-nak küldi el elemzésre.

Ilyenkor a felhasználó nem feltétlenül végez másolást vagy fájlfeltöltést. Az adatküldést maga a program hajtja végre.

Ez különösen fontos az AI segítségével készített belső alkalmazások esetében. Egy munkatárs létrehozhat egy scriptet, amely automatikusan összefoglalja a vállalati riportokat, feldolgozza a hibajegyeket, vagy ügyféladatokat elemez.

Ha a fejlesztés során nem vizsgálják meg az adatkezelést, a program akár olyan információkat is továbbíthat külső szolgáltatásnak, amelyek kezelésére nem kapott engedélyt.

A böngészőalapú DLP ebben az esetben önmagában nem feltétlenül elegendő. A hálózati kontrollok, az API-használat felügyelete, a hozzáférés-kezelés és az alkalmazásszintű ellenőrzések egyaránt szerepet kaphatnak.

Az adatvesztés nem attól függ, hogy egy ember vagy egy program indítja-e el az adatátadást.

5. A legnehezebb kérdés: mit tekintünk érzékeny adatnak?

A DLP hatékonysága nagymértékben függ attól, hogy a szervezet milyen adatok védelmét határozza meg célként.

Viszonylag egyszerű lehet felismerni egy bankkártyaszámot, egy meghatározott formátumú személyes azonosítót vagy egy ismert titkos kulcsot. Nehezebb feladat egy belső üzleti terv, egy szerződéses tárgyalás részlete vagy egy vállalati incidens leírásának érzékenységét megítélni.

Az ilyen információk nem feltétlenül tartalmaznak felismerhető azonosítókat vagy előre meghatározott mintákat.

Egy dokumentum tartalma önmagában akár ártalmatlannak is tűnhet, miközben egy konkrét ügyféllel, projekttel vagy üzleti döntéssel összefüggésben már bizalmas információt jelent.

Ezért a DLP-szabályokat célszerű adatbesorolásra, tartalomelemzésre és a rendelkezésre álló üzleti kontextusra építeni. Egyetlen felismerési módszer nem feltétlenül képes minden érzékeny információt megbízhatóan azonosítani.

6. Nem csak a modellnek küldött adat jelent kockázatot

Az AI-adatbiztonságot gyakran kizárólag a felhasználói bemenet oldaláról vizsgáljuk. A kockázatok azonban az AI által előállított eredményekben is megjelenhetnek.

Egy vállalati AI-alkalmazás például belső dokumentumokból dolgozik, majd választ ad egy felhasználó kérdésére. Ha a rendszer jogosultságkezelése nem megfelelő, olyan adatokat is megjeleníthet, amelyekhez a felhasználónak nem lenne szabad hozzáférnie.

Ez már nem egyszerűen egy külső szolgáltatásba történő adatfeltöltés problémája. A biztonsági hiba az információ vállalaton belüli jogosulatlan hozzáférhetővé válása lehet.

Hasonló kérdés merül fel akkor, ha az AI által generált kimenetet egy másik alkalmazás automatikusan feldolgozza. Egy nem megfelelően ellenőrzött SQL-lekérdezés, parancs vagy más generált tartalom további biztonsági problémákat okozhat.

Az OWASP LLM-alkalmazásokra vonatkozó útmutatói ezért külön foglalkoznak az érzékeny információk felfedésével és a generált kimenetek nem megfelelő kezelésével.

Ezeket a kockázatokat nem lehet minden esetben hagyományos DLP-vel kezelni. Szükség lehet alkalmazásszintű jogosultságkezelésre, kimenetellenőrzésre és biztonságos fejlesztési gyakorlatokra is.

7. Milyen adatfolyamokat érdemes kontrollálni?

A vállalati AI-biztonság kialakításakor célszerű az egyes adatátadási helyzeteket külön megvizsgálni.

Adatátadási helyzet	Elsődleges kontrolllehetőség
Szöveg bemásolása egy AI-chatbe	Endpoint- vagy böngészőalapú DLP
Dokumentum feltöltése AI-szolgáltatásba	Fájltartalom-vizsgálat és DLP
Külső AI API használata saját programból	API-felügyelet, hálózati kontrollok
Belső adatbázis összekapcsolása AI-val	Jogosultságkezelés, adatminimalizálás, alkalmazásszintű kontroll
AI által generált válasz megjelenítése	Hozzáférés-ellenőrzés és kimenetvalidáció
AI-agent műveletei vállalati rendszerekben	IAM, minimális jogosultság és műveletfelügyelet

A táblázatban szereplő kontrollok nem minden esetben helyettesítik egymást. A megfelelő megoldás attól függ, hol történik az adatátadás, milyen adatokról van szó, és milyen technikai lehetőségeket biztosít az adott környezet.

A cél nem az, hogy minden adatmozgást ugyanazzal az eszközzel próbáljunk kezelni, hanem az, hogy minden lényeges adatátadási ponton legyen megfelelő felderítés, megelőzés vagy ellenőrzés.

8. A DLP nem lát mindent

A DLP-rendszerek képességeit könnyű túlbecsülni. Egy vállalat attól, hogy rendelkezik DLP-vel, még nem feltétlenül lát minden AI-val kapcsolatos adatmozgást.

A láthatóság függ a telepített megoldástól, a konfigurációtól, a használt alkalmazásoktól, a böngésző támogatásától és attól is, hogy az adatátadás mely ponton halad át a kontrollon.

Egy kezelt végponton, támogatott böngészőben végrehajtott fájlfeltöltés jól meghatározott körülmények között vizsgálható és blokkolható lehet. Egy saját fejlesztésű program által kezdeményezett API-hívás azonban egészen más felügyeleti megközelítést igényelhet.

További nehézséget okozhatnak a titkosított kommunikációs csatornák, a nem ismert célállomások, a nem támogatott alkalmazások és a jogosultságokkal visszaélő automatizációk.

A Microsoft dokumentációja is külön kezeli a generatív AI-alkalmazások felderítését és a különböző adatvédelmi kontrollokat. Ez is arra utal, hogy az AI-biztonság nem oldható meg egyetlen DLP-szabály bevezetésével.

A megfelelő védelemhez több kontrollréteg összehangolt működésére van szükség.

9. Hogyan mérhető a vállalat valódi felkészültsége?

A vállalat AI-adatbiztonsági érettségét nem önmagában a DLP megléte vagy az AI-használati szabályzat tartalma határozza meg.

Sokkal beszédesebb, hogy a szervezet képes-e konkrét helyzetekre válaszolni.

• Felismerhető-e, ha valaki bizalmas dokumentumot tölt fel egy nem engedélyezett AI-szolgáltatásba?
• Megkülönböztethető-e a szolgáltatás használata az érzékeny adat tényleges továbbításától?
• Ellenőrizhető-e a vállalati alkalmazásokból induló külső AI API-forgalom?
• Azonosíthatók-e az AI által használt belső adatforrások és hozzáférések?
• Van-e kontroll az AI-agentek által végrehajtható műveletek felett?
• Megállapítható-e, hogy egy észlelt adatátadás szabályos üzleti tevékenység vagy biztonsági esemény?

Ezek a kérdések nem feltétlenül egyetlen termék képességeiről szólnak. Sokkal inkább arról, hogy a vállalat technikai és szervezeti kontrolljai együtt képesek-e kezelni az AI-használatból eredő kockázatokat.

Összegzés

A DLP fontos része lehet a Shadow AI elleni védekezésnek, de nem tekinthető az AI-adatbiztonság teljes megoldásának.

A generatív AI elterjedésével nemcsak az adatvesztés lehetséges útvonalai változnak meg, hanem az is, hogy milyen rendszerek kezdeményezhetnek adatátadást. Egy felhasználói másolás, egy dokumentumfeltöltés, egy API-hívás és egy AI-agent által végrehajtott művelet különböző technikai kontrollokat igényelhet.

Ezért a vállalatnak nem elegendő azt tudnia, hogy milyen AI-szolgáltatásokat használnak a munkatársai. Az adatáramlásokat is értenie kell, beleértve az adat forrását, a célállomást, az alkalmazás szerepét és az adat érzékenységét.

A legfontosabb kérdés tehát nem az, hogy van-e DLP a vállalatnál, hanem az, hogy a DLP és a többi biztonsági kontroll együtt lefedi-e azokat az adatfolyamokat, amelyek valóban kockázatot jelentenek.

Mert a kontroll megléte még nem bizonyítja a megfelelő lefedettséget. A biztonsághoz azt is ismerni kell, hogy hol vannak a vakfoltok. :::