2026 januárjában az FBI elindította a Winter SHIELD műveletet, amelynek első ajánlott lépése így szól: adathalászat-ellenálló módszereket, „FIDO2-kompatibilis biztonsági kulcsokat vagy eszközhöz kötött passkeyeket” („FIDO2 compliant security keys or device-bound passkeys”) kell bevezetni a hitelesítéshez, a távoli hozzáféréshez és a kritikus rendszerekhez (FBI). Az ENISA NIS2 végrehajtási útmutatója ugyanezt mondja a VPN-ekről és az adminisztrációs rendszerekről: „ahol csak lehet, adathalászat-ellenálló MFA-t használjon” („wherever possible, use phishing-resistant MFA”) (ENISA, 2025. június). A Microsoft saját dokumentációja ma már úgy jellemzi az SMS-es és a hitelesítő alkalmazásos MFA-t, hogy „ki van téve a távoli adathalász támadásoknak” („prone to remote phishing attacks”) (Microsoft).
Ha az Ön távoli hozzáférése egy VPN-koncentrátor, amely RADIUS-on ellenőrzi a bejelentkezéseket, valószínűleg már észrevette a problémát: a passkeyt nincs hová beilleszteni. Ez a bejegyzés elmagyarázza, miért van ez így, mi a három reális lehetőség, és melyikük mi ellen nem véd.
Mit csinál valójában a passkey
A passkey egy WebAuthn-hitelesítő adat: a felhasználó eszközén létrehozott kulcspár, amelyet egyetlen webhelyhez regisztráltak. Bejelentkezéskor a böngésző megkéri az eszközt, hogy írja alá a webhelytől kapott kihívást (challenge), és az aláírás kiterjed annak az oldalnak az originjére, amelyet a böngésző ténylegesen megjelenít. A webhely ellenőrzi, hogy az aláírásban szereplő origin a sajátja. Egy másik domainen futó hamis bejelentkezési oldal rossz originre szóló aláírást kap, amelyet a valódi webhely elutasít. A felhasználónak semmit nem kell észrevennie, mert az ellenőrzést a böngésző végzi (W3C WebAuthn).
Ezt értik a szabványok adathalászat-ellenálláson. A NIST jelenlegi definíciója szerint ez „a hitelesítési protokoll azon képessége, hogy az igénylő éberségére támaszkodás nélkül megakadályozza a hitelesítési titkok … kiszivárgását” („the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant”), és egyértelműen kimondja, mi bukik meg ezen a próbán: a jelszavak, az egyszer használatos kódok, a push-jóváhagyások és minden, amit a felhasználónak át kell gépelnie, „nem adathalászat-ellenálló” (NIST SP 800-63B-4, 2025). A CISA ugyanígy rangsorolja a módszereket: az élen a FIDO/WebAuthn és a PKI, majd az egyszer használatos kódok és a számegyeztetéses push, utána a számegyeztetés nélküli push, végül az SMS (CISA).
Abban, ahogyan a passkey megfelel ennek a definíciónak, két dolog fontos a VPN szempontjából. A védelmet egy böngésző vagy platformkliens adja, amely tudja, melyik originnel beszél, valamint egy kihívás és aláírás, amely a bejelentkezési protokollon belül utazik.
Miért nincs helye a passkeynek a RADIUS VPN-en
A RADIUS-t, azt a protokollt, amellyel a legtöbb VPN-átjáró megkérdezi a hitelesítési szervertől, hogy „jó ez a bejelentkezés?”, betárcsázós modemekhez tervezték. Az Access-Request egy felhasználónevet és egy MD5-kulcsfolyammal elrejtett jelszót vagy egy CHAP-választ visz. Ha a szerver többet akar, Access-Challenge üzenetet küld, amelynek szövegét az átjáró „megjelenítheti” („MAY display”) a felhasználónak, aki ezután begépel egy választ, és az a jelszómezőben megy vissza (RFC 2865). Ez a teljes szókincs: ember által begépelt karakterláncok. Nincs mező az aláírt WebAuthn-assertionnek, nincs origin, amelyet az aláírás lefedhetne, mert a VPN-kliensnek nincs oldala, és nincs user agent, amely ezt kikényszerítené.
Önmagában tehát az alábbiak egyike sem képes passkeyes VPN-bejelentkezésre:
- MikroTik RouterOS: csak RADIUS-kliens, SAML- és OIDC-támogatás nélkül (MikroTik dokumentáció).
- WireGuard: a peereket statikus nyilvános kulcsokkal hitelesíti, és felhasználói bejelentkezése egyáltalán nincs, így az alábbi lehetőségek egyike sem vonatkozik rá; ott a kulcsok kiosztása a probléma (wireguard.com).
- OpenVPN Access Server: RADIUS, LDAP vagy PAM esetén a második faktor időalapú kód, és csak a SAML módja tudja böngészőnek átadni a bejelentkezést (OpenVPN dokumentáció).
A FortiGate, a Palo Alto GlobalProtect és a Cisco Secure Client viszont kínál passkeyes VPN-bejelentkezést, és mindhárom ugyanúgy teszi: a VPN-kliens megnyit egy böngészőt, a böngésző bejelentkezik egy SAML-identitásszolgáltatónál, a passkeyt ott használják, és az IdP közli az átjáróval, hogy a felhasználó rendben van. A FortiClient ezt a „külső böngésző mint user agent” opcióval teszi, a Cisco ASA 9.17-től pontosan ezért indítja el a rendszerböngészőt, a GlobalProtect pedig böngészőnézetet ágyaz a kliensbe (Fortinet, Duo for Cisco ASA, Palo Alto). A Microsoft a saját RADIUS-megoldásáról kertelés nélkül kimondja: az NPS-bővítmény nem tud számegyeztetést, az MS-CHAPv2 pedig nem tud időalapú kódot továbbítani (Microsoft).
A passkey soha nem érinti a RADIUS-t. A munkát a böngésző végzi, az átjáró pedig az IdP szavára hagyatkozik.
A három reális lehetőség
1. SAML-identitásszolgáltató a VPN elé, és passkey ott
Ez az út szigorú értelemben vett adathalászat-ellenállást ad a felhasználói VPN-bejelentkezéseknek, és ha az átjárója és a kliensei támogatják, a probléma böngészőn keresztül kezelhető részére ez a helyes válasz.
Mibe kerül: egy passkeyt támogató identitásszolgáltató és a vele járó licenc, a külső böngészős SAML-hez elég új kliensverziók, a passkey bevezetése minden VPN-felhasználónál, és egy helyreállítási folyamat az elveszett eszközökre. Mit hagy fedetlenül: minden rendszert, amely nem tud SAML-t, beleértve sok eszközön a tűzfal saját adminisztrátori bejelentkezését, a MikroTiket, a WireGuardot és mindent, ami böngésző nélkül jelentkezik be.
2. Tanúsítványok
A klienstanúsítványos hitelesítés (EAP-TLS a VPN-en vagy géptanúsítvány az eszközön) a másik módszer, amelyet a NIST adathalászat-ellenállónak tekint, az általa csatornakötésnek (channel binding) nevezett mechanizmus révén (NIST). Itt a felhasználónak nincs mit begépelnie, és nincs mit továbbítani.
Mibe kerül: egy tanúsítványkiadó (CA), minden eszköz regisztrálása, ténylegesen működő megújítás és visszavonás, és valaki, aki mindezért felel. A CISA szerint a PKI-alapú MFA „nagyon kiforrott identitáskezelési gyakorlatot” („highly mature identity management practices”) kíván, és megjegyzi, hogy nem széles körben támogatott (CISA). És a géptanúsítvány azt bizonyítja, melyik eszköz csatlakozott, nem azt, hogy ki ült előtte.
3. Maradjon a RADIUS, és jöjjön mellé egy telefonos jóváhagyás, amely megmutatja a bejelentkezést
A harmadik út az átjárót és a RADIUS-szervert pontosan úgy hagyja, ahogy vannak, és egy második lépést iktat be a RADIUS-útvonalba: az Ön RADIUS-szervere először a jelszót ellenőrzi, és a felhasználó csak akkor kap jóváhagyási kérést a telefonjára, ha a szerver elfogadta a bejelentkezést. A kérés megnevezi a szolgáltatást, a fiókot és a forrás IP-címet, és a bejelentkezés csak akkor sikerül, ha a felhasználó jóváhagyja. Ezt csinálja a Notakey auth-proxy; a beállítási útmutató végigvezet rajta a FreeRADIUS, az NPS és a MikroTik User Manager esetében.
Ez a legolcsóbban bevezethető út, mert az átjárón semmi nem változik azon kívül, hová küldi a RADIUS-t, és működik minden átjárón, amely RADIUS-on ellenőrzi a bejelentkezéseket, azokon is, amelyek soha nem fogják támogatni a SAML-t. Egyúttal ez az az út, amelynek a leírásánál a legóvatosabbnak kell lennünk.
Mit állít meg. A kiszivárgott, szórt vagy feltört jelszó többé nem bejelentkezés. A FortiBleednek, a FortiGate VPN-ek elleni 2026-os kampánynak ennél többre nem volt szüksége (elemzésünk). Az SMS-lehallgatás és a SIM-csere itt nem jelent veszélyt, mert nincs kód. A push-bombing 2022-ben a Cisco és az Uber VPN-jébe juttatta be a támadókat: addig küldték a jóváhagyási kéréseket, amíg valaki rá nem koppintott az igenre (Cisco Talos, Uber). Itt ez egy olyan kártyába ütközik, amely megmutatja, melyik fiók melyik szolgáltatásba jelentkezik be és honnan, valamint a szerver gyakoriságkorlátozójába (hogyan).
Mit nem állít meg. Nem állítja meg a valós idejű közvetítést, amelyben egy hamis VPN-portál továbbítja az áldozat valódi bejelentkezését, és az áldozat a saját munkamenetét hagyja jóvá a támadó kapcsolatán. A jóváhagyási kártya megmutatja a forrás IP-címet, így a közvetítés látható annak a felhasználónak, aki odanéz, de a védelem azon múlik, hogy odanéz-e, és a NIST definíciója pontosan az ilyen támaszkodást zárja ki. A push-jóváhagyás a CISA értelmében nem adathalászat-ellenálló, számegyeztetéssel vagy anélkül, és ezt a biztonsági oldalunkon ki is mondjuk, ahelyett hogy kölcsönvennénk a címkét.
Hogyan néztek ki valójában a betörések
Érdemes a lehetőségeket ahhoz mérni, ahogyan a VPN-eket és a távoli hozzáféréseket ténylegesen feltörték, nem pedig egy fenyegetési modellhez.
| Incidens | Hogyan jutott be a támadó | Melyik lehetőség állította volna meg |
|---|---|---|
| Colonial Pipeline, 2021 | Egy régi VPN-fiók jelszóval, második faktor nélkül (tanúvallomás) | A három közül bármelyik |
| Change Healthcare, 2024 | Egy Citrix távoli hozzáférési portál MFA nélkül (tanúvallomás) | A három közül bármelyik |
| FortiBleed, 2026 | Szórt, kiszivárgott és feltört FortiGate-jelszavak (FBI/USSS) | A három közül bármelyik |
| Cisco, Uber, 2022 | Ellopott jelszó, majd push-kérések, amíg egyet el nem fogadtak | Passkey, tanúsítvány; az olvasható jóváhagyás megmutatja, hogy a kérést senki nem indította |
| Scattered Spider, 2023 | Hamis SSO-oldalak, SIM-csere, push-bombing VPN-ek és webmail ellen (CISA AA23-320A) | Passkey és tanúsítvány maradéktalanul; a jóváhagyás megmutatja a közvetítést |
| 0ktapus, 2022 | Hamis Okta-oldalak, amelyek valós időben továbbították a jelszavakat és az egyszer használatos kódokat (Cloudflare) | Csak passkey és tanúsítvány |
A hatból háromnál egyáltalán nem kellett MFA-t megkerülni: nem volt MFA. A táblázat becsületes olvasata az, hogy a „csak jelszó” és a „valamilyen második faktor” közötti szakadék még mindig az, ahol a kár nagy része keletkezik, és hogy az olvasható jóváhagyás és a passkey közötti különbség azoknál a fiókoknál számít a legtöbbet, amelyek bejelentkezését egy elszánt támadó valós időben is hajlandó közvetíteni.
Hogyan döntsön
- Tűzfal- és átjáró-adminisztrátori fiókok. Ezekre a fiókokra ment rá a FortiBleed, és ezeket mondja a Winter SHIELD elsőként kezelendőnek. Ha a felügyeleti felület támogatja a FIDO2-kulcsokat vagy a passkeyes SAML-bejelentkezést, használja őket. Ha csak RADIUS-t támogat, az adminisztrátori bejelentkezésre tett telefonos jóváhagyás sokkal jobb a puszta jelszónál, különösen, ha az ráadásul közös jelszó.
- Felhasználói VPN olyan átjárón, amely külső böngészős SAML-t tud. Vezesse be a passkeyt az identitásszolgáltatónál. Ez a szigorú válasz, és ma elérhető FortiGate-en, GlobalProtecten és Ciscón.
- Felhasználói VPN csak RADIUS-t tudó eszközökön, például MikroTiken vagy régebbi koncentrátorokon. A választás: tanúsítvány vagy telefonos jóváhagyás. Adathalászat-ellenállásban a tanúsítvány nyer, ha már üzemeltet PKI-t. Ha nem, olvasható jóváhagyással a jelszó önmagában már nem elég a bejelentkezéshez, az SMS-kódokat és a vak push-kéréseket már ma lecserélheti, a böngészőn keresztül zajló bejelentkezéseket pedig később még átállíthatja a passkeyre.
- Bármit választ, a teljes útvonalat nézze. A 2022-es Cisco-betörés egy személyes Google-fiókkal kezdődött, amely szinkronizált egy munkahelyi jelszót; a VPN csak a második lépés volt. Ha az MFA a VPN-en megvan, de a webmailen vagy a távoli asztalon hiányzik, a támadó egyszerűen a szomszéd ajtón próbálkozik.
A Notakey a harmadik utat fedi le, és világosan megmondjuk, hol áll ez a CISA rangsorán. Ha az átjárója RADIUS-t használ, a VPN 2FA útmutató egy délután alatt eljuttatja az első telefonos jóváhagyásig, a készülék pedig az Ön saját infrastruktúráján vagy a mi felhőnkben fut. Próbálja ki az élő demót, hogy a saját telefonján lássa, hogyan néz ki egy olvasható jóváhagyás, vagy kérjen bemutatót, és feltérképezzük, hogyan vonhatók be egy pilot projektbe a VPN-, a tűzfal-adminisztrátori és a távoli asztali bejelentkezései.