Hvem har egentlig tilgang? Slik gjennomfører dere en tilgangsrevisjon i WordPress

Kategori: Nettsikkerhet

Gamle brukerkontoer er en vanlig blindflekk i WordPress. Ansatte bytter rolle, byråer avslutter oppdrag, frilansere leverer ferdig og integrasjoner erstattes. Likevel blir tilgangen ofte stående. Resultatet er flere mulige innganger til nettstedet enn virksomheten har oversikt over.

En tilgangsrevisjon handler om å finne ut hvem og hva som kan logge inn, hvilke rettigheter de har, og om tilgangen fortsatt er nødvendig. Den bør ikke begrenses til brukerlisten i WordPress. Driftspanel, domeneadministrasjon, kodearkiv, analyseverktøy, sikkerhetstjenester og systemer som utveksler data med nettsiden, må også vurderes.

Målet er ikke å fjerne tilgang for sikkerhets skyld. Målet er at hver person og teknisk tjeneste har riktig tilgang, på riktig sted, så lenge behovet finnes.

Start med å definere hva revisjonen omfatter

WordPress er sjelden et isolert system. En administrator kan kanskje endre innhold og installere utvidelser, mens en person med tilgang til driftsmiljøet kan endre filer, database og sikkerhetskopier uten å logge inn i WordPress.

Lag derfor en enkel oversikt over systemene som kan påvirke nettstedet:

• WordPress-brukere og roller
• driftsmiljø og kontrollpanel
• filoverføring, kommandolinje og databaseverktøy
• domene og DNS
• kodearkiv og utrullingsløsninger
• backup og gjenoppretting
• overvåking og sikkerhetsvarsler
• skjema-, e-post-, analyse- og betalingsløsninger
• integrasjoner med CRM, ERP eller andre fagsystemer

For hvert system bør dere registrere en intern eier. Eieren trenger ikke å utføre alle tekniske oppgaver, men skal kunne avgjøre hvem som skal ha tilgang og hvem som skal kontaktes ved avvik.

Skill mellom personer og tekniske kontoer

En god brukeroversikt skiller mellom personlige kontoer og kontoer som brukes av integrasjoner, automatisering eller drift. Disse må håndteres forskjellig.

Personlige kontoer skal være knyttet til én identifiserbar person. Navn som «admin», «web» eller «marked» gjør det vanskelig å vite hvem som faktisk utførte en endring. Delte kontoer gjør også avslutning av tilgang mer krevende, fordi passordet må byttes for alle brukere.

Tekniske kontoer kan være nødvendige når et system skal publisere data, kontrollere oppetid eller utføre planlagte oppgaver. De bør ha et tydelig navn, dokumentert formål, en ansvarlig eier og minst mulig tilgang. En integrasjon som bare skal lese produktinformasjon, trenger normalt ikke administratorrettigheter.

Hvis dere ikke kan forklare hva en konto brukes til, bør den undersøkes før den beholdes. Ikke slett ukjente tekniske kontoer impulsivt. Deaktiver dem kontrollert eller test konsekvensen i et trygt miljø først.

Kontroller rettigheter, ikke bare brukernavn

Det er lett å avslutte kontoen til en tidligere ansatt. Den vanskeligere delen er å vurdere om aktive brukere har for omfattende rettigheter.

I WordPress bør administratorrollen reserveres for personer som faktisk trenger å endre nettstedets tekniske oppsett, administrere brukere eller håndtere utvidelser. En innholdsprodusent trenger vanligvis ikke disse mulighetene. Redaktører kan få ansvar for innhold uten samtidig å kunne installere kode.

Still tre spørsmål om hver bruker:

1. Trenger personen fortsatt tilgang?
2. Trenger personen tilgang til akkurat dette systemet?
3. Trenger personen alle rettighetene kontoen har?

Vurder også hvor ofte tilgangen brukes. En ekstern utvikler trenger kanskje administratorrettigheter under et prosjekt, men ikke permanent. Midlertidig tilgang bør ha en avtalt sluttdato og fjernes når arbeidet er godkjent.

Gjør sterk autentisering til et krav

Tilgangsstyring mister mye av effekten dersom kontoene bare beskyttes av svake eller gjenbrukte passord. Alle kontoer med betydelige rettigheter bør bruke flerfaktorautentisering der det er mulig. Det gjelder ikke bare WordPress, men også e-postkontoen som brukes til tilbakestilling av passord, driftsmiljøet og domeneadministrasjonen.

Brukerne bør ha unike passord lagret i en godkjent passordbehandler. Innloggingsinformasjon skal ikke sendes rundt i e-post, chat eller dokumenter. Dersom en delt konto ikke kan unngås, må virksomheten ha en kontrollert måte å lagre, dele og bytte legitimasjonen på.

Kontroller samtidig prosessen for gjenoppretting av kontoer. En angriper trenger ikke å kjenne passordet dersom det er enkelt å overta e-postkontoen eller lure kundeservice til å nullstille tilgangen.

Se etter tilganger utenfor WordPress

En ryddig brukerliste i WordPress betyr ikke nødvendigvis at nettstedet er godt sikret. En tidligere leverandør kan fortsatt ha tilgang til filer eller database. En utvikler kan ha tilgang gjennom et kodearkiv. En gammel integrasjonsnøkkel kan fortsatt fungere.

Kontroller derfor:

• brukere og nøkler i driftsmiljøet
• tilgang til kodearkiv og utrulling
• aktive API-nøkler og integrasjoner
• hvem som kan endre DNS og domeneinnstillinger
• hvem som kan hente eller gjenopprette sikkerhetskopier
• mottakere av sikkerhets- og driftsvarsler

Sikkerhetskopier krever særlig oppmerksomhet. De kan inneholde database, personopplysninger, konfigurasjon og annen sensitiv informasjon. Tilgang til backup bør derfor behandles som tilgang til selve produksjonsmiljøet.

Koble revisjonen til oppdateringer og sårbarheter

Tilgangsstyring og teknisk vedlikehold henger sammen. Hvis ingen vet hvem som har ansvar for en utvidelse eller integrasjon, blir det også uklart hvem som skal vurdere sikkerhetsoppdateringer og sårbarheter.

Bruk revisjonen til å kontrollere at hver kritiske komponent har en ansvarlig part. Det bør være avklart hvem som følger med på varsler, hvem som vurderer konsekvensen av en oppdatering, hvem som tester, og hvem som kan godkjenne utrulling.

En sårbar utvidelse bør ikke bli stående fordi den opprinnelige leverandøren fortsatt er den eneste med nødvendig tilgang. Virksomheten må selv ha kontroll over administrative kontoer, lisenser, teknisk dokumentasjon og muligheten til å bytte leverandør.

Bruk logger til å bekrefte faktisk aktivitet

Brukerlisten viser hvem som kan logge inn. Logger kan vise hvem som faktisk har gjort det. Ved revisjonen bør dere undersøke uventede innlogginger, endringer i brukerroller, opprettelse av nye administratorer og tekniske endringer uten kjent arbeidsordre.

Det er også nyttig å se etter kontoer som ikke har vært brukt på lenge. Inaktivitet er ikke automatisk et bevis på at kontoen kan slettes, men det er et tydelig signal om at behovet bør bekreftes.

Overvåking må ha en mottaker og en reaksjonsplan. Et varsel om en ny administrator har liten verdi dersom det sendes til en avsluttet e-postkonto eller ingen vet hvem som skal undersøke det.

Lag en fast prosess for oppstart, rollebytte og avslutning

Den mest effektive tilgangsrevisjonen er den som gradvis blir mindre omfattende fordi den daglige prosessen fungerer. Tilgang bør håndteres som en del av medarbeiderens eller leverandørens livsløp.

Når noen starter

• Opprett en personlig konto.
• Gi minste nødvendige rolle.
• Aktiver sterk autentisering.
• Registrer systemeier og formål.
• Avtal sluttdato for midlertidig tilgang.

Når noen bytter rolle

• Fjern tilganger som hørte til den gamle rollen.
• Vurder nye behov fra bunnen av.
• Kontroller tilgang til eksterne systemer, ikke bare WordPress.

Når noen slutter

• Deaktiver personlige kontoer raskt.
• Overfør eierskap til innhold, integrasjoner og varsler.
• Bytt delte passord og relevante nøkler.
• Fjern tilgang til drift, kode, backup og domene.
• Dokumenter at avslutningen er gjennomført.

Dokumenter beslutningene i en enkel tilgangsmatrise

Dere trenger ikke et tungt styringssystem for å komme i gang. En tilgangsmatrise kan inneholde person eller tjeneste, system, rolle, begrunnelse, eier, dato for godkjenning og dato for neste kontroll.

Selve revisjonen bør ende med konkrete handlinger, ikke bare en oppdatert liste. Eksempler kan være å nedgradere en administrator til redaktør, avslutte en gammel integrasjonsnøkkel, flytte backupvarsler til riktig mottaker eller kreve flerfaktorautentisering før neste innlogging.

Gjennomfør kontrollen regelmessig og alltid etter større organisatoriske endringer, leverandørbytter eller avsluttede prosjekter. Nettstedets betydning og antall brukere avgjør hvor ofte det er nødvendig.

God nettsikkerhet begynner med et enkelt spørsmål: Hvem kan gjøre hva? Når svaret er dokumentert, kontrollert og knyttet til tydelig ansvar, blir både oppdateringer, sårbarhetshåndtering, backup og overvåking tryggere å forvalte.