Iemand verloor ’n selfoon en die kaartjie kom in as VPN wat stukkend is. Dié raamwerk is twee keer verkeerd: die rekening bestaan steeds, en die poort vertrou steeds die identiteitsverskaffer, so die enigste stukkende deel is een faktor wat iemand nie meer het nie. Hanteer dit as herstel eerder as as ’n onderbreking: verifieer die aanvraer, registreer ’n plaasvervanger, trek die verlore metode terug en bewys dan dat die rekening werk. Dit alles veronderstel dat die plan voor die verlies geskryf is, want om dit tydens die oproep te bedink is hoe MFA vir almal afgeskakel word.

Stap 1: lees die geregistreerde faktore uit ’n rekord, nie uit die geheue nie

Die eerste vraag is nie watter toestel verloor is nie, maar wat anders die rekening nog kan gebruik. ’n Rekening kan ’n wagwoord plus push, ’n tydgebaseerde kode, ’n hardewaresleutel en gedrukte herstelkodes hê, en om een daarvan te verloor is ’n heel ander gebeurtenis as om die enigste een te verloor. Lees die lys metodes uit die identiteitsstelsel eerder as om die gebruiker te vra om dit te onthou, en in ’n Microsoft Entra-huurder is die navraag een reël:

Get-MgUserAuthenticationMethod -UserId [email protected]

Skryf dan die herstelrekord terwyl die rekening nog werk: rekeningidentifiseerder, geregistreerde faktore, waar die herstelkodes leef, wie die aanvraer onafhanklik kan verifieer, en watter stelsels die rekening bereik. Hou dit in die beskermde inventaris wat die span reeds gebruik, nooit in ’n nota wat ook lewende kodes hou nie. Daardie vyf velde verander ’n paniekerige oproep in ’n kontrolelys, en NIST se riglyne vir die lewensiklus van verifikasiemiddels beskou herstel as deel van die geloofsbrief eerder as ’n uitsondering daarop.

Teken die verifikasiekanaal as ’n eie veld aan, want dit is die deel wat mense oorslaan. ’n Telefoonnommer wat aan die rekening gekoppel is, is nie ’n onafhanklike kanaal wanneer die persoon wat vra ook die telefoon beheer nie.

Stap 2: verifieer die aanvraer buite die foutiewe pad

Voer die identiteitskontrole uit deur ’n kanaal wat nie van die VPN, die posbus of die verlore toestel afhang nie. ’n Terugbel na ’n nommer uit die HR-rekord, of ’n persoonlike kontrole by ’n bestuurder wat reeds in die gids is, werk albei; ’n kletsboodskap wat vanaf die rekening onder herstel gestuur word, werk nie. Die kontrole gaan oor die persoon, nie oor hulle vermoë om vrae oor die rekening te beantwoord nie, want rekeningbesonderhede lek. Teken aan wie die versoek verifieer het en wanneer, aangesien die volgende keurder albei sal wil hê.

Wanneer die versoek met dringendheid en druk aankom om die kontrole oor te slaan, is dit die oomblik om te vertraag. Herstelbedrog lyk presies soos ’n behulpsame kollega wat haastig is.

Stap 3: registreer die plaasvervanger en trek dan die ou faktor terug

Registreer die nuwe verifikasiemiddel deur die normale registrasievloei, nooit deur ’n administratiewe omweg nie. Verwyder dan die verlore metode eksplisiet, want om ’n plaasvervanger te registreer laat die vorige verifikasiemiddel gemagtig totdat iemand dit terugtrek. As die ou toestel moontlik in iemand anders se hande is, hanteer die verwydering as dringend en volg die voorvalproses eerder as die herstelproses. Herroep bestaande sessies in dieselfde pas, aangesien ’n sessie wat voor die verandering geskep is, dit kan oorleef:

Revoke-MgUserSignInSession -UserId [email protected]

Om die faktor vir almal anders te verwyder, of om die poort se sertifikaatkontroles te verslap, ruil een persoon se herstel vir ’n onderbreking wat die hele ontplooiing raak. Hou die verandering beperk tot die enkele rekening en eskaleer as die bewyse op ’n wyer kompromittering dui. Noteer in die kaartjie watter faktor teruggetrek is en watter een dit vervang het.

Stap 4: bewys die rekening werk in beide rigtings

Meld een keer aan met die nuwe faktor deur ’n ondersteunde kliënt en bevestig dan dat die rekening steeds die hulpbronne bereik wat dit voor die verlies bereik het. Toets een hulpbron wat die tonnel nodig het en een wat dit nie nodig het nie, sodat ’n fout na die regte laag wys. Probeer ’n aanmelding met die teruggetrekte faktor en verwag ’n weiering eerder as ’n aansporing, wat bewys dat die verwydering effek gehad het. ’n Uitdaging wat van ’n bestaande geregistreerde toestel misluk is ’n aansporingsprobleem, nie ’n rede om alles weer te registreer nie.

Vra die gebruiker dan om dieselfde aanmelding sonder leiding te voltooi. Jou suksesvolle toets bewys die konfigurasie; hulle poging bewys die oorhandiging.

Sluit die kaartjie met die tydstempel van die suksesvolle aanmelding en die naam van die faktor wat nou in gebruik is. Werk die herstelrekord in dieselfde pas by, sodat die volgende verlies van ’n akkurate inventaris eerder as ’n verouderde een begin.

Stap 5: verwyder die toestand wat dit pynlik gemaak het

Elke hersteloproep is bewyse oor die registrasieontwerp. As die rekening presies een faktor gehad het, vereis ’n tweede vir almal in daardie groep. As die herstelkodes op die skootrekenaar gesit het wat verloor is, verander waar hulle leef. As verifikasie ’n bestuurder nodig gehad het wat op verlof was, noem ’n plaasvervanger. Elke regstelling neem ’n middag en verwyder die slegste uur van die volgende voorval.

Lees dan die rekord van stap een weer teen die werklikheid. Lys dit die faktore wat werklik bestaan, en bereik die verifikasiekanaal steeds ’n mens? ’n Runbook wat niemand bywerk nie, verval in ’n dokument wat mense ignoreer tydens die oproep waarvoor dit geskryf is.

Verwante artikels