{"id":14829,"date":"2026-09-25T09:00:09","date_gmt":"2026-09-25T07:00:09","guid":{"rendered":"https:\/\/jimber.io\/?p=14829"},"modified":"2026-09-25T09:00:09","modified_gmt":"2026-09-25T07:00:09","slug":"van-het-einde-van-de-ondersteuning-tot-sase-het-30-dagenplan-voor-het-vervangen-van-de-firewall","status":"publish","type":"post","link":"https:\/\/jimber.io\/nl\/blog\/van-het-einde-van-de-ondersteuning-tot-sase-het-30-dagenplan-voor-het-vervangen-van-de-firewall\/","title":{"rendered":"Van het einde van de ondersteuning tot SASE: het 30-dagenplan voor het vervangen van de firewall"},"content":{"rendered":"

Een vervanging van de firewall binnen dertig dagen is alleen haalbaar als we ons beperken tot risicobeperkende maatregelen: identiteitsintegratie, uitgaande bemiddeling voor priv\u00e9toepassingen en basis-DNS- en webfiltering, waarbij de vervanging van de hardware in de vestigingen en de volledige TLS-inspectie worden uitgesteld. Een vervanging van de hardware door gelijkwaardige apparatuur is geen optie, omdat de aanschaf van de apparatuur alleen al vier tot acht weken in beslag neemt voordat de technische werkzaamheden kunnen beginnen.<\/strong><\/p>\n

Jij hebt dit project niet gekozen. Dat heeft een date gedaan.<\/p>\n

Er is iets in je omgeving waarvan de ondersteuning binnen enkele weken afloopt; een vervanging door een gelijkwaardig product is niet zonder meer de juiste oplossing, en je hebt een stappenplan nodig om de organisatie op tijd in een verdedigbare positie te brengen. Dat is een ander probleem dan het evalueren van een platform, en het is ook een ander probleem dan een volledige uitrol. Deze pagina behandelt het eerste: <\/https:>“>de 30-daagse proof of concept<\/a> is bedoeld voor evaluatie wanneer je de luxe hebt om te kiezen, en <\/https:>“>de implementatietermijn van 90 dagen<\/a> is bedoeld voor de volledige uitrol over meerdere locaties. In beide gevallen is sprake van dertig dagen. Alleen hier wordt ervan uitgegaan dat de datum niet onderhandelbaar is.<\/p>\n

Het hele plan staat op de pagina. Geen formulier, geen download achter een betaalmuur \u2014 hoewel dat, eerlijk gezegd, minder een onderscheidend kenmerk is dan we hadden verwacht. We hebben op de eerste pagina gezocht naar \u2018plan voor het vervangen van een firewall\u2019<\/em>, \u2018vervangen van een firewall aan het einde van de levensduur<\/em>\u2019, \u2018SASE-migratie binnen 30 dagen\u2019<\/em> en \u2018noodmigratie van een firewall<\/em>\u2019, en de drempel is laag: minder dan 5% bij de zoekopdracht over \u2018einde levensduur\u2019, 10 tot 15% bij de zoekopdracht over het vervangingsplan, en helemaal niets bij de zoekopdracht over noodsituaties, waarbij pagina \u00e9\u00e9n volledig bestaat uit discussiethreads op het communityforum.<\/p>\n

De echte tekortkoming ligt elders, en er zijn er twee. Ten eerste bevat elke checklist voor rangschikking mijlpalen \u2013 de regels doornemen, de hardware klaarzetten, de overgang uitvoeren, de logbestanden controleren \u2013 zonder ook maar \u00e9\u00e9n kwantitatief afsluitingscriterium<\/strong>. Nergens wordt vermeld welk helpdeskvolume betekent dat de overgang mislukt, welk percentage mislukte authenticaties aanleiding geeft tot afbreken, of hoe je bepaalt of een applicatie veilig kan worden overgezet als de documentatie ontbreekt.<\/p>\n

Ten tweede gaan ze er stuk voor stuk van uit dat het plan slaagt. Geen enkele biedt een verdedigbaar alternatief voor het geval dat dertig dagen niet voldoende zijn, wat \u2014 als je een OT-site of een niet-gedocumenteerd applicatiepark hebt \u2014 eerder een realistisch dan een pessimistisch scenario is.<\/p>\n

Dit plan is dus opgebouwd rond fasen in plaats van taken, en het eindigt met het scenario waarin het misgaat, in plaats van dat scenario te negeren.<\/p>\n

De realistische voorwaarde voor een firewallvervanging binnen 30 dagen<\/h2>\n

Allereerst: een vervanging door identieke hardware is binnen dertig dagen niet mogelijk.<\/strong> De toeleveringsketens voor beveiligingsapparatuur voor bedrijven hebben een doorlooptijd van vier tot acht weken voor inkoop en voorbereiding, en bij conventionele firewallvervangingen op \u00e9\u00e9n locatie is gemiddeld vijf tot zeven weken nodig voor de technische implementatie, plus twee tot vier weken voor het opstellen van nalevingsdocumentatie. Als de vervangende apparaten nog niet in het gebouw aanwezig zijn, past de hardware-aanpak niet binnen het tijdsbestek. Dat is de beperking die dit plan noodzakelijk maakt, niet een voorkeur voor de ene architectuur boven de andere.<\/p>\n

Tweede voorwaarde, en dit is degene die de meeste gecomprimeerde projecten de das omdoet: je identiteitsdirectory moet in redelijk goede staat verkeren.<\/strong> Een Zero Trust-platform beoordeelt toegang op basis van identiteit, groepslidmaatschap en de status van het apparaat, in plaats van op basis van IP-adressen. Als Active Directory of Entra ID verweesde beheerdersaccounts, niet-toegewezen geneste groepen, serviceaccounts zonder eigenaar of onvolledige MFA-registratie bevat, kan de beleidsengine het principe van \u2018minimale rechten\u2019 niet toepassen en ontstaan er authenticatielussen of lock-outs.<\/p>\n

Volgens onafhankelijke praktijkgegevens duurt het opstellen van de identiteits- en beleidsontwerpen twee tot vier weken. Via de spoedprocedure wordt dit teruggebracht tot zeven dagen, maar niet verder. Als je directory een maand nodig heeft om opgeschoond te worden, gaat het dertig-dagenplan pas van start als dat klaar is, en door te doen alsof dat niet zo is, mislukken deze projecten al in week drie.<\/p>\n

Hier wordt de spanning duidelijk benoemd in plaats van verdoezeld, want je zult dit nodig hebben wanneer je voor een stuurgroep staat.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Fase<\/th>\nDoor de leverancier opgegeven duur<\/th>\nOnafhankelijke veldgegevens<\/th>\nMinimum voor spoedtraject<\/th>\nSamendrukbaar?<\/th>\n<\/tr>\n<\/thead>\n
Verkenning en afbakening<\/td>\n1\u20132 weken<\/td>\n3\u20135 weken<\/td>\n5 dagen<\/td>\nGedeeltelijk. Het controleren van de interface gaat sneller; het opsporen van verborgen oost-west-afhankelijkheden niet<\/td>\n<\/tr>\n
Identiteit en beleidsontwerp<\/td>\n1\u20132 weken<\/td>\n2\u20134 weken<\/td>\n7 dagen<\/td>\nNee. Het opschonen van de directory, SCIM-synchronisatie en de status van MFA zijn strikte vereisten<\/td>\n<\/tr>\n
Gecontroleerde proef<\/td>\n2\u20133 weken<\/td>\n6\u20138 weken<\/td>\n7 dagen<\/td>\nAlleen met uitgebreide telemetrie, en alleen bij 10\u201315% van de gebruikers in niet-kritieke cohorten<\/td>\n<\/tr>\n
Gefaseerde overgang naar de productie<\/td>\n3\u20135 weken<\/td>\n4\u20138 weken<\/td>\n7 dagen<\/td>\nJa, in fasen per groep. Eerst gebruikers op afstand en browserwerk; vestigingen volgen later, gespreid in de tijd<\/td>\n<\/tr>\n
Hypercare en buitengebruikstelling<\/td>\n2\u20134 weken<\/td>\n2\u20134 weken<\/td>\n4 dagen voor de eerste ontmanteling<\/td>\nGedeeltelijk. Ontkoppeling van de perimeter in vier dagen; fysieke ontsmetting vindt plaats na dag 30<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Elke termijn in het spoedtraject is korter dan de onafhankelijke veldgegevens. Dat is wat \u201espoed\u201d inhoudt, en dit wordt bereikt door de reikwijdte te beperken, niet door optimisme. Volledige SASE-programma\u2019s voor grote ondernemingen duren gemiddeld zes tot twaalf maanden; versnelde projecten voor het middensegment lopen van scoping tot buitengebruikstelling 60 tot 90 dagen. Dertig dagen is het versnelde traject, dat wordt bereikt door alles uit te stellen wat geen risicobeperking betreft.<\/p>\n

De vijf fasen en hun mijlpalen<\/h2>\n

Vijf fasen verspreid over dertig dagen: verkenning en afbakening tot dag 5, basisconfiguratie tot dag 12, een pilot van 10 tot 15 procent tot dag 19, gefaseerde overgang tot dag 26, en hypercare met buitengebruikstelling tot dag 30. De kolom met de mijlpaalcriteria vormt het plan \u2013 zonder deze kolom is dit slechts een checklist, en een checklist kan je niet vertellen of je verder moet gaan.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Fase<\/th>\nActiviteiten<\/th>\nEigenaar<\/th>\nUitvoerartefact<\/th>\nToelatingscriteria om te stoppen<\/th>\n<\/tr>\n<\/thead>\n
1. Verkenning en afbakening<\/strong>
\n, dag 1\u20135<\/td>\n		Exporteer actieve configuraties van legacy-systemen, NAT-tabellen en tellers voor het aantal keer dat regels zijn geraakt. Voer een analyse van actieve datastromen uit om live bedrijfsdiensten in kaart te brengen. Controleer het schema van de identiteitsprovider, de groepen en de MFA-status. Segmenteer applicaties in web, standaard client-server en complexe legacy-protocollen<\/td>\nHoofdarchitect infrastructuur<\/td>\nAfgebakende applicatiecatalogus; register van netwerkafhankelijkheden; risicobeoordeling voor het einde van de levensduur en overzicht van uitzonderingen<\/td>\nGate 0:<\/strong> 100% van de externe statische IP-adressen en actieve NAT-koppelingen gedocumenteerd. Directory-synchronisatie in orde, zonder verweesde beheerdersaccounts. Top 10 bedrijfskritische applicaties in kaart gebracht per poort en protocol<\/td>\n<\/tr>\n
2. Basisconfiguratie<\/strong>
\n, dag 6\u201312<\/td>\n		Zet de cloudtenant op en koppel SAML- of OIDC-authenticatie. Implementeer redundante, uitsluitend uitgaande connectors binnen priv\u00e9-subnetten voor applicaties. Configureer basis-toegangsbeleidsregels voor beheerders en algemene gebruikersgroepen. Pas de basis-webgateway toe: DNS-bedreigingsfiltering, blokkering van command-and-control-verkeer, onderdrukking van kwaadaardige URL’s<\/td>\nCloud Security Operations Engineer<\/td>\nBasisconfiguratie van de tenant; connectorarchitectuur en routeringskaart; synthetisch testplan v\u00f3\u00f3r de overgang<\/td>\nGate 1:<\/strong> Geautomatiseerde gebruikersprovisioning werkt via SCIM. Connectorcluster rapporteert continu geldige heartbeats. Synthetische gezondheidscontroles slagen voor interne staging-doelen. Testbeleidsregels blokkeren bekende schadelijke domeinen en EICAR-strings<\/td>\n<\/tr>\n
3. Proef<\/strong>
\n: dagen 13\u201319<\/td>\n		Schrijf een groep van 10\u201315% in: IT-medewerkers, technische leidinggevenden, operationele koplopers. Verspreid de endpoint-agent of maak agentloze toegang tot het portaal mogelijk. Leid de toegang tot echte private productietoepassingen via de broker. Monitor live variaties in latentie, authenticatiefouten en sessiestabiliteit<\/td>\nServicedesk en systeemverantwoordelijke<\/td>\nRapport over pilotprestaties en telemetrie; servicedesk-runbook v1; formele goedkeuring van de pilot<\/td>\nGate 2:<\/strong> Succesvolle authenticatie bij de eerste poging op of boven de overeengekomen drempel voor de hele groep. Verslechtering van de round-trip-tijd van applicaties binnen het overeengekomen maximum ten opzichte van de oude baseline. Aantal piloottickets onder het overeengekomen percentage van het groepsbestand, met nul blokkerende issues van ernstniveau 1<\/td>\n<\/tr>\n
4. Gefaseerde overgang<\/strong>
\n-dagen 20\u201326<\/td>\n		Fase 1, dag 20\u201321: haal thuiswerkers en hybride werknemers van het oude VPN-netwerk. Fase 2, dag 22\u201324: leid het uitgaande internetverkeer van de vestigingen om via de cloudgateway. Fase 3, dag 25\u201326: verplaats de publicatie van inkomende applicaties naar de beveiligde reverse proxy. Houd parallelle routing gedurende het hele proces actief voor onmiddellijke failback<\/td>\nLeiding van de netwerkoperaties met de adviesraad voor verandering<\/td>\nUitgevoerd cutover-runbook; goedkeuringsverslag van de CAB; realtime logbestanden voor verkeerscontrole<\/td>\nGate 3:<\/strong> CAB-goedkeuring formeel vastgelegd. Externe DNS-TTL\u2019s ten minste 24 uur van tevoren verlaagd. Aangetoond dat het terugdraaipad binnen 15 minuten uitvoerbaar is. 100% van de externe gebruikers authenticeert via de nieuwe fabric. Het aantal helpdeskverzoeken ligt binnen 10% van de normale basiswaarde. Geen aanhoudende routeringslussen, asymmetrische uitval of tunnelinstabiliteit<\/td>\n<\/tr>\n
5. Hypercare en buitengebruikstellings<\/strong>
\n, dag 27\u201330<\/td>\n		48 uur hypercare: grondige inspectie van datastromen, controle van logbestanden, analyse van uitval. Schakel beheerinterfaces die toegang geven tot het internet en verouderde VPN-listeners op het apparaat dat het einde van de levensduur nadert uit. Zet het verouderde apparaat in de passieve tap-modus of in een ge\u00efsoleerd quarantaine-VLAN. Exporteer de laatste auditlogs; plan het cryptografisch opschonen van opslagmedia<\/td>\nCISO of directeur IT-operaties<\/td>\nAuditpakket na de overgang; logboek van het opschonen van media; indiening van wettelijk vereiste kennisgevingen<\/td>\nGate 4:<\/strong> Geen enkel productieverkeer van het bedrijf dat gedurende een aaneengesloten periode van 48 uur via de verouderde hardware verloopt. Fysieke WAN-interfaces losgekoppeld, beheertoegang ge\u00efsoleerd. Definitieve auditdocumentatie ondertekend en gearchiveerd<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Drie gate-drempels worden bewust aangeduid als “de overeengekomen drempel” in plaats van als concrete getallen, omdat deze moeten worden afgestemd op uw<\/em> gemeten referentiewaarde uit fase 1 en met het bedrijf moeten worden overeengekomen voordat de pilot van start gaat. Een latentieplafond heeft geen betekenis zonder de bestaande referentie om het mee te vergelijken. Leg deze schriftelijk vast bij Gate 0 en pas ze later niet aan om een fase toch door te laten gaan.<\/p>\n

De rollback wordt geactiveerd<\/h3>\n

op basis v
\n. Hierover valt niet te onderhandelen en het zijn geen beoordelingskwesties. De migratieco\u00f6rdinator stopt de overgang en voert de rollback van 15 minuten uit als zich binnen de eerste 120 minuten na de livegang een van de volgende situaties voordoet:<\/p>\n