Backup er ikke beredskap før den er testet: Øv på gjenoppretting av WordPress

En grønn status ved siden av «backup fullført» forteller bare at en prosess har kjørt. Den forteller ikke om sikkerhetskopien er komplett, om den kan gjenopprettes, eller om dere finner riktige tilganger når nettsiden er utilgjengelig.

Derfor bør virksomheter øve på gjenoppretting av WordPress. Målet er ikke bare å hente tilbake filer og database. Dere må kunne etablere et kjent, rent utgangspunkt, kontrollere hvem som har tilgang, tette årsaken til hendelsen og verifisere at forretningskritiske funksjoner virker.

En slik øvelse passer for både enkle bedriftsnettsteder og større løsninger med skjemaer, nettbutikk eller integrasjoner. Den gir et mer realistisk bilde av beredskapen enn en sjekkliste alene.

Start med et konkret hendelsesscenario

En øvelse blir mer nyttig når den tar utgangspunkt i en bestemt situasjon. Unngå det vage scenarioet «nettsiden er nede». Beskriv heller hva dere vet, hva dere ikke vet, og hvilke beslutninger som må tas.

Et egnet scenario kan være at en administrator oppdager ukjente brukere i WordPress, samtidig som enkelte sider sender besøkende videre til uønsket innhold. Dere vet ikke når endringene startet. Nettsiden er fortsatt tilgjengelig, men kan ikke betraktes som trygg.

Dette scenarioet tvinger frem viktige spørsmål:

• Skal nettsiden tas helt eller delvis ut av drift?
• Hvilken sikkerhetskopi kan regnes som ren?
• Hvordan hindrer dere angriperen i å beholde tilgangen?
• Hvilke passord, nøkler og integrasjonstilganger må byttes?
• Hvordan kontrollerer dere at problemet ikke følger med tilbake?
• Hvem avgjør når nettsiden kan åpnes igjen?

Øvelsen kan gjennomføres uten en reell sikkerhetshendelse. Bruk et isolert testmiljø, og avtal tydelig at produksjonsnettstedet ikke skal påvirkes.

Bestem hva som må kunne gjenopprettes

Et WordPress-nettsted består av mer enn innholdet i databasen. En brukbar backup må normalt omfatte database, mediefiler, temaer, egne kodeendringer og nødvendige konfigurasjoner. Samtidig bør dere vite hvilke deler som ikke bør gjenbrukes ukritisk etter et innbrudd.

Plugins og WordPress-kjerne kan ofte installeres på nytt fra kjente, rene pakker. Det er tryggere enn å kopiere alle programfiler direkte fra en sikkerhetskopi som kan inneholde manipulert kode. Egne temaer og spesialutviklede utvidelser bør hentes fra virksomhetens godkjente kodearkiv dersom dette finnes.

Kartlegg også avhengigheter utenfor selve WordPress-installasjonen:

• DNS og domeneadministrasjon
• Webhotell, server eller driftsplattform
• Sertifikater og sikkerhetsinnstillinger
• E-posttjenester og skjemamottak
• Betalingsløsninger, analyseverktøy og andre integrasjoner
• Eksterne fonter, medier eller innholdskilder
• Jobber som kjører automatisk i bakgrunnen

Hvis ingen vet hvor disse delene administreres, er det et beredskapsproblem selv om backupen er teknisk god.

Definer akseptabelt datatap og nedetid

Før øvelsen bør ledelsen avklare hvor mye data virksomheten kan tåle å miste, og hvor lenge nettsiden kan være utilgjengelig. Behovet avhenger av hva nettstedet brukes til.

En enkel presentasjonsside kan kanskje gjenopprettes fra gårsdagens backup uten store konsekvenser. For en nettbutikk kan samme valg bety tap av nye ordre, lagerendringer og kundedata. Et nettsted med mange skjemainnsendinger kan miste henvendelser som ikke finnes i andre systemer.

Gjør kravene konkrete. «Raskt tilbake» er ikke et operativt mål. Angi heller hvor gammelt gjenopprettingspunktet maksimalt kan være, og hvor lang tid teamet har på å etablere en kontrollert løsning. Kravene avgjør hvor ofte backup må tas, hvordan den lagres, og hvem som må kunne starte gjenopprettingen.

Kontroller backupen før dere trenger den

En sikkerhetskopi bør lagres adskilt fra nettstedet den beskytter. Hvis produksjonsmiljø og backup kan slettes eller krypteres med samme administratorkonto, har dere en felles feilkilde. Tilgangen til backup bør ha sterk autentisering og være begrenset til personer som faktisk trenger den.

Før øvelsen bør dere kontrollere følgende:

• At planlagte sikkerhetskopier faktisk fullføres
• At flere historiske gjenopprettingspunkter er tilgjengelige
• At backupen ikke bare ligger på samme server som nettstedet
• At innholdet er beskyttet mot uautoriserte endringer og sletting
• At minst to avtalte personer vet hvordan backupen hentes ut
• At varsler ved mislykket backup går til en kanal som blir fulgt opp

Ikke bruk øvelsen til å dele hovedpassord i e-post eller chat. Bruk navngitte kontoer, passordhvelv og en dokumentert nødprosedyre. Nødtilgang skal være mulig å bruke, men vanskelig å misbruke.

Gjenopprett i et isolert miljø

Selve gjenopprettingen bør først skje i et miljø som ikke er offentlig tilgjengelig og som ikke kan sende e-post, belaste betalingskort eller overskrive data i eksterne systemer. Produksjonskopier kan ellers utløse handlinger som ser ekte ut.

1. Registrer starttid og ansvar. Noter hvem som leder øvelsen, hvem som utfører tekniske oppgaver, og hvem som godkjenner resultatet.
2. Velg et gjenopprettingspunkt. Begrunn hvorfor tidspunktet anses som trygt. Det nyeste eksemplaret er ikke nødvendigvis det riktige ved mistanke om langvarig kompromittering.
3. Etabler et rent grunnmiljø. Installer operativsystem, serverkomponenter og WordPress fra kontrollerte kilder fremfor å gjenbruke et miljø dere ikke stoler på.
4. Importer nødvendige data. Gjenopprett database og mediefiler, men vurder programfiler separat.
5. Installer godkjent kode på nytt. Bruk vedlikeholdte versjoner av temaer og utvidelser. Fjern komponenter som ikke lenger er nødvendige.
6. Deaktiver utgående handlinger. Hindre utsending av e-post, automatiske ordreprosesser og kall til eksterne tjenester til løsningen er kontrollert.
7. Test funksjonene. Kontroller representative sider, innlogging, skjemaer, søk, redigering og eventuelle kjøpsløp.

Noter alle manuelle inngrep. Hvis gjenopprettingen avhenger av at én utvikler husker en bestemt serverinnstilling, er prosessen for sårbar.

Bytt tilganger, ikke bare administratorpassordet

Ved et reelt innbrudd er det sjelden tilstrekkelig å endre passordet til én WordPress-bruker. Angriperen kan ha opprettet flere kontoer, hentet ut integrasjonsnøkler eller fått tilgang via webhotell og e-post.

Lag en fast liste over tilganger som skal vurderes:

• Administratorer og redaktører i WordPress
• Webhotell, server og kontrollpanel
• Databasebrukere og filoverføring
• Domene- og DNS-administrasjon
• Backupkontoer
• E-postkontoer som kan tilbakestille passord
• Nøkler til betalings-, skjema- og analyseintegrasjoner
• Utviklerverktøy og automatiserte publiseringsprosesser

Fjern ukjente og foreldede kontoer. Krev flerfaktorautentisering der det er mulig, særlig for administrative innganger. Unngå delte brukere fordi de gjør det vanskeligere å se hvem som har utført en handling.

Et passordbytte hjelper heller ikke dersom en sårbar plugin fortsatt gir adgang. Finn derfor sannsynlig inngangsvei før løsningen åpnes igjen. Oppdater eller fjern den utsatte komponenten, og undersøk om tilsvarende svakhet finnes i andre miljøer.

Kontroller at den gjenopprettede løsningen er trygg

At forsiden vises, betyr ikke at nettstedet er klart. Gjennomfør en kontroll som kombinerer sikkerhet, funksjon og datakvalitet.

Se etter ukjente administratorer, endrede systeminnstillinger, nye planlagte oppgaver, mistenkelige filer og kode som lastes fra uventede steder. Sammenlign egne kodefiler med godkjente versjoner. Kontroller også at WordPress, temaer og utvidelser er oppdatert og fortsatt støttet.

Test deretter de viktigste brukerreisene. Send et skjema til en kontrollert mottaker. Gjennomfør et testkjøp uten reell belastning dersom nettstedet har nettbutikk. Kontroller at samtykker, e-postvarsler, søk og innlogging fungerer som forventet.

Overvåkingen må også tilbake i drift. Bekreft at dere får varsel ved utilgjengelighet, mislykket backup, uventede filendringer og administrative innlogginger som krever oppfølging. Varslene må ha en navngitt mottaker og en avtalt handling.

Avslutt med beslutninger, ikke bare et referat

Etter øvelsen bør teamet svare på tre spørsmål: Hva stoppet oss, hva tok unødvendig lang tid, og hva var avhengig av enkeltpersoner?

Gjør funnene om til konkrete oppgaver med ansvarlig person og frist. Det kan være å etablere separat backuplagring, dokumentere DNS-tilgang, innføre flerfaktorautentisering, fjerne gamle brukere eller automatisere kontroll av sikkerhetskopier.

Oppdater deretter en kort gjenopprettingsplan. Den bør beskrive hvem som kan erklære en hendelse, hvordan nettsiden isoleres, hvor backup finnes, hvilke tilganger som må byttes, hvilke funksjoner som skal testes, og hvem som godkjenner gjenåpning.

Gjenta øvelsen når nettstedet får vesentlige nye funksjoner, driftsleverandøren byttes eller sentrale personer slutter. Beredskap er ikke et dokument som blir ferdig. Den består av rutiner som fortsatt virker når de vanlige forutsetningene svikter.