„Ha nagyon le akarjuk egyszerűsíteni, akkor ma a biztonságban is minden vagy szinte minden a SaS modell miatt történik, ez hívta életre az ún. Cloud Native Application Protection Platform (CNAPP) megoldásokat. A publikus felhőszolgáltatások azonban fejlődnek: sok szervezet a szoftverfejlesztési környezetét is felhőalapúvá alakította, ott futtatja a pipeline-ok stb. Ez a helyzet pedig gyorsan kialakított egy új fejlesztési elvet” – mondta Werner Obring, a Clico Hungary cloud security architektje arról, hogy miért érte el a platformszemlélet a fejlesztés területét.

Milyen új elvre gondol?

Werner Obring: Ez a shift-left, amely a fejlesztési életciklus korai szakaszába „tolja vissza” a tesztelési, biztonsági és minőségbiztosítási feladatokat. Tehát már a kód írása közben működésbe lépnek a biztonsági kontrollok.

Az elv kialakulása annak is köszönhető, hogy ma már az infrastruktúra szintén kód. Az IaC (Infrastructure as Code) koncepcióban nem manuálisan, hanem kód és automatizált folyamatok segítségével történik a felhős infrastruktúra konfigurálása és a provisioningje, mert így biztosítható többek között a gyors és automatizált skálázás. Az IaC egyfelől csökkenti az emberi hibák lehetőségét, másfelől azonban kulcskérdéssé teszi a kód biztonságát. Továbbra is szükség van olyan kontrollokra – például forráskód-elemzésre –, melyek ismerik a fejlesztéshez használt nyelveket, valamint képesek a third-party szofverkomponensek ellenőrizni biztonsági, függőségi és compliance, sőt lincencelés szempontjából – utóbbi különösen az open source kódok felhasználásánál lehet fontos. De kellenek olyan kontrollok is, melyek az infrastruktúra kódját tudják elemezni, fel tudják deríteni a skálázásban, a jogosultságkezelésben stb. a kockázatos pontokat. A shift-left a kontrollokat már a build fázis előtt alkalmazza mind az infrastruktúránál, mind pedig az alkalmazásoknál. Ugyanakkor biztosítani kell a futásidejű védelmet is.

Még szerteágazóbb lesz a probléma, ha a konténerizáció is belép a képbe, amikor sok ezer node-ból álló klaszteres konténerkörnyezeteket kell védeni. Szükség lesz hálózati szegmentációra, például annak ellenőrzését, hogy hol indokolt és hol tiltott az „átjárás” a konténerek között.

Ennek a bonyolult ökoszisztémának az átfogó kezelése már nem oldható meg elszigetelt, részmegoldásokat nyújtó védelemmel. Ezért bővülnek folyamatosan az integrált és átfogó védelmet nyújtó CNAPP-k új funkciókkal.

Hogyan működik mindez a gyakorlatban?

W. O.: A hagyományos fejlesztési folyamat az volt, hogy a fejlesztő megírta a kódot, amit az üzemeltetési csapat manuálisan telepített valamilyen erőforrásra. Csak ekkor lépett színre a biztonsági csapat, amely elvégezte a sérülékenységvizsgálatot. A sérülékenységlistát visszakapták a fejlesztők, és szép sorban haladva elkészítették a javításokat.

Ma viszont az alkalmazás és az infrastruktúra forráskódja egyaránt egy repositoryba, mondjuk egy Git repóba kerül, a diployment folyamat pedig teljes mértékben automatizáltan fut le a CI/CD pipeline-on keresztül. Ha azonban az infrastruktúra-automatizáláshoz használt Terraform fájlokban van egy rosszul beállított AWS S3 bucket, azaz egy fő adattároló mappa, amibe belekerül valamilyen nyilvánosan elérhető adat, az olyan sérülékenység, amely kihasználható egy alkalmazáson keresztül, még ha nem is az alkalmazás generálta. Ezek már nem olyan klasszikus kódbiztonsági hibák, amik például statikus vagy dinamikus forráskód-elemzéssel feltérképezhetők. A támadások többsége ma már nem is az alkalmazásokat célozza mondjuk SQL Injection vagy Crossite Scripting módszerrel, hanem inkább konfigurációs hibákat keres. Például olyan indokolatlan admin jogosultságokat, melyeken keresztül akár a teljes konténerizált környezet kompromittálható.

CNAPP-kből bőséges a kínálat. Mi segíthet a felhasználóknak eligazodni közöttük?

W. O.: A CNAPP-választás kockázatalapú döntés. Minden szervezet más – lehet közműszolgáltató, gyártócégnek, startup és így tovább –, így más kontrollokra is van szüksége. Más az infrastruktúra, más a fejlesztés folyamata. Ha egy cég nyílt forráskódú komponenseket használ, szükség lesz SCI-re (Software Composition Analysis); ha Kubernetes platformot, akkor erős IaC- és workload-védelemre stb. Figyelembe kell venni a fejlesztői környezetet, a CI/CD-konfigurációkat, van-e multi cloud környezet, mi a ticketing rendszer, van-e már SIEM megoldás és még sorolhatnám.

A CNAPP-nek ugyanis illeszkednie kell meglévő biztonsági eszköztárhoz. Ha nem illeszthető össze azokkal, nem úgy fog működni, ahogy várnánk.

Emiatt egyes rendszereket le is kell cserélni...

W. O.: Én inkább egyszerűsítést mondanék. Vannak cégek – például a bankok –, melyeknél a legacy rendszereket nem is lenne egyszerű kiváltani. De a teljes lefedettséghez szükséges eszközszám ettől még jelentősen csökkenthető, ami nagyobb átláthatóságot és alacsonyabb üzemeltetési költségeket eredményez.

Melyek ma a legerősebb érvek a CNAPP-k mellett?

W. O.: Leggyakrabban három érv kerül elő. Először is: a CNAPP-k teljes fejlesztési életciklusra nyújtanak védelmet, a DevOps folyamatokat átalakítják DevSecOps folyamatokká a shift-left megközelítés révén. Másodszor: segítik a védelem automatizálását, ráadásul a fejlesztési folyamatba integrálva és egyszerre védve az alkalmazásréteget és az azt futtató platformot; így nem utólag, futásidőben kell az alkalmazásokban sérülékenységeket keresni. Végül, de nem utolsósorban lehetőséget adnak a költségcsökkentésre azzal, hogy segítik az erőforrások optimalizálását, felderítik például azokat a túlskálázott virtuális gépeken futó alkalmazásokat, melyeknek egy serverless környezet is elegendő lenne – ami ugye lényegesen olcsóbb.

Azaz a CNAPP-k figyelme a kódtól a költségekig terjed.
 

Werner Obring: "A meghatározó kiberbiztonsági cégek egyaránt olyan end-to-end megoldások felé haladnak, amelyekkel lefedhetik a teljesen fejlesztési-üzemeltetési láncot."

A Gartner piaci elemzéseiben évek óta a Palo Alto Networks vezeti a CNAPP-piacot. Miben tud többet a Cortex Cloud, mint a konkurensei?

W. O.: A Cortex Cloud – korábban Prisma Cloudnak hívták – legnagyobb előnye a teljes lefedettség. A Palo Alto Networks az első között indult el a platformvédelem irányába, és tudatos felvásárlási politikával, szisztematikusan építtette a CNAPP-jét. Nemcsak felvásárolt piacvezető megoldásokat, hanem nagy gondot fordított az integrációjukra is. Hasonlóan mély a platform integrációja a különböző felhős megoldásokkal az AWS-től a Google Cloudon át a különböző OpenShift konténerkörnyezetekig, és jól támogatja a multi- és hibridfelhős környezetet. Policy engine-jei pontosak, nemcsak listáznak, hanem priorizálnak is, ráadásul nagyon jó javítási javaslatokat adnak. Vagy ott van a korábban említett hálózati szegmentáció: a Cortex Cloud egy tesztkörnyezetből képes megtanulni az alkalmazások infrastrukturális viselkedését, és ezt a tudását automatikusan használja production környezetben.

Ön szerint merre fejlődnek a CNAPP-ek?

W. O.: Azt látom, hogy a meghatározó kiberbiztonsági cégek egyaránt olyan end-to-end megoldások felé haladnak, amelyekkel lefedhetik a teljesen fejlesztési-üzemeltetési láncot. Előbb-utóbb a platformok része lesz a statikus és dinamikus alkalmazásbiztonsági tesztelés, a szoftverösszetevők analízise vagy akár a policy-motorok is.

De leginkább abban vagyok biztos, hogy a mesterséges intelligencia nem hagyja érintetlenül ezt a piacot sem. Már ma is vannak olyan biztonsági MI-asszisztensek, melyek javítási ajánlásokat tesznek. Ezek nem váltják ki az embert, de gyorsítanak a folyamatokon.