Bagikan melalui

Investigasi aplikasi yang disusupi dan berbahaya

  • Artikel

Artikel ini memberikan panduan tentang mengidentifikasi dan menyelidiki serangan berbahaya pada satu atau beberapa aplikasi di penyewa pelanggan. Instruksi langkah demi langkah membantu Anda mengambil tindakan perbaikan yang diperlukan untuk melindungi informasi dan meminimalkan risiko lebih lanjut.

  • 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.
  • Langkah-langkah investigasi: Menyertakan panduan langkah demi langkah terperinci untuk penyelidikan khusus ini.
  • Langkah-langkah penahanan: Berisi langkah-langkah tentang cara menonaktifkan aplikasi yang disusupi.
  • Langkah-langkah pemulihan: Berisi langkah-langkah tingkat tinggi tentang cara memulihkan/mengurangi dari serangan berbahaya pada aplikasi yang disusupi.
  • Referensi: Berisi materi bacaan dan referensi lainnya.

Prasyarat

Sebelum memulai penyelidikan, pastikan Anda memiliki alat dan izin yang benar untuk mengumpulkan informasi terperinci.

Alat yang diperlukan

Untuk penyelidikan yang efektif, instal modul PowerShell berikut dan toolkit di komputer investigasi Anda:

Alur kerja

Alur terperinci dari langkah-langkah investigasi

Langkah investigasi

Untuk penyelidikan ini, asumsikan bahwa Anda memiliki indikasi untuk potensi kompromi aplikasi dalam bentuk laporan pengguna, contoh log masuk Microsoft Entra, atau deteksi perlindungan identitas. Pastikan untuk menyelesaikan dan mengaktifkan semua langkah prasyarat yang diperlukan.

Playbook ini dibuat dengan niat bahwa tidak semua pelanggan Microsoft dan tim investigasi mereka memiliki rangkaian lisensi Microsoft 365 E5 atau Microsoft Entra ID P2 lengkap yang tersedia atau dikonfigurasi. Playbook ini menyoroti kemampuan otomatisasi lainnya jika sesuai.

Menentukan jenis aplikasi

Penting untuk menentukan jenis aplikasi (multi atau penyewa tunggal) di awal fase investigasi untuk mendapatkan informasi yang benar yang diperlukan untuk menjangkau pemilik aplikasi. Untuk informasi selengkapnya, lihat Penyewaan di MICROSOFT Entra ID.

Aplikasi multi penyewa

Untuk aplikasi multipenyewa, aplikasi dihosting dan dikelola oleh pihak ketiga. Identifikasi proses yang diperlukan untuk menjangkau dan melaporkan masalah kepada pemilik aplikasi.

Aplikasi penyewa tunggal

Temukan detail kontak pemilik aplikasi dalam organisasi Anda. Anda dapat menemukannya di bawah tab Pemilik di bagian Aplikasi Perusahaan. Atau, organisasi Anda mungkin memiliki database yang memiliki informasi ini.

Anda juga dapat menjalankan kueri Microsoft Graph ini:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Periksa Perlindungan Identitas - identitas beban kerja berisiko

Fitur ini dalam pratinjau pada saat menulis playbook ini dan persyaratan lisensi berlaku untuk penggunaannya. Identitas beban kerja berisiko dapat menjadi pemicu untuk menyelidiki Perwakilan Layanan, tetapi juga dapat digunakan untuk menyelidiki lebih lanjut pemicu lain yang telah Anda identifikasi. Anda dapat memeriksa Status Risiko Perwakilan Layanan menggunakan tab Perlindungan Identitas - identitas beban kerja berisiko, atau Anda dapat menggunakan Microsoft Graph API.

Portal Deteksi Risiko

Detail Deteksi Risiko

Sampel API Grafik Deteksi Risiko Perwakilan Layanan

Periksa perilaku masuk yang tidak biasa

Langkah pertama dari penyelidikan adalah mencari bukti pola autentikasi yang tidak biasa dalam penggunaan Perwakilan Layanan. Dalam sistem portal Azure, Azure Monitor, Microsoft Sentinel, atau Security Information and Event Management (SIEM) pilihan organisasi Anda, cari yang berikut ini di bagian Rincian masuk perwakilan layanan:

  • Lokasi - apakah Perwakilan Layanan mengautentikasi dari lokasi\alamat IP yang tidak Anda harapkan?
  • Kegagalan - Apakah ada sejumlah besar kegagalan autentikasi untuk Perwakilan Layanan?
  • Tanda waktu - apakah ada autentikasi yang berhasil yang terjadi kadang-kadang yang tidak Anda harapkan?
  • Frekuensi - apakah ada peningkatan frekuensi autentikasi untuk Perwakilan Layanan?
  • Info Masuk Bocor - apakah ada kredensial aplikasi yang dikodekan secara permanen dan diterbitkan di sumber publik seperti GitHub?

Jika Anda menyebarkan Entra ID Identity Protection - identitas beban kerja berisiko, periksa deteksi Masuk dan Kredensial Kebocoran yang Mencurigakan. Untuk informasi selengkapnya, lihat penahanan risiko identitas beban kerja.

Periksa sumber daya target

Dalam rincian masuk perwakilan layanan, periksa juga Sumber Daya yang diakses Oleh Perwakilan Layanan selama autentikasi. Penting untuk mendapatkan input dari pemilik aplikasi karena mereka terbiasa dengan sumber daya mana yang harus diakses oleh Perwakilan Layanan.

Periksa Sumber Daya untuk Perwakilan Layanan

Periksa perubahan kredensial abnormal

Gunakan log Audit untuk mendapatkan informasi tentang perubahan kredensial pada aplikasi dan perwakilan layanan. Filter untuk Kategori menurut Manajemen Aplikasi, dan Aktivitas menurut Perbarui Aplikasi – Manajemen sertifikat dan rahasia.

  • Periksa apakah ada kredensial yang baru dibuat atau tidak terduga yang ditetapkan ke perwakilan layanan.
  • Periksa kredensial pada Perwakilan Layanan menggunakan Microsoft Graph API.
  • Periksa aplikasi dan objek perwakilan layanan terkait.
  • Periksa peran kustom apa pun yang Anda buat atau ubah. Perhatikan izin yang ditandai di bawah ini:

Periksa peran kustom yang dibuat atau telah dimodifikasi

Jika Anda menyebarkan tata kelola aplikasi di Microsoft Defender untuk Cloud Apps, periksa portal Azure untuk pemberitahuan yang berkaitan dengan aplikasi. Untuk informasi selengkapnya, lihat Mulai menggunakan deteksi dan remediasi ancaman aplikasi.

Jika Anda menyebarkan Perlindungan Identitas, periksa laporan "Deteksi risiko" dan dalam identitas pengguna atau beban kerja "riwayat risiko."

Portal Deteksi Risiko

Jika Anda menyebarkan Microsoft Defender untuk Cloud Apps, pastikan bahwa kebijakan "Penambahan info masuk yang tidak biasa ke aplikasi OAuth" diaktifkan, dan periksa pemberitahuan terbuka.

Untuk informasi selengkapnya, lihat Penambahan info masuk yang tidak biasa ke aplikasi OAuth.

Selain itu, Anda dapat mengkueri api servicePrincipalRiskDetections dan user riskDetections untuk mengambil deteksi risiko ini.

Mencari perubahan konfigurasi aplikasi anomali

  • Periksa izin API yang ditetapkan ke aplikasi untuk memastikan bahwa izin konsisten dengan apa yang diharapkan untuk aplikasi.
  • Periksa Log audit (filter Aktivitas menurut Perbarui Aplikasi atau Perbarui Perwakilan Layanan).
  • Konfirmasikan apakah string koneksi konsisten dan apakah URL keluar telah dimodifikasi.
  • Konfirmasikan apakah domain di URL sejalan dengan domain yang terdaftar.
  • Tentukan apakah ada yang telah menambahkan URL pengalihan yang tidak sah.
  • Konfirmasikan kepemilikan URI pengalihan yang Anda miliki untuk memastikannya tidak kedaluwarsa dan diklaim oleh pesaing.

Selain itu, jika Anda menyebarkan Microsoft Defender untuk Cloud Apps, periksa portal Azure untuk pemberitahuan yang berkaitan dengan aplikasi yang saat ini Anda selidiki. Tidak semua kebijakan pemberitahuan diaktifkan secara default untuk aplikasi OAuth, jadi pastikan bahwa semua kebijakan ini diaktifkan. Untuk informasi selengkapnya, lihat kebijakan aplikasi OAuth. Anda juga dapat melihat informasi tentang prevalensi aplikasi dan aktivitas terbaru di bawah tab Investigasi>Aplikasi OAuth.

Periksa peran aplikasi yang mencurigakan

  • Anda juga dapat menggunakan log Audit. Filter Aktivitas menurut Tambahkan penetapan peran aplikasi ke perwakilan layanan.
  • Konfirmasi apakah peran yang ditetapkan memiliki hak istimewa tinggi.
  • Konfirmasi apakah hak istimewa tersebut diperlukan.

Periksa aplikasi komersial yang belum diverifikasi

  • Periksa apakah aplikasi galeri komersial (versi yang diterbitkan dan diverifikasi) sedang digunakan.

Periksa indikasi pengungkapan informasi properti keyCredential

Tinjau penyewa Anda untuk potensi pengungkapan informasi properti keyCredential seperti yang diuraikan dalam CVE-2021-42306.

Untuk mengidentifikasi dan memulihkan aplikasi Microsoft Entra yang terkena dampak yang terkait dengan akun Run-As Automation yang terkena dampak, buka panduan remediasi GitHub Repo.

Penting

Bukti penyusupan: Jika Anda menemukan bukti penyusupan, maka penting untuk mengambil langkah-langkah yang disorot di bagian penahanan dan pemulihan. Langkah-langkah ini membantu mengatasi risiko, tetapi melakukan penyelidikan lebih lanjut untuk memahami sumber kompromi untuk menghindari dampak lebih lanjut dan memastikan pelaku jahat dihapus.

Ada dua metode utama untuk mendapatkan akses ke sistem melalui penggunaan aplikasi. Yang pertama melibatkan aplikasi yang disetujui oleh administrator atau pengguna, biasanya melalui serangan phishing. Metode ini adalah bagian dari akses awal ke sistem dan sering disebut sebagai "phishing persetujuan".

Metode kedua melibatkan akun administrator yang sudah disusupi yang membuat aplikasi baru untuk tujuan persistensi, pengumpulan data, dan untuk tetap berada di bawah radar. Misalnya, administrator yang disusupi dapat membuat aplikasi OAuth dengan nama yang tampaknya tidak berbahaya, menghindari deteksi dan mengizinkan akses jangka panjang ke data tanpa perlu akun. Metode ini sering terlihat dalam serangan negara negara.

Berikut adalah beberapa langkah yang dapat diambil untuk menyelidiki lebih lanjut.

Periksa Log Audit Terpadu (UAL) Microsoft 365 untuk indikasi pengelabuan selama tujuh hari terakhir

Terkadang, ketika penyerang menggunakan aplikasi berbahaya atau disusupi sebagai sarana persistensi atau untuk menyelundupkan data, kampanye phishing terlibat. Berdasarkan temuan dari langkah-langkah sebelumnya, Anda harus meninjau identitas:

  • Pemilik Aplikasi
  • Admin Persetujuan

Tinjau identitas untuk indikasi serangan phishing dalam 24 jam terakhir. Tingkatkan rentang waktu ini jika diperlukan hingga 7, 14, dan 30 hari jika tidak ada indikasi langsung. Untuk playbook investigasi pengelabuan terperinci, lihat Playbook Investigasi Phishing.

Mencari persetujuan aplikasi berbahaya selama tujuh hari terakhir

Untuk mendapatkan aplikasi yang ditambahkan ke penyewa, penyerang memalsukan pengguna atau admin untuk menyetujui aplikasi. Untuk mengetahui selengkapnya tentang tanda-tanda serangan, lihat Playbook Investigasi Pemberian Persetujuan Aplikasi.

Periksa Log audit

Untuk melihat semua pemberian persetujuan untuk aplikasi tersebut, filter Aktivitas menurut Persetujuan ke aplikasi.

  • Menggunakan Log Audit pusat admin Microsoft Entra

  • Menggunakan Microsoft Graph untuk mengkueri log Audit

    a) Filter untuk jangka waktu tertentu:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Filter Log Audit untuk entri log audit 'Persetujuan untuk Aplikasi':

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Gunakan Analitik Log

AuditLogs
| where ActivityDisplayName == "Consent to application"

Untuk informasi selengkapnya, lihat Playbook Investigasi Pemberian Persetujuan Aplikasi.

Pengguna dapat mengotorisasi aplikasi untuk mengakses beberapa data di sumber daya yang dilindungi, sambil bertindak sebagai pengguna tersebut. Izin yang mengizinkan jenis akses ini disebut "izin yang didelegasikan" atau persetujuan pengguna.

Untuk menemukan aplikasi yang disetujui oleh pengguna, gunakan LogAnalytics untuk mencari log Audit:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

Periksa Log audit untuk menemukan apakah izin yang diberikan terlalu luas (di seluruh penyewa atau disetujui admin)

Meninjau izin yang diberikan ke aplikasi atau Perwakilan Layanan dapat menjadi tugas yang memakan waktu. Mulailah dengan memahami izin yang berpotensi berisiko di ID Microsoft Entra.

Sekarang, ikuti panduan tentang cara menghitung dan meninjau izin dalam penyelidikan pemberian persetujuan aplikasi.

Periksa apakah izin diberikan oleh identitas pengguna yang seharusnya tidak memiliki kemampuan untuk melakukan ini, atau apakah tindakan dilakukan pada tanggal dan waktu aneh

Tinjau menggunakan Log Audit:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Anda juga dapat menggunakan log audit Microsoft Entra, memfilter menurut Persetujuan ke aplikasi. Di bagian Detail Log Audit, klik Properti yang Dimodifikasi, lalu tinjau ConsentAction.Permissions:

Menggunakan log audit Microsoft Entra

Langkah-langkah penahanan

Setelah mengidentifikasi satu atau beberapa aplikasi atau identitas beban kerja sebagai berbahaya atau disusupi, Anda mungkin tidak ingin segera menggulirkan kredensial untuk aplikasi ini, atau Anda ingin segera menghapus aplikasi.

Penting

Sebelum Anda melakukan langkah berikut, organisasi Anda harus menimbang dampak keamanan dan dampak bisnis dari menonaktifkan aplikasi. Jika dampak bisnis dari menonaktifkan aplikasi terlalu besar, maka pertimbangkan untuk mempersiapkan dan pindah ke tahap Pemulihan proses ini.

Menonaktifkan aplikasi yang disusupi

Strategi penahanan umum melibatkan penonaktifan rincian masuk ke aplikasi yang diidentifikasi, untuk memberi tim respons insiden Anda atau waktu unit bisnis yang terpengaruh untuk mengevaluasi dampak penghapusan atau pengguliran kunci. Jika investigasi Anda mengarahkan Anda untuk percaya bahwa kredensial akun administrator juga disusupi, jenis aktivitas ini harus dikoordinasikan dengan peristiwa pengeluaran untuk memastikan bahwa semua rute untuk mengakses penyewa dipotong secara bersamaan.

Alihkan untuk menonaktifkan pengguna untuk masuk

Anda juga dapat menggunakan kode Microsoft Graph PowerShell berikut untuk menonaktifkan masuk ke aplikasi:

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Langkah pemulihan

Memulihkan Perwakilan Layanan

  1. Cantumkan semua kredensial yang ditetapkan ke Perwakilan Layanan Berisiko. Cara terbaik untuk melakukan ini adalah dengan melakukan panggilan Microsoft Graph menggunakan GET ~/application/{id} di mana id yang diteruskan adalah ID objek aplikasi.

    • Uraikan output untuk kredensial. Output mungkin berisi passwordCredentials atau keyCredentials. Rekam keyIds untuk semua.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Tambahkan kredensial sertifikat baru (x509) ke objek aplikasi menggunakan API addKey aplikasi.

    POST ~/applications/{id}/addKey

  3. Segera hapus semua kredensial lama. Untuk setiap kredensial kata sandi lama, hapus dengan menggunakan:

    POST ~/applications/{id}/removePassword

    Untuk setiap kredensial kunci lama, hapus dengan menggunakan:

    POST ~/applications/{id}/removeKey

  4. Remediasi semua Perwakilan Layanan yang terkait dengan aplikasi. Ikuti langkah ini jika penyewa Anda menghosting/mendaftarkan aplikasi multi-penyewa, dan/atau mendaftarkan beberapa perwakilan layanan yang terkait dengan aplikasi. Lakukan langkah serupa dengan apa yang tercantum sebelumnya:

  • GET ~/servicePrincipals/{id}

  • Temukan passwordCredentials dan keyCredentials dalam respons, rekam semua keyId lama

  • Hapus semua kata sandi lama dan kredensial kunci. Gunakan:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Memulihkan sumber daya Perwakilan Layanan yang terpengaruh

Remediasi rahasia KeyVault yang dapat diakses oleh Perwakilan Layanan dengan memutarnya, dalam prioritas berikut:

  • Rahasia langsung terekspos dengan panggilan GetSecret .
  • Rahasia lainnya dalam KeyVault yang terekspos.
  • Rahasia lainnya di seluruh langganan yang diekspos.

Untuk informasi selengkapnya, lihat Menghapus dan menggulirkan sertifikat dan rahasia Perwakilan Layanan atau Aplikasi secara interaktif.

Untuk panduan Microsoft Entra SecOps tentang aplikasi, lihat Panduan operasi keamanan Microsoft Entra untuk Aplikasi.

Dalam urutan prioritas, skenario ini adalah:

  • Perbarui cmdlet PowerShell Graph (Tambahkan/Hapus Dokumen ApplicationKey + ApplicationPassword) untuk menyertakan contoh untuk roll-over kredensial.
  • Tambahkan cmdlet kustom ke Microsoft Graph PowerShell yang menyederhanakan skenario ini.

Menonaktifkan atau menghapus aplikasi berbahaya

Aplikasi dapat dinonaktifkan atau dihapus. Untuk menonaktifkan aplikasi, di bawah Diaktifkan bagi pengguna untuk masuk, pindahkan tombol ke Tidak.

Anda dapat menghapus aplikasi, baik untuk sementara atau permanen, di portal Azure atau melalui Microsoft Graph API. Saat Anda menghapus sementara, aplikasi dapat dipulihkan hingga 30 hari setelah penghapusan.

DELETE /applications/{id}

Untuk menghapus aplikasi secara permanen, gunakan panggilan Microsoft Graph API ini:

DELETE /directory/deletedItems/{id}

Jika Anda menonaktifkan atau jika Anda menghapus sementara aplikasi, siapkan pemantauan di log audit Microsoft Entra untuk mempelajari apakah status berubah kembali ke diaktifkan atau dipulihkan.

Pengelogan untuk diaktifkan:

  • Layanan - Direktori Inti
  • Jenis Aktivitas - Perbarui Perwakilan Layanan
  • Kategori - Manajemen Aplikasi
  • Diinisiasi oleh (aktor) - UPN aktor
  • Target - ID Aplikasi dan Nama Tampilan
  • Properti yang Dimodifikasi - Nama Properti = akun diaktifkan, nilai baru = true

Pengelogan untuk dipulihkan:

  • Layanan - Direktori Inti
  • Jenis Aktivitas - Tambahkan Perwakilan Layanan
  • Kategori - Manajemen Aplikasi
  • Diinisiasi oleh (aktor) - UPN aktor
  • Target - ID Aplikasi dan Nama Tampilan
  • Properti yang Dimodifikasi - Nama properti = akun diaktifkan, nilai baru = true

Catatan: Microsoft secara global menonaktifkan aplikasi yang ditemukan melanggar Ketentuan Layanannya. Dalam kasus tersebut, aplikasi ini ditampilkan DisabledDueToViolationOfServicesAgreement pada disabledByMicrosoftStatus properti pada jenis sumber daya aplikasi dan perwakilan layanan terkait di Microsoft Graph. Untuk mencegahnya diinstansiasi di organisasi Anda lagi di masa mendatang, Anda tidak dapat menghapus objek ini.

Menerapkan Perlindungan Identitas untuk identitas beban kerja

Microsoft mendeteksi risiko pada identitas beban kerja di seluruh perilaku masuk dan indikator kompromi offline.

Untuk informasi selengkapnya, lihat Mengamankan identitas beban kerja dengan Perlindungan Identitas.

Pemberitahuan ini muncul di portal Perlindungan Identitas dan dapat diekspor ke alat SIEM melalui Pengaturan Diagnostik atau API Perlindungan Identitas.

Meninjau risiko dan pemberitahuan di portal Perlindungan Identitas

Akses Bersyarah untuk identitas beban kerja berisiko

Akses Bersyarkat memungkinkan Anda memblokir akses untuk akun tertentu yang Anda tetapkan saat Perlindungan Identitas menandainya sebagai "berisiko." Perhatikan bahwa pemberlakuan melalui Akses Bersyar saat ini hanya terbatas pada aplikasi penyewa tunggal.

Mengontrol akses pengguna berdasarkan kebijakan akses bersyarah

Untuk informasi selengkapnya, lihat Akses Bersyarah untuk identitas beban kerja.

Menerapkan kebijakan risiko aplikasi

Tinjau pengaturan persetujuan pengguna di bawah Persetujuan aplikasi>Microsoft Entra ID>Enterprise dan izin>Pengaturan persetujuan pengguna.

Pilih Izinkan persetujuan pengguna untuk aplikasi dari opsi

Untuk meninjau opsi konfigurasi, lihat Mengonfigurasi bagaimana pengguna menyetujui aplikasi.

Ketika pengembang aplikasi mengarahkan pengguna ke titik akhir persetujuan admin dengan niat untuk memberikan persetujuan untuk seluruh penyewa, itu dikenal sebagai alur persetujuan admin. Untuk memastikan alur persetujuan admin berfungsi dengan baik, pengembang aplikasi harus mencantumkan semua izin di properti RequiredResourceAccess dalam manifes aplikasi.

Sebagian besar organisasi menonaktifkan kemampuan pengguna mereka untuk menyetujui aplikasi. Untuk memberi pengguna kemampuan untuk tetap meminta persetujuan untuk aplikasi dan memiliki kemampuan peninjauan administratif, disarankan untuk menerapkan alur kerja persetujuan admin. Ikuti langkah-langkah alur kerja persetujuan admin untuk mengonfigurasinya di penyewa Anda.

Untuk operasi istimewa tinggi seperti persetujuan admin, memiliki strategi akses istimewa yang ditentukan dalam panduan kami.

Persetujuan peningkatan berbasis risiko membantu mengurangi paparan pengguna terhadap aplikasi berbahaya. Misalnya, permintaan persetujuan untuk aplikasi multipenyewa yang baru terdaftar yang tidak diverifikasi penerbit dan memerlukan izin non-dasar dianggap berisiko. Jika permintaan izin pengguna yang berisiko terdeteksi, permintaan tersebut memerlukan "peningkatan" untuk izin admin. Kemampuan peningkatan ini diaktifkan secara default, tetapi akan menghasilkan perubahan perilaku hanya jika izin pengguna diaktifkan.

Pastikan diaktifkan di penyewa Anda dan tinjau pengaturan konfigurasi yang diuraikan di sini.

Referensi

Playbook respons insiden tambahan

Periksa panduan untuk mengidentifikasi dan menyelidiki jenis serangan tambahan ini:

Sumber daya respons insiden