Phishing Persetujuan di Microsoft 365

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Pelajari bagaimana phishing persetujuan Microsoft 365 melewati pertahanan MFA tradisional, menyalahgunakan izin OAuth, serta cara mendeteksi dan mencegahnya.

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

Consent phishing termasuk ancaman yang paling cepat berkembang di lingkungan Microsoft 365 dan Azure. Ancaman ini sering luput dari perhatian organisasi karena melewati bahkan pertahanan autentikasi yang paling kuat. Berbeda dengan phishing klasik yang berusaha mencuri kata sandi Anda, consent phishing memungkinkan penyerang masuk melalui "pintu samping", dengan menyalahgunakan mekanisme yang sebenarnya dibuat untuk membuat proses masuk menjadi aman. Teknik ini memanfaatkan kepercayaan pengguna dan memanfaatkan OAuth, kerangka kerja otorisasi yang sama dengan yang mendukung single sign-on dan integrasi aplikasi yang sah di cloud.

Penyerang dapat menggunakan consent phishing untuk mempertahankan akses yang persisten dan tersembunyi ke data bisnis yang sensitif, bahkan di lingkungan yang dilindungi autentikasi multifaktor (MFA). Panduan ini membahas secara mendalam bagaimana dan mengapa consent phishing melewati keamanan tradisional, menguraikan serangan nyata, dan memandu Anda melalui langkah-langkah praktis untuk mendeteksi, mencegah, dan membatasi ancaman terkait persetujuan. Baik Anda mengelola Microsoft 365 untuk tim kecil maupun mengawasi keamanan untuk ribuan pengguna, memahami cara penyerang bekerja dalam alur persetujuan OAuth kini menjadi keterampilan wajib.

Memahami Phishing Persetujuan dan Mengapa MFA Gagal

Sebelum masuk ke detail teknis, penting untuk memahami gambaran besarnya mengapa consent phishing terus menjadi sorotan dalam dunia keamanan cloud. Kita tidak sedang membicarakan trik phishing biasa yang berusaha mencuri info login Anda lalu menerobos pertahanan dengan percobaan berulang. Consent phishing termasuk kelas serangan yang lebih baru dan lebih halus. Serangan ini memutarbalikkan kemudahan menjadi senjata melawan Anda dengan menyalahgunakan izin aplikasi dan alur otorisasi yang sah.

Dengan platform cloud seperti Microsoft 365 dan Azure, OAuth ada di mana-mana. Inilah cara pengguna menghubungkan aplikasi pihak ketiga, berbagi data, dan mengotomatisasi tugas, sering kali hanya dengan satu klik. Sayangnya, penyerang tahu bahwa pengguna umumnya mempercayai apa pun yang terlihat resmi, dan mereka memanfaatkan momen ketika layar izin muncul sekilas dan tidak ada yang bertanya terlalu banyak. Yang terpenting, serangan ini tidak bergantung pada pencurian kata sandi. Sebaliknya, serangan ini mengelabui pengguna sungguhan agar menyerahkan "kunci kerajaan" mereka. Tidak perlu peretasan, cukup sedikit rekayasa sosial dan penyamaran yang cerdik.

Yang membuat consent phishing sangat berbahaya adalah kemampuannya menyelinap melewati autentikasi multifaktor (MFA) dan langkah-langkah keamanan tradisional. Alih-alih menerobos masuk, penyerang meminta dengan sopan, dan pengguna yang terburu-buru atau tidak sadar dengan sukarela memberikan akses kepada aplikasi berbahaya. Panduan ini akan membantu Anda memahami bagaimana dan mengapa serangan ini sangat berbahaya bagi sistem identitas Microsoft. Dengan perspektif yang tepat, Anda akan melihat bahwa pertahanan terhadap consent phishing membutuhkan pola pikir yang sangat berbeda dibandingkan perlindungan kredensial konvensional.

Apa Itu Phishing Persetujuan dan Mengapa Ia Lolos dari Autentikasi Multifaktor?

Consent phishing adalah jenis serangan ketika pengguna dikelabui untuk memberikan aplikasi yang dikendalikan penyerang akses ke sumber daya cloud mereka, dengan menyetujui permintaan izin OAuth yang tampak sah. Alih-alih mencuri atau menebak kredensial seperti pada phishing tradisional, consent phishing bergantung pada pengguna sendiri yang memberi otorisasi kepada aplikasi berbahaya. Hal ini membuatnya sangat berbahaya di dunia yang berorientasi cloud.

Inilah intinya: ketika Anda menyetujui layar persetujuan, aplikasi menerima token akses dan token penyegaran dari penyedia identitas (seperti Microsoft Entra ID, sebelumnya Azure AD). Token ini dapat digunakan untuk mengakses data Microsoft 365 Anda, seperti email, berkas, kalender, dan lainnya, tanpa pernah mengetahui kata sandi Anda dan tanpa memicu MFA. Penyerang tidak perlu menembus pertahanan login Anda. Mereka cukup menggunakan akses yang Anda berikan dengan sukarela, dan platform menganggapnya sepenuhnya sah.

Perbedaan antara credential phishing dan consent phishing memang halus, tetapi dampaknya besar. Credential phishing berusaha menangkap nama pengguna dan kata sandi Anda (yang sering kali dilindungi oleh MFA), sedangkan consent phishing bekerja di dalam alur kode otorisasi OAuth 2.0 yang resmi. Bahkan ketika MFA diterapkan sepenuhnya, penyerang melewatinya sepenuhnya dengan meminta pengguna menyelesaikan alur persetujuan menggunakan sesi yang sudah ada. Setelah token OAuth diterbitkan, pijakan penyerang tetap bertahan meskipun korban mengubah kata sandinya atau mencabut sesinya.

Untuk pembahasan yang lebih mendalam, lihat ulasan tentang serangan persetujuan OAuth di Entra ID ini, yang merinci risiko nyata dan strategi pertahanan yang sebaiknya diprioritaskan oleh organisasi. Intinya: organisasi harus melihat lebih jauh dari sekadar keamanan kredensial dan MFA jika ingin menghentikan serangan ini sejak sumbernya.

Bagaimana Phishing Persetujuan OAuth Menyalahgunakan Kepercayaan untuk Membobol Data

Penyerang yang menjalankan kampanye phishing persetujuan membuat—atau menyamar sebagai—aplikasi pihak ketiga, lalu meminta pengguna memberikan izin yang luas, sering kali melalui alur OAuth 2.0 yang terasa familiar dan "aman". Pengguna melihat permintaan persetujuan standar dengan permintaan seperti "Baca email Anda" atau "Akses file Anda". Jika pengguna mengklik "Terima", aplikasi berbahaya tersebut mendapatkan token OAuth yang sah, sehingga memperoleh akses langsung ke sumber daya Microsoft 365 atau Azure yang ditentukan.

Dari titik ini, penyerang tidak lagi memerlukan kata sandi, kode, atau cara untuk melewati autentikasi. Token OAuth (khususnya token akses dan token penyegaran) memungkinkan akses berkelanjutan di balik layar. Token ini tetap berlaku sampai dicabut secara manual atau kedaluwarsa, artinya penyerang dapat terus mengambil data, mengirim email, dan melakukan tindakan atas nama korban, meskipun kata sandi telah diubah atau pengguna sudah keluar dari sesi di tempat lain.

Metode ini memanfaatkan kepercayaan implisit pengguna terhadap dialog persetujuan, terutama di lingkungan yang antarmukanya tampak resmi dan waktunya terbatas. Karena alur OAuth menggunakan alur kerja penyedia identitas yang sah, tidak ada proses login yang mencurigakan untuk ditandai, dan tidak ada tantangan MFA yang harus dilewati penyerang. Serangan berlangsung diam-diam, dengan memanfaatkan API yang sama yang dipercaya untuk operasional bisnis sehari-hari.

Untuk rincian pelanggaran nyata dan wawasan yang dapat ditindaklanjuti tentang rantai serangan ini, tinjau analisis langkah demi langkah tentang penyalahgunaan OAuth di Microsoft 365 ini. Pada akhirnya, akses persisten semacam ini menjadi sakit kepala bagi tim pertahanan: penyerang bisa bertahan tanpa terdeteksi, dan jalan menuju pemulihan data dan remediasi aplikasi bisa panjang dan berliku.

Teknik Umum dan Serangan Phishing Persetujuan di Dunia Nyata

Phishing persetujuan bukan sekadar ancaman teoretis—ancaman ini sudah dijadikan senjata dalam sejumlah kampanye berdampak besar terhadap Microsoft 365, Google Workspace, dan ekosistem cloud lainnya. Penyerang terus melakukan iterasi, mulai dari nama aplikasi yang meyakinkan hingga permintaan izin dengan cakupan rendah yang licik. Hasilnya, tim keamanan menghadapi perangkat taktik yang terus berkembang, dengan trik dan variasi baru yang menantang pertahanan di setiap langkah.

Bagian ini membahas apa yang terjadi ketika teori bertemu praktik. Anda akan memahami siklus serangan, apa yang sebenarnya dilihat pengguna selama upaya phishing yang umum, dan bagaimana penyerang meningkatkan akses atau berpindah antarplatform. Mulai dari akumulasi izin yang "pelan tapi pasti" hingga kampanye yang menjadi berita utama seperti ConsentFix, taktik-taktik ini menunjukkan betapa inventif dan gigihnya aktor ancaman dalam menghindari kontrol normal.

Yang paling penting, contoh-contoh nyata ini menegaskan mengapa sangat penting untuk melampaui panduan "cukup aktifkan MFA" yang bersifat umum. Phishing persetujuan menuntut tim pertahanan untuk memikirkan psikologi manusia sekaligus pencegahan teknis, dengan memahami bagaimana rekayasa sosial yang halus, kelemahan desain pada dialog persetujuan, dan celah dalam tata kelola aplikasi menciptakan peluang bagi penyerang. Dengan membedah serangan praktis, bagian ini membantu tim keamanan Anda membangun intuisi yang lebih tajam dan panduan mitigasi yang lebih baik.

Lima Teknik Serangan Phishing Persetujuan Teratas yang Wajib Diketahui Tim Keamanan

1. Peniruan Penerbit: Penyerang membuat aplikasi dengan nama yang mirip vendor resmi—misalnya "Microsoft Secure Suite" atau "HR Docs Cloud". Pengguna mempercayai merek yang familiar, sehingga lebih besar kemungkinan mereka menyetujui permintaan tersebut. Selalu telusuri detail penerbit dan verifikasi sumbernya.
2. Salah Representasi Izin: Aplikasi berbahaya sering menonjolkan izin yang tampak tidak berbahaya pada layar persetujuan, tetapi diam-diam menyisipkan cakupan dengan hak istimewa tinggi seperti "read/write all mailboxes" atau "full access to files". Pengguna yang terbiasa hanya melihat teks tebal mungkin melewatkan risiko sebenarnya dari izin yang diberikan.
3. Hibah Cakupan Rendah untuk Eskalasi Lanjutan: Sebagian penyerang meminta izin dasar (seperti akses ke profil Anda) untuk menghindari kecurigaan. Setelah itu, mereka memanfaatkan akses token awal sebagai pijakan, lalu mencoba persetujuan yang lebih berbahaya melalui phishing bertahap atau eskalasi hak istimewa.
4. Pergerakan Lateral dengan Token OAuth yang Bertahan: Setelah berhasil masuk, penyerang memanfaatkan token dan izin aplikasi untuk bergerak ke samping, misalnya mengakses drive bersama, acara kalender, atau meningkatkan hak akses di dalam Microsoft 365. Token dapat memberikan akses yang "pas-pasan" di awal, tetapi kemudian diperluas atau diperbarui.
5. Aplikasi Pihak Ketiga yang Disusupi: Alih-alih membuat aplikasinya sendiri, penyerang terkadang membobol atau memanfaatkan kembali aplikasi dari independent software vendor (ISV) tepercaya yang sudah memiliki izin luas dari banyak penyewa. Serangan rantai pasok ini sangat sulit dideteksi dan dapat menyebar dengan cepat ke berbagai organisasi.

Untuk pembahasan teknis mendalam tentang mekanisme yang mendasarinya dan cara memperkuat Entra ID terhadap pola-pola ini, silakan baca ulasan terperinci tentang penyalahgunaan persetujuan OAuth ini. Ini hanyalah sebagian kecil dari berbagai cara kreatif yang telah dipelajari penyerang untuk melampaui pertahanan lama dan MFA.

Cara Kerja Kampanye ConsentFix Langkah demi Langkah

1. Email Phishing Awal: Serangan dimulai dengan email meyakinkan yang mendesak pengguna untuk "memperbaiki masalah kebijakan" atau "mengamankan kotak surat mereka". Pesan tersebut berisi tautan yang disamarkan sebagai sumber resmi Microsoft.
2. Pengalihan ke Halaman Persetujuan Aplikasi Berbahaya: Saat tautan diklik, pengguna diarahkan ke permintaan persetujuan OAuth. Tampilannya terlihat familiar, bermerek, dan sah, tetapi aplikasi di baliknya dikendalikan oleh penyerang, sering kali dengan nama yang ditiru atau menyesatkan.
3. Pemberian Persetujuan dan Penerbitan Token: Pengguna meninjau izin yang diminta, yang biasanya disebut diperlukan untuk "keamanan" atau "kepatuhan", lalu mengklik "Terima". Tindakan ini memberikan penyerang token akses dan token penyegaran untuk akun pengguna.
4. Penyerang Memperoleh Akses Berkelanjutan: Dengan token tersebut, penyerang dapat mengakses kotak surat, file, kalender, atau API data sensitif lain di Microsoft 365. Sesi ini tetap bertahan meskipun kata sandi diubah dan bahkan sebagian besar reset MFA, hingga persetujuan dicabut secara manual.
5. Pengumpulan Data Diam-Diam dan Monetisasi: Penyerang diam-diam menyedot konten email, dokumen sensitif, atau memulai pergerakan lateral ke layanan yang terhubung. Karena semuanya tampak "resmi", deteksi menjadi sulit, kecuali tim Anda memantau aktivitas aplikasi yang tidak biasa atau persetujuan baru.

Jika Anda ingin melihat secara rinci bagaimana penyerang merangkai langkah-langkah ini di Microsoft 365 menggunakan Entra ID, silakan simak panduan teknis tentang serangan persetujuan OAuth ini.

Mengapa ConsentFix Penting bagi Keamanan Microsoft 365 dan Cloud

Kampanye ConsentFix menunjukkan betapa cepat dan diam-diamnya penyerang dapat menyusupi Microsoft 365, Google Workspace, dan penyewaan SaaS lainnya dengan menyalahgunakan alur OAuth yang sah. Organisasi di berbagai sektor mengalami akses email tanpa izin, kebocoran file, dan kegigihan akun yang berkepanjangan, bahkan setelah reset kata sandi dan MFA diterapkan. Serangan-serangan ini menegaskan urgensi pertahanan berlapis: kesadaran pengguna, pemantauan persetujuan secara real-time, dan tata kelola aplikasi yang kuat bukan sekadar "nice to have", melainkan krusial untuk mencegah pelanggaran dan kehilangan data berskala besar di cloud.

Mendeteksi Aplikasi Berbahaya dan Memantau Persetujuan yang Tidak Wajar

Mengenali dan merespons ancaman berbasis OAuth tidak selalu mudah, karena serangan ini menyatu dengan lalu lintas bisnis normal Anda. Pada saat dampaknya terlihat, aplikasi berbahaya mungkin sudah diam-diam menyedot data sensitif selama berhari-hari atau berminggu-minggu. Itulah mengapa strategi deteksi proaktif sangat penting. Tim keamanan membutuhkan lebih dari sekadar kontrol preventif; mereka membutuhkan wawasan nyata tentang pola persetujuan pengguna, perilaku aplikasi, dan seperti apa kondisi "normal" di seluruh organisasi.

Bagian ini berfokus pada pendekatan praktis untuk deteksi dini dan investigasi. Anda akan belajar cara menggunakan sinyal perilaku, pemantauan anomali, dan alat enterprise native Microsoft untuk menangkap peristiwa persetujuan berisiko sebelum semuanya lepas kendali. Mulai dari aktivitas API yang tidak biasa hingga lonjakan pendaftaran aplikasi baru, petunjuk yang tepat dapat membantu Anda mengenali serangan yang sedang berlangsung, lalu segera mengunci semuanya.

Anggap ini sebagai "kamera pengawas" di lingkungan cloud Anda. Pemantauan berkelanjutan, pencatatan otomatis, dan peringatan yang cerdas memberi Anda peluang nyata untuk membatasi waktu tinggal penyerang (attacker dwell time) dan meminimalkan kerusakan. Jika Anda menargetkan otomatisasi kepatuhan atau membutuhkan integrasi dengan manajemen risiko yang lebih luas, integrasi dengan alat seperti Microsoft Defender for Cloud dapat membawa upaya Anda ke tingkat berikutnya. Untuk wawasan tentang menjaga lingkungan Anda tetap patuh dan aman dengan otomatisasi, lihat panduan ini tentang memantau kepatuhan di Microsoft Defender for Cloud.

Cara Mendeteksi Aplikasi Berbahaya Menggunakan Sinyal Perilaku dan Persetujuan

1. Pantau Pemberian Persetujuan yang Tidak Terduga: Waspadai persetujuan OAuth baru, terutama yang disetujui di luar jam kerja normal atau berasal dari penerbit yang tidak dikenal. Jumlah aplikasi baru yang diotorisasi dalam jumlah besar dapat menjadi tanda bahaya.
2. Analisis Pola Panggilan API yang Mencurigakan: Perhatikan perilaku abnormal, seperti akses file berkecepatan tinggi, pembacaan kotak surat secara massal, atau penggunaan API admin yang tidak lazim. Penyerang sering "memakai berlebihan" izin dibandingkan aplikasi biasa.
3. Waspadai Aktivitas Token yang Tidak Biasa: Lacak pembuatan refresh token yang cepat atau berulang serta pola yang janggal dalam siklus hidup token. Aplikasi berbahaya dapat menyalahgunakan refresh token untuk mempertahankan akses jauh setelah kompromi awal.
4. Manfaatkan Log dan Defender Microsoft: Gunakan produk keamanan aplikasi cloud dan log Entra ID untuk membuat inventaris semua aplikasi yang diotorisasi, sehingga aplikasi berisiko atau shadow app yang melewati alur persetujuan TI normal dapat terlihat. Alat seperti Microsoft Defender for Cloud Apps memberikan visibilitas dan peringatan untuk perilaku aplikasi yang mencurigakan.
5. Tindak Lanjuti Temuan Shadow IT: Banyak insiden berawal dari akses aplikasi yang tidak disetujui atau tidak dikelola. Audit penyewa (tenant) Anda secara berkala, tindak lanjuti temuan aplikasi berisiko, dan bersihkan izin OAuth dengan hak akses berlebihan. Pelajari selengkapnya tentang menangani shadow IT dan mengendalikan aplikasi liar di panduan ini tentang mengelola shadow IT di Microsoft 365.

Menyelidiki Serangan Consent Phishing dengan Microsoft 365 Defender dan Entra ID Protection

1. Threat Hunting: Mulailah dengan mencari log Entra ID dan peringatan Microsoft 365 Defender untuk peristiwa persetujuan terbaru, pembuatan aplikasi yang mencurigakan, atau pola sign-in anomali yang terkait dengan aplikasi OAuth.
2. Investigasi Terarah: Telusuri riwayat pengguna dan aplikasi secara individual, periksa izin apa saja yang diberikan, kapan, dan oleh siapa. Bandingkan aktivitas ini dengan baseline normal dan waktu alur kerja bisnis.
3. Remediasi: Ketika persetujuan berbahaya ditemukan, segera cabut token aplikasi dan pemberian persetujuan. Microsoft 365 Defender memungkinkan pencabutan massal dan dapat menandai sesi berisiko tambahan. Ini mencegah penyerang menggunakan token persisten untuk mempertahankan akses.
4. Pemantauan Berkelanjutan dan Otomatisasi: Otomatiskan peringatan untuk persetujuan aplikasi berisiko tinggi yang baru, permintaan persetujuan admin yang berulang, atau ID penerbit berbahaya yang sudah diketahui. Atur kebijakan otomatis untuk respons yang lebih cepat dan pengurangan waktu tinggal penyerang.
5. Integrasikan Kepatuhan dan Penegakan Kebijakan: Gunakan Microsoft Defender for Cloud untuk pemantauan kepatuhan berkelanjutan bersama respons insiden, dan lihat pendekatan tata kelola identitas di Entra ID untuk memastikan kebijakan keamanan tetap dapat ditegakkan dari waktu ke waktu. Ini memastikan Anda menangkap serangan real-time sekaligus mencegah konfigurasi yang melenceng (configuration drift) atau utang identitas (identity debt) yang dapat membuka risiko baru.

Mengamankan Lingkungan Anda dengan Kebijakan Persetujuan dan Pembatasan Aplikasi

Jika Anda ingin menghentikan consent phishing sejak awal, Anda harus langsung menyasar sumbernya: kebijakan dan pengaturan konfigurasi yang mengatur bagaimana aplikasi meminta dan menerima persetujuan pengguna. Mengatur kontrol ini membutuhkan keseimbangan yang cermat, yaitu memungkinkan pengguna tetap produktif dengan integrasi tepercaya, sekaligus mencegah siapa pun secara tidak sengaja (atau sengaja) membiarkan serigala berbulu domba masuk.

Bagian ini berfungsi sebagai peta jalan praktis bagi cloud admin dan CISO, yang menelusuri tuas teknis utama yang tersedia: mulai dari desain kebijakan consent dan verifikasi penerbit, hingga pengelolaan ketat masa berlaku token OAuth. Jika dilakukan dengan benar, strategi-strategi ini dapat meminimalkan risiko dan membatasi dampak jika penyerang berhasil masuk. Tata kelola yang konsisten sangat penting, terutama ketika daftar integrasi SaaS Anda terus bertambah dan shadow IT semakin sulit diabaikan.

Tata kelola bukan tentang mengatakan "tidak" pada inovasi, melainkan tentang mengontrol akses, menetapkan alur kerja tepercaya, dan menegakkan batasan yang menjaga lingkungan Anda tetap sehat seiring pertumbuhannya. Jika Anda sedang menyusun kerangka keamanan yang lebih luas, pelajaran di sini juga berlaku jauh melampaui Microsoft 365, mencakup Power Platform dan SaaS bisnis lainnya. Untuk wawasan tambahan tentang praktik terbaik, lihat panduan tata kelola dan keamanan Power Platform ini.

Cara Mengonfigurasi Kebijakan Consent dan Membatasi Consent Pengguna

1. Batasi Consent Pengguna secara Default: Di Microsoft Entra ID, konfigurasikan pengaturan di seluruh penyewa sehingga hanya administrator yang dapat menyetujui consent aplikasi berisiko tinggi. Pengguna akhir hanya boleh melihat layar consent untuk aplikasi berisiko rendah, sehingga persetujuan tidak disengaja dapat diminimalkan.
2. Aktifkan Alur Kerja Persetujuan Admin: Wajibkan peninjauan dan persetujuan administratif untuk setiap aplikasi yang meminta izin luas atau sensitif. Langkah ini menghentikan otorisasi "drive-by" pada aplikasi berisiko dan membangun catatan formal tentang aktivitas consent.
3. Pembatasan Izin secara Granular: Jangan menggunakan izin "izinkan semua" secara menyeluruh. Batasi consent hanya pada yang benar-benar dibutuhkan untuk kebutuhan bisnis. Definisi scope kustom menyulitkan penyerang untuk menyelinap masuk dengan hak istimewa yang berbahaya.
4. Audit Consent Grant secara Rutin: Tinjau aplikasi mana saja yang saat ini memiliki izin ke penyewa Anda, terutama yang diberikan oleh pengguna tanpa pengawasan TI. Cabut consent yang sudah usang atau tidak diperlukan untuk mengurangi attack surface Anda.
5. Manfaatkan Kebijakan Akses Bersyarat: Padukan pembatasan consent dengan kebijakan akses bersyarat yang kuat, termasuk penegakan berbasis lokasi, perangkat, atau risiko, untuk memblokir session hijacking atau akses dari perangkat yang tidak dikelola.

Untuk tips praktis dan terperinci tentang memperkuat Entra ID dan meminimalkan alur consent yang berisiko, lihat panduan lengkap ini.

Menegakkan Verifikasi Penerbit dan Membatasi Akses ke Aplikasi First-Party

1. Wajibkan Verifikasi Penerbit: Hanya izinkan aplikasi dari penerbit terverifikasi untuk meminta consent pengguna atau admin di lingkungan Anda. Langkah ini memastikan pengembang aplikasi telah memvalidasi identitasnya, sehingga menambah lapisan kepercayaan yang memblokir sebagian besar serangan peniruan identitas secara langsung.
2. Blokir Penerbit yang Belum Terverifikasi: Di Entra ID dan platform lainnya, atur kebijakan dasar untuk menolak otomatis consent bagi aplikasi yang tidak memenuhi standar verifikasi penerbit. Tinjau status penerbit untuk semua aplikasi, baik yang sudah ada maupun yang baru, secara rutin.
3. Batasi Consent hanya ke Aplikasi First-Party Tepercaya: Perketat konfigurasi sehingga hanya aplikasi first-party (misalnya resmi dari Microsoft) atau aplikasi pihak ketiga yang disetujui secara spesifik yang dapat meminta consent baru. Langkah ini secara signifikan mengurangi risiko pergerakan lateral dari satu aplikasi yang disusupi ke aplikasi lainnya.
4. Audit dan Inventarisasi Akses Penerbit: Jadikan status penerbit dan inventaris aplikasi sebagai agenda tetap dalam siklus tinjauan keamanan rutin TI, dengan memanfaatkan alat otomatis untuk menyoroti penerbit baru atau yang belum disetujui.
5. Terapkan ke Semua Platform yang Terhubung: Perluas verifikasi penerbit dan pembatasan aplikasi ke Power Platform, aplikasi Teams, dan SaaS yang terhubung. Pelajari lebih lanjut cara melakukannya dalam skala yang lebih luas di panduan tata kelola Power Platform ini.

Mengelola Masa Berlaku Token dan Menerapkan Pemantauan Berkelanjutan untuk Keamanan OAuth

Konfigurasi masa berlaku token OAuth yang lebih singkat mengurangi jendela waktu yang dimiliki penyerang untuk memanfaatkan token yang dicuri atau yang telah disetujui. Sesuaikan kebijakan kedaluwarsa token sehingga token akses cepat kedaluwarsa dan token penyegaran dirotasi secara berkala. Terapkan token binding dan pencabutan berbasis risiko untuk menghentikan sesi yang mencurigakan atau disalahgunakan. Gabungkan langkah-langkah ini dengan pemantauan berkelanjutan terhadap penggunaan token dan peristiwa persetujuan untuk mendeteksi pola yang tidak biasa, dengan memanfaatkan alat seperti Microsoft Defender for Office 365 dan kebijakan akses bersyarat Entra, agar token yang disusupi tidak berubah menjadi ancaman yang persisten dan senyap. Untuk pengaturan praktis dan strategi pemantauan berkelanjutan, lihat rekomendasi keamanan Microsoft berikut.

Memperkuat Tata Kelola dan Membangun Kesadaran Pengguna terhadap Phishing Persetujuan

Kontrol teknis hanya mampu melindungi sampai batas tertentu menghadapi serangan cloud yang terus berkembang. Ketahanan jangka panjang membutuhkan budaya keamanan, di mana tata kelola yang kuat, audit rutin, dan edukasi pengguna saling memperkuat. Phishing persetujuan memanfaatkan psikologi manusia sama besarnya dengan teknologi, sehingga keberhasilan bergantung pada kebijakan formal sekaligus kewaspadaan harian dari seluruh tim Anda.

Bagian ini membahas secara mendetail cara membangun kerangka tata kelola OAuth dan mengaudit hibah aplikasi yang sudah ada, strategi pelatihan praktis untuk membantu pengguna mengenali permintaan persetujuan yang mencurigakan, serta cara menyiapkan alur kerja yang memberi hambatan nyata bagi penyerang terhadap data Anda. Tujuannya: memastikan pertahanan Anda tidak berhenti di depan pintu departemen TI, melainkan menjangkau seluruh bisnis.

Bagi organisasi dengan ekosistem aplikasi yang kompleks, taruhannya bahkan lebih tinggi. Kesalahan di mana pun dalam rantai pasok Anda dapat merambat ke luar. Tata kelola dan kesadaran yang proaktif serta berkelanjutan sangat penting untuk menjaga keamanan data sensitif dan kepatuhan tetap terkendali, meskipun jumlah pengguna dan inventaris aplikasi terus bertambah. Untuk saran tata kelola tingkat lanjut, termasuk DLP dan audit tingkat lanjut di lingkungan Microsoft, lihat panduan tata kelola Copilot yang mendalam ini dan rincian tentang pengauditan aktivitas pengguna dengan Microsoft Purview Audit.

Membangun Kerangka Tata Kelola OAuth dan Mengaudit Hibah yang Ada

1. Tentukan Kebijakan Persetujuan dan Penggunaan Aplikasi: Tetapkan aturan yang jelas tentang pengguna dan aplikasi mana yang boleh meminta persetujuan, serta rinci jenis izin yang diizinkan dan kasus penggunaan bisnisnya. Publikasikan panduan ini agar semua orang di organisasi Anda mengetahui aturan mainnya.
2. Pelihara Inventaris Aplikasi Lengkap: Catat semua aplikasi terhubung OAuth di Entra ID, termasuk siapa yang memberikan setiap persetujuan, penerbitnya, cakupan yang diminta, dan justifikasi bisnisnya. Penemuan otomatis menggunakan API Entra atau Microsoft Defender dapat mempercepat proses ini dan menemukan aplikasi bayangan.
3. Lakukan Audit Hibah secara Berkala: Jadwalkan tinjauan triwulanan atau dua kali setahun untuk menemukan izin yang sudah usang, duplikat, atau berisiko. Periksa juga status verifikasi penerbit aplikasi, dan cabut hibah untuk aplikasi yang sudah tidak digunakan atau yang telah menjadi mencurigakan.
4. Pantau dan Atasi Penyimpangan: Siapkan peringatan untuk pelanggaran kebijakan, misalnya pengguna yang memberikan izin luas kepada penerbit yang tidak disetujui, dan jalankan kampanye remediasi segera setelah celah ditemukan. Audit rutin menjaga pertahanan Anda tetap tangkas dan ekosistem aplikasi Anda tetap sehat.
5. Integrasikan Tata Kelola dengan Kepatuhan dan DLP: Untuk lingkungan dengan risiko tinggi atau yang diatur regulasi, kaitkan tata kelola OAuth dengan DLP Microsoft Purview dan pencatatan audit Anda. Lihat panduan tata kelola Purview ini untuk cara praktis memantau aktivitas pengguna dan batas konektor dalam skala besar.

Meningkatkan Pelatihan Kesadaran dan Alur Kerja Persetujuan Aplikasi

• Pelatihan Pengguna yang Terfokus tentang Risiko OAuth: Selenggarakan lokakarya atau modul e-learning secara berkala untuk mengajarkan staf tentang bahaya permintaan aplikasi yang mencurigakan, izin yang menyesatkan, dan kepercayaan berlebihan pada antarmuka dengan merek tertentu. Tekankan contoh nyata, seperti email phishing dan layar persetujuan, agar pengguna dapat mengenali tanda bahaya.
• Simulasikan Serangan Consent Phishing: Jalankan uji phishing simulasi yang berfokus pada alur OAuth untuk membangun insting dan kesiapan pengguna. Dorong pengguna untuk melaporkan permintaan yang janggal tanpa rasa takut.
• Formalkan Alur Kerja Persetujuan Aplikasi: Wajibkan bahwa setiap integrasi aplikasi pihak ketiga, terutama yang meminta izin sensitif, harus melalui proses persetujuan yang dipimpin IT sebelum siapa pun dapat memberikan consent.
• Kampanye Kesadaran Kebijakan: Lengkapi pelatihan teknis dengan poster, pengingat rutin, dan penyegaran kebijakan. Jadikan keputusan consent yang aman sebagai topik berkelanjutan, bukan "pasang lalu lupakan."
• Pantau Shadow IT dari Sisi Pengguna: Padukan penegakan alur kerja dengan teknologi yang menandai dan memblokir upaya menggunakan SaaS yang tidak disetujui atau agen AI yang tidak resmi. Untuk pembahasan lebih lanjut tentang menghadapi tantangan shadow IT AI, lihat panduan tata kelola ini.

Hygiene Sisi Pengembang dan Rekomendasi Keamanan Aplikasi untuk ISV dan CISO

• Verifikasi Penerbit: Daftarkan dan verifikasi penerbit untuk meningkatkan transparansi aplikasi dan kepercayaan pembeli enterprise.
• Izin yang Jelas dan Minimal: Hanya minta scope yang diperlukan untuk fungsionalitas—hindari permintaan izin berlebihan yang menimbulkan kecurigaan pengguna dan berisiko ditolak.
• Rancang Alur Consent yang Aman: Gunakan nama aplikasi yang jujur, deskripsi yang jelas, dan pernyataan tujuan yang eksplisit untuk mencegah kebingungan pengguna dan persetujuan yang tidak disengaja.
• Terapkan Praktik Pengembangan yang Aman: Perbarui komponen aplikasi secara rutin dan terapkan pipeline pengujian keamanan untuk memblokir kerentanan rantai pasokan.
• Panduan Kebijakan CISO: Wajibkan tinjauan keamanan aplikasi internal, pelihara inventaris aplikasi yang selalu diperbarui, dan kodifikasikan sikap organisasi terhadap risiko penerbit pihak ketiga sebelum menyetujui integrasi baru.

Dengarkan Juga Episode Berikut

Jika Anda mendalami Microsoft 365 consent phishing, episode-episode ini menambahkan konteks praktis untuk adopsi Microsoft 365 yang aman, perlindungan data, tata kelola, dan manajemen risiko AI.

• Microsoft Purview – Simply Explained — Lihat bagaimana klasifikasi, retensi, kepatuhan, dan perlindungan menyatu dalam satu model tata kelola data Microsoft.
• Microsoft Defender XDR – Simply Explained — Hubungkan kontrol perlindungan data dengan deteksi, investigasi, dan respons.
• Conditional Access – Simply Explained — Pahami bagaimana sinyal identitas dan risiko menambahkan konteks pada keputusan akses.
• Microsoft AI Agent Harness – Simply Explained — Jelajahi kontrol yang membuat otomatisasi AI lebih andal, mudah diamati, dan aman.

Episode-episode ini membantu mengubah konsep artikel menjadi keputusan desain dan penerapan yang praktis.