Olyan problémákkal is számolni kell az SAP felhősítésénél, amivel maga a szoftvergyártó sem kalkulált. Ez abból a posztból derül ki, amely az SAP hivatalos blogjában jelent meg tegnap. A vállalat CSO-ja mellett stratégiai tanácsadóként dolgozó Jay Thoden van Velzen saját kísérletük kudarcán keresztül mutatja be, hogy a helyszíni, adatközponti legacy biztonsági rendszerek lift-and-shift módon történő felhősítése miért is tévút. Biztonsági szempontból olyan lesz az infrastruktúra, mint az az épület, amelynek minden felső emeletét erős rácsok védik a külső behatolóktól, de a földszintre bárki bejuthat és beszállhat a liftekbe ellenőrzés nélkül.

Ezek a hagyományos, on-prem adatközponti környezetekre fejlesztett eszközök egyszerűen nem látják azokat a fenyegetéseket, melyek a felhőben jelentkeznek. Például a vállalati adatközpontokban jellemzően nyílt hálózatok működnek, melyekben ágensalapú megoldásokkal monitorozzák a fenyegetések.

A nyilvános felhők hálózatai ezzel szemben többnyire titkosított API-hívásokkal kommunikálnak, a VM-ek, konténerek és az ezeket összekapcsoló hálózatok pedig sokszor csak időlegesen működnek. Ha a támadó bejut ide, emiatt nehezen tud tartós hozzáférést szerezni hozzájuk, ám megpróbálhat új VM-eket létrehozni, amiken például kriptobányász rendszereket futtathat. Ezek a VM-ek azonban nem az adott vállalat sablonjait használják, és nem futnak rajta biztonsági ágensek sem, miáltal észrevétlenek maradnak.

Az ágensalapú megközelítés hatékonyságát a fejlesztők általános hozzáállása is erősen gyengíti, véli van Velzen. A fejlesztők nagy autonómiával rendelkeznek a felhőben, ahol sokszor kényükre-kedvükre telepíthetnek erőforrásokat. Ahhoz, hogy ezeket biztonságosak lehessen használni, minden egyes végpontra kellene ügynököt telepíteni. A fejlesztők azonban szeretnek akadálymentesen hozzáférni az erőforrásokhoz, ezért rendre elhanyagolják az ágensek telepítését és tesztelését.

Ennek ellenszere a szervezeti szinten megvalósított API-alapú felhőnatív biztonság, ami a központosítható onboarding folyamaton keresztül a szervezet minden felhőfiókjára egységesen alkalmazható anélkül, hogy például ehhez a fejlesztők aktív közreműködését kellene kérni.

Valószínűleg eddig senkinek sem okoztak relevatív élményt van Velzen gondolatmenete – a felhőbiztonsággal foglalkozó cégek egyik alaptétele ugyanis (lásd pl. itt), hogy az ágensalapú védelem drága, nehéz menedzselni, nem utolsó sorban pedig szükségtelenül korlátozza az IT mozgásterét.

Ám a tanácsadó azonban azt is leírta, hogy az SAP-nál ennek a felismeréséhez küzdelmes út vezetett.

Saját káron szerzett tapasztalat

A szoftvergyártó ugyanis éveken keresztül próbálkozott azzal, hogy mégis megoldja a megoldhatatlant, és ágensalapú EDR (endpoint detection and response) rendszerét lift-and-shift módon felhősítse. Végül aztán győzött a józan ész: másfél év meddő kísérletezés után átálltak egy ún. Cloud-Native Application Protection Platformra (CNAPP), amit mindössze három hónap alatt telepítettek és vezettek be a szervezet nagy részében.

Az EDR-nél ugyanis folyamatosan olyan problémákba ütköztek, amire nem találtak jó megoldást, és az egész csak egyre bonyolultabb lett. Ott volt például a licencelés. Az SAP 24 óránként mintegy 30 ezer VM-et hoz létre. Sok gyártó felhasználóalapon (per-seat) licencel, de hogyan kell kiszámolni a fizetendő díjat, ha ezeket csak néhány óráig használták? És mind a 30 ezer VM-et figyelembe kell venni, vagy csak a VM-ek átlagos számát egy adott időszak alatt? Ezt kezelni egy olyan helyzetben, amikor az SAP egy év alatt megduplázta a felhőben lévő erőforrásait, szinte lehetetlen volt. A biztonsági költségek ugyanis lineárisan nőttek a hálózat méretével.

Ráadásul egy saját adatközpontban általában van a hardverekben annyi tartalék, hogy egy ágens futtatása nem jelent problémát. De ha a felhőben köt le erőforrásokat, azokért fizetni kell, ahogy a hálózathasználatért is. Tehát még az is plusz költségként jelentkezik, ha a rendszer riasztásokat küld (egy saját adatközpontban értelemszerűen ez is "ingyen van").

Van Velzen állítása szerint az ágens nélküli, alapvetően side-scanning módszerrel dolgozó CNAPP, amely a felhőszolgáltató API-ján keresztül kommunikál, ötödébe kerül ugyanakkora infrastruktúránál, mint az ágensalapú.

A korábbi stratégia kudarcának teljes beismerése pedig az, hogy az SAP úgy döntött, a jövő év eljére mindenhol lecseréli az bevált CNAPP-re saját fejlesztésű megoldásait. Ügyfelei pedig ennek nyomán megspórolhatják a kudarcélményt, de egy CNAPP-rendszer beszerzését nem. Az on-prem biztonság meg majd elvásik valamikor...