A felhős incidensek túlnyomó része nem a szolgáltató hibája, hanem konfigurációé. Nyitva hagyott tároló, túl széles jogosultság, hiányzó naplózás.
A felhőszolgáltatók infrastruktúrája jellemzően jobban védett, mint bármelyik saját szerverterem. A felhős incidensek túlnyomó része mégis megtörténik, és szinte mindig ugyanabból az okból: a megosztott felelősség ügyféloldali részét senki nem kezeli.
A szolgáltató felel az infrastruktúráért: a hardverért, a hipervizorért, a fizikai biztonságért. Az ügyfél felel az adatért, a hozzáférésekért és a konfigurációért.
Ez a határvonal a szerződésben világos, a gyakorlatban mégis sokan azt hiszik, hogy a felhőbe költözéssel a biztonság is átkerült. Nem kerül át.
A klasszikus eset: egy objektumtároló, amit fejlesztés közben nyitottak meg, és soha nem zártak vissza. Nincs benne bejelentkezés, tehát bárki, aki tudja az URL-t, letölti.
Amit tenni kell: alapértelmezetten tiltott nyilvános hozzáférés fiókszinten, és rendszeres ellenőrzés, hogy nincs-e kivétel.
A projekt idején valaki kapott egy megengedő szabályt, hogy haladjon a munka, és utána senki nem szűkítette vissza. Hónapokkal később ez a szabály még mindig él.
Amit tenni kell: a szolgáltatók legtöbbje mutatja a ténylegesen használt jogosultságokat. Ami hónapok óta nincs használatban, azt el lehet venni.
A statikus API-kulcs, ami sosem jár le, és jellemzően egy konfigurációs fájlban vagy forráskódban van. Ha kiszivárog, korlátlan ideig használható.
Amit tenni kell: rövid életű, automatikusan megújuló hitelesítés (szerep-alapú hozzáférés) a statikus kulcs helyett. Ahol elkerülhetetlen, ott rotáció és titok-kezelő.
A felhős adminisztrátori fiók a legértékesebb célpont: onnan minden erőforrás elérhető, törölhető, és új is indítható.
Amit tenni kell: MFA kivétel nélkül minden konzol-hozzáférésre, lehetőleg hardveres kulccsal a legmagasabb jogúaknál.
A felhős naplózás sok szolgáltatónál nem alapértelmezett, vagy csak rövid ideig őrződik meg. Incidens esetén ez dönti el, hogy rekonstruálható-e, mi történt.
Amit tenni kell: naplózás minden régióban, központi gyűjtés külön fiókba, amit a napi működéshez használt jogosultsággal nem lehet törölni.
A titkosítás a legtöbb szolgáltatónál egy kapcsoló, mégis gyakran kimarad, különösen a mentéseknél és a pillanatképeknél.
Amit tenni kell: titkosítás alapértelmezettként, saját kulcskezeléssel ott, ahol az adat érzékenysége indokolja.
Adatbázis vagy adminisztrációs felület, ami az egész internetről elérhető, mert így volt egyszerűbb a beállítás.
Amit tenni kell: a menedzsment-felületek csak meghatározott IP-tartományból vagy ZTNA-n keresztül. Az adatbázis soha ne legyen publikus.
Az árnyék-IT. Egy-egy osztály saját fiókot nyit bankkártyával, és senki nem tud róla. A proxy-naplókból kilistázható, mely felhőszolgáltatásokat érik el a szervezetből.
A több fiók. Ahol tíz fiók van, ott tíz helyen kell ugyanazt beállítani. A szervezeti szintű házirend (organization policy) az, ami ezt egyben kezeli.
A kód nélküli változtatás. Ha a konfiguráció kézzel készül a konzolon, akkor nincs változáskezelés és nincs visszaállítás. Az infrastruktúra kódként megközelítés ezt oldja meg.
Az egyszeri átvizsgálás kevés, mert a felhős környezet naponta változik. A CSPM típusú eszközök folyamatosan nézik a konfigurációt, és jeleznek, ha valami elcsúszik.
Kisebb környezetben a szolgáltató saját, beépített ellenőrzése is elég lehet, ha valaki tényleg nézi a jelentéseket. A naplózásról a naplózásról szóló cikkünkben írtunk részletesen.
Átfogó IT biztonsági szolgáltatások, tűzfalak, WAF, IPS, SIEM, DLP és végpontvédelem az ARLITECH-től.
A legtöbb incidensvizsgálat azon bukik el, hogy a döntő napló nincs meg vagy már felülíródott. Melyik…
Miért rossz a 90 naponta kötelező jelszócsere, mi a helyes hosszúsági szabály, és hogyan vezessen be…
Szakértőink szívesen átbeszélik, mit jelent mindez az Ön szervezetének környezetében.