Backup og sikkerhed for dit website: før du bliver hacket
En backup, der ikke er testet, er ikke en backup; brug denne tjekliste, før du bliver hacket, og beskyt dit website mod katastrofen.
Udgivet af: Hızlı Yazılım
Hvor din backup faktisk ligger
Hvis backuppen af din hjemmeside kun ligger i en separat mappe på den samme server, kan en angriber, der kommer ind, kryptere eller slette mappen under indbruddet. 3-2-1-reglen er stadig det praktiske udgangspunkt for små virksomheder: Hav tre kopier, brug to forskellige lagringsmedier, og opbevar én kopi et andet sted. En backup, der aldrig forlader produktionsserveren, er ikke en backup; den optager bare diskplads.
Brug værktøjer som UpdraftPlus, Duplicator Pro, cPanel Backup, JetBackup eller en simpel rsync plus et cron-job. Send eksterne kopier til AWS S3, Google Drive, Backblaze B2 eller Hetzner Storage Box. Kræver din branche, at data bliver inden for et bestemt land eller en bestemt region, så tjek, hvor cloududbyderen opbevarer dem. Nogle faglige regler begrænser overførsel af data på tværs af grænser, så afklar det med din compliancerådgiver, før du vælger et eksternt lagringssted.
Ingen gendannelsesøvelse, ingen backup
At en backupfil findes, er ikke det samme som at den kan gendannes. Beskadigede arkiver, ufuldstændige databasedumps og forkerte filrettigheder viser sig først under en rigtig gendannelse. Derfor er en utestet backup slet ikke en backup. Mindst én gang om måneden bør du lave en fuld gendannelse til et testmiljø og kontrollere filer, database, plugins og temaindstillinger samlet.
Automatiser øvelsen med et lille script: Tag en nylig backup, pak den ud i et testområde, og kontroller, at forsiden returnerer HTTP 200. Fejler kontrollen, skal backupsystemet markeres med rød alarm. Mål også gendannelsestiden; en backup, der kan gendannes på to timer, er langt mere værd end en, der tager otte timer i en nødsituation.
Disciplin med opdateringer: Forældet software inviterer angribere indenfor
Gamle versioner af WordPress, WooCommerce, Joomla eller specialudviklede applikationer har kendte sårbarheder, som angribere automatisk scanner efter. En side, der springer opdateringer over, bliver efter et stykke tid et forudsigeligt mål. Slå automatiske opdateringer til for mindre sikkerhedsrettelser, men test spring til nye hovedversioner i et testmiljø først.
Før en oversigt over plugins og temaer; slet alt, der ikke bruges, for selv et inaktivt, forældet plugin øger risikoen. Læs ændringslogger før opdatering, og tjek for kendte konflikter. Men vær forsigtig: Automatiske opdateringer kan ødelægge specialkode og lægge siden ned. I stedet for at sende automatiske hovedopdateringer direkte i produktion bør du planlægge et vedligeholdelsesvindue og udføre dem med en plan for tilbagerulning.
Lås administrationspanelet af som en boks
Angribere bryder ofte ind i administrationspaneler med brute force. Skift standardstierne /admin eller /wp-admin, begræns antallet af loginforsøg, og kræv totrinsgodkendelse. Brug lange, unikke adgangskoder genereret af en adgangskodeadministrator; genbrug aldrig den samme adgangskode til e-mail eller andre tjenester.
Begræns adgangen til administrationen med en liste over tilladte IP-adresser og VPN for medarbejdere, der arbejder eksternt. I WordPress bør du slå XML-RPC og unødvendige REST-endpoints fra. Værktøjer som Wordfence, Sucuri eller Imunify360 på serveren blokerer brute force og ondsindede forespørgsler. Opdel også rollerne: En indholdsredaktør bør ikke have fulde administratorrettigheder.
Tilpas backupfrekvensen til typen af hjemmeside
Én backupplan passer ikke til alle hjemmesider. Webshops, medlemssystemer og bookingmoduler ændrer konstant data; her bør du som minimum tage backup af databasen hver time og fuld backup af filerne dagligt. En statisk brochureside kan ofte klare sig med en ugentlig fuld backup.
På sider med mange transaktioner bør du bruge inkrementel backup; tager en fuld backup timer hver gang, er daglig inkrementel plus ugentlig fuld backup fornuftigt. Med et begrænset budget kan du eksportere de mest kritiske data (ordrer, brugere, indhold) separat. Men automatisk fuld backup hver time er ikke nødvendig for alle sider; det bruger ressourcer og øger omkostningerne. Start med at fastlægge dit mål for gendannelsestid.
Kombiner backup med sikkerhedsovervågning
Backup alene er ikke sikkerhed; det stopper ikke et angreb, det giver kun mulighed for gendannelse. Efter et indbrud er det ikke nok at gendanne fra en ren backup — finder og lukker du ikke sårbarheden, går angriberen ind ad den samme dør igen. Kombiner backup med overvågning af filintegritet, scanning for malware og gennemgang af logfiler.
Kør Sucuri SiteCheck, Wordfence, ClamAV eller scannere på serveren regelmæssigt. Brug Git-baseret versionsstyring til at sammenligne filændringer før og efter en hændelse. En praktisk rutine for et lille team: automatisk backup + ugentlig sikkerhedsrapport + månedlig øvelse i gendannelse. Så reagerer du, før siden bliver hacket.