Bagikan melalui

Kunci yang dikelola pelanggan Azure Monitor

  • Artikel

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, atau Anda dapat 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 mengelola siklus hidup utama dan dapat mencabut akses ke data, Anda dapat mengenkripsi data dengan kunci Anda sendiri menggunakan Azure Key Vault.

Kunci yang dikelola pelanggan tersedia pada kluster khusus dan memberi Anda tingkat perlindungan dan kontrol yang lebih tinggi. Data dienkripsi dalam penyimpanan dua kali - di tingkat layanan menggunakan kunci yang dikelola Microsoft atau kunci yang dikelola pelanggan, dan di 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 mungkin 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 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 sehari.

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 saat Anda membuat kluster jika 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 memberikan izin di Key Vault Anda sebelum pembuatan kluster.

Anda dapat mengonfigurasi kunci yang dikelola pelanggan pada kluster baru, atau kluster yang ada yang ditautkan ke ruang kerja dan sudah 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. Konfigurasi kunci yang dikelola pelanggan tidak memengaruhi kueri Anda, yang terus berjalan pada data lama dan baru dengan mulus. Anda dapat membatalkan tautan ruang kerja dari kluster kapan saja. Data baru yang Anda serap setelah unlink dienkripsi dengan kunci Microsoft, dan kueri dilakukan di seluruh data lama, dan baru dengan mulus.

Penting

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

Cuplikan layar gambaran umum kunci yang dikelola pelanggan.

  1. Key Vault
  2. Sumber daya kluster Analitik Log yang memiliki identitas terkelola dengan izin ke Key Vault - identitas disebarkan ke penyimpanan kluster khusus underlay
  3. Kluster khusus
  4. 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, jika Anda menggunakan "HSM" Terkelola, itu 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

  1. Membuat Azure Key Vault dan menyimpan kunci
  2. Membuat kluster
  3. Memberikan izin ke Key Vault Anda
  4. Memperbarui kluster dengan detail pengidentifikasi utama
  5. 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.

Cuplikan layar pengaturan penghapusan sementara dan perlindungan penghapusan menyeluruh.

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

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).

  1. 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.

    Buka Key Vault Anda di portal Azure dan pilih Pengaturan>Konfigurasi>akses kontrol akses berbasis peran Azure. Kemudian masukkan Kontrol akses (IAM) dan tambahkan penetapan peran Pengguna Enkripsi Layanan Kripto Key Vault.

    Cuplikan layar Izin RBAC Grant Key Vault.

  2. 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

    Cuplikan layar izin kebijakan akses Grant Key Vault.

    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.

Cuplikan layar Izin Berikan Key Vault.

Perbarui KeyVaultProperties dalam kluster dengan detail pengidentifikasi kunci.

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

T/A

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

  • 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 kunci memerlukan pembaruan eksplisit "keyVaultProperties" 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 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.

Cuplikan layar penyimpanan 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

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

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:

  • 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