← Nyttig
15. oktober 20267 min lesetid
Nyheter

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

Gamle brukerkontoer, delte passord og administratorrettigheter som aldri fjernes, skaper unødvendig risiko. En fast tilgangsrevisjon gir virksomheten kontroll over hvem som kan gjøre hva på nettstedet.

Kategori: Nettsikkerhet

Tilganger i WordPress har en tendens til å hope seg opp. En tidligere ansatt har fortsatt brukerkonto. Byrået som bygget nettstedet, har flere administratorer. Markedsavdelingen deler innlogging med en ekstern konsulent. En integrasjon bruker en konto ingen lenger vet hvem som opprettet.

Hver enkelt tilgang kan ha hatt en god begrunnelse. Problemet oppstår når ingen vurderer dem samlet eller fjerner dem når behovet forsvinner. Da blir virksomheten sittende med flere mulige innganger til nettstedet enn nødvendig.

Tilganger bør vurderes av både teknisk og forretningsmessig ansvarlig.
Tilganger bør vurderes av både teknisk og forretningsmessig ansvarlig.

En tilgangsrevisjon er en systematisk gjennomgang av brukere, roller, innloggingsmetoder og tekniske kontoer. Målet er ikke bare å rydde i WordPress. Dere skal kunne svare på tre spørsmål: Hvem har tilgang, hvorfor har de tilgang, og hva kan de gjøre?

Hvorfor tilgangsstyring er mer enn passord

Et sterkt passord hjelper lite dersom kontoen tilhører en person som sluttet for et år siden. Tofaktorautentisering reduserer risikoen ved stjålne passord, men løser ikke problemet med for vide rettigheter. Oppdateringer tetter kjente sårbarheter i programvaren, men kan ikke hindre misbruk av en gyldig administratorkonto.

God nettsikkerhet krever derfor flere lag. Oppdateringer, backup, sårbarhetshåndtering og overvåking er viktige tiltak, men tilgangsstyringen bestemmer hvem som kan påvirke disse lagene. En administrator kan installere programtillegg, endre kode, opprette nye brukere og slå av sikkerhetsfunksjoner. Rettigheten bør behandles som en nøkkel til hele nettstedet, ikke som en praktisk standardrolle.

Start med et komplett tilgangskart

Ikke begrens gjennomgangen til brukerlisten i WordPress. Et bedriftsnettsted består ofte av flere systemer med egne tilganger. Kartlegg minst følgende:

  • brukerkontoer og roller i WordPress
  • tilgang til webhotell, server eller kontrollpanel
  • domeneadministrasjon og DNS
  • kodearkiv og publiseringsløsninger
  • backup, sikkerhetsverktøy og overvåking
  • analyseverktøy, skjemaløsninger og andre integrasjoner
  • e-postkontoer som brukes til passordnullstilling
  • API-nøkler, applikasjonspassord og tekniske brukere

Registrer eier, formål, tilgangsnivå og dato for siste bekreftelse. Hvis ingen kan forklare hvorfor en konto eller nøkkel finnes, bør den ikke automatisk få bli stående. Undersøk først om den brukes av en integrasjon eller en planlagt prosess, og fjern eller roter tilgangen kontrollert.

Tofaktorautentisering bør beskytte alle kontoer med utvidede rettigheter.
Tofaktorautentisering bør beskytte alle kontoer med utvidede rettigheter.

Vurder behovet, ikke stillingstittelen

En vanlig feil er at alle som arbeider med nettstedet, får administratorrolle. Det er enkelt ved oppstart, men gir varig risiko. En innholdsprodusent trenger normalt ikke å installere programtillegg. En oversetter trenger ikke å endre brukere. En utvikler trenger kanskje administratorrettigheter i en avgrenset periode, men ikke nødvendigvis permanent tilgang til produksjonsmiljøet.

Bruk prinsippet om minste privilegium: Hver person og tjeneste skal ha akkurat nok tilgang til å utføre oppgaven sin. Ikke mer.

Still fire spørsmål for hver tilgang

  1. Er behovet fortsatt aktivt? Bekreft at personen eller systemet fremdeles utfører oppgaven.
  2. Er rollen riktig? Undersøk om oppgaven kan løses med færre rettigheter.
  3. Er tilgangen personlig? Mennesker bør bruke egne kontoer, ikke en delt fellesbruker.
  4. Har tilgangen en eier? En navngitt person må ha ansvar for å følge den opp.

Personlige kontoer gjør det mulig å fjerne én persons tilgang uten å påvirke andre. De gir også bedre hendelseslogger. Hvis fem personer bruker samme administrator, blir det vanskelig å fastslå hvem som endret en innstilling eller installerte et programtillegg.

Skill mellom mennesker og maskiner

Tekniske tilganger blir ofte glemt fordi de ikke vises som vanlige medarbeidere. Et publiseringsverktøy kan ha et applikasjonspassord. Et skjema kan sende data til et annet system med en API-nøkkel. En driftsleverandør kan bruke automatiserte nøkler for vedlikehold.

Slike tilganger bør ikke være knyttet til en ansatts personlige konto. Opprett en tydelig navngitt tjenestekonto når løsningen krever det, og dokumenter hva den brukes til. Begrens rettighetene til den konkrete funksjonen. Hemmeligheter skal lagres i et egnet system, ikke i e-post, regneark eller interne dokumenter med bred tilgang.

En fast sjekkliste gjør tilgangsrevisjonen enklere å gjenta.
En fast sjekkliste gjør tilgangsrevisjonen enklere å gjenta.

Fastsett også en rutine for å bytte nøkler og passord. Rotasjon er særlig viktig når en leverandør avslutter oppdraget, en nøkkel kan ha blitt eksponert, eller dere ikke lenger vet hvem som har hatt innsyn.

Gjør sterk autentisering obligatorisk

Alle kontoer med betydelig påvirkning på nettstedet bør beskyttes med tofaktorautentisering. Det gjelder ikke bare WordPress-administratorer, men også webhotell, domeneadministrasjon, e-post og andre systemer som kan brukes til å overta eller endre nettstedet.

Passord skal være unike og lagres i en passordadministrator. Ikke gjenbruk et passord fra andre tjenester, og ikke send passord i e-post eller chat. Der det er mulig, bør virksomheten bruke sentral innlogging. Da blir det enklere å håndheve autentiseringskrav og stenge en medarbeiders tilganger samlet.

Planlegg samtidig for at innlogging kan svikte. Dokumenter hvordan virksomheten får tilgang dersom en telefon forsvinner, en ansatt blir utilgjengelig eller identitetsleverandøren har driftsproblemer. Reservekoder og nødtilganger må oppbevares sikkert, testes og være tilgjengelige for minst to betrodde personer. En nødbruker skal ikke brukes i det daglige.

Bygg tilgangsstyring inn i arbeidsforholdet

Den beste oppryddingen er den dere slipper å gjenta manuelt etter hver bemanningsendring. Tilgang til nettstedet bør inngå i rutinene for oppstart, rollebytte og avslutning.

Når noen starter

  • Opprett en personlig konto med riktig rolle.
  • Aktiver tofaktorautentisering før utvidede rettigheter gis.
  • Forklar hvordan passord og gjenopprettingskoder skal håndteres.
  • Registrer hvem som godkjente tilgangen og hvorfor den er nødvendig.

Når arbeidsoppgavene endres

  • Fjern tidligere rettigheter før nye legges til.
  • Vurder tidsbegrenset tilgang for prosjekter og vikariater.
  • Kontroller tilganger hos eksterne leverandører når oppdraget endres.

Når noen slutter

  • Steng personlige kontoer til avtalt tidspunkt.
  • Trekk tilbake aktive økter og gjenopprettingsmuligheter.
  • Bytt delte hemmeligheter personen kan ha kjent til.
  • Overfør eierskap til integrasjoner, domener og tekniske kontoer.
  • Bevar nødvendig innhold uten å la kontoen forbli innloggingsklar.

Å bare slette WordPress-brukeren er ikke nok. Personen kan fortsatt ha tilgang via webhotellet, en ekstern identitetskonto, kodearkivet eller e-postadressen som mottar passordnullstilling.

Følg med på endringer i privilegier

Tilgangsrevisjonen viser situasjonen på ett tidspunkt. Overvåking skal fange opp det som skjer mellom revisjonene. Prioriter varsler om nye administratorer, endring av roller, mange mislykkede innlogginger, deaktivering av sikkerhetsfunksjoner og innlogging fra uventede forhold.

Et varsel har liten verdi uten en mottaker og en avtalt reaksjon. Bestem hvem som undersøker hendelsen, hvor raskt det skal skje, og hvordan en konto sperres dersom aktiviteten ikke kan forklares. Loggene må være tilgjengelige også hvis selve nettstedet blir kompromittert.

Hold dessuten WordPress, temaer og programtillegg oppdatert. En ubrukt administratorkonto og en sårbar utvidelse er to forskjellige problemer, men kombinasjonen kan gjøre konsekvensene større. Etter større oppdateringer bør dere kontrollere at roller, tofaktorautentisering, integrasjoner og logging fortsatt fungerer som planlagt.

Begrens tilgangen til backup

Backup er siste sikkerhetsnett ved feil, angrep eller uønskede endringer. Derfor bør ikke alle WordPress-administratorer automatisk ha rett til å slette eller endre sikkerhetskopiene. En angriper med full administratortilgang kan ellers ramme både nettstedet og gjenopprettingsmuligheten.

Skill om mulig mellom daglig nettstedadministrasjon og kontroll over backup. Dokumenter hvem som kan starte en gjenoppretting, hvem som godkjenner den, og hvordan tilgangen fungerer dersom produksjonsmiljøet er utilgjengelig. Testen av backup bør også kontrollere at nødvendige nøkler og kontoer faktisk er tilgjengelige i en krisesituasjon.

Gjennomfør revisjonen med faste intervaller

For de fleste virksomheter er det fornuftig å gjennomgå tilganger flere ganger i året og i tillegg ved større endringer. Nettsteder med nettbutikk, personopplysninger, mange redaktører eller hyppig bruk av konsulenter kan trenge tettere oppfølging.

Avslutt hver revisjon med en kort beslutningslogg:

  • hvilke kontoer og nøkler som ble fjernet
  • hvilke roller som ble redusert
  • hvilke unntak som ble godkjent, av hvem og hvor lenge
  • hvilke mangler som må utbedres
  • dato og ansvarlig for neste gjennomgang

Resultatet skal ikke være et omfattende dokument som raskt blir utdatert. En enkel, oppdatert oversikt med tydelig eierskap er mer verdifull enn en detaljert rapport ingen bruker.

Et godt sluttpunkt: Ingen ukjente nøkler

En vellykket tilgangsrevisjon betyr ikke at færrest mulig skal kunne arbeide med nettstedet. Den betyr at alle tilganger er nødvendige, personlige eller tydelig tekniske, riktig avgrenset og mulig å trekke tilbake.

Når virksomheten vet hvem som har nøklene, blir både daglig drift og hendelseshåndtering enklere. Dere kan oppdatere tryggere, undersøke avvik raskere og gjenopprette nettstedet uten å være avhengige av en ukjent konto eller en tidligere leverandør.