Bagikan melalui

Investigasi pemberian persetujuan aplikasi

  • Artikel

Artikel ini memberikan panduan tentang mengidentifikasi dan menyelidiki serangan persetujuan aplikasi, melindungi informasi, dan meminimalkan risiko lebih lanjut.

Artikel ini berisi bagian berikut:

  • Prasyarat: Mencakup persyaratan khusus yang perlu Anda selesaikan sebelum memulai penyelidikan. Misalnya, pengelogan yang harus diaktifkan, peran dan izin yang diperlukan, antara lain.
  • Alur kerja: Menampilkan alur logis yang harus Anda ikuti untuk melakukan penyelidikan ini.
  • Daftar periksa: Berisi daftar tugas untuk setiap langkah dalam bagan alur. Daftar periksa ini dapat membantu di lingkungan yang sangat diatur untuk memverifikasi langkah-langkah yang diambil atau hanya sebagai gerbang kualitas untuk diri Anda sendiri.
  • Langkah-langkah investigasi: Menyertakan panduan langkah demi langkah terperinci untuk penyelidikan khusus ini.
  • Pemulihan: Berisi langkah-langkah tingkat tinggi tentang cara memulihkan/mengurangi dari serangan pemberian Persetujuan Aplikasi Terlarang.
  • Referensi: Berisi lebih banyak materi bacaan dan referensi.

Prasyarat

Berikut adalah pengaturan dan konfigurasi umum yang harus Anda selesaikan saat melakukan penyelidikan untuk Pemberian Persetujuan Aplikasi. Sebelum memulai penyelidikan, pastikan baca tentang jenis izin persetujuan yang dijelaskan dalam jenis izin Persetujuan.

Data pelanggan

Untuk memulai proses investigasi, Anda memerlukan data berikut:

  • Detail indikator kompromi (IoC)
  • Tanggal dan waktu ketika Anda melihat insiden
  • Rentang tanggal
  • Jumlah akun yang disusupi
  • Nama akun yang disusupi
  • Peran akun yang disusupi
  • Apakah akun sangat istimewa (GA Microsoft Exchange, SharePoint)?
  • Apakah ada Aplikasi Perusahaan yang terkait dengan insiden tersebut?
  • Apakah pengguna melaporkan aplikasi apa pun yang meminta izin ke data atas nama mereka?

Persyaratan sistem

Pastikan Anda menyelesaikan penginstalan dan persyaratan konfigurasi berikut:

  1. Modul AzureAD PowerShell diinstal.
  2. Anda memiliki hak Administrator Global pada penyewa yang dijalankan skrip.
  3. Anda diberi peran administrator lokal di komputer yang Anda gunakan untuk menjalankan skrip.

Catatan

Modul Azure ACTIVE Directory dan MSOnline PowerShell tidak digunakan lagi per 30 Maret 2024. Untuk mempelajari lebih lanjut, baca pembaruan penghentian. Setelah tanggal ini, dukungan untuk modul ini terbatas pada bantuan migrasi ke Microsoft Graph PowerShell SDK dan perbaikan keamanan. Modul yang tidak digunakan lagi akan terus berfungsi hingga Maret, 30 2025.

Sebaiknya migrasi ke Microsoft Graph PowerShell untuk berinteraksi dengan ID Microsoft Entra (sebelumnya Microsoft Azure AD). Untuk pertanyaan umum tentang migrasi, lihat Tanya Jawab Umum Migrasi. Catatan: MSOnline versi 1.0.x mungkin mengalami gangguan setelah 30 Juni 2024.

Menginstal modul Azure AD

Gunakan perintah ini untuk menginstal modul AzureAD.

Install-Module -Name AzureAD -Verbose

Catatan

Jika Anda diminta untuk menginstal modul dari repositori yang tidak tepercaya, ketik Y dan tekan Enter.

Menginstal modul MSOnline PowerShell

  1. Jalankan aplikasi Windows PowerShell dengan hak istimewa yang ditinggikan (jalankan sebagai administrator).

  2. Jalankan perintah ini untuk memungkinkan PowerShell menjalankan skrip yang ditandatangani.

    Set-ExecutionPolicy RemoteSigned

  3. Instal modul MSOnline dengan perintah ini.

    Install-Module -Name MSOnline -Verbose

    Catatan

    Jika Anda diminta untuk menginstal modul dari repositori yang tidak tepercaya, ketik Y dan tekan Enter.

Unduh Skrip AzureADPSPermissions dari GitHub

  1. Unduh skrip Get-AzureADPSPermissions.ps1 dari GitHub ke folder tempat Anda menjalankan skrip. File output "permissions.csv" juga ditulis ke folder yang sama ini.

  2. Buka instans PowerShell sebagai administrator dan buka folder tempat Anda menyimpan skrip.

  3. Sambungkan ke direktori Anda menggunakan Connect-AzureAD cmdlet. Berikut adalah contoh.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  4. Jalankan perintah PowerShell ini.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Putuskan sambungan sesi AzureAD Anda dengan perintah ini.

    Disconnect-AzureAD

Persetujuan adalah proses pemberian otorisasi kepada aplikasi untuk mengakses sumber daya yang dilindungi atas nama pengguna. Administrator atau pengguna dapat dimintai persetujuan untuk mengizinkan akses ke data organisasi/individu mereka.

Aplikasi diberikan akses ke data berdasarkan pengguna tertentu atau untuk seluruh organisasi. Penyerang dapat menyalahgunakan persetujuan ini untuk mendapatkan kegigihan lingkungan dan mengakses data sensitif. Jenis serangan ini disebut Pemberian Persetujuan Terlarang, yang dapat terjadi melalui email phishing, akun pengguna disusupi melalui semprotan kata sandi, atau ketika penyerang mendaftarkan aplikasi sebagai pengguna yang sah. Dalam skenario di mana akun administrator disusupi, maka pendaftaran dan pemberian persetujuan adalah untuk seluruh penyewa dan bukan hanya untuk satu pengguna.

Sebelum aplikasi dapat mengakses data organisasi Anda, pengguna harus memberikan izin kepada aplikasi untuk melakukannya. Izin yang berbeda memungkinkan tingkat akses yang berbeda. Secara default, semua pengguna diizinkan untuk menyetujui aplikasi untuk izin yang tidak memerlukan persetujuan administrator. Misalnya, secara default, pengguna dapat menyetujui untuk mengizinkan aplikasi mengakses kotak surat mereka tetapi tidak dapat menyetujui untuk mengizinkan aplikasi akses yang tidak terkalahkan untuk membaca dan menulis ke semua file di organisasi Anda.

Catatan

Dengan mengizinkan pengguna memberi aplikasi akses ke data, pengguna dapat dengan mudah memperoleh aplikasi yang berguna dan menjadi produktif. Namun, dalam beberapa situasi, konfigurasi ini dapat mewakili risiko jika tidak dipantau dan dikontrol dengan hati-hati.

Agar dapat memberikan persetujuan admin di seluruh penyewa, Anda harus masuk dengan setidaknya salah satu peran berikut:

  • Admin Aplikasi
  • Admin Aplikasi Cloud
  • Administrator - Menunjukkan persetujuan diberikan oleh administrator (atas nama organisasi)
  • Pengguna individual - Menunjukkan persetujuan diberikan oleh pengguna dan hanya memiliki akses ke informasi pengguna tersebut
  • Nilai yang diterima
    • AllPrincipals - Disetujui oleh administrator untuk seluruh penyewaan
    • Prinsipal – Disetujui oleh pengguna individu untuk data hanya terkait dengan akun tersebut

Pengalaman pengguna aktual untuk memberikan persetujuan berbeda tergantung pada kebijakan yang ditetapkan pada penyewa pengguna, cakupan otoritas (atau peran) pengguna, dan jenis izin yang diminta oleh aplikasi klien. Ini berarti bahwa pengembang aplikasi dan admin penyewa memiliki kontrol atas pengalaman persetujuan. Admin memiliki fleksibilitas untuk mengatur dan menonaktifkan kebijakan pada penyewa atau aplikasi untuk mengontrol pengalaman persetujuan di penyewa mereka. Pengembang aplikasi dapat menentukan jenis izin apa yang diminta dan jika mereka ingin memandu pengguna melalui alur persetujuan pengguna atau alur persetujuan admin.

  • Alur persetujuan pengguna - Saat pengembang aplikasi mengarahkan pengguna ke titik akhir otorisasi dengan niat untuk merekam persetujuan hanya untuk pengguna saat ini.

  • Alur persetujuan admin - Saat pengembang aplikasi mengarahkan pengguna ke titik akhir persetujuan admin dengan niat untuk merekam persetujuan untuk seluruh penyewa. Untuk memastikan alur persetujuan admin berfungsi dengan baik, pengembang aplikasi harus mencantumkan semua izin di properti RequiredResourceAccess dalam manifes aplikasi.

Izin yang didelegasikan vs. izin aplikasi

Izin yang didelegasikan digunakan oleh aplikasi yang memiliki pengguna yang masuk dan dapat memiliki persetujuan yang diterapkan oleh administrator atau pengguna.

Izin aplikasi digunakan oleh aplikasi yang berjalan tanpa kehadiran pengguna yang masuk. Misalnya, aplikasi yang berjalan sebagai layanan latar belakang atau daemon. Izin aplikasi hanya dapat disetujui oleh administrator.

Untuk informasi selengkapnya, lihat:

Mengklasifikasikan izin berisiko

Ada ribuan (setidaknya) izin dalam sistem, dan tidak layak untuk mencantumkan atau mengurai semua ini. Daftar berikut ini membahas izin yang umumnya disalahgunakan dan lainnya yang akan membuat dampak bencana jika disalahgunakan.

Pada tingkat tinggi, Microsoft telah mengamati izin yang didelegasikan "root" berikut (App+User) yang disalahgunakan dalam serangan phishing persetujuan. Root sama dengan tingkat atas. Misalnya, Kontak.* berarti menyertakan semua permutasi izin Kontak yang didelegasikan: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared, dan Contacts.ReadWrite.Shared.

  1. Mail.* (termasuk Mail.Send*, tetapi bukan Mail.ReadBasic*)
  2. Kontak. *
  3. MailboxSettings.*
  4. Rakyat.*
  5. File.*
  6. Catatan.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Tujuh izin pertama dalam daftar sebelumnya adalah untuk Microsoft Graph dan setara API "warisan", seperti Azure Active Directory (Azure AD) Graph dan Outlook REST. Izin kedelapan adalah untuk Azure Resource Manager (ARM) dan juga bisa berbahaya pada API apa pun yang mengekspos data sensitif dengan cakupan peniruan selimut ini.

Berdasarkan pengamatan tim Respons Insiden Microsoft, penyerang menggunakan kombinasi enam izin pertama dalam 99% dari serangan phishing persetujuan. Sebagian besar orang tidak menganggap versi Mail.Read atau Files.Read yang didelegasikan sebagai izin berisiko tinggi, namun, serangan umumnya tersebar luas dan menargetkan pengguna akhir, daripada mengelabui tombak terhadap admin yang benar-benar dapat menyetujui izin berbahaya. Disarankan untuk menyatukan aplikasi dengan tingkat izin dampak "kritis" ini. Bahkan jika aplikasi tidak memiliki niat jahat, dan jika aktor jahat membahayakan identitas aplikasi, maka seluruh organisasi Anda bisa berisiko.

Untuk izin dampak risiko tertinggi, mulai di sini:

  • Versi izin aplikasi (AppOnly/AppRole) dari semua izin di atas, jika berlaku

Versi izin berikut yang didelegasikan dan AppOnly:

  • Application.ReadWrite.All
  • Direktori.ReadWrite.All
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Semua izin AppOnly lainnya yang memungkinkan akses tulis

Untuk daftar izin dampak risiko terendah, mulai di sini:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • email
  • Profil
  • Offline_access (hanya jika dipasangkan dengan izin lain pada daftar "risiko terendah" ini)

Menampilkan izin

  1. Untuk melihat izin, navigasikan ke layar Pendaftaran di aplikasi perusahaan.

    lihat izin

  2. Pilih Tampilkan izin API.

    apipermissions

  3. Pilih Tambahkan izin dan layar berikut ditampilkan.

    api

  4. Pilih Microsoft Graph untuk melihat berbagai jenis izin.

    jenis izin

  5. Pilih jenis izin yang digunakan aplikasi terdaftar: Izin yang didelegasikan atau Izin aplikasi. Pada gambar di atas, Izin aplikasi dipilih.

  6. Anda dapat mencari salah satu izin dampak risiko tinggi seperti EduRoster.

    contohpermission

  7. Pilih EduRoster dan perluas izin.

    eduroster

  8. Sekarang Anda dapat menetapkan atau meninjau izin ini.

    Untuk informasi selengkapnya, Izin Grafik.

Alur kerja

[Alur kerja investigasi pemberian persetujuan aplikasi]

Anda juga dapat:

  • Unduh pemberian persetujuan aplikasi dan alur kerja playbook respons insiden lainnya sebagai PDF.
  • Unduh pemberian persetujuan aplikasi dan alur kerja playbook respons insiden lainnya sebagai file Visio.

Daftar periksa

Gunakan daftar periksa ini untuk melakukan validasi pemberian persetujuan aplikasi.

  • Indikator kompromi (IoC)

    Periksa indikator kompromi berikut (IoC):

    • Kapan kau melihat insiden itu?
    • Rentang tanggal insiden (seberapa jauh ke kiri posting tujuan?)
    • Jumlah akun yang disusupi
    • Nama akun yang disusupi
    • Peran akun yang disusupi
    • Apakah akun yang disusupi sangat istimewa, pengguna standar, atau kombinasi

  • Peran

    Anda harus ditetapkan dengan peran ini:

    • Hak Administrator Global pada penyewa untuk menjalankan skrip
    • Peran Administrator Lokal di komputer tempat Anda menjalankan skrip

  • Konfigurasi PowerShell

    Konfigurasikan lingkungan PowerShell Anda dengan langkah-langkah berikut:

    1. Instal modul Azure Active Directory PowerShell.
    2. Jalankan aplikasi Windows PowerShell dengan hak istimewa yang ditingkatkan. (Jalankan sebagai administrator).
    3. Konfigurasikan PowerShell untuk menjalankan skrip yang ditandatangani.
    4. Unduh skrip Get-AzureADPSPermissions.ps1.

  • Pemicu investigasi

    • Penyusupan akun
    • Pengaturan Persetujuan Aplikasi dimodifikasi pada penyewa
    • Alasan status peristiwa pemberitahuan/audit "aplikasi berisiko" terdeteksi
    • Melihat aplikasi yang tampak aneh

Anda juga dapat mengunduh pemberian persetujuan aplikasi dan daftar periksa playbook insiden lainnya sebagai file Excel.

Langkah investigasi

Anda dapat menggunakan dua metode berikut untuk menyelidiki pemberian persetujuan aplikasi:

  • Portal Azure
  • skrip PowerShell

Catatan

Menggunakan portal Azure hanya memungkinkan Anda melihat Pemberian Persetujuan Admin selama 90 hari terakhir dan berdasarkan hal ini, sebaiknya gunakan metode skrip PowerShell hanya untuk mengurangi penyerang mendaftarkan langkah-langkah investigasi.

Metode 1 - Menggunakan portal Azure

Anda dapat menggunakan pusat admin Microsoft Entra untuk menemukan aplikasi yang telah diberikan izin oleh pengguna individual.

  1. Masuk ke portal Microsoft Azure sebagai administrator.
  2. Pilih ikon ID Microsoft Entra.
  3. Pilih Pengguna.
  4. Pilih pengguna yang ingin Anda tinjau.
  5. Pilih Aplikasi.
  6. Anda dapat melihat daftar aplikasi yang ditetapkan untuk pengguna dan izin apa yang dimiliki aplikasi ini.

Metode 2 - Menggunakan PowerShell

Ada beberapa alat PowerShell yang dapat Anda gunakan untuk menyelidiki pemberian persetujuan terlarang, seperti:

PowerShell adalah alat termampu dan tidak mengharuskan Anda untuk memodifikasi apa pun dalam penyewaan. Kami akan mendasarkan penyelidikan kami pada dokumentasi publik dari serangan Pemberian Persetujuan Terlarang.

Jalankan Get-AzureADPSPermissions.ps1, untuk mengekspor semua pemberian persetujuan OAuth dan aplikasi OAuth untuk semua pengguna dalam penyewaan Anda ke dalam file .csv . Lihat bagian Prasyarat untuk mengunduh dan menjalankan Get-AzureADPSPermissions skrip.

  1. Buka instans PowerShell sebagai administrator dan buka folder tempat Anda menyimpan skrip.

  2. Sambungkan ke direktori Anda menggunakan perintah Connect-AzureAD berikut. Berikut adalah contoh.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  3. Jalankan perintah PowerShell ini.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. Setelah skrip selesai, disarankan untuk memutuskan sesi Microsoft Entra dengan perintah ini.

     Disconnect-AzureAD

    Catatan

    Skrip mungkin memerlukan waktu berjam-jam untuk diselesaikan, tergantung pada ukuran dan izin yang dikonfigurasi serta koneksi Anda.

  5. Skrip membuat file bernama Permissions.csv.

  6. Buka file, lalu filter atau format data ke dalam tabel dan simpan sebagai .xlxs file.

    Header kolom untuk output ditampilkan dalam gambar ini.

    Contoh header kolom

  7. Di kolom ConsentType (G), cari nilai AllPrinciples. Izin AllPrincipals memungkinkan aplikasi klien untuk mengakses konten semua orang dalam penyewaan. Aplikasi Microsoft 365 asli memerlukan izin ini untuk bekerja dengan benar. Setiap aplikasi non-Microsoft dengan izin ini harus ditinjau dengan hati-hati.

  8. Di kolom Izin (F), tinjau izin yang dimiliki setiap aplikasi yang didelegasikan. Cari izin Baca dan Tulis atau *. Semua izin, dan tinjau izin ini dengan hati-hati karena mungkin tidak sesuai. Contoh kolom Izin F

    Catatan

    Tinjau pengguna tertentu yang memiliki persetujuan yang diberikan. Jika pengguna profil tinggi atau berdampak tinggi memiliki persetujuan yang tidak pantas yang diberikan, Anda harus menyelidiki lebih lanjut.

  9. Di kolom ClientDisplayName (C), cari aplikasi yang tampak mencurigakan, seperti:

    • Aplikasi dengan nama yang salah eja Contoh nama yang salah eja

    • Nama yang tidak biasa atau hambar Contoh nama yang tidak biasa

    • Nama yang terdengar seperti peretas. Anda harus meninjau nama-nama ini dengan hati-hati. Contoh nama peretas

Contoh Output: AllPrincipals dan baca tulis semua. Aplikasi mungkin tidak memiliki sesuatu yang mencurigakan seperti nama hambar dan menggunakan grafik MS. Namun, lakukan penelitian dan tentukan tujuan aplikasi dan izin aktual yang dimiliki aplikasi di penyewa, seperti yang ditunjukkan dalam contoh ini.

Contoh aplikasi dengan AllPrincipals ConsentType

Berikut adalah beberapa tips berguna untuk meninjau investigasi kebijakan keamanan informasi (ISP):

  1. ReplyURL/RedirectURL
    • Cari URL mencurigakan
  2. Apakah URL dihosting pada domain yang mencurigakan?
    • Apakah disusupi?
    • Apakah domain baru-baru ini terdaftar?
    • Apakah ini domain sementara?
  3. Apakah ada tautan ketentuan perjanjian layanan/layanan dalam pendaftaran aplikasi?
  4. Apakah kontennya unik dan khusus untuk aplikasi/penerbit?
  5. Apakah penyewa yang mendaftarkan aplikasi baru dibuat atau disusupi (misalnya, apakah aplikasi terdaftar oleh pengguna berisiko)?

Teknik serangan

Meskipun setiap serangan cenderung bervariasi, teknik serangan intinya adalah:

  • Penyerang mendaftarkan aplikasi dengan penyedia OAuth 2.0, seperti ID Microsoft Entra.

  • Aplikasi dikonfigurasi dengan cara yang membuatnya tampak sah. Misalnya, penyerang mungkin menggunakan nama produk populer yang tersedia dalam ekosistem yang sama.

  • Penyerang mendapatkan tautan langsung dari pengguna, yang mungkin dilakukan melalui phishing berbasis email konvensional, dengan membahayakan situs web nonmalicious, atau melalui teknik lain.

  • Pengguna memilih tautan dan ditampilkan permintaan persetujuan autentik yang meminta mereka untuk memberikan izin aplikasi berbahaya ke data.

  • Jika pengguna memilih 'Terima', mereka memberikan izin aplikasi untuk mengakses data sensitif.

  • Aplikasi ini mendapatkan kode otorisasi, yang ditukarkan dengan token akses, dan berpotensi token refresh.

  • Token akses digunakan untuk melakukan panggilan API atas nama pengguna.

  • Jika pengguna menerima, penyerang dapat memperoleh akses ke email pengguna, aturan penerusan, file, kontak, catatan, profil, dan data dan sumber daya sensitif lainnya.

    Contoh permintaan izin

Menemukan tanda-tanda serangan

  1. Di portal Pertahanan Microsoft 365 di https://security.microsoft.com, buka Audit. Atau untuk langsung masuk ke halaman Audit , gunakan https://security.microsoft.com/auditlogsearch.

  2. Pada halaman Audit , cari semua aktivitas dan semua pengguna, masukkan tanggal mulai dan tanggal selesai jika perlu, lalu pilih Cari.

    Contoh pencarian log audit

  3. Pilih Filter hasil dan di bidang Aktivitas , masukkan Persetujuan untuk aplikasi.

    Contoh pemfilteran pencarian log audit

  4. Jika Anda memiliki aktivitas yang disetujui untuk diberikan, lanjutkan ke langkah berikutnya.

  5. Pilih hasil untuk melihat detail aktivitas. Pilih Informasi Selengkapnya untuk mendapatkan detail aktivitas.

  6. Periksa apakah IsAdminContent diatur ke 'True'.

    Catatan

    Proses ini dapat memakan waktu dari 30 menit hingga 24 jam agar entri log audit yang sesuai ditampilkan dalam hasil pencarian setelah peristiwa terjadi.

    Sejauh mana catatan audit dipertahankan dan dapat dicari di log audit bergantung pada langganan Microsoft 365 Anda, dan khususnya jenis lisensi yang ditetapkan untuk pengguna tertentu. Jika nilai ini benar, itu menunjukkan bahwa seseorang mungkin telah memberikan akses luas ke data. Jika ini tidak terduga, ambil langkah-langkah segera untuk mengonfirmasi serangan.

Bagaimana cara mengonfirmasi serangan?

Jika Anda memiliki satu atau beberapa instans IoC yang sebelumnya tercantum, Anda perlu melakukan penyelidikan lebih lanjut untuk mengonfirmasi secara positif bahwa serangan terjadi.

Aplikasi inventarisasi dengan akses di organisasi Anda

Anda dapat menginventarasikan aplikasi untuk pengguna menggunakan pusat admin Microsoft Entra, PowerShell, atau meminta pengguna Anda menghitung akses aplikasi mereka secara individual.

  • Gunakan pusat admin Microsoft Entra untuk menginventarasikan aplikasi dan izinnya. Metode ini menyeluruh, tetapi Anda hanya dapat memeriksa satu pengguna pada satu waktu, yang dapat memakan waktu jika Anda harus memeriksa izin beberapa pengguna.
  • Gunakan PowerShell untuk menginventarkan aplikasi dan izinnya. Metode ini adalah yang tercepat dan paling menyeluruh, dengan jumlah overhead paling sedikit.
  • Dorong pengguna Anda untuk memeriksa aplikasi dan izin mereka secara individual dan melaporkan hasilnya kembali kepada administrator untuk remediasi.

Aplikasi inventori yang ditetapkan untuk pengguna

Anda dapat menggunakan pusat admin Microsoft Entra untuk melihat daftar aplikasi tempat pengguna individual memberikan izin.

  1. Masuk ke Portal Microsoft Azure dengan hak administratif.
  2. Pilih ikon ID Microsoft Entra.
  3. Pilih Pengguna.
  4. Pilih pengguna yang ingin Anda tinjau.
  5. Pilih Aplikasi.

Anda dapat melihat daftar aplikasi yang ditetapkan untuk pengguna dan izin yang diberikan ke aplikasi ini.

Menentukan cakupan serangan

Setelah menyelesaikan inventarasi akses aplikasi, tinjau log audit untuk menentukan cakupan penuh pelanggaran. Cari pada pengguna yang terpengaruh, jangka waktu yang dapat diakses aplikasi terlaris ke organisasi Anda, dan izin yang dimiliki aplikasi. Anda dapat mencari log audit di Keamanan &portal kepatuhan Microsoft Purview Microsoft 365.

Penting: Jika audit tidak diaktifkan sebelum kemungkinan serangan, Anda tidak akan dapat menyelidiki karena data audit tidak tersedia.

Bagaimana cara mencegah serangan dan mengurangi risiko?

Jika organisasi Anda memiliki lisensi yang sesuai:

  • Gunakan lebih banyak fitur audit aplikasi OAuth di aplikasi Microsoft Defender untuk Cloud.
  • Gunakan Buku Kerja Azure Monitor untuk memantau izin dan persetujuan aktivitas terkait. Buku kerja Wawasan Persetujuan memberikan gambaran aplikasi berdasarkan jumlah permintaan persetujuan yang gagal. Ini dapat membantu untuk memprioritaskan aplikasi yang akan ditinjau oleh administrator dan memutuskan apakah akan memberikan persetujuan admin kepada mereka.

Setelah mengidentifikasi aplikasi dengan izin terlaris, segera nonaktifkan aplikasi dengan mengikuti instruksi di Menonaktifkan aplikasi. Kemudian, hubungi Dukungan Microsoft untuk melaporkan aplikasi berbahaya.

Setelah aplikasi dinonaktifkan di Microsoft Entra, aplikasi tidak dapat memperoleh token baru untuk mengakses data, dan pengguna lain tidak dapat masuk atau memberikan persetujuan ke aplikasi.

Catatan

Jika Anda menduga Anda telah menemukan aplikasi berbahaya di organisasi Anda, lebih baik menonaktifkannya daripada menghapusnya. Jika Anda hanya menghapus aplikasi, aplikasi mungkin akan kembali nanti jika pengguna lain memberikan persetujuan. Sebagai gantinya, nonaktifkan aplikasi untuk memastikan aplikasi tidak dapat kembali nanti.

Langkah-langkah untuk melindungi organisasi Anda

Ada berbagai jenis serangan persetujuan, pertahanan yang direkomendasikan ini mengurangi semua jenis serangan, terutama phishing persetujuan, di mana penyerang menipu pengguna untuk memberikan akses aplikasi berbahaya ke data sensitif atau sumber daya lainnya. Alih-alih mencoba mencuri kata sandi pengguna, penyerang mencari izin untuk aplikasi yang dikendalikan penyerang untuk mengakses data berharga.

Untuk membantu mencegah serangan persetujuan memengaruhi ID Microsoft Entra dan Office 365, lihat rekomendasi berikut:

Mengatur kebijakan

  • Pengaturan ini memiliki implikasi pengguna dan mungkin tidak berlaku untuk lingkungan. Jika Anda akan mengizinkan persetujuan apa pun, pastikan administrator menyetujui permintaan.

  • Izinkan persetujuan untuk aplikasi hanya dari penerbit terverifikasi dan jenis izin tertentu yang diklasifikasikan sebagai dampak rendah.

    Catatan

    Rekomendasi di atas disarankan berdasarkan konfigurasi yang paling ideal dan aman. Namun, karena keamanan adalah keseimbangan yang baik antara fungsionalitas dan operasi, konfigurasi yang paling aman dapat menyebabkan lebih banyak overhead kepada administrator. Ini adalah keputusan terbaik yang dibuat setelah berkonsultasi dengan administrator Anda.

    Mengonfigurasi persetujuan peningkatan berbasis risiko - Diaktifkan secara default jika persetujuan pengguna untuk pemberian diaktifkan

  • Persetujuan step-up berbasis risiko membantu mengurangi paparan pengguna terhadap aplikasi berbahaya yang membuat permintaan persetujuan terlarang. Jika Microsoft mendeteksi permintaan persetujuan pengguna akhir yang berisiko, permintaan memerlukan "langkah-up" untuk persetujuan admin sebagai gantinya. Kemampuan ini diaktifkan secara default, tetapi hanya menghasilkan perubahan perilaku saat persetujuan pengguna akhir diaktifkan.

  • Ketika permintaan persetujuan berisiko terdeteksi, permintaan persetujuan menampilkan pesan yang menunjukkan bahwa persetujuan admin diperlukan. Jika alur kerja permintaan persetujuan admin diaktifkan, pengguna dapat mengirim permintaan ke admin untuk ditinjau lebih lanjut langsung dari permintaan persetujuan. Jika diaktifkan, pesan berikut ditampilkan:

    AADSTS90094: <clientAppDisplayName> memerlukan izin untuk mengakses sumber daya di organisasi Anda yang hanya dapat diberikan admin. Minta admin untuk memberikan izin atas aplikasi ini sebelum dapat Anda gunakan. Dalam hal ini, peristiwa audit juga akan dicatat dengan Kategori "ApplicationManagement" Jenis Aktivitas "Persetujuan untuk aplikasi", dan Alasan Status "Aplikasi berisiko terdeteksi".

Catatan

Tugas apa pun yang memerlukan persetujuan administrator memiliki overhead operasional. "Persetujuan dan izin, Pengaturan persetujuan pengguna" saat ini dalam Pratinjau . Setelah siap untuk ketersediaan umum (GA), fitur "Izinkan persetujuan pengguna dari penerbit terverifikasi, untuk izin yang dipilih" harus mengurangi overhead administrator dan disarankan untuk sebagian besar organisasi.

persetujuan

Mendidik pengembang aplikasi Anda untuk mengikuti ekosistem aplikasi tepercaya. Untuk membantu pengembang membangun integrasi berkualitas tinggi dan aman, kami juga mengumumkan pratinjau publik Asisten Integrasi di pendaftaran aplikasi Microsoft Entra.

  • Asisten Integrasi menganalisis pendaftaran aplikasi Anda dan tolok ukurnya terhadap serangkaian praktik terbaik keamanan yang direkomendasikan.
  • Asisten Integrasi menyoroti praktik terbaik yang relevan selama setiap fase siklus hidup integrasi Anda—mulai dari pengembangan hingga pemantauan—dan memastikan setiap tahap dikonfigurasi dengan benar.
  • Ini membuat pekerjaan Anda lebih mudah, apakah Anda mengintegrasikan aplikasi pertama Anda atau Anda ahli yang ingin meningkatkan keterampilan Anda.

Mendidik organisasi Anda tentang taktik persetujuan (taktik pengelabuan, persetujuan admin dan pengguna ):

  • Memeriksa ejaan dan tata bahasa yang buruk. Jika pesan email atau layar persetujuan aplikasi memiliki kesalahan ejaan dan tata bahasa, kemungkinan akan menjadi aplikasi yang mencurigakan.
  • Perhatikan nama aplikasi dan URL domain dengan cermat. Penyerang suka memalsukan nama aplikasi yang membuatnya tampak berasal dari aplikasi atau perusahaan yang sah tetapi mendorong Anda untuk menyetujui aplikasi berbahaya.
  • Pastikan Anda mengenali nama aplikasi dan URL domain sebelum menyetujui aplikasi.

Mempromosikan dan mengizinkan akses ke aplikasi yang Anda percayai

  • Mempromosikan penggunaan aplikasi yang diverifikasi penerbit. Verifikasi penerbit membantu admin dan pengguna akhir memahami keaslian pengembang aplikasi. Lebih dari 660 aplikasi oleh 390 penerbit diverifikasi sejauh ini.
  • Konfigurasikan kebijakan persetujuan aplikasi dengan mengizinkan pengguna hanya menyetujui aplikasi tertentu yang Anda percayai, seperti aplikasi yang dikembangkan oleh organisasi Anda atau dari penerbit terverifikasi.
  • Mendidik organisasi Anda tentang cara kerja izin dan kerangka kerja persetujuan kami.
  • Pahami data dan izin yang diminta aplikasi dan pahami cara kerja izin dan persetujuan dalam platform kami.
  • Memastikan administrator mengetahui cara mengelola dan mengevaluasi permintaan persetujuan.

Mengaudit aplikasi dan izin yang disetujui di organisasi Anda untuk memastikan aplikasi yang digunakan hanya mengakses data yang mereka butuhkan dan mematuhi prinsip-prinsip hak istimewa paling sedikit.

Mitigasi

  • Mendidik pelanggan dan memberikan kesadaran dan pelatihan tentang mengamankan pemberian persetujuan aplikasi
  • Memperketat proses pemberian persetujuan aplikasi dengan kebijakan organisasi dan kontrol teknis
  • Menyiapkan Buat jadwal untuk meninjau aplikasi yang disetujui
  • Anda dapat menggunakan PowerShell untuk menonaktifkan aplikasi yang dicurigai atau berbahaya dengan menonaktifkan aplikasi

Konten terkait

Playbook respons insiden tambahan

Periksa panduan untuk mengidentifikasi dan menyelidiki jenis serangan tambahan ini:

Sumber daya respons insiden