Stratený VPN autentifikátor: výmena bez vypnutia MFA
Stratený faktor je úloha obnovy, nie výpadok. Overte mimo zlyhávajúcej cesty, zaregistrujte náhradu, vyraďte starú metódu a potom dokážte, že prihlásenie funguje.
Niekto stratí telefón a tiket príde ako VPN nefunguje. Toto zarámovanie je nesprávne dvakrát: účet stále existuje a brána stále dôveruje poskytovateľovi identity, takže jediná pokazená časť je jeden faktor, ktorý človek už nemá. Berte to ako obnovu, nie ako výpadok: overte žiadateľa, zaregistrujte náhradu, vyraďte stratenú metódu a potom dokážte, že účet funguje. Všetko to predpokladá, že plán bol napísaný pred stratou, pretože vymýšľať ho počas hovoru je spôsob, akým MFA nakoniec skončí vypnuté pre všetkých.
Krok 1: čítajte zaregistrované faktory zo záznamu, nie z pamäti
Prvá otázka nie je, ktoré zariadenie sa stratilo, ale čo iné môže účet ešte použiť. Účet môže mať heslo plus push, časový kód, hardvérový kľúč a vytlačené záložné kódy, a strata jedného z nich je úplne iná udalosť ako strata jediného. Čítajte zoznam metód zo systému identity namiesto toho, aby ste používateľa žiadali, aby si ho pamätal, a v tenante Microsoft Entra je dopyt jeden riadok:
Get-MgUserAuthenticationMethod -UserId [email protected]
Potom napíšte záznam obnovy, kým účet ešte funguje: identifikátor účtu, zaregistrované faktory, kde žijú záložné kódy, kto môže nezávisle overiť žiadateľa a ku ktorým systémom sa účet dostane. Uchovávajte ho v chránenom inventári, ktorý tím už používa, nikdy v poznámke, ktorá obsahuje aj živé kódy. Týchto päť polí mení panický hovor na kontrolný zoznam a usmernenia NIST k životnému cyklu autentifikátora považujú obnovu za súčasť poverenia, nie za jeho výnimku.
Zaznamenajte overovací kanál ako samostatné pole, pretože práve túto časť ľudia preskakujú. Telefónne číslo pripojené k účtu nie je nezávislý kanál, keď človek, ktorý o niečo žiada, ovláda aj telefón.
Krok 2: overte žiadateľa mimo zlyhávajúcej cesty
Overenie identity veďte kanálom, ktorý nezávisí od VPN, schránky ani strateného zariadenia. Spätný hovor na číslo zo záznamu HR alebo osobné overenie u manažéra, ktorý už je v adresári, oboje funguje; správa v chate odoslaná z obnovovaného účtu nefunguje. Overenie sa týka osoby, nie jej schopnosti odpovedať na otázky o účte, pretože podrobnosti účtu unikajú. Zaznamenajte, kto požiadavku overil a kedy, pretože ďalší recenzent bude chcieť oboje.
Keď žiadosť príde s naliehavosťou a tlakom overenie preskočiť, to je okamih spomaliť. Podvod pri obnove vyzerá presne ako ochotný kolega, ktorý sa ponáhľa.
Krok 3: zaregistrujte náhradu a potom vyraďte starý faktor
Nový autentifikátor zaregistrujte bežným registračným tokom, nikdy administratívnym obchvatom. Potom stratenú metódu výslovne odstráňte, pretože registrácia náhrady ponecháva predchádzajúci autentifikátor autorizovaný, kým ho niekto nevyradí. Ak staré zariadenie môže byť v cudzích rukách, berte odstránenie ako naliehavé a postupujte podľa procesu incidentu, nie obnovy. Zrušte existujúce relácie v tom istom priechode, pretože relácia vytvorená pred zmenou ju môže prežiť:
Revoke-MgUserSignInSession -UserId [email protected]
Odstránenie faktora pre všetkých ostatných alebo zmiernenie kontrol certifikátu brány vymieňa obnovu jedného človeka za výpadok, ktorý zasiahne celé nasadenie. Držte zmenu v rozsahu jediného účtu a eskalujte, ak dôkazy ukazujú na širšiu kompromitáciu. V tikete poznamenajte, ktorý faktor bol vyradený a ktorý ho nahradil.
Krok 4: dokážte, že účet funguje oboma smermi
Prihláste sa raz novým faktorom cez podporovaného klienta a potom potvrďte, že účet stále dosiahne na prostriedky, na ktoré dosiahol pred stratou. Otestujte jeden prostriedok, ktorý potrebuje tunel, a jeden, ktorý ho nepotrebuje, aby zlyhanie ukazovalo na správnu vrstvu. Skúste prihlásenie s vyradeným faktorom a očakávajte odmietnutie, nie výzvu, čo dokazuje, že odstránenie zabralo. Výzva, ktorá zlyhá z existujúceho zaregistrovaného zariadenia je problém výzvy, nie dôvod znova registrovať všetko.
Potom požiadajte používateľa, aby rovnaké prihlásenie dokončil bez vedenia. Váš úspešný test dokazuje konfiguráciu; jeho pokus dokazuje odovzdanie.
Zatvorte tiket s časovou pečiatkou úspešného prihlásenia a názvom faktora, ktorý sa teraz používa. Aktualizujte záznam obnovy v tom istom priechode, aby budúca strata začala z presného inventára, nie zo zastaraného.
Krok 5: odstráňte podmienku, ktorá to robila bolestivým
Každý hovor o obnove je dôkazom o návrhu registrácie. Ak mal účet práve jeden faktor, vyžadujte druhý pre všetkých v tej skupine. Ak záložné kódy ležali na stratenom notebooku, zmeňte, kde žijú. Ak overenie potrebovalo manažéra na dovolenke, vymenujte zástupcu. Každá oprava zaberie popoludnie a odstráni najhoršiu hodinu budúceho incidentu.
Potom znova prečítajte záznam z prvého kroku proti realite. Uvádza faktory, ktoré skutočne existujú, a overovací kanál stále dosiahne na človeka? Prevádzková príručka, ktorú nikto neaktualizuje, sa rozpadá na dokument, ktorý ľudia počas hovoru, pre ktorý bola napísaná, ignorujú.