A vállalati adatbiztonság egyik új vakfoltja nem egy ismeretlen szerver vagy egy engedély nélkül telepített alkalmazás.
A generatív mesterséges intelligencia néhány év alatt a vállalati környezet mindennapi eszközévé vált. Egy munkatárs ma már néhány másodperc alatt összefoglalhat egy dokumentumot, elemezhet egy Excel-táblát, megírhat egy levelet, SQL-lekérdezést vagy akár egy komplett programot.
A probléma nem maga az AI.
A probléma az, hogy a vállalati biztonsági kontrollok sok esetben nem tartották vele a lépést. A klasszikus Shadow IT-ról általában úgy gondolkodunk, mint amikor egy munkatárs engedély nélkül telepít egy alkalmazást, használ egy saját felhőszolgáltatást vagy létrehoz egy saját SaaS-fiókot. Az AI ezt a jelenséget egy teljesen új szintre emeli.
Nem kell telepíteni semmit
A Shadow IT egyik alapvető problémája korábban az volt, hogy az IT-nak valahogy észre kellett vennie az ismeretlen alkalmazást. Egy AI-szolgáltatás esetében erre sokszor nincs szükség. A munkatárs megnyit egy weboldalt, beilleszt egy szöveget, feltölt egy dokumentumot és máris létrejött egy adatáramlás a vállalati környezetből egy külső – gyakran ismeretlen, ellenőrizetlen – szolgáltatás felé. Ehhez nem kell rendszergazdai jogosultság, nem kell telepíteni semmit, csak simán használni az elérhető megoldást. És pontosan ez teszi az úgynevezett Shadow AI-t különösen érdekes biztonsági problémává.
„Csak ezt az egy dokumentumot másolom be…”
Képzeljünk el egy teljesen hétköznapi helyzetet: Egy munkatárs kap egy 30 oldalas szerződést, amit gyorsan össze kell foglalnia. Megnyit egy számára kényelmes AI-szolgáltatást, majd ezt írja:
„Foglalja össze a dokumentumot, és emelje ki a számunkra hátrányos részeket.”
A feladatot az AI néhány másodperc alatt elvégzi. A munkatárs elégedett.
A vállalat viszont közben elvesztette a kontroll egy részét afelett, hogy milyen üzleti információ hagyta el a vállalati környezetet.
Ugyanez megtörténhet:
- ügyféllistával,
- szerződésekkel,
- belső szabályzatokkal,
- forráskóddal,
- incidensjelentésekkel,
- személyes adatokkal,
- pénzügyi információkkal,
- jelszavakkal vagy API-kulcsokkal,
- üzleti tervekkel,
- vagy akár egy még be nem jelentett termék dokumentációjával.
Az OWASP jelenlegi LLM-kockázati listája külön kategóriaként kezeli a Sensitive Information Disclosure kockázatát, amelybe többek között személyes adatok, pénzügyi információk, üzleti titkok és hitelesítési adatok is beletartozhatnak. A NIST generatív AI-ra vonatkozó profilja szintén külön foglalkozik az adatvédelmi kockázatokkal, többek között az érzékeny információk kiszivárgásának és az adatok nem megfelelő kezelésének problémájával.
De van egy másik probléma is
Az AI nemcsak adatfeldolgozó eszközzé vált hanem fejlesztőeszközzé is. És ez a Shadow IT egy újabb rétegét hozza létre. Ma már egy olyan munkatárs is képes működő alkalmazást létrehozni AI segítségével, aki korábban nem feltétlenül rendelkezett klasszikus szoftverfejlesztési tudással.
„Írj nekem egy PHP alkalmazást, amely…”
„Készíts egy scriptet, ami letölti…”
„Írj egy API-klienst…”
„Kösd össze ezt az adatbázist ezzel a szolgáltatással…”
Az AI pedig megírja a kódot. A munkatárs lefuttatja. Működik.
És ezzel megszületett egy új alkalmazás a vállalati környezetben – anélkül, hogy a klasszikus fejlesztési és biztonsági folyamatokon feltétlenül átment volna.
A veszély nem feltétlenül az AI által írt kód
Fontos különbséget tenni. Nem az a probléma, hogy az AI kódot generál. A probléma az, amikor a generált kódot biztonsági kontrollok nélkül helyezik üzembe.
Egy alkalmazás közvetlenül hozzáfér egy belső adatbázishoz vagy egy API-kulcs bekerül a forráskódba. Egy fejlesztő egy olyan szolgáltatást használ, amely túl széles jogosultságokkal rendelkezik vagy az AI által generált SQL-lekérdezést mindenféle ellenőrzés nélkül futtatják. Ezek egyike sem új biztonsági probléma.
Az új elem az, hogy az AI jelentősen csökkenti azt a tudás- és időbeli küszöböt, amely egy ilyen rendszer létrehozásához szükséges.
Korábban ehhez fejlesztő kellett. Ma elég lehet egy munkatárs, egy AI és néhány jól megfogalmazott prompt.
A „10 soros script” is lehet biztonsági kockázat
Vegyünk egy másik példát.
Egy alkalmazott szeretné automatizálni a napi riportkészítést.
AI segítségével létrehoz egy kis Python scriptet, amely:
- csatlakozik az adatbázishoz,
- lekéri az adatokat,
- elkészíti a riportot,
- majd elküldi egy külső AI API-nak összefoglalásra.
A script 150 sor. Nem kerül be a vállalati repositoryba. Nincs code review. Nincs threat modeling. Nincs dependency scanning. Nincs security testing. Nincs dokumentált adatáramlás.
A fejlesztő pedig valószínűleg úgy gondol rá:
„Ez csak egy kis belső script.”
Biztonsági szempontból azonban nem az számít, hogy 150 vagy 150 000 soros-e.
Az számít, hogy milyen adatokhoz fér hozzá, milyen rendszereket ér el, milyen jogosultságokkal rendelkezik, és hová továbbít adatot.
Az AI tehát két irányban növeli a Shadow IT-t
Ez szerintem az egyik legfontosabb különbség a hagyományos Shadow IT-hoz képest.
1. Shadow AI mint adatkilépési csatorna
A munkatárs adatot küld egy külső AI-szolgáltatásnak.
2. Shadow AI mint alkalmazásfejlesztő
A munkatárs AI segítségével létrehoz egy saját alkalmazást vagy automatizációt és itt már nemcsak az adatvesztés lehet a probléma.
Megjelenik:
- hibás jogosultságkezelés,
- hardcoded credential,
- nem biztonságos API,
- sérülékeny dependency,
- hibás input validation,
- SQL injection,
- érzékeny adatok naplózása,
- túlzott rendszerjogosultság,
- nem megfelelő titkosítás,
- kontrollálatlan külső kommunikáció.
Az OWASP LLM Security Project többek között a Sensitive Information Disclosure, az Improper Output Handling és az Excessive Agency kockázatait is kiemeli. Utóbbi különösen érdekes akkor, amikor egy AI-alapú rendszer már nemcsak tanácsot ad, hanem más rendszerekkel is képes műveleteket végrehajtani.
Fokozzuk még?
Mert az AI-val létrehozott alkalmazás nem feltétlenül marad „kis script”. Először csak egy munkatárs használja, de aztán megmutatja a kollégájának és elkezdi az egész csapat használni. Egy hónap múlva pedig már öt ember munkafolyamata épül rá. Hat hónap múlva pedig kiderül, hogy a szervezetben van egy üzletileg kritikus alkalmazás, amelyről az IT Security nem tudott.
Mit lehet ezzel kezdeni?
Az első reakció sok szervezetben az lenne:
„Tiltsuk le az AI-t.”
Ez rövid távon egyszerű megoldásnak tűnhet, de önmagában nem oldja meg a problémát. Az AI használata már túl széles körű ahhoz, hogy egyszerű tiltólistával kezeljük. Sokkal inkább kontrollált AI-használatra van szükség.
1. AI inventory
A vállalatnak tudnia kellene:
- milyen AI-szolgáltatásokat használnak,
- milyen célra,
- milyen adatokat küldenek ezekbe,
- kik használják,
- milyen üzleti folyamat részei.
A „nem engedélyezett AI” önmagában nem elegendő kategória. A kérdés inkább az: Mit használunk, mire használjuk és milyen adatokkal?
2. Adatosztályozás
Nem minden adat egyformán érzékeny. Érdemes egyértelmű szabályokat létrehozni arra, hogy:
- publikus adat,
- belső adat,
- bizalmas adat,
- személyes adat,
- üzleti titok,
- hitelesítési adat
milyen AI-szolgáltatásba kerülhet.
3. Technikai kontrollok
A policy önmagában kevés. Szükség lehet például:
- DLP-re,
- CASB/SSE megoldásokra,
- web proxy kontrollokra,
- identity alapú hozzáférésre,
- API gateway-ekre,
- secret managementre,
- loggingra,
- monitoringra,
- megfelelő endpoint kontrollokra.
A cél nem feltétlenül az, hogy minden AI-t blokkoljunk. Hanem az, hogy a vállalat tudja, mi történik az adatokkal.
4. AI-assisted development = development
Ha egy AI által létrehozott alkalmazás vállalati adatot kezel, akkor biztonsági szempontból nem szabad „csak egy scriptként” kezelni. Ugyanazoknak az alapelveknek kell érvényesülniük, mint más alkalmazásoknál. Az AI nem mentesíti a fejlesztőt a biztonsági felelősség alól.
5. Ne csak a felhasználót oktassuk
Az AI-használati szabályzat önmagában kevés. A fejlesztőknek különösen azt kell megtanulniuk, hogy az AI által generált kódot nem tekinthetik automatikusan megbízhatónak. Az OWASP ajánlásai között is megjelenik a generált output megfelelő validációja és a klasszikus biztonsági tesztelési gyakorlatok alkalmazása.
A legnagyobb változás azonban szemléleti
A Shadow AI kezelése nem pusztán egy újabb IT policy kérdése.
Ez egyszerre:
- információbiztonsági,
- adatvédelmi,
- fejlesztésbiztonsági,
- identity és access management,
- governance,
- és üzleti kockázatkezelési kérdés.
A NIST AI Risk Management Framework és annak generatív AI profilja éppen ezért az AI kockázatainak kezelését nem egyetlen kontrollra, hanem a teljes életciklusra kiterjedő megközelítésként kezeli.
A kérdés már nem az, hogy használ-e AI-t a vállalat. Valószínűleg használ.
A kérdés inkább az:
- Tudja-e a vállalat, hogy hol használják?
- Tudja-e, milyen adat kerül bele?
- Tudja-e, milyen AI-alapú alkalmazásokat hoztak létre a munkatársak?
- És tudja-e, hogy ezek az alkalmazások milyen rendszerekhez férnek hozzá?
Mert lehet, hogy a vállalatnak van kiváló tűzfala, EDR-je, SIEM-je, DLP-je és IAM-rendszere. Közben pedig egy munkatárs egy böngészőből feltölt egy bizalmas dokumentumot egy AI-szolgáltatásba vagy AI segítségével ír egy 200 soros scriptet, amely közvetlenül hozzáfér egy belső adatbázishoz. És a szervezet minderről semmit sem lát. Ez lehet a Shadow IT következő generációja.
Nem az a kérdés, hogy AI vagy nem AI. Hanem az, hogy látható és kontrollált AI-használat vagy láthatatlan Shadow AI. És a kettő között biztonsági szempontból óriási különbség van.
