FortiGate VPN MFA: token lokal, RADIUS, atau SAML?

Setiap desain FortiGate VPN MFA menjawab satu pertanyaan lebih dulu: siapa yang memverifikasi faktor kedua? Gateway itu sendiri dapat melakukannya dengan token lokal atau kode yang dikirim lewat email, backend RADIUS dapat memaksakannya dan mengembalikan tantangan, atau penyedia identitas SAML dapat mengambil alih seluruh upacara di peramban. Masing-masing menghasilkan urutan masuk yang berbeda, jejak kegagalan yang berbeda, dan prosedur pemulihan yang berbeda, dan menyalin blok perintah di antara keduanya menghasilkan konfigurasi yang tampak masuk akal dan tidak mengautentikasi siapa pun. Ini adalah artikel mekanisme: apa yang sebenarnya dilakukan setiap desain saat masuk, dan di mana ia patah.

Upacara masuk menentukan siapa yang memiliki faktor

Pada dua desain pertama, FortiGate adalah pihak yang memercayai. Ia mengumpulkan kredensial, memutuskan apakah faktor kedua diperlukan, dan memverifikasinya secara lokal atau dengan meminta tantangan. Pada desain ketiga, gateway berhenti menjadi pemverifikasi dan menjadi penerus: ia mengalihkan klien ke penyedia identitas, menerima asersi, dan memetakan identitas yang ditegaskan ke pengguna dan grup. Pada desain RADIUS, ia berada di antaranya dan menjalankan pertukaran permintaan-jawaban dengan backend yang memegang kebijakan.

Perbedaan itu menentukan bukti apa yang dapat Anda kumpulkan. Saat gateway memverifikasi, keluaran debug-nya sendiri memberi tahu Anda apa yang terjadi. Saat penyedia identitas memverifikasi, gateway hanya tahu bahwa asersi telah tiba, dan jawaban atas «apakah MFA benar-benar diperlukan» ada di log penyedia, bukan di log firewall. Membaca log yang salah adalah cara paling umum untuk salah mendiagnosis peluncuran yang berperilaku persis seperti dirancang. Layanan itu sendiri juga membatasi upacara: FortiOS 7.6.3 menghapus mode terowongan SSL VPN demi IPsec, sementara mode web berlanjut sebagai Agentless VPN pada model yang didukung, sehingga upacara yang terbukti pada satu layanan tidak otomatis tersedia pada layanan lain.

Verifikasi lokal: token dan kode email

Faktor yang dikelola FortiGate melekat pada objek pengguna. FortiToken atau integrasi token yang terdokumentasi memerlukan pendaftaran, upacara verifikasi yang didukung, lisensi bila berlaku, dan prosedur penggantian. Kode lewat email memerlukan jalur SMTP yang berfungsi dan kotak surat yang dapat dijangkau pengguna sebelum terowongan ada, ketergantungan yang tidak ada hubungannya dengan kriptografi dan sepenuhnya berkaitan dengan apakah seseorang dapat masuk.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Pengiriman email adalah bagian dari ketersediaan autentikasi. Kotak surat yang hanya dapat dijangkau melalui VPN menciptakan putaran yang tidak selesai dengan sendirinya bagi siapa pun, dan penundaan pengiriman, masa berlaku kode, dan batas waktu autentikasi jarak jauh adalah tiga kendala terpisah. Menaikkan salah satunya tidak memperbaiki kotak surat yang tak terjangkau, dan desain yang tidak pernah menguji putaran itu akan menemukannya pada pengaturan ulang kata sandi pertama setelah liburan.

Persyaratan jaminan juga termasuk di sini, sebelum pemilihan produk. NIST SP 800-63B menganggap email tidak dapat diterima untuk autentikasi di luar pita, sehingga penerapan yang mengklaim kepatuhan tidak dapat memakai kode email sebagai faktor kedua, seberapa pun nyamannya. Adanya fitur pada perangkat bukan pernyataan bahwa fitur itu memenuhi standar tertentu.

RADIUS: gateway bertanya, backend memutuskan

Dengan RADIUS, FortiGate mengirim kredensial ke backend yang memiliki kebijakan faktor. Pertukarannya bisa berupa penerimaan atau penolakan biasa, atau bisa melibatkan tantangan yang harus dijawab klien, yang berarti layanan VPN dan klien keduanya harus mendukung bentuk tantangan itu. Backend yang memaksakan persetujuan push dan klien yang hanya tahu menambahkan kode enam digit ke kata sandi tidak akan bertemu di tengah.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Uji backend secara terpisah sebelum menyalahkan terowongan. Jika uji authserver berhasil dan login VPN tidak, perbedaannya ada pada penanganan tantangan, bukan pada kredensial, dan debug daemon autentikasi gateway adalah tempat hal itu terlihat:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: peramban meninggalkan gateway

Dalam desain SAML, klien dialihkan ke penyedia identitas, diautentikasi di sana, dan kembali dengan asersi yang divalidasi gateway terhadap hubungan kepercayaan dan pemetaan grup. Gateway tidak pernah melihat kata sandi atau faktor kedua, yang sekaligus merupakan peningkatan keamanan dan komplikasi operasional: kegagalan kini terjadi dalam sesi peramban yang tidak dapat diperiksa firewall.

Menerima asersi tidak membuktikan bahwa penyedia mewajibkan MFA untuk masuk tersebut. Kebijakan penyedia yang menerapkan MFA pada sebagian aplikasi dan tidak pada yang lain akan menghasilkan persis masuk yang Anda minta dan tidak sedikit pun jaminan yang Anda asumsikan. Periksa kebijakan penyedia untuk aplikasi khusus ini, dan periksa bahwa pemetaan klaim grup ke grup FortiGate masih cocok setelah penggantian nama di sisi mana pun.

Dukungan klien lebih penting di sini daripada di tempat lain. Sebagian klien VPN menangani penyerahan ke peramban secara asli, sebagian membuka peramban sistem, dan klien tanpa antarmuka atau baris perintah mungkin tidak menyelesaikan alur sama sekali. Uji dengan klien yang benar-benar dijalankan pengguna, pada platform yang benar-benar mereka gunakan, sebelum menerbitkan profil.

Pemulihan adalah bagian dari mekanisme

Setiap desain di atas memiliki ketergantungan yang dapat gagal bagi satu pengguna pada satu waktu: kotak surat tak terjangkau, token hilang, backend yang menolak tantangan, akun penyedia identitas yang terkunci. Putuskan sekarang siapa yang dapat memulihkan akses, melalui prosedur mana yang didukung, dan dengan verifikasi apa atas orang yang meminta. Akun administrator lokal darurat yang dijaga terpisah dari jalur VPN adalah sebuah kontrol; dan pengabaian tanpa penjelasan yang hanya memakai kata sandi adalah insiden yang menunggu ditemukan.

Lalu uji tiga login sebelum peluncuran: yang normal, faktor yang ditolak atau kedaluwarsa, dan pemulihan autentikator hilang yang disetujui. Catat di log mana masing-masing muncul. Catatan itulah yang mengubah «MFA aktif» menjadi desain yang dapat dijalankan orang lain.