Memahami Kasus Tepi Protokol Lama dalam Ekosistem Microsoft

By Mirko Peters · 2026-04-26

Protokol autentikasi lama—misalnya NTLM, SMTP AUTH, atau FTP klasik—mungkin terdengar seperti masalah dari era lain, tetapi protokol ini terus bertahan di dunia perusahaan yang berpusat pada Microsoft…

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

Protokol autentikasi lama—misalnya NTLM, SMTP AUTH, atau FTP klasik—mungkin terdengar seperti masalah dari era lain, tetapi protokol ini terus bertahan di dunia perusahaan yang berpusat pada Microsoft. Organisasi modern meningkatkan sistemnya ke Microsoft 365 dan Azure, namun kasus tepi yang terkait dengan protokol ini diam-diam melemahkan ambisi zero trust dan strategi keamanan mereka. Anda bisa mengunci pintu depan dengan autentikasi multifaktor, tetapi terkadang ada jendela lama di ruang bawah tanah yang masih terbuka.

Mengapa kasus tepi ini terus menimbulkan masalah? Kenyataannya, modernisasi TI tidak selalu bisa terjadi dalam semalam. Banyak sistem bisnis kritis, integrasi pihak ketiga, bahkan perangkat teknologi operasional terhubung secara permanen untuk menggunakan protokol yang lebih lama. Penyerang memahami hal ini—mereka menargetkan apa pun yang masih berjalan, menghindari kontrol modern, dan membuka celah di titik yang paling tidak diduga tim keamanan.

Artikel ini membahas bagaimana dan mengapa risiko protokol lama tetap ada seiring bisnis mengembangkan lingkungan Microsoft mereka. Kami akan menjelaskan komponen teknisnya, mengulas bahaya yang berdampak pada bisnis, dan memaparkan apa yang bisa Anda lakukan—mulai dari deteksi hingga tata kelola—untuk menutup celah yang membandel ini secara tuntas. Mari kita telusuri dari mana sebenarnya risiko berasal, dan bagaimana menutup pintu belakang tersebut untuk selamanya.

Kerentanan Protokol Lama dan Eksploitasi di Dunia Nyata

Meski pertahanan native cloud dan MFA sudah diterapkan, penyerang tetap memanfaatkan titik lemah yang tertinggal dari puluhan tahun lalu. Protokol lama—seperti NTLM untuk autentikasi, SMTP AUTH untuk surel, serta FTP dasar atau POP3 untuk pemindahan data—tetap digunakan karena sistem dunia nyata harus terus berjalan selama bisnis berbenah. Penyerang sangat menyukai hal ini, karena sering kali itu berarti mereka dapat menyelinap melewati sistem yang paling terlindungi di perusahaan.

Dalam lingkungan hibrida masa kini, protokol lama ini tidak hanya ada di satu server yang tersimpan di pusat data. Protokol ini terjalin di platform identitas cloud, aplikasi lini bisnis, bahkan perangkat OT dan IoT yang sama sekali tidak bisa menggunakan autentikasi modern. Menghapusnya secara bertahap bukan hal mudah, karena memblokirnya begitu saja bisa merusak sesuatu yang kritis, dan deteksi di seluruh area tersebut tidak selalu konsisten.

Hasilnya? Insiden seperti pelanggaran data Vercel dan Orange España menunjukkan bahwa satu protokol yang terlewat saja sudah cukup untuk membuka pintu bagi pencurian data atau kompromi jaringan. Penyerang memanfaatkan jalur lama ini untuk melewati MFA, meneruskan kredensial (credential relay), atau meningkatkan izin pada beban kerja cloud maupun on-premises. Kami akan mengurai secara rinci bagaimana serangan ini bekerja, mengapa protokol itu sendiri cacat sejak desainnya, dan di mana risiko bisnis yang paling membandel bersembunyi.

Kami juga akan menyinggung kebiasaan operasional yang membuat risiko ini terus bertahan, seperti pengelolaan kebijakan yang longgar, atau mewarisi utang teknis selama bertahun-tahun dari integrasi yang dibuat "asal jalan". Bagian-bagian berikutnya akan mengupas tuntas bagaimana kerentanan lama dieksploitasi, kelemahan protokol secara sistemik, dan titik di mana pertahanan modern menemui jalan buntu. Jika Anda mencari lingkungan Microsoft yang benar-benar aman, Anda perlu tahu persis di mana ancaman lama ini bersembunyi dan bagaimana ancaman tersebut tetap masuk meski log Anda menyatakan semuanya "aman". Untuk pembahasan lebih lanjut tentang bagaimana serangan ini saling terhubung di dunia nyata, silakan baca rincian mendalam tentang rantai serangan Microsoft 365.

Bagaimana Pelanggaran Data Vercel dan Orange España Mengungkap Risiko Protokol Lama

Pelanggaran data Vercel dan Orange España menyoroti dengan jelas bahwa risiko protokol lama bukan sekadar kekhawatiran hipotetis. Dalam kedua insiden, metode autentikasi yang usang memainkan peran kunci dengan memberi penyerang seperangkat kunci untuk bergerak lebih dalam ke jaringan perusahaan. Pada kasus Vercel, penyerang berhasil mengambil variabel lingkungan dan rahasia dari ratusan pelanggan berprofil tinggi, karena kredensial yang terikat pada alur autentikasi lama masih digunakan di balik layar.

Pelanggaran Orange España menunjukkan pola serupa. Dalam kasus ini, penyerang menembus lini pertahanan terdepan dengan memakai kredensial valid yang dicuri. Banyak kredensial tersebut tidak akan berfungsi jika protokol lama seperti POP3/IMAP atau SMTP AUTH yang tidak aman tidak diaktifkan untuk email. Riset dari laporan ancaman tahunan IBM menyebutkan bahwa pencurian kredensial masih menjadi vektor akses awal paling utama dalam pelanggaran di lingkungan perusahaan, terutama ketika organisasi tidak secara proaktif menonaktifkan metode autentikasi yang sudah usang.

Para pakar yang meninjau kasus-kasus ini menekankan satu poin penting: kerentanan protokol lama bukan sekadar sisa teknologi lama. Protokol ini sering kali tertanam jauh di dalam skrip otomasi, alat cadangan, bahkan perangkat tertanam yang diam-diam menggunakan autentikasi usang setiap hari. Sebagai contoh, dalam rangkaian serangan Vercel, protokol seperti basic auth dan token akses yang tersarang secara tidak rapi memungkinkan penyerang melewati kontrol kebijakan modern dan berpindah secara lateral setelah berhasil masuk ke jaringan.

Apa yang bisa dipelajari organisasi? Pelanggaran berprofil tinggi terus menegaskan bahwa mengamankan titik masuk cloud terbaru saja tidak cukup. Ketahanan sejati menuntut pembersihan jalur lama yang tersembunyi ini. Selama hal itu belum dilakukan, penyerang akan terus memprioritaskan rute akses yang paling mudah dan paling sedikit pertahanannya, yang sering kali berjalan diam-diam di latar belakang pada pengaturan hibrida dan multi-cloud.

Relai NTLM dan Masalah Basic Authentication: Melewati Kontrol Keamanan Modern

Protokol lama seperti NTLM dan Basic Authentication menimbulkan berbagai masalah bagi tim keamanan karena tidak mengikuti aturan MFA modern. Berikut cara aktor ancaman memanfaatkan kelemahan ini untuk melewati pertahanan:

1. Serangan Relai NTLM:
2. Penyerang menangkap hash NTLM pada perangkat yang telah disusupi dan "merelainya" ke layanan lain yang dapat diakses korban. Karena NTLM tidak memerlukan kata sandi asli untuk diketahui, penyerang dapat meniru pengguna tanpa pernah memecahkan kata sandi. Relai ini sering kali membentang dari AD lokal ke cloud, terutama pada pengaturan identitas hibrida yang segmentasinya buruk.
3. Menghindari MFA:
4. Protokol seperti SMTP AUTH dan IMAP sama sekali tidak mendukung MFA. Jika penyerang memperoleh kredensial valid, mereka dapat masuk menggunakan protokol ini, bahkan jika MFA diterapkan pada akun pengguna. Artinya, kata sandi yang lemah dan digunakan ulang menjadi titik kegagalan tunggal di lingkungan yang seharusnya aman.
5. Pergerakan Lateral dan Eskalasi Hak Akses:
6. Setelah berada di dalam, penyerang memakai protokol lama untuk berpindah. Misalnya, dengan mengeksploitasi basic auth pada aplikasi yang terlewat, mereka dapat bergerak secara lateral ke sistem dengan hak akses lebih tinggi. Akses ke satu layanan SMB atau Exchange yang tidak terlindungi sering kali berujung pada kompromi di seluruh jaringan.
7. Melewati Conditional Access:
8. Banyak kebijakan Conditional Access di Azure AD hanya berlaku untuk klien autentikasi modern. Protokol lama dapat menyelinap melewati aturan ini, meninggalkan "daftar izinkan" berbahaya atau celah kebijakan yang aktif dicari penyerang. Ingin pembahasan lebih mendalam tentang loop keamanan identitas dan memperbaiki sprawl Conditional Access? Simak episode podcast ini tentang pengurangan risiko yang dapat diskalakan di lingkungan Microsoft.

Singkatnya, Anda boleh saja menambal dan mengonfigurasi kontrol modern sebanyak apa pun, tetapi selama protokol lama masih ada, penyerang hampir selalu akan menemukan cara untuk melewati pertahanan baru Anda.

Cacat Sistemik: Dari Kerentanan MCP hingga Risiko LLMNR dan NetBIOS

Protokol Microsoft lama dihantui oleh cacat yang bukan sekadar bug, melainkan sudah tertanam langsung dalam desainnya. Berikut alasan mengapa kelemahan ini menjadi risiko yang sulit dihilangkan:

1. Cacat MCP (Microsoft Connector Platform):
2. Beberapa platform dan konektor yang digunakan oleh agen pihak ketiga dan skrip otomasi masih mengandalkan pass-through kredensial lama, tanpa token binding yang memadai atau kontrol akses yang granular. Penyerang memanfaatkannya untuk meningkatkan hak akses, terutama ketika kebijakan agen tidak diatur dengan ketat.
3. Kelemahan LLMNR (Link-Local Multicast Name Resolution):
4. LLMNR dirancang untuk memudahkan resolusi nama jaringan, tetapi sangat mudah disalahgunakan untuk mencuri kredensial. Penyerang menyiarkan respons palsu, sehingga sistem di sekitarnya menyerahkan hash NetNTLM yang kemudian dapat dipecahkan atau direlai.
5. Risiko Penamaan NetBIOS:
6. Jaringan Windows lama masih menggunakan NetBIOS untuk resolusi nama—protokol lain yang tidak pernah dirancang dengan mempertimbangkan keamanan. Penyerang dapat mencegat dan memanipulasi lalu lintas untuk menyamar sebagai layanan atau mengumpulkan detail jaringan yang sensitif, lalu menyiapkan serangan lanjutan.
7. Celah Penandatanganan SMB:
8. Penandatanganan SMB ditambahkan untuk mengamankan berbagi file, tetapi penerapannya belum merata, terutama di jaringan hibrida dan lingkungan OT. Penyerang memanfaatkan celah ini dengan meneruskan kredensial (relay) atau memalsukan respons antarsistem—sering kali melompat dari infrastruktur OT lama ke infrastruktur IT modern.

Menonaktifkan protokol seperti LLMNR dan menerapkan penandatanganan SMB adalah keharusan bagi setiap upaya Zero Trust yang nyata. Untuk melihat lebih dekat bagaimana kontrol terkoordinasi dan keamanan adaptif dapat membantu menutup celah protokol ini, dengarkan episode podcast Zero Trust by Design—sebuah pembahasan mendalam yang praktis tentang identitas terpadu dan kontrol sesi.

Autentikasi Modern vs. Lama: Tantangan Transisi dan Kasus Khusus

Beralih dari autentikasi lama ke autentikasi modern adalah sebuah perjalanan, bukan perpindahan cepat. Saat menjembatani celah ini, Anda akan menemui berbagai kasus khusus. Meskipun protokol seperti OAuth 2 dan MFA meningkatkan standar keamanan, kebutuhan akan kompatibilitas mundur sering kali membuat pintu belakang tetap terbuka separuh. Alur autentikasi "semi-modern"—seperti model hibrida atau protokol yang berpura-pura modern—muncul di mana-mana dan mengaburkan kondisi, baik untuk kepatuhan maupun perlindungan.

Mengapa organisasi berakhir dengan pengaturan hibrida seperti ini? Jawabannya sederhana: aplikasi, layanan, dan integrasi pihak ketiga yang kritis tidak selalu siap untuk mematikan autentikasi lama dalam semalam. Terkadang, sebuah proses bisnis sederhana atau alur otomasi warisan bergantung pada metode autentikasi yang sudah berusia puluhan tahun. Terburu-buru menonaktifkannya dapat mengganggu bisnis atau melanggar kepatuhan, sehingga pengecualian pun dibuat—dan di situlah penyerang masuk.

Zero Trust yang sejati berarti menutup setiap celah, bukan sekadar menambahkan lapisan baru yang mengilap. Bagian yang sulit adalah saat Anda mencoba memodernisasi autentikasi, beberapa "peningkatan" hanya membungkus kerentanan lama dalam kemasan yang lebih baru, seperti BAV2ROPC atau alur kata sandi pemilik sumber daya lainnya. Celah kebijakan dan pengecualian yang terlewat dalam Akses Bersyarat juga dapat membuat keamanan Anda tampak modern di atas kertas, tetapi membiarkan jalur lama terbuka lebar.

Bagian berikutnya membahas secara teknis seluk-beluk konfigurasi semi-modern ini serta menguraikan di mana bahkan rencana perbaikan terbaik pun terbentur hambatan di dunia nyata. Jika Anda merencanakan transformasi yang sesungguhnya—atau sekadar berupaya menjaga penyerang tetap di luar—penting untuk memahami mengapa dukungan lama sulit dihentikan, dan di mana strategi Anda mungkin masih membuat Anda rentan. Untuk tips membangun baseline kebijakan Akses Bersyarat yang andal, lihat panduan ini tentang masalah kepercayaan kebijakan.

Misteri BAV2ROPC dan Jebakan Autentikasi Semi-Modern

BAV2ROPC merupakan singkatan dari "Basic Authentication Version 2 Resource Owner Password Credential." Namanya terdengar modern, tetapi sebenarnya ini hanyalah kemasan baru untuk masalah lama. Protokol ini, yang sering ditemui di lingkungan cloud Microsoft, menjembatani autentikasi lama dan modern dengan memungkinkan aplikasi meneruskan nama pengguna dan kata sandi secara terprogram untuk mendapatkan token sumber daya—tanpa browser atau alur persetujuan modern.

Pendekatan "semi-modern" ini menipu banyak organisasi. Di permukaan, BAV2ROPC menggunakan endpoint modern dan alur OAuth 2. Namun di baliknya, protokol ini bergantung pada pertukaran nama pengguna/kata sandi dasar yang sama seperti yang digunakan protokol lama seperti POP3, IMAP, atau SMTP AUTH—dan jarang mendukung MFA maupun Akses Bersyarat. Hal ini membuka celah bagi penyerang untuk melakukan password stuffing, credential replay, atau serangan relay dari on-prem ke cloud.

Deteksinya sulit. Dalam log, lalu lintas BAV2ROPC sulit dibedakan dari autentikasi modern yang sesungguhnya. Penyerang memahami hal ini dan dengan sengaja menargetkan aplikasi atau akun layanan yang menjalankan alur ini, karena upaya pembobolan tidak akan memicu alarm yang sama seperti Basic Auth konvensional. Banyak organisasi di dunia nyata kesulitan bermigrasi dari BAV2ROPC, terutama untuk tugas otomasi tanpa antarmuka dan skrip integrasi yang masih digunakan dalam operasi sehari-hari.

Bagi tim keamanan, jebakan terbesar adalah menganggap bahwa apa pun yang diberi label "OAuth 2" atau "resource owner" aman secara default. BAV2ROPC dan protokol serupa memperlihatkan kenyataan yang tidak menyenangkan: bahkan API modern yang canggih pun tetap bisa membuka Anda pada kelemahan yang sama seperti protokol yang seharusnya digantikannya. Selama Anda belum mengaudit dan bermigrasi sepenuhnya untuk setiap kasus khusus, celah semi-modern ini tetap menjadi sasaran empuk.

Saat Peningkatan Autentikasi Tidak Cukup: Strategi Keamanan yang Mati Karena Dukungan Lama

Meningkatkan ke OAuth 2 dan menerapkan MFA secara menyeluruh terdengar seperti solusi sempurna, sampai dukungan lama diam-diam menyusup dengan celah fatal. Riset menunjukkan bahwa lebih dari 60% pengambilalihan akun cloud dalam setahun terakhir melibatkan kredensial yang valid dan digunakan melalui protokol lama. Bahkan kebijakan Conditional Access paling canggih pun akan runtuh jika ada pengecualian yang terlewat atau aplikasi lama yang masih menjalankan autentikasi dasar di balik layar.

Para ahli memperingatkan bahwa memodernisasi tumpukan autentikasi Anda bukan sekadar mencentang daftar fitur. Dukungan lama yang terus dipertahankan, kebijakan yang salah konfigurasi, atau akun layanan yang tidak dikelola memungkinkan penyerang melewati pertahanan yang sebenarnya cukup kuat. Rencana transisi yang komprehensif, yang secara aktif menonaktifkan jalur lama, mengaudit pengecualian kebijakan, dan mengatur setiap endpoint, adalah satu-satunya cara untuk tetap mengikuti perkembangan. Untuk melihat contoh nyata bagaimana penyerang memanfaatkan persetujuan OAuth dan jalur lama, baca analisis mendalam tentang serangan persetujuan Entra ID ini, dan pahami mengapa tata kelola yang baik tidak terjadi dengan sendirinya dengan menyimak podcast tentang ilusi tata kelola di Microsoft 365 ini.

Mendeteksi dan Memantau Penggunaan Protokol Lama di Lingkungan Enterprise

Menemukan dan memantau penggunaan autentikasi lama ibarat mencari kebocoran tersembunyi dalam sistem pipa yang sangat luas. Penggunaan protokol yang tertinggal mudah terlewat karena koneksi ini tidak selalu tampil mencolok di dasbor modern. Namun, setiap instans yang terlewat, baik itu skrip cadangan lama, printer, atau sensor IoT, memberi penyerang satu kesempatan lagi untuk masuk.

Untuk mengatasinya, lingkungan Microsoft 365 dan Azure menyediakan serangkaian log dan alat analitik yang dirancang untuk visibilitas mendalam. Namun, Anda perlu tahu di mana harus mencari, dan cara menafsirkan hasil yang tidak selalu secara jelas menunjukkan "autentikasi lama di sini". Dengan menggabungkan log sign-in, jejak audit, dan telemetri kustom dari alat seperti PowerShell dan Python, Anda mendapatkan gambaran yang lebih lengkap tentang tempat protokol lama lolos. Mengorelasikan data dari sumber daya cloud dan on-premises sangat penting, karena pengaturan hybrid sering kali memiliki pelaporan yang tidak konsisten.

Apa yang membuat tantangan ini semakin sulit? Beberapa perangkat pihak ketiga dan OT diam-diam terus menggunakan protokol lama dan jarang disertakan dalam pemindaian keamanan atau laporan analitik standar. Tim keamanan harus menggabungkan berbagai teknik pemantauan, mulai dari workbook sign-in Azure hingga pengambilan Unified Audit Log, untuk menangkap setiap jejak penggunaan protokol. Untuk pembahasan praktis tentang mengaudit aktivitas di seluruh penyewa Anda dan mengapa sinyal yang lebih kaya itu penting bagi kepatuhan dan keamanan, lihat panduan Microsoft Purview Audit ini.

Subbagian berikut akan memandu Anda langkah demi langkah untuk mengenali dan menyelidiki jejak autentikasi lama di lingkungan Anda, beserta tips praktis untuk menghasilkan telemetri yang dapat ditindaklanjuti, agar celah tersembunyi ini tidak tetap tersembunyi terlalu lama.

Mengenali Autentikasi Lama di Log Sign-In Azure dan Workbook Analitik

Menangkap autentikasi lama di Azure Sign-In Logs dan analitik Entra ID membutuhkan pendekatan proaktif. Berikut daftar periksa praktis untuk membantu Anda mengenali protokol berisiko yang tersembunyi saat sedang digunakan:

1. Filter berdasarkan Jenis Aplikasi Klien:
2. Mulailah dari Azure AD Sign-In Logs di portal Azure. Filter entri berdasarkan "Client App" untuk menampilkan koneksi yang dibuat dengan protokol lama seperti IMAP, POP3, SMTP, dan "Other clients". Entri ini biasanya menonjol karena tidak menggunakan alur autentikasi berbasis browser atau modern.
3. Cari Metode Autentikasi:
4. Telusuri peristiwa sign-in dengan "Authentication Method" yang diatur ke "Password" tetapi tanpa "MFA" atau "Modern Auth". Ini sering menunjuk pada protokol yang melewati conditional access, terutama dari perangkat lama atau skrip otomatisasi.
5. Siapkan Workbook Analitik:
6. Gunakan Azure Monitor atau Entra ID Analytics Workbooks untuk memvisualisasikan tren dari waktu ke waktu. Buat workbook kustom untuk memetakan penggunaan protokol, menyorot lonjakan autentikasi lama, dan menandai koneksi klien yang tidak sesuai kebijakan.
7. Korelasikan dengan Data Perangkat dan Lokasi:
8. Silangkan peristiwa autentikasi lama dengan informasi perangkat dan geolokasi saat masuk. Kombinasi yang tidak terduga, misalnya masuk menggunakan protokol lama dari negara tempat bisnis Anda tidak beroperasi, layak mendapat perhatian serius.
9. Tips Pemecahan Masalah:
10. Jika hasilnya tampak sedikit, periksa kesenjangan kebijakan atau retensi log. Beberapa peristiwa mungkin tersaring atau terlewat jika pengaturan audit tidak menyeluruh atau jika ada pengecualian dalam kebijakan Conditional Access.

Dengan mengulangi langkah-langkah ini, Anda akan membangun visibilitas yang andal. Ingatlah, bahkan hanya sejumlah kecil entri protokol lama dalam log Anda dapat menandakan risiko yang lebih besar di tempat lain, jadi gali lebih dalam dan telusuri data ke mana pun ia mengarah.

Membuat Telemetri dengan PowerShell, Python, dan Unified Audit Log: Contoh dan Praktik Terbaik

Untuk menangkap setiap jejak aktivitas protokol lama, tidak ada yang lebih baik daripada telemetri kustom. Berikut cara menyiapkannya menggunakan PowerShell, Python, dan Unified Audit Log milik Microsoft:

1. Kueri PowerShell untuk Protokol Lama:
2. Manfaatkan cmdlet Get-Mailbox dan Get-CASMailbox di Exchange Online untuk membuat daftar pengguna yang mengaktifkan IMAP, POP3, atau SMTP AUTH. Bungkus perintah ini dalam skrip untuk membuat laporan harian atau mingguan, lalu korelasikan dengan wawasan dari log masuk.
3. Otomatisasi Python untuk Korelasi Log:
4. Gunakan skrip Python untuk terhubung ke Microsoft Graph API dan mengambil rekaman log masuk serta audit kotak surat. Urai jenis aplikasi klien dan penanda protokol autentikasi, lalu hasilkan anomali seperti akun layanan tanpa antarmuka yang masih menggunakan autentikasi lama.
5. Unified Audit Log untuk Pemantauan Terpusat:
6. Aktifkan Microsoft Purview Audit (sebelumnya Unified Audit Log) untuk mengumpulkan aktivitas dari Exchange, SharePoint, Teams, dan lainnya. Kueri kolom Operation yang terkait dengan koneksi klien lama atau percobaan autentikasi lama yang gagal untuk membangun alur deteksi yang terkonsolidasi.
7. Terapkan Visual Interaktif dan Peringatan:
8. Ekspor atau alirkan telemetri ke Microsoft Sentinel atau Power BI. Bangun dasbor dengan aturan peringatan yang terpicu saat ada penggunaan protokol lama yang baru atau saat terdeteksi paparan kredensial.
9. Waspadai Jebakan:
10. Waspadai data yang tidak lengkap akibat retensi log yang terbatas, kesenjangan konfigurasi default, atau peristiwa yang tidak dicatat secara default. Selalu validasi cakupan Anda dengan uji masuk menggunakan protokol lama sebelum menyatakan semuanya beres.

Untuk informasi lebih lanjut tentang mengintegrasikan telemetri ke dalam tata kelola dan otomatisasi (saat konten tersebut kembali tersedia), pantau pembaruan di halaman otomatisasi PowerShell yang hilang ini, atau lihat episode podcast terbaru mereka tentang arsitektur perusahaan untuk mengetahui arah strategi telemetri berikutnya.

Strategi Mitigasi: Memblokir dan Menonaktifkan Protokol Lama

Mengetahui bahwa Anda menjalankan protokol lama hanyalah langkah pertama; kemenangan sebenarnya adalah menutup saluran tersebut tanpa mengganggu bisnis. Pendekatan yang tepat berfokus pada keseimbangan antara pengurangan risiko dan kelangsungan operasional. Microsoft 365 dan Azure AD menyediakan alat yang ampuh, seperti Conditional Access dan sakelar admin, untuk menonaktifkan metode autentikasi usang dalam skala perusahaan, tetapi Anda harus menerapkannya dengan bijaksana.

Dua taktik utama adalah: menggunakan Conditional Access untuk memblokir autentikasi lama secara menyeluruh, dan menonaktifkan protokol seperti SMTP AUTH, IMAP, dan POP3 untuk akses surel dan perangkat. Kuncinya adalah menemukan setiap pengecualian dan alur kerja yang terdampak sebelum Anda memutus akses, terutama untuk akun layanan, sistem surel lokal hybrid, atau integrasi pihak ketiga yang sulit dimodernisasi. Peluncuran bertahap dan pembaruan kebijakan yang terarah membantu memastikan proses penting tidak rusak sekaligus mengurangi paparan terhadap pencurian kredensial dan penyalahgunaan spam.

Penting juga untuk memadukan perubahan kebijakan dengan kesadaran bisnis. Libatkan pemangku kepentingan, uji coba di kelompok kecil, dan manfaatkan analitik untuk membuktikan bahwa perubahan ini tidak akan melumpuhkan operasional. Pada bagian-bagian di bawah ini, Anda akan mendapatkan petunjuk langkah demi langkah dan pertimbangan untuk penerapan Conditional Access serta penonaktifan protokol di Microsoft 365 Admin Center. Penasaran dengan risiko tersembunyi ketika kebiasaan bisnis tidak diukur? Simak podcast ini tentang compliance drift dan penegakan kebijakan untuk wawasan tambahan.

Dengan rencana yang tepat, pemblokiran protokol lama tidak hanya memenuhi daftar periksa kepatuhan—Anda juga akan membuat penyerang jauh lebih sulit menemukan satu pintu terbuka yang terlupakan.

Cara Memblokir Autentikasi Lama dengan Conditional Access

Memblokir autentikasi lama dengan Conditional Access di Azure AD itu ampuh sekaligus presisi, asalkan dilakukan dengan benar. Berikut yang perlu Anda ketahui:

Kebijakan Conditional Access memungkinkan organisasi secara eksplisit memblokir upaya autentikasi dari protokol lama seperti SMTP AUTH, IMAP, POP3, dan klien basic auth. Anda dapat membatasi cakupan kebijakan ini ke pengguna, grup, atau perangkat, sambil memantau potensi dampak bisnis dalam mode "report-only" sebelum diberlakukan. Pendekatan bertahap ini memberi Anda kesempatan untuk mengidentifikasi ketergantungan yang bisa rusak jika langsung diblokir.

Microsoft merekomendasikan pembuatan setidaknya dua kebijakan inti: satu yang memblokir autentikasi lama untuk semua pengguna, dan kedua dengan pengecualian berbatas waktu untuk akun layanan atau pengecualian yang sudah diketahui. Pengujian sangat penting; mulailah dengan mode pemantauan untuk melihat akun dan aplikasi mana yang mencoba masuk menggunakan autentikasi lama, lalu beralih ke penegakan setelah Anda yakin hanya alur yang tidak esensial yang akan terganggu.

Jangan lupa untuk meninjau dan meminimalkan entri daftar izin (allow-list) yang luas atau pengecualian yang diwarisi—entri seperti ini menciptakan celah keamanan yang tidak terlihat. Pemantauan dan pemberitahuan berkelanjutan terhadap upaya autentikasi lama akan membantu menangkap risiko baru seiring perubahan lingkungan TI Anda. Untuk praktik terbaik lainnya dan dasar kebijakan inklusif yang solid, tinjau pandangan pakar ini tentang penyetelan Conditional Access untuk pengelolaan akses yang dapat diprediksi dan aman.

Intinya: memperketat Conditional Access adalah garis pertahanan terdepan Anda. Pastikan saja perubahan diterapkan secara metodis—dengan selalu menyeimbangkan kebutuhan bisnis dan tujuan keamanan.

Menonaktifkan SMTP AUTH dan Protokol Email Lama di Microsoft 365 Admin

Menonaktifkan SMTP AUTH dan protokol email lama lainnya adalah salah satu cara tercepat untuk mengurangi pencurian kredensial dan mencegah penyerang mengirim spam melalui penyewa Anda. Berikut cara melakukannya langkah demi langkah:

1. Audit Penggunaan Saat Ini:
2. Mulailah dengan Exchange Online PowerShell (Get-TransportConfig dan Get-Mailbox). Identifikasi kotak surat mana pun yang mengaktifkan SMTP AUTH serta protokol IMAP/POP3 lama yang masih aktif untuk pengguna atau akun layanan.
3. Nonaktifkan di Tingkat Penyewa:
4. Microsoft 365 Admin Center kini memungkinkan Anda menonaktifkan SMTP AUTH untuk seluruh penyewa hanya dengan satu pengaturan. Ini memblokir semua upaya autentikasi baru kecuali ada pengecualian untuk kotak surat tertentu.
5. Pembersihan Kebijakan yang Ditargetkan:
6. Untuk pengguna atau aplikasi yang memang membutuhkan SMTP AUTH, batasi aksesnya secara eksplisit dan pantau dengan ketat. Hapus izin IMAP/POP3 dari semua akun kecuali yang paling esensial—idealnya, tidak ada sama sekali.
7. Uji dan Komunikasikan:
8. Sebelum menonaktifkan dalam skala besar, jalankan kasus uji dan beri tahu pengguna atau pemilik sistem. Perhatikan tiket helpdesk yang terkait dengan otomatisasi yang rusak, lalu bekerja sama dengan tim tersebut untuk memperbarui proses mereka atau beralih ke autentikasi modern.
9. Pantau Setelah Peluncuran:
10. Periksa log audit untuk upaya protokol lama yang gagal. Kegagalan yang terus berulang bisa menandakan percobaan serangan atau ketergantungan bisnis yang terlewat dan perlu Anda tangani.

Playbook ini menghentikan sebagian besar serangan kredensial berbasis email yang umum dan membuat tim kepatuhan Anda jauh lebih tenang. Kontrol yang kuat di awal berarti pekerjaan pembersihan yang lebih kecil di kemudian hari.

Tata Kelola Keamanan dan Pengawasan Strategis untuk Risiko Protokol Lama

Mengunci protokol lama tidak hanya soal mengubah pengaturan teknis. Manajemen risiko yang sebenarnya terjadi di level atas, ketika kepemimpinan eksekutif, tim operasi keamanan, dan arsitek TI bekerja sama mengatur siklus hidup teknologi dan kebijakan. Masalahnya, sebagian besar organisasi besar mengandalkan kumpulan kontrol, kebijakan, dan vendor pihak ketiga yang beragam, sehingga sulit menerapkan pengawasan yang konsisten dalam skala besar.

Strategi tata kelola yang baik menjawab pertanyaan-pertanyaan besar: Bagaimana Anda mengelola risiko ketika integrasi pihak ketiga, alat agentik, dan shadow IT semuanya berjalan dengan aturan yang berbeda? Bagaimana Anda menerapkan kontrol yang seragam ketika separuh mitra "tepercaya" atau perangkat IoT Anda bahkan tidak dapat menggunakan autentikasi modern? Dan bagaimana Anda terus memantau pergeseran kebijakan seiring berkembangnya bisnis, tenaga kerja, dan lanskap keamanan?

Di sinilah kerangka kerja tata kelola virtual, disiplin kebijakan, dan kecerdasan canggih berperan. Kepemimpinan tidak hanya harus menetapkan arah dari atas, tetapi juga menerapkan pemeriksaan nyata, mulai dari menyeleksi penyedia layanan yang paling berisiko hingga menjalankan audit dan menerapkan otomatisasi untuk deteksi dan remediasi. Seiring AI dan otomatisasi bergerak lebih cepat dari sebelumnya, yang terpenting adalah memastikan alat, kebijakan, dan orang berada dalam satu pemahaman yang sama.

Pada bagian berikut, kita akan membahas cara-cara efektif yang dapat dilakukan CISO dan pengambil keputusan untuk membangun model tata kelola yang mengutamakan kerja jarak jauh, mengelola risiko pihak ketiga dan agentik yang paling sulit diprediksi, serta memanfaatkan kecerdasan modern untuk menutup celah protokol secara tuntas. Untuk pembahasan lebih lanjut tentang menyeimbangkan inovasi dengan pengawasan, lihat tips tata kelola Power Platform ini, dan pelajari cara tetap mengikuti otomatisasi dan agen yang bergerak lebih cepat daripada kebijakan Anda dalam episode kerangka tata kelola praktis ini.

Bagaimana Pemimpin Keamanan Melindungi Diri dari Pihak Ketiga yang Paling Berisiko dalam Kerangka Kerja Tata Kelola Virtual

Organisasi terkemuka menerapkan pendekatan berlapis dan proaktif dalam mengatur risiko protokol lama, terutama dari pihak ketiga. Berikut empat strategi praktis:

• Terapkan Pengawasan Agentik: Pantau dan audit semua akun layanan, agen, dan integrasi pihak ketiga yang berinteraksi dengan lingkungan Anda. Gunakan identitas unik (seperti Entra Agent ID) untuk agen dan terapkan kontrak yang ketat melalui platform seperti Microsoft Connector Platform (MCP). Langkah ini membantu mencegah pergeseran identitas dan hilangnya akuntabilitas, terutama pada integrasi berbasis AI (selengkapnya tentang tata kelola agentik di sini).
• Terapkan Kebijakan Autentikasi yang Aman: Wajibkan semua vendor dan mitra menggunakan autentikasi modern. Tidak ada pengecualian atas alasan "kompatibilitas lama" tanpa kontrol kompensasi yang disetujui. Tinjau secara berkala pengecualian Akses Bersyarat untuk perangkat pihak ketiga dan alur kerja berbasis konektor.
• Pisahkan dan Pantau OT/IoT serta Perangkat yang Tidak Dapat Ditambal: Jika Anda memiliki teknologi operasional atau perangkat IoT yang terkunci pada protokol lama, pisahkan perangkat tersebut ke jaringan yang terisolasi. Terapkan kontrol kompensasi seperti pemantauan jaringan dan daftar izin akses untuk mengurangi paparan terhadap ancaman pergerakan lateral.
• Jalankan Tinjauan Tata Kelola Jarak Jauh dan Virtual: Adopsi kerangka kerja tata kelola virtual untuk memantau, melakukan remediasi, dan mengatur dari mana saja. Kerangka kerja ini menekankan tinjauan berkala, audit otomatis, dan komunikasi yang jelas antar pemangku kepentingan, yang sangat penting seiring makin banyak operasi yang berjalan secara hibrida atau jarak jauh.

Dengan berfokus pada pengawasan berlapis, bukan hanya kontrol teknis, CISO dan pemimpin TI dapat memitigasi risiko dari bagian ekosistem mereka yang paling sulit dijangkau.

Memanfaatkan Kecerdasan Canggih untuk Memperkuat Operasi Keamanan Melawan Ancaman Protokol Lama

Alat kecerdasan berbasis AI dan analitik ancaman canggih memberi organisasi keunggulan baru dalam mendeteksi, menyelidiki, dan merespons penyalahgunaan protokol lama dalam skala besar. Platform-platform ini menggunakan machine learning untuk mengidentifikasi perilaku autentikasi yang anomali, dengan cepat menyaring penggunaan protokol lama yang mencurigakan, dan melakukan remediasi ancaman secara otomatis tanpa jeda waktu akibat intervensi manusia.

Tim operasi keamanan modern mengintegrasikan data dari Microsoft Sentinel, Purview Audit, dan analitik perilaku berbasis AI untuk membangun tampilan terpusat atas aktivitas autentikasi, baik yang modern maupun yang lama. Playbook otomatis dapat memicu respons untuk pengecualian kebijakan, akun layanan berisiko tinggi, atau peristiwa relai kredensial—menutup celah sebelum penyerang sempat memanfaatkannya.

Mengintegrasikan otomatisasi dan analitik bukanlah pilihan, melainkan keharusan. Platform orkestrasi membantu menyatukan data di lingkungan cloud, on-premises, dan hibrida, sehingga alur autentikasi lama yang tersembunyi pun tidak luput dari pantauan. Hal ini semakin krusial seiring makin banyaknya agen AI dan otomatisasi skala besar, yang sekaligus meningkatkan manfaat sekaligus risiko operasional.

Terakhir, menerapkan akses dengan hak istimewa minimum, memberi label pada konten sensitif, dan memperluas pemantauan audit akan menjaga pengguna manusia maupun mesin tetap terkendali. Untuk blueprint praktis tentang memanfaatkan analitik lanjutan dan AI guna menghadapi ancaman dari autentikasi lama di lingkungan Microsoft—termasuk Copilot dan bot pihak ketiga—lihat panduan terperinci tentang AI terkelola dan kepatuhan ini.