Zagubiony autentykator VPN: wymiana bez wyłączania MFA

Ktoś gubi telefon, a zgłoszenie przychodzi jako zepsuty VPN. Ta rama jest błędna dwukrotnie: konto nadal istnieje, a brama nadal ufa dostawcy tożsamości, więc jedyną zepsutą częścią jest jeden czynnik, którego osoba już nie ma. Potraktuj to jako odzyskiwanie, a nie awarię: zweryfikuj wnioskodawcę, zarejestruj zamiennik, wycofaj utraconą metodę, a następnie udowodnij, że konto działa. Wszystko to zakłada, że plan napisano przed utratą, ponieważ wymyślanie go podczas rozmowy to droga, na której MFA ostatecznie zostaje wyłączone dla wszystkich.

Krok 1: czytaj zarejestrowane czynniki z rekordu, nie z pamięci

Pierwsze pytanie nie brzmi, które urządzenie zginęło, ale czego konto może jeszcze użyć. Konto może mieć hasło plus push, kod oparty na czasie, klucz sprzętowy i wydrukowane kody odzyskiwania, a utrata jednego z nich to zupełnie inne zdarzenie niż utrata jedynego. Czytaj listę metod z systemu tożsamości, zamiast prosić użytkownika o jej zapamiętanie, a w dzierżawie Microsoft Entra zapytanie to jedna linia:

Get-MgUserAuthenticationMethod -UserId [email protected]

Następnie zapisz rekord odzyskiwania, dopóki konto działa: identyfikator konta, zarejestrowane czynniki, gdzie mieszkają kody odzyskiwania, kto może niezależnie zweryfikować wnioskodawcę i do jakich systemów dociera konto. Trzymaj go w chronionym inwentarzu, którego zespół już używa, nigdy w notatce zawierającej także aktywne kody. Te pięć pól zamienia panikę w rozmowie w listę kontrolną, a wytyczne NIST dotyczące cyklu życia autentykatora traktują odzyskiwanie jako część poświadczenia, a nie wyjątek od niego.

Zapisz kanał weryfikacji jako osobne pole, ponieważ właśnie tę część ludzie pomijają. Numer telefonu przypisany do konta nie jest niezależnym kanałem, gdy osoba prosząca sama kontroluje telefon.

Krok 2: zweryfikuj wnioskodawcę poza zawodną ścieżką

Przeprowadź kontrolę tożsamości kanałem, który nie zależy od VPN, skrzynki pocztowej ani utraconego urządzenia. Oddzwonienie na numer z rekordu kadrowego albo osobista weryfikacja u menedżera, który jest już w katalogu, działają oba; wiadomość na czacie wysłana z odzyskiwanego konta nie działa. Kontrola dotyczy osoby, a nie jej zdolności do odpowiadania na pytania o konto, bo szczegóły konta wyciekają. Zapisz, kto zweryfikował wniosek i kiedy, ponieważ następny recenzent będzie chciał obu.

Gdy wniosek przychodzi z pośpiechem i presją pominięcia kontroli, to jest moment, by zwolnić. Oszustwo przy odzyskiwaniu wygląda dokładnie jak pomocny kolega w pośpiechu.

Krok 3: zarejestruj zamiennik, a potem wycofaj stary czynnik

Zarejestruj nowy autentykator normalnym przepływem rejestracji, nigdy przez obejście administracyjne. Następnie usuń utraconą metodę jawnie, ponieważ rejestracja zamiennika pozostawia poprzedni autentykator autoryzowanym, dopóki ktoś go nie wycofa. Jeśli stare urządzenie może być w cudzych rękach, potraktuj usunięcie jako pilne i podążaj procesem incydentu, a nie odzyskiwania. Unieważnij istniejące sesje w tym samym przebiegu, ponieważ sesja utworzona przed zmianą może ją przeżyć:

Revoke-MgUserSignInSession -UserId [email protected]

Usunięcie czynnika wszystkim innym albo złagodzenie kontroli certyfikatów bramy zamienia odzyskiwanie jednej osoby na awarię dotykającą całego wdrożenia. Utrzymaj zmianę w granicach jednego konta i eskaluj, jeśli dowody wskazują na szerszą kompromitację. Zanotuj w zgłoszeniu, który czynnik wycofano i który go zastąpił.

Krok 4: udowodnij, że konto działa w obu kierunkach

Zaloguj się raz nowym czynnikiem przez obsługiwanego klienta, a potem potwierdź, że konto nadal dociera do zasobów, do których docierało przed utratą. Przetestuj jeden zasób wymagający tunelu i jeden, który go nie wymaga, aby awaria wskazywała właściwą warstwę. Spróbuj logowania wycofanym czynnikiem i oczekuj odmowy, a nie monitu, co dowodzi, że usunięcie zadziałało. Wyzwanie, które zawodzi z istniejącego zarejestrowanego urządzenia to problem monitu, a nie powód, by wszystko rejestrować od nowa.

Następnie poproś użytkownika o wykonanie tego samego logowania bez podpowiedzi. Twój udany test dowodzi konfiguracji; jego próba dowodzi przekazania.

Zamknij zgłoszenie ze znacznikiem czasu udanego logowania i nazwą czynnika używanego teraz. Zaktualizuj rekord odzyskiwania w tym samym przebiegu, aby następna utrata zaczynała się od dokładnego inwentarza, a nie przestarzałego.

Krok 5: usuń warunek, który to utrudniał

Każda rozmowa o odzyskiwaniu jest dowodem o projekcie rejestracji. Jeśli konto miało dokładnie jeden czynnik, wymagaj drugiego dla wszystkich w tej grupie. Jeśli kody odzyskiwania leżały na utraconym laptopie, zmień, gdzie mieszkają. Jeśli weryfikacja wymagała menedżera na urlopie, wyznacz zastępcę. Każda poprawka zajmuje popołudnie i usuwa najgorszą godzinę następnego incydentu.

Następnie przeczytaj ponownie rekord z kroku pierwszego wobec rzeczywistości. Czy wymienia czynniki, które naprawdę istnieją, i czy kanał weryfikacji nadal dociera do człowieka? Instrukcja, której nikt nie aktualizuje, degraduje się do dokumentu ignorowanego podczas rozmowy, dla której ją napisano.