Akses Bersyarat: Sumber daya target

Ikhtisar

Sumber daya target (sebelumnya aplikasi cloud, tindakan, dan konteks autentikasi) adalah sinyal utama dalam kebijakan Akses Bersyarat. Kebijakan Akses Bersyarat memungkinkan admin menetapkan kontrol ke aplikasi, layanan, tindakan, atau konteks autentikasi tertentu.

• Admin dapat memilih dari daftar aplikasi atau layanan yang mencakup aplikasi Microsoft bawaan dan aplikasi terintegrasi Microsoft Entra, termasuk galeri, non-galeri, dan aplikasi yang diterbitkan melalui Proksi Aplikasi.
• Admin dapat menentukan kebijakan berdasarkan tindakan pengguna seperti Mendaftarkan informasi keamanan atau Mendaftarkan atau menggabungkan perangkat, memungkinkan Akses Bersyarat menerapkan kontrol di sekitar tindakan tersebut.
• Admin dapat menargetkan profil penerusan lalu lintas dari Akses Aman Global untuk fungsionalitas yang ditingkatkan.
• Admin dapat menggunakan konteks autentikasi untuk memberikan lapisan keamanan tambahan dalam aplikasi.

Microsoft aplikasi cloud

Admin dapat menugaskan kebijakan Akses Kondisional pada aplikasi cloud Microsoft jika prinsipal layanan muncul di penyewa mereka, kecuali untuk Microsoft Graph. Microsoft Graph berfungsi sebagai sumber daya payung. Gunakan Pelaporan Audiens untuk melihat layanan yang mendasar dan menargetkan layanan tersebut dalam kebijakan Anda. Beberapa aplikasi seperti Microsoft 365/Office 365 dan Windows Azure Service Management API menyertakan beberapa aplikasi atau layanan anak terkait. Ketika aplikasi cloud Microsoft baru dibuat, aplikasi tersebut muncul di daftar pilihan aplikasi segera setelah prinsipal layanan dibuat di tenant.

Office 365

Microsoft 365 menawarkan layanan produktivitas dan kolaborasi berbasis cloud seperti Exchange, SharePoint, dan Microsoft Teams. Di Akses Bersyarah, rangkaian aplikasi Microsoft 365 muncul di bawah 'Office 365'. Microsoft 365 layanan cloud terintegrasi secara mendalam untuk memastikan pengalaman yang lancar dan kolaboratif. Integrasi ini dapat menyebabkan kebingungan saat membuat kebijakan karena beberapa aplikasi, seperti Microsoft Teams, bergantung pada yang lain, seperti SharePoint atau Exchange.

Pengelompokan aplikasi Office 365 dalam Akses Kondisional memungkinkan penargetan semua layanan ini sekaligus. Gunakan pengelompokan Microsoft 365, alih-alih menargetkan aplikasi cloud individual, untuk menghindari masalah dengan dependensi layanan.

Menargetkan grup aplikasi ini membantu menghindari masalah yang mungkin muncul karena kebijakan dan dependensi yang tidak konsisten. Misalnya: Aplikasi Exchange Online terkait dengan data Exchange Online tradisional seperti email, kalender, dan informasi kontak. Metadata terkait mungkin diekspos melalui sumber daya yang berbeda seperti pencarian. Untuk memastikan bahwa semua metadata dilindungi seperti yang dimaksudkan, admin harus menetapkan kebijakan ke aplikasi Microsoft 365.

Administrator dapat mengecualikan seluruh rangkaian Microsoft 365 atau aplikasi cloud Microsoft 365 tertentu dari kebijakan Akses Bersyarat.

Untuk daftar lengkap semua layanan yang disertakan, lihat Apps yang disertakan dalam suite aplikasi Microsoft 365 Akses Bersyarat.

API Manajemen Layanan Windows Azure

Saat Anda menargetkan aplikasi API Manajemen Layanan Windows Azure, kebijakan diberlakukan untuk token yang dikeluarkan ke serangkaian layanan yang terikat erat ke portal. Pengelompokan ini mencakup ID aplikasi dari:

• Azure Resource Manager
• Azure portal, yang juga mencakup pusat admin Microsoft Entra dan Microsoft Engage Center
• Azure Data Lake
• Application Insights API
• API Log Analytics

Karena kebijakan diterapkan ke portal manajemen Azure dan API, layanan atau klien apa pun yang bergantung pada API Azure dapat terpengaruh secara tidak langsung. Contohnya:

• Azure CLI
• portal Azure Data Factory
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• Model penyebaran klasik API
• pusat admin Microsoft 365
• Microsoft IoT Central
• manajemen multipenyewa Microsoft Defender
• SQL Managed Instance
• portal administrator langganan Visual Studio

Perhatian

Kebijakan Akses Bersyarat yang terkait dengan Windows Azure Service Management API tidak lagi mencakup Azure DevOps.

Note

Aplikasi WINDOWS AZURE Service Management API berlaku untuk Azure PowerShell, yang memanggil API Azure Resource Manager. Ini tidak berlaku untuk Microsoft Graph PowerShell, yang memanggil API Microsoft Graph.

Untuk Azure Government, Anda harus menargetkan aplikasi AZURE GOVERNMENT Cloud Management API.

Portal Admin Microsoft

Saat kebijakan Akses Bersyarat menargetkan aplikasi cloud Portal Admin Microsoft, kebijakan diberlakukan untuk token yang dikeluarkan untuk ID aplikasi sumber daya dasar yang spesifik yang terkait dengan portal admin Microsoft. Pengelompokan aplikasi tidak menyertakan layanan backend yang mungkin dipanggil atau diandalkan oleh portal tersebut. Untuk mengidentifikasi dependensi layanan portal admin, gunakan pelaporan audiens Akses Bersyarat dalam log masuk.

Aplikasi berikut terdiri dari Portal Admin Microsoft:

• ID aplikasi Pusat Admin Exchange: 497effe9-df71-4043-a8bb-14cf78c4b63b
• ID aplikasi portal Azure: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• ID aplikasi Microsoft Office 365 Portal: 00000006-0000-0ff1-ce00-0000000000000
• ID aplikasi pusat keamanan dan kepatuhan (Pusat Perlindungan) Microsoft 365: 80ccca67-54bd-44ab-8625-4b79c4dc7775

Pengelompokan Portal Admin terutama ditujukan untuk menyertakan skenario, untuk cara yang disederhanakan untuk menargetkan satu atau beberapa portal admin dengan kebijakan Akses Bersyariah (misalnya, memberlakukan MFA). Pengelompokan ini digunakan dalam kebijakan yang dikelola Microsoft untuk MFA admin, guna menyederhanakan pembuatan kebijakan.

Opsi ini tidak dimaksudkan untuk berfungsi sebagai mekanisme pengecualian massal untuk semua layanan backend yang terkait dengan ID aplikasi yang mendasar.

Note

Kebijakan blokir yang menargetkan Portal Admin Microsoft akan memblokir pengguna akhir mengakses halaman Microsoft 365 penginstalan mandiri, karena halaman ini saat ini terletak di pusat admin Microsoft 365. Untuk informasi tentang opsi penyebaran alternatif, lihat Merencanakan penyebaran perusahaan Aplikasi Microsoft 365 Anda.

Aplikasi lain

Administrator dapat menambahkan aplikasi terdaftar Microsoft Entra apa pun ke kebijakan Akses Bersyarat. Aplikasi ini bisa meliputi:

• Aplikasi yang diterbitkan melalui proksi aplikasi Microsoft Entra
• Aplikasi ditambahkan dari galeri
• Aplikasi kustom tidak ada di galeri
• Aplikasi warisan yang diterbitkan melalui pengontrol dan jaringan pengiriman aplikasi
• Aplikasi yang menggunakan akses menyeluruh berbasis kata sandi

Note

Karena kebijakan Akses Bersyar menetapkan persyaratan untuk mengakses layanan, Anda tidak dapat menerapkannya ke aplikasi klien (publik/asli). Dengan kata lain, kebijakan tidak diatur langsung pada aplikasi klien (publik/asli), tetapi diterapkan saat klien memanggil layanan. Misalnya, kebijakan yang ditetapkan pada layanan SharePoint berlaku untuk semua klien yang memanggil SharePoint. Kebijakan yang ditetapkan pada Exchange berlaku untuk upaya mengakses email menggunakan klien Outlook. Itulah sebabnya aplikasi klien (publik/asli) tidak tersedia untuk dipilih di pemilih aplikasi dan opsi Akses Bersyarah tidak tersedia di pengaturan aplikasi untuk aplikasi klien (publik/asli) yang terdaftar di penyewa Anda.

Beberapa aplikasi tidak muncul di menu pilihan sama sekali. Satu-satunya cara untuk menyertakan aplikasi ini dalam kebijakan Akses Bersyarat adalah dengan menyertakan Semua sumber daya (sebelumnya 'Semua aplikasi cloud') atau menambahkan perwakilan layanan yang hilang menggunakan cmdlet PowerShell New-MgServicePrincipal atau menggunakan Microsoft Graph API.

Akses Bersyarat untuk tipe klien yang berbeda

Akses Bersyarah berlaku untuk sumber daya bukan klien, kecuali ketika klien adalah klien rahasia yang meminta token ID.

• Klien publik
  • Klien publik adalah klien yang berjalan secara lokal di perangkat seperti Microsoft Outlook di desktop atau aplikasi seluler seperti Microsoft Teams.
  • Kebijakan Akses Bersyarkat tidak berlaku untuk klien publik itu sendiri tetapi didasarkan pada sumber daya yang mereka minta.
• Klien rahasia
  • Akses Bersyarat berlaku untuk sumber daya yang diminta oleh klien dan klien rahasia itu sendiri jika meminta token ID.
  • Misalnya: Jika Outlook Web meminta token untuk cakupan Mail.Read dan Files.Read, Akses Bersyarkat menerapkan kebijakan untuk Exchange dan SharePoint. Selain itu, jika Outlook Web meminta token ID, Conditional Access juga menerapkan kebijakan untuk Outlook Web.

Untuk melihat log sign-in untuk jenis klien ini dari pusat admin Microsoft Entra:

1. Masuk ke pusat admin Microsoft Entra setidaknya sebagai Pembaca Laporan.
2. Telusuri ke Entra IDPemantauan & kesehatanLog masuk.
3. Tambahkan filter untuk jenis kredensial Klien .
4. Sesuaikan filter untuk melihat log tertentu berdasarkan kredensial klien yang digunakan dalam masuk.

Untuk informasi selengkapnya, lihat artikel Klien publik dan aplikasi klien rahasia.

Akses Bersyarat untuk SEMUA sumber daya

Menerapkan kebijakan Akses Bersyarat ke Semua sumber daya (sebelumnya 'Semua aplikasi cloud') tanpa pengecualian sumber daya memberlakukan kebijakan untuk semua permintaan token dari situs web dan layanan, termasuk profil penerusan lalu lintas Akses Aman Global. Opsi ini mencakup aplikasi yang tidak dapat ditargetkan secara individual dalam kebijakan Akses Bersyarat, seperti Windows Azure Active Directory (00000002-0000-0000-c000-000000000000).

Important

Microsoft merekomendasikan pembuatan kebijakan autentikasi multifaktor garis besar yang menargetkan semua pengguna dan semua sumber daya (tanpa pengecualian sumber daya), seperti yang dijelaskan dalam Penyediaan autentikasi multifaktor untuk semua pengguna.

Perilaku Akses Kondisional Warisan saat kebijakan SEMUA SUMBER DAYA memiliki pengecualian pada sumber daya

Warning

Akses Kondisional yang berikut ini akan mengalami perubahan. Cakupan istimewa rendah yang sebelumnya dikecualikan dari penegakan kebijakan tidak akan lagi dikecualikan. Perubahan ini berarti bahwa pengguna yang sebelumnya dapat mengakses aplikasi tanpa penerapan Akses Bersyarat sekarang mungkin mengalami kendala Akses Bersyarat. Perubahan ini diluncurkan dalam fase mulai Maret 2026.

Jika ada aplikasi yang dikecualikan dari kebijakan, untuk menghindari pemblokiran akses pengguna secara tidak sengaja, cakupan hak istimewa rendah tertentu sebelumnya dikecualikan dari penegakan kebijakan. Cakupan ini memungkinkan panggilan ke API Grafik yang mendasar, seperti (00000002-0000-0000-c000-0000000000000) dan < (00000003-0000-0000-c000-0000000000000), untuk mengakses profil pengguna dan informasi keanggotaan grup yang umum digunakan oleh aplikasi sebagai bagian dari autentikasi. Misalnya: ketika Outlook meminta token untuk Exchange, itu juga meminta cakupan User.Read untuk dapat menampilkan informasi akun dasar pengguna saat ini.

Sebagian besar aplikasi memiliki dependensi serupa, itulah sebabnya cakupan hak istimewa rendah ini secara otomatis dikecualikan dalam Semua kebijakan sumber daya . Cakupan yang dikecualikan sebelumnya tercantum sebagai berikut, persetujuan masih diperlukan bagi aplikasi untuk menggunakan izin ini.

• Klien asli dan aplikasi halaman tunggal (SPAs) memiliki akses ke cakupan hak istimewa rendah berikut:
  • Azure AD Graph: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
• Klien rahasia memiliki akses ke cakupan hak istimewa rendah berikut, jika dikecualikan dari kebijakan Semua sumber daya :
  • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.All,User.ReadBasic.All
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

Perilaku baru Akses Bersyarat ketika kebijakan SEMUA SUMBER DAYA memiliki pengecualian sumber daya

Cakupan yang tercantum di bagian sebelumnya sekarang dievaluasi sebagai akses direktori dan dipetakan ke Azure Ad Graph (sumber daya: Windows Azure Active Directory, ID: 00000002-0000-0000-c000-0000000000000) untuk tujuan evaluasi Akses Bersyarkat.

Kebijakan Akses Bersyarat yang menargetkan Semua sumber daya dengan satu atau beberapa pengecualian sumber daya, atau kebijakan yang secara eksplisit menargetkan Azure Ad Graph, diberlakukan dalam alur masuk pengguna di mana aplikasi klien hanya meminta cakupan ini. Tidak ada perubahan perilaku ketika aplikasi meminta cakupan tambahan apa pun di luar yang tercantum di atas.

Untuk panduan tentang menilai dampak, mengidentifikasi aplikasi yang terpengaruh, dan mempertahankan perilaku warisan, lihat Peningkatan penerapan untuk kebijakan dengan pengecualian sumber daya.

Note

Penghentian Azure AD Graph tidak berdampak pada sumber daya Azure AD Graph (Windows Azure Active Directory) yang terdaftar di tenant Anda.

Pengalaman pengguna

Dalam alur masuk pengguna di mana aplikasi klien hanya meminta cakupan yang tercantum di atas, pengguna sekarang mungkin menerima tantangan Akses Bersyarat (seperti MFA atau kepatuhan perangkat). Tantangan yang tepat tergantung pada kontrol akses yang dikonfigurasi dalam kebijakan Anda yang menargetkan Semua sumber daya (dengan atau tanpa pengecualian sumber daya) atau kebijakan yang secara eksplisit menargetkan Azure Ad Graph.

Dalam contoh berikut, penyewa memiliki kebijakan Akses Bersyarat dengan detail berikut:

• Menargetkan Semua pengguna dan Semua sumber daya
• Pengecualian sumber daya untuk aplikasi klien rahasia dan Exchange Online
• MFA dikonfigurasi sebagai kontrol pemberian

Contoh skenario

Contoh skenario	Dampak pengguna (sebelum → setelah)	Evaluasi Akses Bersyarat
Pengguna masuk ke klien desktop Visual Studio Code, yang meminta ruang lingkup openid dan profil.	Sebelum: Pengguna tidak diminta untuk MFA Setelah: Pengguna diminta untuk MFA	Akses Bersyarat sekarang dievaluasi menggunakan Windows Azure Active Directory sebagai audiens penegak.
Pengguna masuk menggunakan Azure CLI, yang hanya meminta User.Read.	Sebelum: Pengguna tidak diminta untuk MFA Setelah: Pengguna diminta untuk MFA	Akses Bersyarat sekarang dievaluasi menggunakan Windows Azure Active Directory sebagai audiens penegak.
Pengguna masuk melalui aplikasi klien rahasia (dikecualikan dari kebijakan) yang meminta hanya User.Read dan People.Read.	Sebelum: Pengguna tidak diminta untuk MFA Setelah: Pengguna diminta untuk MFA	Akses Bersyarat sekarang dievaluasi menggunakan Windows Azure Active Directory sebagai audiens penegak.

Tidak ada perubahan perilaku ketika aplikasi klien meminta cakupan di luar cakupan yang tercantum sebelumnya, seperti yang diilustrasikan dalam contoh berikut.

Contoh skenario

Contoh skenario	Dampak pada pengguna	Evaluasi Akses Bersyarat
Pengguna masuk ke aplikasi klien rahasia (dikecualikan dari kebijakan) yang meminta akses offline_access dan SharePoint (Files.Read).	Tidak ada perubahan perilaku	Akses Bersyarat terus diberlakukan dengan mengacu pada sumber daya SharePoint.
Pengguna masuk ke klien sinkronisasi desktop OneDrive. OneDrive meminta akses offline_access dan Exchange Online (Mail.Read).	Tidak ada perubahan perilaku	Akses Bersyarkat tidak diberlakukan karena Exchange Online dikecualikan dari kebijakan.

Sebagian besar aplikasi meminta cakupan tambahan dari yang telah tercantum sebelumnya dan sudah dikenakan penegakan Akses Bersyarat, kecuali aplikasi secara eksplisit dikecualikan dari kebijakan. Dalam kasus seperti itu, tidak ada perubahan perilaku.

Aplikasi kustom yang sengaja dirancang untuk meminta hanya cakupan yang tercantum sebelumnya dan tidak dirancang untuk menangani tantangan Akses Bersyarat mungkin perlu diperbarui agar dapat menangani tantangan Akses Bersyarat. Rujuk panduan pengembang Microsoft Conditional Access untuk detail implementasi.

Cara mengidentifikasi aplikasi yang terpengaruh oleh perubahan penegakan cakupan hak istimewa rendah

Aplikasi dapat dipra-otorisasi untuk meminta hanya satu atau beberapa cakupan yang tercantum sebelumnya. Gunakan opsi berikut untuk mengidentifikasi aplikasi yang terpengaruh.

PowerShell

Gunakan skrip PowerShell berikut untuk mencantumkan semua aplikasi di penyewa Anda yang telah diotorisasi sebelumnya untuk meminta hanya satu atau beberapa cakupan yang terpengaruh oleh perubahan ini.

Note

Aplikasi dapat meminta cakupan tambahan secara dinamis (dengan persetujuan admin). Skrip ini tidak akan mengidentifikasi aplikasi tersebut.

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://graph.microsoft.com/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

Laporan Penggunaan dan Wawasan

Laporan Penggunaan dan Wawasan di Microsoft Entra dapat membantu memantau aktivitas masuk aplikasi untuk aplikasi tertentu.

1. Masuk ke pusat admin Microsoft Entra setidaknya sebagai Pembaca Laporan.
2. Telusuri ke Entra IDMonitoring & kesehatanPenggunaan & wawasan.
3. Pilih aplikasi > pilih Penggunaan & wawasan.

Catatan masuk

Microsoft Entra ID log masuk juga dapat memberikan daftar rincian masuk terperinci untuk aplikasi tertentu.

1. Masuk ke pusat admin Microsoft Entra setidaknya sebagai Pembaca Laporan.
2. Telusuri ke Entra IDPemantauan & kesehatanLog masuk.
3. Atur filter Aplikasi dan masukkan nama aplikasi atau ID aplikasi sebagai nilai .

Lindungi informasi direktori

Note

Bagian berikut berlaku hingga peluncuran perubahan penegakan ruang lingkup hak istimewa rendah selesai.

Jika kebijakan MFA dasar yang direkomendasikan tanpa pengecualian sumber daya tidak dapat dikonfigurasi karena alasan bisnis, dan kebijakan keamanan organisasi Anda harus menyertakan cakupan hak istimewa rendah terkait direktori (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), buat kebijakan Akses Bersyarat terpisah yang menargetkan Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (juga disebut Azure AD Graph) adalah sumber daya yang mewakili data yang disimpan dalam direktori seperti pengguna, grup, dan aplikasi. Sumber daya Microsoft Azure Active Directory disertakan dalam Semua sumber daya tetapi dapat ditargetkan secara individual dalam kebijakan Akses Kondisional dengan langkah-langkah berikut:

1. Masuk ke pusat admin Microsoft Entra sebagai Admin Definisi Atribut dan Admin Penugasan Atribut.
2. Telusuri ke Entra ID>Atribut keamanan kustom.
3. Buat set atribut baru dan definisi atribut. Untuk informasi selengkapnya, lihat Tambahkan atau nonaktifkan definisi atribut keamanan kustom di Microsoft Entra ID.
4. Telusuri ke Entra ID>Aplikasi Perusahaan.
5. Hapus filter jenis Aplikasi dan cari ID Aplikasi yang dimulai dengan 00000002-0000-0000-c000-000000000000.
6. Pilih Windows Azure Active Directory>Kait keamanan kustom>Tambahkan penugasan.
7. Pilih set atribut dan nilai atribut yang Anda rencanakan untuk digunakan dalam kebijakan.
8. Telusuri ke Entra ID>Akses Bersyarat>Policies.
9. Membuat atau mengubah kebijakan yang sudah ada.
10. Di bawah Sumber Daya Sasaran>(sebelumnya aplikasi cloud)>Termasuk, pilih >Pilih sumber daya>Edit filter.
11. Sesuaikan filter untuk menyertakan set atribut dan definisi Anda dari sebelumnya.
12. Di bawah Kontrol akses>Berikan, pilih Berikan akses, Perlu kekuatan autentikasi, pilih Autentikasi multifaktor, lalu pilih Pilih.
13. Konfirmasikan pengaturan Anda dan atur Aktifkan kebijakan ke Khusus Laporan.
14. Pilih Buat untuk mengaktifkan kebijakan Anda.

Note

Konfigurasikan kebijakan ini seperti yang dijelaskan dalam panduan di atas. Setiap penyimpangan dalam membuat kebijakan seperti yang dijelaskan (seperti menentukan pengecualian sumber daya) dapat mengakibatkan cakupan hak istimewa yang rendah dikecualikan dan kebijakan tidak berlaku seperti yang dimaksudkan.

Semua sumber daya internet dengan Akses Aman Global

Opsi Semua sumber daya internet dengan Akses Aman Global memungkinkan admin untuk menargetkan profil penerusan lalu lintas akses internet dari Akses Internet Microsoft Entra.

Profil di Akses Aman Global ini memungkinkan admin menentukan dan mengontrol bagaimana lalu lintas dirutekan melalui Akses Internet Microsoft Entra dan Akses Privat Microsoft Entra. Profil penerusan lalu lintas dapat ditetapkan ke perangkat dan jaringan jarak jauh. Untuk contoh cara menerapkan kebijakan Akses Bersyarat ke profil lalu lintas ini, lihat artikel Cara menerapkan kebijakan Akses Bersyarat ke profil lalu lintas Microsoft 365.

Untuk informasi selengkapnya tentang profil ini, lihat artikel Profil penerusan lalu lintas Akses Aman Global.

Semua sumber daya agen (Pratinjau)

Menerapkan Kebijakan Akses Bersyarat pada Semua sumber daya agen memastikan kebijakan ini diterapkan untuk semua permintaan token pada prinsipal cetak biru identitas agen dan identitas agen.

Tindakan pengguna

Tindakan pengguna adalah tugas yang dilakukan pengguna. Akses Kondisional mendukung dua tindakan pengguna:

• Daftarkan informasi keamanan: Tindakan pengguna ini memungkinkan kebijakan Akses Bersyar memberlakukan aturan saat pengguna mencoba mendaftarkan informasi keamanan mereka. Untuk informasi selengkapnya, lihat Pendaftaran informasi keamanan gabungan.

Note

Jika admin menerapkan kebijakan yang menargetkan registrasi informasi keamanan oleh pengguna, dan akun pengguna adalah tamu dari akun pribadi Microsoft (MSA), kontrol 'Memerlukan autentikasi multifaktor' mengharuskan pengguna MSA tersebut untuk mendaftarkan informasi keamanan mereka dengan organisasi. Jika pengguna tamu berasal dari penyedia lain seperti Google, akses akan diblokir.

• Mendaftarkan atau menggabungkan perangkat: Tindakan pengguna ini memungkinkan admin menerapkan kebijakan Akses Bersyarat saat pengguna mendaftarkan atau bergabung perangkat ke Microsoft Entra ID. Ini memungkinkan admin melakukan konfigurasi autentikasi multi-faktor untuk mendaftarkan atau menggabungkan perangkat dengan tingkat granularitas yang lebih tinggi daripada kebijakan di seluruh penyewa. Ada tiga pertimbangan utama dengan tindakan pengguna ini:
  • Require multifactor authentication dan Require auth strength adalah satu-satunya kontrol akses yang tersedia dengan tindakan pengguna ini dan semua lainnya dinonaktifkan. Pembatasan ini mencegah konflik dengan kontrol akses yang bergantung pada pendaftaran perangkat Microsoft Entra atau tidak berlaku untuk pendaftaran perangkat Microsoft Entra.
    • Windows Hello untuk Bisnis dan kode akses terikat perangkat tidak didukung karena skenario tersebut mengharuskan perangkat sudah terdaftar.
  • Client apps, Filters for devices, dan kondisi Device state tidak tersedia dengan tindakan pengguna ini karena bergantung pada pendaftaran perangkat Microsoft Entra untuk menerapkan kebijakan Akses Bersyarkat.

Warning

Jika kebijakan Akses Bersyar dikonfigurasi dengan tindakan pengguna Mendaftarkan atau menggabungkan perangkat, atur Entra ID>Perangkat>Tinjauan>Pengaturan Perangkat - Require Multifactor Authentication to register or join devices with Microsoft Entra ke Tidak. Jika tidak, kebijakan Akses Bersyarat dengan tindakan pengguna ini tidak diterapkan dengan benar. Pelajari selengkapnya tentang pengaturan perangkat ini di Mengonfigurasi pengaturan perangkat.

Konteks autentikasi

Konteks autentikasi mengamankan data dan tindakan dalam aplikasi. Aplikasi ini mencakup aplikasi kustom, aplikasi lini bisnis (LOB), SharePoint, atau aplikasi yang dilindungi oleh Microsoft Defender for Cloud Apps. Ini juga dapat digunakan dengan Microsoft Entra Privileged Identity Management (PIM) untuk menerapkan kebijakan Akses Bersyarat selama aktivasi peran.

Misalnya, organisasi mungkin menyimpan file di situs SharePoint seperti menu makan siang atau resep saus BBQ rahasia. Semua orang mungkin mengakses situs menu makan siang, tetapi pengguna yang mengakses situs resep saus BBQ rahasia mungkin perlu menggunakan perangkat terkelola dan menyetujui ketentuan penggunaan tertentu. Demikian pula, administrator yang mengaktifkan peran istimewa melalui PIM mungkin diperlukan untuk melakukan autentikasi multifaktor atau menggunakan perangkat yang sesuai.

Konteks autentikasi berfungsi dengan pengguna atau identitas beban kerja, tetapi tidak dalam kebijakan Akses Bersyarat yang sama.

Mengonfigurasi konteks autentikasi

Kelola konteks autentikasi dengan membuka Entra ID>Akses Bersyarat>Konteks autentikasi.

Pilih Konteks autentikasi baru untuk membuat definisi konteks autentikasi. Organisasi dapat membuat hingga 99 definisi konteks autentikasi (c1-c99). Konfigurasikan atribut ini:

• Display name adalah nama yang digunakan untuk mengidentifikasi konteks autentikasi di Microsoft Entra ID dan di berbagai aplikasi yang memanfaatkan konteks autentikasi. Gunakan nama yang dapat digunakan di seluruh sumber daya, seperti perangkat tepercaya, untuk mengurangi jumlah konteks autentikasi yang diperlukan. Memiliki set yang lebih kecil membatasi jumlah pengalihan dan memberikan pengalaman pengguna yang lebih baik.
• Deskripsi menyediakan informasi selengkapnya tentang kebijakan. Informasi ini digunakan oleh admin dan yang menerapkan konteks autentikasi ke sumber daya.
• Kotak centang Terbitkan ke aplikasi , saat dipilih, mengiklankan konteks autentikasi ke aplikasi dan membuatnya tersedia untuk ditetapkan. Jika tidak dipilih, konteks autentikasi tidak tersedia untuk sumber daya hilir.
• ID bersifat baca-saja dan digunakan dalam token dan aplikasi untuk definisi konteks autentikasi khusus permintaan. Tercantum di sini untuk pemecahan masalah dan kasus penggunaan pengembangan.

Menambahkan ke kebijakan Akses Bersyarat

Admin dapat memilih konteks autentikasi yang diterbitkan dalam kebijakan Akses Bersyarah dengan masuk keSumber daya Target> dan memilih Konteks autentikasi dari menu Pilih apa yang diterapkan kebijakan ini.

Menghapus konteks autentikasi

Sebelum menghapus konteks autentikasi, pastikan tidak ada aplikasi yang menggunakannya. Jika tidak, akses ke data aplikasi tidak dilindungi. Konfirmasikan ini dengan memeriksa log masuk untuk kasus di mana konteks autentikasi Kebijakan Akses Bersyarat diterapkan.

Untuk menghapus konteks autentikasi, pastikan tidak memiliki kebijakan Akses Bersyarat yang ditetapkan dan tidak diterbitkan ke aplikasi. Ini mencegah penghapusan konteks autentikasi yang tidak disengaja yang masih digunakan.

Beri tag sumber daya dengan konteks autentikasi

Untuk mempelajari selengkapnya tentang menggunakan konteks autentikasi, lihat artikel berikut ini.

• Gunakan label sensitivitas untuk melindungi konten di Microsoft Teams, grup Microsoft 365, dan situs SharePoint
• Microsoft Defender for Cloud Apps
• Aplikasi kustom
• Privileged Identity Management - Saat aktivasi, memerlukan konteks autentikasi Akses Bersyarat Microsoft Entra

Konten terkait

• Akses Kondisional: Kondisi – Pelajari cara mengonfigurasi kondisi untuk menyempurnakan kebijakan Anda.
• Kebijakan umum Akses Bersyarat – Jelajahi templat kebijakan umum yang sering digunakan untuk memulai dengan cepat.
• Ketergantungan aplikasi klien – Pahami bagaimana ketergantungan memengaruhi kebijakan Akses Bersyarat.