Investigasi aplikasi yang disusupi dan berbahaya

  • Artikel
  • 15 menit untuk membaca

Artikel ini menyediakan panduan tentang mengidentifikasi dan menyelidiki serangan berbahaya pada satu atau beberapa aplikasi di penyewa pelanggan. Instruksi langkah demi langkah akan 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: Memperlihatkan 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 tambahan.

Prasyarat

Sebelum memulai penyelidikan, pastikan Anda memiliki alat dan izin yang benar untuk mengumpulkan informasi terperinci tentang aplikasi yang Anda duga disusupi oleh serangan berbahaya.

Alat yang diperlukan

Untuk penyelidikan yang efektif, instal modul PowerShell berikut dan toolkit pada mesin investigasi Anda:

Alur kerja

Detailed flow of the investigation steps

Langkah investigasi

Untuk penyelidikan ini, diasumsikan bahwa Anda memiliki indikasi untuk potensi penyusupan aplikasi dalam bentuk laporan pengguna, contoh log masuk Azure Active Directory, 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 akan memiliki rangkaian lisensi Microsoft 365 E5 atau Azure AD Premium P2 lengkap yang tersedia atau dikonfigurasi di penyewa yang sedang diselidiki. Namun, kami akan menyoroti kemampuan otomatisasi tambahan 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 Azure Active Directory.

Aplikasi multi-penyewa

Untuk aplikasi multi-penyewa, 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 akan 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 mungkin 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.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Memeriksa perilaku masuk yang tidak biasa

Langkah pertama dari penyelidikan adalah mencari bukti pola autentikasi yang tidak biasa dalam penggunaan Perwakilan Layanan. Dalam portal Microsoft Azure, Azure Monitor, Azure Sentinel, atau sistem 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?
  • Kredensial Kebocoran - apakah ada kredensial aplikasi yang dikodekan secara permanen dan diterbitkan pada sumber publik seperti GitHub?

Jika Anda telah menyebarkan Perlindungan Identitas - 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 memiliki input dari pemilik aplikasi karena mereka akan terbiasa dengan sumber daya mana yang harus diakses oleh Perwakilan Layanan.

Check the Resource for Service Principal

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 – Sertifikat dan manajemen 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 mungkin telah dibuat atau dimodifikasi. Perhatikan izin yang ditandai di bawah ini:

Check custom roles that may be created or modified

Jika Anda telah menyebarkan add-on tata kelola aplikasi, periksa portal Microsoft Azure untuk pemberitahuan yang berkaitan dengan aplikasi. Untuk informasi selengkapnya, lihat Mulai menggunakan deteksi dan remediasi ancaman aplikasi.

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

Risk Detection portal

Jika Anda telah menyebarkan Aplikasi Pertahanan Microsoft untuk Cloud, 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 servicePrincipalRiskDetections dan API riskDetections pengguna 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).
  • Konfirmasi 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 penyandera.

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

Periksa peran aplikasi yang mencurigakan

  • Ini juga dapat diselidiki 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 Azure ACTIVE Directory yang terkena dampak yang terkait dengan akun Run-As Automation yang terkena dampak, navigasikan ke panduan remediasi Github Repo.

Penting

Bukti penyusupan: Jika Anda menemukan bukti penyusupan, penting untuk mengambil langkah-langkah yang disorot di bagian penahanan dan pemulihan. Ini akan membantu mengatasi risiko, tetapi akan memerlukan 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. Ini akan menjadi 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, aplikasi OAuth dapat dibuat oleh administrator yang disusupi dengan nama yang tampaknya tidak berbahaya, menghindari deteksi dan memungkinkan akses jangka panjang ke data tanpa memerlukan akun. Ini sering terlihat dalam serangan negara negara.

Di bawah ini adalah beberapa langkah yang dapat diambil untuk menyelidiki lebih lanjut.

Periksa Log Audit Terpadu M365 (UAL) untuk indikasi pengelabuan selama 7 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 7 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 untuk aplikasi.

  • Menggunakan Log Audit Portal Microsoft Azure AD

  • 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 telah 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 (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 Azure ACTIVE Directory .

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 yang 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 Azure ACTIVE Directory, memfilter menurut Persetujuan untuk aplikasi. Di bagian Detail Log Audit, klik Properti yang Dimodifikasi, lalu tinjau ConsentAction.Permissions:

Use the Azure AD Audit Logs

Langkah-langkah penahanan

Setelah Anda mengidentifikasi satu atau beberapa aplikasi atau identitas beban kerja sebagai berbahaya atau disusupi, Anda mungkin tidak ingin segera menggulung kredensial untuk aplikasi ini, atau Anda ingin segera menghapus aplikasi. Sangat disarankan, agar Anda mengikuti panduan praktik terbaik untuk respons insiden.

Penting

Sebelum Anda melakukan langkah berikut, organisasi Anda harus menimbang dampak keamanan dan dampak bisnis dari menonaktifkan aplikasi. Jika dampak bisnis 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 bergulirnya kunci. Jika investigasi Anda mengarahkan Anda untuk percaya bahwa kredensial akun administrator juga telah disusupi, jenis aktivitas ini harus dikoordinasikan dengan peristiwa pengeluaran untuk memastikan bahwa semua rute untuk mengakses penyewa dipotong secara bersamaan.

Toggle to disable users to sign-in

Anda juga dapat menggunakan kode 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-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
   # Service principal exists already, disable it
   Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   $servicePrincipal = New-AzureADServicePrincipal -AppId $appId -AccountEnabled $false
}

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 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 di atas:

  • 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 diekspos.
  • 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 Azure AD SecOps tentang aplikasi, lihat Panduan operasi keamanan Azure Active Directory untuk Aplikasi.

Dalam urutan prioritas, skenario ini adalah:

  • Perbarui cmdlet PowerShell Graph (Dokumen Tambahkan/Hapus ApplicationKey + ApplicationPassword) untuk menyertakan contoh 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 Microsoft 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 Azure AD untuk mempelajari apakah status berubah kembali ke diaktifkan atau dipulihkan.

Pengelogan untuk diaktifkan:

  • Layanan - Direktori Inti
  • Jenis Aktivitas - Perbarui Prinsip Layanan
  • Kategori - Manajemen Aplikasi
  • Diprakarsai 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 Prinsip Layanan
  • Kategori - Manajemen Aplikasi
  • Diprakarsai oleh (aktor) - UPN aktor
  • Target - ID Aplikasi dan Nama Tampilan
  • Properti yang Dimodifikasi - Nama properti = akun diaktifkan, nilai baru = true

Menerapkan Perlindungan Identitas untuk identitas beban kerja

Rincian masuk yang mencurigakan: Ketika deteksi risiko menunjukkan properti atau pola masuk yang tidak biasa, serta penambahan info masuk yang tidak biasa ke Aplikasi OAuth, itu mungkin merupakan indikator penyusupan. Garis besar deteksi membuat garis besar perilaku masuk antara 2 dan 60 hari, dan diaktifkan jika satu atau beberapa properti yang tidak dikenal berikut terjadi selama masuk berikutnya:

  • Alamat IP/ASN
  • Sumber daya target
  • Agen pengguna
  • Perubahan IP hosting/non-hosting
  • Negara IP
  • Jenis Informasi masuk

Ketika deteksi ini diaktifkan, akun ditandai sebagai risiko tinggi karena ini dapat menunjukkan pengambarapan akun untuk aplikasi subjek. Perhatikan bahwa perubahan yang sah pada konfigurasi aplikasi terkadang akan memicu deteksi ini.

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 API Perlindungan Identitas.

Review risks and alerts in the Identity Protection portal

Akses Bersyar untuk identitas beban kerja yang berisiko

Akses Bersyar 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.

Control user access based on conditional access policy

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

Menerapkan kebijakan risiko aplikasi

Tinjau pengaturan persetujuan pengguna di bawah Persetujuanaplikasi>Azure Active Directory> Enterprisedan izin>Pengaturan persetujuan pengguna.

Select Allow user consent for apps from the options

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, Anda memiliki strategi akses istimewa yang didefinisikan sesuai panduan kami.

Persetujuan peningkatan berbasis risiko membantu mengurangi paparan pengguna terhadap aplikasi berbahaya. Misalnya, permintaan persetujuan untuk aplikasi multi-penyewa 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