3-2-1-backup for nettsteder – bygg uavhengige kopier

3-2-1-regelen er en enkel huskeregel:

• 3 kopier totalt, inkludert produksjonsdata
• 2 ulike lagringstyper eller systemer
• 1 kopi på et annet sted

Modellen hjelper mot maskinvarefeil og lokal skade, men ordene «to medier» og «offsite» er ikke nok. Tre kopier som kan slettes med samme adminkonto, eller to datasentre hos samme kontrollplan, kan fortsatt ha ett felles feilpunkt.

Start med hva dere skal tåle

Definer:

• RPO, Recovery Point Objective: hvor mye nylig data kan gå tapt?
• RTO, Recovery Time Objective: hvor lenge kan tjenesten være utilgjengelig?

En statisk infoside kan kanskje bygges på nytt fra kode på minutter og tåle at ingen brukerdata endres. En nettbutikk kan ha ordre, lager, betaling og integrasjoner som krever langt hyppigere kopier og koordinert gjenoppretting.

Backupplanen må bygges fra konsekvensen, ikke fra en universell «daglig backup»-regel.

Tre kopier må ha ulike feildomener

Vurder uavhengighet langs flere akser:

• fysisk plassering og region
• leverandør og kontrollplan
• administratorkonto og identitetsleverandør
• API-nøkkel og slettetillatelse
• nettverkstilkobling
• backup-programvare og format
• krypteringsnøkkel
• personene som kan godkjenne permanent sletting

En snapshot på samme disk er ikke en uavhengig kopi. En backup i samme konto kan være nyttig for rask restore, men en angriper med administratorrettigheter kan kanskje slette både produksjon og backup.

Legg til én offline eller uforanderlig kopi

Ransomware og kontoovertakelse kan ramme tilkoblede og synkroniserte kopier. Legg derfor til minst én kontroll som gjør sletting vanskelig i en definert periode:

• frakoblet medium som ikke er kontinuerlig tilgjengelig fra produksjon
• object lock eller immutable retention
• separat konto med sterkt begrenset slettetilgang
• to-personers godkjenning for destruktive handlinger

«Immutable» må verifiseres i den aktuelle konfigurasjonen. Kontroller hvem som kan forkorte retensjon, slette hele kontoen, endre livssyklus eller ødelegge krypteringsnøkkelen.

En offline kopi må på sin side kobles til for skriving og testing. Dokumenter hvordan den håndteres uten at skadevare eller feil kopieres ukritisk videre.

Synkronisering er ikke backup

Synkronisering er laget for å gjøre kopier like. Sletting, kryptering eller feil kan derfor replikeres raskt. Versjonshistorikk kan gi beskyttelse, men bare hvis:

• gamle versjoner beholdes lenge nok
• en angriper ikke kan slette historikken
• hele datasettet kan gjenopprettes effektivt
• kvoter, livssyklus og kontostenging er forstått

Behandle speiling og høy tilgjengelighet på samme måte: replika hjelper ved maskinfeil, men replikerer også logiske feil og ondsinnede endringer.

Hva må en nettstedskopi inneholde?

For et CMS trenger dere normalt både database og brukeropplastede filer fra kompatible tidspunkter. En databasedump uten bilder er ufullstendig; en filkopi uten databasen kan mangle alt redaksjonelt innhold.

For en statisk side bør kildeinnhold, byggkonfigurasjon, avhengighetslåser og deployoppskrift være gjenopprettbare. En kopi av generert HTML kan være nyttig for nødvisning, men er ikke nødvendigvis redigerbar kilde.

Velg frekvens og retensjon fra RPO og trussel

Still disse spørsmålene:

• Hvor ofte endres data?
• Hvor raskt oppdages korrupsjon eller innbrudd?
• Hvor langt tilbake kan en ren kopi måtte finnes?
• Finnes juridiske krav til sletting eller oppbevaring?
• Hvor mye lagring og restore-tid gir hver ekstra versjon?
• Kan backupen skille en komplett transaksjon fra en halvskrevet?

Hyppige kopier reduserer mulig datatap, men beskytter ikke alene mot en angriper som var til stede før alle beholdte tidspunkter. Kombiner derfor kortsiktige, hyppige kopier med lengre historikk etter behov.

Dokumenter også hva som skjer når en jobb feiler eller lagringen er full. Et grønt «job completed» beviser bare at prosessen rapporterte suksess.

Beskytt backupdata og nøklene

Backup kan inneholde hele kundedatabasen, passordhashes, konfigurasjon og interne dokumenter.

• Krypter under overføring og lagring.
• Begrens lese-, restore- og slettetilgang separat.
• Bruk MFA på kontrollkontoer.
• Logg eksport, restore, policyendring og sletting.
• Hold aktive produksjonshemmeligheter ute av kopien når det finnes en bedre recoverymetode.
• Oppbevar krypteringsnøkler adskilt, men med testet nøkkel-recovery.
• Slett utløpte kopier på en dokumentert måte.

Kryptering uten tilgjengelig nøkkel gjør kopien ubrukelig. Nøkkel-recovery må testes med samme alvor som datarestore.

Test full gjenoppretting

En restore-test skal ikke bare åpne en zip-fil.

1. Velg et dokumentert gjenopprettingspunkt.
2. Opprett et isolert målmiljø.
3. Hent data med de tilgangene beredskapen faktisk har.
4. Gjenopprett filer, database, konfigurasjon og nødvendige tjenester.
5. Test innhold, innlogging, skjema, betaling og integrasjoner.
6. Mål faktisk RPO og RTO.
7. Kontroller datakonsistens og at backupen ikke inneholder kjent kompromittering.
8. Dokumenter feil, eier og rettingsfrist.
9. Slett testdata sikkert etterpå.

Testfrekvensen skal følge kritikalitet, endringstakt og resultatene fra tidligere tester. Test alltid etter større endring i plattform, backupverktøy, kryptering eller tilgangsmodell.

Bruk den detaljerte restore-testen for backup og gjenopprettingsplanen for nettsteder som arbeidsdokumenter.

NSMs minimum for en backupplan

NSM anbefaler at planen minst beskriver hvilke data som kopieres, frekvens, ansvar, feilprosedyrer, oppbevaring, beskyttelse og krav til gjenopprettingstid. NSM anbefaler også regelmessige offline-kopier som ikke kan nås via virksomhetens nettverk.

Se NSMs grunnprinsipper for IKT-sikkerhet for kontrollene i sammenheng.

Backup i Vymos standardtilbud

Vymo publiserer foreløpig ikke en garantert backupfrekvens, retensjon, immutable kopi eller selvbetjent restore for den enkle bedriftsnettsiden. Kunden bør derfor ikke anta at standardtilbudet oppfyller en bestemt 3-2-1-, RPO- eller RTO-policy.

Hvis nettsiden er kritisk eller lagrer data som endres, må krav til kopier, eksport, retensjon, kryptering og restore-test avklares skriftlig. Beskriv beredskapskravene , eller se om den enkle nettsiden passer når siden kun er en avgrenset presentasjon.