Kunci yang dikelola pelanggan Azure Monitor

Artikel
01/06/2024

Data di Azure Monitor dienkripsi dengan kunci yang dikelola Microsoft. Anda dapat menggunakan kunci enkripsi Anda sendiri untuk melindungi data dan menyimpan kueri di ruang kerja Anda. Kunci yang dikelola pelanggan di Azure Monitor memberi Anda fleksibilitas yang lebih besar untuk mengelola kontrol akses ke log. Setelah dikonfigurasi, data baru yang diserap ke ruang kerja tertaut akan dienkripsi dengan kunci Anda yang disimpan di Azure Key Vault, atau "HSM" Terkelola Azure Key Vault.

Tinjau batasan dan batasan sebelum konfigurasi.

Ringkasan kunci yang dikelola pelanggan

Enkripsi saat Tidak Aktif adalah persyaratan privasi dan keamanan umum dalam organisasi. Anda dapat membiarkan Azure sepenuhnya mengelola enkripsi saat tidak aktif, sementara Anda memiliki berbagai opsi untuk mengelola kunci enkripsi dan enkripsi dengan cermat.

Azure Monitor memastikan bahwa semua data dan kueri yang disimpan dienkripsi saat tidak digunakan menggunakan kunci yang dikelola Microsoft (MMK). Anda dapat mengenkripsi data menggunakan kunci Anda sendiri di Azure Key Vault, untuk mengontrol siklus hidup utama, dan kemampuan untuk mencabut akses ke data Anda. Penggunaan enkripsi Azure Monitor identik dengan cara enkripsi Azure Storage beroperasi.

Kunci yang dikelola pelanggan dikirimkan pada kluster khusus yang memberikan tingkat perlindungan dan kontrol yang lebih tinggi. Data dienkripsi dalam penyimpanan dua kali, sekali di tingkat layanan menggunakan kunci yang dikelola Microsoft atau kunci yang dikelola Pelanggan, dan sekali di tingkat infrastruktur, menggunakan dua algoritma enkripsi yang berbeda dan dua kunci yang berbeda. enkripsi ganda melindungi dari skenario di mana salah satu algoritme atau kunci enkripsi dapat disusupi. Kluster khusus juga memungkinkan Anda melindungi data dengan Lockbox.

Data yang diserap dalam 14 hari terakhir atau baru-baru ini digunakan dalam kueri disimpan dalam cache panas (didukung SSD) untuk efisiensi kueri. Data SSD dienkripsi dengan kunci Microsoft terlepas dari konfigurasi kunci yang dikelola pelanggan, tetapi kontrol Anda atas akses SSD mematuhi pencabutan kunci

Model harga Kluster Khusus Analitik Log memerlukan Tingkat komitmen mulai dari 100 GB per hari.

Cara kerja kunci yang dikelola pelanggan di Azure Monitor

Azure Monitor menggunakan identitas terkelola untuk memberikan akses ke Azure Key Vault Anda. Identitas kluster Log Analytics didukung di tingkat kluster. Untuk mengizinkan kunci yang dikelola pelanggan di beberapa ruang kerja, sumber daya Kluster Analitik Log berfungsi sebagai koneksi identitas perantara antara Key Vault dan ruang kerja Analitik Log Anda. Penyimpanan kluster menggunakan identitas terkelola yang terkait dengan kluster untuk mengautentikasi ke Azure Key Vault Anda melalui ID Microsoft Entra.

Kluster mendukung dua jenis identitas terkelola: Berbasis sistem dan Ditetapkan pengguna, sementara satu identitas dapat ditentukan dalam kluster tergantung pada skenario Anda.

Identitas terkelola yang ditetapkan sistem lebih sederhana dan dihasilkan secara otomatis dengan pembuatan kluster ketika identitas type diatur ke "SystemAssigned". Identitas ini dapat digunakan nanti untuk memberikan akses penyimpanan ke Key Vault Anda untuk operasi bungkus dan bongkar.
Identitas terkelola yang ditetapkan pengguna memungkinkan Anda mengonfigurasi kunci yang dikelola Pelanggan pada pembuatan kluster, saat memberikannya izin di Key Vault Anda sebelum pembuatan kluster.

Anda dapat menerapkan konfigurasi kunci yang dikelola pelanggan ke kluster baru, atau kluster yang ada yang ditautkan ke ruang kerja dan menyerap data. Data baru yang diserap ke ruang kerja tertaut akan dienkripsi dengan kunci Anda, dan data lama yang diserap sebelum konfigurasi, tetap dienkripsi dengan kunci Microsoft. Kueri Anda tidak terpengaruh oleh konfigurasi kunci yang dikelola pelanggan dan dilakukan di seluruh data lama dan baru dengan mulus. Anda dapat membatalkan tautan ruang kerja dari kluster kapan saja. Data baru yang diserap setelah unlink dienkripsi dengan kunci Microsoft, dan kueri dilakukan di seluruh data lama, dan baru dengan mulus.

Penting

Kemampuan kunci yang dikelola pelanggan bergantung wilayah. Azure Key Vault, kluster, dan ruang kerja tertaut Anda harus berada di wilayah yang sama, tetapi dapat berada dalam langganan yang berbeda.

Key Vault
Sumber daya kluster Log Analytics yang memiliki identitas terkelola dengan izin ke Key Vault—Identitas disebarkan ke penyimpanan kluster khusus yang mendasari
Kluster khusus
Ruang kerja yang ditautkan ke kluster khusus

Operasi kunci enkripsi

Ada tiga jenis kunci yang terlibat dalam enkripsi data Penyimpanan:

"KEK" - Kunci Enkripsi Kunci (kunci yang dikelola Pelanggan Anda)
"AEK" - Kunci Enkripsi Akun
"DEK" - Kunci Enkripsi Data

Aturan berikut ini akan berlaku:

Penyimpanan kluster memiliki kunci enkripsi unik untuk setiap Akun Penyimpanan, yang dikenal sebagai "AEK".
"AEK" digunakan untuk memperoleh "DEK", yang merupakan kunci yang digunakan untuk mengenkripsi setiap blok data yang ditulis ke disk.
Saat Anda mengonfigurasi kunci di Key Vault Anda, dan memperbarui detail kunci dalam kluster, penyimpanan kluster melakukan permintaan untuk 'membungkus' dan 'membuka bungkus' "AEK" untuk enkripsi dan dekripsi.
"KEK" Anda tidak pernah meninggalkan Key Vault Anda, dan dalam kasus "HSM" Terkelola, tidak pernah meninggalkan perangkat keras.
Azure Storage menggunakan identitas terkelola yang terkait dengan sumber daya Kluster untuk autentikasi. Ini mengakses Azure Key Vault melalui ID Microsoft Entra.

Langkah-langkah provisi kunci yang Dikelola Pelanggan

Membuat Azure Key Vault dan menyimpan kunci
Membuat kluster
Memberikan izin ke Key Vault Anda
Memperbarui kluster dengan detail pengidentifikasi utama
Menghubungkan ruang kerja

Konfigurasi kunci yang dikelola pelanggan tidak didukung di portal Azure saat ini dan penyediaan dapat dilakukan melalui permintaan PowerShell, CLI, atau REST.

Menyimpan kunci enkripsi ("KEK")

Portofolio produk Azure Key Management mencantumkan vault dan HSM terkelola yang dapat digunakan.

Buat atau gunakan Azure Key Vault yang sudah ada di wilayah tempat kluster dijadwalkan. Di Brankas kunci Anda, buat atau impor kunci yang akan digunakan untuk enkripsi log. Azure Key Vault harus dikonfigurasi sebagai dapat dipulihkan, untuk melindungi kunci Anda dan akses ke data Anda di Azure Monitor. Anda dapat memverifikasi konfigurasi ini di bawah properti di Key Vault Anda, baik Penghapusan sementara dan Perlindungan terhadap hapus menyeluruh harus diaktifkan.

Pengaturan ini dapat diperbarui di Key Vault melalui CLI dan PowerShell:

Hapus sementara
Perlindungan terhadap hapus menyeluruh melindungi terhadap penghapusan paksa untuk rahasia, brankas meskipun setelah hapus menyeluruh

Membuat kluster

Kluster menggunakan identitas terkelola untuk enkripsi data dengan Key Vault Anda. Konfigurasikan properti identitas type ke SystemAssigned saat membuat kluster untuk mengizinkan akses ke Key Vault Anda untuk operasi "bungkus" dan "buka bungkus".

Pengaturan identitas dalam kluster untuk identitas terkelola yang ditetapkan sistem

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Ikuti prosedur yang diilustrasikan dalam artikel Kluster Khusus.

Memberi izin Key Vault

Ada dua model izin di Key Vault untuk memberikan akses ke kluster dan penyimpanan underlay Anda—kontrol akses berbasis peran Azure (Azure RBAC), dan kebijakan akses Vault (warisan).

Tetapkan Azure RBAC yang Anda kontrol (disarankan)

Untuk menambahkan penetapan peran, Anda harus memiliki izin Microsoft.Authorization/roleAssignments/write dan Microsoft.Authorization/roleAssignments/delete, seperti Administrator Akses Pengguna atau Pemilik.

Buka Key Vault Anda di portal Azure, klik Konfigurasi akses di Pengaturan, dan pilih opsi kontrol akses berbasis peran Azure. Kemudian masukkan Kontrol akses (IAM) dan tambahkan penetapan peran Pengguna Enkripsi Layanan Kripto Key Vault.
Menetapkan kebijakan akses vault (warisan)

Buka portal Key Vault di Azure dan klik Kebijakan Akses, pilih Kebijakan akses vault, lalu klik + Tambahkan Kebijakan Akses untuk membuat kebijakan dengan pengaturan berikut:
- Izin kunci—pilih Dapatkan, Kunci Bungkus, dan Buka Kunci Bungkus.
- Pilih prinsipal—tergantung pada jenis identitas yang digunakan dalam kluster (sistem atau identitas terkelola yang ditetapkan pengguna)
  - Identitas terkelola yang ditetapkan sistem - masukkan nama kluster atau ID prinsipal kluster
  - Identitas terkelola yang ditetapkan pengguna - masukkan nama identitas
Izin Dapatkan diperlukan untuk memverifikasi bahwa Key Vault Anda dikonfigurasi sebagai dapat dipulihkan untuk melindungi kunci Anda dan akses ke data Azure Monitor Anda.

Perbarui kluster dengan detail pengidentifikasi kunci

Semua operasi pada kluster memerlukan izin tindakan Microsoft.OperationalInsights/clusters/write. Izin ini dapat diberikan melalui Pemilik atau Kontributor yang berisi tindakan */write atau melalui peran Kontributor Log Analytics yang berisi tindakan Microsoft.OperationalInsights/*.

Langkah ini memperbarui penyimpanan kluster khusus dengan kunci dan versi yang digunakan untuk membungkus dan membuka bungkus "AEK".

Penting

Rotasi kunci dapat dilakukan secara otomatis atau memerlukan pembaruan kunci eksplisit, lihat Rotasi kunci untuk menentukan pendekatan yang cocok untuk Anda sebelum memperbarui detail pengidentifikasi kunci dalam kluster.
Pembaruan kluster tidak boleh menyertakan detail identitas dan pengidentifikasi kunci dalam operasi yang sama. Jika Anda perlu memperbarui keduanya, pembaruan harus dilakukan dalam dua operasi berturut-turut.

Perbarui KeyVaultProperties dalam kluster dengan detail pengidentifikasi kunci.

Operasi ini bersifat asinkron dan dapat memakan waktu cukup lama untuk diselesaikan.

T/A

Saat memasukkan nilai "''" untuk key-version, kluster selalu menggunakan versi kunci terakhir di Key Vault dan tidak perlu memperbarui rotasi kunci pasca kluster.

az account set --subscription cluster-subscription-id

az monitor log-analytics cluster update --no-wait --name "cluster-name" --resource-group "resource-group-name" --key-name "key-name" --key-vault-uri "key-uri" --key-version "key-version"

$clusterResourceId = az monitor log-analytics cluster list --resource-group "resource-group-name" --query "[?contains(name, "cluster-name")].[id]" --output tsv
az resource wait --created --ids $clusterResourceId --include-response-body true

Saat memasukkan nilai "''" untuk KeyVersion, kluster selalu menggunakan versi kunci terakhir di Key Vault dan tidak perlu memperbarui rotasi kunci pasca kluster.

Select-AzSubscription "cluster-subscription-id"

Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -KeyVaultUri "key-uri" -KeyName "key-name" -KeyVersion "key-version" -AsJob

# Check when the job is done when `-AsJob` was used
Get-Job -Command "New-AzOperationalInsightsCluster*" | Format-List -Property *

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/cluster-name?api-version=2021-06-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": "current-version"
  },
  "sku": {
    "name": "CapacityReservation",
    "capacity": 100
  }
}

Respons

Dibutuhkan beberapa saat untuk menyelesaikan propagasi kunci. Anda dapat memeriksa status pembaruan dengan mengirimkan permintaan GET pada kluster dan melihat properti KeyVaultProperties. Kunci yang baru-baru ini diperbarui harus kembali dalam respons.

Respons terhadap permintaan GET saat pembaruan kunci selesai: 202 (Diterima) dan header

{
  "identity": {
    "type": "SystemAssigned",
    "tenantId": "tenant-id",
    "principalId": "principal-id"
  },
  "sku": {
    "name": "capacityreservation",
    "capacity": 100
  },
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": "current-version"
      },
    "provisioningState": "Succeeded",
    "clusterId": "cluster-id",
    "billingType": "Cluster",
    "lastModifiedDate": "last-modified-date",
    "createdDate": "created-date",
    "isDoubleEncryptionEnabled": false,
    "isAvailabilityZonesEnabled": false,
    "capacityReservationProperties": {
      "lastSkuUpdate": "last-sku-modified-date",
      "minCapacity": 100
    }
  },
  "id": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
  "name": "cluster-name",
  "type": "Microsoft.OperationalInsights/clusters",
  "location": "cluster-region"
}

Menautkan ruang kerja ke kluster

Penting

Langkah ini harus dilakukan hanya setelah penyediaan kluster. Jika Anda menautkan ruang kerja dan menyerap data sebelum provisi, data yang diserap akan dihapus dan tidak akan dapat dipulihkan.

Anda harus memiliki izin "tulis" di ruang kerja dan kluster Anda untuk melakukan operasi ini. Ini termasuk Microsoft.OperationalInsights/workspaces/write dan Microsoft.OperationalInsights/clusters/write.

Ikuti prosedur yang diilustrasikan dalam artikel Kluster Khusus.

Pencabutan kunci

Penting

Cara yang disarankan untuk mencabut akses ke data Anda adalah dengan menonaktifkan kunci Anda, atau menghapus Kebijakan Akses di Key Vault Anda.
Mengatur identitytype kluster ke None juga mencabut akses ke data Anda, tetapi pendekatan ini tidak disarankan karena Anda tidak dapat mengembalikannya tanpa menghubungi dukungan.

Penyimpanan kluster selalu menghormati perubahan izin utama dalam waktu satu jam atau lebih cepat, dan penyimpanan menjadi tidak tersedia. Data baru yang diserap ke ruang kerja tertaut tidak berfungsi dan tidak dapat dipulihkan. Data tidak dapat diakses di ruang kerja ini dan kueri gagal. Data yang sebelumnya diserap tetap berada di penyimpanan selama kluster dan ruang kerja Anda tidak dihapus. Data yang tidak dapat diakses diatur oleh kebijakan penyimpanan data dan dibersihkan saat retensi tercapai. Data yang diserap dalam 14 hari terakhir dan data yang baru-baru ini digunakan dalam kueri juga disimpan dalam cache panas (didukung SSD) untuk efisiensi kueri. Data pada SSD akan dihapus pada operasi pencabutan kunci dan menjadi tidak dapat diakses. Penyimpanan kluster mencoba mencapai Key Vault untuk membungkus dan membongkar secara berkala, dan setelah kunci diaktifkan, pembongkaran berhasil, data SSD dimuat ulang dari penyimpanan, dan penyerapan dan kueri data dilanjutkan dalam waktu 30 menit.

Rotasi kunci

Rotasi kunci memiliki dua mode:

Rotasi otomatis—perbarui kluster Anda dengan "keyVaultProperties" tetapi hilangkan properti "keyVersion", atau atur ke "". Penyimpanan secara otomatis menggunakan versi kunci terbaru.
Pembaruan versi kunci eksplisit—perbarui kluster Anda dengan versi kunci di properti "keyVersion". Rotasi tombol memerlukan pembaruan "keyVaultProperties" eksplisit dalam kluster, baca bagian Memperbarui kluster dengan Detail pengidentifikasi utama. Jika Anda membuat versi kunci baru di Key Vault tetapi tidak memperbaruinya di kluster, penyimpanan kluster tetap menggunakan kunci Anda sebelumnya. Jika Anda menonaktifkan atau menghapus kunci lama sebelum memperbarui yang baru di kluster, Anda masuk ke status pencabutan kunci.

Semua data Anda tetap dapat diakses setelah operasi rotasi kunci. Data selalu dienkripsi dengan Kunci Enkripsi Akun ("AEK"), yang dienkripsi dengan versi Key Encryption Key ("KEK") baru Anda di Key Vault.

Kunci yang dikelola pelanggan untuk kueri yang disimpan dan pemberitahuan pencarian log

Bahasa kueri yang digunakan di Log Analytics bersifat ekspresif dan dapat berisi informasi sensitif dalam komentar, atau dalam sintaksis kueri. Beberapa organisasi mengharuskan informasi tersebut dilindungi di bawah Kebijakan kunci yang dikelola pelanggan dan Anda perlu menyimpan kueri yang dienkripsi dengan kunci Anda. Azure Monitor memungkinkan Anda menyimpan kueri yang disimpan dan pemberitahuan pencarian log yang dienkripsi dengan kunci Anda di Akun Penyimpanan Anda sendiri saat ditautkan ke ruang kerja Anda.

Kunci yang dikelola pelanggan untuk Buku Kerja

Dengan pertimbangan yang disebutkan untuk kunci yang dikelola pelanggan untuk kueri tersimpan dan pemberitahuan pencarian log, Azure Monitor memungkinkan Anda menyimpan kueri Buku Kerja yang dienkripsi dengan kunci Anda di Akun Penyimpanan Anda sendiri, saat memilih Simpan konten ke Akun Azure Storage dalam operasi 'Simpan' Buku Kerja.

Catatan

Kueri tetap dienkripsi dengan kunci Microsoft ("MMK") dalam skenario berikut terlepas dari konfigurasi kunci yang dikelola pelanggan: Dasbor Azure, Azure Logic App, Azure Notebooks, dan Automation Runbooks.

Saat menautkan Akun Penyimpanan Anda untuk kueri yang disimpan, layanan menyimpan kueri yang disimpan dan kueri pemberitahuan pencarian log di Akun Penyimpanan Anda. Memiliki kontrol pada kebijakan enkripsi-saat-istirahat Akun Penyimpanan, Anda dapat melindungi kueri yang disimpan dan pemberitahuan pencarian log dengan kunci yang dikelola Pelanggan. Namun, Anda akan bertanggung jawab atas biaya yang terkait dengan Akun Penyimpanan tersebut.

Pertimbangan sebelum menetapkan kunci yang dikelola pelanggan untuk kueri

Anda harus memiliki izin "tulis" di ruang kerja dan Akun Penyimpanan Anda.
Pastikan untuk membuat Akun Penyimpanan Anda di wilayah yang sama dengan ruang kerja Analitik Log Anda berada, dengan enkripsi kunci yang dikelola pelanggan. Ini penting karena kueri yang disimpan disimpan dalam penyimpanan tabel dan hanya dapat dienkripsi pada pembuatan Akun Penyimpanan.
Kueri yang disimpan dalam paket kueri tidak dienkripsi dengan kunci yang dikelola Pelanggan. Pilih Simpan sebagai kueri Warisan saat menyimpan kueri sebagai gantinya, untuk melindunginya dengan kunci yang dikelola pelanggan.
Menyimpan kueri dalam penyimpanan dianggap artefak layanan dan formatnya dapat berubah.
Menautkan Akun Penyimpanan untuk kueri akan menghapus kueri penyimpanan yang sudah ada dari ruang kerja Anda. Salin menyimpan kueri yang Anda butuhkan sebelum konfigurasi ini. Anda bisa menampilkan kueri yang disimpan menggunakan PowerShell.
'Riwayat' kueri dan 'menyematkan ke dasbor' tidak didukung saat menautkan Akun Penyimpanan untuk kueri.
Anda dapat menautkan satu Akun Penyimpanan ke ruang kerja untuk kueri yang disimpan dan kueri pemberitahuan pencarian log.
Pemberitahuan pencarian log disimpan dalam penyimpanan blob dan enkripsi kunci yang dikelola pelanggan dapat dikonfigurasi di pembuatan Akun Penyimpanan, atau yang lebih baru.
Pemberitahuan pencarian log yang diaktifkan tidak akan berisi hasil pencarian atau kueri pemberitahuan. Anda dapat menggunakan dimensi pemberitahuan untuk mendapatkan konteks dalam peringatan yang diaktifkan.

Mengonfigurasi BYOS untuk kueri yang disimpan

Tautkan Akun Penyimpanan untuk kueri untuk menyimpan kueri yang disimpan di Akun Penyimpanan Anda.

T/A

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type Query --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Query -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Query?api-version=2021-06-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Query", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

Setelah konfigurasi, kueri pencarian baru yang disimpan akan disimpan di penyimpanan Anda.

Mengonfigurasi BYOS untuk kueri pemberitahuan pencarian log

Tautkan Akun Penyimpanan untuk Pemberitahuan untuk menyimpan kueri pemberitahuan pencarian log di Akun Penyimpanan Anda.

T/A

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type ALerts --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Alerts -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Alerts?api-version=2021-06-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Alerts", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

Setelah konfigurasi, kueri peringatan baru akan disimpan di penyimpanan Anda.

Customer Lockbox

Lockbox memberi Anda kontrol untuk menyetujui atau menolak permintaan teknisi Microsoft untuk mengakses data Anda selama permintaan dukungan.

Lockbox disediakan dalam kluster khusus di Azure Monitor, tempat izin Anda untuk mengakses data diberikan di tingkat langganan.

Pelajari selengkapnya tentang Customer Lockbox untuk Microsoft Azure

Operasi kunci yang Dikelola Pelanggan

Kunci yang Dikelola Pelanggan disediakan pada kluster khusus dan operasi ini dirujuk dalam artikel kluster khusus

Dapatkan semua kluster di grup sumber daya
Dapatkan semua kluster di langganan
Perbarui reservasi kapasitas dalam kluster
Perbarui billingType dalam kluster
Hapus tautan ruang kerja dari kluster
Menghapus klaster

Pembatasan dan batasan

Maksimal dua kluster aktif dapat dibuat di setiap wilayah dan langganan.
Jumlah maksimum tujuh kluster yang dipesan (aktif atau baru dihapus) dapat dibuat di setiap wilayah dan langganan.
Maksimal 1.000 ruang kerja Log Analytics dapat ditautkan ke kluster.
Maksimal dua operasi tautan ruang kerja di ruang kerja tertentu diperbolehkan dalam periode 30 hari.
Memindahkan kluster ke grup sumber daya atau langganan lain saat ini tidak didukung.
Pembaruan kluster tidak boleh menyertakan detail identitas dan pengidentifikasi kunci dalam operasi yang sama. Jika Anda perlu memperbarui keduanya, pembaruan harus dilakukan dalam dua operasi berturut-turut.
Lockbox tidak tersedia di Tiongkok pada saat ini.
Enkripsi ganda dikonfigurasi secara otomatis untuk kluster yang dibuat mulai Oktober 2020 di wilayah yang didukung. Anda dapat memverifikasi apakah kluster Anda dikonfigurasi untuk enkripsi ganda dengan mengirimkan permintaan GET pada kluster dan mengamati bahwa nilai isDoubleEncryptionEnabled adalah true untuk kluster dengan enkripsi ganda diaktifkan.
- Jika Anda membuat kluster dan mendapatkan pesan kesalahan—"nama wilayah tidak mendukung Enkripsi Ganda untuk kluster", Anda masih dapat membuat kluster tanpa Enkripsi ganda dengan menambahkan "properties": {"isDoubleEncryptionEnabled": false} dalam isi permintaan REST.
- Pengaturan enkripsi ganda tidak dapat diubah setelah kluster dibuat.

Menghapus ruang kerja yang ditautkan diizinkan saat ditautkan ke kluster. Jika Anda memutuskan untuk memulihkan ruang kerja selama periode penghapusan sementara, ruang kerja akan kembali ke status sebelumnya dan tetap tertaut ke kluster.

Enkripsi kunci yang dikelola pelanggan berlaku untuk data yang baru diserap setelah waktu konfigurasi. Data yang diserap sebelum konfigurasi, tetap dienkripsi dengan kunci Microsoft. Anda dapat meminta data yang diserap sebelum dan sesudah konfigurasi kunci yang dikelola Pelanggan dengan mulus.
Azure Key Vault harus dikonfigurasi sebagai dapat dipulihkan. Properti ini tidak diaktifkan secara default dan harus dikonfigurasi menggunakan CLI atau PowerShell:
- Penghapusan Sementara.
- Perlindungan terhadap hapus menyeluruh harus diaktifkan untuk mencegah penghapusan paksa rahasia, vault bahkan setelah penghapusan sementara.
Azure Key Vault, kluster, dan ruang kerja Anda harus berada di wilayah yang sama dan di penyewa Microsoft Entra yang sama, tetapi dapat berada di langganan yang berbeda.
Mengatur identitytype kluster ke None juga mencabut akses ke data Anda, tetapi pendekatan ini tidak disarankan karena Anda tidak dapat mengembalikannya tanpa menghubungi dukungan. Cara yang direkomendasikan untuk mencabut akses ke data Anda adalah pencabutan kunci.
Anda tidak dapat menggunakan kunci yang dikelola Pelanggan dengan identitas terkelola yang ditetapkan pengguna jika Key Vault Anda berada di Private-Link (vNet). Anda dapat menggunakan Identitas terkelola yang ditetapkan sistem dalam skenario ini.
Kueri asinkron pekerjaan pencarian tidak didukung dalam skenario Kunci yang dikelola pelanggan untuk saat ini.

Pemecahan Masalah

Perilaku per ketersediaan Key Vault:
- Operasi normal—penyimpanan menyimpan cache "AEK" untuk waktu yang singkat dan kembali ke Key Vault untuk dibuka secara berkala.
- Kesalahan koneksi Key Vault—penyimpanan menangani kesalahan sementara (waktu habis, kegagalan koneksi, masalah "DNS"), dengan mengizinkan kunci untuk tetap berada di cache selama masalah ketersediaan, dan mengatasi masalah blip dan ketersediaan. Kemampuan kueri dan penyerapan berlanjut tanpa gangguan.
Tingkat akses Key Vault—Frekuensi penyimpanan kluster Azure mengakses Key Vault untuk membungkus dan membuka adalah antara 6 hingga 60 detik.
Jika Anda memperbarui kluster saat berada di status provisi, atau memperbarui status, pembaruan gagal.
Jika Anda mendapatkan konflik—kesalahan saat membuat kluster, kluster dengan nama yang sama mungkin telah dihapus dalam 14 hari terakhir dan disimpan dicadangkan. Nama kluster yang dihapus menjadi tersedia 14 hari setelah penghapusan.
Tautan ruang kerja ke kluster gagal jika ditautkan ke kluster lain.
Jika Anda membuat kluster dan segera menentukan KeyVaultProperties, operasi mungkin gagal hingga identitas ditetapkan dalam kluster, dan diberikan di Key Vault.
Jika Anda memperbarui kluster yang ada dengan KeyVaultProperties dan Kebijakan Akses kunci 'Dapatkan' hilang di Key Vault, operasi gagal.
Jika Anda gagal menyebarkan kluster Anda, verifikasi bahwa Azure Key Vault, kluster, dan ruang kerja tertaut Anda berada di wilayah yang sama. Dapat berada dalam langganan yang berbeda.
Jika Anda memutar kunci di Key Vault dan tidak memperbarui detail pengidentifikasi kunci baru di kluster, kluster tetap menggunakan kunci sebelumnya dan data Anda akan menjadi tidak dapat diakses. Perbarui detail pengidentifikasi kunci baru di kluster untuk melanjutkan penyerapan dan kueri data. Anda dapat memperbarui versi kunci dengan "''" agar penyimpanan selalu menggunakan versi kunci terlambat secara otomatis.
Beberapa operasi berjalan lama dan dapat memakan waktu cukup lama untuk diselesaikan, termasuk pembuatan kluster, pembaruan kunci kluster, dan penghapusan kluster. Anda dapat memeriksa status operasi dengan mengirimkan permintaan GET ke kluster atau ruang kerja dan mengamati responsnya. Misalnya, ruang kerja yang tidak ditautkan tidak akan memiliki clusterResourceId pada fitur.
Pesan kesalahan

Pembaruan Kluster
- 400 — Kluster sedang dalam status penghapusan. Operasi asinkron sedang berlangsung. Kluster harus menyelesaikan operasinya sebelum operasi pembaruan dilakukan.
- 400 — KeyVaultProperties tidak kosong tetapi formatnya buruk. Lihat pembaruan pengidentifikasi kunci.
- 400 — Gagal memvalidasi kunci di Key Vault. Ini terjadi karena kurangnya izin atau ketika kunci tidak ada. Verifikasi bahwa Anda mengatur kunci dan Kebijakan Akses di Key Vault.
- 400 — Kunci tidak dapat dipulihkan. Key Vault harus diatur Hapus sementara dan Perlindungan dari hapus menyeluruh. Lihat dokumentasi Key Vault
- 400 — Operasi tidak dapat dijalankan sekarang. Tunggu hingga operasi Async selesai dan coba lagi.
- 400 — Kluster sedang dalam status penghapusan. Tunggu hingga operasi Async selesai dan coba lagi.
Pengambilan Kluster
- 404--Kluster tidak ditemukan, kluster mungkin telah dihapus. Jika Anda mencoba membuat kluster dengan nama tersebut dan mendapatkan konflik, kluster sedang dalam proses penghapusan.

Langkah berikutnya

Pelajari tentang Tagihan kluster khusus Log Analytics
Pelajari tentang desain ruang kerja Log Analytics yang tepat

Kunci yang dikelola pelanggan Azure Monitor

Ringkasan kunci yang dikelola pelanggan

Cara kerja kunci yang dikelola pelanggan di Azure Monitor

Operasi kunci enkripsi

Langkah-langkah provisi kunci yang Dikelola Pelanggan

Menyimpan kunci enkripsi ("KEK")

Membuat kluster

Memberi izin Key Vault

Perbarui kluster dengan detail pengidentifikasi kunci

Menautkan ruang kerja ke kluster

Pencabutan kunci

Rotasi kunci

Kunci yang dikelola pelanggan untuk kueri yang disimpan dan pemberitahuan pencarian log

Kunci yang dikelola pelanggan untuk Buku Kerja

Customer Lockbox

Operasi kunci yang Dikelola Pelanggan

Pembatasan dan batasan

Pemecahan Masalah

Langkah berikutnya

Sumber Daya Tambahan: