Kunci yang dikelola pelanggan Azure Monitor

Artikel
23/02/2025

Data di Azure Monitor dienkripsi dengan kunci yang dikelola Microsoft. Anda dapat menggunakan kunci enkripsi Anda sendiri untuk melindungi data di ruang kerja Anda. Kunci yang dikelola pelanggan di Azure Monitor memberi Anda kontrol pada siklus hidup kunci enkripsi, dan akses ke log. Setelah dikonfigurasi, data baru yang diserap ke ruang kerja tertaut dienkripsi dengan kunci Anda di Azure Key Vault, atau Azure Key Vault Managed "HSM".

Ringkasan kunci yang dikelola pelanggan

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

Azure Monitor memastikan bahwa semua data dan kueri yang disimpan dienkripsi saat tidak digunakan menggunakan kunci yang dikelola Microsoft (MMK). Penggunaan enkripsi Azure Monitor identik dengan cara enkripsi Azure Storage beroperasi.

Untuk mengontrol siklus hidup utama dengan kemampuan untuk mencabut data akses, enkripsi data dengan kunci Anda sendiri di Azure Key Vault, atau "HSM" terkelola Azure Key Vault. Kemampuan kunci yang dikelola pelanggan tersedia pada kluster khusus dan memberi Anda tingkat perlindungan dan kontrol yang lebih tinggi.

Data yang diserap ke kluster khusus dienkripsi dua kali - pada tingkat layanan menggunakan kunci yang dikelola Microsoft atau kunci yang dikelola pelanggan, dan pada tingkat infrastruktur, menggunakan dua algoritma enkripsi yang berbeda dan dua kunci yang berbeda. Enkripsi ganda melindungi dari skenario di mana salah satu algoritma atau kunci enkripsi 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 hot-cache (didukung SSD) untuk efisiensi kueri. Data SSD dienkripsi dengan kunci yang dikelola Microsoft terlepas dari apakah Anda mengonfigurasi kunci yang dikelola pelanggan, tetapi kontrol Anda atas akses SSD mematuhi pencabutan kunci.

Penting

Kluster khusus menggunakan model harga tingkat komitmen setidaknya 100 GB per hari.

Cara kerja kunci yang dikelola pelanggan di Azure Monitor

Azure Monitor menggunakan identitas terkelola untuk memberikan akses ke kunci Anda di Azure Key Vault. Identitas kluster Analitik Log didukung di tingkat kluster. Untuk menyediakan kunci yang dikelola pelanggan di beberapa ruang kerja, sumber daya kluster Log Analytics 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 kluster ketika identity type diatur ke SystemAssigned. Identitas ini digunakan nanti untuk memberikan akses penyimpanan ke Key Vault Anda untuk enkripsi dan dekripsi data.
Identitas terkelola yang ditetapkan pengguna memungkinkan Anda mengonfigurasi kunci yang dikelola pelanggan pada pembuatan kluster, saat identity type diatur ke UserAssigned, dan memberikannya izin di Key Vault Anda sebelum pembuatan kluster.

Anda dapat mengonfigurasi kunci yang dikelola pelanggan pada kluster baru, atau kluster khusus yang ada dengan ruang kerja tertaut yang menyerap data. Demikian pula, Anda dapat membatalkan tautan ruang kerja dari kluster kapan saja. Data baru yang diserap ke ruang kerja tertaut dienkripsi dengan kunci Anda, dan data lama tetap dienkripsi dengan kunci yang dikelola Microsoft. Konfigurasi tidak mengganggu penyerapan atau kueri, di mana kueri dilakukan di seluruh data lama dan baru dengan mulus. Saat Anda membatalkan tautan ruang kerja dari kluster. Data baru yang diserap dienkripsi dengan kunci yang dikelola Microsoft.

Penting

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

Key Vault
Sumber daya kluster Analitik Log yang memiliki identitas terkelola dengan izin ke Key Vault - identitas disebarkan ke penyimpanan kluster khusus underlay
Kluster khusus
Ruang kerja yang ditautkan ke kluster khusus

Jenis 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 mengonfigurasi "KEK" kunci yang dikelola pelanggan di kluster Anda, penyimpanan kluster melakukan permintaan 'wrap' dan 'unwrap' ke Key Vault Anda untuk enkripsi dan dekripsi "AEK".
"KEK" Anda tidak pernah meninggalkan Key Vault Anda, dan, jika Anda menyimpan kunci Anda di "HSM" Terkelola Azure Key Vault, itu tidak pernah meninggalkan perangkat keras.
Azure Storage menggunakan identitas terkelola yang terkait dengan 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 khusus
Memberikan izin ke Key Vault Anda
Memperbarui kluster khusus dengan detail pengidentifikasi kunci
Menghubungkan ruang kerja

Konfigurasi kunci yang dikelola pelanggan tidak selesai didukung di portal Azure saat ini dan provisi 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

Izin yang diperlukan

Untuk melakukan tindakan terkait kluster, Anda memerlukan izin ini:

Perbuatan	Izin atau peran yang diperlukan
Membuat kluster khusus	`Microsoft.Resources/deployments/*`dan `Microsoft.OperationalInsights/clusters/write` izin, sebagaimana disediakan oleh peran bawaan Kontributor Analitik Log, misalnya
Ubah properti kluster	`Microsoft.OperationalInsights/clusters/write`izin, seperti yang disediakan oleh peran bawaan Kontributor Analitik Log, misalnya
Menautkan ruang kerja ke kluster	`Microsoft.OperationalInsights/clusters/write`, `Microsoft.OperationalInsights/workspaces/write`, dan `Microsoft.OperationalInsights/workspaces/linkedservices/write` izin, seperti yang disediakan oleh peran bawaan Kontributor Analitik Log, misalnya
Periksa status tautan ruang kerja	`Microsoft.OperationalInsights/workspaces/read` izin ke ruang kerja, seperti yang disediakan oleh peran bawaan Pembaca Analitik Log, misalnya
Mendapatkan kluster atau memeriksa status provisi kluster	`Microsoft.OperationalInsights/clusters/read` izin, seperti yang disediakan oleh peran bawaan Pembaca Analitik Log, misalnya
Memperbarui tingkat komitmen atau billingType dalam kluster	`Microsoft.OperationalInsights/clusters/write`izin, seperti yang disediakan oleh peran bawaan Kontributor Analitik Log, misalnya
Memberikan izin yang diperlukan	Peran Pemilik atau Kontributor yang memiliki `/write` izin, atau peran bawaan Kontributor Analitik Log, yang memiliki `Microsoft.OperationalInsights/` izin
Hapus tautan ruang kerja dari kluster	`Microsoft.OperationalInsights/workspaces/linkedServices/delete`izin, seperti yang disediakan oleh peran bawaan Kontributor Analitik Log, misalnya
Menghapus kluster khusus	`Microsoft.OperationalInsights/clusters/delete`izin, seperti yang disediakan oleh peran bawaan Kontributor Analitik Log, misalnya

Membuat kluster

Kluster menggunakan identitas terkelola untuk enkripsi data dengan Key Vault Anda. Konfigurasikan identity type properti ke SystemAssigned atau UserAssigned saat membuat kluster Anda untuk mengizinkan akses ke Key Vault Anda untuk operasi enkripsi dan dekripsi data.

Contoh FOr, tambahkan properti ini dalam isi permintaan untuk identitas terkelola yang ditetapkan sistem

JSON

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

Catatan

Jenis identitas dapat diubah setelah kluster dibuat tanpa gangguan pada penyerapan atau kueri, dengan pertimbangan berikut

Identitas dan kunci tidak dapat diperbarui secara bersamaan dalam kluster —perbarui dalam dua operasi berturut-turut
SystemAssigned Memperbarui ke UserAssigned—Berikan UserAssign identitas di Key Vault, lalu perbarui identity dalam kluster
UserAssigned Memperbarui ke SystemAssigned—Berikan SystemAssigned identitas di Key Vault, lalu perbarui identity dalam kluster

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 peran dengan Microsoft.Authorization/roleAssignments/write izin dan Microsoft.Authorization/roleAssignments/delete , seperti Administrator Akses Pengguna atau Pemilik.
1. Buka Key Vault Anda di portal Azure dan pilih Pengaturan>Konfigurasi>akses kontrol akses berbasis peran Azure dan Terapkan
2. Klik tombol Buka kontrol akses (IAM) dan tambahkan penetapan peran Pengguna Enkripsi Layanan Kripto Key Vault.
3. Pilih Identitas terkelola di tab Anggota dan pilih langganan untuk identitas dan identitas sebagai anggota
Menetapkan kebijakan akses vault (warisan)

Buka Key Vault Anda di portal Azure dan pilih Kebijakan Akses Kebijakan>> akses Vault+ Tambahkan Kebijakan Akses untuk membuat kebijakan dengan pengaturan ini:
- 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 */write tindakan, atau melalui peran Kontributor Analitik Log yang berisi Microsoft.OperationalInsights/* tindakan.

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

Penting

Rotasi kunci bisa otomatis atau per versi kunci eksplisit, lihat Rotasi kunci untuk menentukan pendekatan yang sesuai 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

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

Azure CLI

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

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

PowerShell

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 *

rst

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/cluster-name?api-version=2023-09-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
  },
  "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

JSON

{
  "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": ""
      },
    "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.

Ikuti prosedur yang diilustrasikan dalam artikel Kluster Khusus.

Membatalkan tautan ruang kerja dari kluster

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 identity type kluster ke None juga akan mencabut akses ke data Anda, tetapi pendekatan ini tidak direkomendasikan 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 dihilangkan 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:

Autorotasi—perbarui "keyVaultProperties" properti di kluster dan hilangkan "keyVersion" properti, atau atur ke "". Penyimpanan secara otomatis menggunakan versi kunci terbaru.
Pembaruan versi kunci eksplisit—perbarui "keyVaultProperties" properti dan perbarui versi kunci di "keyVersion" properti. Rotasi kunci memerlukan pembaruan "keyVersion" eksplisit properti dalam kluster. Untuk informasi selengkapnya, lihat Memperbarui kluster dengan detail Pengidentifikasi kunci. Jika Anda membuat versi kunci baru di Key Vault tetapi tidak memperbarui kunci 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 selama dan 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 mungkin 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

Azure CLI

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

PowerShell

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

rst

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Query?api-version=2020-08-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

Azure CLI

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

PowerShell

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

rst

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Alerts?api-version=2020-08-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.
Lockbox tidak berlaku untuk tabel dengan paket Tambahan.
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 mengkueri 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 identity type kluster ke None juga akan mencabut akses ke data Anda, tetapi pendekatan ini tidak direkomendasikan 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.
Paket tabel Tambahan tidak mendukung kunci yang dikelola pelanggan. Data dalam tabel dengan paket Tambahan dienkripsi dengan kunci yang dikelola Microsoft, bahkan jika Anda melindungi data di sisa ruang kerja Analitik Log Anda menggunakan kunci enkripsi Anda sendiri.

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.
Laju akses Key Vault - frekuensi penyimpanan kluster mengakses Key Vault untuk membungkus dan membongkar - 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.
Menautkan ruang kerja ke kluster gagal jika ruang kerja ditautkan ke kluster lain.
Jika Anda membuat kluster dan segera menentukan KeyVaultProperties, operasi mungkin gagal hingga identitas ditetapkan ke kluster, dan diberikan ke 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 dalam status menghapus. Operasi asinkron sedang berlangsung. Kluster harus menyelesaikan operasinya sebelum operasi pembaruan dilakukan.
- 400 - KeyVaultProperties tidak kosong tetapi memiliki format yang 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 dalam status menghapus. 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

Sumber Daya Tambahan:

Dokumentasi

Menggunakan akun penyimpanan yang dikelola pelanggan di Log Azure Monitor - Azure Monitor

Gunakan akun Azure Storage Anda sendiri untuk menyerap log ke Log Azure Monitor.
Kluster Khusus Log Azure Monitor - Azure Monitor

Pelanggan yang memenuhi tingkat komitmen minimum dapat menggunakan kluster khusus
Gambaran umum dan panduan keamanan Azure Monitor - Azure Monitor

Menjelaskan.
Kontrol Kepatuhan Peraturan Azure Policy untuk Azure Monitor - Azure Monitor

Mencantumkan kontrol Kepatuhan Peraturan Azure Policy yang tersedia untuk Azure Monitor. Definisi kebijakan bawaan ini memberikan pendekatan umum untuk mengelola kepatuhan sumber daya Azure Anda.
Garis besar keamanan Azure untuk Azure Monitor

Garis besar keamanan Azure Monitor menyediakan panduan prosedural dan sumber daya untuk menerapkan rekomendasi keamanan yang ditentukan dalam tolok ukur keamanan cloud Microsoft.
Menyiapkan kunci yang dikelola pelanggan di Microsoft Azure Sentinel

Pelajari cara menyiapkan kunci yang dikelola pelanggan (CMK) di Microsoft Sentinel.
Definisi kebijakan bawaan untuk Azure Monitor - Azure Monitor

Mencantumkan definisi kebijakan bawaan Azure Policy untuk Azure Monitor. Definisi kebijakan bawaan ini memberikan pendekatan umum untuk mengelola sumber daya Azure Anda.

Pelatihan

Jalur pembelajaran

Menjalankan aplikasi komputasi berkinerja tinggi (HPC) di Azure - Training

Azure HPC adalah kemampuan cloud yang dibangun khusus untuk beban kerja HPC & AI, menggunakan prosesor terdepan dan interkoneksi InfiniBand kelas HPC, untuk memberikan kinerja, skalabilitas, dan nilai aplikasi terbaik. Azure HPC memungkinkan pengguna untuk membuka inovasi, produktivitas, dan kelincahan bisnis, melalui berbagai teknologi HPC & AI yang sangat tersedia yang dapat dialokasikan secara dinamis saat bisnis dan kebutuhan teknis Anda berubah. Jalur pembelajaran ini adalah serangkaian modul yang memb

Sertifikasi

Bersertifikat Microsoft: Rekan Administrator Database Azure - Certifications

Mengelola infrastruktur database SQL Server untuk database hubungan cloud, lokal, dan hibrid menggunakan penawaran database relasional Microsoft PaaS.

Acara

Membangun Aplikasi dan Agen AI

17 Mar, 21 - 21 Mar, 10

Bergabunglah dengan seri meetup untuk membangun solusi AI yang dapat diskalakan berdasarkan kasus penggunaan dunia nyata dengan sesama pengembang dan pakar.

Daftar sekarang

Bagikan melalui

Kunci yang dikelola pelanggan Azure Monitor

Ringkasan kunci yang dikelola pelanggan

Cara kerja kunci yang dikelola pelanggan di Azure Monitor

Jenis kunci enkripsi

Langkah-langkah provisi kunci yang Dikelola Pelanggan

Menyimpan kunci enkripsi ("KEK")

Izin yang diperlukan

Membuat kluster

Memberi izin Key Vault

Perbarui kluster dengan detail pengidentifikasi kunci

Menautkan ruang kerja ke kluster

Membatalkan tautan ruang kerja dari 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

Saran dan Komentar

Sumber Daya Tambahan: