Hoe je van VPN naar ZTNA overstapt: een zesstappenplan voor middelgrote bedrijven

In de meeste handleidingen voor het vervangen van een VPN door ZTNA wordt een architectuur beschreven. Dat is niet het moeilijke deel. Het moeilijke deel is dat je VPN al elf jaar in gebruik is en niemand een volledig overzicht heeft van wat er allemaal via het netwerk loopt.

Dit is eerder een reeks dan een betoog: zes stappen, met de benodigde input voor elke stap, het resultaat dat deze oplevert, hoe lang het daadwerkelijk duurt en op welke specifieke manier het misgaat. Wanneer in de gepubliceerde bronnen een tijdsduur wordt vermeld, wordt deze overgenomen. Wanneer dat niet het geval is, wordt dit duidelijk aangegeven in plaats van een getal in te vullen dat er netter zou uitzien.

Eén cijfer bepaalt bovenal de verwachtingen. Voor een middelgrote organisatie met 100 tot 250 gebruikers geven benchmarks uit de sector aan dat een volledige vervanging van VPN door ZTNA twaalf tot zestien weken in beslag neemt, waarbij zestig tot zeventig procent van de inspanningen wordt besteed aan inventarisatie en identiteitswerk voordat ook maar één gebruiker er iets van merkt. Cloud-native organisaties met minder dan vijftig gebruikers voltooien dit in vier tot zes weken. Toen Indeed de toegang op afstand voor meer dan 13.000 werknemers en contractanten verving, bedroeg de totale doorlooptijd iets meer dan drie maanden.

Als je te horen hebt gekregen dat dit twee weken werk is, dan is dat het aantal waarmee je moet onderhandelen.

Waarom de volgorde belangrijker is dan het platform

Een VPN voor externe toegang voegt een eindpunt toe aan het netwerk. Het voert eenmalig authenticatie uit aan de rand, wijst een routeerbaar intern adres toe, en vanaf dat moment heeft de gebruiker bereikbaarheid op netwerkniveau binnen de interne subnetten, die alleen wordt beperkt door interne firewallregels en toegangslijsten die bijna niemand meer heeft herzien sinds ze zijn opgesteld.

ZTNA maakt de netwerkstap overbodig. In plaats van een apparaat op het netwerk aan te sluiten, regelt het een identiteits- en contextbewuste sessie tussen een geauthenticeerde gebruiker en één specifieke applicatie. Interne applicaties zijn helemaal niet bereikbaar vanaf het internet; connectoren die naast de workloads staan, zetten tunnels op die uitsluitend uitgaand verkeer naar een broker verwerken, zodat er geen inkomende listener is waarnaar gescand kan worden.

Dat verschil is de reden waarom de migratie geen simpele productwissel is. Alles wat stilletjes afhankelijk was van bereikbaarheid op netwerkniveau, moet eerst worden opgespoord en vervolgens opnieuw worden geformuleerd als een applicatie. Als je het opsporen overslaat, gebeurt het opnieuw formuleren om negen uur ’s ochtends op de dag van de omschakeling, in het bijzijn van iedereen.

De zes stappen

Stap	Uitvoerartefact	Realistische duur	Waarom het misgaat
1. Passieve verkeersdetectie	Toepassingsafhankelijkheidsmatrix	3 tot 4 weken	Monitoringperiode te kort om maandelijkse taken te detecteren
2. Modernisering van identiteitsbeheer	Overzichtelijke groepsstructuur, SSO-federatie, phishingbestendige MFA, baseline voor apparaatstatus	2 tot 4 weken	Oude AD-groepen worden in hun huidige vorm gemigreerd, waarbij platte vertrouwensrelaties opnieuw worden aangemaakt
3. Implementatie van connectoren en publicatie op het web	Redundante, uitsluitend uitgaande connectors per segment; interne webapps gepubliceerd	1 tot 2 weken	Uitgaand 443 geblokkeerd of connector-sessies die symmetrische NAT omzeilen
4. Proefgroep en afstemming van het beleid	Gevalideerde contextbewuste beleidsregels, split-DNS-configuratie, runbook voor de servicedesk	2 tot 3 weken	Eerst een verkeerde groep; randgevallen worden politieke problemen
5. Overgang per afdeling en parallelle werking	Goedkeuring per afdeling, dalend aantal VPN-sessies, dashboards voor latentie en authenticatie	4 tot 8 weken	Gebruikers schakelen ongemerkt terug naar de VPN, waardoor tekortkomingen in het beleid worden gemaskeerd
6. Buitengebruikstelling en archivering	Ontmantelingsverslag, scan van de buitenkant waaruit blijkt dat de aansluitingen zijn afgesloten, pakket met auditbewijsmateriaal	1 tot 2 weken	Het verwijderen van gedeelde cryptografische koppelingen en het beëindigen van site-to-site-tunnels

De doorlooptijden zijn afkomstig uit gepubliceerde benchmarks voor migraties in het middensegment en casestudies van leveranciers uit 2025 en 2026. Ze geven de verstreken tijd weer voor een typisch omgeving met 100 tot 250 gebruikers, niet het aantal gewerkte uren.

Stap 1: ga na wat er daadwerkelijk via de VPN wordt verzonden

Breng vier bronnen met elkaar in verband, want geen enkele bron ziet alles. Syslog-gegevens van de firewall en concentrator, gefilterd op de adrespool van de externe client, leveren je de basistupel op: identiteit, virtueel bron-IP-adres, bestemming, poort, protocol, volume. NetFlow- of IPFIX-collectors op kern-layer-3-switches vangen het oost-westverkeer op dat nooit de perimeter passeert en daarom nooit in firewalllogs verschijnt. Door het loggen van debug-query’s op interne DNS-servers worden afhankelijkheden blootgelegd van korte hostnamen en interne aliassen waarvan je het bestaan was vergeten. Telemetrie van eindpuntbeveiliging en apparaatbeheer koppelt actieve sockets aan de processen die ze hebben geopend; zo identificeer je aangepaste client-server-toepassingen die door niemand zijn gedocumenteerd.

Het resultaat is een matrix met applicatieafhankelijkheden: FQDN’s van bestemmingen, interne subnetten, protocollen, poorten, gebruikersgroepen, gelijktijdige sessies, piekbandbreedte, classificatie.

Laat het programma minstens één volledige maandcyclus draaien. Drie tot vier weken is de aangegeven periode, en de reden hiervoor is niet zozeer de grondigheid op zich: batchtaken aan het einde van de maand, salarisverwerkingen en geplande onderhoudsverbindingen met leveranciers komen slechts één keer voor.

Wat mensen vaak verbaast:

• Back-upagenten op laptops die, zodra er een tunnel tot stand komt, via SMB een synchronisatie op blokniveau van meerdere gigabyte starten.
• Beheersconsoles die afhankelijk zijn van door de server geïnitieerde bidirectionele communicatie om patches te installeren of de inventaris op te vragen, en die niet meer werken zodra de toegang uitsluitend door de gebruiker wordt geïnitieerd.
• Afdrukken en scannen: medewerkers op afstand die verbinding maken met kantoorprinters via TCP-poort 9100 of 515, en multifunctionele apparaten die scans rechtstreeks naar eindpuntadressen verzenden.
• Dynamische RPC-toepassingen die via TCP-poort 135 een handshake uitvoeren en vervolgens tijdelijke hoge poorten afspreken, die door geen enkel statisch beleid worden gedekt.
• De concentrator fungeert als transitrouter, waarbij gebruikers op afstand via site-to-site-tunnels die op hetzelfde apparaat uitkomen, toegang krijgen tot een tweede locatie of het extranet van een partner. Dit bepaalt stap 6.

Stap 2: identiteit is de feitelijke voorwaarde

ZTNA controleert de netwerkgrenzen niet. Het fungeert als een punt voor beleidsafdwinging dat beslissingen uitvoert op basis van de identiteitscontext. Als de identiteitsprovider vol staat met verouderde accounts, gedeelde beheerdersaccounts en geneste groepen die niemand begrijpt, neemt de ZTNA-implementatie al deze problemen over en geeft ze een nieuwe interface.

In NIST SP 800-207 wordt expliciet gesteld dat toegang per sessie wordt verleend, waarbij de regels dynamisch worden bepaald op basis van identiteit, rol, inloggegevens en omgevingscontext, en dat authenticatie en autorisatie worden afgedwongen voordat toegang wordt verleend. Het CISA Zero Trust Maturity Model, versie 2.0, beschrijft wat er nodig is om verder te gaan dan de traditionele aanpak binnen de identiteitspijler: het afschaffen van statische wachtwoorden en verouderde authenticatiemethoden, het centraliseren van federatie, het automatiseren van de gebruikerslevenscyclus via SCIM en het afdwingen van phishingbestendige MFA voor zowel interne als externe gebruikers.

Er moeten vijf voorwaarden vervuld zijn voordat het de moeite waard is om met stap 3 te beginnen:

1. Opruimen van de directory. Inactieve accounts zijn verwijderd, inloggegevens van externe medewerkers zijn gekoppeld aan een daadwerkelijke eigenaar, gedeelde beheerdersaccounts zijn afgeschaft en de SCIM-provisioning is gekoppeld aan het HR-systeem, zodat het intrekken van toegangsrechten automatisch verloopt in plaats van dat dit handmatig moet worden bijgehouden.
2. Groepen die ertoe doen. Diep geneste, overgeërfde groepen zijn vervangen door expliciete, op rollen en attributen gebaseerde groepen die zijn gekoppeld aan toegangsrechten voor applicaties. Een groep die naar een afdeling is vernoemd, is geen toegangsrecht.
3. Phishingbestendige MFA. FIDO2- en WebAuthn-factoren, waarbij sms-codes, telefoongesprekken en standaard pushmeldingen door de identiteitsprovider worden geblokkeerd, omdat deze drie worden omzeild door ‘man-in-the-middle’-proxyservers en door MFA-moeheid.
4. Voorwaardelijke toegang. Beleidsregels die het gebruikersrisico, onmogelijke reizen, de IP-reputatie en het tijdstip van de dag beoordelen voordat een token wordt uitgegeven.
5. Status van het apparaat. Platforms voor eindpuntbeheer en eindpuntbeveiliging die gegevens doorgeven aan de beleidsengine: patchstatus, schijfversleuteling, status van de lokale firewall, status van de agent.

Twee tot vier weken, afhankelijk van de omvang van de opgebouwde directory-achterstand. Dit is de stap die teams vaak proberen over te slaan, maar die bepalend is voor het succes van de rest van het proces.

Stap 3: connectoren en de eenvoudige toepassingen

Implementeer redundante, uitsluitend uitgaande connectors in elk intern netwerksegment of elke VPC, en publiceer vervolgens de interne webapplicaties. Web is de categorie met de laagste moeilijkheidsgraad: een ZTNA-platform fungeert als reverse proxy, connectoren halen de applicatie op via een uitgaande TLS-sessie en identiteitsclaims worden als headers ingevoegd, zodat single sign-on werkt zonder dat de backend hoeft te worden aangeraakt.

Eén tot twee weken. De oorzaak ligt eerder in de omgeving dan in het ontwerp: connectoren die zijn geplaatst achter restrictieve stateful firewalls of symmetrische NAT zonder dat er een permanente uitgaande verbinding via poort 443 is toegestaan, wat leidt tot periodieke verbroken verbindingen en time-outs bij de broker die lijken op platformstoringen, maar dat niet zijn.

Stap 4: voer een proefproject uit met de juiste mensen, in de juiste volgorde

Drie fasen, in deze volgorde, en daar is een reden voor.

Week 1 tot en met 2: IT-beheer en beveiligingstechniek. Mensen die verstand hebben van hoe DNS werkt, certificaatketens en transportdiagnostiek, en die een probleem nauwkeurig kunnen beschrijven in plaats van alleen maar te melden dat het internet niet werkt. Ze controleren de stabiliteit van de connector, de latentie-overhead en de private DNS-resolutie.

Week 3 tot en met 4: ontwikkelaars en DevOps. Intensieve gebruikers van niet-HTTP-protocollen: Git via SSH, databasetools, containerbeheer. Zij ondervinden problemen met microtunnels en de persistentie van terminals.

Week 5 tot en met 6: de kampioenen van de business units. Gebruikers op het gebied van administratie, HR en verkoop die met de kernsystemen ERP en CRM werken. Zij beoordelen wat de eerste twee groepen niet kunnen: of het systeem prettig in het gebruik is.

Opzettelijk uitgesloten van de eerste fasen: het uitvoerend management, de bestuursleden en het financiële team tijdens de maandafsluiting. Niet omdat hun tijd minder belangrijk is, maar omdat een uitzonderlijk geval waarmee een leidinggevende in week twee te maken krijgt, uitgroeit tot een politiek probleem dat het project een maand lang vertraagt.

Stap 5: de parallelle run, en voorkomen dat mensen achterop raken

Vier tot acht weken, en daar gaat het grootste deel van de verstreken tijd naartoe.

Het kernprobleem ligt in het gedrag. Een gebruiker die op de ZTNA-client op enige weerstand stuit, zal de verbinding verbreken en de VPN starten, omdat die nog steeds werkt. Die ene gewoonte maskeert alle configuratiefouten die je had moeten opsporen en maakt je migratiestatistieken zinloos. Er zijn twee maatregelen om dit te voorkomen, en beide hebben betrekking op de firewall in plaats van op de platformconfiguratie.

Het verlaten van de legacy-pool blokkeren. Zodra elke applicatie via ZTNA is gevalideerd, moet u de perimeter- en interne toegangslijsten bijwerken om verkeer naar het subnet van die applicatie vanuit de adrespool van de verouderde VPN-client te blokkeren. De applicatie is dan niet meer bereikbaar via het oude pad.

Verwijder de routes. Werk de routeringstabel bij die de concentrator naar clients stuurt, en verwijder daarbij de routes voor de specifieke host of het specifieke subnet van de gemigreerde applicaties, zodat het verkeer in de eerste plaats niet via de oude tunnel wordt geleid.

Pas alleen teruggroei toe op basis van vastgestelde cijfers, nooit op basis van sentiment. Drie kwantitatieve triggers is het de moeite waard om in het plan op te nemen voordat je begint: door de broker veroorzaakte round-trip-latentie van meer dan 250 milliseconden die gedurende een periode van vijftien minuten aanhoudt; fouten bij de validatie van tokens van identiteitsproviders bij meer dan twee procent van de autorisatiepogingen; of het wegvallen van database-recordvergrendelingen in een kernapplicatie voor de bedrijfsvoering. Al het andere is een defect dat moet worden verholpen, geen reden om te stoppen.

Stap 6: uit gebruik nemen zonder de connectiviteit van je tak te onderbreken

Dit is de stap die in geen enkele gepubliceerde handleiding aan bod komt, en het is juist deze stap die de productie kan stilleggen.

Op een mid-market edge-apparaat worden doorgaans zowel de clienttunnels voor externe toegang als de site-to-site IPsec-tunnels tussen uw vestigingen via hetzelfde apparaat beëindigd. Om de ene te verwijderen zonder de andere te verstoren, moet u een specifieke volgorde aanhouden:

1. Controleer eerst de bevestigingen. Controleer of de IKE-voorstellen, Diffie-Hellman-groepen en vooraf gedeelde sleutels of certificaten die worden gebruikt door site-to-site-tunnels daadwerkelijk gescheiden zijn van de inbelprofielen. Als er objecten zijn die ze delen, splits deze dan op voordat je iets aanraakt.
2. Maak de clientpools vrij. Verwijder de virtuele IP-pools, DHCP-scopes en authenticatiedomeinen die bij inbelgebruikers horen.
3. Sluit de listener af. Schakel de SSL VPN-portaalservice of de inbel-IPsec-daemon die aan de WAN-interface is gekoppeld, administratief uit.
4. Verwijder de inkomende regels. Verwijder de beleidsregels voor inkomend verkeer van buiten naar binnen die inkomend verkeer via poort 443 toestaan (waar deze was gereserveerd voor het portaal), UDP-poorten 500 en 4500 voor inbelverbindingen via IPsec, en UDP-poort 1194 waar OpenVPN in gebruik was.
5. Bewijs het van buitenaf. Voer externe poortscans uit op elk openbaar IP-adres dat u bezit en controleer of er geen daemon voor externe toegang reageert. De uitkomst van deze scan vormt het bewijs, niet de intentie.
6. Verwijder de clients. Zorg ervoor dat de verouderde VPN-software via apparaatbeheer stil wordt verwijderd; hierdoor wordt ook een netwerkfilterdriver verwijderd die anders voor altijd in de stack zou blijven zitten.

Welke toepassingen verlopen soepel, en welke vertragen het project?

Categorie	ZTNA-equivalent	Moeilijkheidsgraad	Veelvoorkomende belemmering
Interne webapplicaties	Reverse-proxy-broker met identiteitsclaims die als headers worden ingevoegd	Laag	Vastgelegde interne IP-adressen in de applicatiecode; NTLM in plaats van moderne identiteitsverificatie
Thick client en client-server	Op agenten gebaseerde lokale proxy op een synthetisch adres; expliciete poortdoorsturing	Gemiddeld tot hoog	Dynamische tijdelijke RPC-poorten; gevoelig voor latentie en jitter bij de handshake
SSH- en RDP-beheer	Identiteitsbewuste bastionproxy, tijdelijke certificaten of browsergeïsoleerde streaming	Laag tot gemiddeld	Weerstand tegen time-outs van sessies en beperkingen op het klembord; synchronisatie van de inloggegevenskluis
MKB en CIFS-bestandsshares	Microtunnel naar de FQDN van de dienst, het webportaal voor bestanden of migratie naar cloudopslag	Hoog. De belangrijkste reden voor stilstand.	Protocolcommunicatie die voorrang heeft boven latentie; snelle hostnaamomzetting; Kerberos SPN-conflicten
Spraak en video	Lokale breakout via split-tunneling via een beveiligde webgateway, of UCaaS in de cloud	Hoog	Proxy-architecturen kunnen symmetrische UDP RTP slecht verwerken; jitter en asymmetrische routing
IoT, OT en onbeheersbare apparaten	Microsegmentatie op netwerkniveau, hardware-gateways, van de browser geïsoleerde jump-hosts	Zeer hoog	Geen agent mogelijk; niet-routeerbare industriële protocollen zoals Modbus en BACnet
Aannemers en derden	Toegang via een browser zonder client, met isolatie van webapplicaties	Laag tot gemiddeld	Weigering om bedrijfsagenten te installeren op niet-bedrijfsapparatuur

Het SMB-probleem verdient een eigen alinea, omdat dit veruit de meest voorkomende reden is waarom deze projecten stilvallen. SMB is een ‘praatgraag’ protocol dat is ontworpen voor een lokaal netwerk: synchrone metadataverzoeken, sequentiële vergrendelingsonderhandelingen, voortdurende roundtrips. Zet het via een applicatieproxy over een internetverbinding, en de prestaties gaan niet geleidelijk achteruit, maar storten volledig in. Gebruikers krijgen te maken met vastgelopen bestandsverkenners, mislukte opslagpogingen en het wegvallen van toegewezen stations. Erger nog: SMB is afhankelijk van Kerberos dat gekoppeld is aan service principal names (SPN’s) van Active Directory. Als het platform dus de FQDN van de bestemming wijzigt of via synthetische adressen routeert, mislukt de ticketuitwisseling volledig.

Teams die deze hindernis nemen, lossen het SMB-probleem niet op. Ze omzeilen het door samenwerkingsgegevens te verplaatsen naar documentopslag in de cloud of door bestanden via een browserportaal te publiceren, en door te accepteren dat een klein aantal daadwerkelijke afhankelijkheden van de bestandsserver een smalle tunnel in stand houdt.

Waar deze projecten daadwerkelijk vastlopen

Afgezien van SMB komen er vier storingspatronen steeds weer voor.

Split-horizon DNS. ZTNA-agents onderscheppen DNS-verzoeken voor geautoriseerde privénamensruimten en leiden deze om naar synthetische, niet-routeerbare adressen om het verkeer via de tunnel te leiden. Wanneer een organisatie versnipperde DNS-zoekachtervoegsels heeft, of wanneer gebruikers korte hostnamen invoeren in plaats van volledig gekwalificeerde, vangen de regels van het naamomzettingsbeleid de query niet op. Deze lekt naar de openbare DNS, retourneert NXDOMAIN en de applicatie lijkt defect te zijn om redenen die niets te maken hebben met het toegangsbeleid.

Verloop van bron-IP-adressen. Sommige platforms richten per applicatieverzoek een onafhankelijke microtunnel in, waardoor het schijnbare bronadres van de client aan de backend verandert. Interne tools, load balancers en databases die zijn geconfigureerd met strikte sessie-affiniteit op basis van het bron-IP-adres, interpreteren dit als sessiekaping en beginnen verbindingen te verbreken of accounts te blokkeren.

Aanrijdingen door bestuurders. Op bedrijfs-endpoints draaien al verschillende netwerkfilterdrivers op kernelniveau: endpointbeveiliging, preventie van gegevensverlies, webfiltering en de verouderde VPN-adapter zelf. Het toevoegen van nog een virtuele adapter is een bekend probleem dat kan leiden tot blauwe schermen en defecte TCP-stacks. Test de volledige stack, en niet alleen het platform op zichzelf.

Uitzondering wildgroei. Een hooggeplaatste belanghebbende stuit op weerstand, er wordt een uitzondering toegestaan, en in de loop van achttien maanden stapelen de uitzonderingen zich op, totdat beveiligingscontroles en MFA-vereisten worden omzeild voor precies die accounts die het meest de moeite waard zijn om aan te vallen. Dit is eerder een tekortkoming op het gebied van governance dan een technische tekortkoming; daarom zijn de hierboven genoemde terugdraaimomenten kwantificeerbaar: ze bieden je iets concreets om naar te verwijzen dat geen mening is.

We hebben hierover meer geschreven in de artikelen “>‘Tien veelgemaakte fouten bij ZTNA’.

Wat de accountant achteraf wil zien

Voor EU-organisaties betekent deze migratie niet alleen een verbetering van de beveiliging, maar ook het bewijs dat jullie hiertoe al verplicht zijn.

Artikel 21, lid 2, onder i), van de NIS2-richtlijn schrijft beleidsregels voor toegangscontrole en activabeheer voor; artikel 21, lid 2, onder j), schrijft meervoudige of continue authenticatie en beveiligde communicatie voor. Een ‘flat’ VPN verleent ongesegmenteerd impliciet vertrouwen op basis van één enkele authenticatiehandeling, wat in beide gevallen moeilijk te verdedigen is.

Op grond van artikel 9, lid 4, van de DORA en de bijbehorende technische reguleringsnormen zijn het „minimale toegangsrecht”, sterke authenticatie, voortdurende monitoring van bevoorrechte sessies, fraudebestendige auditlogs van toegangsbeslissingen en formele, controleerbare processen voor het buiten gebruik stellen van verouderde ICT-systemen vereist. Die laatste bepaling is de reden waarom stap 6 een document oplevert in plaats van alleen een resultaat.

In België is CyberFundamentals het conformiteitskader van de CCB voor NIS2, en de auditmethode ervan werkt in twee lagen: een documentatielaag die aantoont dat de controles doelbewust worden beheerd, en een implementatielaag die aantoont dat ze daadwerkelijk worden uitgevoerd. Voor een migratie van de toegang op afstand betekent dit zowel het zero-trust-toegangsbeleid als de geëxporteerde configuraties, logstreams en statuscontroles die aantonen dat dit in de productieomgeving functioneert. Entiteiten die onder het toepassingsgebied vallen, moesten uiterlijk op 18 april 2026 maatregelen hebben getroffen die gelijkwaardig zijn aan CyFun-niveau Basic; voor de meeste Belgische organisaties is dit nu dus bewijsmateriaal dat moet worden onderhouden, in plaats van een deadline die moet worden gehaald.

Argumenten om de VPN te behouden

Een netwerkingenieur met een klein team en zonder budget zal zeggen dat de VPN werkt, dat het duidelijk is, dat de concentrator is gepatcht, dat er MFA voor zit, en dat deze hele operatie drie maanden werk kost om een probleem op te lossen dat zich nog niet heeft voorgedaan. Dat verdient een eerlijk antwoord in plaats van een slogan.

Twee aspecten daarvan kloppen. Als je concentrator up-to-date is, je MFA bestand is tegen phishing en je interne segmentatie daadwerkelijk wordt gehandhaafd, is je risico veel lager dan gemiddeld en geldt het argument van urgentie niet voor jou. En de schatting van de benodigde tijd klopt: twaalf tot zestien weken is geen marketingcijfer, maar komt overeen met wat de benchmarks aangeven.

Waar het argument echter geen rekening mee houdt, zijn de twee drijvende krachten die er hoe dan ook aankomen. Leveranciers schrappen de functie: Fortinet heeft SSL-VPN al uit zijn kleinere apparaten verwijderd en de tunnelmodus in het hele assortiment vervangen door IPsec, en het is niet de enige. En de verwachting bij audits is verschoven van „wordt toegang op afstand gecontroleerd?” naar „laat me de autorisatiebeslissingen per sessie zien”. Beide veranderen een project dat je zelf kon plannen in een project dat voor je wordt gepland.

De vraag is niet of VPN of ZTNA in abstracto beter is. Het gaat erom of je dit werk volgens een plan of onder tijdsdruk uitvoert.

Dit op de juiste manier aanpakken

Begin met stap 1 en niets anders. Schakel de vier telemetriebronnen in, laat ze een volle maand draaien en stel de afhankelijkheidsmatrix op. In vier weken leer je meer over je eigen netwerk dan bij welke leveranciersbeoordeling dan ook, en de matrix vormt de basis voor alle andere beslissingen, waaronder de keuze welk platform daadwerkelijk aansluit bij wat je hebt vastgesteld.

Het platform van Jimber is speciaal ontwikkeld voor middelgrote bedrijven die precies dit doen: ZTNA en netwerkafscherming met clientloze, browsergebaseerde toegang voor externe medewerkers, een beveiligde webgateway, firewall-as-a-service en afscherming van webapplicaties op één platform dat onder EU-soevereiniteit valt, zodat de migratie slechts één systeem toevoegt in plaats van vier. Als u uw afhankelijkheidsmatrix, zodra deze beschikbaar is, door een tweede paar ogen wilt laten bekijken, “>neem contact met ons op. Wat betreft de architecturale vergelijking: in “>‘Toegang voor derden zonder VPN’ behandelt specifiek het geval van externe medewerkers.

Veelgestelde vragen

Hoe lang duurt de migratie van een VPN naar ZTNA?

Voor een middelgrote organisatie met 100 tot 250 gebruikers duurt een volledige vervanging volgens gepubliceerde benchmarks twaalf tot zestien weken. Cloud-native organisaties met minder dan vijftig gebruikers voltooien dit proces in vier tot zes weken. Zestig tot zeventig procent van de inspanning bestaat uit verkenning en identiteitswerk, voordat er voor de gebruikers daadwerkelijk iets verandert.

Wat is de eerste stap bij de overstap van VPN naar ZTNA?

Passieve verkeersdetectie. Breng de syslog-gegevens van de VPN-concentrator, NetFlow-gegevens van de core-switches, interne DNS-foutlogboeken en telemetrie van eindpunten met elkaar in verband om een matrix van applicatieafhankelijkheden op te stellen. Voer dit uit over een volledige maandelijkse bedrijfscyclus van drie tot vier weken, zodat batchtaken aan het einde van de maand en geplande verbindingen met leveranciers in beeld komen.

Kan ik VPN en ZTNA tegelijkertijd gebruiken?

Ja, en dat zou je ook moeten doen. Een parallelle werking van vier tot acht weken is standaard bij een afdelingsoverstap. Het risico is dat gebruikers terugvallen op het VPN wanneer ze op problemen stuiten, waardoor tekortkomingen in het beleid verborgen blijven. Blokkeer de subnetten van de gemigreerde applicaties in de adrespool van het oude VPN en verwijder die routes uit de concentrator.

Waarom mislukken ZTNA-migraties bij bestandsshares?

SMB is een protocol dat veel verkeer genereert en is ontworpen voor lokale netwerken, met synchrone metadataverzoeken en sequentiële vergrendelingsonderhandelingen. Wanneer het via een applicatieproxy over het internet wordt gerouteerd, neemt de prestatie drastisch af en worden toegewezen stations losgekoppeld. Dit wordt nog verergerd door discrepanties in de Kerberos-serviceprincipaalnamen wanneer het platform de FQDN’s van de bestemmingen wijzigt.

Wat moet ik doen met apparaten waarop geen agent kan worden geïnstalleerd?

IoT-, OT- en industriële apparaten kunnen niet via softwareconnectoren worden beheerd. Isoleer ze in speciale, microgesegmenteerde enclaves en maak ze toegankelijk voor onderhoudstechnici via browsergeïsoleerde jump-hosts of hardware-gateways. Beschouw dit als een afzonderlijke werkstroom, los van de gebruikersmigratie; deze heeft een ander tijdschema.

Wanneer moet ik een ZTNA-overgang ongedaan maken?

Stel numerieke triggers vast voordat je begint. Redelijke drempelwaarden zijn bijvoorbeeld een door de broker veroorzaakte latentie van meer dan 250 milliseconden die langer dan vijftien minuten aanhoudt, meer dan twee procent mislukte validaties van tokens van identiteitsproviders, of het wegvallen van recordvergrendelingen in een kernapplicatie voor bedrijfsvoering. Al het andere is een defect dat moet worden verholpen, geen reden om terug te draaien.

Hoe kan ik een VPN buiten gebruik stellen zonder de site-to-site-tunnels te onderbreken?

Controleer eerst de cryptografische koppelingen om te verifiëren dat de site-to-site IKE-voorstellen en -sleutels gescheiden zijn van de inbelprofielen. Hef vervolgens de toewijzing van de IP-pools voor clients op, schakel de portaalluisteraar uit, verwijder de inkomende regels voor 443, UDP 500, 4500 en 1194, en controleer dit met een externe poortscan.

Welke identiteitsmaatregelen moeten er worden genomen vóór ZTNA?

Vijf punten: verwijder inactieve en gedeelde accounts met SCIM-provisioning uit het HR-systeem, vervang geneste verouderde groepen door expliciete, op rechten gebaseerde groepen, zorg voor phishingbestendige MFA en blokkeer sms- en pushberichten, voeg voorwaardelijke toegang toe op basis van risico en context, en voer signalen over de beveiligingsstatus van apparaten in de beleidsengine in.

Wie zou er deel moeten uitmaken van de ZTNA-proefgroep?

Eerst twee weken IT-operations en beveiligingstechnici, daarna twee weken ontwikkelaars en vervolgens de contactpersonen van de bedrijfsonderdelen. Sluit leidinggevenden, bestuursleden en de financiële afdeling tijdens de maandafsluiting in de beginfase uit: een uitzonderlijk geval dat aan het verkeerde publiek wordt voorgelegd, wordt dan een politiek probleem in plaats van een bugrapport.

Voldoet ZTNA aan de NIS2-eisen inzake toegangscontrole?

Het levert het technische bewijs voor artikel 21, lid 2, onder i), inzake toegangscontrole en artikel 21, lid 2, onder j), inzake meervoudige of continue authenticatie, maar de verplichting reikt verder dan welk product dan ook. In België voert CyFun controles uit op twee niveaus: goedgekeurde beleidsdocumenten en geëxporteerde configuraties, logbestanden en statuscontroles die aantonen dat de beveiligingsmaatregelen in de productieomgeving worden uitgevoerd.