Ha rákeresünk a what is code security szókapcsolatra, a találatok mennyiségéből is látszik: fontos téma. Szinte minden biztonsági cég oldalán olvashatunk friss dokumentumokat, cikkeket, amelyek a problémakört a CNAPP-okkal (cloud-native application protection platform) összefüggésben tárgyalják. Összeállításunk első részében áttekintettük a kódbiztonság felemelkedését. Az alábbiakban azt nézzük meg, hogyan kapcsolódik a kódbiztonság a felhős alkalmazásvédelemhez.

A CNAPP-okat az a felismerés szülte, hogy a biztonsági szint emeléséhez egyesíteni kell a felhős védelmi eszközöket, valamint egyesíteni kell az adatforrásokat. Erre épülhet a biztonsági folyamatok egyre kiterjedtebb automatizálása. A biztonság területén például lehetővé teszi, hogy a CNAPP-ot össze lehessen kapcsolni felhőbiztonsági helyzetkezelővel (CSPM, cloud security posture management) vagy például munkaterhelés-védelmi platformmal.

A CNAPP-ok fontos tulajdonsága, hogy újabb és újabb funkciókkal bővíthetők, így képesek konszolidálni a szervezeteken belül elmerülő különféle biztonsági igényeket. Mivel képesek futásidejű fenyegetésészlelésre, és tudják elemezni a szoftverek alkotóelemeit, maximálisan megfelelnek a DevSecOps igényeinek.

Amikor felveszik MI programozót

Ez a tulajdonságuk különösen fontos a generatív mesterséges intelligencia elterjedése óta. Ahogy az MI megjelenésekor sokan sejtették, a technológia a kiberbűnözőknek is óriási segítséget nyújt, például egyszerűbbé teszi hatékony, személyre szabott adathalász e-mailek generálását vagy social engineering sémák felépítését mélyhamisítás segítségével. Aztán jöttek az olyan eszközök, mint a GitHub Copilot vagy az MI-alapú eszközökkel automatizálható sérülékenységfeltárás. Ezek segítik a fejlesztőket. Ám segít a támadókat is: elképesztően alacsonyra vitték a belépési küszöböt a hekkervilágba, mert egyszerűbbé tették a sérülékenységek megtalálását és az azokat kiaknázó kód megírását egyaránt.

Ezt a CNAPP-ok fejlesztői is igyekeztek követni. A komplex védelmet biztosító CNAPP megoldások már a fejlesztési fázisban képesek azonosítani a sebezhetőségeket, a hibás konfigurációkat és a megfelelőségi problémákat, miközben valós idejű futásidejű védelmet is kell kínálnia.
 Ahhoz azonban, hogy CNAPP képes legyen ebben a helyzetben is teljes körűen támogatni a DevSecOps filozófiát, a biztonságot be kell ágyazni a CI/CD-folyamatokba (Continuous Integration/Continuous Delivery vagy Deployment).

A biztonság kódba építése

Egy ilyen környezet kialakításához két lépés megkerülhetetlen. Az első a kódbiztonság legfontosabb kihívásainak azonosítása. Itt a biztonsági megoldásszállítók első számú általános tanácsa, hogy meg kell találni azt a pontot, ahol a biztonság, a kód leszállításának sebessége és a funkcionalitás egyensúlyban lesz. Tehát a fejlesztők úgy és olyan határidővel tudják leszállítani az adott funkciót, hogy azzal ne sértsék sem az üzleti igényeit, sem az adott funkcióhoz kapcsolódó biztonsági és compliance követelményeket.

Ehhez mindenekelőtt olyan biztonságtudatos fejlesztői kultúrára van szükség, amelyben a biztonságra törekvés a napi munkafolyamatok szerves része. Csak az ilyen gyakorlat akadályozhatja meg például, hogy valamilyen vélt vagy valós (határidős) nyomás miatt ne kerüljenek a fejlesztéshez használt nyilvános repositorykba érzékeny céges adatok.

Ez a szemlélet segít abban is, hogy meg lehessen találni a biztonsági eszközök és folyamatok integrálásának optimumát. A Palo Alto Networks egy tavalyi kutatása szerint egy cég átlagosan közel háromtucatnyi kiberbiztonsági eszközt használ. Könnyen belátható, hogy ezeket nemcsak menedzselni probléma, hanem sokszor a fejlesztőket is nehéz feladat elé állítja. Ezért aztán hajlamosak lesznek figyelmen kívül hagyni egyes biztonsági követelményeket.

Elvileg a fejlesztőkre hárulna, hogy ismerjék, és a kódjukban kezeljék a legfrissebb kiberfenyegetéseket, az új sebezhetőségeket, támadási módszereket stb. Emellett nekik kellene foglalkozniuk a third-party megoldások (pl. nyílt forráskódú könyvtárak) hozta sérülékenységekkel.

Ha a problémákat azonosítottuk, következhet a kódbiztonság integrálása a fejlesztési folyamatba. Az első lépés itt is a tervezés: a követelmények összegyűjtése (titkosítás, hitelesítés, hozzáférés-vezérlés stb.). Rögzíteni kell a kódolás alapvető szabályait – az alapértelmezés, hogy a fejlesztők olyan biztonságos kódot írnak, melyek igazodnak a szervezet biztonság irányelveihez –, dokumentálni kell minden biztonsággal kapcsolatos döntést, és elő kell írni a third-party könyvtárak, függőségek biztonsági kockázatainak értékelését és ellenőrzését.

Ki kell terjeszteni a tesztelést. Az alapvető funkciók ellenőrzésén túl olyan biztonságközpontú teszteket kell bevezetni, mint a kódvizsgálat, a statikus (SAST) és dinamikus tesztek (DAST) vagy a behatolás-teszt (penetration test).

Végül, de nem utolsósorban a védelmet ki kell terjeszteni a CI/CD pipeline-ra annak szellemében, hogy a kódbiztonság egy alkalmazás teljes életciklusára vonatkozik. Szigorú jogosultsági szabályokat kell felállítani (pl. minden új funkciót csak az arra felhatalmazott személyek telepíthessenek), és biztosítani kell az új sebezhetőségek figyelését, hogy gyorsan be lehessen avatkozni, ha azok érintenék a már telepített kódot.

Egy megoldási lehetőség: IaC, azaz az infrastruktúra mint kód

Ezeket a feladatokat azonban felhős környezetben hagyományos eszközökkel szinte lehetetlen megvalósítani. Olyan technológiai megközelítésre van szükség, amely ötvözi az alkalmazás- és infrastruktúra-fejlesztési elveket, emellett rugalmasságot és skálázhatóságot biztosít; azaz egységben kezeli a felhőben történő építkezést és a felhős rendszerek biztonságát.

Ebben segít az IaC (Infrastructure as Code). Az ötlet nem új. Hasonló koncepció mentén – igaz, alacsonyabb szinten – alakult ki az SDN (Software Defined Network), amely szintén erőteljesen hatott a kiberbiztonság fejlődésére. Az IaC azt teszi lehetővé, hogy a felhős rendszerek építése és menedzselése egyaránt szoftverkód segítségével történhessen.

Az IaC számos olyan új biztonsági szempontot vezet be, melyeket a hagyományos biztonsági megközelítések nem képesek kezelni. A felhőből eredő sajátosság például, hogy IaC környezetben egyetlen hibás konfiguráció egy kódfájlban akár több ezer riasztást is eredményezhet. A kódbiztonság hangsúlyos beemelése a CI/CD folyamatba azonban már a fejlesztési életciklus korai szakaszában felszínre hozza a biztonsági problémákat. Így azokat nem a telepítés után, hanem még a "építési" fázisokban lehet gyorsabban és olcsóbban javítani.

Az IaC sikeres kódbiztonsági stratégiája tehát az, hogy a biztonságot közvetlenül beágyazza a fejlesztői eszközökbe és munkafolyamatokba. Ennek fontos eszköze a CNAPP: nemcsak a felhőplatformok vagy a mikroszolgáltatás-architektúrák reaktív és proaktív védelmét tudja ellátni, hanem integrálható a CI/CD-folyamatokkal is.

Nem minden platform biztosít komplex, átfogó védelmet, és nincs is szükség mindenhol erre. Összeállításunk utolsó részében a választási szempontokat tekintjük át.

Ez a cikk független szerkesztőségi tartalom, mely a Clico Hungary támogatásával készült. Részletek »