Backup er ikke beredskap før dere har testet gjenoppretting av WordPress
En kontrollert gjenopprettingsøvelse avdekker om backup, tilganger, dokumentasjon og overvåking faktisk fungerer når bedriftsnettstedet må bygges opp igjen.
Kategori: Sikker WordPress-drift
Det er lett å krysse av for backup når WordPress-nettstedet lagres automatisk hver natt. Det vanskelige spørsmålet er om sikkerhetskopien faktisk kan brukes. En vellykket jobbmelding sier bare at filer og data er kopiert. Den sier ikke at kopien er komplett, fri for skade eller mulig å gjenopprette innen akseptabel tid.
En gjenopprettingsøvelse gjør backupen til reell beredskap. Øvelsen bør foregå i et avskjermet miljø, ikke på det aktive nettstedet. Målet er å dokumentere hele veien fra beslutningen om gjenoppretting til et kontrollert, oppdatert og overvåket WordPress-nettsted.
Bestem hva øvelsen skal bevise
Start med et konkret scenario. Dere kan for eksempel anta at nettstedets database er ødelagt etter en feil, eller at produksjonsmiljøet må erstattes fordi uvedkommende kan ha fått tilgang. Scenarioet avgjør hva som skal gjenopprettes og hvilke kontroller som må gjennomføres.
Sett også et tydelig mål for øvelsen. Det kan være at nettstedet skal kunne gjenopprettes til et isolert miljø, at kritiske skjemaer skal fungere, og at ansvarlig person skal kunne dokumentere hvilket tidspunkt dataene er hentet fra. Unngå et uklart mål som bare sier at dere skal «teste backup».
Avklar på forhånd hvor mye datatap virksomheten kan akseptere. Et nettsted som primært viser informasjon, har andre behov enn en løsning som mottar bestillinger, søknader eller kundehenvendelser. Dersom siste backup er fra natten før, kan nye registreringer mangle selv om gjenopprettingen teknisk sett lykkes.
Kartlegg mer enn WordPress-filene
Et bedriftsnettsted består ofte av flere deler enn WordPress-kjernen, temaet og databasen. En nyttig gjenopprettingsplan må beskrive alle avhengighetene som kreves for normal drift.
- WordPress-filer, opplastede medier og database
- Serveroppsett, planlagte oppgaver og nødvendige innstillinger
- DNS, sertifikater og eventuell mellomlagring
- Skjemamottak, e-postutsending og integrasjoner
- Analyse, samtykkeløsning og andre eksterne tjenester
- Tilganger, tofaktorautentisering og kontaktpersoner
- Overvåking, varsling og loggføring
Hvis bare WordPress-innholdet er sikkerhetskopiert, kan mye manuelt arbeid gjenstå. Manglende serverinnstillinger kan føre til feil opplastingsgrenser, brutte planlagte oppgaver eller svakere sikkerhetsinnstillinger enn før hendelsen.
Kontroller at backupen er egnet
Før gjenopprettingen bør dere kunne svare på fire spørsmål: Når ble kopien tatt, hva inneholder den, hvor er den lagret, og hvem har tilgang? Backupen bør ligge adskilt fra miljøet den beskytter. Hvis både nettstedet og sikkerhetskopien er avhengig av samme konto eller server, kan én feil eller kompromittert tilgang ramme begge.
Kontroller at filene kan leses, at databasen kan importeres, og at kopien dekker riktig nettsted. Dette er spesielt viktig for virksomheter som har flere WordPress-installasjoner med lignende navn. Krypterte sikkerhetskopier må ha en dokumentert og tilgjengelig nøkkel. En backup ingen kan låse opp under en hendelse, har liten praktisk verdi.
Tilgangen til backup bør være begrenset. Sikkerhetskopien kan inneholde personopplysninger, skjemaoppføringer, brukerkontoer og konfigurasjon som ikke skal være tilgjengelig for alle med redaktørtilgang i WordPress.
Gjenopprett i et isolert miljø
Ikke legg en ukontrollert kopi rett tilbake i produksjon. Opprett et isolert testmiljø som ikke indekseres, ikke sender e-post til kunder og ikke behandler ekte bestillinger. Begrens tilgangen med egen autentisering, og bruk andre administratorpassord enn på produksjonsnettstedet.
Loggfør hvert trinn mens dere arbeider. Noter hvem som utfører oppgaven, hvilke kopier som brukes, tidspunktet for gjenopprettingen og eventuelle manuelle endringer. Dette gjør det mulig å forbedre prosedyren etterpå, og reduserer avhengigheten av at én tekniker husker alt.
- Opprett et rent og isolert driftsmiljø.
- Gjenopprett filer, medier og database fra valgt tidspunkt.
- Legg inn nødvendige serverinnstillinger og planlagte oppgaver.
- Deaktiver utgående e-post, betaling og andre handlinger med ekstern effekt.
- Kontroller brukere, programvareversjoner og sikkerhetsinnstillinger.
- Test sidemaler, skjemaer, søk og sentrale integrasjoner.
- Dokumenter feil, tidsbruk og manglende informasjon.
Ikke gjenopprett sårbarheten sammen med nettstedet
En eldre backup kan inneholde den samme sårbare utvidelsen eller den samme ukjente administratorkontoen som førte til problemet. Gjenoppretting må derfor følges av en sikkerhetskontroll før miljøet kan vurderes som klart.
Sammenlign installerte temaer og utvidelser med virksomhetens godkjente oversikt. Fjern komponenter som ikke er i bruk, og oppdater WordPress, utvidelser og temaer kontrollert. Hvis en komponent ikke lenger vedlikeholdes, må dere vurdere erstatning fremfor å aktivere den på nytt.
Se også etter uventede administratorer, endrede e-postadresser, nye integrasjonsnøkler og andre avvik. Ved mistanke om kompromittering bør passord, nøkler og sesjoner erstattes. Det er ikke tilstrekkelig å endre passordet til én WordPress-bruker dersom serverkontoer, databasebrukere eller eksterne tjenester kan være berørt.
Test autentisering og tilgangsstyring
En gjenopprettet løsning skal ikke bare vise riktige sider. Den må også ha riktig tilgangsmodell. Kontroller at administratorer bruker personlige kontoer, at tofaktorautentisering fungerer, og at tidligere ansatte eller leverandører ikke fortsatt har tilgang.
Test hvordan virksomheten får tilgang dersom den vanlige administratoren er utilgjengelig. En beredskapskonto kan være nødvendig, men den bør oppbevares sikkert, overvåkes og bare brukes når situasjonen krever det. Delte administratorbrukere gjør det vanskelig å se hvem som har gjort hva, og bør unngås.
Husk tilgangene utenfor WordPress. Domeneforvaltning, server, backup, e-posttjenester og sikkerhetsløsninger kan være avgjørende for å få nettstedet tilbake. Planen bør angi rolle og kontaktpunkt, men ikke spre passord eller hemmelige nøkler i et vanlig prosedyredokument.
Test funksjonene virksomheten er avhengig av
En forside som laster, er ikke bevis på at nettstedet fungerer. Lag en kort akseptansetest basert på det nettstedet faktisk brukes til. For et vanlig bedriftsnettsted kan testen omfatte navigasjon, kontaktskjema, søk, filnedlasting, innlogging og de viktigste sidemalene.
Skjemaer må testes hele veien fra innsending til mottak. Kontroller at kvitteringssiden vises, at data lagres riktig, og at varsling når avtalt mottaker. I det isolerte miljøet bør dere bruke kontrollerte testadresser slik at kunder eller ansatte ikke mottar misvisende meldinger.
For løsninger med bestillinger eller medlemsdata bør dere også kontrollere hvordan informasjon som er opprettet etter backup-tidspunktet, skal håndteres. Noen data kan kanskje hentes fra et eksternt system, mens andre må registreres manuelt.
Sett overvåkingen tilbake før lansering
Overvåking blir ofte glemt når oppmerksomheten er rettet mot selve gjenopprettingen. Før nettstedet settes i drift, må dere kontrollere at varsling for nedetid, feil, sertifikater, mistenkelige innlogginger og mislykkede sikkerhetskopier er aktiv.
Kontroller også hvem som mottar varslene. En teknisk alarm er verdiløs hvis den går til en avsluttet innboks eller til en leverandør som ikke lenger har ansvar. Varslingsrutinen bør angi hvem som vurderer hendelsen, hvem som kan gjøre endringer, og hvem som informerer internt.
Avslutt med en konkret forbedringsliste
Etter øvelsen bør dere samle funnene i en kort gjennomgang. Skill mellom feil som hindret gjenoppretting, forhold som forsinket arbeidet, og forbedringer som kan planlegges senere.
- Manglet databasen eller mediefiler i backupen?
- Var nødvendige tilganger tilgjengelige for riktig person?
- Var dokumentasjonen oppdatert og forståelig?
- Oppsto det feil på grunn av utdaterte utvidelser?
- Fungerte autentisering og tofaktor etter gjenoppretting?
- Ble kritiske funksjoner og integrasjoner testet?
- Kom varsler frem til ansvarlig mottaker?
Gi hvert tiltak en ansvarlig person og en frist. Oppdater deretter gjenopprettingsplanen mens erfaringene er ferske. Hvis øvelsen avdekket at sikkerhetskopien er ufullstendig eller at ingen har tilgang til den, bør dette behandles som en driftsrisiko, ikke som et notat til neste år.
Gjør øvelsen til en del av trygg drift
Hvor ofte gjenoppretting bør testes, avhenger av hvor ofte nettstedet endres, hvor viktig det er for virksomheten, og hvor mye data som kan gå tapt. En ny øvelse er særlig relevant etter bytte av driftsmiljø, større tekniske endringer, nye integrasjoner eller endret backup-løsning.
Den viktigste leveransen er ikke et skjermbilde som viser at nettstedet startet. Det er en dokumentert prosess som viser at virksomheten kan hente frem riktig kopi, gjenopprette i et rent miljø, stenge gamle tilganger, rette sårbarheter, validere kritiske funksjoner og aktivere overvåking. Først da er backupen en del av faktisk beredskap.
