VPN helyett ZTNA: mikor és miért

A klasszikus VPN a teljes hálózatot adja oda. Mit csinál másképp a Zero Trust hálózati hozzáférés, mibe kerül az átállás, és mikor nem éri meg.

A VPN azért terjedt el, mert egyszerű: a távoli felhasználó úgy dolgozik, mintha az irodában ülne. Pontosan ez a probléma vele. Ha egy laptop kompromittálódik, a támadó is úgy dolgozik, mintha az irodában ülne.

Mi a különbség

Klasszikus VPN ZTNA
Mit ad oda Hálózati hozzáférést Alkalmazás-hozzáférést
Alapértelmezés Bejutott, tehát megbízható Minden kérés külön elbírálva
Láthatóság Az alkalmazások a hálózaton látszanak Csak az látszik, amihez joga van
Eszközállapot Jellemzően nem számít A döntés része
Naplózás Kapcsolat szintjén Alkalmazás- és művelet szintjén

A lényegi különbség: a VPN után a felhasználó a hálózaton van, a ZTNA után egy adott alkalmazásnál. Ami nincs kifejezetten engedélyezve, az nem is látszik, tehát fel sem deríthető.

Mikor éri meg váltani

Ha sok a külső fél. Szállítók, alvállalkozók, karbantartók. Ezeknek VPN-t adni azt jelenti, hogy rálátnak a hálózatra. ZTNA-val csak azt látják, amin dolgozniuk kell.

Ha felhős alkalmazások dominálnak. A VPN a forgalmat a központba tereli, majd onnan a felhőbe, ami felesleges kerülő. A ZTNA közvetlenül, de ellenőrizve enged.

Ha eszközállapotot akar figyelembe venni. Nem felügyelt gépről ne legyen ugyanolyan hozzáférés, mint vállalatiról.

Ha a VPN-koncentrátor a szűk keresztmetszet. Sok szervezetnél a távmunka óta ez a legterheltebb elem.

Mikor ne váltson

Ha örökölt, nem HTTP-alapú alkalmazások dominálnak. A ZTNA-megoldások jelentős része webes protokollra optimalizált. Régi kliens-szerver alkalmazásoknál a támogatás egyenetlen.

Ha nincs rendben az identitás. A ZTNA az identitásra épül. Ha nincs központi azonosítás és MFA, a váltás nem old meg semmit, csak drágább lesz.

Ha az OT-hálózat a cél. Ipari környezetben a szállítói hozzáférés kezelése más eszközt igényel: ugródeszka-szerver, munkamenet-rögzítés, igény szerinti aktiválás. Erről az ICS/SCADA cikkünkben írtunk.

A sorrend számít. Előbb központi identitás és MFA, aztán eszközkezelés, és csak utána ZTNA. Fordítva a projekt megakad, mert a ZTNA-nak nincs mire épülnie.

Az átállás lépései

1. Alkalmazás-leltár. Mit érnek el ma a felhasználók VPN-en? A tapasztalat szerint a lista rövidebb, mint gondolnánk, és tele van olyannal, amit már senki nem használ.

2. Kezdje egy alkalmazással. Egy jól körülhatárolt, webes alkalmazás, egy kisebb felhasználói körrel. Innen tanulja meg a szervezet a mintát.

3. Külső felek másodikként. Itt a legnagyobb a kockázatcsökkenés, és a felhasználói ellenállás a legkisebb, mert nekik úgyis új a folyamat.

4. Párhuzamos üzem. A VPN maradjon élesben, amíg a ZTNA le nem fedi a fő használati eseteket. A kikapcsolás legyen tudatos döntés, ne kényszer.

5. A VPN kivezetése. Ez gyakran évekig húzódik az örökölt alkalmazások miatt. Amíg van VPN, az MFA és a szegmentálás ott is kell.

Amit gyakran elfelejtenek

A ZTNA nem helyettesíti a végpontvédelmet. Ha a gép fertőzött, a ZTNA a fertőzött gépet engedi be az alkalmazáshoz.

A naplózás beállítása. A ZTNA egyik legnagyobb előnye a részletes napló, de ez alapból nem kerül a SIEM-be. Erről a naplózásról szóló cikkünkben írtunk.

A rendelkezésre állás. A ZTNA-átjáró kritikus útvonalba kerül. Ha kiesik, senki nem dolgozik. Redundancia és tesztelt kiesési forgatókönyv kell hozzá.

A szélesebb architektúra-kérdésekről a Zero Trust útmutatóban írtunk részletesen.

Vissza a Tudástárba
Kapcsolódó tartalom

Kapcsolódó tartalom

Kérdése van a témában?

Szakértőink szívesen átbeszélik, mit jelent mindez az Ön szervezetének környezetében.