Security architectuur: van losse maatregelen naar samenhangende beveiliging

Security architectuur geeft richting aan beveiligingskeuzes. Zij verbindt risico's en bedrijfsdoelen met de inrichting van systemen, processen en verantwoordelijkheden. Dat is ook relevant voor organisaties zonder formele architectuurafdeling.

Die samenhang raakt gemakkelijk uit beeld. Er komt een extra control na een audit, een nieuwe tool na een incident of een proceswijziging vanwege compliance. Elke stap kan verdedigbaar zijn. De vraag is of de maatregelen samen de risico's beheersen en of het beheer uitvoerbaar blijft.

Ik zag dat patroon bij een overheidsorganisatie. Business-impactanalyses werden vooral op applicatieniveau uitgevoerd, zonder duidelijke herleiding naar processen, ketens en informatieverwerkingen. Ook ontbrak een beleidsmatige koppeling met hersteldoelen. Er lag een classificatie per applicatie, terwijl de betekenis voor herstel na uitval onduidelijk bleef.

Daarbij moeten twee analyses op elkaar aansluiten. BIV-classificatie bepaalt de bescherming die nodig is voor beschikbaarheid, integriteit en vertrouwelijkheid. Een business-impactanalyse (BIA) onderzoekt de gevolgen van verstoring in de tijd en helpt prioriteiten en hersteldoelen vast te stellen. Begin bij processen en informatie en vertaal de uitkomsten naar de ondersteunende systemen en leveranciers.

Zo wordt de ontwerpvraag concreet: past de huidige inrichting bij wat de organisatie moet kunnen leveren, ook tijdens en na een verstoring?

Waarom security architectuur nodig is

Drie ontwikkelingen maken samenhangende ontwerpkeuzes nodig.

Beveiliging loopt over meerdere grenzen. Gebruikers werken op verschillende locaties en diensten kunnen bij meerdere providers draaien. Netwerkbeveiliging en segmentatie blijven relevant. Daarnaast moet u toegang beoordelen op identiteit, apparaat, gevraagde resource en context. Alleen een vertrouwd netwerk biedt daarvoor onvoldoende grond.

Leveranciers bepalen mede uw weerbaarheid. Uitbestede infrastructuur, applicaties en beheer brengen afhankelijkheden met zich mee. Leg vast welke partij welke maatregelen uitvoert, hoe u bewijs krijgt en wat er gebeurt bij verstoring of beëindiging van de dienstverlening.

Besluiten moeten te onderbouwen zijn. Bestuur, auditors en toezichthouders kunnen vragen naar de relatie tussen risico's, eisen en maatregelen. Architectuur helpt die relatie vast te leggen. Testresultaten en evaluaties moeten vervolgens laten zien of de gekozen inrichting werkt.

Dat voorkomt dat projectteams steeds dezelfde afweging opnieuw maken of tegenstrijdige uitgangspunten hanteren. Ook uitzonderingen worden zichtbare besluiten, met een eigenaar en een moment voor herbeoordeling.

Wat security architectuur in de kern is

Security architectuur vertaalt uw context en afhankelijkheden naar een samenhangend beveiligingsontwerp. Dat ontwerp beschrijft welke processen kritiek zijn, welke eisen gelden, waar u vertrouwen op baseert en hoe maatregelen elkaar aanvullen. NIST behandelt security architectuur en ontwerp binnen systems security engineering: beveiliging wordt gedurende de systeemlevenscyclus ontworpen, gerealiseerd en beoordeeld.¹

Controlkaders en architectuur vullen elkaar aan. ISO 27002 en NIST SP 800-53 bevatten ook doelen en implementatierichtlijnen. De organisatie moet deze vertalen naar haar eigen omgeving:

Een architectuurplaat kan die samenhang tonen. De bruikbaarheid blijkt uit de besluiten die ermee worden genomen en uit de inrichting die erop volgt.

De gevestigde kaders: SABSA, TOGAF en NIST CSF 2.0

SABSA is een methodiek voor bedrijfs- en risicogedreven security architectuur. Zij verbindt bedrijfsbehoeften met ontwerp en beheer gedurende de levenscyclus. De tweerichtingsherleidbaarheid helpt om zowel uit te leggen welk doel een maatregel dient als na te gaan hoe een bedrijfsbehoefte wordt afgedekt.²

TOGAF en de Architecture Development Method (ADM) bieden een aanpak voor enterprise-architectuur. Security en risicomanagement horen daarbij in de architectuurcyclus. The Open Group en The SABSA Institute hebben gezamenlijk uitgewerkt hoe beide benaderingen kunnen worden geïntegreerd.³

NIST Cybersecurity Framework 2.0, gepubliceerd in februari 2024, voegde Govern toe aan Identify, Protect, Detect, Respond en Recover. Het kader beschrijft beoogde uitkomsten voor risicobeheersing. Het schrijft geen specifieke technische architectuur voor. Dat maakt het bruikbaar om de huidige en gewenste situatie te bespreken met bestuur en risicomanagement.⁴

In de praktijk combineer ik deze kaders naar context: SABSA voor herleidbaarheid, TOGAF voor aansluiting op enterprise-architectuur en NIST CSF 2.0 als gemeenschappelijke taal. De benodigde diepgang hangt af van het vraagstuk en de inrichting die de organisatie al heeft.

De kernvraagstukken van moderne security architectuur

Zero Trust: principes vertalen naar architectuur

Zero Trust gaat uit van het ontbreken van impliciet vertrouwen uitsluitend op basis van netwerklocatie of eigendom van een apparaat. NIST SP 800-207 beschrijft hoe een Zero Trust Architecture die principes toepast op infrastructuur en werkprocessen.⁵ Daarvoor zijn keuzes nodig over identiteiten, de beveiligingsstatus van apparaten, toegangsbeleid, monitoring en de resources die u beschermt.

Een toegangstoets bij de start van een sessie en herbeoordeling op basis van relevante signalen moeten passen bij uw risico's en mogelijkheden. Bepaal ook wat er gebeurt als een centrale identiteitsdienst of beleidscomponent uitvalt. Een product kan onderdelen ondersteunen. Het ontwerp moet de samenhang en afhankelijkheden regelen.

Identity als controlepunt

Identiteitsbeheer raakt federatie, privileged access, conditional access en het toekennen en intrekken van rechten. Dat geldt voor mensen en voor niet-menselijke identiteiten, zoals workloads, serviceaccounts en AI-agenten. Leg per identiteit eigenaarschap, toegestane handelingen en de levenscyclus van credentials vast.

Identity vervangt netwerksegmentatie, gegevensbescherming en herstelvoorzieningen niet. Ontwerp deze lagen in samenhang en onderzoek welke gevolgen compromittering van een gedeelde identiteitsvoorziening heeft.

Cloud en hybride omgevingen

Bij een hybride of multi-cloudomgeving moet u bepalen welke beveiligingsfuncties u bij de provider afneemt en welke u zelf beheert. Hoe houdt u beleid consistent, wie beoordeelt configuratiewijzigingen en welke logging blijft beschikbaar bij een incident? Maak ook duidelijk welke afhankelijkheden u accepteert en hoe u gegevens en dienstverlening kunt overzetten.

Meerdere cloudproviders bieden op zichzelf geen onafhankelijk herstelpad. Diensten kunnen bijvoorbeeld dezelfde identityprovider, netwerkverbinding of beheerpartij gebruiken. Die gedeelde afhankelijkheden horen in het ontwerp.

Leveranciersbeheersing als architectuurvraagstuk

ISO 27002:2022 behandelt leveranciersrelaties in maatregelen 5.19 tot en met 5.22 en cloudgebruik in 5.23. NIST SP 800-53 Rev. 5 bevat de controlfamilie Supply Chain Risk Management.⁶ Deze kaders helpen bij vragen over selectie, afspraken, toezicht op de dienstverlening en wijzigingen.

Uitbesteding vraagt dat u verantwoordelijkheden tussen uw organisatie en de leverancier expliciet maakt. Bepaal welk bewijs nodig is gezien de dienst, de risico's en de toepasselijke regels. Contractuele afspraken, onafhankelijke assurance, testresultaten en auditrechten kunnen daarbij verschillende functies vervullen. Een auditrecht alleen toont nog niet aan dat een maatregel werkt.

Ook bij een dienst waarvan u de interne inrichting beperkt kunt inzien, moet u voldoende onderbouwing krijgen. Beoordeel de scope en uitzonderingen van rapportages, de herstelafspraken en uw eigen aanvullende maatregelen. Als de onderbouwing tekortschiet, vraagt dat om een besluit over aanvullende beheersing of een andere inrichting.

Herstel als architectuurvraagstuk

Een BIA helpt om herstelprioriteiten af te leiden uit de gevolgen van verstoring. De RTO is de beoogde hersteltijd. De RPO bepaalt tot welk tijdstip gegevens moeten kunnen worden teruggezet en daarmee hoeveel dataverlies, uitgedrukt in tijd, aanvaardbaar is. Die doelen moeten passen bij de dienstverlening en onderling afhankelijke processen.⁷

Vervolgens onderzoekt u welke inrichting die doelen haalbaar maakt. Bij een korte RTO kan een vooraf ingerichte, geïsoleerde herstelomgeving nodig zijn. Andere situaties vragen om een andere oplossing. Neem ook identiteiten, sleutels, configuraties, schone hersteldata en beschikbare mensen mee. Technische failover na een storing en veilig herstel na een cyberaanval stellen verschillende eisen.

Oefen de volledige herstelketen. Een geslaagde back-up zegt nog weinig over het tijdig hervatten van een dienst. Testresultaten maken zichtbaar welke afhankelijkheden en aannames moeten worden aangepast.

De drie valkuilen: waar architectuurtrajecten vastlopen

Ontwerpprincipes zijn pas bruikbaar als zij richting geven aan uitvoering. Drie terugkerende problemen:

1. Te abstract. Referentieplaten geven onvoldoende houvast voor concrete keuzes in projecten of aanbestedingen. Werk principes uit in toetsbare eisen en besluiten.
2. Te technisch. De verbinding met bedrijfsprocessen, risicobereidheid, leveranciers en eigenaarschap ontbreekt. Daardoor blijven besluiten over middelen en verantwoordelijkheden liggen.
3. Te reactief. Bevindingen uit pentests, incidenten en audits leiden tot losse reparaties. Onderzoek ook of de oorzaak in het ontwerp zit en of de oplossing elders gevolgen heeft.

Verbind daarom risico en eisen aan ontwerp, implementatie en verantwoording. De uitkomsten van tests en evaluaties moeten kunnen terugwerken op eerdere keuzes.

Hoe architectuur helpt bij naleving

De Cyberbeveiligingswet geldt sinds 15 augustus 2026. Het Cbb en toepasselijke sectorregelingen werken de eisen verder uit. Voor overheidsorganisaties regelen de BZK- en IenW-regelingen de toepassing van ISO en relevante BIO2-maatregelen. BIO2 is daarbij een normenkader met een wettelijke rol via die regelingen.⁸ Voor financiële entiteiten binnen de reikwijdte van DORA gelden sinds 17 januari 2025 specifieke eisen aan digitale operationele weerbaarheid.⁹

Neem toepasselijke eisen vanaf het begin mee in uw ontwerp. Leg vast hoe u eraan voldoet en welke ruimte er is voor eigen keuzes. Architectuur helpt de onderbouwing te organiseren, maar vervangt geen werkende maatregelen, wettelijke meldingen, registratie of bestuurlijke verplichtingen. Ook een beschreven herstelvoorziening moet worden getest.

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

Hoe ik security architectuur benader

Ik maak de relatie tussen bedrijfsbehoeften, risico's en beveiligingskeuzes zichtbaar. De aanpak bestaat uit drie samenhangende onderdelen:

1. Context, eisen en risico. We brengen kritieke processen, informatie en afhankelijkheden in kaart. Wettelijke eisen, contractuele afspraken en relevante normen horen vanaf de start bij die afbakening. We toetsen welke aannames de huidige inrichting dragen.
2. Ontwerpprincipes en structuur. We maken keuzes over identity, clouddiensten, segmentatie, herstel en leveranciers. Per keuze leggen we de onderbouwing, verantwoordelijke eigenaar en gevolgen vast. SABSA en TOGAF kunnen helpen om dit aan de bestaande architectuurpraktijk te verbinden.
3. Toetsing en doorvoering. We beoordelen het ontwerp met de toepasselijke eisen en kaders, vertalen besluiten naar uitvoerbaar werk en bepalen hoe de werking wordt getoetst. Normenkaders worden daarbij doorlopend gebruikt. Afwijkingen, testresultaten en wijzigingen geven aanleiding tot bijsturing.

De uitwerking moet bruikbaar zijn voor de mensen die besluiten nemen en de inrichting realiseren. Dat vraagt om duidelijke ontwerpbesluiten, gerichte architectuurbeelden en een uitvoerbare volgorde van verbeteringen.

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