Cloud security bevezetés: amit nem mondanak el a workshopokon

Ez a mondat ismerősebb, mint gondolnánk. A felhőbe költözés elvárt tempója miatt biztonsági hiányosságok keletkeznek, melyek nem azonnal robbannak,  csak akkor, amikor valaki rájuk talál. És általában nem mi fogjuk megtalálni, hanem egy támadó, egy auditor, vagy a legrosszabb esetben egy újságíró, aki épp arról ír cikket, hogy hogyan szivárgott ki tízezer ügyfél adata egy rossz beállítás miatt.

Az ISC2, a kiberbiztonsági szakma egyik legnagyobb tanúsító szervezete alapképzésében öt területet emel ki, amikre kellő figyelmet fordítva a legtöbb katasztrófa elkerülhető. Nincs varázslat, csak alapos munka – de pont ez az, amit a legtöbben kihagynak, mert unalmasabb, mint egy új eszköz bevezetése egy lenyűgöző demóval és egy lelkes sales csapattal a háttérben.

Az alapoknál kezdődik minden

Mielőtt bármit vásárolnánk, tegyünk fel három kérdést: mit védünk, kitől, és mi történik, ha mégis baj van? Ez unalmasan hangzik egy olyan világban, ahol mindenki AI-alapú fenyegetés-észlelésről és automatizált válaszrendszerekről beszél. Mégis, ha nincs rájuk válaszunk, akkor fogalmunk sincs, mire kellene a legdrágább eszköz és a végén nem is tudjuk majd, tulajdonképpen mi ellen védekezünk.

A Microsoft jelentései évről évre ugyanazt mutatják: a nagy incidensek mögött ritkán van kifinomult támadó, sokkal gyakoribbak a rosszul beállított jogosultságok vagy az MFA (multi-factor-authentication; többtényezős hitelesítés) nélküli admin fiókok. A legtöbb baj nem a zseniális hacker-ek miatt történik, hanem mert valaki elfelejtett bepipálni egy checkbox-ot valamikor tavaly ősszel, és azóta senki nem nézett vissza rá. Kicsit olyan ez, mint amikor bezárjuk a bejárati ajtót, de nyitva hagyjuk a garázst – a bűnöző nem fog a fal áttörésével bajlódni, ha van egy egyszerűbb út is befelé.

A hozzáférés-kezelés: ahol tényleg minden eldől 

Ami tényleg számít, az a jogosultságkezelés: ki, mihez férhet hozzá és tényleg szüksége van-e rá? A "least privilege" elve – hogy mindenki csak azt lássa, ami a munkájához kell – nem bürokrácia, hanem az egyik leghatékonyabb védelmi vonal, amit építhetünk, és valószínűleg a legolcsóbb is. Nem kell hozzá új licensz, csak fél nap odafigyelés és egy beszélgetés azzal a kollégával, akinek évek óta megvan a hozzáférése egy rendszerhez (mert pl. három csapatváltással ezelőtt még ő kezelte), de már egyáltalán nem is használja.

Ismerős a helyzet? A legtöbb szervezetnél, amivel találkoztam, a jogosultság-lista úgy néz ki, mint egy régi ruhásszekrény: tele van dolgokkal, amikre "talán még szükség lesz", de valójában senki nem tudja pontosan, mi micsoda, és senki nem meri kidobni, mert mi van, ha épp az kell holnap.

A Microsoft Zero Trust megközelítése pontosan ebből indul ki: ne bízzunk automatikusan senkiben, ellenőrizzünk mindent, és számoljunk azzal, hogy a baj talán már meg is történt. Ez elsőre paranoiásan hangzik, de a gyakorlatban inkább felszabadító: nem kell eldöntenünk, ki a "megbízható", mert senki nem az automatikusan – mindenkit ugyanúgy ellenőrzünk, függetlenül attól, hogy az irodából vagy egy reptéri váróteremből jelentkezik be. Ha az MFA még nincs bekapcsolva minden admin fiókon, ez legyen a legfontosabb teendőnk!

Amikor nincs fal, amit meg lehet védeni 

A felhőben egyébként nincs klasszikus fal, amit meg lehet védeni. Nincs kerítés, nincs "belül biztonságos, kívül veszélyes" logika, mint a régi szerverszobás világban, ahol elég volt egy jó tűzfal, egy zárt ajtó és egy gondnok, aki tudja, ki jön-megy az épületben. A felhőben minden szolgáltatás, minden API, minden mikroszervíz potenciálisan bárhonnan elérhető.

Ehelyett szegmentálni kell, vagyis úgy elválasztani a rendszereket egymástól, hogy ha valaki bejut az egyikbe, ne tudjon szabadon sétálgatni a többiben, mint egy elveszett turista egy őrizetlen múzeumban. Pont ez az, ami megakadályozza, hogy egy kisebb balesetből teljes katasztrófa legyen: a kár egy szobában marad, nem terjed át az egész épületre. E szemlélet szerint nem azt kérdezzük, bejut-e valaki, hanem hogy mi lesz, amikor bejut. Sokaknak még mindig szokatlan, pedig pont ez különbözteti meg a felszínes védekezést a valódi biztonsági programtól. 

A terv, amit remélhetőleg soha nem kell elővenni 

És itt jön a rész, amit mindenki halogat: mi történik, ha tényleg baj van? Kinek szólunk, mennyi idő alatt reagálunk, hogyan állunk helyre? A Microsoft saját tapasztalatai szerint a szervezetek jelentős része sokkal később veszi észre a problémát, mint gondolnánk – nem percekkel, hanem hetekkel később. Gondoljunk bele: hetekig valaki más jár-kel a rendszerünkban, olvassa az e-mailjeinket, mozgatja a fájljainkat, és ezt nem is tudjuk, mert senki nem nézte meg a naplókat azóta, hogy bekapcsolták a rendszert.

Egy leírt és ténylegesen tesztelt terv – mert egy fiókban porosodó dokumentum senkit nem véd meg, csak jó érzést ad annak, aki egyszer megírta, és azóta büszkén mutogatja az auditoroknak – drámaian lerövidíti ezt az időt. Egy évente megtartott, kényelmetlen szimuláció, ahol tényleg leállítunk egy rendszert és megnézzük, mi történik, sokkal többet ér, mint egy tökéletesre csiszolt, de soha nem tesztelt dokumentum. A gyakorlatban ilyenkor derül ki, hogy a "vészhelyzeti kapcsolattartó lista" harmadik neve már két éve nem dolgozik a cégnél.

A napi rutin, amit ritkán posztolnak a LinkedIN-en 

A napi rutin adja végül a különbséget: naplózás, monitorozás, frissítések, és igen, a kollégák képzése is. Ez az a rész, ami sosem lesz izgalmas konferencia-előadás témája, mert nincs benne semmi látványos – nincs AI, nincs látványos dashboard, csak fáradságos, ismétlődő munka.

Egy korszerű monitoring rendszer önmagában semmit nem ér, ha senki nem néz rá a riasztásokra, vagy nem tudja, mit kezdjen velük. Ez olyan, mintha vennénk egy füstérzékelőt, de kivennénk belőle az elemet, mert zavar a sípolása. A technológia csak annyira jó, amennyire a mögötte álló csapat és a csapat csak annyira jó, amennyi időt és figyelmet kap arra, hogy valóban odafigyeljen, ahelyett hogy folyamatosan tüzeket oltana más, sürgősebbnek tűnő feladatok miatt.

És itt jön a képzés kérdése, amit sokan alábecsülnek. Egy jól megírt phishing e-mail sokkal olcsóbb és gyakran hatékonyabb, mint bármilyen technikai támadás – miért törnénk fel a zárat, ha valaki egyszerűen kinyitja az ajtót, mert azt hitte, a főnöke küldött egy sürgős kérést? A rendszeres, nem büntető jellegű, hanem tényleg hasznos biztonsági képzés az egyik legjobb befektetés, még akkor is, ha a kollégák eleinte csak forgatják a szemüket, amikor meglátják a naptárban.

Hol érdemes kezdeni? 

Nem kell egyszerre mindent megoldani. Ez a leggyakoribb félreértés, amit láttam, és általában ezért fullad ki a lelkesedés is. Az ember látja a feladatlistát és inkább elhalasztja az egészet a következő negyedévre. Ehelyett nézzük meg őszintén, hol állunk most, majd priorizáljunk kockázat szerint.

A legtöbb esetben az MFA bevezetése és a jogosultságok átvizsgálása a leggyorsabb és legnagyobb hatású első lépés, amit még ma elkezdhetünk, méghozzá egyetlen fillér elköltése nélkül. Utána jöhet a naplózás rendbetétele, majd a hálózati szegmentáció, és végül – de nem utolsósorban – az incidenskezelési terv megírása és tesztelése. Nem kell egy hónap alatt mindent tökéletesíteni. Elég, ha minden hónapban egy kicsit jobb a helyzet, mint az előzőben.

A cloud security nem egy dobozból kipipálható projekt, amit egyszer lezárunk és elfelejtünk. Folyamatos, élő program – de ha a fenti alapokra figyelünk, sokkal nyugodtabban alszolunk majd éjszaka, és nem egy jogi osztálytól érkező e-mail fog felébreszteni hajnali háromkor.

És a kollégám, akiről a bevezetőben írtam? Ő is elkezdte átnézni a jogosultságokat. Jobb később, mint soha, és sokkal jobb, mint egy incidens utáni sajtóközlemény megírása közben rájönni ugyanerre, amikor már mindenki azt kérdezi, hogy ez hogyan történhetett meg.