Uwierzytelnianie wieloskładnikowe w firmowych kontach SaaS: jak wdrożyć

Dlaczego hasła nie wystarczą w firmowych kontach SaaS

Tradycyjne logowanie opiera się tylko na tym, co użytkownik zna – nazwie użytkownika i haśle. To jeden składnik, który można ukraść, odgadnąć albo pozyskać z wycieku w innym serwisie, w którym pracownik użył tego samego hasła. W firmowym SaaS skutki są większe niż na koncie prywatnym: jedno przejęte konto może otwierać dostęp do dokumentów, korespondencji, danych klientów i integracji z innymi systemami.

Rublon podaje, że w 2025 r. skradzione dane uwierzytelniające nadal są główną drogą wejścia do organizacji, a ataki ransomware wykorzystują słabe i wielokrotnie używane hasła. Do najczęstszych wektorów naruszeń, które blokuje MFA, ten sam materiał zalicza skradzione lub odgadnięte dane logowania, ataki ransomware i ataki botów.

Presja regulacyjna rośnie. Według Rublona w finansach, opiece zdrowotnej, administracji publicznej, handlu detalicznym, edukacji i technologii organy regulacyjne coraz częściej oczekują MFA. W części przypadków jest wymagane wprost (PCI DSS, PSD2 SCA), w innych – oczekiwane w ramach NIST SP 800-171, HIPAA, FERPA, CCPA czy NIS2. Firmy technologiczne, w tym dostawcy chmury i SaaS, muszą stosować MFA także po to, by spełnić wymogi audytowe.

Kolejność wdrażania nie powinna być alfabetyczna. Najpierw obejmij konta o największym wpływie na organizację: administratorów aplikacji SaaS, dostęp zdalny, pocztę e-mail oraz dostawców tożsamości używanych przez użytkowników i administratorów. Taki start rekomenduje Rublon w zestawieniu dobrych praktyk.

MFA w praktyce SaaS: czynniki, 2FA i silne uwierzytelnianie

MFA to logowanie wymagające co najmniej dwóch niezależnych dowodów tożsamości – np. hasła (coś, co wiesz) i telefonu (coś, co masz) albo odcisku palca (coś, czym jesteś). Kluczowe jest słowo „niezależnych”: składniki muszą należeć do różnych kategorii, bo dwa hasła nie tworzą MFA.

MFA a 2FA: uwierzytelnianie dwuskładnikowe używa dwóch odrębnych czynników, a MFA może obejmować dwa lub więcej. Rublon zauważa, że przepisy często mówią o MFA, ale w praktyce wymagają dwóch czynników – dlatego 2FA także bywa zgodne z takim wymogiem, a cel obu rozwiązań jest ten sam: utrudnić nieuprawnionym dostęp do danych.

Osobna kategoria to „silne uwierzytelnianie”, o którym mówi np. SCA w PSD2. W praktyce najczęściej oznacza MFA stosowane przy dostępie do konta lub przy transakcjach podwyższonego ryzyka.

Logowanie do usługi SaaS po włączeniu dodatkowej weryfikacji wygląda prosto: użytkownik podaje nazwę użytkownika i hasło (pierwszy składnik – coś, co zna), a potem otrzymuje jednorazowy kod na telefon albo zatwierdza powiadomienie push w aplikacji. Dostęp dostaje dopiero po przejściu wszystkich kroków. W środowisku Microsoft jako przykłady metod podaje się aplikację Microsoft Authenticator lub jednorazowe kody SMS.

Inwentaryzacja kont SaaS i priorytety wdrożenia

Wdrożenie zaczyna się od spisu, nie od konfiguracji. Dla każdej aplikacji SaaS zbierz: nazwę i cel biznesowy, właściciela (osobę w firmie, nie dostawcę), listę kont i ich typów (użytkownik, konto techniczne, konto integracyjne), informację, kto ma uprawnienia administracyjne, oraz czy aplikacja pozwala eksportować dane, zmieniać ustawienia bezpieczeństwa lub dostęp do płatności. Osobno spisz kanały dostępu zdalnego (VPN, pulpity zdalne), system pocztowy i dostawcę tożsamości, przez którego logują się pracownicy.

Kryteria priorytetyzacji są praktyczne, nie techniczne: czy konto może zmieniać uprawnienia innych, czy daje dostęp do danych osobowych lub finansowych, czy jest dostępne z internetu bez dodatkowej warstwy, czy pozwala wyprowadzić dane poza firmę. Konto administratora w narzędziu, z którego można zresetować hasła całej organizacji, należy do pierwszej grupy.

Kolejność wdrożenia rekomendowana przez Rublona to dostęp zdalny, poczta e-mail oraz dostawcy tożsamości użytkowników i administratorów. Do tego dochodzą konta uprzywilejowane w samych aplikacjach SaaS.

Na koniec przypisz właściciela do każdej pozycji i ustal, kto zatwierdza wyjątki oraz kto odbiera zgłoszenia o utracie urządzenia. Bez właściciela wpis w rejestrze starzeje się szybciej niż polityka, którą ma wspierać.

Wybór metod uwierzytelniania: klucze FIDO2, push, TOTP i kody zapasowe

Rublon w zestawieniu metod wskazuje hierarchię: odporne na phishing klucze FIDO2/klucze dostępu (passkeys) do dostępu krytycznego, powiadomienia push z number matching (dopasowaniem numeru) jako ogólna linia bazowa, a SMS wyłącznie jako opcja zapasowa. Ta sama publikacja zaleca klucze sprzętowe FIDO2 lub passkeys dla kont uprzywilejowanych.

Różnica nie jest kosmetyczna. Klucze FIDO2 i passkeys wiążą logowanie z konkretną domeną usługi, więc nie da się ich skutecznie użyć na fałszywej stronie logowania. Kody jednorazowe z aplikacji (TOTP) i powiadomienia push są wygodne, ale użytkownik może je przepisać lub zatwierdzić w odpowiedzi na oszukańczą prośbę – dlatego łącz je z dodatkowym kontekstem (dopasowanie numeru, nazwa lokalizacji) i szkoleniem.

Dla kont, na których nie da się użyć klucza sprzętowego (np. gdy dostawca SaaS nie obsługuje tej metody), wybierz najsilniejszą metodę dostępną w aplikacji i zapisz w rejestrze, jaka klasa zabezpieczenia obowiązuje na danym koncie. Rejestr metod to też podstawa rozmowy z audytorem.

Niezależnie od metody zaplanuj kody zapasowe i jasne procedury odzyskiwania dostępu – Rublon wymienia to wprost jako element wdrożenia obok monitorowania i udoskonalania procesu. W praktyce oznacza to co najmniej dwie zapisane metody dla każdego użytkownika oraz procedurę, która nie kończy się telefonicznym „proszę wyłączyć MFA”.

Porównanie metod uwierzytelniania w MFA

Zalety i wady głównych metod MFA w środowisku SaaS

Wdrożenie krok po kroku: pilotaż, polityki i wymuszenie MFA

Zacznij od grupy pilotażowej: kilku–kilkunastu osób z różnych zespołów, w tym co najmniej jednej osoby obsługującej helpdesk. Celem pilotażu jest sprawdzenie nie samego logowania, ale ścieżek odzyskiwania: co się dzieje po utracie telefonu, po zmianie urządzenia, przy logowaniu z nowej przeglądarki i przy dostępie do aplikacji mobilnej.

Po pilocie skonfiguruj polityki w dwóch profilach – dla użytkowników i administratorów – i wymuszaj je stopniowo: dostęp zdalny, poczta e-mail, dostawca tożsamości, aplikacje SaaS o podwyższonym ryzyku. Rublon jako szybki start wymienia wymuszenie MFA dla dostępu zdalnego, poczty e-mail oraz dostawców tożsamości użytkowników i administratorów.

Konta uprzywilejowane traktuj odrębnie: klucz sprzętowy FIDO2 lub passkey, brak możliwości pominięcia weryfikacji, a w aplikacjach, które na to pozwalają – osobne konta administracyjne nieużywane do codziennej pracy i poczty.

Równolegle z konfiguracją prowadź komunikację i szkolenie: co zmieni się dla użytkownika, jak wygląda ekran weryfikacji, gdzie zgłosić problem i jak przebiega odzyskiwanie dostępu. Helpdesk powinien mieć gotowe skrypty, w tym sposób weryfikacji tożsamości osoby zgłaszającej utratę urządzenia, oraz listę pytań, na które nie odpowiada się przez telefon. Datę wymuszenia podaj z wyprzedzeniem i przypominaj o niej kilka dni przed terminem.

Opór użytkowników i wygoda: jak wdrożyć MFA bez paraliżu pracy

Wybieraj metody bezproblemowe – powiadomienia push i klucze dostępu – i edukuj użytkowników, a nie tylko wysyłaj instrukcje. Rublon wskazuje też potrzebę opcji samoobsługi, aby użytkownik mógł sam zarejestrować nowe urządzenie, wygenerować kody zapasowe czy sprawdzić stan konta bez zgłoszenia do helpdesku.

Zbuduj jasną ścieżkę odzyskiwania dostępu zamiast zakazu: utracone urządzenie, utracony dostęp do skrzynki służbowej, zmiana telefonu, wyjazd za granicę. Każdy scenariusz powinien mieć opisane kroki, czas realizacji i osobę zatwierdzającą. Szybka i przewidywalna ścieżka odzyskiwania realnie ogranicza chęć obchodzenia polityki.

Osobno zaadresuj obejścia. Użytkownicy, którym MFA przeszkadza, tworzą lokalne konta w aplikacjach, współdzielą hasła w zespołach albo wracają do starszych protokołów pocztowych, które nie obsługują dodatkowej weryfikacji. Wykryjesz to po nieudanych próbach logowania, logowaniu z nietypowych klientów poczty i liczbie aktywnych kont lokalnych w aplikacjach.

Mierz wygodę, nie tylko bezpieczeństwo: czas od zarejestrowania do pierwszego udanego logowania, liczbę zgłoszeń do helpdesku na użytkownika w pierwszym tygodniu i liczbę nieudanych prób uwierzytelnienia. Te wskaźniki pokazują, gdzie polityka jest zbyt sztywna, a gdzie brakuje szkolenia.

MFA, SSO i dostawcy tożsamości w środowisku SaaS

Najprostszy model to egzekwowanie MFA w warstwie dostawcy tożsamości, do którego aplikacje są podłączone przez SSO. Wtedy polityka działa jednolicie dla wszystkich zintegrowanych usług, a administrator zmienia ją w jednym miejscu, również dla przyszłych wdrożeń.

Problemem są aplikacje poza SSO. Prowadź listę integracji i dla każdej pozycji wiedz, czy logowanie odbywa się przez dostawcę tożsamości, czy przez lokalne konto w aplikacji. Aplikacje spoza federacji wymagają konfiguracji MFA po stronie dostawcy SaaS – i to one najczęściej zostają jedynym miejscem, w którym pracownik loguje się wyłącznie hasłem.

Konta administracyjne bywają furtką obok SSO. Konto „break-glass” do dostawcy tożsamości, konto administratora w aplikacji bez federacji albo konto integracyjne używane przez skrypt nie przejdą standardowej polityki. Dla takich kont ustaw silniejszą, dedykowaną metodę, ogranicz zakres uprawnień i zapisz w dokumentacji, kto i kiedy może z nich korzystać.

Jeśli dopiero wybierasz dostawcę tożsamości lub nową aplikację SaaS, pytaj wprost o obsługę FIDO2/passkeys, obsługę wielu metod dla jednego użytkownika, eksport zdarzeń uwierzytelnienia oraz możliwość wyłączenia logowania hasłem lokalnym. To kryteria, które po fakcie trudno nadrobić, a które decydują o tym, czy polityka MFA da się utrzymać.

Utrzymanie i audyt: monitoring, raportowanie i dokumentacja wdrożenia

Monitoruj zdarzenia uwierzytelniania, a nie sam fakt włączenia MFA. Do przeglądu nadają się: nieudane logowania, odmowy zatwierdzenia powiadomienia push, rejestracja nowego urządzenia lub klucza, zmiana lub dodanie metody, użycie kodu zapasowego oraz logowania do kont administracyjnych. Rejestr użycia kodu zapasowego jest szczególnie istotny – zwykle oznacza, że użytkownik zgubił urządzenie albo że próbę przejęcia konta podejmuje ktoś obcy.

Ustal cykliczny przegląd: odsetek kont z włączonym MFA w podziale na aplikacje, liczbę kont bez MFA, liczbę aktywnych kont administracyjnych, liczbę aktywnych kont integracyjnych i wyjątków od polityki. Każdy wyjątek powinien mieć właściciela i termin ważności.

Zbuduj procedurę reakcji na próby obejścia polityki: serię nieudanych weryfikacji, wielokrotne powtarzanie powiadomień push kierowanych do jednej osoby, logowanie do konta po użyciu kodu zapasowego z nietypowej lokalizacji. Kolejność działań w takiej sytuacji to zwykle zablokowanie sesji, wymuszenie zmiany hasła, odebranie aktywnych metod i ponowna rejestracja urządzenia po weryfikacji tożsamości.

Na potrzeby audytu i zgodności zbierz dokumentację: politykę uwierzytelniania, dowody rejestracji metod, rejestr wyjątków, raporty pokrycia kont oraz opis procedur odzyskiwania dostępu. Rublon wśród obszarów, w których MFA pomaga spełnić wymagania, wymienia RODO, NIS2, ustawę o KSC oraz PCI DSS, PSD2, HIPAA, FTC Safeguards i ubezpieczenia cybernetyczne – zestawienie tych ram warto mieć w jednym miejscu razem z dowodami, które pokazują, jak polityka działa w praktyce.