Adgangsoversigten: hvem har adgang til hvad – og hvorfor?

Kort svar: En adgangsoversigt er én tabel med et system pr. række – WordPress, hosting, domæne og DNS, mail, betaling, statistik og sociale kanaler – og fire kolonner: hvem har adgang, med hvilken rolle, hvorfor, og hvornår det sidst blev bekræftet. Før den efter tre principper: mindst nødvendige rettighed, personlige logins frem for delte og totrinslogin på alt vigtigt. Gennemgå den hvert kvartal, og luk adgange samme dag, et samarbejde slutter. Mange hackede sites bliver ikke brudt op – de bliver låst op med en gammel nøgle.

Fagligt gennemgået: 2. oktober 2026

Hvor mange personer og virksomheder kan lige nu logge ind i din WordPress, din DNS eller din betalingsgateway? Hvis svaret starter med “øh”, er denne guide til dig.

Hver glemt adgang er både et sikkerhedshul og et driftsproblem den dag, noget skal løses hurtigt. Oversigten tager omkring en time at lave og et kvarter i kvartalet at holde ved lige.

Hvorfor glemte adgange er farlige

Adgange har det med kun at vokse. Praktikanten fik redaktørrollen for tre år siden, det gamle bureau har stadig administratoradgang “for en sikkerheds skyld”, og freelancedesigneren kender FTP-koden, der aldrig blev skiftet.

Hver af dem er en angrebsvej, du ikke overvåger. Bliver deres mail eller kodeord kompromitteret, er det dit site, der bliver hacket. Lækkede kodeord fra andre tjenester bliver afprøvet automatisk mod alt, hvad angriberne kan finde.

Risikoen er også driftsmæssig og juridisk. Når ingen ved, hvem der kan hvad, kan ingen svare på GDPR-spørgsmålet “hvem har adgang til kundedata?”. Og når noget haster, går den første halve time med at finde ud af, hvem der overhovedet kan logge ind. Oversigten løser alle tre problemer: færre nøgler, kendte nøgler og et svar på skrift.

Tabellen: rækker og kolonner

Start med systemerne som rækker. En typisk liste for en lille virksomhed:

• WordPress (alle brugere med rolle)
• Hostingens kontrolpanel samt SFTP- og SSH-adgange
• Domæneregistrator og DNS
• Mailadministration
• Betalingsgateway og eventuelt fragtplatform
• Statistik, Search Console og annoncekonti
• Nyhedsbrevssystem og sociale kanaler
• Integrationer med API-nøgler, fx regnskab
• Password manageren selv

Udfyld derefter fire kolonner pr. adgang. Sådan kan det se ud (navnene er eksempler):

System	Hvem	Rolle	Hvorfor	Sidst bekræftet
WordPress	Anne Hansen	Administrator	Driver sitet	1. oktober
WordPress	Bureau, Jonas	Redaktør	Kampagnesider, til 1. december	1. oktober
Betalingsgateway	Bogholder, Lis	Læseadgang	Afstemning	1. oktober
DNS	Anne Hansen	Ejer	Domæne og records	1. oktober

• Hvem: et navn, aldrig “kontoret”.
• Rolle: brug systemets egne betegnelser, fx administrator, redaktør eller læseadgang.
• Hvorfor: en halv sætning, gerne med slutdato for midlertidige adgange.
• Sidst bekræftet: datoen fra seneste gennemgang.

Allerede første udfyldning finder ofte adgange, som ingen kan forklare. Luk dem med det samme, og notér det i ændringsloggen.

Vigtigt: Oversigten må aldrig indeholde kodeord – kun hvem og hvad. Kodeord hører til i en password manager. Gem tabellen sammen med driftsdokumentationen, så den også kan bruges af vikaren og ved revision.

De tre principper

Mindst nødvendige rettighed

Giv den rolle, arbejdet kræver – ikke den, der er nemmest. Skribenten er forfatter eller redaktør, ikke administrator. Bogholderen har læseadgang i gatewayen, ikke ejerskab. Og antallet af WordPress-administratorer kan tælles på én hånd med fingre til overs.

WordPress har som standard rollerne administrator, redaktør, forfatter, bidragyder og abonnent. WooCommerce tilføjer bl.a. en butiksrolle (Shop manager), der kan styre ordrer og produkter uden fuld administratoradgang. Brug den til medarbejdere, der kun skal ekspedere ordrer.

Personlige logins

Delte konti, fx “info@ er admin”, gør både revision og offboarding umulig. Når én person stopper, skal alle delte koder skiftes. Opret i stedet en bruger pr. person, så en adgang kan lukkes uden at røre de andres. Det giver også sporbarhed: du kan se, hvem der gjorde hvad.

Totrinslogin på alt, der kan gøre skade

Slå totrinslogin til på WordPress-administratorer, hosting, domæne og DNS, mail og betalingsgateway. Det stopper netop de angreb med lækkede kodeord, som glemte adgange inviterer til. Guiden om totrinslogin i WordPress viser opsætningen.

De tre principper er samtidig den praktiske halvdel af GDPR-arbejdet: adgangsstyring på skrift er en del af det, der kan dokumentere passende sikkerhedsforanstaltninger, hvis nogen spørger.

De skjulte adgange: nøgler, tokens og apps

Ikke alle adgange er en bruger med et kodeord. Nogle af de mest oversete ligger her:

• Applikationsadgangskoder (Application Passwords) i WordPress-brugerprofiler, som eksterne værktøjer bruger til REST API’et.
• WooCommerce REST API-nøgler til regnskab, fragt og lagerstyring.
• SSH-nøgler på hostingkontoen, fx fra en tidligere udvikler.
• Tredjepartsapps med adgang til mail, statistik eller sociale konti via “Log ind med …”.
• Webhooks og integrationer, der sender data ud af huset.

Giv dem en række i tabellen ligesom brugere: hvilket system, hvilken integration, hvilke rettigheder, og hvem der er ansvarlig. Nøgler, der ikke bruges, tilbagekaldes. Guiden om API-nøgler og mindste privilegium går i dybden.

Gennemgangen: et kvarter i kvartalet

Oversigten holder kun, hvis den gennemgås, og rytmen er allerede sat: et fast punkt i kvartalstjekket. Åbn tabellen, gå rækkerne igennem, og stil tre spørgsmål pr. adgang:

1. Bruges den stadig? Nej: luk den i dag.
2. Passer rollen stadig? En administrator, der kun læser, skal nedjusteres.
3. Passer virkeligheden med tabellen? Sammenlign med systemernes egne brugerlister. WordPress’ brugerliste og hostingpanelets adgange er facit; tabellen er kortet.

Opdatér “sidst bekræftet”, og skriv ændringerne i loggen. Der er to faste anledninger uden for rytmen: samme-dags-lukning, når nogen stopper, eller et samarbejde ophører – læg det i offboarding-tjeklisten, jf. guiden om ejerskab af domæne og hosting – og en ekstra runde efter enhver mistanke om kompromittering.

Når en administrator stopper, så husk også at overføre indholdet til en anden bruger, når kontoen slettes. WordPress spørger selv, hvad der skal ske med brugerens indlæg og sider.

I praksis: bureauer, vikarer og nødadgang

• Bureauet får sin egen navngivne bruger med den rolle, opgaven kræver, og en note om slutdato i tabellen (“kampagne til 1. december”) – aldrig jeres eget login.
• Vikaren får adgang via overdragelsespakken: oprettet før ferien, lukket eller nedjusteret efter.
• Nødadgangen: Har kun én person administratoradgang, er det også en risiko. Løs det med en ekstra administratorkonto, hvis kodeord ligger i password manageren med adgang for en medejer eller betroet person. Dokumentér den i tabellen, så den aldrig bliver en glemt bagdør.

Har du flere personer, der arbejder på sitet, giver guiden om adgangsstyring i teams flere detaljer om roller og deling uden fælles kodeord. Og med WordPress hosting hos Hostious kan du kontakte den danske support døgnet rundt, hvis du er i tvivl om, hvem der har adgang til hostingkontoen.

Læs også

• Hub: Driftshåndbogen
• Driftsdokumentation: den ene side, en vikar kan drive sitet fra
• Ferie, sygdom og exit: overdragelse af driften uden panik
• Adgangsstyring i teams: roller, 2FA og deling uden fælles kodeord
• Totrinslogin (2FA) i WordPress
• WordPress hosting hos Hostious – dansk support døgnet rundt og daglig backup

Ofte stillede spørgsmål om adgangsoversigter

Hvor ofte skal adgange revideres?

Et kvarter hvert kvartal som fast punkt i kvartalstjekket – plus samme-dags-lukning, når nogen stopper, og en ekstra runde ved mistanke om kompromittering.

Er delte logins okay, hvis vi kun er få?

Nej. Delte konti gør offboarding og sporbarhed umulig: stopper én, skal alt skiftes. Personlige brugere koster typisk ingenting og kan lukkes enkeltvis.

Hvad gør vi med det gamle bureaus adgang?

Luk den i dag, og notér det i ændringsloggen. Skal bureauet hjælpe igen senere, opretter du en ny, navngiven bruger på få minutter. En sovende administratorkonto er ikke praktisk – den er en risiko.

Skal kodeordene stå i adgangsoversigten?

Nej. Oversigten viser kun, hvem der har adgang til hvad, og hvorfor. Kodeord hører til i en password manager, så oversigten kan deles med vikarer og revision uden risiko.