Hoe voorkom je schijnveiligheid bij netwerkredundantie?

Schijnveiligheid bij netwerkredundantie ontstaat wanneer een netwerk op papier redundant is ingericht, maar in de praktijk toch één of meerdere kwetsbare punten bevat die bij een storing alsnog de volledige beschikbaarheid in gevaar brengen. Dit probleem treft organisaties vaker dan verwacht, juist omdat redundantie op het eerste gezicht correct lijkt te zijn opgezet. De vragen hieronder helpen je herkennen waar de risico’s zitten en hoe je ze aanpakt.

Wat zijn de meest voorkomende oorzaken van schijnveiligheid bij redundantie?

De meest voorkomende oorzaak van schijnveiligheid bij redundantie is het bestaan van een verborgen single point of failure: een component, verbinding of beheerpad dat door meerdere redundante paden wordt gedeeld, waardoor die paden bij een storing tegelijkertijd uitvallen. Andere veelvoorkomende oorzaken zijn ongetest failovergedrag, gedeelde fysieke infrastructuur en ontbrekende redundantie op laag 1 van het OSI-model.

In de praktijk zien we een aantal terugkerende patronen:

• Gedeelde fysieke routes: Twee glasvezelverbindingen die op de kaart verschillende paden lijken te volgen, maar fysiek door dezelfde kabelgoot, manhole of gebouw lopen. Eén graafmachine maakt dan beide verbindingen onbruikbaar.
• Gedeelde netwerkapparatuur: Twee logisch gescheiden uplinks die via dezelfde switch of router lopen, waardoor het uitvallen van dat ene apparaat beide paden treft.
• Gedeelde beheerinfrastructuur: Out-of-band management dat afhankelijk is van hetzelfde netwerk dat het moet beheren, zodat je bij een storing ook de toegang tot je beheerinterface verliest.
• Ongetest failovergedrag: Redundante verbindingen die nooit zijn getest, waarna bij een echte storing blijkt dat de failover niet automatisch of niet snel genoeg werkt.
• Softwarematige redundantie zonder fysieke back-up: Protocollen zoals OSPF of BGP die redundantie simuleren, maar die afhankelijk zijn van onderliggende fysieke infrastructuur die niet is gedupliceerd.

Het gevaarlijke aan schijnveiligheid is precies dat je denkt beschermd te zijn. Een gelaagde beveiligingsaanpak begint daarom altijd met een eerlijke analyse van de werkelijke infrastructuur, niet alleen van de logische topologie.

Hoe herken je een single point of failure in een redundant netwerk?

Een single point of failure in een redundant netwerk herken je door systematisch elk component, elke verbinding en elk beheerpad te volgen en te toetsen: als dit element uitvalt, blijft het netwerk dan volledig functioneel? Als het antwoord op welk punt dan ook “nee” is, heb je een single point of failure gevonden, ongeacht hoe redundant de rest van het ontwerp eruitziet.

Concreet kun je dit aanpakken door de volgende vragen te stellen voor elk onderdeel van je infrastructuur:

1. Delen meerdere redundante paden dezelfde fysieke route, kabelgoot of gebouw?
2. Lopen beide uplinks via dezelfde switch, router of patchpanel?
3. Is de voeding van redundante apparaten aangesloten op hetzelfde stroomcircuit of dezelfde UPS?
4. Gebruikt het out-of-band beheerpad hetzelfde netwerk als de productieomgeving?
5. Zijn de redundante verbindingen bij dezelfde provider of carrier ingekocht, die gebruik maakt van dezelfde fysieke infrastructuur?

Een nuttige techniek is het uitvoeren van een “failure mode analysis”: ga voor elk component na wat er gebeurt als het uitvalt, en volg de gevolgen door de hele keten. Dit onthult vaak verborgen afhankelijkheden die in een topologiediagram niet zichtbaar zijn. Tools voor monitoring en netwerkbeheer kunnen daarbij helpen door realtime inzicht te geven in de staat van alle verbindingen en componenten.

Wat is het verschil tussen geografische redundantie en logische redundantie?

Geografische redundantie betekent dat kritieke infrastructuurcomponenten fysiek op verschillende locaties zijn geplaatst, zodat een lokale storing zoals brand, overstroming of stroomuitval niet alle systemen tegelijk treft. Logische redundantie verwijst naar het dupliceren van netwerkconfiguraties, protocollen en paden binnen dezelfde of overlappende fysieke infrastructuur, zonder dat de fysieke scheiding is gegarandeerd.

Het onderscheid is cruciaal voor hoge beschikbaarheid. Logische redundantie, zoals het configureren van twee BGP-sessies of het instellen van VRRP, biedt bescherming tegen softwarefouten en configuratieproblemen. Maar als beide logische paden over dezelfde fysieke bekabeling lopen of via hetzelfde datacenter gaan, biedt logische redundantie geen bescherming bij een fysieke storing op die locatie.

Geografische redundantie pakt dit aan door te zorgen dat de fysieke infrastructuur daadwerkelijk gescheiden is. Denk aan twee datacenters in verschillende steden, met onafhankelijke stroomvoorziening, koeling en glasvezelroutes die via verschillende tracés lopen. Pas wanneer logische en geografische redundantie samen worden ingezet, ontstaat echte netwerkweerbaarheid. Veel organisaties investeren in logische redundantie en denken daarmee klaar te zijn, terwijl de onderliggende fysieke infrastructuur nog steeds één kwetsbaar punt vormt.

Hoe test je of netwerkredundantie echt werkt?

Netwerkredundantie test je door gecontroleerd en bewust storingen te simuleren in productie- of testomgevingen, en te meten of het netwerk binnen de verwachte tijd en zonder dataverlies overschakelt op het redundante pad. Redundantie die nooit is getest, is geen redundantie maar een aanname.

Een effectieve testmethodiek bevat minimaal de volgende stappen:

• Geplande failovertests: Schakel bewust een primaire verbinding of apparaat uit en meet hoe lang het duurt voordat het redundante pad actief is. Vergelijk dit met de RTO (Recovery Time Objective) die je organisatie heeft vastgesteld.
• Fysieke kabeltests: Trek daadwerkelijk een glasvezelverbinding los of simuleer een kabelbreuk, zodat je zeker weet dat de failover ook werkt bij een fysieke storing en niet alleen bij een softwarematige fout.
• Stroomuitvaltests: Simuleer het uitvallen van een stroomgroep of UPS om te controleren of redundante voeding correct overneemt.
• Beheertoegangstests: Controleer of je tijdens een storing nog steeds toegang hebt tot je netwerkapparatuur via een out-of-band beheerpad, onafhankelijk van het primaire netwerk.
• Documenteer en herhaal: Leg testresultaten vast en herhaal tests periodiek, zeker na wijzigingen in de infrastructuur.

Voor kritieke omgevingen is het zinvol om realtime glasvezelbewaking in te zetten, zodat je niet alleen bij geplande tests inzicht hebt, maar continu ziet of alle verbindingen de verwachte prestaties leveren.

Welke rol speelt laag 1-infrastructuur bij echte netwerkweerbaarheid?

Laag 1, de fysieke laag van het OSI-model, is de fundering van alle netwerkweerbaarheid. Zonder een robuuste en goed ontworpen fysieke infrastructuur, inclusief glasvezelroutes, connectoren, patchpanelen en bekabeling, bieden hogere lagen geen werkelijke bescherming. Schijnveiligheid ontstaat vrijwel altijd wanneer redundantie wordt gebouwd op een zwakke of onvoldoende gediversifieerde laag 1.

Concreet betekent dit dat de keuze voor fysieke routes, de kwaliteit van glasvezelverbindingen en de fysieke scheiding van kabeltracés net zo belangrijk zijn als de configuratie van routeringsprotocollen. Een netwerk met perfect geconfigureerde failover op laag 3 valt alsnog volledig uit als de onderliggende glasvezelverbindingen door dezelfde kabelgoot lopen en die kabelgoot beschadigd raakt.

Aandachtspunten op laag 1 voor echte netwerkweerbaarheid zijn:

• Fysiek gescheiden kabeltracés voor redundante verbindingen, ook bij het binnenkomen van een gebouw
• Kwalitatief hoogwaardige connectoren en patchpanelen die storingen door slechte verbindingen voorkomen
• Voldoende reservecapaciteit in glasvezelinfrastructuur om snel te kunnen schakelen
• Regelmatige inspectie en meting van de fysieke verbindingskwaliteit

Onze optische netwerkoplossingen zijn specifiek ontworpen om op laag 1 de betrouwbaarheid te bieden die bedrijfskritische omgevingen vereisen, van datacenterverbindingen tot campusnetwerken en backbone-infrastructuur.

Wanneer is een vendor-onafhankelijke netwerkaudit zinvol?

Een vendor-onafhankelijke netwerkaudit is zinvol wanneer je twijfelt of je huidige redundantie-inrichting werkelijk beschermt, wanneer je infrastructuur organisch is gegroeid zonder integraal ontwerp, of wanneer je organisatie te maken heeft met verhoogde beschikbaarheidseisen door groei, nieuwe regelgeving of een uitbreiding van bedrijfskritische processen.

Het verschil met een audit door een bestaande leverancier is dat een vendor-onafhankelijke partij geen belang heeft bij het aanbevelen van specifieke producten of het goedpraten van bestaande keuzes. De focus ligt volledig op wat jouw infrastructuur nodig heeft, niet op wat een leverancier wil verkopen.

Situaties waarin een audit bijzonder waardevol is:

• Na een storing of bijna-storing waarbij bleek dat de failover niet werkte zoals verwacht
• Bij een fusie of overname waarbij twee netwerkinfrastructuren worden samengevoegd
• Wanneer compliance-eisen, zoals NIS2 of sectorspecifieke regelgeving, aantoonbare beschikbaarheid en weerbaarheid vereisen
• Bij de voorbereiding op een grootschalige migratie naar de cloud of hybride omgevingen
• Wanneer de huidige infrastructuur organisch is gegroeid en niemand meer een volledig beeld heeft van alle afhankelijkheden

Wij werken vendor-onafhankelijk en hebben meer dan twintig jaar ervaring met het doorlichten van netwerkinfrastructuren in uiteenlopende sectoren. Dat betekent dat we een audit uitvoeren vanuit technische diepgang, zonder voorkeur voor een specifiek merk of platform. Het resultaat is een eerlijk beeld van waar je redundantie echt werkt en waar schijnveiligheid op de loer ligt, inclusief concrete aanbevelingen die aansluiten bij jouw situatie en doelstellingen.