Kort sagt: Tvåfaktorsautentisering för adminåtkomst ser till att ett stulet eller gissat lösenord ensamt inte räcker. Den måste gälla överallt där någon kan ändra er webbplats eller server: CMS, hosting, panel, SSH, domän, DNS och administratörernas postfack. Lika viktiga som installationen är nödkoder och en tydlig regel för vem som har en egen åtkomst till vad.
Varför lösenord ensamma inte räcker för administratörer
Lösenord går förlorade på många sätt: genom nätfiskemejl, skadlig programvara på en arbetsdator, dataläckor hos andra tjänster eller helt enkelt genom återanvändning. Automatiserade angrepp provar oavbrutet stulna inloggningsuppgifter mot kända inloggningssidor.
Med en andra faktor behöver en angripare dessutom något som bara den behöriga användaren har, till exempel en smartphone med autentiseringsapp eller en säkerhetsnyckel. Det höjer tröskeln avsevärt, särskilt för konton med vittgående rättigheter.
För ledningen är en avgränsning viktig: Tvåfaktorsinloggning skyddar åtkomster, inte programvaran bakom. En sårbarhet som PHP2Shell, som tillåter kodkörning utan inloggning, stängs inte därmed. Båda hör ihop: aktuell programvara och väl skyddade åtkomster.
Vilka tvåfaktorsmetoder som passar
Metoderna skiljer sig i säkerhet och användarvänlighet. För adminkonton bör ni använda minst autentiseringsappar, för särskilt kritiska åtkomster säkerhetsnycklar eller passkeys.
| Metod | Skydd mot nätfiske | Lämplighet för administratörer |
|---|---|---|
| SMS-kod | lågt | bara som övergång |
| Autentiseringsapp (TOTP) | medel | bra standard |
| Push-bekräftelse | medel, känslig för utmattningsangrepp | lämplig med nummerjämförelse |
| Säkerhetsnyckel eller passkey (FIDO2/WebAuthn) | högt | rekommenderas för kritiska åtkomster |
| SSH-nyckel med lösenfras | högt | standard för serveråtkomst |
Engångskoder från en app kan snappas upp på en bedrägligt äkta nätfiskesida och användas direkt. FIDO2-metoder kontrollerar däremot sidans adress och fungerar inte på en förfalskad sida. Det är skälet till att de är det bästa valet för administratörer med åtkomst till många system.
Tvåfaktorsautentisering för adminåtkomst: den fullständiga listan
Angripare väljer den svagaste åtkomsten. Gå därför igenom alla ställen där någon kan ändra er webbplats, er server eller er domän:
- CMS och butiksbackend: WordPress, Shopware, TYPO3 och andra erbjuder tvåfaktorsinloggning i kärnan eller via underhållna tillägg. Vilken variant som rekommenderas står i tillverkarens dokumentation.
- Hostingkundkonto: Den som kommer in här kan ofta återställa lösenord, ladda ned säkerhetskopior eller installera om servern.
- Serverpanel som Plesk eller cPanel, i den mån sådan finns.
- SSH och SFTP: Nyckel i stället för lösenord, se nästa avsnitt.
- Domänregistrator och DNS: En ändrad DNS-inställning leder om era besökare och e-post utan att servern berörs.
- Administratörernas e-postkonton: Via dem går lösenordsåterställningar för nästan alla andra tjänster.
- Kodförvar och deployment: Den som får skriva där kan rulla ut skadlig kod.
- CDN, WAF, Google Search Console och betalleverantörer.
Fastställ för varje post vem som har åtkomst, om den andra faktorn är aktiv och var återställningskoderna finns. Den listan är samtidigt en viktig del av er nödlägesplan, för efter en incident måste just de åtkomsterna kontrolleras och förnyas på kort tid.
SSH: nyckel i stället för lösenord
För serveråtkomst är inloggning med SSH-nyckel det vanliga starka skyddet. Den privata nyckeln ligger på administratörens enhet och skyddas av en lösenfras; på särskilt skyddsvärda servrar kan den ligga på en maskinvarunyckel. När nyckelinloggningen är införd och testad för alla administratörer stänger ni av lösenordsinloggningen:
# /etc/ssh/sshd_config (utdrag)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Kontrollera konfigurationen innan tjänsten laddas om
sshd -t && systemctl reload ssh # under RHEL-system: sshd
Låt vid omställningen en befintlig session vara öppen och testa inloggningen i ett andra fönster. Då låser ni inte ute er själva vid ett fel. Varje administratör får en egen nyckel; gemensamma nycklar för ett helt team går inte att dra in rent när enskilda personer slutar. Fler grunder beskriver Säkra root-servrar och vServers själv.
Nödåtkomst och återställningskoder
Ett bra införande planerar in bortfall. Smartphones försvinner, medarbetare lämnar företaget, säkerhetsnycklar går sönder. Utan plan står då ingen med åtkomst redo i fel ögonblick.
Registrera två faktorer för varje kritiskt konto, till exempel en säkerhetsnyckel på kontoret och en autentiseringsapp, och förvara återställningskoderna åtskilda från lösenordet.
Fler regler som har visat sig fungera:
- Personliga konton i stället för gemensamt använda adminkonton, så att ändringar går att följa.
- En dokumenterad nödåtkomst med åtskilt förvarade inloggningsuppgifter, vars användning syns och loggas.
- När medarbetare eller tjänsteleverantörer slutar, dra in alla åtkomster och nycklar samma dag.
- Efter en säkerhetsincident, kontrollera inte bara lösenord utan även registrerade faktorer och aktiva sessioner.
Vid införandet i teamet har ett tydligt förlopp visat sig fungera. Börja med de konton som kan göra störst skada: hosting, domän, DNS och administratörernas e-postkonton. Därefter följer server, CMS och tjänster. Fastställ ett stoppdatum från vilket inloggningar utan andra faktor inte längre är möjliga, och säkerställ i förväg att alla inblandade är uppsatta.
Förklara kort för teamet varför omställningen behövs och hur den fungerar i vardagen. En enkel anvisning med skärmbilder minskar följdfrågorna avsevärt. Externa tjänsteleverantörer och byråer bör få egna, personliga åtkomster med andra faktor i stället för en gemensam inloggning, så att åtkomster förblir spårbara och kan dras in rent efter projektets slut.
Hur ni dessutom skyddar inloggningssidor mot automatiserade försök står i guiden Skydda admininloggningar mot brute force.
Hur hjälper PHP SOS konkret?
- Vi upprättar tillsammans med er en fullständig lista över alla adminåtkomster och visar var den andra faktorn saknas.
- Vi ställer om serveråtkomster till SSH-nycklar och stänger av lösenordsinloggningar kontrollerat inom ramen för serverhärdningen.
- Vi dokumenterar nödåtkomster och återställningsvägar så att de fungerar när det är allvar.
- I säkerhetsunderhållsavtalet granskar vi åtkomster regelbundet och tar bort övergivna konton.
Vanliga frågor
Vilken tvåfaktorsmetod är säkrast?
Maskinvarubaserade säkerhetsnycklar och passkeys enligt FIDO2-standarden anses särskilt motståndskraftiga mot nätfiske, eftersom de är bundna till den riktiga adressen. Autentiseringsappar med engångskoder är en bra standard. SMS är bättre än ingenting men den svagaste varianten.
Vad händer om smartphonen med autentiseringsappen försvinner?
För det finns återställningskoder som visas vid installationen. De ska förvaras säkert, till exempel i kassaskåp eller i en skyddad lösenordshanterare. Dessutom bör minst en andra administratör kunna återställa åtkomsten.
Skyddar tvåfaktorsinloggning även mot PHP2Shell?
Nej. PHP2Shell tillåter kodkörning utan inloggning, inloggningen används då överhuvudtaget inte. Mot PHP2Shell hjälper bara uppdateringen till en åtgärdad PHP-version med omstart av alla workers. Tvåfaktorsinloggning skyddar mot stulna eller gissade lösenord.
Räcker tvåfaktorsinloggning i CMS:et?
Nej, en angripare väljer den svagaste åtkomsten. Hostingkonto, serverpanel, SSH, domänhantering, DNS och administratörernas e-postkonton måste skyddas lika väl, annars går CMS-skyddet att kringgå.