Out of Band-netwerk

“Een management-omgeving die fysiek en functioneel onafhankelijk is van de productie-infrastructuur”

Situatieschets

Klant beschikt niet over een onafhankelijk out-of-band (OOB)management netwerk. Dit netwerk dient om in geval van calamiteiten met de productie-infrastructuur toch verbinding te kunnen maken met de management-interfaces aan de apparatuur. De klant heeft een dergelijk netwerk, maar toegang tot dat netwerk wordt geregeld via authenticatie-servers die in de productie-omgeving draaien en die in geval van calamiteiten mogelijk niet bereikbaar zijn. Het OOB-netwerk is niet redundant opgezet. Beheertooling voor de infrastructuur draait in de productie-omgeving.

De eisen en wensen van de verschillende belanghebbende partijen liepen nogal uiteen. Vanuit het management was het belangrijk om de onafhankelijke toegang snel geregeld te krijgen en daarnaast niet te veel aan te passen aan het huidige netwerk. De toegankelijkheid van de beheerinterfaces van de apparatuur moest tijdens calamiteiten gewaarborgd zijn. Dat het OOB-netwerk door de niet-redundante opzet geen hoge beschikbaahied had was geen issue. Two-factor authentication was een eis.

De beheerafdeling wilde juist een heel andere opzet van het OOB-netwerk. Ook en vooral tijdens calamiteiten op het productie-netwerk wilden zij kunnen beschikken over alle tooling en monitoring die zij onder de normale omstandigheden ook gebruikten. Zij wilden in een stressvolle situatie juist niet anders hoeven te werken dan normaal. Dit betekent een beheer-infrastructuur en een productie-infrastructuur die naast elkaar draaien, waarbij uitval van de één niet eidt to verstoring op de ander. De consequentie hiervan was dat zowel de normale werkplek van de beheerders als de beheertooling op het OOB-netwerk moesten gaan draaien. Dit hield in dat het OOB-netwerk meer capaciteit moest krijgen en redundant uitgevoerd moest worden.

Methode

Het was belangrijk consensus te krijgen over de uit te voeren opdracht. Ik heb daarom een toekomstvisie geschreven voor het OOB-netwerk, en een stappenplan om daar te komen. Als stap 1 heb ik datgene benoemd wat vanuit het management aangedragen werd, de onafhankelijke toegang tot het netwerk. Daarna heb ik een aantal vervolgstappen gedefinieerd die nodig waren om te komen tot het eindplaatje dat de beheerafdeling voor ogen had. Na goedkeuring door alle partijen ben ik gaan bouwen aan stap 1.

Stap 1 regelt de onafhankelijke toegang tot het netwerk. In de daarop volgende fases wordt de capaciteit en de redundantie van het netwerk vergroot, zodat het klaar is om de gebruikte management-stations en netwerk-tooling te faciliteren. Als laatste verhuizen deze diensten daadwerkelijk naar het OOB.

Resultaat

Stap 1 is op dit moment bijna afgerond. Ik heb, aansluitend op de aanwezige kennis, een tweetal Fortinet firewalls ingericht, met Radius- en token authenticatie. Ook heb ik een tweetal ESX-servers ingericht met een aantal werkplekken. Op de firewalls staat op de buitenkant een portal die de gebruikers (beheerders) naar een werkplek op een DMZ leidt. Vanaf deze werkplek hebben zij toegang tot het OOB-netwerk. De benodigde netwerkdiensten als Radius en DNS zijn lokaal en onafhankelijk van productie op het DMZ beschikbaar.

Na de volledig implementatie van het plan heeft de opdrachtgever een management-omgeving die fysiek en functioneel onafhankelijk is van de productie-infrastructuur. Dit houdt in dat netwerkmanagement volledig beschikbaar is als de productie uitvalt, en tegelijk dat onderhoud of verstoringen op de management-omgeving geen invloed hebben op de productie.

Conclusie

Een opdracht die eenvoudig lijkt (bouw een toegang tot het OOB-netwerk voor calamiteiten) is vaak door de wensen van de belanghebbende partijen moeilijker dan het in eerste instantie lijkt. Bij deze opdrachtgever lagen de verschillende wensen ver uit elkaar, zonder dat de opdrachtgever zich dat realiseerde. Ook lagen de eisen nog niet vast, wat betekende dat een bereikt akkoord soms weer op de helling ging. Het is daarom belangrijk goed te documenteren wat er overeengekomen is voordat het ontwerp echt gemaakt kan worden. Dit proces lijkt vanuit de opdrachtgever onnuttig bestede tijd, maar het kan tijdsverlies door het terugdraaien van eerder gemaakte stappen voorkomen. Grote verschillen tussen partijen kunnen vaak overbrugd worden door het project in verschillende fasen op te delen. Uiteraard moet de opdrachtgever/financier het wel met het op deze manier bereikte einddoel eens zijn.