Žádost o MFA pro VPN zamítnuta: co má klient udělat
Zamítnutá žádost o MFA je neúspěšné přihlášení, ne smyčka opakování. Rozpoznejte žádost, neskrývejte selhání a zaznamenejte, co bude podpora chtít.
Zamítnutá žádost o MFA vypadá jako problém sítí, ale není. Server požádal o druhý faktor, faktor se vrátil negativní nebo nikdy nedorazil a relace byla odmítnuta dřív, než vznikl jakýkoli tunel. Co se stane potom, je otázka chování klienta: ukázat selhání a nechat uživatele začít čistý pokus, nebo opakovat způsoby, které generují další žádosti a nakonec spustí ochranu účtu. Druhá cesta je to, jak se z jednoho překlepu stane uzamčený účet.
Zjistěte, která žádost selhala
Začněte tím, že zjistíte, která žádost selhala. Push oznámení, kód TOTP, tvrzení FIDO a tok SAML selhávají každý jinak a klient obvykle ví, kterou z nich požádal. Odmítnutí, vypršelá výzva a selhání doručení, které se k zařízení nikdy nedostalo, končí všechny stejnou obecnou chybou, takže stav samotného klienta je často jediné místo, kde rozdíl přežije.
Tento stav stojí za přesné zaznamenání. Zaznamenejte identifikátor výzvy nebo referenci transakce, typ faktoru, časové razítko a výsledek, ale nikdy kód ani tvrzení. Identifikátor výzvy je to, co administrátorovi umožní najít událost na straně poskytovatele identity; bez něj rozhovor s podporou začíná slovy „někdy v poslední hodině“ a obvykle tam i končí. Berte ho jako diagnostická metadata, ne jako tajemství.
Zkuste to jednou, záměrně, s novou výzvou
Opakovaný pokus má být nový pokus s novou výzvou, ne přehrání staré. Když klient znovu použije předchozí výzvu, poskytovatel identity ji buď odmítne jako zastaralou, nebo, což je horší, přijme schválení určené pro dřívější pokus. Vyžádejte si novou výzvu, zobrazte ji a nechte uživatele jednat podle té, která je právě na obrazovce.
Dva pokusy s krátkou pauzou mezi nimi jsou rozumné výchozí nastavení; neomezená smyčka není. Pokud druhý pokus selže stejně, zastavte se a nahlaste to, místo abyste pokračovali.
Co klient nesmí dělat
Klient nesmí dělat několik věcí, které vypadají užitečně a nejsou. Nesmí dál posílat push oznámení, dokud někdo neklepne na „schválit“, protože to učí uživatele schvalovat žádosti, které sami nezahájili, a přesně na toto chování spoléhají phishingové sady. Nesmí se vrátit ke slabšímu faktoru proto, že silný selhal, a nesmí vypnout kontrolu identity serveru, aby obešel stížnost na certifikát, která se objevila ve stejnou dobu. Každá z těchto tří zkratek mění selhání autentizace v bezpečnostní incident.
Také nesmí selhání tiše spolknout. Klient, který zavře spojení a ukáže spinner, nechává uživatele bez tušení, zda zkusit znovu, počkat, nebo zavolat podpoře. Ukažte selhání s typem faktoru a krátkým kódem, udržte zprávu bez tajemství a udělejte akci opakování explicitní, ne automatickou.
Pokud žádost nezahájil člověk u klávesnice, správná akce je nechat ji zamítnutou a nahlásit ji ověřenou cestou podpory. Schválit žádost, aby přestal hluk, je vzorec selhání, ne oprava.
Co zaznamenat pro podporu
Pro podporu je užitečný záznam malý. Přibližný čas s časovým pásmem, účet, klient a verze, typ faktoru a neveřejný stav každého pokusu: vyžádáno, zamítnuto, vypršelo, schváleno, ale odmítnuto politikou.
Mějte na očích i hodiny klienta a serveru. TOTP je kontrola časového okna, takže zařízení s posunutými hodinami vytváří kódy, které vypadají platně a pokaždé selžou, a klient, který nahlásí neplatný kód bez poznámky o posunu, posílá lidi resetovat přihlašovací údaje, které nikdy nebyly špatné. Uživatel, jehož přihlášení opakovaně selhává, by měl zkontrolovat podporovanou verzi klienta, stav registrace a dokumentovaný postup obnovy, než vygeneruje další žádosti.
Cesta obnovy si zaslouží stejnou péči jako cesta přihlášení. Postup pro ztracené zařízení existuje právě proto, aby se z odmítnutí nestalo povolení obejít autentizaci, a klient by měl odkazovat na dokumentovaný proces organizace, místo aby improvizoval vlastní.
Pravidlo, proti kterému je třeba stavět, je, že odmítnutí je výsledek, ne překážka. Nahlaste ho jednou, jasně, s dostatkem kontextu k jednání, a nechte další pokus být nový. Pokyny CISA k MFA odolnému proti phishingu vysvětlují, proč je vzorec „ptejte se, dokud se neschválí“ nebezpečný už od základu, a je to reference, kterou stojí za to citovat, když někdo navrhne smyčku opakování. Vše, co klient po odmítnutí přidá, má usnadnit další rozhodnutí člověku, ne mu rozhodnutí odebrat.