Zero Trust enkelt förklarat: ZTNA i stället för klassisk VPN
Zero Trust betyder inte att ingen längre betros. Det betyder att åtkomst inte längre ges brett bara för att en användare finns i det interna nätet, i VPN eller på en känd plats. Varje åtkomst kontrolleras medvetet: vem ansluter? Från vilken enhet? Till vilken applikation? Under vilka villkor?
Zero Trust Network Access, eller ZTNA, är en konkret tillämpning av denna idé för remote access och privata applikationer. I stället för att öppna ett helt nätverk via VPN får en användare bara åtkomst till de applikationer eller resurser som är avsedda för rollen.
Den här artikeln förklarar grunderna avsiktligt leverantörsneutralt. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access och andra lösningar tillämpar liknande principer på olika sätt. Det första beslutet är därför inte produkten, utan åtkomstmodellen.
Placera Zero Trust och ZTNA
Zero Trust är en säkerhetsarkitektur. ZTNA är en teknisk åtkomstväg inom denna arkitektur.
Zero Trust är en princip
Klassiska nätverk arbetar ofta med ett tyst antagande: insidan är mer betrodd än utsidan. I dag är det antagandet farligt. Användare arbetar mobilt, applikationer finns i SaaS, datacenter och cloud, enheter byter ständigt plats och komprometterade inloggningsuppgifter är realistiska.
Zero Trust flyttar fokus från nätverksgränser till identitet, enhet, applikation, data och kontext. NIST beskriver Zero Trust som en arkitektur som minskar implicit förtroende och utvärderar åtkomst per begäran. I praktiken räcker en lyckad inloggning inte längre.
ZTNA är åtkomst till konkreta resurser
ZTNA ersätter bred nätverksåtkomst med resursbaserad åtkomst. En användare ser inte automatiskt ett helt subnet, utan bara de applikationer där en policy matchar.
Typiska ZTNA-resurser är:
- interna webbapplikationer,
- adminportaler,
- RDP- eller SSH-åtkomst via kontrollerade vägar,
- enskilda TCP-applikationer,
- utvecklings-, support- eller partneråtkomst,
- SaaS-applikationer med extra åtkomstkontroll.
Därmed blir remote access mer finstyrd. Ett komprometterat konto ska inte omedelbart kunna nå hela det interna nätverket.
Varför ZTNA skiljer sig från VPN
VPN är inte automatiskt dåligt. Många miljöer behöver fortfarande site-to-site VPN, admin-VPN, specialprotokoll eller nödfallstillgång. Skillnaden ligger i förtroendemodellen.
VPN öppnar ofta ett nätverk
En klassisk remote access VPN ansluter en enhet till ett internt nätverk. Därefter avgör routing, brandväggsregler, DNS och segmentering vad som är nåbart. Om miljön är rent byggd kan det fungera. I praktiken är VPN-nät ofta för breda, historiskt vuxna eller svåra att granska.
Typiska risker är:
- Användare får åtkomst till fler system än nödvändigt.
- Gamla VPN-grupper blir kvar.
- Split tunnel, DNS och rutter är oklara.
- Malware på en VPN-klient kan nå interna mål.
- Adminåtkomst använder samma tunnel som användaråtkomst.
ZTNA kontrollerar närmare applikationen
ZTNA beslutar per applikation eller resurs. En policy kan ta hänsyn till användargrupp, MFA, enhet, plats, risk, klientstatus och andra villkor. Först när villkoren matchar tillåts åtkomst till exakt den resursen.
Det minskar attackytan, men ersätter inte säker applikationsdesign. En osäker applikation förblir osäker även bakom ZTNA. ZTNA kontrollerar åtkomsten, inte automatiskt själva applikationen.
Byggstenar i en bra Zero Trust-miljö
Zero Trust blir svagt om det bara införs som ett nytt åtkomstverktyg. Värdet uppstår när flera byggstenar passar ihop.
Identitet och MFA
Identiteten är den viktigaste ingångspunkten. Användare, grupper, roller och externa konton måste underhållas rent. MFA bör vara obligatoriskt för kritisk åtkomst. I Microsoft-miljöer är Microsoft Entra ID ofta den centrala identitetskällan; i andra miljöer kan andra Identity Providers ha samma roll.
Offboarding är också viktigt. När en användare lämnar företaget ska åtkomst försvinna inte bara i en applikation, utan i central identitet och alla relevanta policies.
Enhet och kontext
ZTNA blir starkare när inte bara användaren utan också enheten utvärderas. Beroende på lösning kan operativsystem, enhetsstatus, certifikat, EDR-status, managementstatus, plats eller risk påverka beslutet.
Detta är särskilt relevant för:
- privata enheter,
- externa tjänsteleverantörer,
- privilegierad adminåtkomst,
- åtkomst till finance-, HR- eller produktionssystem,
- enheter utan aktuell skyddsstatus.
Gateway, connector eller cloudtjänst
ZTNA behöver en dataväg mellan användare och applikation. Beroende på leverantör finns gateways, connectors, tunnlar eller cloud-PoPs. Denna del avgör var trafiken går in, vem som driver datavägen och vilka DNS-, certifikat- och brandväggsregler som behövs.
Cloudflare arbetar ofta med Cloudflare Tunnel och Access Policies. Sophos ZTNA använder Sophos Central, ZTNA Gateways och resource policies. Arkitekturen skiljer sig, men grundfrågan är densamma: hur når en användare kontrollerat applikationen utan att öppna hela nätverket?
Policies, logging och drift
En ZTNA-policy måste vara begriplig även senare. Därför bör namn, grupper, villkor och undantag dokumenteras. Logging är obligatoriskt, eftersom man annars inte ser om en policy är för bred, användare blockeras eller åtkomst används oväntat ofta.
När ZTNA är meningsfullt
ZTNA passar särskilt bra när enskilda applikationer ska vara åtkomliga på ett kontrollerat sätt. Det är inte ett självändamål och inte en automatisk ersättning för varje anslutning.
Bra användningsfall
ZTNA är oftast meningsfullt för:
- interna webbapplikationer för medarbetare,
- partner- eller tjänsteleverantörsåtkomst,
- adminportaler som inte ska vara publikt åtkomliga,
- RDP eller SSH via kontrollerade åtkomstvägar,
- applikationer med tydliga användargrupper,
- miljöer där VPN-åtkomst blivit för bred,
- stegvis ersättning av gamla remote access-modeller.
Särskilt för externa tjänsteleverantörer är ZTNA ofta smidigare än VPN. Man behöver inte öppna ett helt nätverk, utan kan publicera en konkret applikation med tydlig policy.
Där VPN fortfarande passar
VPN är fortsatt användbart när hela nätverk måste kopplas ihop, när specialprotokoll inte fungerar rent via ZTNA eller när nödfallstillgång måste vara oberoende av cloudtjänster. Site-to-site-länkar, vissa OT-miljöer, legacy-applikationer och komplexa adminscenarier kan fortfarande kräva VPN.
Rätt fråga är därför inte: “VPN eller ZTNA?” Bättre är: “Vilken resurs behöver vilken åtkomstväg?”
Utvärdera leverantörer neutralt
ZTNA-lösningar skiljer sig mycket. Vissa är mycket bra för webbläsarbaserade applikationer, andra för klientbaserad åtkomst och andra som del av en bredare SSE- eller SASE-plattform.
Viktiga urvalskriterier
Före produktval bör dessa punkter klargöras:
- Vilka applikationer ska vara åtkomliga?
- Behövs webbläsaråtkomst, klientåtkomst eller båda?
- Vilken Identity Provider är redan bestämd?
- Ska enheter kontrolleras baserat på posture?
- Var finns datavägen: egen plats, leverantörens cloud eller båda?
- Hur fungerar logs, SIEM-export och audit?
- Finns tydliga nödfalls- och break-glass-processer?
- Hur väl passar lösningen med befintliga brandväggar, EDR, MDM och DNS?
Cloudflare är ofta starkt när Access, Tunnel, DNS, web security och global edge-infrastruktur ska samverka. Sophos ZTNA passar ofta bra i miljöer som redan använder Sophos Central, Sophos Endpoint eller Sophos Firewall mycket. Det är ingen trosfråga, utan arkitekturarbete.
Inte varje Zero Trust är automatiskt bättre
Dåligt underhållet ZTNA är bara en modernare risk. Om grupper är för breda, gamla undantag finns kvar, ingen läser logs eller enhetskontroll bara finns på papper, skapas ingen stark Zero Trust-miljö.
Inför i rimlig ordning
En bra införandeprocess börjar inte med produktklicket, utan med en liten, väl förstådd applikation.
- Inventera applikationer och sortera efter risk.
- Rensa användargrupper och externa roller.
- Stabilisera Identity Provider och MFA.
- Välj en pilotapplikation som är viktig men hanterbar.
- Planera dataväg, DNS, certifikat och logging.
- Testa policyn med en liten användargrupp.
- Granska logs, samla supportfall och förbättra användarupplevelsen.
- Migrera fler applikationer stegvis.
- Minska VPN-åtkomst först när ZTNA fungerar i drift.
För Sophos-specifika miljöer passar sedan Konfigurera Sophos ZTNA: översikt och ordning. Om det konkret gäller gateway hjälper Planera och skapa Sophos ZTNA Gateway.
Typiska fel
Behandla ZTNA som ren VPN-ersättning
Om bara tunneln ersätts, men grupper, applikationer, enheter och logs förblir oförändrade, blir säkerhetsvinsten liten. ZTNA bör planeras per resurs.
Migrera för många applikationer samtidigt
En stor big-bang-utrullning är riskabel. Bättre är en pilot med en verklig applikation, tydliga framgångskriterier och en ren fallback-väg.
Glömma nödfallstillgång
Identity Provider, DNS, cloudtjänst eller gateway kan falla bort. Admins behöver dokumenterad break-glass-åtkomst som är starkt skyddad, sällan används och regelbundet kontrolleras.
Inte driva loggarna
ZTNA utan logging är svårt att supporta. Det ska gå att se vilken användare som når vilken resurs, vilken policy som gäller, varför åtkomst blockerades och om ovanliga mönster uppstår.
Driftchecklista
- Dokumentera applikationer och owners.
- Håll användargrupper små och begripliga.
- Kräv MFA för kritisk åtkomst.
- Använd enhetskontroll aktivt om lösningen stödjer det rent.
- Granska policies regelbundet mot verklig användning.
- Skicka logs till SIEM eller central logging om åtkomsten är kritisk.
- Dokumentera och testa break-glass-åtkomst.
- Ta bort gamla VPN-behörigheter efter lyckad migrering.
- Ge tjänsteleverantörsåtkomst ett utgångsdatum eller reviewdatum.