ZTNA, és ami a VPN után jön

AI fog támadni AI-t.

Míg a támadók igazából, amit nem szégyellnek, azt használják. Amit nem látunk, azt nem is tudjuk védeni.

Elsőként köszöntöm Dudás Mátét, a Checkpoint értékesítési mérnökét. Azután köszöntöm Balog Gábort, a Checkpoint kiemelt ügyfélkapcsolati menedzserét és végül Páli Pétert, aki a Control IT biztonsági megoldások értékesítője. Sokáig a vállalati biztonság az egy elég egyszerű alapokon álló dolog volt, van egy belső hálózat, azt körbeveszi egy tűzfal, és azon kívül meg kb. a vadnyugat volt. Mára ez nyilván egy kicsit bonyolultabb, a felhasználó otthon ül, az alkalmazás a felhőben fut, az adat egy böngésző fülön utazik, az MI ügynök az van otthon is, meg bent is, szinte mindenhol.

Na most vajon ilyenkor hol is van pontosan ez a fal?

Én azt gondolom, hogy nagyon elmosódtak a határok. Ha visszagondolunk talán a 2020-as évekre, ahol a Covid bejött, ott volt ugye ez a törés, amikor ezek a határok, én úgy gondolom, hogy elkezdtek elmosódni. Nem volt már meg ez a tradicionális, van egy belső hálózat, valaki bejön a céges irodába, ott feldugja a laptopját és onnan dolgozik, hanem megjelentek ezek a hibrid vagy távmunkában dolgozó kollégák is. És éppen ebből kifolyólag én azt gondolom, hogy ezek a határok már a mai napra nagyon nehezen definiálhatóak pontosan, hogy hol van még az a határmezsgye, ami még külső, de még nem belső, fordítva, tehát ezt nagyon nehéz definiálni. És alapvetően én úgy gondolom, hogy nem feltétlenül érdemes már csak külön külső és mondjuk belső hálózatról beszélni, hanem ezt egy nagy, ilyen hibrid munkavégzési környezetként kell tekinteni, és így erre rálátni.

Igen, csak annyi, hogy egyébként maga ezek a határok meg úgy is elmosódtak hogy most már ugye korábban még csak ilyen úgymond onprem meg belső hálózati környezeteket használtunk, most majd egyre többször, meg itt többen jelenik meg a klaudos megoldások, tehát ahol a klaudos környezetek is vannak, tehát a felhasználóknak nem csak kifejezetten a vállalati erőforrások belső hálózatát kell elérniük, hanem adott esetben egy külső részt is. Tehát az például lehet ilyen szempontból egy klaudos környezet is. Tehát ilyen szempontból a hatás.

Igen, és már saját környezeti felhő részen van, tehát akár egy inas környezet, tehát ez teljesen igazából már szeparált rész, de mégis ugyanúgy egy egységként tekinthető.

De azt mondjuk mindig tudnom kell, hogy egy adott tranzakciót vagy utasítást a felhasználó éppen hol csinál ezeken a különböző területeken belül?

Én azt gondolom, hogy célszerű ezt tudni, mert visszautalva kicsit a legutóbbi beszélgetésünkre, amit nem látunk, azt nem is tudjuk védeni.

Nézzük akkor meg ezt felhasználói szemmel, ugye különösen a felhőinfrastruktúrák óta tulajdonképpen a felhasználó mondhatnám azt is, hogy egy alkalmazást használ reggeltől estig a böngészőjét, és hát erről nagyon keveset beszélünk az e-mail meg a hálózati eszközök mellett. Hová sorolnátok a belső, külső tengelyen ezt a szoftvert, hogy böngésző, meg mi a különbség mondjuk egy hagyományos, egyszerű otthoni vagy akár mobilos böngésző, meg egy vállalati környezetben futtatott böngésző között, és van-e esetleg, ami többletlehetőség, vagy hatékonyabbá teszi a védekezést azért, mert építhetek mondjuk a böngésző funkcióimra.

Igen, én ezt én pont onnan fognám meg, hogy szerintem az első érdekes felismerés, amit te is említettél, hogy a böngésző a checpoint nézetéből nézve már nem is egy alkalmazás, hanem hanem konkrétan már maga a munkahely, hiszen a kolléga, ahogy kinyitja ugye a laptopot, onnan ér el különböző felhős alkalmazásokat, generatív AI alkalmazásokat onnan tud használni akár egy webes e-mailt, CRM-et, bármilyen domainen keresztül onnan tud elérni és és szerintem ugye a fő probléma hogy hogy ugye a browsert vagy te is mondod, egy külön alkalmazásként kezelik a vállalatok, és azon a tengelyen, hogy belső külső, én inkább pont azt mondanám, hogy a határvonalra tenném a browsernek a védelmét ebből fakadóan, hiszen onnan tud különböző megoldásokat elérni, és ugye ott az adott munkahelyen tudjuk védeni a munkavállalónak az adott tevékenységét.

Én itt ehhez annyit tennék hozzá, hogy alapvetően én ezt úgy látom, hogy azt is külön kell választani, hogy milyen böngészőről beszélünk, mert hogyha mondjuk van egy vállalat által definiált és kontrollált böngésző, az egy teljesen másik téma, mint hogyha én kinyitom otthon a laptopomat és bármelyik böngészőt használom. Tehát alapvetően, hogyha egy sima böngészőt használunk, ami felett nincs a vállalatnak kontrollja, akkor értelemszerűen nagyon nehezen tudjuk megvédeni. Ezért azt tudom így, ha lehet ilyen javaslattal élni, hogy egy olyan megoldást válasszunk, amivel szintén kontrollálni is tudjuk azt, hogy mit csinál a felhasználó, hogyan csinálja, és ezt böngésző szinten tudjuk megtenni.

Péter, ez a tapasztalat, hogy az ügyfelek mondjuk ilyen standard alkalmazásként tekintenek a böngészőre, és nem veszik figyelembe, hogy mi minden más alkalmazást használnak ebben a felhasználók. Ez a ti ügyfélkörötökben is hasonló tapasztalat?

Igen, egyébként ez megvan nálunk is, tehát illetve az ügyfeleknél ez jelentős szerepet tölt be az, hogy akár az otthoni felhasználás, illetve akár a céges felhasználás és a böngésző által azok hogy működnek, viszont majd pont egyébként ezzel kapcsolódik maga a checpointnak azon megoldása amit egyébként pont beszélünk itt a böngésző során hogy akár egy egy egy szasziba egy interneteshez moduljába hogy adott esetben ő már alapértelmezetten használja ezt a cloudbase proxy irányt, akkor igazából már az otthoni munkavégzés, tehát amikor hazaviszi a céges mondjuk notebookot, eszközt, stb, akkor automatikusan ebbe a felhőbe konnektál be maga a felhasználó, és ebbe a felhőbe már meg fog történni azok a szűrések, mintha már bent ülne ugyanúgy egyébként bent a belső hálózatban, a vállalaton belül, és akkor a belső infrastruktúrát, a vállalati infrastruktúrát használná.

Itt még egy kanyart hadd tegyek, mielőtt továbbmegyünk ebbe az otthoni munkavégzés és a VPN-nel a vállalati környezet, hogy arról elég kevés helyen hallok, hogy egyfelől nagyon sok alkalmazásnak tűnő valami a gépemen, az valójában böngésző. Tehát, hogy nekem úgy tűnik, mintha letelepítenék egy appot, de ő valójában egy ugyanolyan kromium alapú, vagy valamilyen akár Edge alapú böngészőt futtat magában, hogy ezt észlelik-e a vállalatok, meg tudják-e, hogy akkor azt is, azt az alkalmazást is úgy kéne védeni, mint egy böngészőt. És van-e ennek olyan tapasztalata itthon, hogy esetleg a mi cégeink fejlesztenének ilyen letelepíthető böngészőket, amik annak tűnnek, és ezért ők mondjuk úgy is építik ki annak az alkalmazásnak a biztonsági funkcióit.

Ez ilyen nüansznyi kérdés, de ilyenekről szeretünk itt beszélgetni.

Igen, igen. Én azt tudnám erre reflektálni, hogy kicsit a hátáról fogjam meg magát a kérdést. Nagyon jó példa, hogy a checkpoint is épít egy saját olyan böngészőt, ami szintén kromium alapú, és igazándiból abban már, ahogy itt a többiek említették, benne van maga a biztonsági layer is. Tehát abszolút vannak már ilyen megoldások a piacon, és erre mindenképp fókuszálni kell, mert ugye ha védhetjük a vállalati hálózatunkat, védhetünk bármit, mindig ott lesz a végén az end user, aki nyomkodja a számítógépét, és mindig ő lesz a lenge gém láncszem. És hogyha nekifókuszálunk arra, hogy kontrolláljuk és őt is védjük, akkor szerintem abszolút sikereket tudunk elérni a védelem szempontjából.

Nézzünk rá egy percre a számokra is. A checkpoint anyagában két erős számot is találtam. Az egyik, hogy 60%-os költségcsökkenés, a másik, hogy akár 10-szer gyorsabb böngészés. Péter, a gyakorlat visszaigazolja ezeket a számokat, illetve ti mihez viszonyítotok, vagy egy ilyen gyártói prezentációt a másikhoz képest hogyan értékeltek, hogy mi az, ami mondjuk fél évvel később is tényleg megmarad, vagy nagyon könnyű hozzászokni is mondjuk az ilyen jóságokhoz.

Ez a költségcsökkentés egyébként ez megmarad, mármint hogy igazából beteljesül.

Főleg egyébként abban az esetben, hogy egyre jobban ezek a határok ugye elmosódnak, ugye otthoni felhasználás igazából az, hogy ez a környezeti beszűkítés ez eltűnik így a felhasználók számára, és ugye el kell kezdeni minél jobban igazából a klaudos környezeteket használni, az adott belső hálózati vagy vállalati eszközöknek az infrastruktúrában az utilizációja sokkal jobban úgymond így csökken, tehát kevesebb vagy kisebb olyan eszközöket kell úgymond vásárolni, akár fejlesztés szempontjából, itt gondolok akár egy tűzfalra, annak az áteresztő képességeinek úgymond így kisebbnek kell lenni, hisz mondjuk a felhasználók nem alapértelmezetten, amikor otthon ülnek és VPN-en keresztül bemennek úgymond a belső hálózatra, és azon keresztül érik el az internetet.

Nagyon sok esetben ez egy ilyen tradicionális, úgymond ilyen VPN elérés, ez még mindig így működik egyébként a magyar vállalatoknál, hanem igazából ezt a részt ki tudjuk váltani egy ilyen szaszi megoldásra, tehát amikor a cloudbased megoldást használjuk a checkpointnál is, kihagyva magát a belső hálózati úgymond útvonalat, és egyből be tudunk konnektálni a felhőbe, ahol azokat biztonsági funkciók, akár egy tartalomszűrés, antivírus funkciók, ezek ugyanúgy rendelkezésre állnak így a felhasználók számára, minthogyha ezt mondjuk ezt a belső hálózaton keresztül a belső infrastruktúrát, a belső erőforrásokat használná a felhasználó.

Ha jól értem, és ezt most akkor egy kicsit fejtegessük még, mert sok idegen kifejezés is elhangzott, hogy itt most különösen azok a vállalatok figyeljenek, akinek viszonylag sok otthoni munkavégző kollégája van, mert hogy ott merül fel ez, hogy vajon milyen gyorsan tudom én ezeket az oda-vissza adatcsomagokat küldözgetni a vállalati hálózat, a kubikus internet, az intranet, meg a laptopom között. És ugye ez a Saci, ez a Sequery Access Service Edge, ez nálunk is téma volt itt már a csatornán többször. Az elmúlt két évben foglalkoztunk vele. Ez egy olyan modell, amennyire én megértettem, hogy a hálózat és a biztonsági funkciók így egyetlen felhőszolgáltatás csomagban épülnek össze. Ez egy ilyen paradigmaváltás, és arra nagyon kíváncsi lennék, hogy hát most már tényleg két éve mondjuk ezt itthon is, vajon mennyiben ment ez végbe a szervezeteknél, illetve ahol nem ment végbe, hogy van-e olyan terület, ahol megmaradt a hagyományos telepített védelem, ott vajon miért maradt meg, és nekik mit javasoltok?

Én azt gondolom, hogy lesz talán egy olyan terület, ahol ez, én úgy gondolom, hogy sosem fog változni, és még mindig, amíg világ a világ ez lesz, ez pedig az ipari OT terület.

Mert egy olyan cégnél, ahol nem tudom, kritikus infrastruktúrában dolgoznak, nem feltétlenül a munkavállalók, hanem maga a termelés igazából, vagy az irányítás, stb. ugye úgy megy, ott én nem tartom jelen állás szerint elképzelhetőnek, hogy valamit kicsatornázunk a felhőbe.

Illetve ha mégis megtesszük, akkor úgy járunk, mint a francia hűtőszolgáltató.

Igen.

Úgyhogy ezt tényleg nem tanácsolnám.

Igen, a fejlettségi szinttel kapcsolatban majd itt Péter is az ő álláspontját elmondja integrátori oldalról. Én gyártói oldalról nagyon azt látom, hogy még nincs ez a legtöbb magyar vállalatnál bevezetve, nem történt meg ez a paradigmaváltás. Lassan, szépen, biztos léptekkel, hamarosan én úgy gondolom, hogy el fogunk jutni ide. Ez, ami gyártói oldalról átjön, de Péter, mi az, ami integrátori oldalról látszik?

Ez hasonlóan látszódik egyébként, hisz maga a piacon azért az a tradicionális, akár VPN, meg egyéb ilyen infrastruktúra, ami a távoli hozzáférés biztosítja. Ezek az infrastruktúrák azért még így úgymond ilyen röghöz kötöttek, és még így megvannak még így a régi berögzültségek, hogy akkor milyen az adott esetben milyen ilyen rimótesszes ilyen iskolákat alapvetően kell majd vagy kell még követni de én azt látom hogy itt a az az elmosódott határokból adódóan tehát maga ez az egész ztn a megjelenés.

Azt kifejtenéd légy szíves, hogy mit rövidít?

Igen, tehát maga az ETNA, tehát a zero trust networkesses úgymond kifejezés, tehát hogy amikor igazából nem bízunk semmilyen szempontból a felhasználóba, hanem alapértelmezetten mindig autentikálni, autorizálni kell magát a felhasználó önmagát, és bizonyos ezekhez a felhasználókhoz társított szabályoknak, szabályzóknak megfelelően tudja csak azokat a bizonyos erőforrásokat elérni, ami hozzá mondjuk kapcsolódik. Akár ez egy csoporttagság, akár pedig ez egy kifejezetten dedikált felhasználóhoz van mondjuk hozzárendelve.

De ez az elv, ha jól értem, ez még a régi paradigmába is behegeszthető.

Ez a régiben is benne van, ezeket így hívják ilyen profilozásra alapon, de itt igazából magán a ZTE-nál már sokkal több szerteágazó környezeti eléréseket is úgymond lehet belebiztosítani akár egy belső hálózati elérés, akár egy egy claudos, tehát amikor saját környezetünk van, és azoknak az elérését akarjuk úgymond biztosítani a felhasználók számára, vagy akár olyan szolgáltatások, amik amiket igazából a vállalat használ, és ezek egy alapértelmezetten felhős szolgáltatások. Gondolok akár itt egy Microsoftnak igazából itt egy share point, az is egy egy felhőszolgáltatás, azok is igazából ezen a felhőn úgymond tudnak keresztülmenni.

Itt is ezek az alapelvek, ami az ETA-ban szükséges, azok ugyanúgy egyébként szükségesek, hogy a felhasználónak biztosítva legyenek.

Na most egyre többen használnak egyre intenzívebben mindenféle AI funkciót, meg akár több tucat AI alkalmazást, hogyha nagyobb vállalatról beszélgetünk, amik szintén mint hálózati forgalom alapon tudnak működni. Egy ilyen hálózati biztonsági felhőszolgáltatás, tehát ez a szaszi világ, ez jelent-e bármilyen előnyt, ami akár a napi munkát megkönnyíti ezeknek a kollégáknak, akik otthonról, bárhonnan, az ügyféltől akár el kell, hogy érjék az AI szolgáltatásokat.

Én erre talán azt mondanám, hogy sok előnye lehet, viszont ahhoz, hogy ezeket az előnyöket ki tudjuk aknázni, illetve ki tudjuk használni, ehhez tényleg egy szemléletváltásra van szükség. Mert ha belegondolunk ebbe, van egy darab belépési pontunk a hálózatba, az mondjuk egy IP cím, ami ki van publikálva, és akkor azon keresztül kvázi VPN-nel tudnak kapcsolódni a felhasználók. Ez egy teljes szemléletmódváltást igényel. Viszont hogyha ezt a szemléletváltást sikeresen adoptáljuk és megtörténik a vállalatnál, akkor például egy hibrid működés is elindulhat. Mit értek ez alatt? Hogy lehet azt biztosítani a felhasználók számára, hogy igazából a világ bármely pontjáról tudjanak kapcsolódni. Ugye ezek a, mondjuk úgy, hogy SASE adatközpontok, ahová a felhasználók csatlakoznak, ezek bárhol lehetnek a világban.

Tehát ha mondjuk elutazik akár Európán kívül egy munkavállaló, akkor nem az van, hogy neki mindenféle hosszú utakat kell bejárni ahhoz, hogy hazataláljon az ő forgalma, hanem akár ott helyben tud csatlakozni, és ennek nyilván az az előnye, hogy sokkal gyorsabb kapcsolódást tesz lehetővé, illetve sokkal kisebb válaszidő van benne így a rendszerben. Alapvetően azok mellett, hogy beszélünk adatközpontokról, illetve felhasználókról. Érdemes megemlíteni a különböző ilyen brents office, ilyen vidéki telephely, vidéki irodás környezeteket, mert magába ebbe a teljes hálózati architektúrába, ebbe a full mensbe igazából azok is beköthetőek. És így igazából bárki kapcsolódhat bárkihez úgy, hogy nem kell feltétlenül a központon keresztül járnia ennek az adott forgalomnak, és így ezeket a válaszidőket, illetve kapcsolódási időket is tudjuk rövidíteni.

Nevetni fogtok, de nekem ez azt juttatja eszembe, hogy a nagykövetségi rendszerek, aztán a konzuli rendszerek kiépültek a világban, hogy ne kelljen már hazamennem azokért a papírokért, vagy a postát megverni, hanem ott van helyben egy kis Magyarország, nem tudom, Szöul közepén, és akkor el tudom intézni. Most ugyanez egy kicsit így a bitek világából. Péter, te integrátori oldalról látod ezeket a dolgokat, ami azért egy terepmunka, tehát hogy ott már mindenképpen harapófogóban vagy, mert egyrészt a gyártói sztenderdek szerint kell végezd a munkádat, másrészt viszont az ügyfél fizet, és annak a megoldásnak tudnia kell azt, amit az ügyfél elvár. És vajon mennyire könnyű olyan ügyfeleket találni, aki meg tudja mondani azt, hogy neki hány fióktelepen milyen adatforgalma van, hogy az ő alkalmazásához hogy férnek hozzá a külső partnerek, hányféle partner, hányféle eszközön, merthogy a home office oké, azt most már megoldottuk, meg hát muszáj volt már évekkel ezelőtt, de hogy itt messze többről is van szó.

Ez igazából szerintem az látszódik az ügyfeleknél és egyre jobban, hogy folyamatosan tudják egyébként ezeket jobban definiálni, akár itt a külsősöket tekintjük mondjuk, vagy nézzük igazából, őnekik sokkal egyszerűbben tudják definiálni azt, hogy adott esetben milyen alkalmazást tudnának elérni. Tehát például vegyünk mondjuk egy fejlesztőt, aki az adott ügyfélnél mondjuk fejleszt valamit, ott például külön meg tudjuk azt csinálni akár a checkpointnak a Society Private Assess megoldásával, hogy bizonyos hálózati szegmenst tudja elérni, ami neki egyébként így a munkájához szükséges, vagy meg tudjuk azt is csinálni, kipublikálva csak egy adott alkalmazást, akár ez egy webes felületen, akár legyen ez egy SSH-s konzolos elérés, hogy azokat csak kizárólag csak azok az alkalmazások úgymond jelenjenek meg a felhasználónál.

És amikor a külsős felhasználónak ennél egy sokkal granulárisabb elérést kell biztosítani, akkor nem ezzel az egész nagy hálózati tömbbel van úgymond így összeköttetésben, hanem egy sokkal szűkebb részen, amiben ebben a szűkebb részben egy ilyen Wyergard úgymond egy ilyen hostot, virtuál hostot telepítve ő bekonnektál ugyanúgy egyébként magába a szaszi felhőbe, és egy ilyen nagyon szűkebb, zártabb rétegű elérést tud biztosítani azoknak a felhasználóknak, azoknak a külsős felhasználóknak, ahol mondjuk valami lehet, hogy van olyan érzékeny adatokat, vagy egy nagyon olyan specifikus dolgot kell elérni, amire lehet, hogy nem biztos, hogy az egész úgymond környezetet biztosítanák így a külsősnek.

Mondtok erre egy példát, hogy ez milyen ügyfél élethelyzetre ad megoldást?

Én ezt úgy fejteném ki, hogy eddig a hagyományos VPN azt mondta, hogy oké, autentikáltalak, bejöhetsz a hálózatomba, és azon belül azt csinálsz, amit szeretnél, mondjuk egy profilozás nélkül. Ugye ez a szaszi esetében mondjuk egy külső alkalmazásfejlesztőnél mondjuk úgy néz ki, és akkor még ide sorolnám azt is, hogy akár egy ilyen bring your one device, tehát ugye saját platformú eszköz, amit te szeretsz dolgozni, a Szaszi lehetőséget ad arra, hogy neki azt mondjuk, hogy akkor te csak ezt vagy ezt az adott alkalmazást érheted el azzal a megfelelő eszközzel amit én autentikáltam és milyen ügyfélnél de hát ez érdekes mondjuk a bank az egy egzakt példa, van-e esetleg más, vagy mondjuk KKV-ban, akár nem tudom, egy kutatóintézet teszem azt, ahol ugye nagyon érzékeny adatok lehetnek, vagy egy közhivatal, tehát hogy ilyen példákra gondolok.

Én ezt onnan fognám meg, hogy ha azt nézzük, hogy van egy tényleg egy nagy banki vagy akár kutatószektorban dolgozó cég, és annak a cégnek van egy 10 millió IP címből álló tartománya. Ott, ha egy felhasználó elszabadul, mert mondjuk a számítógépén korábban volt valami malware, valahogy ez bekerül a hálózatba. Hiába alkalmazunk már ott bizonyos falakat, most legyen az tűzfal vagy egyéb fajta kontrollok, nem feltétlenül tudjuk olyan hatékonysággal őt megállítani, mintha már be sem engedjük. Tehát azt mondjuk, hogy ő csak és kizárólag az általa használt dedikált alkalmazáshoz, valamilyen IP címen futó szolgáltatáshoz fér hozzá, és nem bent a tűzfalszinten kontrolláljuk, hanem eleve magát a kapcsolódási pontot is oda tesszük be, ahol a legközelebb van ahhoz a rendszerhez mondjuk, amit el szeretne érni, és abból a környezetből sokkal nehezebben tud kijutni, ha ez izolálva van, mintha a nagyból leveszünk valamekkora részt, amihez ő hozzáférhet.

Elérkeztünk a félidőhöz, és most már tudom, hogy ti is tudjátok, hogy itt mi a szokás, mert hallgattatok már Digit Podcast adást, ilyenkor megpihenünk a szakmával, és egy kicsit az emberi oldalunkat vesszük elő. Nem tudom, hogy hallottátok-e már azt a kifejezést, hogy rigolyás a mi családi nyelvhasználatunkban ez még benne volt. És engem most ez fogott meg valamiért, az érdekelne, hogy vannak olyan szokásaitok, amihez nagyon ragaszkodtok, ami egy kicsit ilyen merevebb dolog az életetekben, honnan jön ez, mit jelent számotokra, vagy volt ilyen, és le akartatok róla szokni, sikerült, ilyesmi sztorik érdekelnek.

Én akkor elkezdeném a sort.

Én ezt nem feltétlenül teljesen rigolyának nevezném, hanem inkább egy alapvető elvárásnak, de én például nagyon ilyen tüchtig gyerek vagyok, ami azt takarja, hogy ami kész kell, hogy legyen időben, az kész kell, hogy legyen, nem az utolsó pillanatra hagyom, el van mosogatva, amikor eljövök otthonról, viszonylag egy olyan állapotban hagyom mondjuk a lakást vagy házat, amibe szeretnék mondjuk hazatérni, és ha mondjuk hirtelen vendégek megjelennek, akkor sem okoz problémát. Tehát én ezt nevezném ilyen saját rigolyámnak talán.

Nekem ilyenek nincsenek, tehát én biztos, hogy úgy hagyok mindent. Tehát, hogy nekem ez így máshogy működik. Viszont én ezen gondolkodom, és pont igazából nekem ilyen nagyon személyes rigolyáim igazából így nincsenek. Inkább úgy tudom megfogalmazni, hogy nehezen viselem inkább azt, hogyha valami nem úgy történik, ahogy én azt elképzelem. Tehát nekem inkább ilyen van, de ez nem kifejezetten rigolya.

Hát általában nem szeretjük azt mondani magunkra, hogy rigolyásak vagyunk, még ha egyébként.

Kevesebb, de nehezen vallja be bárki, hogy rigolyás.

Gábor?

Igen.

Hát ő meg így ugye a kollégák után nagyjából én a kettőnek az egyvelegét tudom így magamból felfedezni, amit itt Máté és Péter is említett, hogy igen, én is ilyen szempontból elég tüchtig vagyok, hogy annak, amit például ezt a feleségem tudna nagyon jól visszaigazolni, hogy amit én letettem, annak ott van a helye, hisz akkor tudom, hogy az a leggyorsabb, legrövidebb út a leggyorsabban elérhető módja, hogy ezt én meg is találjam, és ugyanez, amit Péter mond, hogy nekem is azért néha, ezt ki merem mondani hangosan, tehát tudom, hogy probléma, csak még a kezelését nem találtam meg, hogy ha én így fejben összerakok valamit, hogy hogy jutok el A-ból B-be, akkor ott nem szeretem, hogyha valami változó, az beesik kívülről.

Ehhez nagyon tudok kapcsolódni egyébként. Én is, ha elterveztünk valamit, akkor nagyon nehezen értem meg, hogyha most hirtelen kitaláljuk egy órával azelőtt, hogy nem úgy lesz, az nekem nehéz. Ez se biztos, hogy rigolya. Meg a másik, hogy azt én se szeretem, amikor otthagyok valamit, hogy egy óra múlva megiszom azt a fél pohár vizet, azt nem találom sehol. És akkor úgy nem értem, hogy miért kell a másik cuccát elrakni. Na most hát azért ahogy telnek az évek, szinte megtanuljuk magunkról, hogy nem ez a világvége, attól még fontos nekünk, de hát hogyha nem úgy van, hát most akkor valószínűleg értékeljük át egy kicsit, de azt viszont nagyon fontosnak tartom, hogy merjünk ezekről beszélgetni, hogy hát nekem ez, neked az, honnan jön, miért fontos az, és talán az az érdekes benne, hogy miért, hogy te miért szereted, hogy ott tüktig legyen, mert az viszont tényleg rólad szól, az nem egy rossz szokás.

Jó, ugorjunk vissza a szakmába, és emízzünk még, mert egyszerűen annyi izgalmas téma van, hogy muszáj. Máténál a dugusztusban az árnyék említ, azt kiveséztük, hogy a kolléga a saját szakállára használ valami publikus, vagy legalábbis nem a vállalat által biztosított szolgáltatást. Mi történik a háttérben, a biztonsági rendszerekben, abban a pillanatban, amikor mondjuk valaki bemásol egy frontba egy vállalati adatbázist vagy dokumentumot, vagy egy olyan adatot ad meg, ami láthatóan nem való oda. Ezt most direkt próbálom én nagyon általánosan megfogalmazni. Tehát, hogy mennyire tudjuk ezt ma már észlelni, mert ez azért sok cégvezető fejében egy piros lámpa, hogy hoppá, hát én nem is tudom, hogy mit használ a kolléga, vagy mit másol be a kolléga.

Illetve mi a jó gyakorlat ilyenkor, hogy ezt így mind le kell blokkolni, és akkor nem tudom, még jól egy ilyen valami eljárást is indítsunk a kolléga ellen, vagy pedig valami edukációt kell itt biztosítani, vagy legalábbis valamilyen mértékig lehet-e ezt engedélyezni.

Mi történik kérdésre? Egy sajnálatos választ kell, hogy adjak, mert a legtöbb esetben még semmi. Hogy ez miért sajnálatos? A legtöbb cégnél nincs meg az érettség még erre, hogy ezt valamilyen szinten figyeljük.

Főleg így a múltkori beszélgetésünkre visszautalva a mesterséges intelligencia világában. Sok cég ugye alkalmaz már különböző ilyen DLP jellegű szűréseket, tehát az micsoda?

A Data Los Prevention, ami talán konyhanyelven úgy tudnám ezt megfogni, hogy szeretnénk megakadályozni azt, hogy érzékeny adatok kikerüljenek. És ez adatszivárgás megelőzés.

Aha, tehát ez nem az, hogy elvesztem az adatot, mint a svéd tévécsatorna, hogy egy sorozat eltűnik, hanem ez az, hogy kikerül.

Hát érzékeny adat kerül ki olyan illetéktelen kézbe, ahova nem kellene például.

Igen, és ezzel, tehát a legtöbb cég azért dolgozik. Tehát látjuk azt, hogy ők ezt kontrollálják. Viszont ha meg a másik oldalt nézem, ez a kontroll sokszor nem feltétlenül elegendő, mert régebbi, elavult rendszerek dolgoznak, olyan kulcsszó alapú szűrés történik, ami miatt átcsúszhatnak ezen a rostán bizonyos adatok, viszont ezekkel mind az MI világában, mind pedig a nem MI világában minél jobban foglalkoznunk kell. Az, hogy ebben a témában mi a best practice, mi ez a legjobb hozzáállás. Én azt mondom, ahogy korábban is említettem, hogy engedni szükséges, de a megfelelő kontrollok mellett. Mert a teljes blokkolásból felhasználói elégedetlenség lesz, és ez nemcsak az MI generatív jellegű MI használatnál, hanem egyéb területeken is megvan.

Ilyenkor szoktuk még mondani, tehát azon belül, hogy a kontroll az megvan, tehát hogy jobban kontrolláljuk, ugye ezáltal inkább a vizibilitás inkább legyen meg, tehát hogy sokkal nagyobb rálátásunk legyen arra, hogy az adott felhasználó az milyen műveleteket hajt végre. Ebből adódik, hogy nyilván, amit van vizibilitásunk, sokkal jobban tudunk kontrollokat kifejteni.

Mi az ügyféligény itt, vagy mi az, amit nektek föl szoktak hozni egy-egy ilyen tárgyaláson, vagy akár konferencia-előadás utáni kávészünetben, hogy mi nyomasztja most a cégeket ezen a téren. Tehát azon a téren, hogy nem csak az árnyék, de akár a publikus MI szolgáltatásoknál is vajon a felhasználó mi mindent tesz abba a programba bele, azt vajon tudjuk-e bent tartani, hogy ne kerüljön mondjuk az MI szolgáltatónál tréningre, mármint a rendszer tanítására és így tovább.

Kettő felé választanám ezt a dolgot. Az egyik az érettebb ügyfelek, az érettebb ügyfeleknél általában az merül fel, hogy van valami, elindultak valami stratégiai úton, valami stratégiát már elkezdtek építeni, de elakadtak egy bizonyos ponton, mert nincsenek olyan eszközök a kezükben, amivel teljes egészében azt a kigondolt stratégiát végig tudnák vinni. Természetesen ugye mi ebben tudunk segíteni, mert egy komplett stratégiát az ügyfél mellé tudunk tenni, és azt tudjuk mondani, hogy amennyiben mondjuk a mesterséges intelligenciát szeretnéd szűrni, akkor van erre egy megoldásunk. Ha alapvető ilyen tradicionális DLP funkcionalitásokat szeretnél megvalósítani, arra is van megoldásunk, tehát tudjuk fogni az ügyfélnek a kezét.

Ugyanúgy tudjuk fogni az ügyfél kezét a kevésbé érettebb ügyfeleknél, ahol még csak fel sem merült ez a gondolat, hogy ezzel foglalkozni kellene. Ott pedig tudjuk őket edukálni, akár a teljes vállalatot, akár a döntéshozókat, akár a végfelhasználókat annak érdekében, hogy sokkal tudatosabbak használják, és hogy nyilván felhasználói oldalról, és a belsős szabályozói oldalról pedig, hogy segítsünk nekik abban, hogy a megfelelő stratégiát ki tudják alakítani akár tényleg a nulláról, és ebben azok mellett, hogy én most gyártói székből beszélek, emellett természetesen az integrátori oldalról akár a mi megoldásainkkal tudnak segíteni a szakemberek.

Igazából ennek a fejlődését látjuk mi is egyébként magát az integrátori oldalról, tehát hogy az ügyfeleknek ez az igen, úgymond ilyen evolúciója, tehát folyamatos fejlettségi szintje az egyre magasabb, akár úgy azért, mert a szolgáltatásaikat már egyre jobban már az AI köré építik, ezáltal a biztonsági, úgymond ehhez kapcsolódó biztonsági szolgáltatásokat a felhasználói tudatosságnak úgymond az emelése igazából egy kitettségünk van annak, hogy sokkal nagyobb rálátás legyen, és ezáltal egy jobban kontrollálható környezetet lehessen építeni.

Itt a kontroll kapcsán megint tennék egy kanyart. Eszembe jutott, gondolkozni szoktam ezen időnként, hogy mit jelent a vándorlókén, vagyis a szállítófüggés ebben a világban. Mert hogyha onnan nézem, hogy amiről az első félidőben beszélgettünk, van egy felhőbiztonsági szolgáltató központ, amit egy partnertől, legyen az például a checkpoint megveszek, és folyamatosan használom, üzemeltetik nekem, akkor tulajdonképpen elég erős ez a szárítófüggés. Amit a checkpoint tud, azt tudom én is biztonságban kapni, és valószínűleg nem is olyan könnyű aztán ebből kilépni vagy továbblépni vagy megosztani. Másfelől viszont ez egy óriási előny is, hiszen nyilván ez egy integrált működés, költségcsökkentést leginkább itt tudok elérni, illetve ösztönzi abszolút a szállítóoldali innovációt is, hogyha ilyen erősen magas a bizalom felém, mint szállító felé.

Tehát egyrészt ez érdekelne, hogy hogy látjátok általában a szállítófüggést, hány ilyen nagyon széles szolgáltatást nyújtó szállítóval érdemes egy nagyvállalatnak dolgozni, másfelől meg akár az Aerotrus oldaláról nem megy el egy picit szembe ez a logika, hogy de hát én a szállítóban megbízom, akkor a többiekben is megbízhatnék ennyi erővel. Most túlzás nyilván, amit mondok, de szokott foglalkoztatni.

Egyre jobban egyébként az elfogadott ez a úgymond az, hogy egy gyártótól vagy van úgymond így az adott megoldás biztosítva, hisz maga az architektúra is így tud működni igazából, így lehet leginkább kifejteni úgymond a hatását, és így leginkább biztonságos, de hogy magát ezekhez sokkal jobban lehet integrálni egyéb úgymond ilyen szőrparti megoldásokat, tehát egyéb más gyártóknak a biztonsági megoldásait, vagy akár olyan szolgáltatásokat, amik akár mondjuk egy monitoring rendszer, akár egy végpontvédelem, bármi olyan rész ezekhez hozzá integrálható, mint egy nagy ökoszisztéma úgymond, amivel igazából ez az egy vendortól való függés igazából azért szertefoszlik mert igazából max csak ez az architektúra épül fel magából egy vendorból, de maga a teljes környezet, ami a vállalati infrastruktúrában van, az egy integrálható és egyre jobban integrálhatóbb környezetté tud majd igazából így válni.

Ha a checkpointos szemszögből nézem, és innen próbálom ezt megfogni, mi nem vagyunk a vándorlók én híve. Nyilván azt nem tudom megmondani, hogy akár egy sose vagy egyéb terméknek nem tudom a motorját most kicserélem egy kompetitív gyártónak a motorjára, vagy bármilyen más komponenst kicserélek, de ahol lehet, mi ezt az Open Garden szemléletmódot alkalmazzuk, tehát amennyire csak tudunk, próbálunk összeintegrálódni más gyártókkal. Például, hogyha az előző sas-e vagy ZTN-es példát vesszük alapul, ott is, ahogy ugye Péter említette, nem várjuk el azt, hogy mondjuk a vállalati hálózat középpontjában mondjuk egy checkpointos tűzfal legyen, hanem kvázi bármelyik tűzfallal össze tudunk integrálódni, ugyanígy különböző saját és egyéb fejlesztésű incidens kezelési rendszerben, tehát automatizálásban is több gyártóval dolgozunk együtt, mert nyilván látszik az, hogy nem feltétlenül tud teljes egészében egy homogén rendszer úgy működni, hogy mondjuk egy meglévő felhasználói bázissal rendelkező óriáscéghez nem tud az ember odamenni, hogy oké, rendben, akkor most az egész infrastruktúrát cseréljük le.

Nyilván zöldmezős beruházásoknál, kisebb cégeknél ez még tud jobban működni, de én úgy gondolom, hogy Vendor Lokin szempontjából cégmérettől függ az, hogy mennyivel kell, hogy együtt dolgozzanak, de én úgy gondolom, hogy pont ez az előnye akár a mi megoldásainknak, hogy mi nem a hátunkat mutatjuk a többi gyártónak, hanem azt, hogy akkor lehet hozzánk csatlakozni.

Mostanában mindenkitől megkérdezem, hogy így a mesterséges intelligencia mindkét oldalon ott van, tehát a támadók is, meg a védekezők is aktívan használják és egyre széleskörűbben, meg egyre többféle motort. Ettől összességében egyszerűbb lesz a biztonság, de ugyanakkor bonyolítja is ezt a helyzetet, hogy egy ilyen nem determinisztikus dolog kerül be a folyamatokba, hogy az AI-nak ez az egyik tulajdonsága, hogy azért nem fekete-fehér, hogy akkor most mindig ugyanaz a kimenet. Mit gondoltok, hogy melyik oldal tud most aktuálisan így 2026-ban jobban élni ezekkel az AI adta lehetőségekkel, remélem, hogy a védekező oldal, illetve mondjuk befolyásolja azt itt nálunk az EU-ban, hogy itt van egy AI-act.

Ez például most konkrétan gyengíti-e a védekező oldalt bármilyen mértékben.

Véleményem szerint ez egy nagyon érdekes paradoxon, mert ahogy említetted, és ugye mind a védekező fél kezében ott van az AI adta lehetőségek, ugye itt gondolok például arra, hogy az AI-jal az üzemeltetési vagy a szekuritis kollégák nagyon gyorsan tudnak reagálni, nagyon rövid időn belül tudnak nagy mennyiségű adatot feldolgozni, és ezáltal gyorsabb reakciót adni a különböző támadásokra, viszont ugye támadói oldalon is ott van az AI-nak az összes tárháza és lehetősége, ami pedig ugye abban támogatja a támadókat, hogy nekik az a feladatuk, hogy csak egy belépési pontot találjanak akár az adott felhasználónál vagy az adott cégnél, és ebből fakadóan én úgy látom, hogy ugye ez inkább egy verseny jelen pillanatban, és nincs olyan, hogy ki a gyorsabb, vagyis hát pont úgy fogalmaznám meg, hogy ebben az fog dönteni, hogy ki használja ügyesebben, hogy kinél van gyorsabb AI kapacitás, AI lehetőség, és hogy a humán kontroll mögötte milyen, és ugye az AIAC pont ugye ilyen szempontból erre ad választ, hiszen ugye az EU-AIACT bevezetésével ugye arra kapunk válaszokat, hogy ki akár kutatócentrumok milyen jellegű AI-okkal dolgozhatnak, ott azon belül milyen erőforrásokat használhatják fel, és mire használhatják azt az AI tudást, amire képesek.

Ez szerintem egy nagyon hosszú távú verseny lesz mind támadó, mind védekezői oldalon.

Igen, ezt sokszor szoktuk látni, hogy ezt beszéljük is néha így egymás között, hogy igazából már AI fog támadni AI-t. Tehát, hogy nem is igazából.

Igen, igen, már így nézett ki igazából.

És azzal, hogy ugye folyamatosan nőnek ezek az AI adta lehetőségek, illetve kapacitások folyamatosan gyorsulnak mind a támadói oldal, mind pedig a védekezői oldal, tehát ez egy ilyen nagyon fej-fej melletti verseny. Nyilván a támadóknak az a célja, hogy ők legyenek lépéselőnyben, míg a védekezői oldalnak a másik. Tehát én nem tudnám ezt most megfogalmazni, hogy ki van előrébb. Nagyjából fej-fej mellett haladnak, és itt igazából, amit még ide érdemesnek látok behozni, hogy egy védekezői oldalt sokkal jobban kontrollálunk, mint egy támadói oldalt, akár így az AI-ek, és ez nagyon-nagyon megnehezíti sokszor a védekezői oldalt, mert ha meg van határozva, hogy mondjuk te csak és ezt és ezt a típusú mesterséges intelligenciát használhatod, csak ilyen és ilyen körülmények között, az azért belimitálja azt, hogy milyen védekezési platform áll rendelkezésre, míg a támadók igazából, amit nem szégyellnek, azt használják.

Illetve egyébként a végfelhasználói oldalról is egyre jobban látszik, hogy azért mindamellett, hogy volt a klaus stratégia, meg egyéb ilyen biztonsági stratégiák, most már van, hogy úgymond ilyen AI, meg AI kompetenciák és AI stratégiát is folyamatosan építenek ide nagyvállalatok, tehát hogy pont ezen, ezen kapcsolódóan, hogy akár a saját szolgáltatásaikat, ami AI-jal úgymond vezérelt, vagy mondjuk a saját felhasználóiknak mondjuk az AI használatát, az igazából milyen szabályzóknak megfelelően tudják igazából így kivetíteni őrájuk.

Igen, szerintem ez nagyon fontos, hogy ebben a gyorsuló világban, amit Máté is, meg Péter is említett, én még ugye azt tenném hozzá, hogy nem az lesz előnyben, aki az AI-t különálló eszközként használja, hanem igazából amiről ez a mai egész beszélgetés szólt, hanem aki képes lesz az AI-t egy architektúrába beemelni. Egy ugyanolyan funkció igazából. Igen, igen. És ugye nagyon fontos, hogy hozzátenném, hogy mindeközben ezt az egészet governance szempontból is még kontroll alatt kell tartani.

Abszolút.

Ilyenkor jön nagyon jól, hogyha valaki ért a szabványok nyelvén, merthogy nemcsak technikai szabványok vannak, ami nyilván egy csomó ilyen hálózati kommunikációt már régóta nagyon jól leír, hogy mi szerint kell tudni kompatibilisnek lenni egymással ezeknek a biztonsági termékeknek. Viszont van menedzsmentszabvány is, és azért a 42 ezer egy ilyen menedzsment rendszer az pont azért előnyös, merthogy elejétől a végéig felsorolja, hogy mivel kéne a stratégiában is, meg a belső szabályokban is foglalkozni. Tehát ott aki ilyen logikával tud gondolkodni, meg hozzáállni, az nem valószínű, hogy kihagy fontos dolgokat, és akkor ott minden fal annyit ér, amennyi luk van benne. Az árvíznél is tudjuk, hogy a töltésnél is elég egy luk ahhoz, hogy az egész töltés fölösleges legyen.

Így a vége felé még egy utolsó kérdést engedjetek meg. Ugye a checkpoint tűzfalgyártóként vált nagyjából, legalábbis én úgy tudom, és hát naponta klasszikus tűzfal leváltásáról vagy új paradigmákról beszélgettünk. Hogyan élik meg ezt a kollégák, akik megszokták a régi, nemcsak logikát, de eszköztárat gyakorlatilag. Hogyan boldogultok ennek a változás kezelésével így a checkpoint és a partneri körben.

Ha megengeditek, akkor elkezdeném. Én úgy látom, hogy nyilván vállalaton belül is kell egy szemléletmódváltás.

De ezt én úgy gondolom, hogy nálunk, házon belül ez megtörtént, és viszonylag gyorsan tudunk ehhez az igazából új helyzethez adaptálódni. Ugye, ha egy kicsit szélesebbre nyitjuk ezt a kérdést, és azt nézzük, hogy maga a checkpoint több mint 30 éve, mint tűzfalgyártó mozog a piacon. Átállt talán abból, hogy maga a tűzfal a termék, abból, hogy a tűzfal csak egy termék. És szerintem ez elmondja azt, hogy egy ilyen, én úgy gondolom, hogy neves Security gyártó is már így gondolkodik mondjuk a tűzfalról, hogy csak egy termék és nem a termék, ez megmutatja azt, hogy mennyire tudunk ehhez a helyzethez adoptálódni, illetve alkalmazkodni.

Igen, én ugye ehhez fűzném és hozzá, amit ugye Máté is mondott, hogy ugye a checkpointok mindig is a DNS része volt a tűzfal és a tűzfalas megoldások. De én most azt mondanám, hogy nem leváltjuk a tűzfalat, hanem odahelyezzük a tűzfalnak a működését, ahova kell, és ugye a helyén kezeljük, hiszen nekünk mint checkpoint könnyebb lenne azt mondani, hogy nagyon jók voltunk tűzfal gyártásban és a tűzfal technológia kitalálásában, csináljuk tovább ezt is, hanem én ezzel értek egyet, és ez nagyon szimpatikus a cégnek a működésében. Ugye azt mondtuk, hogy megváltozott a világ, és menjünk el olyan technológiák irányába, hozzunk be olyan megoldásokat is ami számunkra újként újként működik és és gondolkodjunk ugye egy ökoszisztémában, hiszen szél szempontból is nekem is egyszerűbb lenne a kereskedelmi oldalról azt mondani, hogy adjunk el egy jól működő tűzfal megoldást.

Ehelyett már minden tárgyalásunk, és szerintem ezt majd Péter meg tudja erősíteni. Minden tárgyalásunk arról szól, hogy adott üzleti problémát értünk meg, és arra szállítunk megfelelő infrastruktúrát és megoldáscsomagot.

Igen, itt egy nem kifejezett terméknek úgymond így a vásárlása szokott ez előjönni, hanem igen, ahogy Gábor is mondja, igazából maga az üzleti igény, és arra az üzleti igényt kell minél jobban definiálni és arra tudunk egyébként legjobban úgymond így köré építeni a megoldásokat akár ez ilyen teljesen entuen megoldások tehát akár a felhőtől kezdve az on premen keresztül vagy on premen át igazából minden szegmensét tudja érinteni, vagy tudja lefedni igazából a megoldási rész.

Nagyon tetszik, ahogy fogalmaztál Gábor, hogy ökoszisztémában gondolkodni, az mindig a nehezebb út fog maradni, de ugyanakkor hosszú távon szerintem az a nagyobb sikerrel kecsegtető út mindenkinek. És valahol itt a Digit Podcastban is ezt próbáljuk követni, úgyhogy én emiatt is nagyon örülök és hálás vagyok, hogy ismételten elgyalogoltatok hozzánk négy keréken. Ma pont ennyi fért bele, a többinek egy másik adásba kell majd a végére járnunk. Máté Gábor és Péter nagyon szépen köszönöm a beszélgetést.

Köszönjük a meghívást.

Nagyon szépen köszönjük.

Mi pedig nagyon köszönjük nektek a figyelmet, és kövessetek bennünket továbbra is minden csatornán, ami nektek kedves Spotify-on, Youtube-on, Apple Podcaston és a közösségi médián is.