Jak už napovídá samotný název, CNAPP (Cloud-Native Application Protection Platform) je především řešením, které umožňuje automatickou ochranu aplikací běžících v cloudovém prostředí. Jde o bezpečnostní platformy se širokým záběrem, které sdružují až desítky jednotlivých kyberbezpečnostních funkcí či nástrojů. Díky tomu umožňují získat dohled a kontrolu nad celým životním cyklem aplikací (od fáze vývoje až po jejich provoz) napříč nejrůznějšími cloudovými prostředími. Jejich výhodou je mimo jiné jednotná správa a jednotná úroveň bezpečnosti napříč nejrůznějšími cloudy – interními či veřejnými. CNAPP mohou využít všechny firmy, které využívají multicloudovou strategii, zvlášť přínosný je ale právě u společností, které v těchto cloudových prostředích provozují či vyvíjejí vlastní aplikace.

„Vý­ho­dou CNAPP je mimo jiné to, že po­sky­tu­je ne­pře­tr­ži­tou kon­tro­lu a ochra­nu ap­li­ka­cí během celé­ho jejich život­ní­ho cyk­lu. Od po­čá­teč­ní­ho kó­do­vá­ní přes jejich stav­bu až po samot­ný pro­voz. Na­hra­zu­je při­tom řadu ná­stro­jů, které nyní spo­leč­nos­ti vy­uží­va­jí, ale které často nema­jí spo­leč­né řídi­cí roz­hra­ní. Díky tomu snižuje pracnost ovládání a zároveň snižuje riziko, že některá z kritických chyb zůstane neodhalena,“ vysvětluje Ivan Svoboda, poradce pro kybernetickou bezpečnost společnosti ANECT.

Nástroje typu CNAPP tak reagují mimo jiné na fakt, že vývoj aplikací je dnes kontinuální činností, při které na jedné straně vývojáři neustále tvoří nové verze kódu podle požadavků z byznysu a při níž je zároveň potřeba tyto nové verze průběžně zapojovat do reálného provozu. V tomto režimu (tzv. CI/CD pipeline neboli Continuous Integration / Continuous Delivery) se tedy vše děje současně a existuje zde i široký prostor pro vznik kritických chyb. Zároveň se však minimalizuje čas na jakoukoliv bezpečnostní kontrolu. Jak tedy zapojit do tohoto kontinuálního procesu neustálých změn také někoho za kyberbezpečnost, ale tak, aby nebyla ohrožena rychlost, flexibilita a dynamika toho vývoje?

Jedním z hlavních rizik při tvorbě aplikací je dnes fakt, že se skládají z tisíců mikrokomponent, které pocházejí z různých zdrojů a o kterých je potřeba mít přehled. Některé části kódu píšou interní vývojáři přímo pro konkrétní aplikaci, některé si vypůjčí z jiných interních aplikací a u některých použijí například open source kódy z GitHubu. U řady aplikací se přitom objem skutečně nového kódu pohybuje pouze v jednotkách procent nebo dokonce promile. Části kódu se následně skládají do stále větších balíčků, které se potom často ukládají v tzv. kontejnerech, ze kterých je postavena celá aplikace. „Zde je potřeba připomenout, že každá jednotlivá zranitelnost v kódu může při běhu aplikace vést ke stovkám různých zranitelností. Proto je zapotřebí nejen prvotně otestovat bezpečnost všech jejích komponent, ale mít o nich dokonalý přehled. Odkud jaká komponenta pochází a zda se náhodou v průběhu času neukázalo, že obsahuje nějakou zranitelnost, případně zda se v průběhu času nezměnila, a pokud ano, tak jak. To vše je samozřejmě potřeba dělat nepřetržitě a automaticky na pozadí, aby bylo možné včas zareagovat a nebezpečnou část co nejrychleji opravit nebo vyměnit,“ vysvětluje Ivan Svoboda.

Zatímco bezpečnost samotného kódu a aplikace řeší vývojáři nástroji typu SAST a DAST (Static/Dynamic Application Security Testing), pro přehled o jednotlivých komponentách se využívají nástroje typu Software Composition. Ty fungují jako živá komponentová databáze dané aplikace, která upozorní na možná rizika. Pokud aplikace využívá ke svému provozu API rozhraní, přidávají se ještě nástroje na zajištění bezpečnosti tohoto propojení, tzv. WAAP (Web Application and API Protection).

Ochranu prostředí, ve kterém se skládají dohromady dílčí části kódu a ve kterém následně běží jednotlivé aplikace, mají na starosti nástroje typu CWPP (Cloud Workload Protection Platform). Ty poskytují komplexní ochranu aplikací v prostředí, ve kterém tyto části běží. Ať už jde o virtuální servery, kontejnery, nebo aplikace postavené na bezserverových službách.

„Plat­for­my CWPP inte­gru­jí mnoho bez­peč­nost­ních prv­ků, které každý IT ad­mi­ni­strá­tor zná ze světa fy­zic­kých ser­ve­rů, jako je ske­no­vá­ní zra­ni­tel­nos­tí, black­list­ing/white­list­ing, hard­en­ing po­kro­či­lé typy fire­wallů či end­point de­tec­tion and re­sponse,“ vy­svět­lu­je Petr Moj­žíš, secu­ri­ty archi­tect spo­leč­nos­ti ANECT.

Mezi další vrstvy, které je třeba hlídat, patří obecně infrastruktura, na které jednotlivé aplikace běží. Například pokud aplikace funguje na virtuálních datových centrech nebo na privátním cloudu, je potřeba vědět, že vše je postaveno tak, aby nebylo možné se do tohoto prostředí nabourat a exfiltrovat například citlivá data. Stejně tak u veřejného cloudového poskytovatele je třeba zajistit správnou konfiguraci této infrastruktury. Zda je vše v souladu s interními bezpečnostními politikami nebo legislativou typu NIS2. Zodpovědnost poskytovatelů cloudu je totiž velmi striktně omezena a většina zodpovědnosti je na jejich zákaznících. K tomu všemu slouží Cloud Security Posture Management (CSPM). Ke správě identit a přístupových práv uživatelů i jednotlivých aplikací v cloudovém prostředí se potom používají CIEM nástroje (Cloud Infrastructure Entitlement Management).

Jeden nástroj vládne všem

Tradiční bezpečnostní nástroje, které jsou navrženy pro ochranu klasických onpremise sítí a koncových bodů na místě (firewall, antivir, XDR apod.) už však s přechodem na cloudové technologie a služby nestačí. S rychlejšími cykly vydávání jednotlivých verzí a vylepšení aplikací či moderními metodami vývoje aplikací (CI/CD pipeline, kontejnery, serverless funkce, Kubernetes apod.) jejich využitelnost a účinnost klesá. Hlavním důvodem je, že pracují izolovaně a nezvládají dostatečně pružně reagovat na neustálé změny, které se dějí jak na straně vývoje, tak na straně prostředí, ve kterém aplikace běží.

Firmy tak často mají zabezpečené některé z výše vyjmenovaných tradičních oblastí, zatímco u cloudových mají naopak větší či menší nedostatky. Typickým prohřeškem je například jednostranný důraz na zabezpečení provozu aplikací bez toho, aby měly dobrý přehled o tom, z čeho jsou poskládané a jestli se v jejich základu neobjevuje nějaká komponenta, u které byla objevena kritická zranitelnost. „Obecně můžeme říci, že nedostatečný přehled o zranitelnostech a konfiguračních chybách v různých částech aplikace i infrastruktury (od kódu přes konfiguraci prostředí, ve kterém fungují až po samotný jejich provoz) je jedním z kamenů úrazu u většiny firem,“ říká Petr Mojžíš.

Dalším typickým problémem je důraz na vizibilitu bez toho, aby následoval automatický patch management. „Když už mají firmy dobrý přehled o tom, co se v jejich síti či aplikaci děje, tak ve chvíli, kdy se vyskytne problém, už často nevědí, jak s ním naložit. Pokud navíc různé nástroje objeví různé problémy, podle našich zkušeností firmy často selhávají v prioritizaci těchto událostí,“ dodává Petr Mojžíš.

Díky tomu, že CNAPP integruje všechny výše popsané principy a nástroje do jedné platformy s jedním řídicím centrem, a díky tomu, že funguje jako zastřešující nástroj nad všemi cloudovými prostředími, umožňuje firmám řadu těchto problémů efektivně řešit.

„CNAPP je v obecné rovině vhodný pro širokou škálu podniků, od malých start-upů po velké korporace, které využívají cloudové služby. Jeho flexibilita a škálovatelnost umožňují přizpůsobení potřebám různých podniků, ať už v oblasti zpracování velkých objemů dat nebo zajištění bezpečnosti citlivých informací. Největší přínos má ale právě pro větší firmy vyvíjející vlastní aplikace v multicloudovém prostředí. Těm umožňuje zjednodušit správu bezpečnostních řešení a zároveň snížit počet jejich dodavatelů,“ uzavírá Ivan Svoboda.