Загубен VPN автентикатор: подмяна без изключване на MFA

Някой губи телефона си и тикетът пристига като „VPN е счупен“. Тази рамка е погрешна два пъти: профилът все още съществува и шлюзът все още се доверява на доставчика на идентичност, така че единствената счупена част е един фактор, който човекът вече не притежава. Третирайте го като възстановяване, а не като авария: проверете заявителя, регистрирайте замяна, оттеглете загубения метод, после докажете, че профилът работи. Всичко това предполага, че планът е написан преди загубата, защото измислянето му по време на разговора е начинът, по който MFA в крайна сметка се изключва за всички.

Стъпка 1: четете регистрираните фактори от запис, а не от паметта

Първият въпрос не е кой апарат е загубен, а какво друго профилът все още може да използва. Профилът може да носи парола плюс push, код, базиран на време, хардуерен ключ и разпечатани кодове за възстановяване, и загубата на един от тях е събитие, съвсем различно от загубата на единствения. Четете списъка с методи от системата за идентичност, вместо да молите потребителя да го помни, а в наемател на Microsoft Entra заявката е един ред:

Get-MgUserAuthenticationMethod -UserId [email protected]

След това напишете записа за възстановяване, докато профилът още работи: идентификатор на профила, регистрирани фактори, къде живеят кодовете за възстановяване, кой може независимо да провери заявителя и кои системи достига профилът. Дръжте го в защитения инвентар, който екипът вече използва, никога в бележка, която също съдържа живи кодове. Тези пет полета превръщат паникьосаното обаждане в контролен списък и ръководството на NIST за жизнения цикъл на автентикатора третира възстановяването като част от удостоверението, а не изключение от него.

Запишете канала за проверка като отделно поле, защото точно тази част хората пропускат. Телефонен номер, прикачен към профила, не е независим канал, когато човекът, който пита, също контролира телефона.

Стъпка 2: проверете заявителя извън дефектиралия път

Извършете проверката на идентичността през канал, който не зависи от VPN, пощенската кутия или загубения апарат. Обратно обаждане на номер от HR записа или проверка на място с мениджър, който вече е в указателя, и двете работят; съобщение в чат, изпратено от профила под възстановяване, не работи. Проверката е за човека, а не за способността му да отговаря на въпроси за профила, защото детайлите на профила изтичат. Регистрирайте кой е проверил заявката и кога, тъй като следващият преглеждащ ще иска и двете.

Когато заявката пристигне със спешност и натиск да се пропусне проверката, това е моментът да се забавите. Измамата при възстановяване изглежда точно като услужлив колега, който бърза.

Стъпка 3: регистрирайте замяната, после оттеглете стария фактор

Регистрирайте новия автентикатор през нормалния поток за регистрация, никога през административно заобикаляне. След това премахнете загубения метод изрично, защото регистрирането на замяна оставя предишния автентикатор оторизиран, докато някой не го оттегли. Ако старият апарат може да е в чужди ръце, третирайте премахването като спешно и следвайте процеса за инциденти, а не този за възстановяване. Отменете съществуващите сесии в същия проход, тъй като сесия, създадена преди промяната, може да я надживее:

Revoke-MgUserSignInSession -UserId [email protected]

Премахването на фактора за всички останали или разхлабването на проверките на сертификата на шлюза заменя възстановяването на един човек с авария, която засяга цялото внедряване. Дръжте промяната в обхвата на единствения профил и ескалирайте, ако доказателствата сочат по-широк компромис. Отбележете в тикета кой фактор е оттеглен и кой го е заменил.

Стъпка 4: докажете, че профилът работи в двете посоки

Влезте веднъж с новия фактор през поддържан клиент, после потвърдете, че профилът все още достига ресурсите, които е достигал преди загубата. Тествайте един ресурс, който се нуждае от тунела, и един, който не, така че отказ да сочи към правилния слой. Опитайте вход с оттегления фактор и очаквайте отказ, а не подкана, което доказва, че премахването е подействало. Предизвикателство, което се проваля от съществуващ регистриран апарат е проблем с подканата, а не причина да пререгистрирате всичко.

След това помолете потребителя да изпълни същия вход без напътствия. Вашият успешен тест доказва конфигурацията; неговият опит доказва предаването.

Затворете тикета с времевия печат на успешния вход и името на фактора, който се използва сега. Актуализирайте записа за възстановяване в същия проход, така че следващата загуба да започне от точен инвентар, а не от остарял.

Стъпка 5: премахнете условието, което направи това болезнено

Всяко обаждане за възстановяване е доказателство за дизайна на регистрацията. Ако профилът е имал точно един фактор, изисквайте втори за всички в тази група. Ако кодовете за възстановяване са били на загубения лаптоп, сменете къде живеят. Ако проверката е изисквала мениджър в отпуск, посочете заместник. Всяка поправка отнема един следобед и премахва най-лошия час от следващия инцидент.

След това препрочетете записа от първата стъпка срещу реалността. Изброява ли факторите, които наистина съществуват, и достига ли каналът за проверка все още до човек? Ръководство, което никой не обновява, се превръща в документ, който хората игнорират по време на обаждането, за което е написано.