Hub-and-spoke oogt goed, tot je de kosten en de onbeheer(s)baarheid ziet.

Hub-and-spoke klinkt als volwassen architectuur.

Netjes. Centraal. Beheersbaar.
Eén hub voor controle, security en routing. Daaromheen spokes die voorspelbaar worden aangesloten.

Op papier ziet het eruit als orde. 
In de praktijk groeit het vaak uit tot iets wat we helemaal niet willen: een duur en lastig te doorgronden verkeersknooppunt.

Want de belofte van eenvoud zit vooral in .. tja het plaatje. Niet in het gedrag van het systeem zodra je omgeving groter wordt.

Aanvankelijk lijkt elke extra spoke onschuldig. Totdat je beseft wat er onder water gebeurt.

Even hoogover rekenen: bij N spokes kan elke spoke via de hub met N-1 andere spokes communiceren. Daarmee groeit het aantal mogelijke communicatiepaden niet lineair, maar kwadratisch: N × (N-1). Met 10 spokes praat je al over 90 mogelijke paden. Bij 100 spokes zijn dat er 9.900. En bij 300 spokes zit je tegen de 90.000 aan.

Zonder te rekenen: voordat je het weet loopt de hele boel enorm uit de klauwen.

Dat is geen netwerk meer dat een team nog intuïtief kan overzien. Dat is een verkeersplan wat je spreadsheet nog bijhoudt, maar je mensen allang niet meer.

En precies daar begint het echte probleem. Niet alleen technisch, maar ook bedrijfsmatig.

Meer paden betekent meer regels, meer uitzonderingen, meer afhankelijkheden, meer foutkansen en meer tijdverlies bij wijzigingen, incidenten en audits. Iedere aanpassing raakt al snel meer dan één verbinding. Iedere verstoring krijgt meer mogelijke oorzaken. Iedere groeistap maakt het geheel minder transparant.

Daar blijft het niet bij. In de cloud komt er nog ongewenste verrassing bij: de rekening.

In Azure wordt hub-and-spoke vaak uitgerold rond een Azure Firewall. Die kost niet alleen geld omdat hij aan staat, maar ook omdat al het verkeer erdoorheen loopt. En omdat verwerkingscapaciteit moet meegroeien met de belasting. Bij gemiddeld 90 MB/s aan verkeer - voor een serieuze enterprise-omgeving eerder bescheiden dan extreem - kunnen de kosten van die firewall gemakkelijk en razendsnel verviervoudigen. En dan heb je de extra capaciteitskosten nog niet eens meegenomen.

Wat begint als centrale regie, eindigt zo makkelijk in centrale opstopping.

En hoe groter de omgeving, hoe duurder het wordt om te blijven geloven dat dit nog simpel is.

Meer security, minder gedoe: slimmere alternatieven voor hub-and-spoke

Hub-and-spoke wordt vaak verkocht als security-architectuur.

De redenering klinkt logisch: als een systeem wordt gecompromitteerd, wil je niet dat het als springplank dient naar de rest van je omgeving. Dat uitgangspunt is prima. Daar is ook geen discussie over. Het probleem zit ergens anders: hub-and-spoke is lang niet de enige manier om laterale beweging te beperken. En vaak ook niet de slimste.

Te veel organisaties lossen een beheervraagstuk op met extra netwerkcomplexiteit. Leveranciers promoten dit volop. Alsof veiligheid vooral ontstaat door meer paden, meer centrale voorzieningen en meer controlelagen. Maar security wordt niet automatisch beter omdat je architectuur duurder, zwaarder en abstracter wordt. Vaak gebeurt het omgekeerde: je bouwt een indrukwekkend hek om een terrein dat intern nog steeds vol open deuren staat.

Wie zijwaartse beweging serieus wil beperken, moet eerst kijken naar het verkleinen van het aanvalsvlak.

Laten we het praktisch maken. Begin met het uitschakelen van diensten die je niet gebruikt. Wat uitstaat, kan niet worden misbruikt. Dat klinkt bijna te simpel, maar precies daarom wordt het vaak over het hoofd gezien en overgeslagen. Veel kwetsbaarheden leven niet in ‘exotische’ software, maar in gewone services die ooit nodig waren. Ze zijn nooit opgeruimd en draaien dus nog steeds braaf mee. Op Windows is dat uitzetten soms lastiger dan het zou moeten zijn. SMB kun je niet zomaar wegdenken, maar verouderde en kwetsbare authenticatievormen daarbinnen vaak wel. En waarom zou op een server - waarop nooit geprint wordt - de print spooler dan actief blijven? Elk onnodig actief onderdeel is gratis gereedschap voor een aanvaller.

Daarna komt een klassieker die opvallend en te vaak wordt onderschat: de lokale firewall.

Veel security-discussies worden gevoerd op netwerk- of platformniveau. Terwijl de server zelf een uitstekende poortwachter kan zijn. Servers in hetzelfde segment hoeven lang niet altijd vrij met elkaar te praten. In veel omgevingen is dat zelfs pure gemakzucht. Door alleen strikt noodzakelijke communicatie toe te staan en de rest te blokkeren, maak je kruisbesmetting met malware een stuk moeilijker. Niet perfect. Wel effectief. En vooral: veel gerichter dan een generieke architectuurlaag waar uiteindelijk alles toch weer doorheen moet.

Ook helpt het om beheer en serviceverkeer van elkaar te scheiden.

Een gecompromitteerde server mag soms best een applicatie op een andere server bereiken. Wat je vooral níét wilt, is dat dezelfde server ook direct bij managementinterfaces kan. Zodra beheerpaden en servicepaden door elkaar lopen, maak je de route naar verdere escalatie veel korter. Dan hoeft een aanvaller niet alleen een workload te raken, maar krijgt die mogelijk ook zicht op het bedieningspaneel erachter. Scheiding verlaagt die kans. Uiteraard mits managementinterfaces onderling óók niet vrij kunnen praten.

Draai je nog on premise met eigen netwerkapparatuur, dan kun je nog een stap verder gaan: met filtering op netwerkniveau.

Dat lijkt op wat een lokale firewall doet, maar dan buiten de server zelf. Daardoor wordt het robuuster. Servers binnen hetzelfde VLAN hoeven lang niet automatisch met elkaar te communiceren. Dat “we zetten ze bij elkaar, dus ze mogen elkaar zien” is technisch makkelijk, maar security-inhoudelijk niet verstandig. En mag ik zeggen ‘lui’? Filteren buiten het systeem voorkomt dat een gecompromitteerde server ook nog zijn eigen hek mag beheren.

Een andere onderschatte fout zit in identiteit.

We houden allemaal van Single Sign-On. Begrijpelijk. Ik ook. Het is handig, snel en gebruiksvriendelijk. Maar gemak heeft een prijs. Als hetzelfde account zowel applicaties gebruikt als servers kan beheren, trek je functioneel en administratief verkeer over elkaar heen. Dan hoeft een aanvaller niet eens direct beheerrechten te hebben om waardevolle informatie op te halen. Zelfs leesrechten kunnen al genoeg zijn om een volgende stap voor te bereiden. Wie laterale beweging wil afremmen, moet beheeraccounts en gebruikersaccounts dus hard uit elkaar trekken.

In dat verlengde zijn lokale beheeraccounts vaak verstandiger dan overal dezelfde globale macht.

Niet omdat lokaal per definitie mooier is, maar omdat het de besmetting begrenst. Credentials die op server A bruikbaar zijn, moeten niet automatisch toegang geven tot server B. Anders bouw je een dominoreeks die je centralisatie noemt maar een potentieel gevaar vormen. Moet je niet willen.

En dan is er nóg een ongemakkelijke waarheid: IPv6 is vaak veiliger dan organisaties denken.

Veel malware probeert direct buurtonderzoek te doen: welke andere systemen hangen er nog meer in dit netwerk? Onder IPv4 is dat overzichtelijk. Onder IPv6 wordt dat ineens praktisch ondoenlijk. De adresruimte is zo veelomvattend dat ‘simpel’ rondkijken verandert van een snelle scan naar een operatie die absurd veel tijd en verdacht verkeer oplevert. Alleen al daardoor wordt laterale verkenning lastiger en veel beter detecteerbaar.

De kern is simpel: laterale beweging tegengaan is verstandig. Maar daar heb je niet automatisch een kostbaar hub-and-spoke landschap voor nodig. Vaak bereik je méér met minder ‘glamour’ en meer discipline. Minder open deuren. Minder overbodige rechten. Minder impliciet vertrouwen. En vooral: minder architectuur als doekje voor operationele slordigheid.

Wat is in jouw omgeving wél verstandig?

“Best practice” klinkt aantrekkelijk en veilig. Tot je ontdekt dat je onbedoeld andermans complexiteit hebt overgenomen. En geloof me, het komt vaker voor dan we met z’n allen willen.

De waarheid is simpel: wat voor de één logisch en ‘the very best practice’ is, kan voor jouw omgeving onnodig duur, lastig beheerbaar of ronduit onhandig zijn. Zeker bij keuzes rond hub-and-spoke, security en segmentatie is er geen standaardplaatje dat altijd past. Daarvoor verschillen workloads, beheerlast, risico’s en groeiplannen simpelweg te veel.

De alternatieven zijn er wel. Vaak meer dan genoeg zelfs. Maar welke combinatie verstandig is, hangt af van jouw infrastructuur. Van hoe je werkt. Van wat je wilt afschermen. En van wat je vooral níét wilt meeslepen aan kosten en complexiteit.

Hub-and-spoke oogt goed, tot je de afhankelijkheden en de rekening ziet.

 

Heb je 30 minuten? Dan kijk ik met je mee naar wat in jouw situatie logisch is. 
Gratis.

Ik heb al bij zo ontzettend veel organisaties in de IT-keuken gekeken, ik weet direct waar er ergens iets niet goed gaat. Zeg maar de Gordon Ramsey van IT, maar dan zonder het geschreeuw.

Maak een vrijblijvende afspraak. Dan weet je direct hoe je veiliger en slimmer kunt inrichten, en goedkoper.