Keur elke wijziging goed voor de exacte revisie, en bewaar de vastlegging van wat er draaide.

Een klant of auditor neemt één wijziging als steekproef en vraagt wie haar goedkeurde, en wat precies. Een wijziging is een plan, en een plan is een geordende lijst van stappen tegen genoemde hosts. Het wordt per host vooraf getoond, goedgekeurd voor één revisie en uitgevoerd, en niets kan er tussendoor worden bewerkt zonder dat de goedkeuring vervalt. CyFun vraagt dat wijzigingen worden getest en gevalideerd voordat ze in operationele systemen terechtkomen (PR.PS-06.2).

Goedgekeurd voor één revisie

De goedkeuring geldt voor de revisie die draait. Past u het plan aan, dan vervalt ze.

De goedkeurder moet toegang hebben tot de omgeving, en de omgeving komt uit de hosts waar het plan op mikt. Een run in een beschermde omgeving wacht tot die persoon beslist.

Fig. 1, het goedkeuringsverzoek voor revisie 7 in prod

Patch nginx across prod

Upgrade nginx to 1.25.3

blocked 2mweb-01, web-02, web-03console4 items

@alex → AIDry-run passedApproval requiredAudit

Revision: Covers revision 7 only.
Targets: web-01, web-02, web-03 in prod, derived from the targets
Approver: Must hold access to prod

Eerst vooraf getoond

Zie wat elke host gaat doen voordat iemand goedkeurt.

De proefrun verbindt met elk doel en meldt per host. De goedkeurder leest wat er op web-02 zou veranderen, en geen samenvatting van het plan.

Fig. 2, proefrun van #4f2a, revisie 7, op 3 hosts

Dry run #4f2a, revision 7

14:29:40Passed on 3 hosts

What the dry run found on each host
Host	Changes	Destructive	Time
web-01	4	0	810 ms
web-02, diff shown	4	0	790 ms
web-03	4	0	840 ms
Total	12	0
Since the last run	+2	0
ssl_session_tickets added

Diffweb-02

/etc/nginx/nginx.conf+3/−2

 --- a/etc/nginx/nginx.conf
 +++ b/etc/nginx/nginx.conf
 @@ -1,7 +1,7 @@
  user  www-data;
−worker_processes  4;
+worker_processes  auto;
  pid /run/nginx.pid;
 @@ -31,6 +31,7 @@
      ssl_prefer_server_ciphers on;
−    ssl_protocols TLSv1.2;
+    ssl_protocols TLSv1.3;
+    ssl_session_tickets off;

De vastlegging van de wijziging

De keten van verzoek tot uitkomst, bewaard voor de auditor die een steekproef neemt.

De vastlegging bewaart wie het vroeg, wat het plan opstelde (het model wordt genoemd wanneer de AI-composer het deed), de proefrun, wie goedkeurde en wat er gebeurde. Het is de vierde vastlegging op de bewijspagina.

Fig. 3, vastlegging van de wijziging voor run #4f2a, revisie 7 (de diff staat bij de proefrun)

Change record /Patch nginx across prod, run #4f2a

Sample

@alex → AIDry-run passedApproved by @danaAudited · #4f2a

Origin: Drafted by the AI composer for @alex
Targets: web-01, web-02, web-03 in prod
Dry run: 3 hosts, 12 changes, 0 destructive
Approved: Dana Okafor at 14:32:07, for revision 7 only
Outcome: Completed on 3 hosts, 4 steps

De eis waarop dit antwoordtCyFun 2025, PR.PS-06.2 (2023: PR.IP-3.1)

Wijzigingen en uitzonderingen worden getest en gevalideerd voordat ze in operationele systemen terechtkomen.

De proefrun per host is die test vooraf. De goedkeuring, gebonden aan de revisie die draait, voegt Opafra daaraan toe. Punt 6.4.2 van Uitvoeringsverordening (EU) 2024/2690 vraagt gedocumenteerde, geteste en beoordeelde wijzigingen.

Catalogus van standaardwijzigingen

Keur een plan één keer goed, en draai het vaak als standaardwijziging.

Een routineklus heeft niet elke keer een nieuw goedkeuringsverzoek nodig. Keur het plan één keer goed, zet het als standaardwijziging in de catalogus en draai het wanneer de klus terugkomt. Elke run wordt nog steeds vastgelegd.

Eén keer goedgekeurd, voor één revisie: De goedkeuring geldt voor een exacte revisie, zoals bij elke wijziging. Past u het plan aan, dan verlaat het de catalogus tot het opnieuw is goedgekeurd.
Vaak gedraaid, elke run vastgelegd: Elke run van een standaardwijziging schrijft een eigen vastlegging: wie hem draaide, op welke hosts, welke goedgekeurde revisie draaide en wat er gebeurde.
Minder risico, en de historie laat het zien: Een wijziging die eerder onder een goedkeuring is gedraaid, heeft minder risico dan een nieuwe, en de eerdere runs staan in de vastlegging voor het overleg dat wijzigingen beoordeelt.

Noodprocedure

Ligt productie plat, draai dan nu. Keur het achteraf goed en beoordeel het.

Wachten op een goedkeurder is in een incident de verkeerde prijs. De noodprocedure laat iemand met toegang tot de omgeving het plan nu uitvoeren, en het wordt vastgelegd als noodwijziging, zodat er niets van verborgen blijft.

Nu draaien, met een reden: De persoon geeft aan waarom het niet kan wachten, de run start meteen, en het auditlog legt hem vast zoals elke run.
Onafhankelijke goedkeuring en beoordeling achteraf, binnen een vaste termijn: Een tweede persoon, niet degene die hem draaide, keurt de wijziging achteraf goed en beoordeelt haar, binnen de termijn die uw organisatie instelt, en de beoordeling wordt ondertekend vastgelegd.
Vastgelegd als noodwijziging: De vastlegging zegt dat het een noodwijziging was, wie hem draaide, wie hem achteraf beoordeelde en wanneer, zodat een steekproef van noodwijzigingen een lijst is en geen zoektocht.

Wijzigingen volgens schema

De wijzigingen die terugkomen hebben elke keer een vastlegging nodig.

Een run volgens schema gaat door dezelfde goedkeuringspoort als een handmatige.

Patchen, met de reden dat een server is overgeslagen: Een patchplan volgens schema toont per host een voorbeeld vooraf, draait na goedkeuring en vraagt een reden voor elke host die het weglaat. Per host leest de vastlegging gepatcht, of overgeslagen met de reden, met de run en de goedkeurder. Dit hoort bij sleutelmaatregel ID.RA-08.1 (een plan voor het beheer van kwetsbaarheden): de patchruns en hun termijnen zijn vastgelegd. Opafra scant niet op kwetsbaarheden, en het plan zelf is uw document.
Certificaatvernieuwing: Een plan volgens schema controleert de vervaldatum op elk domein, vernieuwt wat aan de beurt is, installeert het certificaat en laadt de service die het houdt opnieuw. Elke vernieuwing is een run: welke hosts, welk certificaat en het resultaat.
Configuratiewijzigingen: Bewerk een bestand of een template op veel servers tegelijk. Elke host toont zijn diff voordat er iets verandert, en elke revisie blijft bewaard.

CIS- en STIG-herstel

Herstel afwijkingen van CIS- en STIG-baselines, met de uitzonderingen vastgelegd.

Het herstel draait als plannen, dus elke oplossing wordt per host vooraf getoond, goedgekeurd voor haar revisie en vastgelegd zoals elke andere wijziging. Een maatregel die u niet herstelt is een uitzondering, en ook de uitzondering wordt vastgelegd.

Herstel als plannen: Schrijf de oplossing voor een maatregel als plan, toon haar vooraf op elke host, keur haar goed en draai haar. De run legt het resultaat per host vast. De benchmark zelf blijft van u.
Een vastgelegde uitzonderingenlijst: Elke uitzondering noemt de host en de maatregel, met de reden dat ze bleef staan en de persoon die goedkeurde dat ze bleef. De lijst is wat een beoordelaar naast de runs wil zien.

Beantwoord de vraag over wijzigingen met een vastlegging.

Vertel ons hoe wijzigingen nu bij uw servers komen en wie ze moet goedkeuren. U krijgt een demo en uw prijs schriftelijk binnen één werkdag, zonder gesprek.

Vraag een demo aan