MFA odporne na phishing a NIS2

Hasło z kodem z SMS-a oraz powiadomienia push to powszechnie stosowane MFA, ale atakujący mogą je obejść. Ten poradnik wyjaśnia dlaczego, pokazuje faktory MFA odporne na phishing i opisuje, jak wdrożyć je etapami, także w kontekście NIS2.

Wdrażamy je w Okta Workforce Identity, a szerzej o tożsamości w firmie piszemy na stronie IAM.

Dlaczego SMS i kody push ulegają phishingowi

Kod z SMS-a czy zatwierdzenie push mają wspólną słabość: atakujący może wyłudzić każde z nich od użytkownika.

Wystarczy fałszywa strona logowania, na której użytkownik wpisuje hasło i kod. Atakujący od razu używa ich na prawdziwej stronie. Może też sam zalogować się na prawdziwej stronie i poprosić użytkownika o zatwierdzenie logowania.

Kody SMS można dodatkowo przejąć, zdobywając kontrolę nad numerem telefonu (SIM swap).

FIDO2, passkeys i Okta FastPass

FIDO2 i WebAuthn, to standardy, w których klucz kryptograficzny jest powiązany z domeną prawdziwej strony. Na fałszywej domenie urządzenie nie wygeneruje odpowiedzi, którą atakujący mógłby wykorzystać na prawdziwej stronie, więc nie ma czego wyłudzić od użytkownika.

  • Klucze bezpieczeństwa FIDO2: fizyczny klucz (USB lub NFC), który działa na wielu urządzeniach i dobrze nadaje się dla kont uprzywilejowanych.
  • Passkeys: dane logowania oparte na WebAuthn, zapisane na urządzeniu użytkownika i czasem synchronizowane między jego urządzeniami, odblokowywane biometrią lub PIN-em urządzenia.
  • Okta FastPass: faktor w aplikacji Okta Verify, w którym to urządzenie weryfikuje logowanie. Jest odporny na phishing tylko wtedy, gdy polityka wymaga uwierzytelniania odpornego na phishing. Okta może uwzględnić w polityce także stan urządzenia.

Wybór zależy od urządzeń użytkowników: Okta FastPass, jeżeli urządzenie może korzystać z Okta Verify, klucze FIDO2 dla kont uprzywilejowanych, a dla klientów Twojego produktu passkeys w Auth0, które opisujemy w poradniku CIAM z Auth0 w praktyce.

NIS2 a uwierzytelnianie wieloskładnikowe

Zgodnie z art. 21 ust. 2 lit. j dyrektywy NIS2 środki zarządzania ryzykiem obejmują, w stosownych przypadkach, stosowanie uwierzytelniania wieloskładnikowego lub ciągłego. W Polsce obowiązki te wynikają ze znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa.

Dyrektywa nie wskazuje konkretnej metody MFA, więc dobór faktorów wynika z analizy ryzyka Twojej organizacji. Faktory odporne na phishing są jednym ze sposobów, by to w praktyce spełnić. O tym, jakie środki musi stosować Twoja organizacja, ustal z zespołem compliance lub prawnikiem. Szerzej o NIS2 w Polsce piszemy na stronie NIS2 / KSC.

Wdrożenie etapami

Planujemy wdrożenie grupami, żeby ograniczyć ryzyko dla codziennej pracy użytkowników. Polityki konfigurujemy w Okcie, a w każdej grupie wymagamy faktorów odpornych na phishing i dążymy do wycofania słabszych faktorów MFA.

  1. Admini

    Zaczynamy od kont adminów, bo ich przejęcie daje atakującemu największe możliwości. Dla tej grupy faktory MFA odporne na phishing są wymagane od razu.

  2. Grupy podwyższonego ryzyka

    Potem obejmujemy grupy z dostępem do danych finansowych, kadrowych lub kodu źródłowego oraz osoby często atakowane, na przykład zarząd i dział finansów.

  3. Wszyscy użytkownicy

    Na końcu rozszerzamy politykę na pozostałych użytkowników, gdy helpdesk i pierwsze grupy znają już nowy sposób logowania.

Odzyskiwanie dostępu i wyjątki

Najsłabszym ogniwem bywa proces odzyskiwania dostępu: jeśli konto można odzyskać szybką rozmową z helpdeskiem, atakujący może podszyć się pod użytkownika i poprosić o reset. Dlatego ustalamy, jak helpdesk weryfikuje tożsamość i kiedy potrzebuje potwierdzenia od drugiej osoby.

Użytkownik zgubił klucz albo telefon.

−Helpdesk resetuje faktor po krótkiej rozmowie telefonicznej.

+Rejestrujemy co najmniej dwa faktory na konto i weryfikujemy tożsamość według ustalonej procedury, na przykład z udziałem przełożonego.

Część użytkowników nie ma urządzenia, na którym działa Okta Verify.

−SMS zostaje dla nich stałym wyjątkiem, bez terminu końca.

+Dajemy im klucze FIDO2, a każdy wyjątek zapisujemy z właścicielem i datą przeglądu.

W polityce zostaje SMS jako zapasowa metoda logowania (fallback).

−Atakujący wybiera najsłabszą dostępną drogę, czyli właśnie ten zapasowy SMS.

+Wymagamy faktorów odpornych na phishing i dążymy do wycofania słabszych faktorów MFA.

Wyjątki i polityki wymagają przeglądów także po wdrożeniu, a zakres tej opieki opisujemy na stronie Utrzymanie i wsparcie Okta.

Jan Czajkowski

CEO

Jan Czajkowski jest CEO i współzałożycielem Zelto, oficjalnym partnerem Okty, który pomaga organizacjom projektować, wdrażać i utrzymywać zarządzanie tożsamością i dostępem.

Więcej od Jana →

Porozmawiajmy o MFA w Twojej firmie

Opowiedz nam o swoich urządzeniach i grupach użytkowników, a zaproponujemy kolejność wdrożenia. Jeśli wolisz e-mail, napisz na hello@zelto.id.