Security architectuur: van losse maatregelen naar samenhangende beveiliging

Security architectuur wordt vaak verward met referentieplaten en theoretische doelarchitecturen. Iets dat zweeft tussen enterprise-architectuur en security operations, bedoeld voor multinationals met een formele architectuurafdeling. Die voorstelling is hardnekkig, en verkeerd.

In de praktijk is security architectuur de discipline die ervoor zorgt dat uw beveiliging samenhang krijgt. Het is het mechanisme dat risico's, afhankelijkheden, ontwerpprincipes en verantwoordelijkheden bij elkaar brengt tot één logisch geheel.

Daar gaat het in veel organisaties mis. Maatregelen worden reactief gestapeld: een extra control na een audit, een nieuwe tool na een incident, een proceswijziging vanwege compliance. Elke stap is op zichzelf verdedigbaar, maar zonder architectuur ontstaat er geen samenhang. Uw beveiliging groeit dan in omvang en kosten, niet in kwaliteit. In de literatuur heet dat patroon control sprawl of security debt.

Ik zag dat patroon in zijn zuiverste vorm bij een overheidsorganisatie. Elk probleem werd operationeel benaderd; wat ontbrak, was de stap terug: veroorzaakt onze inrichting dit probleem, en lossen we het op de juiste laag op? Dat werd concreet zichtbaar in de risicoclassificatie. Business impact-analyses werden vooral op applicatieniveau uitgevoerd, zonder duidelijke herleiding naar processen, ketens en informatieverwerkingen. Terwijl BIV-classificatie primair daar hoort te beginnen: bij de impact op het proces en de informatie die daarin wordt verwerkt. Ook ontbrak een beleidsmatige koppeling tussen de BIA en de RTO's en RPO's. Zo bleef classificatie een papieren exercitie: er lag een cijfer op elke applicatie, maar niemand kon uitleggen wat dat betekende voor herstel na uitval. Dat is schijnzekerheid, geen beveiliging.

De onderliggende fout is bijna altijd dezelfde. Er wordt vanuit techniek naar een oplossing toe gewerkt, terwijl de vraag zou moeten zijn of de organisatie zelf anders ingericht moet worden. Dat onderscheid, tussen een probleem operationeel wegwerken en het bij de wortel adresseren, is precies waar architectuur over gaat.

Waarom security architectuur onmisbaar is geworden

Drie ontwikkelingen hebben security architectuur van nice-to-have naar noodzaak getild.

Het perimeter-model is verdwenen. De klassieke burcht met de firewall als gracht bestaat niet meer. Gebruikers werken overal, workloads draaien bij meerdere cloudproviders, en identiteiten zijn de nieuwe perimeter geworden in plaats van netwerksegmenten. Zonder architectonische keuzes over identity, segmentatie en trust-zones ontstaat een onhoudbare lappendeken.

De keten is uw grootste aanvalsvlak. U besteedt infrastructuur, applicaties en beheer uit. Leveranciers nemen technische beslissingen en beheren configuraties. Uitbesteding neemt uw verantwoordelijkheid voor risicobeheersing en leveranciersregie echter niet weg. Zonder ontwerp voor afhankelijkheden bent u gijzelaar, geen regisseur.

Toezicht eist uitlegbaarheid. Of het nu gaat om NIS2, DORA, BIO2, een ISO-audit of een due diligence bij een overname: de vraag verschuift van een opsomming van maatregelen naar de onderbouwing erachter. Zonder architectonische onderbouwing is elk antwoord anekdotisch.

Zonder security architectuur ontstaan bekende patronen: controls zonder risicokoppeling, projectteams die los van elkaar beveiligingsbesluiten nemen, en leveranciers die hun eigen logica toepassen terwijl u denkt de regie te hebben. Wanneer een auditor of toezichthouder vragen stelt, blijkt dat maatregelen wel aanwezig zijn, maar niet uitlegbaar.

Wat security architectuur in de kern is

Security architectuur vertaalt uw risico's, context en afhankelijkheden naar een samenhangend beveiligingsontwerp. Dat ontwerp gaat verder dan technische componenten. Het definieert grenzen, uitgangspunten en verantwoordelijkheden: welke processen zijn echt kritiek, welke afhankelijkheden accepteren we, waar leggen we vertrouwen neer en waar organiseren we harde controles. NIST positioneert dit vakgebied als onderdeel van systems security engineering: beveiliging als ontworpen systeemeigenschap, en niet als verzameling toegevoegde maatregelen.¹

Daarmee is security architectuur wezenlijk iets anders dan een control framework:

Normenkaders zijn essentieel, maar ze vervangen architectuur niet. Zij leveren de grammatica; architectuur schrijft het verhaal.

De gevestigde kaders: SABSA, TOGAF en NIST CSF 2.0

Security architectuur is geen uitvinding van gisteren. Er bestaan beproefde, open kaders en methodieken die onderbouwen hoe u risico vertaalt naar ontwerp.

SABSA (Sherwood Applied Business Security Architecture) is de meest volwassen methodiek specifiek voor risicogedreven security architectuur. SABSA werkt top-down vanuit business requirements via zes lagen (contextueel, conceptueel, logisch, fysiek, component en operationeel) naar concrete implementatie. De kracht zit in de chain of traceability: elke technische keuze is terug te leiden tot een expliciete business requirement en risicoanalyse.² Precies de uitlegbaarheid die moderne toezichthouders eisen.

TOGAF Architecture Development Method (ADM) biedt het bredere enterprise-architectuurkader waarop security integreert. TOGAF en SABSA zijn expliciet ontworpen om naast elkaar te werken: TOGAF levert de enterprise-architectuurcyclus, SABSA vult het security-domein daarin in.³

NIST Cybersecurity Framework 2.0 introduceerde begin 2024 de Govern-functie naast Identify, Protect, Detect, Respond en Recover, expliciet om cybersecurity als bestuurs- en risicocommunicatievraagstuk te positioneren.⁴ Dat maakt CSF 2.0 bruikbaar als brug tussen de architectuur en de directietafel.

In de praktijk combineer ik deze kaders naar context. SABSA als motor voor traceability, TOGAF als kader voor integratie met bredere enterprise-architectuur, NIST CSF 2.0 als gemeenschappelijke taal richting bestuur. Geen van deze kaders is een doel op zich. Het zijn instrumenten om keuzes expliciet en verdedigbaar te maken.

De kernvraagstukken van moderne security architectuur

Zero Trust: principe, geen product

Zero Trust is het dominante ontwerpprincipe van het afgelopen decennium: verifieer continu, vertrouw nooit op basis van locatie. Een architectuurvraagstuk bij uitstek, want Zero Trust is een set ontwerpkeuzes over identity, device posture, segmentatie en access policies, geen tool die u koopt. NIST SP 800-207 beschrijft de architectuurcomponenten en migratiepaden, en maakt daarbij expliciet dat een zero trust-architectuur begint bij inzicht in de eigen organisatie, resources en dataflows.⁵ Wie Zero Trust framet als productcategorie, stapt in de marketinghype en mist het punt. De architectuurvraag is: welke Zero Trust-principes passen bij uw risicoprofiel, uw bestaande identity-infrastructuur en de volwassenheid van uw operations-teams?

Identity als de nieuwe perimeter

Waar netwerkgrenzen eroderen, wordt identity het primaire controlepunt. Dat verschuift fundamentele architectuurkeuzes naar vragen over federatie, privileged access, conditional access, lifecycle management en non-human identities (workloads, service accounts, agentic AI). Een zwakke identity-architectuur maakt elke andere beveiligingslaag kwetsbaar. Een sterke identity-architectuur maakt veel andere lagen goedkoper.

Cloud-native en multi-cloud

De meeste organisaties zijn inmiddels hybride of multi-cloud. Dat betekent ontwerpkeuzes maken, in plaats van dezelfde architectuur drie keer te kopiëren: waar legt u beveiligingslogica neer (provider-native of provider-agnostisch), hoe borgt u consistentie in beleid, waar accepteert u lock-in als prijs voor eenvoud, en hoe vermijdt u dat elke cloud zijn eigen parallelle security-stack krijgt?

Supply chain als architectuurvraagstuk

De grootste architectuuruitdaging ligt vaak buiten uw eigen muren. Leveranciers beheren kritieke configuraties, maar de risicoverantwoordelijkheid blijft bij u. Dat maakt leveranciersbeheersing een ontwerpvraagstuk, expliciet zo gepositioneerd in ISO/IEC 27002 en NIST 800-53.⁶ De vragen zijn concreet: welke security-eisen moeten leveranciers aantoonbaar ondersteunen, welke principes zijn onderhandelbaar in contracten, waar accepteert u een black box-dienst en waar niet?

Die laatste vraag is onder NIS2 scherper geworden. Een black box-dienst kan operationeel prima presteren, maar aantoonbaarheid vereist dat u de werking kunt uitleggen: welke maatregelen de leverancier treft, hoe herstel verloopt, waar uw data staat. Wat u niet rechtstreeks kunt inzien, moet u op een andere manier aantoonbaar maken: via contractuele afspraken, assurance-rapportages of auditrechten. Voor kritieke functies, en herstel is er daar één van, is een dienst die geen van die routes biedt daarmee een compliance-risico, hoe goed de dienst technisch ook is.

Wie deze vragen niet expliciet maakt, heeft geen regie. Alleen afhankelijkheid.

Herstel als architectuurvraagstuk

Herstel wordt vaak behandeld als een technisch onderwerp: backups, replicatie, een tool. Dat is de verkeerde laag. De snelheid van herstel en het maximale dataverlies worden gedefinieerd door business-eisen, vastgelegd als RTO en RPO. Om die eisen waar te maken is een strategie nodig die op procesniveau, mensniveau en technisch niveau tegelijk werkt. Herstel raakt daarmee per definitie alle pijlers van de organisatie. Wie de nadruk op één pijler legt, overziet het geheel niet.

Die business-eisen sturen vervolgens harde ontwerpkeuzes. Een ambitieuze RTO valt niet te halen door na een incident te beginnen met opbouwen. Dan kan een vooraf ingerichte, geïsoleerde herstelomgeving nodig zijn, waar identiteiten, deployment-pijplijnen en monitoring al klaarstaan, maar strikt gescheiden van productie vanwege besmettingsgevaar. Dat is geen productkeuze. Het is een architectuurkeuze die rechtstreeks volgt uit een business-eis, en die zonder architectonische onderbouwing nooit door een investeringsbeslissing komt.

De drie valkuilen: waar architectuurtrajecten vastlopen

Veel organisaties hebben ergens een document met ontwerpprincipes liggen. Dat betekent niet dat de architectuur werkt. Drie terugkerende problemen:

1. Te abstract. Er zijn fraaie referentieplaten, maar ze sturen geen enkele concrete keuze in dagelijkse projecten of aanbestedingen. De architectuur is documentatie, geen besluitvormingsinstrument.
2. Te technisch. De focus ligt uitsluitend op netwerksegmentatie, firewalls of IAM-tools, terwijl de verbinding met governance, leveranciers en risicobereidheid ontbreekt. Dit levert technische kwaliteit op, geen bestuurbare organisatie.
3. Te reactief. Er is geen expliciete ontwerplogica. Keuzes zijn incidentgedreven: na een pentest wordt een gat gedicht, na nieuwe wetgeving wordt iets in kaart gebracht. Er is geen kompas, alleen reactie.

Security architectuur werkt pas wanneer zij de brug vormt tussen risico, ontwerpprincipe, implementatie en bestuurlijke verantwoording.

Architectuur als hefboom voor compliance

Wetgeving als NIS2 en de Cyberbeveiligingswet, DORA voor de financiële sector, of BIO2 voor de overheid, is zelden de aanleiding voor een goede architectuur. Maar zij beloont een goede architectuur wel. Wie samenhangend ontwerpt, kan aantoonbaarheid leveren zonder maandenlang te reconstrueren. Wie losse controls stapelt, zit bij elke audit opnieuw in een archeologische opgraving.

Voor de vertaling naar wettelijke context, zie NIS2 implementatie en NIS2 audit en aantoonbaarheid.

Hoe ik security architectuur benader

Mijn aanpak draait niet om dikke boekwerken of visueel indrukwekkende diagrammen. Ik benader security architectuur als het instrument om uw beveiliging uitlegbaar en bestuurbaar te maken, in drie fasen:

1. Context en risico. We brengen in kaart wat echt kritiek is. Waar zitten materiële faalwijzen en afhankelijkheden? Welke keuzes zijn in het verleden impliciet gemaakt, en welke aannames willen we expliciet maken?
2. Ontwerpprincipes en structuur. We maken keuzes zichtbaar. Waar standaardiseren we, waar zijn uitzonderingen legitiem? Hoe gaan we om met identities, cloud-diensten, segmentatie, recovery en ketenafhankelijkheden? Hier levert SABSA de traceability en TOGAF de integratie met enterprise-architectuur.
3. Normenkaders als toetssteen. Pas daarna krijgen normen (ISO 27001/27002, BIO2, NIST CSF 2.0, NIST 800-53) hun plek. Als bewezen instrumenten om keuzes te structureren en aantoonbaar te maken, nooit als afvinklijst.

Deze aanpak is de kern van de dienst Security-architectuur →