Seseorang kehilangan telefon dan tiket tiba sebagai VPN rosak. Bingkai itu salah dua kali: akaun masih wujud, dan gerbang masih mempercayai pembekal identiti, jadi satu-satunya bahagian rosak ialah satu faktor yang tidak lagi dipegang oleh orang itu. Layannya sebagai pemulihan, bukan gangguan: sahkan pemohon, daftarkan pengganti, tarik balik kaedah yang hilang, kemudian buktikan akaun berfungsi. Semua ini menganggap pelan telah ditulis sebelum kehilangan, kerana menciptanya semasa panggilan ialah cara MFA akhirnya dimatikan untuk semua orang.

Langkah 1: baca faktor berdaftar daripada rekod, bukan daripada ingatan

Soalan pertama bukan peranti mana yang hilang, tetapi apa lagi yang masih boleh digunakan oleh akaun. Akaun boleh membawa kata laluan serta push, kod berasaskan masa, kunci perkakasan dan kod pemulihan bercetak, dan kehilangan salah satunya ialah peristiwa yang sangat berbeza daripada kehilangan satu-satunya. Baca senarai kaedah daripada sistem identiti dan bukan meminta pengguna mengingatinya, dan dalam penyewa Microsoft Entra pertanyaannya satu baris:

Get-MgUserAuthenticationMethod -UserId [email protected]

Kemudian tulis rekod pemulihan semasa akaun masih berfungsi: pengecam akaun, faktor berdaftar, tempat kod pemulihan tinggal, siapa yang boleh mengesahkan pemohon secara bebas, dan sistem mana yang dicapai oleh akaun. Simpan dalam inventori terlindung yang sudah digunakan oleh pasukan, jangan sekali-kali dalam nota yang juga mengandungi kod aktif. Kelima-lima medan itu menjadikan panggilan panik sebagai senarai semak, dan panduan NIST tentang kitaran hayat pengesah menganggap pemulihan sebagai bahagian kelayakan, bukan pengecualian daripadanya.

Rekodkan saluran pengesahan sebagai medan tersendiri, kerana bahagian itulah yang dilangkau oleh orang. Nombor telefon yang dipautkan pada akaun bukan saluran bebas apabila orang yang meminta juga mengawal telefon.

Langkah 2: sahkan pemohon di luar laluan yang gagal

Lakukan pemeriksaan identiti melalui saluran yang tidak bergantung pada VPN, peti mel atau peranti yang hilang. Panggilan balik ke nombor daripada rekod sumber manusia, atau pemeriksaan bersemuka dengan pengurus yang sudah ada dalam direktori, kedua-duanya berfungsi; mesej sembang yang dihantar daripada akaun yang sedang dipulihkan tidak berfungsi. Pemeriksaan itu tentang orang itu, bukan tentang keupayaannya menjawab soalan tentang akaun, kerana butiran akaun bocor. Rekodkan siapa yang mengesahkan permintaan dan bila, kerana penyemak seterusnya akan mahukan kedua-duanya.

Apabila permintaan tiba dengan desakan dan tekanan untuk melangkau pemeriksaan, itulah saatnya memperlahankan. Penipuan pemulihan kelihatan sama seperti rakan sekerja yang membantu dan tergesa-gesa.

Langkah 3: daftarkan pengganti, kemudian tarik balik faktor lama

Daftarkan pengesah baharu melalui aliran pendaftaran biasa, jangan sekali-kali melalui pintasan pentadbiran. Kemudian buang kaedah yang hilang secara eksplisit, kerana mendaftarkan pengganti membiarkan pengesah sebelumnya diberi kuasa sehingga seseorang menariknya balik. Jika peranti lama mungkin berada di tangan orang lain, anggap pembuangan itu mendesak dan ikuti proses insiden dan bukan proses pemulihan. Batalkan sesi sedia ada dalam pas yang sama, kerana sesi yang dicipta sebelum perubahan boleh hidup lebih lama daripadanya:

Revoke-MgUserSignInSession -UserId [email protected]

Membuang faktor itu untuk semua orang lain, atau melonggarkan pemeriksaan sijil gerbang, menukar pemulihan seorang dengan gangguan yang menyentuh keseluruhan penggunaan. Kekalkan perubahan itu terbatas kepada akaun tunggal dan eskalasi jika bukti menunjukkan kompromi yang lebih luas. Catat dalam tiket faktor mana yang ditarik balik dan mana yang menggantikannya.

Langkah 4: buktikan akaun berfungsi dalam kedua-dua arah

Log masuk sekali dengan faktor baharu melalui klien yang disokong, kemudian sahkan akaun masih mencapai sumber yang dicapainya sebelum kehilangan. Uji satu sumber yang memerlukan terowong dan satu yang tidak, supaya kegagalan menunjukkan lapisan yang betul. Cuba log masuk dengan faktor yang ditarik balik dan jangkakan penolakan dan bukan gesaan, yang membuktikan pembuangan berkesan. Cabaran yang gagal daripada peranti berdaftar sedia ada ialah masalah gesaan, bukan alasan untuk mendaftar semula segala-galanya.

Kemudian minta pengguna menyelesaikan log masuk yang sama tanpa bimbingan. Ujian anda yang berjaya membuktikan konfigurasi; percubaan mereka membuktikan penyerahan.

Tutup tiket dengan cap masa log masuk berjaya dan nama faktor yang kini digunakan. Kemas kini rekod pemulihan dalam pas yang sama, supaya kehilangan seterusnya bermula daripada inventori yang tepat dan bukan yang lapuk.

Langkah 5: buang syarat yang menjadikan ini menyakitkan

Setiap panggilan pemulihan ialah bukti tentang reka bentuk pendaftaran. Jika akaun mempunyai tepat satu faktor, wajibkan yang kedua untuk semua orang dalam kumpulan itu. Jika kod pemulihan berada pada komputer riba yang hilang, ubah tempat ia tinggal. Jika pengesahan memerlukan pengurus yang bercuti, lantik timbalan. Setiap pembetulan mengambil satu petang dan membuang jam terburuk insiden seterusnya.

Kemudian baca semula rekod langkah satu terhadap realiti. Adakah ia menyenaraikan faktor yang benar-benar wujud, dan adakah saluran pengesahan masih sampai kepada manusia? Buku panduan yang tidak dikemas kini oleh sesiapa merosot menjadi dokumen yang diabaikan orang semasa panggilan yang menjadi sebab ia ditulis.

Artikel berkaitan