Kort gezegd: Tweefactorauthenticatie voor beheertoegangen zorgt ervoor dat een gestolen of geraden wachtwoord alleen niet volstaat. Ze moet overal gelden waar iemand uw website of server kan wijzigen: CMS, hosting, paneel, SSH, domein, DNS en de postvakken van de beheerders. Even belangrijk als het instellen zijn noodcodes en een duidelijke regel wie waarvoor een eigen toegang heeft.
Waarom wachtwoorden alleen voor beheerders niet volstaan
Wachtwoorden gaan op veel manieren verloren: door phishingmails, schadelijke software op een werkcomputer, datalekken bij andere diensten of simpelweg door hergebruik. Geautomatiseerde aanvallen proberen gestolen toegangsgegevens onophoudelijk uit tegen bekende inlogpagina's.
Met een tweede factor heeft een aanvaller bovendien iets nodig dat alleen de bevoegde gebruiker bezit, bijvoorbeeld een smartphone met authenticator-app of een beveiligingssleutel. Dat verhoogt de drempel aanzienlijk, vooral bij accounts met verstrekkende rechten.
Voor de directie is een afbakening belangrijk: tweefactorauthenticatie beschermt toegangen, niet de software erachter. Een kwetsbaarheid als PHP2Shell, die code-uitvoering zonder aanmelding mogelijk maakt, wordt daardoor niet gedicht. Beide horen bij elkaar: actuele software en goed beschermde toegangen.
Welke tweefactormethoden geschikt zijn
De methoden verschillen in veiligheid en gebruiksgemak. Voor beheerdersaccounts moet u minstens authenticator-apps inzetten, voor bijzonder kritieke toegangen beveiligingssleutels of passkeys.
| Methode | Bescherming tegen phishing | Geschiktheid voor beheerders |
|---|---|---|
| Sms-code | gering | alleen als overgang |
| Authenticator-app (TOTP) | gemiddeld | goede standaard |
| Pushbevestiging | gemiddeld, gevoelig voor vermoeidheidsaanvallen | met nummervergelijking geschikt |
| Beveiligingssleutel of passkey (FIDO2/WebAuthn) | hoog | aanbevolen voor kritieke toegangen |
| SSH-sleutel met wachtzin | hoog | standaard voor servertoegang |
Eenmalige codes uit een app kunnen op een bedrieglijk echte phishingpagina worden onderschept en meteen worden hergebruikt. FIDO2-methoden controleren daarentegen het adres van de pagina en werken niet op een vervalste pagina. Dat is de reden waarom ze voor beheerders met toegang tot veel systemen de beste keuze zijn.
Tweefactorauthenticatie voor beheertoegangen: de volledige lijst
Aanvallers zoeken de zwakste toegang. Loop daarom alle plekken langs waar iemand uw website, server of domein kan wijzigen:
- CMS en webshopbackend: WordPress, Shopware, TYPO3 en andere bieden tweefactorauthenticatie in de kern of via onderhouden extensies. Welke variant wordt aanbevolen, staat in de documentatie van de fabrikant.
- Klantaccount bij de hoster: Wie hier binnenkomt, kan vaak wachtwoorden resetten, back-ups downloaden of de server opnieuw installeren.
- Serverpaneel zoals Plesk of cPanel, voor zover aanwezig.
- SSH en SFTP: Sleutel in plaats van wachtwoord, zie de volgende paragraaf.
- Domeinregistrar en DNS: Een gewijzigde DNS-instelling leidt uw bezoekers en mails om, zonder dat de server is getroffen.
- E-mailpostvakken van de beheerders: Via hen lopen wachtwoordherstelacties voor bijna alle andere diensten.
- Coderepository en deployment: Wie daar mag schrijven, kan schadelijke code uitrollen.
- CDN, WAF, Google Search Console en betaalaanbieders.
Leg voor elke vermelding vast wie toegang heeft, of de tweede factor actief is en waar de herstelcodes liggen. Deze lijst is tegelijk een belangrijk onderdeel van uw noodplan, want na een incident moeten juist deze toegangen in korte tijd worden gecontroleerd en vernieuwd.
SSH: sleutel in plaats van wachtwoord
Voor servertoegang is aanmelding met een SSH-sleutel de gebruikelijke sterke bescherming. De privésleutel staat op het apparaat van de beheerder en is beschermd met een wachtzin; bij bijzonder te beschermen servers kan hij op een hardwaresleutel staan. Is de sleutelaanmelding voor alle beheerders ingesteld en getest, schakel dan de wachtwoordaanmelding uit:
# /etc/ssh/sshd_config (fragment)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Configuratie controleren voordat de dienst opnieuw wordt geladen
sshd -t && systemctl reload ssh # onder RHEL-systemen: sshd
Laat bij het omschakelen een bestaande sessie open en test de aanmelding in een tweede venster. Zo sluit u uzelf bij een fout niet buiten. Elke beheerder krijgt een eigen sleutel; gemeenschappelijke sleutels voor een heel team zijn bij het vertrek van afzonderlijke personen niet netjes in te trekken. Verdere basisprincipes beschrijft Rootserver en vServer zelf beveiligen.
Noodtoegang en herstelcodes
Een goede invoering plant de uitval in. Smartphones raken zoek, medewerkers verlaten het bedrijf, beveiligingssleutels gaan kapot. Zonder plan staat op het verkeerde moment niemand met toegang klaar.
Registreer voor elk kritiek account twee factoren, bijvoorbeeld een beveiligingssleutel op kantoor en een authenticator-app, en bewaar de herstelcodes gescheiden van het wachtwoord.
Verdere regels die zich hebben bewezen:
- Persoonlijke accounts in plaats van gedeelde beheerlogins, zodat wijzigingen traceerbaar zijn.
- Een gedocumenteerde noodtoegang met gescheiden bewaarde toegangsgegevens, waarvan het gebruik opvalt en wordt gelogd.
- Bij het vertrek van medewerkers of dienstverleners alle toegangen en sleutels dezelfde dag intrekken.
- Na een beveiligingsincident niet alleen wachtwoorden, maar ook geregistreerde factoren en actieve sessies controleren.
Bij de invoering in het team heeft een duidelijk verloop zich bewezen. Begin met de accounts die de meeste schade kunnen aanrichten: hosting, domein, DNS en de e-mailpostvakken van de beheerders. Daarna volgen servers, CMS en diensten. Bepaal een peildatum vanaf wanneer aanmeldingen zonder tweede factor niet meer mogelijk zijn, en zorg ervoor dat alle betrokkenen tevoren zijn ingesteld.
Leg het team kort uit waarom de omschakeling nodig is en hoe ze in het dagelijks gebruik werkt. Een handleiding van één pagina met schermafbeeldingen verlaagt het aantal vragen aanzienlijk. Externe dienstverleners en bureaus moeten eigen, persoonlijke toegangen met tweede factor krijgen in plaats van een gedeelde login, zodat toegang toewijsbaar blijft en na afloop van het project netjes is in te trekken.
Hoe u aanmeldpagina's aanvullend beschermt tegen geautomatiseerde pogingen, staat in de gids Beheerlogins beschermen tegen brute force.
Hoe helpt PHP SOS concreet?
- Samen met u maken we een volledige lijst van alle beheertoegangen en tonen we waar de tweede factor ontbreekt.
- We zetten servertoegangen om naar SSH-sleutels en schakelen wachtwoordaanmeldingen binnen de serververharding gecontroleerd uit.
- We documenteren noodtoegangen en herstelroutes zo dat ze in een noodgeval werken.
- In het beveiligingsonderhoudscontract controleren we toegangen regelmatig en verwijderen we verweesde accounts.
Veelgestelde vragen
Welke tweefactormethode is het veiligst?
Hardwarebeveiligingssleutels en passkeys volgens de FIDO2-standaard gelden als bijzonder bestand tegen phishing, omdat ze aan het echte adres zijn gebonden. Authenticator-apps met eenmalige codes zijn een goede standaard. Sms is beter dan niets, maar de zwakste variant.
Wat gebeurt er als de smartphone met de authenticator-app verloren gaat?
Daarvoor zijn er herstelcodes die bij het instellen worden getoond. Ze horen veilig te worden bewaard, bijvoorbeeld in de kluis of in een beschermde wachtwoordmanager. Bovendien moet minstens een tweede beheerder de toegang kunnen resetten.
Beschermt tweefactorauthenticatie ook tegen PHP2Shell?
Nee. PHP2Shell maakt code-uitvoering zonder aanmelding mogelijk, de login wordt daarbij helemaal niet gebruikt. Tegen PHP2Shell helpt alleen de update naar een verholpen PHP-versie met herstart van alle workers. Tweefactorauthenticatie beschermt tegen gestolen of geraden wachtwoorden.
Volstaat tweefactorauthenticatie in het CMS?
Nee, een aanvaller kiest de zwakste toegang. Hostingaccount, serverpaneel, SSH, domeinbeheer, DNS en de e-mailpostvakken van de beheerders moeten even goed zijn beschermd, anders is de CMS-bescherming te omzeilen.