Besluit 16 · architectuur

Veertien domeinen met hun ontwerp op hoofdlijnen

Het platform is ingedeeld in veertien domeinen met een eigenaar; per domein liggen op hoofdlijnen vast wat het doet, zijn grens, zijn onderdelen met hun producten, hun samenhang, de doelen en de belanghebbenden.

Aanvaard28 september 2026Besloten door vdo89

Uitspraken die op dit besluit wachten

Uitspraak	Onderwerp	Nu
Basisdiensten die hun gegevens zelf repliceren, zoals het geheimenbeheer, en de databases van de basisdiensten gebruiken lokale opslag op de eigen servers, niet het opslagcluste…	Startketen, opslag en herstel	Vastgesteld
Het eindbeeld is een eigen bewakingsvoorziening buiten de platformclusters, met eigen servers, eigen opslag en eigen toegang. Daar ko…	De eigen bewakingsvoorziening	Vastgesteld
Met de cel deelt de eigen bewakingsvoorziening alleen netwerk, stroom, naam- en tijdvoorziening en de voeding van haar accounts. Van de platformclusters van de cel en van het vl…	De eigen bewakingsvoorziening	Vastgesteld
De inventaris combineert de bestaande registraties, die ieder voor hun deel de bron zijn: NetBox voor apparatuur, netwerken en adressen, de zoekfunctie van het vlootbeheer (Red …	Inventaris en cryptografieoverzicht	Vastgesteld
Audit- en beveiligingslogboeken gaan van ieder cluster via de logverzamelaar van OpenShift Logging rechtstreeks naar de [SIEM van het SOC](/bouwstenen/producten/siem-van-het-soc…	Logboeken en de koppeling met het SOC	Vastgesteld
Ieder OpenShift-cluster bewaakt zichzelf met zijn ingebouwde bewaking, Prometheus en Alertmanager, en meldt rechtstreeks aan de afgesproken meldingsroutes. Een melding hangt nie…	Signalering en meldingen	Vastgesteld
De eerste levering werkt met wat het platform al heeft: de bewaking per cluster en de samengevatte metingen in het vlootbeheer, dat de observability al in huis heeft. Er wordt n…	Het vlootoverzicht	Vastgesteld
De configuratiedatabase (etcd) van iedere gehoste besturing staat op lokale volumes van het clusterbeheer, met LVM Storage, en nooit op h…	Het clusterbeheer	Vastgesteld
Een applicatieteam neemt zijn cluster af als dienst: een applicatiecluster ontstaat, wijzigt en verdwijnt alleen via de dienstbeschrijving va…	De clusterdefinitie	Vastgesteld
De standaardinrichting geldt voor ieder applicatiecluster en is beleid van het vlootbeheer, geen instelling per…	De standaardinrichting	Vastgesteld
Geheimen van een gehost cluster komen uit het geheimenbeheer van de cel; de clusterdefinitie bevat alleen verwijzingen.	Toegang, identiteit en geheimen	Vastgesteld
De wortel van de PKI is de bestaande interne RWS-PKI. Iedere cel heeft een eigen tussen-CA, uitgegeven door PKI-beheer, met naambeperking tot de domeinen van die cel; haar sleut…	Certificaten en PKI	Vastgesteld
Alle geheimen (wachtwoorden, sleutels, tokens, certificaten) komen uit het geheimenbeheer van de cel. Geen geheim staat in code, containerbeelden, tickets, chat, e-mail of docum…	Geheimenbeheer	Vastgesteld
Het geheimenbeheer draait op lokale volumes en niet op het opslagcluster, zodat het bruikbaar blijft tijdens herstel van het opslagcluster. Gevolg: geen live-migratie.	Geheimenbeheer	Vastgesteld
De back-up wordt per laag gemaakt, zodat ieder onderdeel consistent te herstellen is: clusterobjecten, volumes en virtuele machines met OpenShift API for Data Protection (OADP);…	Back-up per laag	Vastgesteld
Een back-up telt pas na een geslaagd herstel. Iedere herstelproef meet de hersteltijd, met de opbouw van de herstelomgeving en het ophalen van de kopie, en het gegevensverlies, …	Beproeving en continuïteitsplan	Vastgesteld
Cohesity haalt de back-ups zelf op uit de objectopslag van de cel, met een identiteit die daar alleen mag lezen. Lukt dat niet, dan schrijft een kopieertaak met alleen toevoegre…	Beschermingslagen en de onveranderbare kopie	Vastgesteld
Geen platform- of opslagaccount heeft rechten op het beschermingsbeleid, de bewaartermijnen of de kopieën op Cohesity. De cel leest alleen, behalve de kopieertaak, die alleen ma…	Beschermingslagen en de onveranderbare kopie	Vastgesteld
Een kopie van buiten de cel en ieder herstel na een aanval gaan eerst door de controle in de herstelomgeving; pas na een geslaagde controle wordt productie hersteld. Software ko…	De herstelomgeving	Vastgesteld
Beheertoegang loopt alleen via de beheerwerkplek. Iedere bevoorrechte sessie, ook via opdrachtregel, API, exec en poortdoorschakeling, gaat via d…	De beheerwerkplek	Vastgesteld
Bevoorrechte rechten zijn taakgebonden en tijdelijk. De aanvrager keurt nooit zelf goed, in productie bestaat geen zelfactivering, en personen hebben geen blijvende beheerrechte…	Verhoging en intrekking	Vastgesteld
Een team kan zijn dienstbeschrijving ook rechtstreeks in het versiebeheer als wijzigingsvoorstel indienen, als terugval bij uitval van het portaal of om zijn levering vanuit sof…	Beoordelen en samenvoegen in versiebeheer	Vastgesteld
Het portaal dient de dienstbeschrijving in als wijzigingsvoorstel en toont de voortgang, maar voert zelf niets uit: zijn technische identiteit kan alleen voorstellen doen, niet …	Het portaal en de ontwikkelomgeving	Vastgesteld
Van buiten het datacenter zijn toepassingen en API’s alleen bereikbaar via een virtueel adres van de externe verkeersverdeling, die het verkeer doorgeeft aan de ingang van het c…	Publicatie, namen en TLS	Vastgesteld
De externe verkeersverdeling werkt op laag 4: zij geeft TCP door zonder TLS af te sluiten, heeft geen dienstcertificaten en kiest niet op hostnaam. TLS eindigt bij de API-server…	Publicatie, namen en TLS	Vastgesteld
Software komt langs drie routes binnen: eigen software via de bouwpijplijn op het bouwcluster, software van derden die RWS niet zelf herbouwt via de…	Aanvoerroutes, quarantaine en vrijgave	Vastgesteld
Uit de quarantaine wordt niets uitgerold. Een team schrijft alleen in zijn eigen quarantaineruimte. Alleen identiteiten van het platform, buiten de naamruimten van teams, tekene…	Aanvoerroutes, quarantaine en vrijgave	Vastgesteld
Van ontwikkelen tot productie wordt steeds hetzelfde inhoudskenmerk vrijgegeven, niet een versielabel dat kan verand…	Aanvoerroutes, quarantaine en vrijgave	Vastgesteld
Alle eigen software, van teams en van het platform, wordt gebouwd op één apart gehost applicatiecluster van het platform: het bouwcluster, gescheide…	Bouwen op het bouwcluster	Vastgesteld
Eigen software wordt alleen op het bouwcluster gebouwd, met een gepubliceerde versie van het pijplijnsjabloon, en nooit op een werkplek. Sjabloon, bouwomgeving en ondertekenaar …	Bouwen op het bouwcluster	Vastgesteld
Iedere draaiende versie is via haar inhoudskenmerk herleidbaar naar haar onderdelenlijst en herkomst. Software die niet herleidbaar is, wordt gemeld.	Kwetsbaarheden, licenties en herleidbaarheid	Vastgesteld
Het platform verklaart de herkomst, niet de bouwtaak: een onafhankelijke besturing van het platform ondertekent resultaat, onderdelenlijst en herkomstverklaring. Geen bouwtaak o…	Ondertekening en herkomst	Vastgesteld
Iedere vrijgegeven versie van eigen software en van software van derden heeft een handtekening, een onderdelenlijst en een herkomstverklaring of toelatingsattest, en die zijn vó…	Ondertekening en herkomst	Vastgesteld
Op een cluster start alleen software uit de ruimtes vrijgegeven, derden of spiegel van de containerregistry van de eigen cel, met een geldige handtekening van het platform of, v…	Toelating op cluster en knooppunt	Vastgesteld
Twee onafhankelijke controlepunten toetsen ieder voor zich de handtekening: de toelatingscontrole bij de toelating tot het cluster, met de Policy Controller van Trusted Artifact…	Toelating op cluster en knooppunt	Vastgesteld
De virtuele schijven van werkers en virtuele servers staan op gedeelde blokopslag van het opslagcluster van de cel, via Data Foundation in externe modus: blokopslag met gedeelde…	Live-migratie en onderhoud	Vastgesteld

Context en probleemstelling

Een architect moet per gebied kunnen zien hoe het in elkaar zit en wie er verantwoordelijk voor is, voordat de uitwerking aan bod komt. De hoofdlijnen per gebied moeten daarom vastliggen, los van de details.

Besluit

Het platform is ingedeeld in veertien domeinen: dienstverlening en portaal, beheercellen, vlootbeheer, clusterbeheer, werkervirtualisatie, basisdiensten, identiteit en beheertoegang, geheimen en certificaten, beheerde databases, softwarelevering, bewaking, herstel, netwerk en opslag. Het kaderdomein strategie en aanbod staat erboven.

Per domein liggen op hoofdlijnen vast: wat het doet en zijn grens, de stelling, de onderdelen met de producten die ze invullen, hun samenhang, de doelen, de belanghebbenden en de samenhang met andere domeinen. Een uitspraak in de uitwerking die alleen zo’n hoofdlijn herhaalt of scherper maakt zonder concrete waarden, rust ook op dit besluit.

Gevolgen

Iedere domein heeft een eigenaar die de kennis inhoudelijk bewaakt.
De uitwerking per domein staat in zijn onderwerpen en is een voorstel (ADR-0017), behalve de opslag (ADR-0015).

Verwijzen hiernaar

Onderwerpen 27

Domeinen 13