Ersätt VPN med ZTNA: den säkrare approachen för hybridarbete

Varför VPN har blivit en säkerhetsrisk

VPN-arkitekturer vilar på ett enkelt antagande: alla som kan etablera en tunnel in i företagsnätverket är betrodda att operera inuti det. Det antagandet misslyckas i moderna miljöer på fyra konkreta sätt.

Lateral rörelse. När en angripare kompromissar en VPN-uppgift (phishing, credential stuffing, malware på endpunkten) har de åtkomst på nätverksnivå. Från det fotfästet är lateral rörelse till känsliga system till stor del obehindrad eftersom perimetern litade på dem.

Alltför bred åtkomst. VPN ger åtkomst till nätverkssegment, inte till specifika applikationer. En användare som behöver en applikation får synlighet till allt i sitt subnät. Minsta-behörighet-principen saknas strukturellt.

Prestanda och skala. VPN-koncentratorer är fysiska eller virtuella flaskhalsar. När hybridarbetsstyrkan växte staplade organisationer appliances och lade till komplexitet för att skala. Prestandan försämras, support-belastningen ökar.

Audit-osynlighet. VPN-loggar visar typiskt lyckade anslutningar, inte vad som gjordes under sessionen. En revisor som frågar "vilka applikationer kom underleverantör X åt igår?" får på sin höjd opreciserade svar.

Hur ZTNA fungerar: minsta behörighet, kontinuerlig verifiering och enhets-posture

ZTNA inverterar VPN-modellen. Istället för att ge nätverksåtkomst ger ZTNA applikationsåtkomst. Användaren autentiserar sig, plattformen utvärderar kontext, plattformen skapar en begränsad, tidsbegränsad, applikationsspecifik anslutning. Allt annat förblir osynligt.

De tekniska byggstenarna är identitet, kontext och posture. Identitet betyder stark autentisering, typiskt inklusive MFA och integration med företagets identity provider. Kontext inkluderar plats, tid på dygnet, förfrågningsmönster och beteendebaslinje. Posture betyder realtidsverifiering av enheten: OS-version, patch-nivå, endpunkt-skyddsstatus, certifikatsgiltighet.

Om någon faktor ändras mitt i sessionen (enhets-posture försämras, beteende avviker från baslinjen, plats skiftar oväntat) omvärderas åtkomstbeslutet. Sessioner som började giltiga kan återkallas dynamiskt.

Universal ZTNA från Cato: en policy för alla, överallt

De flesta ZTNA-produkter är fastskruvade på en befintlig infrastruktur: en separat gateway, en separat policy-motor, en separat klient. Universal ZTNA på Cato SASE-plattformen är annorlunda. Det körs som inbyggd funktion på samma cloud-native plattform som levererar SD-WAN, SSE och AI Security.

De praktiska implikationerna är viktiga. En policy-motor betyder ett enda policy-ramverk för kontorsanställda, fjärrarbetare, underleverantörer, leverantörer och maskinidentiteter. En klient (eller klientlös via webbläsare för ohanterade enheter) betyder lägre endpunkt-komplexitet. En audit trail betyder att alla åtkomstbeslut, oavsett användarkategori, landar i samma datalagring.

För organisationer som har hanterat tre separata åtkomstregimer (VPN för anställda, separat portal för underleverantörer, federerad åtkomst för partners) komprimerar Universal ZTNA det till en driftsmodell.

BYOD och underleverantörer: den glömda angreppsvektorn

De flesta VPN-arkitekturer hanterar hanterade enheter någorlunda väl. Där de misslyckas är BYOD och underleverantörer: personliga telefoner, underleverantörs-laptops, leverantörs-ingenjörs-arbetsstationer. Antingen får de samma nätverksåtkomst som hanterade enheter (en verklig risk) eller får de en klumpig separat portal som driver användare till genvägar.

ZTNA hanterar detta elegant. Posture-kontroller skiljer hanterade från ohanterade enheter i realtid; policys justerar åtkomstomfattning därefter. En underleverantör på en ohanterad laptop kan få läsåtkomst till projektets filresurs utan VPN; företagets ingenjör på en hanterad laptop får full åtkomst plus andra resurser. Samma policy-ramverk, olika utvärderingsresultat.

Det är också här NIS2:s supply chain-säkerhetskrav blir konkret. ZTNA producerar bevisen tillsynsmyndigheter förväntar sig: vilken leverantör, med åtkomst till vad, när, med vilken enhets-posture.

ZTNA och NIS2: påvisbar åtkomstkontroll för revisorer

NIS2 Artikel 21 kräver åtkomstkontroll och identitetshantering. Tillsynsmyndigheten förväntar sig bevis, inte policys på papper. ZTNA genererar dessa bevis som biprodukt av normal drift: varje åtkomstbeslut loggat med identitet, enhet, kontext och policy-referens.

För efterlevnadsrapportering är detta skillnaden mellan en flerveckors bevissamlings-övning över tolv verktyg och en konsol-export. Vi packar upp den bredare NIS2-efterlevnadshistorien i vår artikel om NIS2 och SASE.

Migration: parallell drift, sedan VPN-pension

En pragmatisk ZTNA-migration kör VPN och ZTNA parallellt i tre till sex månader. Högvärdiga applikationer flyttar till ZTNA först; support-teamet övervakar användarupplevelse och förfinar policys. När det första uppsättningen applikationer är stabil på ZTNA följer nästa. VPN-pension kommer när applikationstäckningen är komplett.

Cato-implementeringsmönstret speglar detta: Universal ZTNA aktiveras utan att omedelbart inaktivera det äldre VPN:et. Kunder kontrollerar migrationstidplanen baserat på sin driftberedskap, inte på ett leverantörscutover-schema.