# Opsæt tofaktor-godkendelse til admin-adgange

> Tofaktor-godkendelse for admins: egnede metoder, alle vigtige adgange fra CMS til SSH, nødkoder og en ren indførelse i teamet.

Kilde: https://phpsos.de/da/ratgeber/zwei-faktor-admin/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Tofaktor-godkendelse til admin-adgange sørger for, at en stjålet eller gættet adgangskode alene ikke er nok. Den skal gælde overalt, hvor nogen kan ændre jeres website eller server: CMS, hosting, panel, SSH, domæne, DNS og adminernes postkasser. Lige så vigtige som opsætningen er nødkoder og en klar regel om, hvem der har en egen adgang til hvad.

## Hvorfor adgangskoder alene ikke er nok for admins

Adgangskoder går tabt på mange måder: gennem phishing-mails, skadelig software på en arbejdscomputer, datalæk hos andre tjenester eller blot ved genbrug. Automatiserede angreb afprøver uafbrudt stjålne adgangsdata mod kendte loginsider.

Med en anden faktor har en angriber desuden brug for noget, som kun den berettigede bruger besidder, f.eks. en smartphone med authenticator-app eller en sikkerhedsnøgle. Det hæver tærsklen betydeligt, især ved konti med vidtgående rettigheder.

For ledelsen er en afgrænsning vigtig: Tofaktor-login beskytter adgange, ikke softwaren bagved. En sårbarhed som PHP2Shell, der muliggør kodekørsel uden login, bliver ikke lukket af det. Begge dele hører sammen: aktuel software og godt beskyttede adgange.

## Hvilke tofaktor-metoder der egner sig

Metoderne adskiller sig i sikkerhed og betjeningskomfort. Til admin-konti bør I mindst bruge authenticator-apps, til særligt kritiske adgange sikkerhedsnøgler eller passkeys.

| Metode | Beskyttelse mod phishing | Egnethed for admins |
|---|---|---|
| SMS-kode | lav | kun som overgang |
| Authenticator-app (TOTP) | middel | god standard |
| Push-bekræftelse | middel, modtagelig for udmattelsesangreb | egnet med nummerafstemning |
| Sikkerhedsnøgle eller passkey (FIDO2/WebAuthn) | høj | anbefalet til kritiske adgange |
| SSH-nøgle med adgangsfrase | høj | standard for serveradgange |

Engangskoder fra en app kan opsnappes på en en forbløffende ægte phishing-side og straks genbruges. FIDO2-metoder kontrollerer derimod sidens adresse og virker ikke på en forfalsket side. Det er grunden til, at de er det bedste valg for admins med adgang til mange systemer.

## Tofaktor-godkendelse til admin-adgange: den fuldstændige liste

Angribere vælger den svageste adgang. Gå derfor alle steder igennem, hvor nogen kan ændre jeres website, jeres server eller jeres domæne:

- **CMS og shop-backend:** WordPress, Shopware, TYPO3 og andre tilbyder tofaktor-login i kernen eller via vedligeholdte udvidelser. Hvilken variant der anbefales, står i producentens dokumentation.
- **Hostingens kundekonto:** Den, der kommer ind her, kan ofte nulstille adgangskoder, downloade sikkerhedskopier eller geninstallere serveren.
- **Serverpanel** som Plesk eller cPanel, hvis det findes.
- **SSH og SFTP:** nøgle i stedet for adgangskode, se næste afsnit.
- **Domæneregistrator og DNS:** En ændret DNS-indstilling omdirigerer jeres besøgende og mails, uden at serveren er berørt.
- **Adminernes e-mailpostkasser:** Via dem kører nulstillinger af adgangskoder til næsten alle andre tjenester.
- **Kode-repository og deployment:** Den, der må skrive dér, kan udrulle skadelig kode.
- **CDN, WAF, Google Search Console og betalingsudbydere.**

Notér for hver post, hvem der har adgang, om den anden faktor er aktiv, og hvor genoprettelseskoderne ligger. Denne liste er samtidig en vigtig del af jeres nødplan, for efter en hændelse skal netop disse adgange kontrolleres og fornyes på kort tid.

## SSH: nøgle i stedet for adgangskode

Til serveradgange er login med SSH-nøgle den sædvanlige stærke beskyttelse. Den private nøgle ligger på adminens enhed og er beskyttet med en adgangsfrase; ved særligt beskyttelsesværdige servere kan den ligge på en hardwarenøgle. Er nøglelogin opsat og testet for alle admins, slår I adgangskodelogin fra:

```text
# /etc/ssh/sshd_config (uddrag)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
```

```bash
# Kontrollér konfigurationen, før tjenesten genindlæses
sshd -t && systemctl reload ssh   # under RHEL-systemer: sshd
```

Lad ved omstillingen en eksisterende session stå åben, og test loginet i et andet vindue. Så låser I jer ikke ude ved en fejl. Hver admin får en egen nøgle; fælles nøgler til et helt team kan ikke fratages rent, når enkelte personer forlader virksomheden. Yderligere grundlag beskriver [Sikr root-server og vServer selv](https://phpsos.de/da/server/root-server-vserver/).

## Nødadgang og genoprettelseskoder

En god indførelse planlægger udfaldet med. Smartphones går tabt, medarbejdere forlader virksomheden, sikkerhedsnøgler går i stykker. Uden plan står der så ingen med adgang klar i det forkerte øjeblik.

> **Tip:**
> Registrér for hver kritisk konto to faktorer, f.eks. en sikkerhedsnøgle på kontoret og en authenticator-app, og opbevar genoprettelseskoderne adskilt fra adgangskoden.

Yderligere regler, der har vist sit værd:

- Personlige konti i stedet for delt brugte admin-logins, så ændringer kan spores.
- En dokumenteret nødadgang med adskilt opbevarede adgangsdata, hvis brug falder i øjnene og logges.
- Når medarbejdere eller tjenesteudbydere forlader, fratages alle adgange og nøgler samme dag.
- Efter en sikkerhedshændelse kontrolleres ikke kun adgangskoder, men også registrerede faktorer og aktive sessioner.

Ved indførelsen i teamet har et klart forløb vist sit værd. Begynd med de konti, der kan forvolde størst skade: hosting, domæne, DNS og adminernes e-mailpostkasser. Derefter følger servere, CMS og tjenester. Fastlæg en skæringsdato, fra hvilken logins uden anden faktor ikke længere er mulige, og sørg forinden for, at alle involverede er sat op.

Forklar kort teamet, hvorfor omstillingen er nødvendig, og hvordan den fungerer i hverdagen. En enkeltsidet vejledning med skærmbilleder sænker antallet af spørgsmål tydeligt. Eksterne tjenesteudbydere og bureauer bør have egne, personlige adgange med anden faktor i stedet for et fælles login, så adgange forbliver tilordnelige og kan fratages rent efter projektets afslutning.

Hvordan I yderligere beskytter loginsider mod automatiserede forsøg, står i vejledningen [Beskyt admin-logins mod brute force](https://phpsos.de/da/ratgeber/brute-force-login-schutz/).

## Hvordan hjælper PHP SOS konkret?

- Vi udarbejder sammen med jer en fuldstændig liste over alle admin-adgange og viser, hvor den anden faktor mangler.
- Vi omstiller serveradgange til SSH-nøgler og slår adgangskodelogin fra kontrolleret inden for rammerne af [serverhærdningen](https://phpsos.de/da/leistungen/server-haertung/).
- Vi dokumenterer nødadgange og genoprettelsesveje, så de fungerer i en nødsituation.
- I [sikkerhedsvedligeholdelsesaftalen](https://phpsos.de/da/leistungen/security-wartungsvertrag/) kontrollerer vi adgange regelmæssigt og fjerner forladte konti.


## Ofte stillede spørgsmål

**Hvilken tofaktor-metode er den sikreste?**  
Hardware-sikkerhedsnøgler og passkeys efter FIDO2-standarden regnes for særligt modstandsdygtige over for phishing, fordi de er bundet til den rigtige adresse. Authenticator-apps med engangskoder er en god standard. SMS er bedre end intet, men den svageste variant.

**Hvad sker der, hvis smartphonen med authenticator-appen går tabt?**  
Dertil findes genoprettelseskoder, som vises ved opsætningen. De skal opbevares sikkert, f.eks. i pengeskab eller i en beskyttet adgangskodemanager. Desuden bør mindst en anden admin kunne nulstille adgangen.

**Beskytter tofaktor-login også mod PHP2Shell?**  
Nej. PHP2Shell muliggør kodekørsel uden login, loginet bruges slet ikke. Mod PHP2Shell hjælper kun opdateringen til en rettet PHP-version med genstart af alle workere. Tofaktor-login beskytter mod stjålne eller gættede adgangskoder.

**Er tofaktor-login i CMS'et nok?**  
Nej, en angriber vælger den svageste adgang. Hostingkonto, serverpanel, SSH, domæneadministration, DNS og adminernes e-mailpostkasser skal være beskyttet lige så meget, ellers kan CMS-beskyttelsen omgås.

## Kilder

- [BSI (det tyske forbundskontor for informationssikkerhed): tofaktor-autentificering](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series (Multifactor Authentication)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)