Autentikator VPN hilang: ganti tanpa menonaktifkan MFA

Seseorang kehilangan ponsel dan tiketnya datang sebagai VPN rusak. Kerangka itu salah dua kali: akun masih ada, dan gateway masih memercayai penyedia identitas, jadi satu-satunya bagian yang rusak adalah satu faktor yang tidak lagi dipegang orang itu. Perlakukan sebagai pemulihan, bukan sebagai gangguan: verifikasi pemohon, daftarkan pengganti, pensiunkan metode yang hilang, lalu buktikan akun berfungsi. Semua itu mengasumsikan rencananya ditulis sebelum kehilangan, karena mengarangnya saat panggilan adalah cara MFA akhirnya dimatikan untuk semua orang.

Langkah 1: baca faktor terdaftar dari catatan, bukan dari ingatan

Pertanyaan pertama bukan perangkat mana yang hilang, melainkan apa lagi yang masih bisa dipakai akun. Akun bisa membawa kata sandi plus push, kode berbasis waktu, kunci perangkat keras, dan kode pemulihan tercetak, dan kehilangan salah satunya adalah peristiwa yang sangat berbeda dari kehilangan satu-satunya. Baca daftar metode dari sistem identitas alih-alih meminta pengguna mengingatnya, dan di penyewa Microsoft Entra kuerinya satu baris:

Get-MgUserAuthenticationMethod -UserId [email protected]

Lalu tulis catatan pemulihan selama akun masih berfungsi: pengenal akun, faktor terdaftar, tempat kode pemulihan berada, siapa yang dapat memverifikasi pemohon secara independen, dan sistem mana yang dicapai akun. Simpan di inventaris terlindungi yang sudah dipakai tim, jangan pernah di catatan yang juga berisi kode aktif. Kelima bidang itu mengubah panggilan panik menjadi daftar periksa, dan panduan NIST tentang siklus hidup autentikator memperlakukan pemulihan sebagai bagian dari kredensial, bukan pengecualian darinya.

Catat kanal verifikasi sebagai bidang tersendiri, karena bagian itulah yang dilewati orang. Nomor telepon yang terpasang pada akun bukan kanal independen ketika orang yang meminta juga mengendalikan telepon.

Langkah 2: verifikasi pemohon di luar jalur yang gagal

Lakukan pemeriksaan identitas melalui kanal yang tidak bergantung pada VPN, kotak surat, atau perangkat yang hilang. Panggilan balik ke nomor dari catatan SDM, atau pemeriksaan langsung dengan manajer yang sudah ada di direktori, keduanya berfungsi; pesan obrolan yang dikirim dari akun yang sedang dipulihkan tidak berfungsi. Pemeriksaan itu tentang orangnya, bukan tentang kemampuannya menjawab pertanyaan tentang akun, karena detail akun bocor. Catat siapa yang memverifikasi permintaan dan kapan, sebab peninjau berikutnya akan membutuhkan keduanya.

Ketika permintaan datang dengan urgensi dan tekanan untuk melewati pemeriksaan, itulah saatnya melambat. Penipuan pemulihan terlihat persis seperti rekan kerja yang membantu dan sedang terburu-buru.

Langkah 3: daftarkan pengganti, lalu pensiunkan faktor lama

Daftarkan autentikator baru melalui alur pendaftaran normal, jangan pernah melalui jalan pintas administratif. Lalu hapus metode yang hilang secara eksplisit, karena mendaftarkan pengganti membuat autentikator sebelumnya tetap berwenang sampai seseorang memensiunkannya. Jika perangkat lama mungkin berada di tangan orang lain, perlakukan penghapusan sebagai mendesak dan ikuti proses insiden, bukan proses pemulihan. Cabut sesi yang ada pada langkah yang sama, karena sesi yang dibuat sebelum perubahan bisa hidup lebih lama darinya:

Revoke-MgUserSignInSession -UserId [email protected]

Menghapus faktor untuk semua orang lain, atau melonggarkan pemeriksaan sertifikat gateway, menukar pemulihan satu orang dengan gangguan yang menyentuh seluruh penerapan. Jaga perubahan tetap terbatas pada satu akun dan eskalasi jika bukti mengarah ke kompromi yang lebih luas. Catat di tiket faktor mana yang dipensiunkan dan mana yang menggantikannya.

Langkah 4: buktikan akun berfungsi di kedua arah

Masuk sekali dengan faktor baru melalui klien yang didukung, lalu pastikan akun masih mencapai sumber daya yang dicapainya sebelum kehilangan. Uji satu sumber daya yang membutuhkan terowongan dan satu yang tidak, agar kegagalan menunjuk lapisan yang tepat. Coba login dengan faktor yang dipensiunkan dan harapkan penolakan, bukan prompt, yang membuktikan penghapusan berlaku. Tantangan yang gagal dari perangkat terdaftar yang sudah ada adalah masalah prompt, bukan alasan untuk mendaftarkan ulang semuanya.

Lalu minta pengguna menyelesaikan login yang sama tanpa pendampingan. Uji Anda yang berhasil membuktikan konfigurasi; upaya mereka membuktikan serah terima.

Tutup tiket dengan stempel waktu login berhasil dan nama faktor yang sekarang dipakai. Perbarui catatan pemulihan pada langkah yang sama, agar kehilangan berikutnya dimulai dari inventaris yang akurat, bukan yang basi.

Langkah 5: hapus kondisi yang membuat ini menyakitkan

Setiap panggilan pemulihan adalah bukti tentang desain pendaftaran. Jika akun hanya punya satu faktor, wajibkan faktor kedua bagi semua orang di grup itu. Jika kode pemulihan ada di laptop yang hilang, ubah tempat penyimpanannya. Jika verifikasi membutuhkan manajer yang sedang cuti, tunjuk wakil. Setiap perbaikan memakan satu sore dan menghapus jam terburuk dari insiden berikutnya.

Lalu baca ulang catatan dari langkah satu terhadap kenyataan. Apakah ia mendaftar faktor yang benar-benar ada, dan apakah kanal verifikasi masih menjangkau manusia? Buku panduan yang tidak diperbarui siapa pun membusuk menjadi dokumen yang diabaikan orang selama panggilan yang menjadi alasan penulisannya.