Keamanan Outlook Web App: Lindungi Exchange dengan MFA

Pendahuluan

Sebagian besar pembahasan tentang keamanan akses jarak jauh dimulai dengan VPN. Hampir tidak ada yang membahas Outlook Web App (OWA), dan ini merupakan celah yang aneh mengingat apa sebenarnya OWA itu: sebuah formulir login untuk email perusahaan, yang berada di internet terbuka, dapat diakses dari browser apa pun di perangkat apa pun, di mana pun. Tidak ada klien VPN yang perlu dikonfigurasi, tidak ada aturan firewall yang perlu dilewati, tidak ada segmen jaringan yang perlu dilalui — hanya kolom nama pengguna, kolom kata sandi, dan apa pun yang diputuskan oleh server Exchange untuk diterima.

Bagi penyerang, hal itu hampir sama dengan jalur langsung menuju kotak surat. Login OWA yang disusupi tidak memerlukan pergerakan lateral untuk menjadi berbahaya — hal itu sudah berbahaya, seketika, karena kotak surat itu sendiri adalah sasarannya. Penipuan email bisnis tidak memerlukan malware, tidak memerlukan eksploit, dan tidak memicu sebagian besar alat deteksi yang dirancang untuk intrusi jaringan. Yang dibutuhkan hanyalah satu set kredensial yang valid dan halaman login yang tidak meminta informasi lain apa pun.

Mengapa Exchange On-Premise dan Hybrid Tidak Mendapatkan MFA Secara Gratis

Kebingungan ini dapat dimengerti, karena penyewa Microsoft 365 yang menggunakan Exchange Online memang mendapatkan otentikasi kuat hampir secara otomatis — kebijakan Akses Bersyarat Entra ID dapat mewajibkan MFA di lapisan identitas sebelum token sesi diterbitkan, dan perlindungan tersebut berlaku untuk Outlook di web tanpa konfigurasi khusus Exchange. Tim keamanan yang hanya pernah bekerja di lingkungan cloud murni secara wajar menganggap MFA untuk webmail adalah cara kerja Exchange.

Exchange on-premises dan hybrid tidak mewarisi perilaku tersebut. Tumpukan otentikasi Exchange Server sendiri — peran Layanan Akses Klien yang menangani OWA dan Pusat Admin Exchange — memvalidasi nama pengguna dan kata sandi terhadap Active Directory, dan tanpa konfigurasi tambahan, itulah seluruh proses pengambilan keputusan otentikasi. Tidak ada faktor kedua bawaan yang terintegrasi dalam proses login OWA on-premises. Penerapan hybrid semakin memperumit hal ini: beberapa kotak surat mungkin sudah dipindahkan ke Exchange Online dan dilindungi oleh Akses Bersyarat, sementara yang lain tetap berada di lingkungan on-premises dan mungkin masih mengandalkan jalur otentikasi Exchange Server sendiri, kecuali jika Otentikasi Modern Hybrid atau solusi MFA lainnya telah dikonfigurasi secara eksplisit. Sangat mungkin bagi suatu organisasi untuk meyakini bahwa emailnya “dilindungi oleh MFA” karena hal itu memang benar untuk tenant tersebut, sementara sebagian kotak surat yang signifikan masih berada di balik OWA on-premises yang hanya mengandalkan kata sandi.

Inilah celah yang penting secara operasional, bukan karena Exchange di lokasi secara inheren kurang aman berdasarkan desainnya, tetapi karena hal ini menempatkan tanggung jawab untuk menambahkan faktor otentikasi kedua sepenuhnya pada admin Exchange, tanpa adanya pengaturan default yang dapat diandalkan.

Apa yang Sebenarnya Didapatkan Penyerang dari Akun OWA atau EAC yang Diretas

Nilai dari satu kredensial OWA mudah diremehkan jika Anda menganggapnya sebagai “hanya email.” Dalam praktiknya, akun kotak surat yang diretas merupakan titik masuk dengan beberapa jalur serangan yang berbeda yang bercabang darinya.

Penipuan email bisnis (BEC) adalah yang paling berdampak langsung secara finansial.

Penipuan email bisnis (BEC) adalah yang paling berdampak langsung secara finansial. Pusat Pengaduan Kejahatan Internet FBI mencatat kerugian BEC sebesar $3,046 miliar yang dilaporkan di Amerika Serikat pada tahun 2025, kategori kerugian tertinggi kedua setelah penipuan investasi, tersebar di sekitar 24.768 pengaduan — dengan kerugian rata-rata lebih dari $120.000 per insiden yang dikonfirmasi. Serangan BEC secara khas tidak melibatkan malware maupun tautan berbahaya yang dapat terdeteksi oleh filter keamanan; penyerang berada di dalam kotak surat yang sah, mengirim pesan dari alamat yang sah, sering kali membalas dalam utas percakapan yang sudah ada dengan nomor routing bank yang dimodifikasi atau faktur yang dialihkan. Aturan aliran email membuat teknik ini lebih sulit dideteksi setelah kejadian — penyerang yang memiliki akses ke kotak surat dapat membuat aturan kotak masuk yang secara diam-diam meneruskan atau menghapus pesan yang berisi kata-kata seperti “faktur,” “transfer,” atau “pembayaran,” sehingga kompromi tersebut tetap tidak terlihat oleh pemilik akun sementara percakapan penipuan terus berlanjut secara paralel.

Akses delegasi memperparah risiko paparan.

Akses delegasi memperparah risiko paparan. Asisten eksekutif dan anggota tim keuangan sering kali memiliki izin delegasi atau “kirim sebagai” pada kotak surat eksekutif sebagai bagian dari alur kerja normal, yang berarti satu akun asisten yang diretas dapat digunakan untuk mengirim komunikasi yang tampak berasal langsung dari CFO atau CEO tanpa pernah menyentuh kredensial eksekutif tersebut.

Paparan data adalah risiko yang lebih tersembunyi

Paparan data adalah risiko yang lebih tersembunyi, dan seringkali lebih berakibat serius bagi organisasi yang diatur. Kotak surat menumpuk lampiran, memo internal, korespondensi SDM, dan komunikasi klien selama bertahun-tahun, semuanya dapat diakses melalui antarmuka OWA sendiri begitu penyerang terotentikasi — tidak memerlukan alat eksfiltrasi terpisah, karena penyerang dapat mengakses dan mengunduh konten kotak surat menggunakan fungsi OWA yang sah.

Pendekatan 1: Penerapan MFA Langsung pada Login OWA dan EAC

Solusi yang paling tepat sasaran menangani permukaan risiko spesifik tanpa mengubah apa pun yang terhubung ke Active Directory. MFA untuk Outlook Web App dan Exchange Admin Center diinstal sebagai komponen pada peran layanan Akses Klien Exchange, yang ditempatkan di depan halaman login OWA dan EAC yang sudah ada, bukan menggantikan mekanisme otentikasi Exchange secara langsung. Setelah diinstal, pengguna melakukan otentikasi terlebih dahulu dengan nama pengguna dan kata sandi AD biasa, kemudian menyelesaikan langkah otentikasi kedua — misalnya, dengan memasukkan OTP dari aplikasi otentikator atau token perangkat keras, atau dengan menyetujui notifikasi push — sebelum sesi diberikan.

Cakupan ditentukan melalui keanggotaan grup Active Directory pada saat instalasi: seorang administrator dapat mewajibkan MFA untuk seluruh pengguna secara langsung, atau mengaktifkannya terlebih dahulu untuk satu grup AD — misalnya grup uji coba, atau secara khusus grup yang memiliki akses ke Exchange Admin Center — sementara peluncuran lebih luas sedang direncanakan. Perbedaan tersebut penting dalam praktiknya, karena akun EAC membawa risiko organisasi yang jauh lebih besar daripada kotak surat individu; akun admin dengan akses EAC dapat membuat aturan aliran email, mengubah izin, atau mengekspor data di seluruh lingkungan Exchange, yang merupakan alasan mengapa melindungi login EAC cenderung menjadi prioritas bahkan ketika peluncuran penuh untuk pengguna memakan waktu lebih lama.

Perilaku sesi dapat dikonfigurasi, bukan bersifat tetap. Administrator menentukan seberapa sering pengguna diminta kembali untuk memasukkan OTP baru — misalnya, sekali setiap 12 jam penggunaan OWA yang berkelanjutan — dengan menyeimbangkan ketidaknyamanan otentikasi berulang terhadap risiko sesi yang berlangsung lama dan tidak diawasi pada perangkat bersama atau yang tidak dikelola. Komponen ini mendukung HOTP, TOTP, dan OCRA berbasis tantangan-respons, sehingga memberikan fleksibilitas bagi organisasi yang menggunakan berbagai jenis token OTP.

Pendekatan 2: MFA di Tingkat Active Directory, Mencakup OWA Bersama dengan Layanan Lainnya

Sebuah pertanyaan yang lebih spesifik yang perlu diajukan sebelum menerapkan komponen khusus OWA: apakah OWA benar-benar satu-satunya layanan yang terhubung ke AD yang masih melakukan otentikasi hanya dengan kata sandi? Untuk sebagian besar lingkungan on-premises, jawaban jujurnya adalah tidak — Winlogon, RDP, dan seringkali aplikasi internal yang terikat LDAP berada dalam posisi yang sama, tidak dilindungi oleh apa pun selain kebijakan kata sandi yang diberlakukan oleh AD.

Otentikasi multi-faktor di tingkat direktori mengatasi kerentanan yang lebih luas ini dengan mengintegrasikan langsung ke Active Directory itu sendiri, bukan di halaman login masing-masing layanan. Alih-alih serangkaian penerapan MFA terpisah — satu komponen untuk OWA, agen berbeda untuk RDP, proxy RADIUS untuk VPN, yang masing-masing diinstal, dikonfigurasi, dan dipelihara secara mandiri — integrasi di tingkat direktori mengubah cara kerja kredensial pengguna di Active Directory dengan mengganti kata sandi statis dengan kata sandi dinamis berbasis waktu, sehingga layanan yang terhubung ke AD dapat menggunakan kredensial dinamis yang sama tanpa memerlukan komponen MFA terpisah untuk setiap layanan. OWA tercakup bukan karena secara khusus ditargetkan, melainkan karena, seperti semua layanan lain yang terhubung ke AD, kini harus memenuhi pemeriksaan kredensial dinamis yang sama.

Kompromi ini berjalan ke arah yang berlawanan dari Pendekatan 1: cakupan yang lebih luas sebagai ganti perubahan yang lebih luas pada cara otentikasi AD bekerja di seluruh lingkungan, yang biasanya memerlukan pengujian yang lebih cermat dan peluncuran bertahap daripada yang diperlukan oleh komponen OWA tunggal. Pilihan yang tepat di antara keduanya benar-benar bergantung pada cakupan — organisasi yang satu-satunya permukaan terhubung ke AD yang tidak terlindungi adalah OWA tidak perlu mengubah direktori untuk memperbaikinya; organisasi yang menemukan bahwa OWA, RDP, dan Winlogon semuanya masih menggunakan otentikasi berbasis kata sandi saja memiliki masalah yang lebih luas yang tidak dapat diselesaikan dengan perbaikan pada satu layanan saja.

Bagaimana Mekanisme Tingkat Direktori Bekerja Tanpa Agen Endpoint

Mekanisme di balik MFA tingkat direktori layak dipahami secara terpisah, karena hal ini menjelaskan mengapa mekanisme tersebut menjangkau setiap layanan yang terhubung ke AD tanpa perlu menginstal apa pun di workstation atau server individu.

Otentikasi Kata Sandi Kuat Dinamis bekerja dengan memodifikasi kata sandi yang disimpan di Active Directory itu sendiri, bukan dengan mencegat lalu lintas otentikasi di setiap titik akhir. Kata sandi statis pengguna diganti dengan kata sandi dinamis berbasis TOTP yang berganti secara otomatis pada interval yang dikonfigurasi oleh administrator — nilai tersebut harus merupakan kelipatan dari 30 detik. Kata sandi dinamis saat ini dihasilkan menggunakan algoritma TOTP dan tersedia bagi pengguna melalui aplikasi Protectimus SMART atau chatbot yang didukung. Karena perubahan terjadi langsung di direktori, klien atau layanan apa pun yang melakukan otentikasi terhadap AD — Winlogon, RDP, OWA, aplikasi yang terikat LDAP — secara otomatis menggunakan kata sandi dinamis saat ini, tanpa layanan tersebut perlu mengetahui bahwa ada perubahan.

Inilah yang menjadikan pendekatan ini “tanpa agen” dalam arti yang penting: tidak ada perangkat lunak yang berjalan di laptop, host RDP, atau server Akses Klien Exchange yang memeriksa faktor kedua. Direktori itu sendiri adalah titik penegakan. Kompromi yang sesuai adalah bahwa komponen ini berjalan sebagai bagian dari implementasi di lokasi (on-premises) daripada layanan berbasis cloud saja, karena memerlukan integrasi langsung dengan pengontrol domain.

Memilih Cakupan: Hanya Webmail, atau Seluruh Lingkungan AD

Kedua pendekatan ini memecahkan masalah mendasar — kata sandi saja tidak lagi cukup untuk otentikasi — tetapi memecahkannya pada titik yang berbeda dalam tumpukan, dan pilihan yang tepat bergantung pada inventarisasi yang jujur daripada preferensi default.

Jika OWA dan EAC benar-benar merupakan satu-satunya layanan yang masih melakukan otentikasi terhadap AD hanya dengan kata sandi — VPN sudah tercakup melalui RADIUS, RDP sudah dikunci, tidak ada aplikasi warisan lain yang diam-diam mempercayai kredensial AD — komponen OWA yang ditargetkan menutup celah spesifik tersebut dengan gangguan minimal terhadap layanan lain yang berjalan di direktori. Jika inventarisasi menemukan lebih dari satu layanan yang terpapar — yang merupakan temuan yang lebih umum begitu tim TI benar-benar mulai memeriksa — MFA tingkat direktori menutup semua celah tersebut dari satu titik integrasi, alih-alih mengumpulkan produk MFA terpisah untuk masing-masing layanan.

Bagaimanapun juga, angka kerugian akibat BEC dari FBI mengarah pada fakta mendasar yang sama: proses masuk hanya dengan kata sandi pada kotak surat perusahaan, yang berada di internet terbuka, tidak lagi menjadi posisi yang dapat dipertahankan bagi organisasi mana pun yang menjalankan Exchange — baik di lokasi, hybrid, maupun lainnya.