Hogyan lehet a Zero Trust elveket valódi lépésekre bontani: identitás, eszközállapot, mikroszegmentálás és a legkisebb jogosultság elve, reális ütemezéssel.
A Zero Trust az elmúlt évek legtöbbet emlegetett és legfélreértettebb biztonsági fogalma. Nem termék, nem is egyetlen projekt, hanem egy tervezési elv: soha ne bízz meg semmiben alapértelmezetten, mindig ellenőrizz. Ez a cikk arról szól, hogyan lehet ebből az elvből konkrét, ütemezhető lépéseket csinálni.
A hagyományos biztonsági modell a periméterre épült: van egy „kint" és egy „bent", a tűzfal pedig a kettő között áll. Aki bejutott a hálózatra, az többé-kevésbé megbízhatónak számított.
Ez a modell három okból omlott össze:
Nincs többé egyértelmű perem. Felhőszolgáltatások, távmunka, mobil eszközök, szállítói hozzáférések, az erőforrások és a felhasználók egyaránt a hálózaton kívül vannak.
A támadók a peremen belülről dolgoznak. A tipikus incidens phishinggel vagy egy ellopott jelszóval indul. Ekkor a támadó definíció szerint „bent" van, és a peremvédelem semmit nem ér.
A laterális mozgás olcsó. Egy lapos belső hálózaton egyetlen kompromittált munkaállomásról az egész szervezet elérhető.
A Zero Trust válasza: minden hozzáférési kérést külön-külön, a kontextus ismeretében kell elbírálni, függetlenül attól, honnan érkezik.
A NIST SP 800-207 és az iparági gyakorlat alapján a Zero Trust öt területre bontható. Nem kell mindet egyszerre, de mindegyikkel foglalkozni kell.
1. Identitás. Minden hozzáférés egy erős, ellenőrzött identitáshoz kötődik. Ez a legfontosabb pillér: ha az identitás gyenge, a többi nem számít.
2. Eszköz. A hozzáférés feltétele az eszköz állapota: felügyelt-e, naprakész-e, fut-e rajta védelem.
3. Hálózat. Mikroszegmentálás: a hálózat nem egy nagy megbízható zóna, hanem sok kicsi, közöttük ellenőrzött átjárással.
4. Alkalmazás és adat. Az alkalmazások nem a hálózati elhelyezkedés alapján engednek be, az adatok pedig osztályozottak és titkosítottak.
5. Láthatóság és analitika. Minden hozzáférési döntés naplózott, és a naplók elemzése visszahat a szabályokra.
Ha egyetlen dolgot csinálsz, ez legyen az. A hitelesítő adatok ellopása a leggyakoribb kezdeti behatolási vektor, és a többtényezős hitelesítés ennek túlnyomó részét megállítja.
Néhány gyakorlati pont:
A második legnagyobb hozamú lépés. A legtöbb szervezetnél a jogosultságok idővel felhalmozódnak: valaki átkerül egy másik osztályra, de a régi hozzáférései megmaradnak.
Amit érdemes megtenni:
Ez a pillér ijeszti el a legtöbb szervezetet, mert nagynak tűnik. Fokozatosan viszont kezelhető.
Első kör: kritikus rendszerek elkülönítése. A tartományvezérlők, a mentési infrastruktúra és a pénzügyi rendszerek kerüljenek saját szegmensbe, szigorúan definiált beengedett forgalommal. Már ez is jelentősen megnehezíti a laterális mozgást.
Második kör: felhasználói és szerverhálózat szétválasztása. Egy munkaállomásnak semmi keresnivalója nincs egy másik munkaállomás adminisztratív portjain, a kliens-izoláció olcsó és hatásos.
Harmadik kör: alkalmazásszintű szegmentálás. Az egyes alkalmazások csak azzal beszélhetnek, amivel muszáj.
A hozzáférési döntésbe be kell vonni az eszközt is. Egy nem felügyelt, ismeretlen állapotú gépről érkező bejelentkezés más elbírálást érdemel, mint egy vállalati, naprakész eszközről érkező.
Praktikus szintek:
Ezekből feltételes hozzáférési szabályok építhetők: nem megfelelő eszközről csak korlátozott funkcionalitás, vagy csak böngészős, letöltés nélküli hozzáférés.
Ipari környezetben a Zero Trust elvei érvényesek, de a megvalósítás más. A vezérlőeszközökre nem telepíthető ügynök, és a folyamatos hitelesítés sem értelmezhető egy PLC esetében.
Amit át lehet ültetni:
Az ICS/SCADA biztonságról szóló cikkünk ezt részletesen tárgyalja.
Egy Zero Trust bevezetés jellemzően 18–36 hónap, és sosem „készül el" teljesen. Egy működő sorrend:
0–6. hónap. MFA minden felhasználóra, SSO-konszolidáció, adminisztrátori fiókok szétválasztása, eszközleltár, a mentési infrastruktúra izolálása.
6–12. hónap. Feltételes hozzáférés eszközállapot alapján, jogosultsági felülvizsgálati folyamat, just-in-time admin, kritikus rendszerek szegmentálása.
12–24. hónap. Felhasználói/szerverhálózat szétválasztása, alkalmazásszintű hozzáférés (VPN kiváltása), adatosztályozás.
Folyamatosan. Naplózás és analitika, a szabályok finomhangolása, rendszeres tesztelés, a penetrációs teszt itt méri, hogy a szegmentálás valóban működik-e.
Termékként kezelni. Egyetlen gyártó sem ad „Zero Trust megoldást". A meglévő eszközeid nagy részéből is sokat ki lehet hozni.
A felhasználói élményt figyelmen kívül hagyni. Ha a biztonság túl sok súrlódást okoz, a felhasználók megkerülik. A kockázatalapú hitelesítés (ahol az alacsony kockázatú, ismerős kontextusból érkező hozzáférés zökkenőmentes) nem gyengeség, hanem feltétele a bevezetés sikerének.
Az örökölt rendszereket kihagyni. Pont azok jelentik a kockázatot. Ha nem modernizálhatók, kompenzáló kontroll kell köréjük: szigorú szegmentálás, ugródeszka-szerver, fokozott monitorozás.
Egyszerre mindent. A fokozatos, mérhető lépések működnek. Minden kör után mérd, mennyivel csökkent a támadási felület.
Ha szeretnéd felmérni, hol tartasz, az IT biztonsági szolgáltatásaink között az architektúra-felülvizsgálat pontosan ezt a kérdést járja körül.
Átfogó IT biztonsági szolgáltatások, tűzfalak, WAF, IPS, SIEM, DLP és végpontvédelem az ARLITECH-től.
Új generációs tűzfal tervezés, telepítés és felügyelt szolgáltatások az ARLITECH-től: Fortinet, Check…
Mi a különbség a sérülékenységvizsgálat és a penetrációs teszt között, milyen gyakran érdemes tesztelni,…
Szakértőink szívesen átbeszélik, mit jelent mindez az Ön szervezetének környezetében.