Изгубен VPN автентикатор: замена без исклучување на MFA

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

Чекор 1: читајте ги регистрираните фактори од запис, а не од меморија

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

Get-MgUserAuthenticationMethod -UserId [email protected]

Потоа напишете го записот за обновување додека сметката се уште работи: идентификатор на сметката, регистрирани фактори, каде живеат кодовите за обновување, кој може независно да го провери барателот и до кои системи стигнува сметката. Чувајте го во заштитениот инвентар што тимот веќе го користи, никогаш во белешка што содржи и активни кодови. Тие пет полиња паничниот повик го претвораат во контролна листа, а упатството на NIST за животниот циклус на автентикаторот го третира обновувањето како дел од акредитивот, а не како исклучок.

Запишете го каналот за проверка како посебно поле, бидејќи токму тој дел луѓето го прескокнуваат. Телефонски број поврзан со сметката не е независен канал кога лицето што бара исто така го контролира телефонот.

Чекор 2: проверете го барателот надвор од патеката што не успева

Извршете ја проверката на идентитетот преку канал што не зависи од VPN, поштенското сандаче или изгубениот уред. Повратен повик на број од кадровиот запис или лична проверка кај менаџер што веќе е во директориумот функционираат и двете; порака во чет испратена од сметката во обновување не функционира. Проверката се однесува на лицето, а не на неговата способност да одговара на прашања за сметката, бидејќи деталите на сметката истекуваат. Запишете кој го проверил барањето и кога, бидејќи следниот прегледувач ќе ги сака двете.

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

Чекор 3: регистрирајте ја замената, потоа повлечете го стариот фактор

Регистрирајте го новиот автентикатор преку нормалниот тек на регистрација, никогаш преку административно заобиколување. Потоа експлицитно отстранете го изгубениот метод, бидејќи регистрацијата на замена го остава претходниот автентикатор овластен додека некој не го повлече. Ако стариот уред може да е во туѓи раце, третирајте го отстранувањето како итно и следете го процесот за инциденти, а не оној за обновување. Откажете ги постоечките сесии во истиот чекор, бидејќи сесија создадена пред промената може да ја надживее:

Revoke-MgUserSignInSession -UserId [email protected]

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

Чекор 4: докажете дека сметката работи во двете насоки

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

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

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

Чекор 5: отстранете го условот што го направи ова болно

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

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