Az AI egyre mélyebben integrálódik a hagyományos vállalati infrastruktúrába, és folyamatosan alakítja át az IT és az arra saját folyamatait ráépítő üzlet kapcsolatát. A szervezeteknek emiatt újra kell gondolniuk az IT-biztonságukat.

Az átalakulást jól mutatja az üzleti folyamatok automatizálása. Korábban az ezzel kapcsolatos kódolási feladatok kevés kivétellel a belső vagy külső fejlesztői csapatokra hárultak, még az ún. low-coding platformok esetében is az IT szoros felügyeletével történt az integrálás. A mesterséges intelligencia korában azonban, amikor természetes nyelven lehet leírni egy alkalmazás működését, és az alapján az AI képes működő kódot létrehozni, kis túlzással bárki lehet "szoftverfejlesztő" – foglalta össze az AI hatását a vállalati működésre Werner Obring, a Clico Hungary cloud security architektje.

A technológia utat nyit egy rugalmasabb vállalati működés felé, ugyanakkor óriási biztonsági kockázatokat is hordoz, ha egy szervezet nem veszi figyelembe azokat a változásokat, melyeket az AI hoz a szervezet működésébe. A szakember szerint problémák többségének ugyanaz a gyökere: nem veszik figyelembe, hogy az AI nem úgy működik, mint az ember. A mesterséges intelligencia hatékonyságra optimalizált, azaz egyetlen célja, hogy megvalósítsa a kitűzött célt. Ezzel szemben az ember komplexen látja a megoldandó feladatot, és bizonyos korlátokat akkor sem lép át, ha azok nem formalizáltak. Az ember ugyanis nemcsak a feladatot látja, hanem a kontextust is – mondta Werner Obring. Ezért ha az AI-t beengedjük a vállalati folyamatokba, a korábbinál sokkal hangsúlyosabb lesz a kontrollok szerepe.

Milyen kontrollokra kell itt gondolni?

Werner Obring: Mindenekelőtt ott van az IAM (Identity and Access Management) keretrendszer. Fontos annak árnyalt és pontos konfigurálása, hogy egy AI-agent milyen rendszerekhez, adatokhoz API-khoz férhet hozzá. Az AI esetében a feladatok végrehajtását minden esetben emberhez kell kötni, aki felelős az agent munkájáért.

De ez önmagában nem elegendő. Nem zárja ki ugyanis annak a lehetőségét, hogy adott agent hibás vagy manipulált utasítást hajtson végre, azaz ún. prompt injection incidens történjen. Ennek megelőzésére szintén kell kontroll.

Milyen kihívásokat jelent, hogy az AI-biztonság és a hagyományos, akár legacy rendszer együttes védelme?

W. O.: Ilyen esetben is az a legfontosabb, hogy pontosan definiáljuk az AI-agent által elvégezhető műveleteket. Mihez férhet hozzá? Mit kérdezhet le? Hol és milyen feltételek teljesülése esetén hajthat végre módosítást? És így tovább. Fontos, hogy ebben lépésről lépésre haladjunk, azaz fokozatosan bővítsük az agentek mozgásterét, mert így gyorsabban azonosítható, ha probléma adódik. És mindig be kell iktatni az embert mint végső ellenőrző és védelmi vonalat. Ha például AI-agenteket használunk ajánlatok összeállítására, az a minimum, hogy például értékhatár-korlátot szabunk, amíg az agent önállóan dolgozhat. Ugyanakkor minden ajánlatot jóvá kell hagynia egy felelősnek is. És természetesen minden esetben kell egy funkció, amivel az agent tevékenysége azonnal leállítható.

A legacy rendszerek esetében gyakori, hogy a megfelelő API hiánya miatt az alkalmazás nem lát rá azokra a műveletekre, amelyeket az agent végrehajt, esetleg nem tudja a tevékenységét elég részletesen naplózni. Ebben az esetben be kell iktatni egy olyan köztes réteget, amely egyaránt ismeri a legacy és az agent működését, így mindkét irányba tudja menedzselni az elvárt biztonsági szintnek megfelelő kontrollokat.

Ez a köztes réteg lehet például egy szűrő – ezt hívjuk policy enforcement pointnak –, amely kikényszeríti a szabályokat. Ezt a szerepet jellemzően MCP (Model Context Protocol) gateway vagy API gateway tölti be. A gatewayek önmagukban nem biztonsági szűrők, de képesek ellenőrizni az identitást és a jogosultságokat. Emellett külön ki kell alakítani a műveleti korlátokat, azaz hogy az agent a jóváhagyott paramétereken belül hajtja-e végre az adott műveletet, és az engedélyezett adatokhoz akar-e hozzáférni.

Vannak olyan biztonsági megoldások, amelyek képesek egyben kezelni a hagyományos technológiákat és az AI-t?

W. O.: A gyártók többsége már igyekszik valamilyen módon integrálni a két területet megoldásaikban. A Zscaler például azt az utat választotta a Zero Trust Exchange-nél, hogy zero trust hozzáférési és adatvédelmi funkcióit kiterjesztette az AI-agentekre. A megoldás biztonsági gatewayként az MCP- és API-forgalmat monitorozza. A Palo Alto Networks más irányt követ. Prisma AIRS nevű megoldását API-n keresztül be lehet építeni az agentbe vagy az alkalmazásba, hogy futásidőben ellenőrizze a promptokat, az AI kimenetét, valamint felügyelje az adatáramlást.

Az agentic AI egyik első és máig legnépszerűbb felhasználási területe a szoftverfejlesztés. Ott milyen változásokat hozott a biztonsági szemléletben?

W. O.: A fejlesztéstámogató agenteknél is alap a hozzáférés-kezelés. De az elkészült kódot és az élesben futó alkalmazást is kontrollálni kell. Egy coding agentnek viszonylag nagy mozgástérre van szüksége, hiszen akkor tudja érdemben támogatni a fejlesztést, gyorsítani a szállítást, ha fájlokat módosíthat, kapcsolódhat külső rendszerekhez, felhasználhat open source csomagokat. Ezért különösen fontos, hogy pontosan lefektessük az agentek műveleti korlátait. De mivel ezzel még nem lehet kizárni minden kockázatot, védeni kell a fejlesztési környezetet is.

Továbbra sem hagyhatók el a hagyományos tesztelési módszerek. Bár az AI ma már közel olyan minőségű kódot állít elő, mint egy szenior fejlesztő, itt is igaz, hogy az agentek célorientáltak, azaz arra vannak optimalizálva, hogy működő kódot hozzanak létre. Ez azonban még nem jelenti azt, hogy a kódban nem lesznek sérülékenységek, vagy hogy stabil, megbízható lesz.

Statikus kódelemzéssel a saját kód biztonsági hibáit vizsgáljuk. A beemelt nyílt forráskódú komponensek ismert sérülékenységeit és licenckötelezettségeit szoftverösszetétel-elemzéssel ellenőrizzük. Ez a fázis egyébként elengedhetetlen, mivel ma már az alkalmazások kódjának 80 százaléka open source elemekből épül fel.

El kell végezni az ún. secret scanninget is – ezt magyarul titokvizsgálatnak vagy hitelesítőadat-keresésnek is nevezik –, amikor azt ellenőrizzük, hogy a kódban nem maradtak-e érzékeny adatok, például API-kulcsok, jelszavak, hozzáférési tokenek. És hát továbbra is nélkülözhetetlenek a funkcionális tesztek, amikor az alkalmazás helyes működését ellenőrizzük. A kontrollok akkor hatékonyak, ha beépülnek a CI/CD pipeline-ba, és ott automatikusan lefutnak, mert így nem kerül be ellenőrizetlen kód az alkalmazásokba.

Már vannak a piacon olyan "dobozos" termékek, amelyek valós időben felügyelik a kódgenerálás folyamatát. A Black Duck Signal a coding agentek munkafolyamatába integrálva elemzi a létrehozott vagy módosított kódot. A Black Duck ContextAI biztonsági tudására támaszkodva azonosítja a hibákat, és javítási javaslatokat ad, amelyeket a coding agent felhasználhat a kód javításához.

A magyar szervezetek mennyire készültek fel AI-biztonságból?

W. O.: Én egyet visszalépnék: néhány nagy szervezetet kivéve a cégek többségénél még az AI-használatot sem szabályozzák. Nincs központi AI-előfizetés, és nincs is előírás arra, hogy milyen modellt, melyik szolgáltatást lehet használni. Emiatt persze kontrollok sincsenek, viszont burjánzik a shadow AI, amely melegágya az adatszivárgásnak.

Mi kellene ahhoz, hogy javuljon a helyzet? Mit tanácsolna azoknak a szervezeteknek, melyek valamilyen AI-megoldás bevezetését tervezik?

W. O.: A fokozatosságot. Először az irányt kell meghatározni: on-premise megoldást vagy felhős szolgáltatást szeretnénk? Fel kell állítani egy AI-biztonsági keretrendszert, amely rögzíti az AI jogosultságait, az elérhető adatok körét, egy coding agent milyen kódbázisokból dolgozhat, hol futtathat valamit… Valamint ki kell alakítani a használat szabályait is.

Ha a környezetet körültekintően építjük fel, akkor elmondhatjuk, hogy biztonságosabban futtathatunk AI-agenteket, AI-funkciókat.