Krótko: Uwierzytelnianie dwuskładnikowe dla dostępów administratora sprawia, że skradzione lub odgadnięte hasło samo nie wystarcza. Musi obowiązywać wszędzie, gdzie ktoś może zmieniać Państwa stronę lub serwer: CMS, hosting, panel, SSH, domena, DNS i skrzynki administratorów. Równie ważne jak konfiguracja są kody awaryjne i jasna zasada, kto do czego ma własny dostęp.
Dlaczego same hasła nie wystarczają administratorom
Hasła giną na wiele sposobów: przez wiadomości phishingowe, złośliwe oprogramowanie na komputerze roboczym, wycieki danych w innych usługach lub po prostu przez ponowne użycie. Zautomatyzowane ataki bez przerwy wypróbowują skradzione dane dostępowe na znanych stronach logowania.
Dzięki drugiemu składnikowi atakujący potrzebuje dodatkowo czegoś, co posiada tylko uprawniony użytkownik, na przykład smartfona z aplikacją uwierzytelniającą lub klucza bezpieczeństwa. Znacznie to podnosi poprzeczkę, zwłaszcza przy kontach z szerokimi uprawnieniami.
Dla zarządu ważne jest rozróżnienie: logowanie dwuskładnikowe chroni dostępy, a nie oprogramowanie, które za nimi stoi. Luka taka jak PHP2Shell, umożliwiająca wykonanie kodu bez logowania, nie zostaje przez to zamknięta. Jedno i drugie należy do siebie: aktualne oprogramowanie i dobrze chronione dostępy.
Jakie metody dwuskładnikowe się nadają
Metody różnią się bezpieczeństwem i wygodą obsługi. Dla kont administratorów powinni Państwo stosować co najmniej aplikacje uwierzytelniające, a dla szczególnie krytycznych dostępów klucze bezpieczeństwa lub passkeys.
| Metoda | Ochrona przed phishingiem | Przydatność dla adminów |
|---|---|---|
| Kod SMS | niska | tylko jako rozwiązanie przejściowe |
| Aplikacja uwierzytelniająca (TOTP) | średnia | dobry standard |
| Potwierdzenie push | średnia, podatne na ataki zmęczeniowe | odpowiednie z porównaniem numeru |
| Klucz bezpieczeństwa lub passkey (FIDO2/WebAuthn) | wysoka | zalecane dla krytycznych dostępów |
| Klucz SSH z hasłem (passphrase) | wysoka | standard dla dostępów do serwerów |
Kody jednorazowe z aplikacji mogą zostać przechwycone na łudząco prawdziwej stronie phishingowej i od razu użyte. Metody FIDO2 sprawdzają natomiast adres strony i na fałszywej stronie nie działają. To powód, dla którego są najlepszym wyborem dla administratorów z dostępem do wielu systemów.
Uwierzytelnianie dwuskładnikowe dla dostępów administratora: pełna lista
Atakujący szukają najsłabszego dostępu. Proszę więc przejść wszystkie miejsca, w których ktoś może zmieniać Państwa stronę, serwer lub domenę:
- CMS i panel sklepu: WordPress, Shopware, TYPO3 i inne oferują logowanie dwuskładnikowe w rdzeniu lub przez utrzymywane rozszerzenia. Który wariant jest zalecany, podaje dokumentacja producenta.
- Konto klienta u hostingu: kto się tu dostanie, często może resetować hasła, pobierać kopie zapasowe lub instalować serwer od nowa.
- Panel serwera taki jak Plesk lub cPanel, o ile istnieje.
- SSH i SFTP: klucz zamiast hasła, zob. następny rozdział.
- Rejestrator domeny i DNS: zmienione ustawienie DNS przekierowuje Państwa odwiedzających i pocztę, bez udziału serwera.
- Skrzynki e-mail administratorów: przez nie przechodzą resety haseł prawie wszystkich pozostałych usług.
- Repozytorium kodu i wdrażanie: kto może tam zapisywać, może rozsyłać złośliwy kod.
- CDN, WAF, Google Search Console i dostawcy płatności.
Dla każdego wpisu proszę ustalić, kto ma dostęp, czy drugi składnik jest aktywny i gdzie leżą kody odzyskiwania. Ta lista jest zarazem ważną częścią Państwa planu awaryjnego, ponieważ po incydencie dokładnie te dostępy trzeba w krótkim czasie sprawdzić i odnowić.
SSH: klucz zamiast hasła
Dla dostępów do serwerów logowanie kluczem SSH jest zwykłą mocną ochroną. Klucz prywatny leży na urządzeniu administratora i jest chroniony hasłem (passphrase); w szczególnie chronionych serwerach może znajdować się na kluczu sprzętowym. Gdy logowanie kluczem jest skonfigurowane i przetestowane dla wszystkich administratorów, wyłączają Państwo logowanie hasłem:
# /etc/ssh/sshd_config (fragment)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Sprawdź konfigurację, zanim usługa zostanie przeładowana
sshd -t && systemctl reload ssh # w systemach RHEL: sshd
Przy przestawianiu proszę zostawić istniejącą sesję otwartą i przetestować logowanie w drugim oknie. Dzięki temu w razie błędu nie zablokują się Państwo. Każdy administrator dostaje własny klucz; wspólnych kluczy dla całego zespołu nie da się czysto odebrać, gdy odchodzą pojedyncze osoby. Dalsze podstawy opisuje Samodzielne zabezpieczanie serwerów root i vServerów.
Dostęp awaryjny i kody odzyskiwania
Dobre wdrożenie uwzględnia awarię. Smartfony giną, pracownicy opuszczają firmę, klucze bezpieczeństwa się psują. Bez planu w niewłaściwym momencie nikt nie ma wtedy dostępu.
Dla każdego krytycznego konta proszę zarejestrować dwa składniki, na przykład klucz bezpieczeństwa w biurze i aplikację uwierzytelniającą, a kody odzyskiwania przechowywać oddzielnie od hasła.
Dalsze zasady, które się sprawdziły:
- Konta osobiste zamiast wspólnie używanych loginów administratora, aby zmiany dało się prześledzić.
- Udokumentowany dostęp awaryjny z osobno przechowywanymi danymi dostępowymi, którego użycie rzuca się w oczy i jest protokołowane.
- Przy odejściu pracowników lub usługodawców odebrać wszystkie dostępy i klucze tego samego dnia.
- Po incydencie bezpieczeństwa sprawdzić nie tylko hasła, ale także zarejestrowane składniki i aktywne sesje.
Przy wprowadzaniu w zespole sprawdził się jasny przebieg. Proszę zacząć od kont, które mogą wyrządzić największą szkodę: hosting, domena, DNS i skrzynki e-mail administratorów. Potem następują serwery, CMS i usługi. Proszę ustalić dzień graniczny, od którego logowania bez drugiego składnika nie są już możliwe, i wcześniej upewnić się, że wszyscy uczestnicy są skonfigurowani.
Proszę krótko wyjaśnić zespołowi, dlaczego zmiana jest potrzebna i jak działa na co dzień. Jednostronicowa instrukcja ze zrzutami ekranu wyraźnie zmniejsza liczbę pytań. Zewnętrzni usługodawcy i agencje powinni otrzymać własne, osobiste dostępy z drugim składnikiem zamiast wspólnego loginu, aby dostępy dało się przypisać i czysto odebrać po zakończeniu projektu.
Jak dodatkowo chronić strony logowania przed zautomatyzowanymi próbami, opisuje poradnik Ochrona logowania administratora przed brute force.
Jak konkretnie pomaga PHP SOS?
- Tworzymy z Państwem pełną listę wszystkich dostępów administratora i pokazujemy, gdzie brakuje drugiego składnika.
- Przestawiamy dostępy do serwerów na klucze SSH i kontrolowanie wyłączamy logowanie hasłem w ramach utwardzania serwera.
- Dokumentujemy dostępy awaryjne i drogi odzyskiwania tak, aby w poważnej sytuacji działały.
- W umowie serwisowej na bezpieczeństwo regularnie sprawdzamy dostępy i usuwamy osierocone konta.
Częste pytania
Która metoda dwuskładnikowa jest najbezpieczniejsza?
Sprzętowe klucze bezpieczeństwa i passkeys zgodne ze standardem FIDO2 uchodzą za szczególnie odporne na phishing, ponieważ są powiązane z prawdziwym adresem. Aplikacje uwierzytelniające z kodami jednorazowymi to dobry standard. SMS jest lepszy niż nic, ale to najsłabszy wariant.
Co się stanie, jeśli zgubię smartfon z aplikacją uwierzytelniającą?
Na to są kody odzyskiwania, wyświetlane przy konfiguracji. Należy je bezpiecznie przechowywać, na przykład w sejfie lub w chronionym menedżerze haseł. Dodatkowo przynajmniej jeden drugi administrator powinien móc zresetować dostęp.
Czy logowanie dwuskładnikowe chroni także przed PHP2Shell?
Nie. PHP2Shell umożliwia wykonanie kodu bez logowania, logowanie nie jest przy tym w ogóle używane. Przeciw PHP2Shell pomaga tylko aktualizacja do naprawionej wersji PHP z restartem wszystkich procesów roboczych. Logowanie dwuskładnikowe chroni przed skradzionymi lub odgadniętymi hasłami.
Czy wystarczy logowanie dwuskładnikowe w CMS?
Nie, atakujący wybiera najsłabszy dostęp. Konto hostingowe, panel serwera, SSH, zarządzanie domeną, DNS i skrzynki e-mail administratorów muszą być chronione tak samo, w przeciwnym razie ochronę w CMS można obejść.