Ontwerpkeuze
Geen vanzelfsprekend vertrouwen in netwerkverkeer
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Hoe voorkom je dat één inbraak zich vrij verspreidt?
- Leidend
- ja
Principes
Digitale veiligheid als voortdurend ontwerpprincipe (zero trust); segmentatie beperkt verspreiding; gelaagde beveiliging; inzicht in netwerkverkeer.
Waarom niet eenvoudiger
Eén buitengrens is eenvoudiger te beheren, maar wie binnen is, beweegt zich dan vrij. Daarom is alleen vooraf vastgelegd, herkend en versleuteld verkeer toegestaan; onversleuteld verkeer is een uitzondering met einddatum.
Wat het oplevert
Verkeer tussen zones is standaard dicht en gaat alleen via firewalls. Netwerkbeleid, applicatie-identiteit en de rechten bij de ontvangende dienst begrenzen samen de toegang.
Wat het vraagt
Meerdere lagen vragen beheer en bewijs. In de eerste levering verzorgt de toepassing zelf de versleuteling; de overgang naar het dienstennetwerk moet ondersteund en beproefd zijn.
- Lost op
- Uitgewerkt in
Onderwerpen die eruit volgen
Opbouw van het platform
Eén vlootbeheer boven zelfstandige beheercellen, één per datacenter, met vier eigen platformclusters per cel. Wat de cellen delen, is vlootbreed of staat buiten de cellen, met eigen maatregelen en een eigen herstelpad.
Zonering en verkeersstromen
Het netwerk van een cel is verdeeld in zones met elk een eigen vertrouwensniveau. Verkeer tussen zones gaat alleen via de firewall en alleen langs vooraf vastgelegde, getoetste verkeersstromen; een team declareert zijn verbindingen en de zonecontrole toetst ze.
Architectuurprincipes
De architectuurprincipes van RWS en de overheid waaraan het platform is getoetst, per bron en met hoe het platform ieder principe verwerkt, en de afwegingen waar principes met elkaar schuren.
Bouwen op het bouwcluster
Eigen software wordt alleen gebouwd op één afgeschermd bouwcluster, met een gepubliceerde versie van het pijplijnsjabloon. Het sjabloon legt de vaste stappen, controles en toegangsbewijzen vast; teams kiezen alleen de bouwmethode en hun eigen tests.
Dienstbeschrijving en toetsing
De dienstbeschrijving is de enige invoer van een team. Een toetspijplijn in de opslagplaats Afnemers toetst ieder voorstel, langs iedere ingang, aan de geldende regels: rol, velden, capaciteit, zones en instemming.
Het datacenternetwerk van een cel
Iedere cel krijgt een eigen fabric op EVPN en VXLAN, met Cisco Nexus 9000-switches in NX-OS-modus en Nexus Dashboard als fabriccontroller. De fabric is dubbel uitgevoerd, wordt als code beheerd en met een vaste testset beproefd.
Certificaten en PKI
Waar certificaten vandaan komen en hoe lang ze gelden. De interne RWS-PKI is de wortel, iedere cel heeft een eigen tussen-CA, certificaten zijn kortlevend en worden automatisch vernieuwd, en publieke namen hebben een gescheiden keten.
De herstelomgeving
Een tijdelijk, afgeschermd gehost cluster uit code, op afroep in de gezonde cel, waarin een kopie eerst wordt gecontroleerd en de dienst wordt beproefd voordat productie terugkomt. Zij staat in een eigen zone zonder route naar productie en wordt na afloop verwijderd.
Logboeken en de koppeling met het SOC
Audit- en beveiligingslogboeken gaan van ieder cluster rechtstreeks naar de SIEM van het SOC, dat er een onveranderbare kopie van bewaart; beheerlogboeken blijven in de cel. Voor bronnen, transport, inhoud en bewaring gelden vaste regels.
Scheiding per afnemer
Ieder cluster dat koppelt, krijgt een eigen ruimte met quotum en eigen, beperkte sleutels. Objectopslag is per vertrouwensdomein gescheiden in realms, en alle gegevens zijn versleuteld.
Segmenten, adressen en aansluitingen
Hoe de fabric verkeer scheidt in segmenten, welke VLAN’s, VNI’s en adresreeksen daarbij horen, hoe servers en clusters aansluiten, en waar adressen en namen worden toegewezen en geregistreerd.
Celgrens, verbindingen en certificaten
De cel is een vertrouwensgrens: beheerrechten, geheimen en certificaten gelden per cel, verkeer tussen de cellen is standaard geweigerd, en alleen vlootbrede rollen en vastgelegde stromen gaan over de grens.
Netwerkbeleid en uitgaand verkeer
Binnen een cluster gaat het beleid van het platform vóór dat van het team: verkeer tussen naamruimten en afnemers is standaard geweigerd en uitgaand verkeer mag alleen naar vastgelegde bestemmingen. Daarbij horen de netwerkvarianten die een team kan kiezen en de weg naar een dienstennetwerk.
Adres, verbindingen en versleuteling
De database is alleen bereikbaar via een eigen adres en naam voor de schrijvende kant, alleen met TLS 1.3, en alleen voor de toepassingen en platformdiensten die de dienstbeschrijving en het netwerkbeleid toestaan.
Beveiliging van het vlootbeheer
Wie het vlootbeheer beheerst, raakt beide cellen. Daarom gelden extra beoordeling, hardwaresleutels, opname van iedere sessie, gescheiden ingangen, geheimen per cel en een eigen dreigingsmodel.
De beheerwerkplek
Iedere bevoorrechte sessie loopt via de beheerwerkplek en wordt opgenomen. Platformbeheer en teams hebben elk een eigen ingang en een eigen pool beheerservers, en zonder opname start geen sessie.
Netwerk en scheiding van afnemers
Hoe de werkervirtualisatie en haar machines op het datacenternetwerk aansluiten: eigen VLAN’s per verkeerssoort, een segment per applicatiecluster, de opslagaansluiting, adresuitgifte, scheiding op het segment voor virtuele machines en versleuteling.
Netwerk en verbindingen
In welke netwerken het basisdienstencluster en zijn virtuele machines staan, welk verkeer het netwerkbeleid toelaat en welke verbindingen er van en naar het cluster lopen.
Publicatie, namen en TLS
Hoe een dienst van buiten bereikbaar wordt: via een eigen virtueel adres op de externe verkeersverdeling, als doorgifte zonder TLS-afsluiting, met TLS, certificaat en naam bij de ingang of bij de dienst zelf.
Netwerk, ingang en verkeer tussen diensten
Hoe het clusterbeheer en de applicatieclusters in het netwerk staan, hoe een cluster wordt gepubliceerd, welk netwerkbeleid geldt en hoe het verkeer tussen diensten nu en in de doelsituatie is beschermd.
Koppelingen met bestaande systemen
Hoe een toepassing op het platform gegevens uit een bestaand systeem mag lezen: begrensd in vier lagen, met instemming van de eigenaar van de bron, op de identiteit van de toepassing en langs het werkelijke pad beproefd.
Wat voor ieder onderdeel geldt
De regels die ieder onderdeel van het platform volgt: inrichting uit code, zelfstandig per cel, toegang op identiteit, alleen vrijgegeven software, logboeken naar het SOC, ondersteunde versies, beproefde draaiboeken en één eindverantwoordelijke.
De beveiligingsbaseline
De beveiligingsbaseline van het platform: risicogerichte, gelaagde maatregelen met norm en bewijs, met BIO2 en ISO/IEC 27002:2022 als kader, getoetst aan de referentieset securityeisen, met uitzonderingen, onderhoud en naleving.
Inrichting, netwerk en beproeving
Hoe de bewaking zelf wordt ingericht, verbonden, beschermd en beproefd: als code in de standaardinrichting, met een vastgelegde softwarestapel, vaste stromen in de zonematrix, een foutdomeinmodel, een taakverdeling, draaiboeken en een bewijsset per fase.
Verkeer tussen de cellen en de overgang
De fabrics van de twee cellen koppelen alleen gerouteerd; afnemersverkeer naar de andere cel loopt via de ingang van die cel, en een bedrijfskritische dienst schakelt nooit automatisch om. Met de overgang van het oude netwerk in AM2 en de routekaart van netwerk en ingang.