Ontwerpkeuze
Beveiliging en controle in de standaard
Rust op Twaalf dragende ontwerpkeuzes. Bevestigd door vdo89 op 26 september 2026. Bron in de atlas
- Vraag
- Hoe blijft een maatregel ook na oplevering werken?
- Leidend
- nee
Principes
Veilig door ontwerp en standaardinstelling; verifieer altijd; observeer en verifieer continu; beheers risico’s voortdurend; continue beveiligingsbewaking.
Waarom niet eenvoudiger
Controle achteraf per audit is lichter, maar kan afwijkingen maanden laten bestaan en maakt het bewijs per dienst tot handwerk.
Wat het oplevert
Voorgeschreven instellingen en controles horen bij elke levering. Het platform blijft afwijkingen signaleren en houdt per maatregel ontwerp, bewijs en uitzonderingen bij.
Wat het vraagt
Niet elke eis is technisch af te dwingen. Organisatorische afspraken, bewijs en uitzonderingen met een eigenaar en einddatum blijven nodig.
- Lost op
- Uitgewerkt in
Onderwerpen die eruit volgen
Aanvoerroutes, quarantaine en vrijgave
Software komt langs drie routes binnen en is pas bruikbaar na vrijgave in de containerregistry van de cel: eigen software via de bouw, software van derden via de toelatingsroute en platformsoftware via de gecontroleerde spiegel. Quarantaine, rechten per ruimte en doorzetten op inhoudskenmerk houden die vrijgave controleerbaar.
Beschermingslagen en de onveranderbare kopie
Kopieën in de cel beschermen tegen fouten en tegen uitval van onderdelen; de onveranderbare kopie op de back-upvoorziening van RWS, buiten de cel en buiten de beheerrechten van het platform, beschermt de productie. De cel heeft geen rechten op haar eigen bescherming, en voor alle back-ups geldt één bewaarregel.
Geheimenbeheer
Hoe toepassingen en beheerders aan geheimen komen. Eén geheimenbeheer per cel, kort geldige inloggegevens op de eigen identiteit, en vervanging zonder onderbreking waar de koppeling dat toelaat.
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.
Sleutels, ontgrendeling en versleuteling
Welke sleutels er zijn en waar ze liggen, hoe het geheimenbeheer van buiten de cel wordt ontgrendeld, en wat er in rust en tijdens transport versleuteld is.
Uitrol van de gewenste inrichting
Het vlootbeheer rolt alleen ondertekende, beoordeelde inrichting uit Platform en Beleid uit, met één Argo CD in het pushmodel, begrensde projecten en identiteiten, en zet afwijkingen terug.
Beoordelen en samenvoegen in versiebeheer
Versiebeheer is beschermd met ondertekende vastleggingen, een beschermde hoofdtak en twee beoordelaars naast de auteur. Binnen de vastgestelde varianten voegt alleen een samenvoegidentiteit automatisch samen; sjablonen en beleid nooit.
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.
Ondertekening en herkomst
Een onafhankelijke besturing van het platform tekent resultaat, onderdelenlijst en herkomst, nooit de bouwtaak; iedere handtekening staat in een eigen transparantielogboek op het vlootcluster. Tot groeipadstap 2 met een bouwsleutel, daarna zonder langlevende sleutel.
Selectie en aansluiten van clusters
Kenmerken, clustersets en plaatsingen bepalen waar inrichting en beleid terechtkomen. Clusters komen onder beheer via de registratie; gehoste clusters worden automatisch geïmporteerd.
Wat de samenhang oplevert
Het aanbod is gericht op gedeelde behoeften van teams; de winst zit in de samenhang tussen de voorzieningen, van minder overdrachten tot gezamenlijk onderhoud.
Beleid en uitrolgolven
Beleid gaat eerst op melden en pas na een geslaagde proef per golf op afdwingen. Iedere wijziging en platformversie begint in de leeromgeving en de proefgroep en bereikt cel 1 vóór cel 2.
De standaardinrichting
Het beleid dat het vlootbeheer op ieder applicatiecluster afdwingt en dat een team niet kan wijzigen: beleidspakketten, teamnaamruimten, beveiliging van werklasten, naleving en bewaking.
Detectie van beveiligingssignalen
De SIEM van het SOC en Advanced Cluster Security herkennen misbruik met dertien detectieregels, elk met een drempel, een reactietermijn en een draaiboek. Iedere regel wordt beproefd, gemeten en bijgesteld, en een persoon beoordeelt daarnaast wekelijks wat buiten de regels valt.
Dienstverlening
Eén dienstbeschrijving stuurt levering en beheer over de hele levensduur van een dienst; een team combineert uit het aanbod wat het nodig heeft en kiest een dienstprofiel voor gebruik en continuïteit.
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.
Rollen, toegang en inloggegevens
Toepassingen, taken en personen krijgen tijdelijke inloggegevens op een eigen rol uit het geheimenbeheer. Vaste rollen bezitten de objecten, niemand werkt als postgres, en een verlopen of ingetrokken rol raakt ook lopende sessies.
Toelating op cluster en knooppunt
Op een cluster start alleen vrijgegeven software met een geldige handtekening. Twee afzonderlijke controlepunten, de toelatingscontrole en het knooppunt, toetsen die handtekening tegen een vertrouwensbasis die het cluster al heeft, ook zonder verbinding met het vlootcluster.
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.
Incidentrespons en meldplicht
Bij een beveiligingsincident leidt het SOC detectie en analyse, coördineert de incidentmanager en voert platformbeheer de maatregelen uit, volgens een draaiboek per incidenttype. Een significant incident wordt langs één route gemeld, binnen de termijnen van de Cyberbeveiligingswet.
Kwetsbaarheden, licenties en herleidbaarheid
Software wordt vóór de vrijgave en tijdens gebruik gescand, en onderdelenlijsten koppelen een nieuwe kwetsbaarheid aan de software die werkelijk draait. Kwetsbaarheden worden binnen vaste termijnen opgelost, en alleen toegestane licenties komen door.
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.
Toegang, identiteit en geheimen
Wie zich op een applicatiecluster aanmeldt en met welke rechten, hoe toepassingen worden uitgerold, en hoe toepassingen en besturingen aan identiteit, geheimen en certificaten komen.
Fysieke basis
Geregistreerde apparatuur op een vaste basislijn, gescheiden netwerken en één gecontroleerde route voor software, vastgelegd vóór de installatie van software, met de maatregelen voor apparatuur, fysieke toegang en tijd.
Inventaris en cryptografieoverzicht
De inventaris combineert de bestaande registraties tot één overzicht per dienst, met eigenaar, versies en einddatums, zodat iedere melding herleidbaar is tot dienst en eigenaar. Het cryptografieoverzicht legt per dienst en per pad vast welke cryptografie wordt gebruikt.
Leveranciers, ontwikkelteam en ketenproducten
De producten van de keten blijven binnen hun ondersteuning en gaan in een vaste volgorde over, met voorwaarden bij de acceptatie. Voor het ontwikkelteam en voor leveranciers gelden aanvullende beveiligingsmaatregelen.
Sleutels, toegang en taken
Hoe herstelkopieën versleuteld zijn en hun sleutels ook zonder de cel bruikbaar blijven, wie welke toegang heeft tot back-ups en herstel, en hoe de taken tussen platformbeheer, back-upbeheer, opslagbeheer, netwerkbeheer en het SOC zijn verdeeld.
Versies, onderhoud en levenscyclus
Welke versies de dienst gebruikt, hoe nieuwe versies via de toelatingsroute en uitrolgolven binnenkomen, hoe een nieuwe hoofdversie overgaat, en wat er gebeurt als de leverancier de stapel niet ondersteunt.
Wijzigen, bijwerken en beëindigen
Een wijziging is een nieuwe levering langs hetzelfde pad, en bijwerken levert een nieuwe versie in versiebeheer op die gespreid wordt uitgerold: eerst de proefgroep, dan in golven. Beëindigen loopt via de toestand in de dienstbeschrijving.
Wijziging, versies en draaiboeken
Hoe het basisdienstencluster en zijn basisdiensten alleen via code en beoordeelde wijzigingen veranderen, welke productversies gelden, in welke volgorde nieuwe versies uitrollen en welke draaiboeken beproefd moeten zijn.
Beproeving en continuïteitsplan
Een back-up telt pas na een geslaagd herstel. Herstel wordt volgens een vaste kalender beproefd en gemeten tot de afnemer weer kan werken, en het continuïteitsplan legt per onderdeel de herstelbron, de afhankelijkheden en de gemeten hersteltijd vast.
Bewaking, logboeken en beproeving
Wat van iedere database wordt gemeten en gemeld, welke gebeurtenissen naar het SOC gaan, hoe de database in de inventaris staat, en wat vóór productie en vrijgave aantoonbaar moet zijn.
Bewaking, logging en naleving
Welke meetwaarden en drempels voor het basisdienstencluster gelden, welke logboeken naar het SOC gaan, en hoe het cluster aan de basislijn, de inventaris en de firmwarebasislijn wordt getoetst en versleutelt.
Toezicht, taakverdeling en beproeving
Wie in identiteit en toegang welke taak heeft, welke gebeurtenissen naar het SOC gaan en welke drempels gelden, hoe de geheimen en verbindingen van de voorzieningen zijn beschermd, en wat per fase beproefd moet zijn.
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.
Beproeving en oplevering
Hoe de eerste levering wordt geaccepteerd en aan platformbeheer overgedragen, met welke maatstaven de voortgang wordt gevolgd en hoe de aandachtspunten voor de uitbreiding worden beheerst.