Security by Design: zo bouw je een veilig en schaalbaar dataplatform

Wat is Security by Design?

Security by Design is zowel een technisch principe als een manier van werken. Je ontwerpt identiteit, toegang, netwerkpaden, data-classificatie, logging en incident & change management als één geheel. Daarmee voorkom je dat beveiliging later als verzameling uitzonderingen wordt toegevoegd. Het resultaat is niet alleen veiliger, maar ook beter uitlegbaar, eenvoudiger te auditen en makkelijker op te schalen.

Waarom gebruikersgedrag onderdeel is van Security by Design

Zonder een goed fundament kan er geen veilig dataplatform worden gebouwd. Het effect van veiligheidsmaatregelen hangt af van hoe mensen ermee omgaan. Zelfs een sterk ontwerp faalt wanneer gebruikers beveiliging vooral als obstakel zien. De mentaliteit van gebruikers is daarom vaak showstopper nummer één. Als uitzonderingen de standaard worden, accounts worden gedeeld of updates bewust worden uitgesteld, verliest de architectuur haar effect. Maak veilig gedrag daarom de eenvoudigste route: bied duidelijke rollen, snelle maar controleerbare toegang, begrijpelijke richtlijnen. Bovenop het fundament zijn er drie samenhangende pijlers voor een veilig dataplatform.

De 3 pijlers van een veilig dataplatform

De kern: een veilig dataplatform steunt op drie samenhangende pijlers: Identity & Access Management, networking en incident & change management. Als één pijler ontbreekt, ontstaan blinde vlekken die de andere maatregelen niet volledig kunnen opvangen.

Schaalbaar toegangsbeheer met IAM en RBAC

• IAM en RBAC: Identity & Access Management (IAM) organiseert wie toegang krijgt tot welke onderdelen van het dataplatform. Role-Based Access Control (RBAC) koppelt die toegang aan rollen, zodat rechten schaalbaar, consistent en controleerbaar kunnen worden beheerd.
• Least privilege: Dit betekent dat iedere gebruiker, applicatie of geautomatiseerd proces alleen de minimale rechten krijgt die nodig zijn om een taak uit te voeren, niet meer en niet langer dan noodzakelijk. Een data-analist kan bijvoorbeeld wel datasets lezen en analyseren, maar kan de data niet manipuleren. Door verantwoordelijkheden te scheiden, voorkom je bovendien dat één persoon zelfstandig een gevoelige wijziging kan aanvragen, goedkeuren én uitvoeren.

  Om least privilege praktisch in te richten, kun je Role-Based Access Control (RBAC) gebruiken. Stel eerst persona’s op basis van functies of verantwoordelijkheden op in rollen. Definieer per rol een duidelijke scope en de minimaal benodigde acties, scheid waar nodig lees-, schrijf- en beheerrechten en voorkom conflicterende rollen. Wijs gebruikers vervolgens via groepen aan deze rollen toe, in plaats van rechten rechtstreeks aan individuele accounts te koppelen. Zo ontstaat een beheersbaar model van gebruiker naar groep, van groep naar rol en van rol naar permissies. Dat maakt wijzigingen bij instroom, functiewisselingen en uitstroom beheersbaar en controleerbaar, terwijl periodieke reviews voorkomen dat rollen ongemerkt te breed worden.

  Bij grotere organisaties is het niet praktisch om groepen handmatig te beheren. Gebruik waar mogelijk dynamische securitygroepen, waarbij gebruikers automatisch worden toegevoegd op basis van betrouwbare kenmerken, zoals hun functie of afdeling. Leg deze groepen, rollen en toewijzingen vervolgens vast als Infrastructure as Code (IaC), bijvoorbeeld met Terraform. Zo worden wijzigingen reproduceerbaar, toetsbaar via een reviewproces en consistent over omgevingen heen.

  Schaal maakt het verschil. In een goed ontworpen toegangsmodel zijn doorgaans minder securitygroepen dan gebruikers nodig, omdat meerdere gebruikers met dezelfde functie of verantwoordelijkheid aan dezelfde rollen en groepen worden gekoppeld. Zijn er juist evenveel of meer groepen dan gebruikers, dan is dat een signaal dat het model onnodig complex is geworden en dat RBAC en least privilege mogelijk niet goed zijn ingericht. Het is geen harde regel, maar wel een goede aanleiding om rollen, uitzonderingen en directe toewijzingen opnieuw te bekijken. Toch bepaalt een goed rollenmodel alleen welke data iemand kan benaderen; soms is ook bescherming binnen een dataset nodig.

• Data masking: Schermt gevoelige velden af voor gebruikers die de onderliggende dataset wel nodig hebben, maar de gevoelige waarden niet hoeven te zien. Waar RBAC vooral bepaalt tot welke data iemand toegang krijgt, kan masking bijvoorbeeld voorkomen dat een analist een BSN ziet. Alleen rollen die deze informatie echt nodig hebben, krijgen de oorspronkelijke waarde te zien. Zo hoef je niet voor iedere doelgroep een aparte dataset te maken en beperk je tegelijkertijd de blootstelling van gevoelige data.

  Een schaalbaar toegangsmodel brengt deze onderdelen samen: duidelijke rollen op basis van least privilege, gebruikers die via beheersbare groepen aan die rollen worden gekoppeld en masking voor gevoelige gegevens die niet iedereen hoeft te zien. Met vaste naamgeving, duidelijk eigenaarschap, automatische provisioning, periodieke toegangsreviews en een gecontroleerd verwijderproces blijft dit model ook bij groei overzichtelijk. Ontwerp de toegang daarom niet alleen voor de eerste honderd gebruikers, maar voor de omvang en complexiteit die het platform over enkele jaren kan bereiken.

Beperk het aanvalsoppervlak met Zero Trust en netwerksegmentatie

Netwerksegmentatie verdeelt een infrastructuur in afzonderlijke zones en staat verkeer tussen die zones alleen toe wanneer daar een expliciete functionele reden voor is. Zo verklein je het aanvalsoppervlak en beperk je de mogelijke impact van een incident.

Networking bepaalt hoe systemen, gebruikers en databronnen technisch met elkaar kunnen communiceren. Een dienst kan bijvoorbeeld publiek bereikbaar zijn, alleen via een bedrijfsnetwerk of uitsluitend via een virtual private networking (VPN) verbinding. Daarbij kijk je niet alleen naar inkomend verkeer, maar ook naar uitgaand verkeer. Welke externe diensten mag een platform benaderen en hoe voorkom je dat data via een ongecontroleerde route het platform verlaat?

Daarmee verschilt networking van Identity & Access Management: IAM controleert wie een identiteit is en welke handelingen die mag uitvoeren, terwijl networking bepaalt of die identiteit een dienst technisch kan bereiken. De twee zijn dus geen alternatieven, maar aanvullende lagen: IAM beperkt de rechten binnen het platform, networking de toegangspaden ernaartoe.

Combineer daarom Zero Trust-principes met netwerksegmentatie, private verbindingen en een expliciete scheiding tussen ontwikkel-, test- en productieomgevingen. Volgens NIST SP 800-207 over Zero Trust Architecture wordt geen impliciet vertrouwen toegekend op basis van alleen de netwerkpositie of het eigendom van een systeem. Zo kan een gecompromitteerd account of systeem zich niet zomaar door het hele platform bewegen en blijft de impact van een incident beperkt. Andersom voorkomt sterke autorisatie dat technische netwerktoegang automatisch toegang tot data betekent. Networking en IAM verkleinen zo samen het aanvalsoppervlak en de mogelijke impact van fouten en incidenten.

Een veilig netwerk moet ook overzichtelijk en goed te beheren zijn. Leg netwerkregels en routes centraal vast, zodat wijzigingen gecontroleerd worden doorgevoerd en omgevingen hetzelfde blijven werken. Houd daarnaast bij welke verbindingen worden gemaakt, welke verzoeken worden geblokkeerd en wie instellingen wijzigt. Zo vallen afwijkend verkeer en ongewenste toegang sneller op.

Wat heeft Security by Design te maken met NIS2 en de AI Act?

Security by Design kan bijdragen aan aantoonbaar risicomanagement, passende beveiligingsmaatregelen, governance en beheer over de volledige levenscyclus. Dat sluit aan op onderwerpen in de officiële NIS2-richtlijn, waaronder beheers maateregelen en incidentrapportage. Voor AI-systemen raakt dezelfde aanpak aan de risicogestuurde governance en beheersing die centraal staan in de geconsolideerde Europese AI Act. Welke verplichtingen precies gelden, hangt af van de organisatie, sector, rol en het type systeem. Security by Design ondersteunt compliance, maar vervangt geen juridische scopebepaling of afzonderlijke toetsing aan alle toepasselijke vereisten.

Security by Design-checklist voor je dataplatform

Met deze Security by Design-checklist controleer je of de belangrijkste beveiligingsprincipes in de architectuur en het beheer van je dataplatform zijn verwerkt.