Layanan MFA mati: putuskan akses VPN sebelum gagal

Akses VPN berhenti, dan peringatan menyebut layanan faktor kedua tidak dapat dijangkau. Apakah seseorang masih bisa terhubung adalah pertanyaan kebijakan yang seharusnya dijawab sebelum gangguan, bukan saat gangguan. Pemverifikasi yang tidak tersedia bukan bukti bahwa suatu faktor lolos, dan tantangan yang ditolak bukan peristiwa yang sama dengan yang tak terjangkau. Runbook di bawah mengubah perbedaan itu menjadi aturan tertulis yang dapat Anda uji.

Langkah 1: sebutkan ketiga hasil secara terpisah

Tuliskan tiga keadaan dan tolak untuk menggabungkannya: autentikasi primer gagal, tantangan faktor kedua ditolak atau kedaluwarsa, dan layanan MFA tidak pernah menjawab. Masing-masing punya pemilik berbeda, baris log berbeda, dan respons benar yang berbeda. Satu pesan batas waktu generik menyembunyikan yang mana Anda alami, dan ambiguitas itulah yang mengubah gangguan menjadi perdebatan. Sebutkan keadaan itu di runbook sebelum Anda membutuhkannya.

Penolakan berarti pemverifikasi menjawab dan berkata tidak, yang merupakan hasil kebijakan, bukan masalah ketersediaan. Percobaan kedaluwarsa berarti tantangan ada dan tidak ada yang menyelesaikannya tepat waktu. Layanan tak terjangkau berarti pertanyaannya sama sekali tidak dijawab. Hanya yang ketiga adalah gangguan.

Langkah 2: baca mode kegagalan yang benar-benar dipakai proxy

Temukan pengaturan yang mengatur perilaku saat layanan tidak dapat dihubungi, dan bacalah dari konfigurasi yang berjalan, bukan dari templat. Di proxy RADIUS Duo, nilai failmode yang didokumentasikan adalah safe dan secure, dengan safe hanya mengizinkan percobaan bila autentikasi primer berhasil, dan secure menolak percobaan dalam kondisi itu.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Nama safe menggambarkan pilihan ketersediaan, bukan jaminan bahwa setiap sesi yang diterima punya faktor kedua yang baru. Kalimat itu masuk ke daftar risiko, karena itulah tepatnya pertukaran yang dibuat pengaturan ini. Jangan menggeneralisasi nilainya ke penyedia lain, integrasi lain, atau mode proxy yang berbeda; baca dokumentasi produk itu untuk padanannya sendiri. Konfigurasi yang disalin dari contoh vendor tanpa pemahaman ini adalah kejutan yang menunggu gangguan berikutnya.

Berhenti jika tidak ada yang bisa menyebut mode mana yang aktif. Sisa runbook bergantung pada jawaban itu.

Langkah 3: selaraskan percobaan ulang dengan alur

Selaraskan batas waktu dan perilaku percobaan ulang gateway dengan alur autentikasi yang dijalankannya. Percobaan ulang yang tidak terkoordinasi menciptakan banyak permintaan, mengacaukan pencocokan percobaan, dan membuat log tidak bisa menyebut hasil mana milik login mana. Batas waktu yang sangat panjang bukan desain ketersediaan; itu penantian lebih lama untuk jawaban yang sama.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Batas waktu permintaan milik proxy adalah batas terpisah: permintaan autentikasi yang dikirim dan tidak pernah selesai akan ditolak, dan penolakan itu bukan gangguan yang bisa dihindari dengan mundur. Perlakukan penolakan, tantangan yang belum selesai, dan layanan tak terjangkau sebagai tiga masukan berbeda pada tabel keputusan Anda. Lalu buat tabel itu eksplisit: keadaan mana yang menerima, keadaan mana yang menahan, dan keadaan mana yang dieskalasi ke manusia.

Jika dua komponen sama-sama mencoba ulang, perbaiki dulu kepemilikan percobaan ulang. Permintaan ganda adalah gejala dua pemilik, bukan layanan yang lambat.

Langkah 4: kelola akses darurat secara terpisah

Jika akses darurat diperlukan, beri ia cakupan, identitas, otorisasi, dan jejak audit sendiri. Menonaktifkan MFA secara diam-diam untuk semua pengguna bukan prosedur darurat; itu pelemahan permanen dengan insiden menempel padanya. Pemilik keamanan menyetujui aturan penerimaan, visibilitas, dan jalur eskalasi lebih dulu.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Uji seluruh matriks di lingkungan non-produksi: kegagalan primer, penolakan sengaja, kedaluwarsa tantangan, dan ketidaktersediaan layanan. Untuk masing-masing, catat hasil penerimaan dan alasan yang tercatat di log. Jangan membuat gangguan produksi untuk menemukan perilaku yang dikonfigurasi, dan jangan menguji jalur darurat untuk pertama kalinya selama insiden yang menjadi alasan penulisannya. Prosedur pemulihan yang belum pernah berjalan adalah dokumen, bukan kendali.

Runbook berakhir ketika ketiga keadaan sudah disebut, mode kegagalan dibaca dari sistem yang berjalan, percobaan ulang punya satu pemilik, dan akses darurat punya persetujuan serta tinjauannya sendiri. Penegakan yang dapat diprediksi plus jalur pemulihan yang dikenal adalah hasil yang layak didokumentasikan.