Nawalang VPN authenticator: palitan nang hindi pinapatay ang MFA

May nawalan ng telepono at dumarating ang ticket bilang sira ang VPN. Mali ang balangkas na iyon nang dalawang beses: buhay pa ang account, at nagtitiwala pa rin ang gateway sa identity provider, kaya ang tanging sirang bahagi ay isang factor na wala nang hawak ang tao. Tratuhin ito bilang pagbawi at hindi outage: i-verify ang humihiling, magparehistro ng kapalit, alisin ang nawalang paraan, at pagkatapos ay patunayan na gumagana ang account. Ang lahat ng ito ay nagpapalagay na ang plano ay isinulat bago ang pagkawala, dahil ang pag-imbento nito habang nasa tawag ang paraan kung paano nauuwi sa patay ang MFA para sa lahat.

Hakbang 1: basahin ang mga nakarehistrong factor mula sa rekord, hindi sa memorya

Ang unang tanong ay hindi kung aling device ang nawala, kundi ano pa ang magagamit ng account. Ang isang account ay maaaring may password at push, time-based code, hardware key at nakalimbag na recovery code, at ang mawala ang isa sa mga iyon ay ibang-iba sa mawala ang nag-iisa. Basahin ang listahan ng paraan mula sa identity system sa halip na hilingin sa user na tandaan ito, at sa isang Microsoft Entra tenant ang query ay isang linya:

Get-MgUserAuthenticationMethod -UserId [email protected]

Pagkatapos ay isulat ang recovery record habang gumagana pa ang account: identifier ng account, mga nakarehistrong factor, kung saan nakatira ang mga recovery code, sino ang makakapag-verify ng humihiling nang malaya, at aling mga system ang naaabot ng account. Itago ito sa protektadong imbentaryo na ginagamit na ng team, hindi kailanman sa note na may mga aktibong code rin. Ang limang field na iyon ay ginagawang checklist ang isang panikong tawag, at ang gabay ng NIST sa lifecycle ng authenticator ay itinuturing na bahagi ng credential ang pagbawi, hindi eksepsiyon dito.

Itala ang verification channel bilang sariling field, dahil iyon ang bahaging nilalaktawan ng mga tao. Ang numero ng telepono na nakakabit sa account ay hindi malayang channel kapag kontrolado rin ng humihiling ang telepono.

Hakbang 2: i-verify ang humihiling sa labas ng bumabagsak na landas

Gawin ang identity check sa channel na hindi umaasa sa VPN, mailbox o nawalang device. Ang callback sa numerong mula sa HR record, o personal na check sa manager na nasa directory na, gumagana ang dalawa; ang chat message na ipinadala mula sa account na binabawi ay hindi gumagana. Ang check ay tungkol sa tao, hindi sa kakayahang sagutin ang mga tanong tungkol sa account, dahil tumatagas ang detalye ng account. Itala kung sino ang nag-verify ng kahilingan at kailan, dahil kakailanganin ng susunod na reviewer ang dalawa.

Kapag dumating ang kahilingan na may pagmamadali at presyur na laktawan ang check, iyon ang sandali para bumagal. Ang recovery fraud ay mukhang eksaktong katulad ng matulunging katrabahong nagmamadali.

Hakbang 3: magparehistro ng kapalit, pagkatapos ay alisin ang lumang factor

Irehistro ang bagong authenticator sa normal na daloy ng pagpaparehistro, hindi kailanman sa administrative bypass. Pagkatapos ay tahasang alisin ang nawalang paraan, dahil ang pagpaparehistro ng kapalit ay nag-iiwan ng awtorisadong dating authenticator hanggang may mag-alis nito. Kung ang lumang device ay maaaring nasa kamay ng iba, ituring na urgent ang pag-alis at sundan ang proseso ng insidente, hindi ang proseso ng pagbawi. Bawiin ang mga umiiral na session sa parehong pagdaan, dahil ang session na ginawa bago ang pagbabago ay maaaring mabuhay nang mas mahaba kaysa rito:

Revoke-MgUserSignInSession -UserId [email protected]

Ang pag-alis ng factor para sa lahat ng iba, o pagluwag sa mga pagsusuri ng certificate ng gateway, ay ipinagpapalit ang pagbawi ng isang tao sa outage na tumatama sa buong deployment. Panatilihing limitado ang pagbabago sa nag-iisang account at i-escalate kung ang ebidensya ay tumuturo sa mas malawak na kompromiso. Itala sa ticket kung aling factor ang inalis at alin ang pumalit.

Hakbang 4: patunayan na gumagana ang account sa dalawang direksyon

Mag-log in nang isang beses gamit ang bagong factor sa sinusuportahang client, pagkatapos ay kumpirmahin na naaabot pa rin ng account ang mga resource na naabot nito bago ang pagkawala. Subukan ang isang resource na nangangailangan ng tunnel at isa na hindi, upang ang failure ay tumuro sa tamang layer. Subukang mag-log in gamit ang inalis na factor at asahan ang pagtanggi sa halip na prompt, na nagpapatunay na gumana ang pag-alis. Ang hamon na nabigo mula sa umiiral na nakarehistrong device ay problema sa prompt, hindi dahilan para muling i-register ang lahat.

Pagkatapos ay hilingin sa user na kumpletuhin ang parehong pag-login nang walang gabay. Ang matagumpay na pagsubok mo ay nagpapatunay ng configuration; ang pagtatangka niya ay nagpapatunay ng paglipat.

Isara ang ticket gamit ang timestamp ng matagumpay na pag-login at ang pangalan ng factor na ginagamit ngayon. I-update ang recovery record sa parehong pagdaan, upang ang susunod na pagkawala ay magsimula sa tumpak na imbentaryo at hindi sa luma.

Hakbang 5: alisin ang kundisyon na nagpahirap nito

Ang bawat tawag sa pagbawi ay ebidensya tungkol sa disenyo ng pagpaparehistro. Kung ang account ay may eksaktong isang factor, hilingin ang pangalawa para sa lahat sa grupong iyon. Kung ang mga recovery code ay nasa nawalang laptop, baguhin kung saan sila nakatira. Kung ang verification ay nangangailangan ng manager na nasa bakasyon, magtalaga ng kapalit. Ang bawat pagwawasto ay tumatagal ng isang hapon at nag-aalis ng pinakamasamang oras ng susunod na insidente.

Pagkatapos ay basahin muli ang record mula sa hakbang isa laban sa realidad. Itinatag ba nito ang mga factor na talagang umiiral, at naaabot pa ba ng verification channel ang isang tao? Ang manual na walang nag-a-update ay nagiging dokumentong binabalewala ng mga tao sa tawag kung saan ito isinulat.