Mengapa MFA Tidak Berjalan Padahal Seharusnya Berjalan di Lingkungan Microsoft

By Mirko Peters · 2026-04-22

Autentikasi multi-faktor (MFA) seharusnya menjadi jaring pengaman Anda di Microsoft 365 dan Azure, yang menghentikan penyerang meskipun mereka berhasil mencuri kata sandi. Namun, apa yang terjadi ketika jaring pengaman itu tidak ada, padahal seharusnya ada? …

Automatically translated with AI from the original post. Read the English original

Autentikasi multi-faktor (MFA) seharusnya menjadi jaring pengaman Anda di Microsoft 365 dan Azure, yang menghentikan penyerang meskipun mereka berhasil mencuri kata sandi. Namun, apa yang terjadi ketika jaring pengaman itu tidak ada, padahal seharusnya ada? “Seharusnya” merujuk pada momen-momen kritis: sesi masuk yang berisiko, akun admin yang masuk, atau akses dari luar lokasi yang biasa Anda gunakan. Jika MFA tidak terpicu pada kondisi tersebut, berarti Anda memiliki celah keamanan, titik.

Celah seperti ini sering muncul akibat kombinasi masalah teknis, pengaturan kebijakan yang membingungkan, dan bahkan cara-cara yang dibuat pengguna akhir. Terkadang penyebabnya adalah aplikasi autentikasi lama, kebijakan akses bersyarat yang lemah, atau cakupan pengguna yang belum lengkap. Apa pun penyebabnya, MFA yang tidak aktif pada saat paling penting membuka pintu bagi penyerang dan menimbulkan masalah keamanan yang nyata.

Memahami dan memperbaiki celah penegakan ini sangat penting untuk menjaga data Anda tetap aman. Jika Anda ingin melihat secara nyata bagaimana penyerang memanfaatkan celah ini melalui pencurian token dan permainan OAuth, ulasan pelanggaran Microsoft 365 ini menunjukkan secara jelas apa yang dipertaruhkan.

Memahami Di Mana MFA Gagal Terpicu dan Penyebabnya

MFA hanya sekuat kebijakan dan teknologi yang Anda terapkan di belakangnya. Yang membuat frustrasi, bahkan ketika Anda yakin sudah mengatur semuanya dengan benar, ada banyak skenario di mana MFA diam-diam tidak muncul, termasuk untuk pengguna kritis atau saat sesi masuk berisiko.

Penyebab yang sering terjadi adalah kebijakan akses bersyarat yang salah konfigurasi. Misalnya, pengguna VIP dikecualikan demi “kemudahan”, atau akun uji coba tetap aktif dengan izin yang luas dan tanpa MFA. Pengecualian seperti ini mungkin terasa tidak berbahaya saat pengaturan awal, tetapi bisa membuat lubang langsung menembus pertahanan Anda. Jika kebijakan tidak ditinjau secara berkala, Anda bisa berakhir dengan celah keamanan tak terlihat yang tidak diperingatkan oleh dasbor mana pun.

Aplikasi lama adalah masalah terselubung lainnya. Alat seperti Exchange ActiveSync atau sejumlah klien email desktop tertentu sering menggunakan autentikasi usang, sehingga secara default melewati MFA modern. Aplikasi non-browser ini mengandalkan basic auth, yang tidak kompatibel dengan pengaturan MFA baru Anda, dan hal ini dapat menyebabkan sesi masuk berlangsung sepenuhnya di luar kendali Anda.

Dan jangan lupakan perilaku pengguna. Sebagian pengguna membuat “kata sandi aplikasi” untuk menghubungkan aplikasi lama, yang sepenuhnya melewati MFA. Yang lain tanpa sengaja memberikan izin OAuth kepada aplikasi pihak ketiga melalui permintaan persetujuan yang berisiko, sehingga memberi penyerang pintu belakang yang tidak pernah diminta verifikasi MFA. Di sinilah tata kelola menjadi penting, karena pengguna dapat mengabaikan MFA tanpa menyadari risikonya.

Bagi organisasi yang menjalankan lingkungan hibrida atau multi-cloud, celah ini semakin bertambah. Jika Anda tidak secara sistematis mengaudit siapa dan apa yang wajib menggunakan MFA, Anda mungkin melewatkan eksposur kritis. Menelusuri dasbor identitas di berbagai platform adalah satu-satunya cara untuk memetakan cakupan sebenarnya. Memahami di mana MFA gagal membangun fondasi untuk memperketat kontrol dan melindungi setiap sesi masuk, di mana pun dan bagaimana pun terjadinya.

Menerapkan Metode MFA Tahan Phishing untuk Autentikasi yang Aman

MFA standar sudah baik, sampai penyerang menemukan cara menipu pengguna dengan kelelahan notifikasi (push fatigue), perintah phishing, atau pencurian token. Itulah sebabnya beralih ke MFA tahan phishing sangat penting jika Anda ingin menutup rapat pintu bagi serangan modern.

Pencocokan angka (number matching) pada aplikasi autentikator adalah peningkatan yang solid. Alih-alih menyetujui notifikasi push generik, pengguna diminta memasukkan kode, sehingga hampir mustahil bagi penyerang untuk menipu seseorang melalui prompt bombing. Microsoft dan pihak lain sangat mendorong fitur ini, bahkan mengaktifkannya secara default untuk pengaturan MFA baru. Fitur ini secara langsung menjawab trik prompt bombing yang digunakan dalam pelanggaran besar belakangan ini.

Kunci keamanan fisik seperti YubiKey dan token FIDO2 membawa perlindungan lebih jauh lagi. Kunci ini tidak bisa di-phishing dan tidak bergantung pada rahasia bersama. Di lingkungan yang sangat sensitif, atau untuk admin dan eksekutif, ini nyaris setara dengan “mode kunci total”, yaitu autentikasi berbasis perangkat keras yang menggagalkan sebagian besar teknik serangan dunia nyata dengan telak.

Anda tidak perlu mengorbankan kemudahan penggunaan juga. Dengan opsi login tanpa kata sandi yang modern dan integrasi yang kuat ke platform seperti Microsoft 365 dan Defender, Anda dapat menerapkan MFA tahan phishing langsung ke dalam alur kerja yang sudah ada. Untuk contoh nyata integrasi conditional access dengan perlindungan ancaman lanjutan dan pengalaman pengguna yang nyaman, lihat panduan tentang pengaturan keamanan M365 yang ketat. Meningkatkan ke MFA tahan phishing bukan lagi sekadar "nice to have"—dengan cepat, ini menjadi standar dasar baru untuk melindungi dari penyerang yang canggih.

Implementasi MFA Tanpa Biaya untuk Bisnis Kecil dengan Microsoft Entra ID

Jika Anda menjalankan bisnis kecil, Anda tidak memerlukan anggaran besar atau lisensi mahal untuk menerapkan MFA yang andal. Microsoft Entra ID (sebelumnya Azure AD) menyediakan security defaults, yang dapat diaktifkan oleh setiap bisnis hanya dengan beberapa klik.

Aktifkan security defaults di Pusat admin Entra. Langkah ini langsung memberlakukan MFA untuk semua pengguna—tanpa perlu menyusun kebijakan yang rumit atau lisensi tambahan. Yang terbaik, pengaturan prakonfigurasi ini langsung berfungsi, memberikan perlindungan dasar terhadap pembobolan akun serta memblokir protokol autentikasi lama secara default.

Penerapan yang mulus itu penting. Beri tahu pengguna sebelumnya agar tidak ada yang terkejut dengan permintaan verifikasi baru. Dukung mereka yang kurang familiar dengan alat MFA atau aplikasi autentikator. Jika memungkinkan, uji pengaturan terlebih dahulu dengan kelompok pilot untuk memastikan tidak ada masalah tak terduga pada aplikasi kerja penting atau akun layanan.

Kuncinya adalah tidak mengandalkan pola "atur lalu lupakan". Tinjau secara berkala siapa saja yang berada di security defaults, dan periksa akun yang mungkin luput. Jika Anda membutuhkan kontrol yang lebih terperinci, pertimbangkan untuk menambahkan Conditional Access secara bertahap—tetapi mulailah dari yang sederhana dan aman. Untuk rencana penerapan yang aman serta ide untuk menutup celah yang tidak terlihat, panduan Conditional Access praktis ini membahas jebakan dan strategi yang perlu Anda ketahui.

MFA untuk Bisnis: Praktik Terbaik untuk Penegakan Kebijakan dan Mitigasi Risiko

1. Terapkan MFA secara menyeluruh—tanpa pengecualian demi kenyamanan. Pastikan semua akun pengguna (tidak hanya admin) tercakup oleh kebijakan MFA, termasuk akun untuk staf sementara, vendor, dan eksekutif. Pengecualian harus jarang dilakukan dan selalu dibatasi waktu, dengan justifikasi bisnis yang kuat.
2. Amankan akun layanan dan akun non-manusia dengan solusi modern. Akun layanan tradisional bisa menjadi celah MFA yang besar. Modernisasikan akun tersebut dengan alat seperti Entra Workload Identities untuk autentikasi terkelola, yang memungkinkan manajemen siklus hidup dan kemampuan audit. Pelajari lebih lanjut tentang pendekatan ini dalam ulasan tentang risiko non-manusia ini.
3. Lakukan onboarding pengguna dengan pelatihan dan dukungan yang tepat. Bantu pengguna menyiapkan aplikasi autentikator atau token fisik, dan jelaskan mengapa MFA penting. Sediakan dukungan helpdesk selama penerapan, terutama bagi pengguna yang belum terbiasa dengan permintaan MFA baru seperti number matching.
4. Pantau upaya bypass MFA dan sign-in yang tidak wajar. Siapkan peringatan dan log untuk mendeteksi saat MFA tidak diterapkan pada skenario berisiko tinggi yang seharusnya dilindungi, atau saat protokol lama lolos. Otomatiskan respons insiden sebisa mungkin—misalnya mereset kata sandi atau memicu MFA step-up pada sign-in berisiko.
5. Audit cakupan MFA dan kepatuhan kebijakan secara berkala. Jangan berasumsi cakupannya sudah beres. Gunakan dashboard identitas dan pelaporan, baik di Microsoft 365 maupun di platform lain jika Anda menjalankan multi-cloud. Terjemahkan temuan ke dalam laporan yang jelas agar tim IT dan pimpinan dapat melihat di mana risiko masih tersisa. Tata kelola yang efektif tidak berhenti pada tombol dan pengaturan; untuk wawasan lebih dalam, tinjau pelajaran dari kegagalan tata kelola M365 ini.

Dengan mengikuti daftar periksa ini, Anda secara signifikan mengurangi risiko penyerang dapat melewati MFA—apa pun tekniknya. Konsistensi, kebijakan yang jelas, dan tinjauan berkala menjaga perlindungan tetap kuat dan celah tetap tertutup.