Most ez folyik minden csapból - vagy ha még nem is, de hamarosan mindenképpen, tekinthető a legújabb buzzwordnek is. Mindazonáltal itt jóval többről van szó, mint egy új termékről, valójában a Zero Trust biztonsági modell egy újfajta megközelítése a biztonságnak.
A Zero Trust Networköt (találkozhatunk vele Zero Trust Architecture-ként is) 10 éve találta ki John Kindervag. A modell elsődleges ismérve, hogy leszámol a megbízhatónak tartott hálózati zónákkal és eszközökkel, függetlenül attól, hogy azok az adott szervezet hálózatán kívülről, vagy belülről jönnek.
Első olvasatra furcsának tűnhet ez, azt gondolhatja az ember, hogy jelentős mértékben akadályozhatja a napi munkát, ha a belső erőforrások is teljes mértékben szeparáltnak számítanak.
A jelenleg uralkodó trendek mindenképpen arrafelé mutatnak, hogy megbízhatatlannak tekintsük a belső hálózatot is. A szoftverek egyre bonyolultabbak, egyre több réteg épül egymásra pl. egy web alkalmazás miatt, sok esetben ezek nem is a cég DC-jében futnak, hanem valamilyen külső szolgáltató infrastruktúráján, legyen az szimple web hosting vagy a skála másik végén lévő cloud.
A komplexitás növekedése természetesen igaz a kliens oldali szoftverekre is, beleértve az operációs rendszert is. Egyre több és több kényelmi funkciókat nyújtanak, ezzel együtt nő a karbantartandó kódbázis is.
Természetesen maguk a különböző hálózati eszközök komplexitása is növekszik, elég, ha az SDN-SDWAN-SDP különböző - elsősorban szoftveres - rétegeire gondolunk.
Mindezeken felül ott van a mindig leggyengébb láncszemnek számító Layer 8 - az emberi tényező is. A munkához számítógépet használók elsöprő többsége nem érti, mi bújik meg a dobozban, meg nem is érdekli, de ha még értene hozzá és érdekelné is, normális céges policy nem engedi, nem engedheti akárkinek a magas szintű hozzáférést (pl. OS frissítések telepítéséhez).
A fentiekből kifolyólag a Zero Trust modell megbízhatatlannak tekint mindent és mindenkit. Ha valami/valaki el akar érni egy erőforrást, akkor a modell alapján ellenőrzik, majd újra és újra és újra... Kicsit sánta példa, de képzeljük el azt, mondjuk egy desktop Linux rendszeren minden egyes programindításkor be kellene írnunk a jelszavunkat. Nyilván ha mindezt manuálisan kellene csinálni, értelmét vesztené a modell, hiszen a használhatatlanságig lassítaná a munkát, ebből következően teljesen automatizált a folyamat (a user kliensoldali belépését kivéve). A háttérben azonban mindennek és mindenkinek megvan a saját maga certifikációja, amely minden vonatkozó információt tartalmaz: milyen szintű hozzáférése van a felhasználónak az erőforráshoz, milyen típusú OS fut a gépén, annak mi az update státusza, milyen egyéb védelmi mechanizmusok találhatók rajta, mi a biztonsági státusza, a felhasználó alkalmazásai milyen frissítési szinten állnak, milyen hálózatból és melyik napszakban érkezik az erőforrás-hozzáférési kérelem.
Tulajdonképpen a modell nem más, mint egy nagy rakás policy gyűjtemény.
Elég sok dokumentációt lehet találni a modellről - legfőképpen angolul - és természetes módon mindegyik leírás (amit eddig találtam) az első ponttól indul. Valójában nekem az a véleményem, hogy elindulhatunk egy nulladik ponttól, amiből az összes többi eredeztethető.
A hagyományos felsorolás így néz ki:
0. Make sure your organization is mature enough for Zero Trust
Ez a zéró pont mind közül a legfontosabb: amíg egy szervezet nem elég érett a modellhez, kimondottan nem ajánlott belefogni a modell megvalósításába. Mire gondolok? Néhány egyszerű példa: nincs BYOD policy, nincs remote work policy, nincs kötelező VPN a távolról dolgozóknak, többfaktoros autentikáció, biztonságtudatosság, szegmentált hálózat stb. Ha egy ilyen szervezet belekezd a megvalósításba, abból csak káosz és elérhetetlen rendszerek lesznek, nem pedig emelt szintű biztonság.
Tegyük fel, hogy egy szervezet elég fejlett a biztonság terén ahhoz, hogy belekezdjen ebbe az utazásba. Első lépésként mindenképpen javasolt egy kicsi résszel kezdeni, ahol nem futnak üzleti kritikus szolgáltatások. Ez nem helyezi extra nyomás alá az implementációs csoportot és lehetőséget ad a finomhangolásra. Egészen biztosan lesznek olyan alkalmazások/szolgáltatások, amelyek nem kompatibilisek a modellel, a jó megoldás megtalálása időbe kerülhet. Azt is érdemes meggondolni, hogy a pilot szakasz befejezésével melyek azok az üzleti kritikus folyamatok, amelyek ténylegesen megkövetelik a Zero Trust jelenlétét.
Néhány tévhit a Zero Trust modellről:
Mi is a Zero Trust?
A Zero Trust Networköt (találkozhatunk vele Zero Trust Architecture-ként is) 10 éve találta ki John Kindervag. A modell elsődleges ismérve, hogy leszámol a megbízhatónak tartott hálózati zónákkal és eszközökkel, függetlenül attól, hogy azok az adott szervezet hálózatán kívülről, vagy belülről jönnek.
Első olvasatra furcsának tűnhet ez, azt gondolhatja az ember, hogy jelentős mértékben akadályozhatja a napi munkát, ha a belső erőforrások is teljes mértékben szeparáltnak számítanak.
A jelenleg uralkodó trendek mindenképpen arrafelé mutatnak, hogy megbízhatatlannak tekintsük a belső hálózatot is. A szoftverek egyre bonyolultabbak, egyre több réteg épül egymásra pl. egy web alkalmazás miatt, sok esetben ezek nem is a cég DC-jében futnak, hanem valamilyen külső szolgáltató infrastruktúráján, legyen az szimple web hosting vagy a skála másik végén lévő cloud.
A komplexitás növekedése természetesen igaz a kliens oldali szoftverekre is, beleértve az operációs rendszert is. Egyre több és több kényelmi funkciókat nyújtanak, ezzel együtt nő a karbantartandó kódbázis is.
Természetesen maguk a különböző hálózati eszközök komplexitása is növekszik, elég, ha az SDN-SDWAN-SDP különböző - elsősorban szoftveres - rétegeire gondolunk.
Mindezeken felül ott van a mindig leggyengébb láncszemnek számító Layer 8 - az emberi tényező is. A munkához számítógépet használók elsöprő többsége nem érti, mi bújik meg a dobozban, meg nem is érdekli, de ha még értene hozzá és érdekelné is, normális céges policy nem engedi, nem engedheti akárkinek a magas szintű hozzáférést (pl. OS frissítések telepítéséhez).
A fentiekből kifolyólag a Zero Trust modell megbízhatatlannak tekint mindent és mindenkit. Ha valami/valaki el akar érni egy erőforrást, akkor a modell alapján ellenőrzik, majd újra és újra és újra... Kicsit sánta példa, de képzeljük el azt, mondjuk egy desktop Linux rendszeren minden egyes programindításkor be kellene írnunk a jelszavunkat. Nyilván ha mindezt manuálisan kellene csinálni, értelmét vesztené a modell, hiszen a használhatatlanságig lassítaná a munkát, ebből következően teljesen automatizált a folyamat (a user kliensoldali belépését kivéve). A háttérben azonban mindennek és mindenkinek megvan a saját maga certifikációja, amely minden vonatkozó információt tartalmaz: milyen szintű hozzáférése van a felhasználónak az erőforráshoz, milyen típusú OS fut a gépén, annak mi az update státusza, milyen egyéb védelmi mechanizmusok találhatók rajta, mi a biztonsági státusza, a felhasználó alkalmazásai milyen frissítési szinten állnak, milyen hálózatból és melyik napszakban érkezik az erőforrás-hozzáférési kérelem.
Tulajdonképpen a modell nem más, mint egy nagy rakás policy gyűjtemény.
Szükséges feltételek a modell sikeres alkalmazásához
Elég sok dokumentációt lehet találni a modellről - legfőképpen angolul - és természetes módon mindegyik leírás (amit eddig találtam) az első ponttól indul. Valójában nekem az a véleményem, hogy elindulhatunk egy nulladik ponttól, amiből az összes többi eredeztethető.
A hagyományos felsorolás így néz ki:
- Know your architecture including users, devices, and services
- Create a single strong user identity
- Create a strong device identity
- Authenticate everywhere
- Know the health of your devices and services
- Focus your monitoring on devices and services
- Set policies according to value of the service or data
- Control access to your services and data
- Don’t trust the network, including the local network
- Choose services designed for zero trust
0. Make sure your organization is mature enough for Zero Trust
Ez a zéró pont mind közül a legfontosabb: amíg egy szervezet nem elég érett a modellhez, kimondottan nem ajánlott belefogni a modell megvalósításába. Mire gondolok? Néhány egyszerű példa: nincs BYOD policy, nincs remote work policy, nincs kötelező VPN a távolról dolgozóknak, többfaktoros autentikáció, biztonságtudatosság, szegmentált hálózat stb. Ha egy ilyen szervezet belekezd a megvalósításba, abból csak káosz és elérhetetlen rendszerek lesznek, nem pedig emelt szintű biztonság.
Tegyük fel, hogy egy szervezet elég fejlett a biztonság terén ahhoz, hogy belekezdjen ebbe az utazásba. Első lépésként mindenképpen javasolt egy kicsi résszel kezdeni, ahol nem futnak üzleti kritikus szolgáltatások. Ez nem helyezi extra nyomás alá az implementációs csoportot és lehetőséget ad a finomhangolásra. Egészen biztosan lesznek olyan alkalmazások/szolgáltatások, amelyek nem kompatibilisek a modellel, a jó megoldás megtalálása időbe kerülhet. Azt is érdemes meggondolni, hogy a pilot szakasz befejezésével melyek azok az üzleti kritikus folyamatok, amelyek ténylegesen megkövetelik a Zero Trust jelenlétét.
Záró gondolatok
A Zero Trust különböző megvalósításaival találkozhatunk néhány igazi óriásnál. Találkozhatunk vele a Google-nél, a Cisco-nál, Akamainál, Cloudflare-nél - a felsorolás nyilvánvalóan nem teljes. A Forrester szerint a modell bevezetése legalább 37%-kal csökkentette a kockázati kitettséget (risk exposure), mindeközben lehetőséget ad a biztonsági költségek - egyes esetekben - 31%-os csökkentésére.Néhány tévhit a Zero Trust modellről:
- meglévő hálózat teljes kukázása. Jogos felvetés, de ilyesmire nincs szükség. A szegmentációs átjárókat hozzá lehet adni a meglévő hálózathoz, definiálni a policy-ket.
- a modell drága és akadályozza a mindennapi munkát. Mivel csak a meglévő hálózatot kell bővíteni és nem kell a régebbi eszközöket kidobni, a költségek alacsonyan tarthatók. Elérhetetlen erőforrások csak a bevezetés idején várhatók, a policy-k finomhangolásával ezek megszűnnek.
- a modell az endpointon valósítható meg. Ott IS. Ha csak a felhasználói végpontokra korlátozzuk a modell implementálását, kifizettük a pénzt a szükséges eszközökre, de nem kapjuk meg azt a hatékonyságot, amit a modell nyújtani tud, ha már a hálózati szinten elkezdjük a megvalósítást.
- a modell nem használható a publikus felhőszolgáltatásokban. Ez kifejezetten rossz felvetés. Mostanság egyre gyakoribb, hogy az alkalmazások a privát adatközpontokból a publikus felhőkbe kerülnek. Fel kell tenni a kérdést, hogy akkor hol húzódik a saját hálózatunk határvonala? A kérdésre adandó válasz a hagyományos hálózatszervezés keretein belül többféle is lehet, miközben a Zero Trust modell egyféle és egyértelmű választ ad.
Comments
Post a Comment