W styczniu 2026 roku FBI rozpoczęło operację Winter SHIELD, a pierwsze z jej zaleceń brzmi: wdrożyć metody odporne na phishing – „klucze bezpieczeństwa zgodne z FIDO2 lub klucze dostępu powiązane z urządzeniem” („FIDO2 compliant security keys or device-bound passkeys”) – do uwierzytelniania, dostępu zdalnego i systemów krytycznych (FBI). Wytyczne ENISA do wdrażania NIS2 mówią to samo o VPN i systemach administracyjnych: „wszędzie tam, gdzie to możliwe, stosować MFA odporne na phishing” („wherever possible, use phishing-resistant MFA”) (ENISA, czerwiec 2025). Własna dokumentacja Microsoftu opisuje dziś MFA oparte na SMS-ach i aplikacji uwierzytelniającej jako „podatne na zdalne ataki phishingowe” („prone to remote phishing attacks”) (Microsoft).
Jeśli Państwa dostęp zdalny to koncentrator VPN, który sprawdza logowania przez RADIUS, problem zapewne już Państwo zauważyli: nie ma gdzie podłączyć klucza dostępu. Ten wpis wyjaśnia, dlaczego tak jest, jakie są trzy realne opcje i przed czym każda z nich nie zabezpiecza.
Co właściwie robi klucz dostępu
Klucz dostępu (passkey) to poświadczenie WebAuthn: para kluczy wygenerowana na urządzeniu użytkownika i zarejestrowana w jednej witrynie. Gdy użytkownik się loguje, przeglądarka prosi urządzenie o podpisanie wyzwania (challenge) przysłanego przez witrynę, a podpis obejmuje adres pochodzenia (origin) strony, którą przeglądarka faktycznie wyświetla. Witryna sprawdza, czy adres pochodzenia w podpisie jest jej własny. Fałszywa strona logowania w innej domenie otrzymuje podpis dla niewłaściwego adresu pochodzenia, a prawdziwa witryna go odrzuca. Użytkownik nie musi niczego zauważać, bo sprawdzanie wykonuje przeglądarka (W3C WebAuthn).
To właśnie standardy rozumieją przez odporność na phishing. Obecna definicja NIST mówi o „zdolności protokołu uwierzytelniania do zapobiegania ujawnieniu sekretów uwierzytelniających … bez polegania na czujności osoby uwierzytelnianej” („the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant”) i wprost wskazuje, co tego testu nie przechodzi: hasła, kody jednorazowe, zatwierdzenia push i wszystko, co użytkownik musi przepisać, „nie są odporne na phishing” (NIST SP 800-63B-4, 2025). CISA szereguje metody tak samo: FIDO/WebAuthn i PKI na szczycie, potem kody jednorazowe i push z dopasowywaniem liczb (number matching), potem push bez niego, a na końcu SMS (CISA).
Z punktu widzenia VPN ważne są dwa elementy tego, jak klucz dostępu spełnia tę definicję. Ochronę zapewnia przeglądarka lub klient systemowy, który wie, z jakim adresem pochodzenia się komunikuje, oraz wyzwanie i podpis przesyłane w ramach samego protokołu logowania.
Dlaczego VPN z RADIUS nie ma gdzie go użyć
RADIUS, protokół, którym większość bram VPN pyta serwer uwierzytelniania „czy to logowanie jest poprawne?”, został zaprojektowany z myślą o połączeniach modemowych typu dial-up. Access-Request zawiera nazwę użytkownika i hasło zamaskowane strumieniem klucza MD5 albo odpowiedź CHAP. Jeśli serwer chce czegoś więcej, wysyła Access-Challenge, którego tekst brama „MOŻE wyświetlić” („MAY display”) użytkownikowi, a ten wpisuje odpowiedź, która wraca w polu hasła (RFC 2865). Na tym kończy się słownik tego protokołu: ciągi znaków wpisane przez człowieka. Nie ma pola na podpisaną asercję WebAuthn, nie ma adresu pochodzenia do podpisania, bo klient VPN nie ma żadnej strony, i nie ma agenta użytkownika, który by to wymusił.
Dlatego żadne z poniższych rozwiązań samo w sobie nie obsłuży kluczy dostępu przy logowaniu do VPN:
- MikroTik RouterOS: wyłącznie klient RADIUS, bez SAML ani OIDC (dokumentacja MikroTik).
- WireGuard: uwierzytelnia węzły (peers) statycznymi kluczami publicznymi i w ogóle nie ma logowania użytkownika, więc żadna z poniższych opcji go nie dotyczy; problemem jest tam dystrybucja kluczy (wireguard.com).
- OpenVPN Access Server: z RADIUS, LDAP lub PAM drugim składnikiem jest kod czasowy, a tylko tryb SAML potrafi przekazać logowanie do przeglądarki (dokumentacja OpenVPN).
FortiGate, Palo Alto GlobalProtect i Cisco Secure Client oferują klucze dostępu przy logowaniu do VPN i wszystkie trzy robią to tak samo: klient VPN otwiera przeglądarkę, przeglądarka loguje się u dostawcy tożsamości SAML, tam używany jest klucz dostępu, a dostawca tożsamości (IdP) potwierdza bramie, że użytkownik przeszedł weryfikację. FortiClient robi to przez opcję „external browser as user agent” (zewnętrzna przeglądarka jako agent użytkownika), Cisco ASA od wersji 9.17 uruchamia przeglądarkę systemową właśnie z tego powodu, a GlobalProtect osadza widok przeglądarki w kliencie (Fortinet, Duo dla Cisco ASA, Palo Alto). Microsoft pisze wprost o własnej ścieżce RADIUS: rozszerzenie NPS nie potrafi dopasowywać liczb, a MS-CHAPv2 nie przeniesie kodu czasowego (Microsoft).
Klucz dostępu nigdy nie dotyka RADIUS. Pracę wykonuje przeglądarka, a brama wierzy dostawcy tożsamości na słowo.
Trzy realne opcje
1. Postawić dostawcę tożsamości SAML przed VPN i tam używać kluczy dostępu
Ta droga daje odporność na phishing w ścisłym sensie dla logowań użytkowników do VPN, a jeśli obsługują ją Państwa brama i aplikacje klienckie, jest właściwą odpowiedzią na tę część problemu, która rozgrywa się w przeglądarce.
Koszty: dostawca tożsamości obsługujący klucze dostępu wraz z licencją, która się z nim wiąże, wersje klientów VPN na tyle nowe, by obsługiwały SAML w zewnętrznej przeglądarce, wdrożenie kluczy dostępu u każdego użytkownika VPN oraz procedura odzyskiwania dostępu po utracie urządzenia. Czego nie obejmuje: żadnego systemu, który nie obsługuje SAML – w tym, na wielu urządzeniach, logowania administratora samej zapory – ani MikroTika, WireGuarda i niczego, co loguje się bez przeglądarki.
2. Certyfikaty
Uwierzytelnianie certyfikatem klienta (EAP-TLS w VPN albo certyfikaty maszynowe na urządzeniu) to druga metoda, którą NIST zalicza do odpornych na phishing – dzięki mechanizmowi, który nazywa wiązaniem kanału (channel binding) (NIST). Użytkownik nie ma tu nic do wpisania, a atakujący nic do przekazania dalej.
Koszty: urząd certyfikacji, rejestracja każdego urządzenia, odnawianie i unieważnianie, które naprawdę działają, oraz ktoś, kto za to wszystko odpowiada. CISA opisuje MFA oparte na PKI jako wymagające „bardzo dojrzałych praktyk zarządzania tożsamością” („highly mature identity management practices”) i zauważa, że nie jest powszechnie obsługiwane (CISA). A certyfikat maszynowy dowodzi, które urządzenie się połączyło, a nie kto przy nim siedział.
3. Zostawić RADIUS i dodać zatwierdzenie na telefonie, które pokazuje logowanie
Trzecia droga pozostawia bramę i serwer RADIUS bez żadnych zmian i dodaje drugi krok w ścieżce RADIUS: Państwa serwer RADIUS najpierw sprawdza hasło, a dopiero gdy zaakceptuje logowanie, użytkownik otrzymuje na telefon prośbę o zatwierdzenie. Prośba zawiera nazwę usługi, konto i źródłowy adres IP, a logowanie powiedzie się tylko wtedy, gdy użytkownik je zatwierdzi. Tak właśnie działa Notakey auth-proxy; przewodnik konfiguracji prowadzi przez to krok po kroku dla FreeRADIUS, NPS i User Managera MikroTika.
To najtańsza droga we wdrożeniu, bo na bramie nie zmienia się nic poza adresem, na który wysyła żądania RADIUS, i działa ona na każdej bramie sprawdzającej logowania przez RADIUS, łącznie z tymi, które nigdy nie będą obsługiwać SAML. To także droga, którą musimy opisywać najostrożniej.
Co zatrzymuje. Hasło z wycieku, odgadnięte metodą password spraying lub złamane nie wystarcza już do zalogowania. FortiBleed, kampania z 2026 roku przeciwko sieciom VPN FortiGate, nie potrzebował niczego więcej (nasza analiza). Przechwytywanie SMS-ów i SIM-swap nie mają zastosowania, bo nie ma żadnego kodu. Push-bombing wpuścił atakujących do sieci VPN Cisco i Ubera w 2022 roku: wysyłali monity o zatwierdzenie, aż ktoś dotknął „tak” (Cisco Talos, Uber). Tutaj natrafia na kartę, która pokazuje, jakie konto loguje się do jakiej usługi i skąd, oraz na ogranicznik częstotliwości na serwerze (jak to działa).
Czego nie zatrzymuje. Nie zatrzymuje przekazywania logowania w czasie rzeczywistym (relay), gdy fałszywy portal VPN przekazuje prawdziwe logowanie ofiary, a ofiara zatwierdza własną sesję na połączeniu atakującego. Karta zatwierdzenia pokazuje źródłowy adres IP, więc pośrednik jest widoczny dla użytkownika, który się przyjrzy, ale ochrona zależy od tego, czy użytkownik się przyjrzy, a definicja NIST wyklucza właśnie takie poleganie na użytkowniku. Zatwierdzanie push nie jest odporne na phishing w rozumieniu CISA, z dopasowywaniem liczb czy bez, i mówimy to otwarcie na naszej stronie o bezpieczeństwie, zamiast przypisywać sobie tę etykietę.
Jak naprawdę wyglądały włamania
Warto sprawdzić te opcje nie względem modelu zagrożeń, lecz względem sposobów, w jakie faktycznie włamywano się do VPN i dostępu zdalnego.
| Incydent | Jak atakujący wszedł | Która opcja by go zatrzymała |
|---|---|---|
| Colonial Pipeline, 2021 | Stare konto VPN z hasłem i bez drugiego składnika (zeznanie) | Każda z trzech |
| Change Healthcare, 2024 | Portal dostępu zdalnego Citrix bez MFA (zeznanie) | Każda z trzech |
| FortiBleed, 2026 | Hasła do FortiGate odgadnięte metodą password spraying, pochodzące z wycieków i złamane (FBI/USSS) | Każda z trzech |
| Cisco, Uber, 2022 | Wykradzione hasło, a potem monity push aż do zaakceptowania jednego z nich | Klucze dostępu, certyfikaty; czytelne zatwierdzenie pokazuje monit, którego nikt nie zainicjował |
| Scattered Spider, 2023 | Fałszywe strony SSO, SIM-swap, push-bombing przeciw VPN i poczcie webowej (CISA AA23-320A) | Klucze dostępu i certyfikaty w pełni; zatwierdzenie ujawnia pośrednika |
| 0ktapus, 2022 | Fałszywe strony Okta przekazujące hasła i kody jednorazowe w czasie rzeczywistym (Cloudflare) | Wyłącznie klucze dostępu i certyfikaty |
W trzech z sześciu przypadków nie trzeba było w ogóle obchodzić MFA: MFA po prostu nie było. Uczciwy wniosek z tabeli jest taki, że większość szkód wciąż powstaje w luce między „samym hasłem” a „jakimkolwiek drugim składnikiem”, a różnica między czytelnym zatwierdzeniem a kluczem dostępu ma największe znaczenie w przypadku kont, których logowania zdeterminowany atakujący będzie przekazywał w czasie rzeczywistym.
Jak zdecydować
- Konta administratorów zapór i bram. To na nie polował FortiBleed i to je Winter SHIELD każe traktować priorytetowo. Jeśli interfejs zarządzania obsługuje klucze FIDO2 albo logowanie SAML z kluczami dostępu, należy ich użyć. Jeśli obsługuje tylko RADIUS, zatwierdzenie na telefonie przy logowaniu administratora jest o niebo lepsze niż samo hasło, a tym bardziej niż hasło współdzielone.
- VPN użytkowników na bramie, która potrafi SAML z zewnętrzną przeglądarką. Należy wdrożyć klucze dostępu u dostawcy tożsamości. To odpowiedź w ścisłym sensie i jest dostępna już dziś na FortiGate, GlobalProtect i Cisco.
- VPN użytkowników na sprzęcie obsługującym wyłącznie RADIUS, takim jak MikroTik czy starsze koncentratory. Do wyboru są certyfikaty albo zatwierdzenie na telefonie. Certyfikaty wygrywają pod względem odporności na phishing, jeśli mają już Państwo działającą infrastrukturę PKI. Jeśli nie, czytelne zatwierdzenie sprawia, że samo hasło przestaje być logowaniem, i już dziś zastępuje kody SMS i ślepe monity push, a logowania rozgrywające się w przeglądarce można później przenieść na klucze dostępu.
- Cokolwiek Państwo wybiorą, trzeba spojrzeć na całą ścieżkę. Włamanie do Cisco w 2022 roku zaczęło się od prywatnego konta Google synchronizującego służbowe hasło; VPN był dopiero drugim krokiem. MFA w VPN, którego brakuje w poczcie webowej lub pulpicie zdalnym, tylko kieruje atakującego do sąsiednich drzwi.
Notakey realizuje trzecią drogę i otwarcie mówimy, które miejsce zajmuje ona na drabinie CISA. Jeśli Państwa brama obsługuje RADIUS, przewodnik VPN 2FA doprowadzi Państwa do pierwszego zatwierdzenia na telefonie w jedno popołudnie, a appliance działa w Państwa własnej infrastrukturze lub w naszej chmurze. Wypróbuj demo na żywo, aby zobaczyć na własnym telefonie, jak wygląda czytelne zatwierdzenie, lub poproś o prezentację, a odwzorujemy Państwa logowania do VPN, administracji zapory i pulpitu zdalnego w pilotaż.