Før dere installerer neste WordPress-utvidelse: Bygg en sikkerhetsport for plugins

Kategori: Nettsikkerhet

En ny WordPress-utvidelse kan løse et behov på få minutter. Den kan legge til et skjema, koble nettsiden til et kundesystem eller gi redaksjonen en ny innholdsfunksjon. Samtidig tilfører hver utvidelse mer kode, flere oppdateringer og enda en mulig inngang til nettstedet.

Problemet er derfor ikke at bedriften bruker plugins. Problemet oppstår når de installeres uten en definert vurdering, tydelig eier eller plan for videre drift. Resultatet blir ofte et nettsted med overlappende funksjoner, uklare tilganger og komponenter ingen tør å fjerne.

En sikkerhetsport er en enkel beslutningsprosess som alle nye WordPress-utvidelser må gjennom før de tas i bruk. Den gjør sikkerhetsarbeidet konkret og hjelper bedriften med å vurdere behov, sårbarheter, tilgang, oppdateringer, backup og overvåking i sammenheng.

Start med behovet, ikke utvidelsen

Mange plugin-problemer begynner med en løsning som leter etter et behov. En medarbeider finner en utvidelse som virker nyttig, installerer den og tester direkte på produksjonsnettstedet. Selv om funksjonen senere blir forkastet, kan utvidelsen bli liggende aktiv eller etterlate data og innstillinger.

Før noen vurderer et konkret produkt, bør behovet beskrives med én eller to setninger. Eksempel: Bedriften trenger at besøkende kan melde seg på arrangementer, og påmeldingene skal sendes til systemet som håndterer deltakerlisten.

Deretter bør dere avklare:

• Om funksjonen allerede finnes i WordPress-oppsettet.
• Om behovet kan løses uten en ny utvidelse.
• Hvilke data funksjonen skal lese, lagre eller sende videre.
• Hvem som skal bruke og forvalte funksjonen.
• Hva som skjer dersom utvidelsen slutter å virke.

Denne avklaringen hindrer at plugins blir installert for små bekvemmeligheter, mens bedriften overtar et langsiktig driftsansvar.

Vurder konsekvensen av feil

Ikke alle utvidelser har samme risikoprofil. En enkel presentasjonsfunksjon er noe annet enn en utvidelse som behandler skjemaopplysninger, betalinger eller administrative brukere. Sikkerhetsporten bør derfor klassifisere konsekvensen dersom utvidelsen blir misbrukt eller svikter.

Lav konsekvens

Utvidelsen påvirker hovedsakelig visning og har begrenset tilgang til data. En feil kan gi en ødelagt modul eller dårligere brukeropplevelse, men stopper ikke sentrale prosesser.

Middels konsekvens

Utvidelsen behandler kundehenvendelser, påvirker søkbarhet eller er viktig for publisering. Feil kan føre til tapte henvendelser, feil innhold eller merkbar nedetid.

Høy konsekvens

Utvidelsen håndterer betaling, personopplysninger, innlogging, sikkerhet, backup eller integrasjoner med sentrale fagsystemer. Kompromittering kan få betydelige følger for både kunder og virksomheten.

Jo høyere konsekvens, desto strengere bør kravene være til testing, tilgangsstyring, overvåking og gjenoppretting. Klassifiseringen gjør det også enklere å prioritere når flere sikkerhetsoppgaver konkurrerer om tiden.

Undersøk vedlikehold før installasjon

En utvidelse er ikke et engangskjøp. Den må fungere sammen med WordPress, temaet, servermiljøet og andre utvidelser over tid. Før godkjenning bør noen få ansvar for å vurdere om løsningen fremstår som aktivt vedlikeholdt og om den passer virksomhetens tekniske oppsett.

Vurder blant annet:

• Om utvidelsen vedlikeholdes og oppdateres på en forutsigbar måte.
• Om det finnes en tydelig aktør som har ansvar for produktet.
• Om kjente sikkerhetsproblemer blir håndtert.
• Om utvidelsen krever flere tillegg for å levere ønsket funksjon.
• Om data lagres lokalt, sendes til en ekstern tjeneste eller begge deler.
• Om bedriften kan hente ut data og avvikle løsningen senere.

En utvidelse kan være teknisk god i dag, men likevel være et dårlig valg dersom leverandørforholdet er uklart eller bedriften blir låst til en løsning som er vanskelig å erstatte.

Test utenfor produksjonsnettstedet

Nye plugins bør som hovedregel prøves i et separat testmiljø. Installasjon direkte på det aktive nettstedet kan påvirke ytelse, design, database og eksisterende funksjoner. En konflikt viser seg heller ikke alltid med en tydelig feilmelding. Den kan like gjerne føre til at et skjema slutter å sende e-post eller at redigering blir ustabil.

En praktisk test bør dekke mer enn om den nye funksjonen ser riktig ut:

1. Ta en verifisert backup før endringen.
2. Installer og konfigurer utvidelsen i testmiljøet.
3. Test sentrale kundereiser, skjemaer, søk og innlogging.
4. Kontroller hvilke nye brukere, roller, databasefelt og planlagte oppgaver som opprettes.
5. Vurder om sidene blir merkbart tregere.
6. Oppdater utvidelsen én gang i testmiljøet hvis en oppdatering er tilgjengelig.
7. Deaktiver og fjern den for å undersøke hva som blir liggende igjen.

Det siste punktet blir ofte glemt. En plugin som er enkel å installere, er ikke nødvendigvis enkel å avvikle.

Begrens tilganger og eksterne koblinger

En utvidelse kan gi nye innstillinger, brukerroller, integrasjonsnøkler eller innloggingsmuligheter. Sikkerhetsporten må derfor avklare hvem som faktisk trenger tilgang. Redaktører bør ikke få administrativ tilgang bare fordi det er den raskeste måten å få funksjonen til å virke på.

Bruk personlige kontoer, sterke unike passord og flerfaktorautentisering for brukere med utvidede rettigheter. Delte administratorkontoer gjør det vanskelig å se hvem som har utført en endring, og kompliserer arbeidet når ansatte eller leverandører avslutter oppdraget.

Eksterne leverandører bør få tidsbegrenset tilgang med lavest nødvendige rettighetsnivå. Tilgangen må fjernes eller sperres når arbeidet er ferdig. Integrasjonsnøkler og andre hemmeligheter bør ikke sendes i åpne samtaler eller lagres i redaksjonelle felt.

Bestem hvordan oppdateringer skal håndteres

En godkjenning er ikke fullført før det finnes en oppdateringsplan. Utvidelser som ikke oppdateres, kan beholde kjente sårbarheter. Oppdateringer som gjennomføres ukritisk, kan på sin side skape konflikter og nedetid.

Planen bør angi:

• Hvem som følger med på tilgjengelige oppdateringer og sikkerhetsvarsler.
• Hvor raskt sikkerhetskritiske oppdateringer skal vurderes.
• Hvilke endringer som skal testes før produksjon.
• Når oppdateringer kan gjennomføres med lavest konsekvens.
• Hvem som kontrollerer nettstedet etterpå.
• Hvordan forrige fungerende tilstand kan gjenopprettes.

Automatiske oppdateringer kan være nyttige for enkelte komponenter, men de fjerner ikke behovet for kontroll. Bedriften må fortsatt oppdage feil og vite hva som ble endret.

Koble backup til reell gjenoppretting

Backup er sikkerhetsnettet når en installasjon eller oppdatering går galt. Den har begrenset verdi hvis kopien er ufullstendig, ligger i samme miljø som nettstedet eller aldri er testet.

Før en utvidelse med middels eller høy konsekvens settes i drift, bør dere vite at både filer og database kan gjenopprettes. Kopiene bør oppbevares slik at en hendelse på webserveren ikke ødelegger både originalen og sikkerhetskopien.

Test også selve tilbakeføringen. Målet er ikke bare å ha en backup, men å kunne få nettstedet og forretningsfunksjonen tilbake innen akseptabel tid. For en påmeldingsløsning betyr det også å kontrollere at innsendte data og koblinger til andre systemer er intakte.

Overvåk funksjonen etter lansering

At nettsiden svarer, betyr ikke at plugin-funksjonen virker. Et nettsted kan være tilgjengelig samtidig som skjemaer feiler, betaling stopper eller integrasjonen ikke sender data videre.

Overvåkingen bør tilpasses konsekvensen. For en viktig skjemaløsning kan dere sende en kontrollhenvendelse med jevne mellomrom og bekrefte at den kommer frem. For en nettbutikk bør en definert test kontrollere sentrale deler av kjøpsløpet. Feillogger og uventede endringer i administrative brukere bør også følges opp.

Avklar hvem som mottar varsler, hvem som vurderer dem og hvor raskt det forventes reaksjon. Varsler uten eierskap blir lett stående ulest.

Før et enkelt plugin-register

Bedriften trenger ikke et omfattende styringssystem. Et enkelt register gir likevel langt bedre kontroll enn hukommelse og tilfeldige notater. For hver utvidelse bør dere registrere:

• Navn og formål.
• Internt ansvarlig person.
• Teknisk driftsansvarlig.
• Risikoklasse og data som behandles.
• Viktige integrasjoner og tilganger.
• Rutine for oppdatering og testing.
• Dato for siste vurdering.
• Plan for erstatning eller avvikling.

Registeret gjør periodiske kontroller raskere. Det blir også lettere å fjerne utvidelser som ikke lenger støtter et reelt behov.

Gjør beslutningen tydelig

Sikkerhetsporten bør ende med én av tre beslutninger: godkjent, godkjent med tiltak eller avvist. En utvidelse kan for eksempel godkjennes under forutsetning av at flerfaktorautentisering aktiveres, at en bestemt kundereise overvåkes, eller at den først innføres etter en vellykket gjenopprettingstest.

Poenget er ikke å gjøre enhver installasjon tungvint. Målet er å unngå at små, raske valg skaper ukjent risiko og varig driftsarbeid. Når behov, konsekvens, tilgang, oppdatering, backup og overvåking vurderes før installasjon, blir WordPress-miljøet enklere å forvalte og tryggere å drive.