Ztracený VPN autentizátor: výměna bez vypnutí MFA
Ztracený faktor je úkol obnovy, ne výpadek. Ověřte mimo selhávající cestu, zaregistrujte náhradu, vyřaďte starou metodu a pak dokažte, že přihlášení funguje.
Někdo ztratí telefon a tiket dorazí jako VPN nefunguje. Toto zarámování je špatné dvakrát: účet stále existuje a brána stále důvěřuje poskytovateli identity, takže jediná rozbitá část je jeden faktor, který člověk už nemá. Berte to jako obnovu, ne jako výpadek: ověřte žadatele, zaregistrujte náhradu, vyřaďte ztracenou metodu a pak dokažte, že účet funguje. Všechno to předpokládá, že plán byl napsán před ztrátou, protože vymýšlet ho během hovoru je způsob, jak MFA nakonec skončí vypnuté pro všechny.
Krok 1: čtěte zaregistrované faktory ze záznamu, ne z paměti
První otázka není, které zařízení se ztratilo, ale co dalšího může účet ještě použít. Účet může mít heslo plus push, časový kód, hardwarový klíč a vytištěné záložní kódy, a ztráta jednoho z nich je zcela jiná událost než ztráta jediného. Čtěte seznam metod ze systému identity místo toho, abyste uživatele žádali, aby si ho pamatoval, a v tenantovi Microsoft Entra je dotaz jeden řádek:
Get-MgUserAuthenticationMethod -UserId [email protected]
Potom napište záznam obnovy, dokud účet ještě funguje: identifikátor účtu, zaregistrované faktory, kde žijí záložní kódy, kdo může nezávisle ověřit žadatele a ke kterým systémům se účet dostane. Uchovávejte ho v chráněném inventáři, který tým už používá, nikdy v poznámce, která obsahuje i živé kódy. Těchto pět polí mění panický hovor v kontrolní seznam a pokyny NIST k životnímu cyklu autentizátoru považují obnovu za součást pověření, ne za jeho výjimku.
Zaznamenejte ověřovací kanál jako samostatné pole, protože právě tuto část lidé přeskakují. Telefonní číslo připojené k účtu není nezávislý kanál, když člověk, který o něco žádá, ovládá i telefon.
Krok 2: ověřte žadatele mimo selhávající cestu
Ověření identity veďte kanálem, který nezávisí na VPN, schránce ani ztraceném zařízení. Zpětný hovor na číslo ze záznamu HR nebo osobní ověření u manažera, který už je v adresáři, obojí funguje; zpráva v chatu odeslaná z obnovovaného účtu nefunguje. Ověření se týká osoby, ne její schopnosti odpovídat na otázky o účtu, protože podrobnosti účtu unikají. Zaznamenejte, kdo požadavek ověřil a kdy, protože další recenzent bude chtít obojí.
Když žádost dorazí s naléhavostí a tlakem ověření přeskočit, to je okamžik zpomalit. Podvod při obnově vypadá přesně jako ochotný kolega, který spěchá.
Krok 3: zaregistrujte náhradu a pak vyřaďte starý faktor
Nový autentizátor zaregistrujte běžným registračním tokem, nikdy administrativním obchvatem. Potom ztracenou metodu výslovně odstraňte, protože registrace náhrady ponechává předchozí autentizátor autorizovaný, dokud ho někdo nevyřadí. Pokud staré zařízení může být v cizích rukou, berte odstranění jako naléhavé a postupujte podle procesu incidentu, ne obnovy. Zrušte existující relace ve stejném průchodu, protože relace vytvořená před změnou ji může přežít:
Revoke-MgUserSignInSession -UserId [email protected]
Odstranění faktoru pro všechny ostatní nebo zmírnění kontrol certifikátu brány vyměňuje obnovu jednoho člověka za výpadek, který zasáhne celé nasazení. Držte změnu v rozsahu jediného účtu a eskalujte, pokud důkazy ukazují na širší kompromitaci. V tiketu poznamenejte, který faktor byl vyřazen a který ho nahradil.
Krok 4: dokažte, že účet funguje oběma směry
Přihlaste se jednou novým faktorem přes podporovaného klienta a potom potvrďte, že účet stále dosáhne na prostředky, na které dosáhl před ztrátou. Otestujte jeden prostředek, který potřebuje tunel, a jeden, který ho nepotřebuje, aby selhání ukazovalo na správnou vrstvu. Zkuste přihlášení s vyřazeným faktorem a očekávejte odmítnutí, ne výzvu, což dokazuje, že odstranění zabralo. Výzva, která selže ze stávajícího zaregistrovaného zařízení je problém výzvy, ne důvod znovu registrovat všechno.
Potom požádejte uživatele, aby stejné přihlášení dokončil bez vedení. Váš úspěšný test dokazuje konfiguraci; jeho pokus dokazuje předání.
Zavřete tiket s časovým razítkem úspěšného přihlášení a názvem faktoru, který se nyní používá. Aktualizujte záznam obnovy ve stejném průchodu, aby příští ztráta začala z přesného inventáře, ne ze zastaralého.
Krok 5: odstraňte podmínku, která to dělala bolestivým
Každý hovor o obnově je důkazem o návrhu registrace. Pokud účet měl právě jeden faktor, vyžadujte druhý pro všechny v té skupině. Pokud záložní kódy ležely na ztraceném notebooku, změňte, kde žijí. Pokud ověření potřebovalo manažera na dovolené, jmenujte zástupce. Každá oprava zabere odpoledne a odstraní nejhorší hodinu příštího incidentu.
Potom znovu přečtěte záznam z prvního kroku proti realitě. Uvádí faktory, které skutečně existují, a ověřovací kanál stále dosáhne na člověka? Provozní příručka, kterou nikdo neaktualizuje, se rozpadá v dokument, který lidé během hovoru, pro který byl napsán, ignorují.