Pamestas VPN autentifikatorius: pakeisti neišjungiant MFA

Kažkas pameta telefoną, o bilietas atkeliauja kaip sugedęs VPN. Ši formuluotė klaidinga du kartus: paskyra vis dar egzistuoja, o šliuzas vis dar pasitiki tapatybės teikėju, tad vienintelė sugedusi dalis yra vienas veiksnys, kurio žmogus nebeturi. Traktuokite tai kaip atkūrimą, o ne kaip triktį: patikrinkite prašytoją, užregistruokite pakaitalą, atšaukite pamestą metodą ir tada įrodykite, kad paskyra veikia. Visa tai daro prielaidą, kad planas buvo parašytas prieš praradimą, nes jo kūrimas pokalbio metu yra kelias, kuriuo MFA galiausiai išjungiamas visiems.

1 žingsnis: skaitykite užregistruotus veiksnius iš įrašo, o ne iš atminties

Pirmas klausimas – ne kuris įrenginys pamestas, o ką dar paskyra gali naudoti. Paskyra gali turėti slaptažodį su push, laiku pagrįstą kodą, aparatinį raktą ir atspausdintus atkūrimo kodus, o vieno iš jų praradimas yra visiškai kitas įvykis nei vienintelio praradimas. Skaitykite metodų sąrašą iš tapatybės sistemos, o ne prašykite naudotojo jį atsiminti, ir Microsoft Entra nuomininke užklausa yra viena eilutė:

Get-MgUserAuthenticationMethod -UserId [email protected]

Tada parašykite atkūrimo įrašą, kol paskyra dar veikia: paskyros identifikatorius, užregistruoti veiksniai, kur gyvena atkūrimo kodai, kas gali nepriklausomai patikrinti prašytoją ir kokias sistemas pasiekia paskyra. Laikykite jį apsaugotame inventoriuje, kurį komanda jau naudoja, niekada pastaboje, kurioje taip pat yra aktyvių kodų. Tie penki laukai panikos skambutį paverčia kontroliniu sąrašu, o NIST autentifikatoriaus gyvavimo ciklo gairės atkūrimą laiko kredencialų dalimi, o ne išimtimi.

Užfiksuokite patikros kanalą kaip atskirą lauką, nes būtent šią dalį žmonės praleidžia. Prie paskyros prijungtas telefono numeris nėra nepriklausomas kanalas, kai prašantis asmuo taip pat valdo telefoną.

2 žingsnis: patikrinkite prašytoją už nepavykusio kelio

Atlikite tapatybės patikrą kanalu, kuris nepriklauso nuo VPN, pašto dėžutės ar pamesto įrenginio. Skambutis atgal į numerį iš personalo įrašo arba asmeninė patikra pas vadovą, kuris jau yra kataloge, veikia abu; pokalbio žinutė, išsiųsta iš atkuriamos paskyros, neveikia. Patikra susijusi su asmeniu, o ne su jo gebėjimu atsakyti į klausimus apie paskyrą, nes paskyros duomenys nuteka. Užregistruokite, kas patikrino prašymą ir kada, nes kitas peržiūrėtojas norės abiejų.

Kai prašymas ateina su skubumu ir spaudimu praleisti patikrą, tai yra momentas sulėtėti. Atkūrimo sukčiavimas atrodo lygiai kaip skubantis paslaugus kolega.

3 žingsnis: užregistruokite pakaitalą, tada atšaukite seną veiksnį

Užregistruokite naują autentifikatorių įprastu registracijos srautu, niekada administraciniu apėjimu. Tada aiškiai pašalinkite pamestą metodą, nes pakaitalo registracija palieka ankstesnį autentifikatorių įgaliotą tol, kol kas nors jį atšauks. Jei senas įrenginys gali būti kito žmogaus rankose, traktuokite pašalinimą kaip skubų ir vadovaukitės incidento procesu, o ne atkūrimo. Atšaukite esamas sesijas tame pačiame žingsnyje, nes sesija, sukurta prieš pakeitimą, gali jį pergyventi:

Revoke-MgUserSignInSession -UserId [email protected]

Veiksnio pašalinimas visiems kitiems arba šliuzo sertifikatų patikrų sušvelninimas maino vieno žmogaus atkūrimą į triktį, kuri paliečia visą diegimą. Laikykite pakeitimą vienoje paskyroje ir eskaluokite, jei įrodymai rodo platesnį kompromisą. Biliete pažymėkite, kuris veiksnys buvo atšauktas ir kuris jį pakeitė.

4 žingsnis: įrodykite, kad paskyra veikia abiem kryptimis

Prisijunkite vieną kartą su nauju veiksniu per palaikomą klientą, tada patvirtinkite, kad paskyra vis dar pasiekia išteklius, kuriuos pasiekė prieš praradimą. Išbandykite vieną išteklių, kuriam reikia tunelio, ir vieną, kuriam nereikia, kad triktis nurodytų tinkamą sluoksnį. Pabandykite prisijungti su atšauktu veiksniu ir tikėkitės atmetimo, o ne raginimo, tai įrodo, kad pašalinimas įsigaliojo. Iššūkis, kuris nepavyksta iš esamo užregistruoto įrenginio yra raginimo problema, o ne priežastis iš naujo registruoti viską.

Tada paprašykite naudotojo atlikti tą patį prisijungimą be patarimų. Jūsų sėkmingas testas įrodo konfigūraciją; jo bandymas įrodo perdavimą.

Uždarykite bilietą su sėkmingo prisijungimo laiko žyma ir dabar naudojamo veiksnio pavadinimu. Atnaujinkite atkūrimo įrašą tame pačiame žingsnyje, kad kitas praradimas prasidėtų nuo tikslaus inventoriaus, o ne pasenusio.

5 žingsnis: pašalinkite sąlygą, kuri padarė tai skaudžiu

Kiekvienas atkūrimo skambutis yra įrodymas apie registracijos dizainą. Jei paskyra turėjo tiksliai vieną veiksnį, reikalaukite antrojo visiems toje grupėje. Jei atkūrimo kodai buvo pamestame nešiojamajame kompiuteryje, pakeiskite, kur jie gyvena. Jei patikrai reikėjo atostogaujančio vadovo, paskirkite pavaduotoją. Kiekvienas pataisymas užima popietę ir pašalina blogiausią kito incidento valandą.

Tada dar kartą perskaitykite pirmo žingsnio įrašą prieš realybę. Ar jis išvardija veiksnius, kurie tikrai egzistuoja, ir ar patikros kanalas vis dar pasiekia žmogų? Vadovas, kurio niekas neatnaujina, virsta dokumentu, kurio žmonės nepaiso pokalbio, kuriam jis buvo parašytas, metu.