Du vil gerne modernisere jeres sikkerhedsarkitektur - og Zero Trust lyder som det rigtige svar.

Måske har du allerede siddet til 2-3 vendor-præsentationer, hvor alle lover 'ZTNA', 'context-based access' og 'identitetsbaseret sikkerhed'?

Men så har du måske også bemærket, at slidesne ligner hinanden mistænkeligt meget.

Så er der ikke noget at sige til, at du måske er usikker på, om det virkelig er en ny arkitektur - eller bare jeres nuværende VPN med nye features.

For i værste fald kan I jo investere 12-18 måneder og et betydeligt budget på en "ZTNA-løsning", der ikke fundamentalt ændrer noget.

Men...

‍

Efter at have implementeret Zero Trust i over 30 danske organisationer, har vi bemærket noget interessant:

Mange af de løsninger der markedsføres som 'ZTNA' (Zero Trust Network Access) fungerer stadig med VPN-arkitektur - bare med moderne features oven på.

Legacy vendors som Cisco, Fortinet og Palo Alto tilføjer MFA, device posture checks og micro segmentation til deres eksisterende platforme - og kalder det "Zero Trust".

Men grundmekanismen forbliver ofte den samme: Log ind → Få netværksadgang → Trusted session.

Og hvad bliver resultatet? IT-chefer investerer i 'ZTNA' og opdager typisk 12-18 måneder senere at grundarkitekturen - den måde trust fundamentalt fungerer - er fuldstændig uændret.

I denne artikel får du svar på hvorfor det sker - og:

• En konkret test der afslører hvor enforcement sker: netværkslaget eller applikationslaget
• Forklaring på den fundamentale forskel og hvorfor den betyder noget
• 5 spørgsmål der afslører om en leverandør leverer VPN-arkitektur eller ægte Zero Trust

Er det ZTNA med VPN-arkitektur - eller ægte Zero Trust?

Lad os starte med et konkret eksempel - I overvejer en leverandørs "Zero Trust-løsning".

Her kan I teste dem og spørge:

"Hvad sker der når en remote medarbejder logger ind?"

Scenario A: "ZTNA" med VPN-arkitektur

Hvis svaret involverer at brugeren først autentificerer (selv med MFA og device checks), derefter får adgang til virksomhedsnetværket, og så kan tilgå systemer internt - så er det VPN-arkitektur. Selv om leverandøren kalder det "ZTNA".

Features er blevet kraftigt forbedret med MFA, conditional access, device posture og microsegmentation. Men grundmekanismen er identisk med traditionel VPN: Login etablerer tillid, adgang gives til netværket, og sessionen forbliver trusted indtil logout.

Scenario B: Ægte Zero Trust-arkitektur

Det rigtige svar bør være at brugeren autentificerer baseret på identity, device posture og context - og derefter får adgang til det specifikke system. Ikke netværket. Brugeren kan ikke browse netværket eller se andre ressourcer.

Dette er Zero Trust-arkitektur: Ingen netværksadgang gives, kun system-niveau adgang. Hvert system verificeres separat, og context vurderes kontinuerligt gennem hele sessionen.

Hvad kendetegner ægte Zero Trust teknisk?

Hvis leverandøren leverer ægte Zero Trust-arkitektur, vil løsningen have nogle tekniske karakteristika der afslører at enforcement sker på applikationslaget - ikke netværkslaget.

Outbound-only forbindelser betyder at ingen servere eller applikationer er synlige fra WAN. Klienten initierer altid forbindelsen efter identitetsverifikation. Dette er kritisk forskelligt fra VPN, hvor netværket eksponeres. Selv med mikrosegmentering på en VPN eksisterer der latente angrebsflader: protokoller som ARP, ICMP eller DNS discovery kan stadig misbruges til at probe netværket.

Software-defined segmentering på systemniveau betyder at adgang styres helt ned til det enkelte system - ikke baseret på IP-adresser eller subnets. Det er enforcement på applikationslaget, ikke netværkslaget. Hvert adgangsforsøg vurderes isoleret baseret på identitet og kontekst, ikke på hvor brugeren er "placeret" netværksmæssigt.

Dynamiske beslutninger baseret på kontekst træffes kontinuerligt gennem hele sessionen. Det handler ikke kun om brugernavn og password, men om hele konteksten: identitet, device posture, lokation, adfærd og tidspunkt. Og essentielt er det, at disse beslutninger træffes for hver applikation, kontinuerligt - ikke én gang ved netværksadgang.

Intelligent routing betyder at cloud-systemer tilgås direkte uden unødvendig detour gennem jeres datacenter. Dette er muligt fordi enforcement ikke er bundet til en central VPN-gateway på netværkslaget, men distribueret på applikationslaget.

‍

Hvorfor betyder det noget?

Fordi jeres organisation har ændret sig siden VPN var moderne:

Gartner's forskning viser at "more than 50% of all applications now reside outside of an on-premises network and data center."

Hvis mere end halvdelen af jeres systemer er M365, Salesforce, AWS - hvorfor skal remote brugere først "ind på netværket" for at tilgå dem?

Det skaber:

• Latency: Trafik omdirigeres gennem jeres VPN gateway tilbage til cloud
• Dårlig brugeroplevelse: Især når brugere arbejder fra forskellige lokationer
• Breach-radius: Hvis credentials kompromitteres, har angriberen netværksadgang

Hvad Zero Trust-arkitektur egentlig kræver

Gartner, der har haft en nøglerolle i at popularisere konceptet, definerer det således:

"Zero trust networking models replace implicit trust with continuously assessed risk/trust levels."

Men lad os gøre det endnu mere præcist: Den fundamentale forskel er ikke kun om brugeren får netværksadgang, men hvor og hvordan tillid vurderes og håndhæves - og gerne kontinuerligt og applikationsspecifikt frem for implicit og netværksbaseret.

Med andre ord: Zero Trust flytter enforcement fra netværkslaget til applikationslaget.

Hvis adgang afgøres på netværkslaget (IP, port, routing) er det altså VPN-arkitektur. Hvis adgang afgøres på applikations- eller identitetslaget (hvilken app, hvilken bruger, hvilket device, hvilken kontekst) - så er det Zero Trust.

Forskellen på implicit vs. continuously assessed trust

Implicit trust er kernen i VPN-arkitektur: Du logger ind, tillid etableres, og du er "trusted" indtil logout. Logikken er "du er inde på netværket = jeg stoler på dig = du kan bevæge dig frit". Dette gælder både traditionel VPN og "ZTNA" der giver netværksadgang efter login.

Continuously assessed risk er kernen i ægte Zero Trust: Hver systemadgang verificeres baseret på context. Hvem er du? Hvilken device? Hvor er du? Hvad vil du lave? Passer det med normal adfærd? Tillid er ikke binær (trusted/untrusted) - det er en kontinuerlig risikovurdering. Og kritisk vigtigt: Ingen netværksadgang gives, kun systemniveau adgang.

Analogi: "Velkommen ind… men kun i ét rum ad gangen"

Tænk på VPN-arkitektur som at få udleveret en nøgle til hele huset. Du logger på, du får netværksadgang (selv med MFA og device checks), og nu kan du "gå rundt i huset" og åbne døre du har adgang til. Hvis en hacker får dine credentials, har de samme frihed til at bevæge sig på netværket. Dette gælder både traditionel VPN og "ZTNA" der giver netværksadgang.

Ægte Zero Trust fungerer anderledes: Du får adgang til ét rum ad gangen. Skal du tilgå jeres CRM? Du verificeres og får adgang til CRM - ikke netværket. Du skal tilgå email? Du verificeres igen og får adgang til email. Du kan ikke "gå rundt" og se hvilke andre systemer der findes. Hvis en hacker får dine credentials, er skaden begrænset til den præcise applikation du tilgår på det tidspunkt.

Hvorfor Zero Trust er nødvendigt for jeres organisation

Måske tænker du: "Okay, så det er VPN-arkitektur med bedre features. Men det fungerer jo?"

Det gjorde det. Indtil jeres organisation ændrede sig.

Før gav VPN-arkitektur mening: Systemer eksisterede kun i jeres datacenter, medarbejdere sad på kontoret, og perimeter-sikkerhed var en fornuftig model.

Nu har virkeligheden ændret sig fundamentalt. Mere end 50% af jeres systemer er typisk SaaS-løsninger. Hybrid og remote-arbejde er standarden, og "perimeteren" er ikke længere et relevant koncept. Men mange "ZTNA-løsninger" giver stadig netværksadgang efter login - de har ikke tilpasset sig den nye virkelighed.

Dette skaber tre konkrete problemer - alle rodfæstet i at enforcement sker på netværkslaget:

For det første går jeres cloudsystemer unødvendigt gennem jeres infrastruktur. En remote bruger skal først via VPN til jeres datacenter for derefter at tilgå Microsoft 365 - som ligger i Microsofts cloud. Hvorfor? Fordi enforcement sker på netværkslaget i jeres datacenter. Med enforcement på applikationslaget kan brugeren tilgå MS365 direkte - og systemet verificerer identitet og kontekst uden en netværksdetour.

For det andet skaber enforcement på netværkslaget en større breach-radius. Når VPN-sessionen etableres på netværkslaget, og credentials bliver kompromitteret, har angriberen netværksadgang. Selv med mikrosegmentering eksisterer latente protokoller (ARP, ICMP, DNS) der kan misbruges til at probe netværket. Med enforcement på applikationslaget har angriberen kun adgang til den specifikke applikation - ikke netværket.

For det tredje kræver ethvert nyt system/applikation en specifik netværkskonfiguration. Skal trafikken gennem VPN? Nye firewall-regler? Split-tunnel konfiguration? Dette er symptomatisk for enforcement på netværkslaget - hver ændring kræver netværkskonfiguration. Med enforcement på applikationslaget defineres policies centralt: "Sælgere må tilgå CRM fra managed devices" - ingen netværkskonfiguration nødvendig.

Kort sagt: I stedet for at bygge sikkerhed ud fra hvor brugeren er forbundet fra (netværkslaget), bygger man den på hvem brugeren er, hvilken applikation, og hvilke policies der gælder (applikationslaget).

Gartner beskriver problemet præcist:

"Network security designs based on perimeter security appliances are ill-suited to address the dynamic anywhere, anytime needs of modern digital business."

Hvorfor sælges VPN-arkitektur som "ZTNA"?

Det er ikke fordi leverandører lyver. Det er fordi features og arkitektur bliver blandet sammen - og fordi nogle features faktisk er betydelige fremskridt.

Legacy vendors som Cisco, Fortinet og Palo Alto tilføjer MFA og kalder det "Zero Trust authentication". De tilføjer device posture checks og kalder det "Zero Trust access". De tilføjer microsegmentation og kalder det "Zero Trust network".

Og vi lægger os fladt ned: Disse features er værdifulde og repræsenterer ægte sikkerhedsforbedringer. Microsegmentation reducerer reelt lateral movement. Continuous verification er bedre end session-based trust. Device posture checks giver bedre kontrol.

Men - og dette er det kritiske - hvis enforcement stadig sker på network layer, forbliver det arkitektonisk en VPN-model. Så længe brugeren får netværksadgang efter login, og dataplanen er netværksbaseret, har vi ikke flyttet enforcement til applikationslaget.

Legacy vendors er etableret med VPN-løsninger der fungerer fremragende til hvad de er designet til. Problemet er ikke at VPN er "dårligt" - problemet er at det ikke er designet til hybride cloud-infrastrukturer hvor 50%+ af systemerne er eksterne.

Forskellen er fundamental: Features kan tilføjes til eksisterende arkitektur. Arkitektur kræver redesign af hvor enforcement sker. Man kan tilføje microsegmentation til VPN, men man kan ikke flytte enforcement fra netværkslaget til applikationslaget uden fundamentalt redesign.

5 spørgsmål til næste vendor-møde

Næste gang en leverandør præsenterer deres "Zero Trust-løsning", kan disse fem spørgsmål give jer klarhed om hvorvidt enforcement sker på netværkslaget eller applikationslaget.

Spørgsmål 1: "Kan remotebrugere browse netværket efter login?"

Hvis svaret er ja, indikerer det enforcement på netværkslaget. Ægte Zero Trust for remote users giver kun adgang til specifikke systemer - brugeren får aldrig synlighed på netværket. Dette er ikke bare en sikkerhedsfeature - det afslører hvor enforcement sker. Hvis brugeren kan se netværket, sker enforcement på network layer (IP, port, routing).

‍

Spørgsmål 2: "Verificeres kontekst kun ved login - eller kontinuerligt?"

Hvis verification kun sker ved login, indikerer det enforcement på netværkslaget med session-based trust. Gartner's definition er klar: "continuously assessed risk/trust levels". Continuous verification kræver enforcement på applikationslaget - for hver applikation, gennem hele sessionen. Hvis sessionen er trusted efter login (netværkslaget), har vi implicit trust.

‍

Spørgsmål 3: "Hvor defineres og håndhæves policies?"

Hvis policies defineres lokalt i hver appliance, indikerer det enforcement på netværkslaget (perimeter-tænkning). Zero Trust kræver at policies defineres centralt men håndhæves distribueret på applikationslaget. Bemærk: SD-WAN edge devices med cloud-baseret policy management er ikke problematisk - det afgørende er at policies håndhæves på applikationslaget, ikke at der er hardware.

‍

Spørgsmål 4: "Kan I håndhæve samme policies på tværs af alle adgangsmetoder?"

Hvis der er forskellige policies for forskellige kanaler, har vi en fragmenteret model. Zero Trust kræver unified policies - én policy, håndhævet alle steder. Dette er hvor mange legacy-løsninger fejler, fordi de har vokset sig sammen af separate produkter.

‍

Spørgsmål 5: "Skal brugere først 'komme på netværket' for at tilgå SaaS-apps?"

Hvis svaret er ja, indikerer det enforcement på netværkslaget. Ægte Zero Trust til cloud systemer giver direkte adgang til applikationen - enforcement sker på applikationslaget uden detour gennem jeres netværk. Hvorfor? Fordi enforcement ikke er bundet til en centralt gateway på netværkslaget. Dette gælder primært SaaS-apps - on-prem apps kan kræve anden routing, men grundprincippet om enforcement på applikationslaget gælder stadig.

‍

3 Red Flags der ofte indikerer enforcement på netværkslaget

Udover de fem spørgsmål, er der tre klassiske red flags i ved præsentation af VPN i ZTNA forklædning:

Første red flag: De taler primært om features (MFA, device checks, microsegmentation) frem for hvor enforcement sker. Spørg direkte: "Håndhæves adgang på netværkslaget eller applikationslaget?" Features som microsegmentation er værdifulde fremskridt, men de flytter ikke enforcement-niveau.

Andet red flag: De siger "det er en opgradering til jeres eksisterende VPN-platform". Ægte Zero Trust-arkitektur kræver typisk redesign af enforcement-niveau, ikke en opgradering. Du kan ikke flytte enforcement fra netværkslaget til applikationslaget uden fundamentalt redesign.

Tredje red flag: De beskriver det som "VPN med Zero Trust-funktionalitet". Dette afslører præcist at enforcement forbliver på netværkslaget med moderne features oven på. Unified Zero Trust-arkitektur kræver enforcement på applikationslaget konsistent på tværs af hele løsningen.

Næste udfordring: Kompleksitet

Nu forstår du den fundamentale forskel: hvor enforcement sker.

Du ved hvorfor continuously assessed risk kræver enforcement på applikationslaget - ikke netværkslaget.

Du forstår hvorfor microsegmentation og continuous verification på VPN er fremskridt, men ikke flytter enforcement-niveau.

Og du har fem konkrete spørgsmål der afslører om en leverandør leverer enforcement på netværkslaget eller applikationslaget.

Men selv hvis I vælger en ægte Zero Trust-baseret løsning - står I stadig over for én massiv udfordring: Jeres eksisterende miljø.

Mange organisationer har 10-15 forskellige vendors, policies spredt over 7-8 systemer, og separate netværks- og sikkerhedsteams. Gartner observerer at "the vast majority of enterprise SASE adoptions take three to five years."

Hvorfor tager det så lang tid? Fordi det ikke kun handler om teknologi. Det handler om at konsolidere kompleksitet i organisationen.

I næste artikel ser vi på den udfordring: Hvorfor kompleksitet er Zero Trust's største fjende.

Stay tuned!