Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De eerste levering is pas af als zij aantoonbaar werkt en RWS haar zelf kan beheren. Dit onderwerp legt vast hoe de levering wordt geaccepteerd, hoe het beheer van het ontwikkelteam overgaat naar platformbeheer, met welke maatstaven de voortgang wordt gevolgd en hoe de aandachtspunten voor de uitbreiding worden beheerst.
Een aanwezige instelling bewijst niet dat een dienst werkt. Daarom accepteert RWS de eerste levering op proeven langs het werkelijke gebruikerspad, met vastgelegd bewijs en een eigenaar per bevinding, en telt een proef die haar slaagcriterium niet haalt niet als geslaagd. De overdracht is pas af als de beheerders de belangrijkste handelingen zelf hebben uitgevoerd; zo hangt RWS na de nazorg niet meer af van enkele specialisten in het ontwikkelteam.
De acceptatie- en overdrachtsgrens en de maatstaven zijn vastgesteld. De proeven, de controlelijst, de duur van de nazorg, de voorwaarden voor reguliere productie en de definities en streefwaarden van de maatstaven zijn een voorstel: zij maken de grens toetsbaar en blijven staan tot een architect erover besluit.
De eerste levering wordt voor het profiel ontwikkelen en beproeven geaccepteerd op grond van acceptatieproeven; voor reguliere en bedrijfskritische productie gelden eigen proeven en de voorwaarden voor vrijgave. De proeven gebruiken de testtoepassing van het eerste applicatieteam en volgen het werkelijke gebruikerspad: zij tonen de werking voor die toepassing, niet voor iedere variant.
Zie vrijgave voor productie en de proef langs het gebruikerspad.
De eerste levering is geaccepteerd wanneer iedere acceptatieproef als geslaagd of als geslaagd met bevindingen is beoordeeld, het bewijs is vastgelegd en iedere bevinding een eigenaar en een termijn heeft. Een bevinding met hoog risico mag alleen openstaan als de bevoegde verantwoordelijke haar als uitzondering met einddatum heeft goedgekeurd. Een proef die haar slaagcriterium niet haalt, is niet geslaagd, ook niet ‘met bevindingen’. De productverantwoordelijke beslist over de acceptatie.
Bij de acceptatie horen ook de dienstafspraken voor de geërfde maatregelen. Als diensteigenaar van het platform tekent de productverantwoordelijke ook voor de vrijgave naar reguliere en bedrijfskritische productie; zie vrijgave en restrisico.
Veertien acceptatieproeven tonen aan dat de eerste levering werkt, van de aanvraag tot de beëindiging, en dat beveiliging, herstel en bewijs zijn ingericht.
| Proef | Proef en handelingen | Verwachte uitkomst en bewijs |
|---|---|---|
| Levering | Het team vraagt via het portaal een applicatiecluster aan in het profiel ontwikkelen en beproeven, met een database en een koppeling. | Opgeleverd via het vaste pad, zonder handmatige stap; de levertijd is afgezet tegen de nulmeting. |
| Onvolledige levering | De databasestap wordt bewust verhinderd. | Status ‘Onvolledig’, met de mislukte stap en de verantwoordelijke; na herstel hervat beheer de levering zonder dubbele onderdelen. |
| Afgewezen aanvraag | Aanvragen met een niet-vrijgegeven versie, met een niet-toegestane zone en met beide. | Iedere aanvraag is met uitleg afgewezen en er is nergens iets aangemaakt. |
| Toegang en koppeling | De toepassing leest brongegevens en probeert te schrijven en een niet-gedeclareerde verbinding te maken. | Lezen slaagt; schrijven wordt geweigerd; de verbinding wordt geweigerd en gemeld; het bewijs toont per weigering welke controle ingreep. |
| Wijziging | Het team vraagt via een wijzigingsvoorstel meer capaciteit aan. | Uitgevoerd zonder nieuwe aanvraag per beheerdomein; de toepassing blijft beschikbaar, gemeten op het gebruikerspad. |
| Update | Een platformupdate gaat eerst naar de proefgroep en daarna gespreid naar de overige clusters, met een nagebootste fout bij één cluster. | De uitrol stopt bij het cluster met de fout en het herstelpad werkt; de overige clusters volgen alleen als de fout aantoonbaar bij dat cluster ligt. |
| Herstel van de database | Herstel naar een gekozen tijdstip, in een afgeschermde kopie. | De eigenaar controleert de gegevens; hersteltijd en gegevensverlies zijn vastgelegd en afgezet tegen het dienstprofiel; de productiedatabase blijft ongewijzigd. |
| Herbouw van een cluster | Het applicatiecluster wordt verwijderd en uit code en back-up opnieuw opgebouwd. | Toepassing en gegevens werken weer; de duur is vastgelegd en afgezet tegen het dienstprofiel. |
| Softwareketen | Starten van niet-ondertekende software, van software uit een andere containerregistry en van een containerbeeld van derden vóór en na toelating. | Geweigerd bij de toelatingscontrole en, in een afzonderlijke proef, bij het ophalen door het knooppunt, met een melding bij het SOC; het toegelaten beeld van derden start wel. |
| Detectie en respons | Gesimuleerd misbruik: gebruik van een noodaccount, een interactieve opdrachtregel in een container en verboden uitgaand verkeer. | Het SOC ziet de meldingen binnen de reactietijd en volgt het draaiboek; de vroegtijdige waarschuwing via de meldroute is geoefend, met de tijd gemeten vanaf de kennisname. |
| Geheimen en certificaten | Inloggegevens en certificaten worden tijdens gebruik vervangen. | Geen onderbreking bij koppelingen die twee geldige waarden tegelijk of herladen zonder herstart ondersteunen, bij andere een onderbreking binnen de goedgekeurde uitzondering; de oude inloggegevens werken niet meer. |
| Herstel na een aanval | Gijzelsoftware wordt gesimuleerd op het cluster van de testtoepassing. | Herstel slaagt uit de onveranderbare kopie in de herstelomgeving, met gemeten hersteltijd en gegevensverlies; platformbeheer kan de kopie niet wijzigen. Herstel zonder gezonde cel wordt apart beproefd in groeipadstap 2. |
| Beëindiging | Het team beëindigt de dienst. | Verbindingen, identiteiten en rechten zijn verwijderd; gegevens en back-ups volgen hun bewaartermijn. |
| Bewijs en naleving | Het bewijsdossier per maatregel van de baseline en het nalevingsoverzicht worden getoetst aan de baseline en de referentieset; het dreigingsmodel is beoordeeld. | Per maatregel is er bewijs of een goedgekeurde uitzondering met einddatum; per eis uit de referentieset zijn ontwerp, leverfase, bewijs en een eventuele uitzondering vastgelegd; er is geen open afwijking met hoog risico zonder besluit van de bevoegde verantwoordelijke. |
Een proef dekt een toets meestal maar deels; de volledige toets wordt afzonderlijk uitgevoerd.
Iedere acceptatieproef heeft een eigenaar, een bewaard resultaat en een vast script met versie, uitgangssituatie, handelingen, verwachte uitkomst en slaagcriterium; de scripts toetsen aan de getalsmatige normen. Bij iedere proef is een waarnemer van platformbeheer aanwezig. De proeven voor de softwareketen, voor detectie en respons en voor herstel na een aanval worden samen met het SOC uitgevoerd, de proef voor bewijs en naleving met de beveiligingsadviseur.
Bij iedere getalsmatige norm staan het scenario, de klok en de meetmethode bij de beproeving die haar meet. Een norm die rechtstreeks uit een SAK of een wet volgt, noemt die bron, en een gemeten afwijking van een norm wordt in de jaarlijkse herziening verwerkt.
Eigenaar van de normen zijn de diensteigenaren en de CISO-functie. Zie herziening van de baseline.
Voor de vrijgave naar reguliere productie moeten de beheerafspraken zijn vastgesteld, moet het SOC de detectie en de bewaartermijnen hebben bevestigd en moeten de getalsmatige normen zijn gemeten. De uitzondering voor de centrale logopslag moet zijn gesloten, want de eigen vergrendelde logopslag is een voorwaarde voor reguliere productie; de uitzondering voor onversleutelde verkeersstromen is gesloten of met een nieuwe einddatum opnieuw geaccepteerd.
De hoofdlijn staat bij vrijgave voor productie. Eigenaar zijn de diensteigenaar en de CISO-functie. Omdat de vergrendelde logopslag met de eigen bewakingsvoorziening in groeipadstap 2 komt, blijft de dienst tot dan in het profiel ontwikkelen en beproeven. Voor bedrijfskritische productie worden bij de beproefde overname en terugkeer het herstelpunt en de hersteltijd gemeten tegen de bedrijfsimpactanalyse, ook bij uitwijk zonder gezonde cel; daar zijn de diensteigenaar en de proceseigenaar eigenaar.
De overdracht omvat de opslagplaatsen van het platform, niet die van de applicatieteams: de rol van eigenaar en beoordelaar gaat van het ontwikkelteam naar platformbeheer. Platformbeheer loopt vanaf het begin van de bouw mee, en de primaire en de plaatsvervangende beheerders voeren de draaiboeken vóór de overdracht zelf uit.
Zie de opslagplaatsen van het platform en geen blijvende beheerrechten voor het ontwikkelteam.
De overdracht aan platformbeheer is afgerond als de primaire en de plaatsvervangende beheerders zelfstandig een cluster hebben geleverd, een update en een herstel hebben uitgevoerd en een beveiligingsmelding hebben afgehandeld, volgens de draaiboeken en met vastgelegd bewijs.
Het ontwikkelteam draagt elf onderdelen over aan platformbeheer, elk met het bewijs dat de overdracht is gelukt.
| Onderdeel | Wat wordt overgedragen | Aangetoond door |
|---|---|---|
| Code en opslagplaatsen | De opslagplaatsen van het platform, niet die van de applicatieteams; de rol van eigenaar en beoordelaar gaat van het ontwikkelteam naar platformbeheer. | Rechten en regels in het versiebeheer |
| Draaiboeken | Voor installatie, update, herstel, veelvoorkomende storingen en incidentrespons. | Zelfstandig uitgevoerd door de primaire en plaatsvervangende beheerders, ook de stappen bij een afwijking |
| Ontwerpbesluiten | Een register met alle besluiten en afwijkingen van de standaard. | Beoordeling door de architect |
| Bewijs | Acceptatieproeven, herstelproeven en bewijs per maatregel van de baseline; per eis van de referentieset het bewijs of een goedgekeurde uitzondering. | Een volledig dossier, ook met de niet-geslaagde en niet-beproefde onderdelen |
| Beveiligingsdocumentatie | Het dreigingsmodel per platformcluster en per dienst, het continuïteitsplan en de vastgestelde beveiligingsarchitectuur. | Vaststelling door de CISO-functie |
| Bekende tekortkomingen | Een lijst met per tekortkoming eigenaar, termijn en risico. | De productverantwoordelijke; de CISO-functie tekent mee voor het restrisico |
| Uitzonderingen | Het register met per uitzondering de compenserende maatregelen, de einddatum en het goedkeuringsbesluit. | Een besluit van de bevoegde verantwoordelijke per uitzondering |
| Leverancierscontracten en ondersteuning | Ondersteuningsaccounts, contracten en escalatieroutes. | Platformbeheer heeft eigen toegang |
| Sleutels en noodaccounts | Nieuwe houders uit RWS voor de herstelsleutels; nieuwe wachtwoorden voor de noodaccounts. | Het verslag van de sleutelceremonie en een geslaagde herstelproef met de nieuwe sleutels |
| Kennis | Training, meelopen en zelfstandig uitgevoerde handelingen. | De vier handelingen zelfstandig uitgevoerd |
| Rechten van het ontwikkelteam | Intrekking na de nazorgperiode. | Geen rechten uit de ontwikkelrol meer, ook niet op de doelsystemen |
Na de overdracht volgt een nazorgperiode van drie maanden. Platformbeheer krijgt verse rechten, en na de nazorgperiode worden de rechten uit de ontwikkelrol ingetrokken, met controle op de doelsystemen.
Daarna heeft het ontwikkelteam geen rechten uit de ontwikkelrol meer, ook niet op de doelsystemen; de controlelijst voor de overdracht toont dat aan.
De voortgang wordt vanaf de eerste levering gevolgd met twaalf maatstaven: voor de levering levertijd, wachttijd, handmatige stappen en softwarelevering; voor de continuïteit herstel; voor de beheersing kwetsbaarheden, naleving, verhoogde rechten, softwareketen en detectie en melding; en voor gebruik en kosten het gebruik en de afbouw en kosten. De voortgangsrapportage aan het bestuur zet de gemeten waarde naast de beoogde richting en meet naast de techniek ook wat afnemers in hun werk merken.
De maatstaven maken de opbrengst van de invoering meetbaar. De levertijd wordt vergeleken met de nulmeting, en de softwarelevering wordt gemeten met de DORA-maatstaven.
Iedere maatstaf voor de voortgang heeft een definitie, een bron en een beoogde richting.
| Maatstaf | Definitie en meting | Bron | Richting |
|---|---|---|---|
| Levertijd | Tijd per levering van de status ‘Ingediend’ tot ‘Opgeleverd’, ook voor onvolledig gebleven leveringen; mediaan en 90e percentiel per maand, vergeleken met de nulmeting. | Leverstatus | Korter dan de nulmeting |
| Wachttijd | Het deel van de levertijd waarin een levering op een persoon wacht, apart van wachten op een systeem. | Leverstatus | Dalend |
| Handmatige stappen | Aantal handelingen door een persoon per levering, inclusief het herstel van onvolledige leveringen. | Leverstatus en draaiboeken | Dalend; voor standaardvarianten naar nul |
| Softwarelevering | Vijf gangbare maatstaven per toepassing of dienst: doorlooptijd van een wijziging, uitrolfrequentie, aandeel mislukte uitrollen, hersteltijd na een mislukte uitrol en aandeel ongeplande hersteluitrollen. | Pijplijnen en uitrol | Verbeterend per kwartaal |
| Herstel | Behaalde hersteltijd en gegevensverlies per herstelproef, afgezet tegen de afspraak van het dienstprofiel. | Herstelproeven | Binnen de afspraak |
| Kwetsbaarheden | Doorlooptijd per ernstklasse en het aandeel dat binnen de termijn is opgelost. | Beveiligingsbewaking | Ten minste 95 procent binnen de termijn; iedere overschrijding met een goedgekeurde uitzondering; een kritieke overschrijding afzonderlijk gemeld |
| Naleving | Aandeel clusters zonder open afwijking met hoog risico, met niet-gecontroleerde clusters als onbekend; aantal open uitzonderingen en hun leeftijd. | Compliancecontrole en uitzonderingsregister | Alle clusters; aantal uitzonderingen dalend |
| Verhoogde rechten | Aantal verhogingen per team en per maand, gesplitst naar eigen dienst en platformbreed; wachttijd tot goedkeuring; aandeel zonder verwijzing naar een incident of wijziging. | Identiteitsbeheer en audit | Dalend na de eerste maanden; wachttijd binnen 15 minuten; geen verhoging zonder verwijzing |
| Softwareketen | Aandeel van de draaiende software dat is ondertekend en een herkomstverklaring heeft, gemeten tegen de inventaris; uitzonderingen en onbekende software apart vermeld. | Toelatingscontrole en inventaris | Volledig |
| Detectie en melding | Tijd tot detectie, tot kennisname en tot de verzonden vroegtijdige waarschuwing, gemeten in oefeningen. | Oefeningen van het SOC | Binnen de reactietijd; waarschuwing binnen 24 uur na kennisname |
| Gebruik | Aantal teams en diensten, tevredenheid per kwartaal en terugkerende knelpunten. | Portaal en enquête | Groeiend; knelpunten op de verbeterplanning |
| Afbouw en kosten | Afgesloten oude voorzieningen volgens de afbouwlijst; resterend dubbel beheer; kosten per dienst naast de totale kosten. | Inventaris en kostenbeheer | Dubbel beheer met einddatum |
Vóór de eerste voortgangsrapportage legt de eigenaar per maatstaf de periode, de noemer en de behandeling van mislukte en ontbrekende metingen vast, zodat de meting herhaalbaar is, ongeacht wie rapporteert.
Ieder aandachtspunt dat het tempo van uitbreiding mede bepaalt, heeft een eigen beheersing; de voortgangsrapportage volgt de aandachtspunten naast de maatstaven.
| Aandachtspunt | Waarom het aandacht vraagt | Beheersing |
|---|---|---|
| Gezamenlijke uitval | Gedeelde voorzieningen vergroten de gevolgen van één fout of aanval. | Beheercellen, gespreid onderhoud en beproeving van uitval en aanval in groeipadstap 2; aparte maatregelen en een aparte beproeving voor vlootbrede rollen en gedeelde voorzieningen. |
| Tijdelijk dubbel beheer | Oude en nieuwe voorzieningen naast elkaar kosten extra en dreigen blijvend te worden. | Afbouw in dezelfde planning als de overgang; eigenaar en einddatum per tijdelijke voorziening; ieder af te bouwen product met zijn opvolger. |
| Externe afhankelijkheid bij SaaS | Beveiliging, continuïteit en vertrek liggen deels buiten RWS. | Een exitplan met twee scenario’s en sleutelbeheer in eigen hand; gegevensoverdracht en sleutelvrijgave aangetoond voordat RWS afhankelijk wordt. |
| Beveiligingsachterstand | Uitzonderingen en uitgestelde updates stapelen zich ongemerkt op. | Eigenaar en einddatum per uitzondering; zonder verlenging geldt de afwijking daarna weer als open; rapportage aan het bestuur. |
| Kennis en capaciteit | Het platform is nieuw, en RWS hangt af van enkele specialisten in het ontwikkelteam. | Meelopen van beheer, draaiboeken, opleiding en kennisoverdracht als voorwaarde voor de overdracht, ook voor de plaatsvervangende beheerders. |
| Randvoorwaarden van RWS-teams | Netwerkbeheer levert het nieuwe datacenternetwerk en opslagbeheer het opslagcluster, buiten de opdracht van het ontwikkelteam. Loopt een van beide uit, dan schuiven de eerste levering en de tweede beheercel op. | Een routekaart van het netwerk met een go/no-go per fase en de testset als bewijs; de bewijsset van het opslagcluster; vaste afstemming in de planning. |
De aandachtspunten zelf staan bij het tempo van uitbreiding. Voor SaaS op een publieke cloud geldt daarnaast het Rijkscloudbeleid voor SaaS, met het exitplan; de toetsen SaaS aansluiten en kunnen beëindigen en Gevoelige verwerking en sleutelvrijgave tonen gegevensoverdracht en sleutelvrijgave aan.
Functies die een product tot nu toe maar deels invulde, zijn toegewezen aan een product of voorziening en aan het moment waarop zij beschikbaar komen.
| Functie | Invulling | Wanneer |
|---|---|---|
| Handhaving van bevoorrechte sessies | De beheerwerkplek, samen met het identiteitsbeheer | Groeipadstap 1 |
| Toegang tot taalmodellen | De LLM-gateway; vanaf groeipadstap 4 ook via de applicatie-ingang | Groeipadstap 3 |
| Werkstroommotor achter werkstromen als dienst | OpenShift Serverless Logic met PostgreSQL | Groeipadstap 4 |
| API-beheer | Een API-gateway achter de ingang van het cluster, de applicatie-ingang | Groeipadstap 4 |
| Dienstbrede overname | De automatisering, met een draaiboek per dienst | Bij de overname van bedrijfskritische diensten tussen de cellen |
De kostentoerekening door het kostenbeheer volgt in groeipadstap 3; zie kosten en capaciteit zichtbaar. Datacatalogus en herkomst van gegevens zijn geërfd van de metadatavoorziening van het RWS-datastelsel; zie betekenis en herkomst.