Röviden: Az admin hozzáférések kétfaktoros hitelesítése gondoskodik arról, hogy egy ellopott vagy kitalált jelszó önmagában ne legyen elég. Mindenhol érvényesnek kell lennie, ahol valaki módosíthatja a weboldalát vagy a szerverét: CMS, tárhely, panel, SSH, domain, DNS és az adminok postafiókjai. A beállítás mellett ugyanolyan fontosak a vészkódok és egy világos szabály arról, hogy ki mihez kap saját hozzáférést.
Miért nem elég a jelszó az adminoknak
A jelszavak sokféle úton vesznek el: adathalász levelek, egy munkaállomáson lévő kártékony szoftver, más szolgáltatásoknál bekövetkezett adatszivárgások vagy egyszerűen az újrahasználat miatt. Az automatizált támadások megszakítás nélkül próbálgatják az ellopott hozzáférési adatokat az ismert bejelentkezési oldalakon.
Egy második faktorral a támadónak ezen felül olyasmire is szüksége van, amivel csak a jogosult felhasználó rendelkezik, például egy authenticator alkalmazással ellátott okostelefonra vagy egy biztonsági kulcsra. Ez jelentősen megemeli a mércét, különösen a messzemenő jogokkal rendelkező fiókoknál.
A vezetőség számára egy elhatárolás fontos: a kétfaktoros bejelentkezés a hozzáféréseket védi, nem a mögöttük lévő szoftvert. Egy olyan rést, mint a PHP2Shell, amely bejelentkezés nélküli kódfuttatást tesz lehetővé, ez nem zár le. Mindkettő összetartozik: naprakész szoftver és jól védett hozzáférések.
Mely kétfaktoros eljárások alkalmasak
Az eljárások a biztonságban és a kezelési kényelemben különböznek. Admin fiókokhoz legalább authenticator alkalmazásokat használjon, különösen kritikus hozzáférésekhez biztonsági kulcsokat vagy passkey-ket.
| Eljárás | Védelem az adathalászat ellen | Alkalmasság adminoknak |
|---|---|---|
| SMS-kód | csekély | csak átmenetként |
| Authenticator alkalmazás (TOTP) | közepes | jó szabvány |
| Push-megerősítés | közepes, kifárasztásos támadásokra érzékeny | számegyeztetéssel alkalmas |
| Biztonsági kulcs vagy passkey (FIDO2/WebAuthn) | magas | kritikus hozzáférésekhez ajánlott |
| SSH-kulcs jelmondattal | magas | szabvány a szerverhozzáférésekhez |
Egy alkalmazásból származó egyszeri kódokat egy megtévesztően valódi adathalász oldalon el lehet fogni, és azonnal újra felhasználni. A FIDO2-eljárások ezzel szemben ellenőrzik az oldal címét, és hamis oldalon nem működnek. Ezért ők a legjobb választás az olyan adminoknak, akik sok rendszerhez férnek hozzá.
Kétfaktoros hitelesítés admin hozzáférésekhez: a teljes lista
A támadók a leggyengébb hozzáférést keresik. Ezért menjen végig az összes helyen, ahol valaki módosíthatja a weboldalát, a szerverét vagy a domainjét:
- CMS és webshop-backend: A WordPress, a Shopware, a TYPO3 és mások a magban vagy gondozott bővítményeken keresztül kínálnak kétfaktoros bejelentkezést. Hogy melyik változat ajánlott, azt a gyártó dokumentációja tartalmazza.
- Tárhely-ügyfélfiók: Aki ide bejut, gyakran visszaállíthat jelszavakat, letölthet mentéseket vagy újratelepítheti a szervert.
- Szerverpanel, mint a Plesk vagy a cPanel, ha van.
- SSH és SFTP: kulcs jelszó helyett, lásd a következő szakaszt.
- Domain-regisztrátor és DNS: Egy megváltoztatott DNS-beállítás átirányítja a látogatóit és a leveleit, anélkül hogy a szerver érintett lenne.
- Az adminok e-mail-postafiókjai: Rajtuk keresztül fut majdnem az összes többi szolgáltatás jelszó-visszaállítása.
- Kódtároló és deployment: Aki ott írhat, kártékony kódot gördíthet ki.
- CDN, WAF, Google Search Console és fizetési szolgáltatók.
Minden bejegyzéshez rögzítse, ki fér hozzá, aktív-e a második faktor, és hol vannak a helyreállítási kódok. Ez a lista egyben a vészhelyzeti terve fontos része, mert egy incidens után éppen ezeket a hozzáféréseket kell rövid idő alatt ellenőrizni és megújítani.
SSH: kulcs jelszó helyett
A szerverhozzáférések esetén az SSH-kulccsal való bejelentkezés a szokásos erős védelem. A privát kulcs az admin eszközén van, és jelmondattal védett; különösen védendő szervereknél hardveres kulcson is lehet. Ha a kulcsos bejelentkezés minden adminnak be van állítva és tesztelve van, kapcsolja ki a jelszavas bejelentkezést:
# /etc/ssh/sshd_config (részlet)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# A konfiguráció ellenőrzése a szolgáltatás újratöltése előtt
sshd -t && systemctl reload ssh # RHEL-rendszereken: sshd
Az átállításkor hagyjon nyitva egy meglévő munkamenetet, és a bejelentkezést tesztelje egy második ablakban. Így hiba esetén nem zárja ki magát. Minden admin saját kulcsot kap; egy egész csapat közös kulcsait az egyes személyek kilépésekor nem lehet szabályosan visszavonni. További alapokat a Root szerver és vServer saját védelme ír le.
Vészhozzáférés és helyreállítási kódok
Egy jó bevezetés beleszámolja a kiesést is. Az okostelefonok elvesznek, a munkatársak elhagyják a vállalkozást, a biztonsági kulcsok tönkremennek. Terv nélkül ilyenkor a rossz pillanatban senki sem áll rendelkezésre hozzáféréssel.
Minden kritikus fiókhoz regisztráljon két faktort, például egy biztonsági kulcsot az irodában és egy authenticator alkalmazást, és a helyreállítási kódokat a jelszótól elkülönítve őrizze.
További bevált szabályok:
- Személyes fiókok a közösen használt admin bejelentkezések helyett, hogy a módosítások követhetők legyenek.
- Egy dokumentált vészhozzáférés elkülönítve őrzött hozzáférési adatokkal, amelynek használata feltűnik és naplózódik.
- A munkatársak vagy szolgáltatók kilépésekor az összes hozzáférést és kulcsot ugyanazon a napon vonja vissza.
- Egy biztonsági incidens után ne csak a jelszavakat, hanem a regisztrált faktorokat és az aktív munkameneteket is ellenőrizze.
A csapatban való bevezetésnél egy világos menet vált be. Kezdje azokkal a fiókokkal, amelyek a legnagyobb kárt okozhatják: tárhely, domain, DNS és az adminok e-mail-postafiókjai. Utána következnek a szerverek, a CMS és a szolgáltatások. Rögzítsen egy határnapot, amelytől kezdve a második faktor nélküli bejelentkezések már nem lehetségesek, és előtte gondoskodjon arról, hogy minden érintett be legyen állítva.
Magyarázza el röviden a csapatnak, miért szükséges az átállás, és hogyan működik a mindennapokban. Egy egyoldalas útmutató képernyőképekkel jelentősen csökkenti a visszakérdezéseket. A külső szolgáltatók és ügynökségek közös bejelentkezés helyett saját, személyes hozzáféréseket kapjanak második faktorral, hogy a hozzáférések hozzárendelhetők maradjanak, és a projekt végén szabályosan visszavonhatók legyenek.
Hogyan védheti a bejelentkezési oldalakat ezen felül az automatizált próbálkozások ellen, azt az Admin bejelentkezések védelme brute force ellen útmutató írja le.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt készítünk egy teljes listát az összes admin hozzáférésről, és megmutatjuk, hol hiányzik a második faktor.
- A szerverhozzáféréseket SSH-kulcsra állítjuk át, és a szerver-keményítés keretében ellenőrzötten kikapcsoljuk a jelszavas bejelentkezéseket.
- Úgy dokumentáljuk a vészhozzáféréseket és a helyreállítási utakat, hogy éles helyzetben működjenek.
- A biztonsági karbantartási szerződésben rendszeresen ellenőrizzük a hozzáféréseket, és eltávolítjuk az árván maradt fiókokat.
Gyakori kérdések
Melyik kétfaktoros eljárás a legbiztonságosabb?
A FIDO2 szabvány szerinti hardveres biztonsági kulcsok és passkey-k különösen ellenállónak számítanak az adathalászattal szemben, mert a valódi címhez vannak kötve. Az egyszeri kódokat használó authenticator alkalmazások jó szabványt jelentenek. Az SMS jobb a semminél, de a leggyengébb változat.
Mi történik, ha elveszik az authenticator alkalmazást tartalmazó okostelefon?
Erre vannak a helyreállítási kódok, amelyeket a beállításkor megjelenítenek. Biztonságosan kell őrizni őket, például széfben vagy védett jelszókezelőben. Emellett legalább egy második adminnak is vissza kell tudnia állítani a hozzáférést.
Véd a kétfaktoros bejelentkezés a PHP2Shell ellen is?
Nem. A PHP2Shell bejelentkezés nélküli kódfuttatást tesz lehetővé, a bejelentkezést ilyenkor egyáltalán nem használják. A PHP2Shell ellen csak a javított PHP-verzióra való frissítés és az összes worker újraindítása segít. A kétfaktoros bejelentkezés az ellopott vagy kitalált jelszavak ellen véd.
Elég a kétfaktoros bejelentkezés a CMS-ben?
Nem, a támadó a leggyengébb hozzáférést választja. A tárhelyfiókot, a szerverpanelt, az SSH-t, a domainkezelést, a DNS-t és az adminok e-mail-postafiókjait ugyanúgy védeni kell, különben a CMS védelme megkerülhető.