Неко изгуби телефон, а тикет стигне као VPN не ради. Тај оквир је погрешан двапут: налог још постоји, а пролаз још верује пружаоцу идентитета, па је једини покварени део један фактор који особа више не држи. Третирајте то као опоравак, а не као испад: проверите подносиоца захтева, региструјте замену, повуците изгубљени метод, па докажите да налог ради. Све то претпоставља да је план написан пре губитка, јер измишљање плана током позива је начин на који MFA на крају буде искључен за све.

Корак 1: прочитајте регистроване факторе из записа, а не из сећања

Прво питање није који је уређај изгубљен, него шта још налог може да користи. Налог може да носи лозинку плус push, временски код, хардверски кључ и одштампане кодове за опоравак, а губитак једног од њих је сасвим другачији догађај од губитка јединог. Читајте листу метода из система идентитета уместо да тражите од корисника да је памти, а у Microsoft Entra закупцу упит је један ред:

Get-MgUserAuthenticationMethod -UserId [email protected]

Затим напишите запис опоравка док налог још ради: идентификатор налога, регистровани фактори, где живе кодови за опоравак, ко може независно да провери подносиоца и којим системима налог приступа. Држите га у заштићеном инвентару који тим већ користи, никада у белешци која садржи и живе кодове. Тих пет поља претвара паничан позив у контролну листу, а NIST-ово упутство о животном циклусу аутентификатора третира опоравак као део акредитива, а не изузетак од њега.

Запишите канал провере као засебно поље, јер то је део који људи прескачу. Телефонски број везан за налог није независан канал када особа која тражи такође контролише телефон.

Корак 2: проверите подносиоца изван пута који не успева

Обавите проверу идентитета кроз канал који не зависи од VPN-а, поштанског сандучета или изгубљеног уређаја. Повратни позив на број из кадровског записа или лична провера код менаџера који је већ у именику обоје раде; порука у чети послата са налога који се опоравља не ради. Провера се тиче особе, а не њене способности да одговара на питања о налогу, јер детаљи налога цуре. Забележите ко је проверио захтев и када, јер ће следећи рецензент тражити обоје.

Када захтев стигне са хитношћу и притиском да се провера прескочи, то је тренутак да успорите. Превара при опоравку изгледа управо као услужни колега који жури.

Корак 3: региструјте замену, па повуците стари фактор

Региструјте нови аутентификатор кроз нормалан ток регистрације, никада кроз административно заобилажење. Затим експлицитно уклоните изгубљени метод, јер регистрација замене оставља претходни аутентификатор овлашћеним док га неко не повуче. Ако стари уређај може бити у туђим рукама, третирајте уклањање као хитно и следите процес инцидента, а не опоравка. Опозовите постојеће сесије у истом пролазу, јер сесија створена пре промене може је надживети:

Revoke-MgUserSignInSession -UserId [email protected]

Уклањање фактора за све остале или олабављивање провера сертификата пролаза мења опоравак једне особе за испад који погађа цело распоређивање. Држите промену унутар једног налога и ескалирајте ако докази указују на шири компромис. У тикету наведите који је фактор повучен и који га је заменио.

Корак 4: докажите да налог ради у оба смера

Пријавите се једном са новим фактором кроз подржани клијент, затим потврдите да налог још достиже ресурсе које је достигао пре губитка. Тестирајте један ресурс коме треба тунел и један коме не треба, да би квар указао на прави слој. Покушајте пријаву са повученим фактором и очекујте одбијање, а не упит, што доказује да је уклањање деловало. Изазов који не успева са постојећег регистрованог уређаја је проблем упита, а не разлог да поново региструјете све.

Затим замолите корисника да обави исту пријаву без навођења. Ваш успешан тест доказује конфигурацију; његов покушај доказује предају.

Затворите тикет са временском ознаком успешне пријаве и именом фактора који се сада користи. Ажурирајте запис опоравка у истом пролазу, да би следећи губитак почео од тачног инвентара, а не застарелог.

Корак 5: уклоните услов који је ово учинио болним

Сваки позив опоравка је доказ о дизајну регистрације. Ако је налог имао тачно један фактор, захтевајте други за све у тој групи. Ако су кодови за опоравак били на изгубљеном лаптопу, промените где живе. Ако је провера захтевала менаџера на одмору, именујте заменика. Свака поправка траје једно поподне и уклања најгори сат следећег инцидента.

Затим поново прочитајте запис из првог корака према стварности. Да ли наводи факторе који заиста постоје и да ли канал провере још достиже човека? Приручник који нико не ажурира претвара се у документ који људи игноришу током позива за који је написан.

Повезани чланци