Erstatt VPN med ZTNA: den tryggere tilnærmingen til hybridarbeid

Hvorfor VPN er blitt en sikkerhetsrisiko

VPN-arkitekturer hviler på en enkel antagelse: enhver som kan etablere en tunnel inn i bedriftsnettverket, bør få lov til å operere derinne. Den antagelsen feiler i moderne miljøer på fire konkrete måter.

Lateral bevegelse. Så snart en angriper kompromitterer en VPN-pålogging (phishing, credential stuffing, malware på endpoint), har han tilgang på nettverksnivå. Fra det utgangspunktet er lateral bevegelse til sensitive systemer i stor grad uhindret, fordi perimeteren betrodde ham.

For bred tilgang. VPN-er gir tilgang til nettverkssegmenter, ikke til spesifikke applikasjoner. En bruker som trenger én applikasjon, får synlighet til alt i sitt subnet. Minst-privilegium-prinsippet mangler strukturelt.

Ytelse og skalering. VPN-konsentratorer er fysiske eller virtuelle flaskehalser. Etter hvert som den hybride arbeidsstyrken vokser, har bedrifter stablet appliances oppå hverandre og lagt til kompleksitet i skaleringen. Ytelsen forringes, supportbyrden stiger.

Audit-usynlighet. VPN-logs viser typisk vellykkede tilkoblinger, ikke hva som ble gjort under sesjonen. En revisor som spør "hvilke applikasjoner nådde entreprenør X i går?", får i beste fall upresise svar.

Hvordan ZTNA virker: minst-privilegium, kontinuerlig verifikasjon og enhets-posture

ZTNA snur VPN-modellen. I stedet for å gi nettverkstilgang gir ZTNA applikasjonstilgang. Brukeren autentiserer seg, plattformen vurderer kontekst, plattformen oppretter en begrenset, tidsavgrenset, applikasjonsspesifikk forbindelse. Alt annet forblir usynlig.

De tekniske byggesteinene er identitet, kontekst og posture. Identitet betyr sterk autentisering, typisk inklusive MFA og integrasjon med bedriftens identity provider. Kontekst omfatter lokasjon, tidspunkt, forespørselsmønster og atferdsbaseline. Posture betyr sanntidsverifikasjon av enheten: OS-versjon, patch-nivå, endpoint-beskyttelsesstatus, sertifikatsgyldighet.

Hvis en faktor endrer seg midt i sesjonen (enhets-posture forringes, atferd avviker fra baseline, lokasjon skifter uventet), revurderes tilgangsbeslutningen. Sesjoner som startet gyldig, kan trekkes tilbake dynamisk.

Universal ZTNA fra Cato: én policy for alle, overalt

De fleste ZTNA-produkter bygges oppå eksisterende infrastruktur: en separat gateway, en separat policy-motor, en separat klient. Universal ZTNA på Cato SASE-plattformen er annerledes. Det kjører som innebygd kapasitet på samme cloud-native plattform som leverer SD-WAN, SSE og AI Security.

De praktiske implikasjonene er viktige. Én policy-motor betyr én samlet policyramme for kontormedarbeidere, remote-medarbeidere, entreprenører, leverandører og maskinidentiteter. Én klient (eller clientless via nettleser for ikke-administrerte enheter) betyr lavere endpoint-kompleksitet. Ett audit trail betyr at alle tilgangsbeslutninger, uavhengig av brukerkategori, havner i samme datalager.

For bedrifter som har administrert tre separate tilgangsregimer (VPN for medarbeidere, separat portal for entreprenører, føderert tilgang for partnere), konsoliderer Universal ZTNA dette i én driftsmodell.

BYOD og entreprenører: den glemte angrepsvektoren

De fleste VPN-arkitekturer håndterer administrerte enheter rimelig godt. Der de feiler, er ved BYOD og entreprenører: personlige telefoner, entreprenør-laptoper, leverandøringeniørers arbeidsstasjoner. Enten får de samme nettverkstilgang som administrerte enheter (en reell risiko), eller de får en tungvint separat portal som driver brukere mot omveier.

ZTNA håndterer det elegant. Posture checks skiller i sanntid mellom administrerte og ikke-administrerte enheter, policy tilpasser tilgangsomfanget tilsvarende. En entreprenør på en ikke-administrert laptop kan få lesetilgang til prosjekt-fildelingen uten VPN, bedriftens ingeniør på en administrert laptop får full tilgang pluss andre ressurser. Samme policyramme, forskjellige vurderingsresultater.

Det er også her NIS2s forsyningskjedesikkerhetskrav blir konkret. ZTNA produserer de bevisene tilsynsmyndigheter forventer: hvilken leverandør, med tilgang til hva, når, med hvilken enhets-posture.

ZTNA og NIS2: påviselig tilgangskontroll overfor revisorer

NIS2 artikkel 21 krever tilgangskontroll og identitetsstyring. Tilsynsmyndigheten forventer bevis, ikke policy på papir. ZTNA genererer disse bevisene som biprodukt av normal drift: hver tilgangsbeslutning logget med identitet, enhet, kontekst og policyreferanse.

For samsvarsrapportering er det forskjellen mellom en flere uker lang bevisinnsamling på tvers av tolv verktøy og en konsolleksport. Vi pakker den bredere NIS2-samsvarshistorien ut i artikkelen vår om NIS2 og SASE.

Migrering: kjør parallelt, fasé deretter VPN ut

En pragmatisk ZTNA-migrering kjører VPN og ZTNA parallelt i tre til seks måneder. Høyverdi-applikasjoner skifter først til ZTNA, supportteamet overvåker brukeropplevelsen og finsliper policy. Når det første settet av applikasjoner er stabilt på ZTNA, følger det neste settet. VPN-et fasés ut når applikasjonsdekningen er komplett.

Cato-implementeringsmønsteret reflekterer det: Universal ZTNA aktiveres uten å deaktivere legacy-VPN-et umiddelbart. Kunder styrer migreringstidslinjen basert på operasjonell beredskap, ikke på en leverandørs cutover-plan.