Erstat VPN med ZTNA: den sikrere tilgang til hybridarbejde

Hvorfor VPN er blevet en sikkerhedsrisiko

VPN-arkitekturer hviler på en simpel antagelse: enhver der kan etablere en tunnel ind i virksomhedsnetværket, bør have lov til at operere derinde. Den antagelse fejler i moderne miljøer på fire konkrete måder.

Lateral bevægelse. Så snart en angriber kompromitterer et VPN-login (phishing, credential stuffing, malware på endpoint), har han netværksniveau-adgang. Fra det udgangspunkt er lateral bevægelse til følsomme systemer i vid udstrækning uhindret, fordi perimeteren betroede ham.

For bred adgang. VPN'er giver adgang til netværkssegmenter, ikke til specifikke applikationer. En bruger der har brug for én applikation, får synlighed til alt i sit subnet. Mindst-privilegium-princippet mangler strukturelt.

Ydelse og skalering. VPN-koncentratorer er fysiske eller virtuelle flaskehalse. I takt med at den hybride arbejdsstyrke vokser, har virksomheder stablet appliances oven på hinanden og tilføjet kompleksitet til skaleringen. Ydelsen forringes, supportbyrden stiger.

Audit-usynlighed. VPN-logs viser typisk vellykkede forbindelser, ikke hvad der blev gjort under sessionen. En revisor der spørger "hvilke applikationer tilgik entreprenør X i går?", får i bedste fald upræcise svar.

Hvordan ZTNA virker: mindst-privilegium, kontinuerlig verifikation og enheds-posture

ZTNA vender VPN-modellen om. I stedet for at give netværksadgang giver ZTNA applikationsadgang. Brugeren autentificerer sig, platformen vurderer kontekst, platformen opretter en begrænset, tidsafgrænset, applikationsspecifik forbindelse. Alt andet forbliver usynligt.

De tekniske byggesten er identitet, kontekst og posture. Identitet betyder stærk autentificering, typisk inklusive MFA og integration med virksomhedens identity provider. Kontekst omfatter lokation, tidspunkt, anmodningsmønster og adfærdsbaseline. Posture betyder realtidsverifikation af enheden: OS-version, patch-niveau, endpoint-beskyttelsesstatus, certifikatsgyldighed.

Hvis en faktor ændrer sig midt i sessionen (enheds-posture forringes, adfærd afviger fra baseline, lokation skifter uventet), revurderes adgangsbeslutningen. Sessioner der startede gyldigt, kan tilbagekaldes dynamisk.

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

De fleste ZTNA-produkter bygges oven på eksisterende infrastruktur: en separat gateway, en separat politikmotor, en separat klient. Universal ZTNA på Cato SASE-platformen er anderledes. Det kører som indbygget kapacitet på samme cloud-native platform, der leverer SD-WAN, SSE og AI Security.

De praktiske implikationer er vigtige. Én politikmotor betyder én samlet politikramme for kontormedarbejdere, remote-medarbejdere, entreprenører, leverandører og maskinidentiteter. Én klient (eller clientless via browser for ikke-administrerede enheder) betyder lavere endpoint-kompleksitet. Ét audit trail betyder, at alle adgangsbeslutninger, uanset brugerkategori, lander i samme datalager.

For virksomheder der har administreret tre separate adgangsregimer (VPN for medarbejdere, separat portal for entreprenører, fødereret adgang for partnere), konsoliderer Universal ZTNA dette i én driftsmodel.

BYOD og entreprenører: den glemte angrebsvektor

De fleste VPN-arkitekturer håndterer administrerede enheder rimeligt godt. Hvor de fejler, er ved BYOD og entreprenører: personlige telefoner, entreprenør-laptops, leverandøringeniørers arbejdsstationer. Enten får de samme netværksadgang som administrerede enheder (en reel risiko), eller de får en besværlig separat portal som driver brugere mod omveje.

ZTNA håndterer det elegant. Posture checks skelner i realtid mellem administrerede og ikke-administrerede enheder, politikker tilpasser adgangsomfanget tilsvarende. En entreprenør på en ikke-administreret laptop kan få læseadgang til projekt-fildelingen uden VPN, virksomhedens ingeniør på en administreret laptop får fuld adgang plus andre ressourcer. Samme politikramme, forskellige vurderingsresultater.

Det er også her, NIS2's forsyningskædesikkerhedskrav bliver konkret. ZTNA producerer de beviser, tilsynsmyndigheder forventer: hvilken leverandør, med adgang til hvad, hvornår, med hvilken enheds-posture.

ZTNA og NIS2: påviselig adgangskontrol over for revisorer

NIS2 artikel 21 kræver adgangskontrol og identitetsstyring. Tilsynsmyndigheden forventer beviser, ikke politik på papir. ZTNA genererer disse beviser som biprodukt af normal drift: hver adgangsbeslutning logget med identitet, enhed, kontekst og politikreference.

For overholdelsesrapportering er det forskellen mellem en flere uger lang bevisindsamling på tværs af tolv værktøjer og en konsoleksport. Vi pakker den bredere NIS2-overholdelseshistorie ud i vores artikel om NIS2 og SASE.

Migrering: kør parallelt, fasér derefter VPN ud

En pragmatisk ZTNA-migrering kører VPN og ZTNA parallelt i tre til seks måneder. Højværdiapplikationer skifter først til ZTNA, supportteamet overvåger brugeroplevelsen og finsliber politikker. Når det første sæt applikationer er stabilt på ZTNA, følger det næste sæt. VPN'et fases ud, når applikationsdækningen er komplet.

Cato-implementeringsmønsteret afspejler det: Universal ZTNA aktiveres uden at deaktivere legacy-VPN'et øjeblikkeligt. Kunder styrer migreringstidslinjen baseret på deres operationelle parathed, ikke på en leverandørs cutover-plan.