Door Cronos Amsterdam · Gepubliceerd op
Fase 1 — Inventariseren
Begin met een overzicht van wat er via de VPN gebeurt. Welke applicaties worden gebruikt, door welke groepen, vanaf welke apparaten? Welke identity-provider is leidend en is die op orde? Welke applicaties zijn afhankelijk van andere systemen, vaste IP-adressen of netwerkprotocollen? Deze inventaris bepaalt de volgorde van migreren en voorkomt verrassingen.
Fase 2 — Een pilot met een beperkt aantal applicaties
Kies twee of drie applicaties met een overzichtelijke gebruikersgroep en geen extreme afhankelijkheden. Webapplicaties zijn vaak de logische start: die kunnen meestal via de browser worden ontsloten zonder software op het apparaat. Laat de VPN tijdens de pilot gewoon bestaan als terugvaloptie.
Browser en client: niet elke applicatie is gelijk
Browsergebaseerde applicaties kunnen vaak clientless worden ontsloten: de gebruiker logt in via de identity-provider en krijgt alleen toegang tot die ene applicatie. Voor niet-browserverkeer zoals SSH, RDP, databaseverbindingen, fat clients of applicaties die op netwerkniveau communiceren, is doorgaans een client op het apparaat nodig. Sommige oudere applicaties of systemen die verkeer naar de gebruiker initiëren, vragen extra ontwerp. Daar kan een aangepaste of beperkte VPN tijdelijk of blijvend nodig zijn.
Fase 3 — Expliciete policies en uitrol in golven
Formuleer per applicatie wie toegang krijgt, onder welke voorwaarden (bijvoorbeeld MFA, beheerd apparaat, land) en met welke sessieduur. Rol daarna uit in golven per applicatiegroep of afdeling, met vooraf afgesproken criteria om door te gaan of terug te schakelen.
Fase 4 — Beheer, logging en uitfaseren
Zorg dat toegangslogs worden bewaard en gekoppeld aan je monitoring of SIEM, en dat iemand eigenaar is van policywijzigingen. Pas als de laatste afhankelijke applicatie is gemigreerd en het terugvalscenario niet meer nodig blijkt, kun je VPN-toegang voor die groep afbouwen.
Checklist voor je eerste golf
- Applicatie-inventaris — Applicaties, gebruikersgroepen, protocollen en afhankelijkheden in kaart.
- Identity op orde — Eén leidende identity-provider met MFA en actuele groepen.
- Apparaatbeleid — Welke apparaten zijn beheerd, en welke status eis je per applicatie?
- Policies per applicatie — Expliciet wie, onder welke voorwaarden en met welke sessieduur.
- Logging — Toegangslogs bewaard, gekoppeld aan monitoring en met een eigenaar.
- Terugval en rollback — VPN blijft beschikbaar tot de golf aantoonbaar stabiel is; criteria om terug te schakelen vooraf vastgelegd.
- Communicatie en support — Gebruikers weten wat er verandert en waar ze terechtkunnen.
Grenzen en eerlijke kanttekeningen
- Volledige VPN-uitfasering is niet voor elk scenario haalbaar of zinvol; sommige protocollen en legacy-systemen vragen een blijvende uitzondering.
- Zero Trust is een werkwijze, geen product. Een tool zonder actuele identity, apparaatbeheer en eigenaarschap van policies levert schijnveiligheid op.
- Deze gids beschrijft een gangbare aanpak en vervangt geen ontwerp voor jouw specifieke landschap.
Verder lezen
Bronnen
Deze gids is in eigen woorden geschreven. Voor achtergrond verwijzen we naar de volgende primaire bronnen.
- Replace your VPN — learning path (opent in nieuw venster) — Cloudflare Docs
- Replace your VPN — Cloudflare One (opent in nieuw venster) — Cloudflare Docs
- Clientless access — initial setup (opent in nieuw venster) — Cloudflare Docs
- SP 800-207: Zero Trust Architecture (opent in nieuw venster) — NIST