Elveszett VPN-hitelesítő: csere az MFA kikapcsolása nélkül

Valaki elveszíti a telefonját, és a jegy úgy érkezik, hogy a VPN elromlott. Ez a keretezés kétszeresen hibás: a fiók még létezik, és az átjáró még mindig megbízik az identitásszolgáltatóban, tehát az egyetlen elromlott rész egy tényező, amely már nincs a személynél. Kezelje helyreállításként, nem kiesésként: ellenőrizze a kérelmezőt, regisztráljon cserét, vonja vissza az elveszett módszert, majd bizonyítsa, hogy a fiók működik. Mindez feltételezi, hogy a tervet az elvesztés előtt írták meg, mert a hívás közbeni kitalálása az az út, amelyen az MFA végül mindenkinél kikapcsolva végzi.

1. lépés: a regisztrált tényezőket rekordból olvassa ki, ne emlékezetből

Az első kérdés nem az, melyik eszköz veszett el, hanem hogy mi mást használhat még a fiók. Egy fiókon lehet jelszó plusz push, időalapú kód, hardverkulcs és kinyomtatott helyreállítási kódok, és ezek egyikének elvesztése egészen más esemény, mint az egyetlen elvesztése. A módszerek listáját az identitásrendszerből olvassa ki, ne a felhasználót kérje, hogy emlékezzen rá, és egy Microsoft Entra-bérlőben a lekérdezés egy sor:

Get-MgUserAuthenticationMethod -UserId [email protected]

Ezután írja meg a helyreállítási rekordot, amíg a fiók még működik: fiókazonosító, regisztrált tényezők, hol vannak a helyreállítási kódok, ki tudja függetlenül ellenőrizni a kérelmezőt, és mely rendszereket éri el a fiók. Tartsa a csapat által már használt védett leltárban, soha ne olyan jegyzetben, amely élő kódokat is tartalmaz. Ez az öt mező pánikoló hívást alakít át ellenőrzőlistává, és a NIST hitelesítő-életciklus útmutatása a helyreállítást a hitelesítő adat részének tekinti, nem kivételnek alóla.

Az ellenőrzési csatornát külön mezőként rögzítse, mert éppen ezt a részt hagyják ki az emberek. A fiókhoz kapcsolt telefonszám nem független csatorna, ha a kérdező maga is irányítja a telefont.

2. lépés: a kérelmezőt a hibás útvonalon kívül ellenőrizze

Az identitásellenőrzést olyan csatornán végezze, amely nem függ a VPN-től, a postaládától vagy az elveszett eszköztől. Visszahívás a HR-rekordból származó számra, vagy személyes ellenőrzés egy már a címtárban lévő vezetővel, mindkettő működik; a helyreállítás alatt álló fiókról küldött csevegőüzenet nem működik. Az ellenőrzés a személyről szól, nem arról, hogy tud-e válaszolni a fiókra vonatkozó kérdésekre, mert a fiók részletei kiszivárognak. Rögzítse, ki ellenőrizte a kérelmet és mikor, mert a következő bíráló mindkettőt kérni fogja.

Amikor a kérelem sürgetéssel és az ellenőrzés kihagyására irányuló nyomással érkezik, az a lassítás pillanata. A helyreállítási csalás pontosan úgy néz ki, mint egy siető segítőkész kolléga.

3. lépés: regisztrálja a cserét, majd vonja vissza a régi tényezőt

Az új hitelesítőt a normál regisztrációs folyamaton keresztül regisztrálja, soha nem adminisztratív megkerüléssel. Ezután kifejezetten távolítsa el az elveszett módszert, mert a csere regisztrálása engedélyezve hagyja az előző hitelesítőt, amíg valaki vissza nem vonja. Ha a régi eszköz más kezében lehet, kezelje az eltávolítást sürgősként, és az eseményfolyamatot kövesse a helyreállítási helyett. Vonja vissza a meglévő munkameneteket ugyanabban a menetben, mert a változás előtt létrehozott munkamenet túlélheti azt:

Revoke-MgUserSignInSession -UserId [email protected]

A tényező eltávolítása mindenki másnál, vagy az átjáró tanúsítványellenőrzéseinek lazítása egy ember helyreállítását egy egész telepítést érintő kiesésre cseréli. Tartsa a változtatást az egyetlen fiókra korlátozva, és eszkaláljon, ha a bizonyítékok szélesebb kompromittálódásra utalnak. Jegyezze fel a jegyben, melyik tényezőt vonták vissza, és melyik váltotta fel.

4. lépés: bizonyítsa, hogy a fiók mindkét irányban működik

Jelentkezzen be egyszer az új tényezővel egy támogatott kliensen keresztül, majd erősítse meg, hogy a fiók továbbra is eléri azokat az erőforrásokat, amelyeket az elvesztés előtt elért. Teszteljen egy erőforrást, amelyhez kell az alagút, és egyet, amelyhez nem, hogy a hiba a megfelelő rétegre mutasson. Próbáljon bejelentkezni a visszavont tényezővel, és elutasításra számítson, nem felszólításra, ami bizonyítja, hogy az eltávolítás hatályba lépett. Egy kihívás, amely egy meglévő regisztrált eszközről meghiúsul felszólítási probléma, nem ok arra, hogy mindent újraregisztráljon.

Ezután kérje meg a felhasználót, hogy ugyanezt a bejelentkezést útmutatás nélkül végezze el. Az Ön sikeres tesztje a konfigurációt bizonyítja; az ő kísérlete az átadást.

Zárja le a jegyet a sikeres bejelentkezés időbélyegével és a jelenleg használt tényező nevével. Frissítse a helyreállítási rekordot ugyanabban a menetben, hogy a következő elvesztés pontos leltárból induljon ki, ne elavultból.

5. lépés: távolítsa el a feltételt, amely fájdalmassá tette ezt

Minden helyreállítási hívás bizonyíték a regisztráció tervezéséről. Ha a fióknak pontosan egy tényezője volt, írjon elő másodikat a csoport minden tagjának. Ha a helyreállítási kódok az elveszett laptopon voltak, változtassa meg, hol vannak. Ha az ellenőrzéshez szabadságon lévő vezető kellett, nevezzen ki helyettest. Minden javítás egy délutánt vesz igénybe, és eltávolítja a következő esemény legrosszabb óráját.

Ezután olvassa újra az első lépés rekordját a valósággal szemben. Felsorolja-e a ténylegesen létező tényezőket, és eléri-e az ellenőrzési csatorna még mindig az embert? Az a kézikönyv, amelyet senki nem frissít, olyan dokumentummá válik, amelyet az emberek figyelmen kívül hagynak az alatt a hívás alatt, amelyre írták.