Onveranderbare back-ups

NormenBIO2

Levert bewijs voorBIO8.28.13NIST CSFPR.AA-05PR.DS-11AVGA32WpgW06

Barriere: bescherm back-ups met onveranderbaarheid en gescheiden beheer. Back-ups staan buiten het bereik van een aanvaller, write-once, offline of in een apart vertrouwensdomein, zodat ze ransomware en sabotage overleven.

Back-ups staan in dezelfde vertrouwensgrens als productie. Een aanvaller met beheerrechten kan ze versleutelen of vernietigen, en doet dat ook, als eerste stap voor ransomware. Een back-up die in een aanval geraakt wordt, is geen back-up.

Wanneer wel, wanneer niet#

Altijd zinvol, voor elke organisatie waar dienstverlening afhangt van digitale data. Wanneer niet als losse stap: zonder geoefend herstel weet niemand of de back-up bruikbaar is wanneer je hem nodig hebt.

Zo richt je het in#

Back-ups worden geschreven naar opslag die geen wijziging of verwijdering toestaat gedurende de retentieperiode (immutable, write-once, object lock). Eén exemplaar staat in een ander vertrouwensdomein (offline, andere cloud, ander beheer). De back-up-keten heeft eigen credentials, niet die van productie.

1. Inventariseer welke data en configuratie kritiek is voor herstel (RPO per systeem).
2. Kies een back-upoplossing met immutability/object-lock op de doel-opslag.
3. Plaats minimaal één kopie in een ander vertrouwensdomein (offline of andere cloud).
4. Scheid back-up-credentials van productie-beheer-credentials.
5. Test technisch herstel, niet alleen of de back-up bestaat, of hij ook restoret.
6. Monitor back-up-status en alarmeer bij wijzigingen op de back-up-keten.

Wat het kost en wat het oplevert#

Kosten: midden.

Wat het oplevert

• Ransomware en sabotage overleven dit type back-up niet, fundamentele weerbaarheid.
• Sluit aan op de NIS2-eis voor bedrijfscontinuïteit en herstel.
• Levert ook bescherming tegen 'gewone' beheerfouten.

Waar je op moet letten

• Hogere opslagkosten dan reguliere back-ups.
• Immutability betekent dat je tijdens de retentieperiode niet kunt opruimen, capaciteit moet vooraf geregeld.
• Vereist discipline om kopieën daadwerkelijk in een ander vertrouwensdomein te zetten.

Bewijs#

• De configuratie waaruit blijkt dat back-ups onveranderbaar zijn, met de bewaartermijn van die onveranderbaarheid.
• De scheiding van beheer: welk account beheert de back-ups, en waarom kan een gecompromitteerd domeinbeheeraccount daar niet bij.
• De dekking: welke kritieke systemen en data zitten erin, en welke niet.
• Een test waarin is geprobeerd een back-up te wijzigen of te verwijderen, met de uitkomst.

Zo leg je het uit#

Aan de directie. Een aanvaller versleutelt de productie én de back-up als die binnen handbereik is. Immutable en offline back-ups maken dat onmogelijk, fundamentele voorwaarde voor herstel na een groot incident.

Aan de informatiemanager. Inpassing op het back-up-platform en de opslag. Vraagt een tweede locatie of een ander vertrouwensdomein, met eigen credentials.

Aan het MT. Het back-up-beheer wordt strikter; herstel-oefeningen worden onderdeel van het ritme. Reken op periodiek geoefend herstel als reguliere taak.

Hoe dit samenhangt#

Deze handleiding hoort bij barriere backup uit de zelfcheck aanvalspaden. Wat je hiermee aantoont in BIO 2.0, NIST CSF, het Wpg-kader en de AVG staat op Van aanvalspad naar norm.

Een back-up is pas een back-up als je hebt teruggezet: zie Hersteltest tegen RTO en RPO.

Licentie#

EUPL-1.2.