Bagikan melalui

Enkripsi data tidak aktif di Azure Database for PostgreSQL

Semua data yang dikelola oleh instans server fleksibel Azure Database for PostgreSQL selalu dienkripsi saat tidak aktif. Data tersebut mencakup semua database sistem dan pengguna, log server, segmen log write-ahead, dan cadangan. Enkripsi ditangani oleh penyimpanan yang mendasar melalui enkripsi sisi server Azure Disk Storage.

Enkripsi saat Istirahat dengan Layanan (SMK) atau Kunci yang Dikelola Pelanggan (CMK)

Azure Database for PostgreSQL mendukung dua mode enkripsi data tidak aktif: kunci terkelola layanan (SMK) dan kunci yang dikelola pelanggan (CMK). Enkripsi data dengan kunci yang dikelola layanan adalah mode default untuk server fleksibel Azure Database for PostgreSQL. Dalam mode ini, layanan secara otomatis mengelola kunci enkripsi yang digunakan untuk mengenkripsi data Anda. Anda tidak perlu mengambil tindakan apa pun untuk mengaktifkan atau mengelola enkripsi dalam mode ini.

Dalam mode kunci yang dikelola pelanggan , Anda dapat membawa kunci enkripsi Anda sendiri untuk mengenkripsi data Anda. Mode ini memberi Anda lebih banyak kontrol atas proses enkripsi, tetapi juga mengharuskan Anda untuk mengelola kunci enkripsi sendiri. Anda harus menyebarkan Azure Key Vault atau Modul Keamanan Perangkat Keras Terkelola (HSM) Azure Key Vault Anda sendiri dan mengonfigurasinya untuk menyimpan kunci enkripsi yang digunakan oleh instans server fleksibel Azure Database for PostgreSQL Anda.

Mode hanya dapat dipilih pada waktu pembuatan server. Ini tidak dapat diubah dari satu mode ke mode lainnya selama masa pakai server.

Untuk mencapai enkripsi data Anda, Azure Database for PostgreSQL menggunakan enkripsi Azure Storage untuk data tidak aktif. Saat menggunakan CMK, pelanggan bertanggung jawab untuk menyediakan kunci untuk mengenkripsi dan mendekripsi data di layanan Blob Storage dan Azure Files. Kunci ini harus disimpan di Azure Key Vault atau Modul Keamanan Perangkat Keras Terkelola (HSM) Azure Key Vault. Untuk informasi selengkapnya, lihat kunci yang dikelola pelanggan untuk enkripsi Azure Storage.

Manfaat yang diberikan oleh setiap mode (SMK atau CMK)

Enkripsi data dengan kunci terkelola layanan untuk Azure Database for PostgreSQL memberikan manfaat berikut:

  • Layanan ini secara otomatis dan sepenuhnya mengendalikan akses data.
  • Layanan ini secara otomatis dan sepenuhnya mengendalikan siklus hidup kunci Anda, termasuk perputaran kunci tersebut.
  • Anda tidak perlu khawatir mengelola kunci enkripsi data.
  • Enkripsi data berdasarkan kunci yang dikelola layanan tidak berdampak negatif pada performa beban kerja Anda.
  • Ini menyederhanakan pengelolaan kunci enkripsi (termasuk rotasi regulernya), dan pengelolaan identitas yang digunakan untuk mengakses kunci tersebut.

Enkripsi data dengan kunci yang dikelola pelanggan untuk Azure Database for PostgreSQL memberikan manfaat berikut:

  • Anda sepenuhnya mengontrol akses data. Anda bisa menghapus kunci untuk membuat database tidak dapat diakses.
  • Anda sepenuhnya mengontrol siklus hidup kunci, termasuk rotasi kunci, untuk menyelaraskan dengan kebijakan perusahaan.
  • Anda dapat mengelola dan mengatur semua kunci enkripsi Anda secara terpusat dalam instans Azure Key Vault Anda sendiri.
  • Enkripsi data berdasarkan kunci yang dikelola pelanggan tidak berdampak negatif pada performa beban kerja Anda.
  • Anda dapat menerapkan pemisahan tugas antara petugas keamanan, administrator basis data, dan administrator sistem.

Persyaratan CMK

Dengan kunci enkripsi yang dikelola pelanggan , Anda mengasumsikan semua tanggung jawab. Oleh karena itu, Anda harus menyebarkan Azure Key Vault atau Azure Key Vault HSM Anda sendiri. Anda harus menghasilkan atau mengimpor kunci Anda sendiri. Anda harus memberikan izin yang diperlukan pada Key Vault, sehingga instans server fleksibel Azure Database for PostgreSQL Anda dapat melakukan tindakan yang diperlukan pada kunci. Anda harus mengurus konfigurasi semua aspek jaringan Azure Key Vault tempat kunci disimpan, sehingga instans server fleksibel Azure Database for PostgreSQL Anda dapat mengakses kunci. Tanggung jawab Anda juga mencakup mengaudit akses ke kunci. Terakhir, Anda bertanggung jawab untuk mengganti kunci dan, jika diperlukan, memperbarui konfigurasi instans server fleksibel Azure Database for PostgreSQL Anda agar mereferensikan versi kunci yang telah diganti.

Saat Anda mengonfigurasi kunci yang dikelola pelanggan untuk akun penyimpanan, Azure Storage membungkus kunci enkripsi data akar (DEK) untuk akun dengan kunci yang dikelola pelanggan di brankas kunci terkait atau HSM terkelola. Perlindungan kunci enkripsi akar berubah, tetapi data di akun Azure Storage Anda selalu dienkripsi. Tidak ada tindakan tambahan yang diperlukan dari pihak Anda untuk memastikan data Anda tetap terenkripsi. Perlindungan oleh kunci yang dikelola pelanggan mulai berlaku segera.

Azure Key Vault adalah sistem manajemen kunci eksternal berbasis cloud. Ini sangat tersedia dan menyediakan penyimpanan yang dapat diskalakan dan aman untuk kunci kriptografi RSA, yang didukung secara opsional oleh modul keamanan perangkat keras (HSM) yang divalidasi FIPS 140 . Tidak memungkinkan akses langsung ke kunci yang disimpan, tetapi menyediakan layanan enkripsi dan dekripsi untuk entitas yang berwenang. Key Vault dapat membuat kunci, mengimpornya, atau menerimanya yang ditransfer dari perangkat HSM di lokasi.

Berikut ini adalah daftar persyaratan untuk mengonfigurasi enkripsi data untuk Azure Database for PostgreSQL:

  • Key Vault dan instans server fleksibel Azure Database for PostgreSQL Anda harus milik penyewa Microsoft Entra yang sama. Key Vault lintas penyewa dan interaksi server tidak didukung. Memindahkan sumber daya Key Vault setelah itu mengharuskan Anda untuk mengonfigurasi ulang enkripsi data.
  • Kami menyarankan Anda untuk mengatur Hari untuk mempertahankan konfigurasi vault yang dihapus untuk Key Vault menjadi 90 hari. Jika Anda mengonfigurasi instans Key Vault yang ada dengan angka yang lebih rendah, instans tersebut masih harus valid. Namun, jika Anda ingin mengubah pengaturan ini dan meningkatkan nilainya, anda perlu membuat instans Key Vault baru. Setelah instance dibuat, tidak mungkin untuk mengubah pengaturan ini.
  • Aktifkan fitur yang dihapus sementara di Key Vault untuk membantu Anda melindungi dari kehilangan data, jika kunci atau instans Key Vault dihapus secara tidak sengaja. Key Vault mempertahankan sumber daya yang dihapus sementara selama 90 hari kecuali pengguna memulihkan atau membersihkannya sementara itu. Tindakan pemulihan dan penghapusan menyeluruh memiliki izin mereka sendiri yang terkait dengan Key Vault peran RBAC atau izin kebijakan akses. Fitur penghapusan lunak secara otomatis diaktifkan. Jika Anda memiliki beberapa Key Vault yang disebarkan sejak lama, itu mungkin masih menonaktifkan penghapusan sementara. Dalam hal ini, Anda dapat mengaktifkannya menggunakan Azure CLI.
  • Aktifkan perlindungan penghapusan menyeluruh untuk memberlakukan periode retensi wajib untuk vault dan objek vault yang dihapus.
  • ** Berikan akses ke kunci untuk identitas terkelola yang ditetapkan pengguna dari instans server fleksibel Azure Database for PostgreSQL dengan cara:
  • Disarankan: Azure Key Vault sebaiknya dikonfigurasi dengan model izin RBAC dan identitas terkelola harus diberikan peran Pengguna Enkripsi Layanan Kripto Key Vault.
  • Warisan: Jika Azure Key Vault dikonfigurasi dengan model izin kebijakan Access, berikan izin berikut ke identitas terkelola:
  • get: Untuk mengambil properti dan bagian publik dari kunci di Key Vault.
  • list: Untuk mencantumkan dan melakukan iterasi melalui kunci yang disimpan di Key Vault.
  • wrapKey: Untuk mengenkripsi kunci enkripsi data.
  • unwrapKey: Untuk mendekripsi kunci enkripsi data.
  • Kunci yang digunakan untuk mengenkripsi kunci enkripsi data hanya dapat berupa asimetris, RSA, atau RSA-HSM. Ukuran kunci 2.048, 3.072, dan 4.096 didukung. Sebaiknya gunakan kunci 4.096-bit untuk keamanan yang lebih baik.
  • Tanggal dan waktu untuk aktivasi kunci (jika ditetapkan) harus di masa lalu. Tanggal dan waktu untuk kedaluwarsa (jika ditetapkan) harus di masa mendatang.
  • Kunci harus dalam keadaan Diaktifkan.
  • Jika Anda mengimpor kunci yang ada ke Key Vault, berikan dalam format file yang didukung (.pfx, , .byokatau .backup).

Pembaruan versi kunci CMK

CMK dapat dikonfigurasi dengan rotasi dan pembaruan kunci manual atau dengan pembaruan versi kunci otomatis setelah rotasi kunci manual atau otomatis di Key Vault.

Untuk detailnya, lihat Mengonfigurasi enkripsi data dengan kunci yang dikelola pelanggan selama provisi server.

Penting

Saat Memutar kunci ke versi baru, Anda harus menjaga kunci lama tetap tersedia agar reenkripsi berhasil. Meskipun sebagian besar reenkripsi harus terjadi dalam waktu 30 menit, kami sarankan Anda menunggu setidaknya 2 jam sebelum menonaktifkan akses ke versi kunci lama.

Rotasi dan pembaruan kunci manual

Saat mengonfigurasi CMK dengan pembaruan kunci manual, Anda harus memperbarui versi kunci secara manual di instans server fleksibel Azure Database for PostgreSQL setelah rotasi kunci manual atau otomatis di Key Vault. Server akan terus menggunakan versi kunci lama hingga Anda memperbaruinya. Anda menyediakan mode ini dengan menentukan URI kunci termasuk versi GUID dalam URI. Contohnya, https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Sampai saat ini ini adalah satu-satunya opsi yang tersedia.

Setiap kali Anda memutar kunci secara manual atau AKV memutar kunci secara otomatis berdasarkan kebijakan rotasinya, Anda harus memperbarui properti CMK pada instans PostgreSQL Anda. Pendekatan ini terbukti rawan kesalahan untuk operator atau memerlukan skrip kustom untuk menangani rotasi, terutama saat menggunakan fitur rotasi otomatis Key Vault.

Pembaruan versi kunci otomatis

Untuk mengaktifkan pembaruan versi kunci otomatis, gunakan URI kunci tanpa versi. Ini menghilangkan kebutuhan untuk memperbarui properti versi CMK di instans PostgreSQL Anda setelah rotasi kunci. PostgreSQL akan secara otomatis mengambil versi kunci baru dan mendekripsi ulang kunci enkripsi data. Ini adalah penyederhanaan besar dalam manajemen siklus hidup utama Anda, terutama jika dikombinasikan dengan rotasi otomatis Key Vault.

Untuk menerapkan menggunakan ARM, Bicep, Terraform, Azure PowerShell, atau Azure CLI, cukup hilangkan versi GUID dari URI kunci Anda.

Di Portal pilih kotak centang untuk memandu UI untuk menekan GUID versi selama pemilihan interaktif dan saat memvalidasi URI.

Recommendations

Saat Anda menggunakan kunci yang dikelola pelanggan untuk enkripsi data, ikuti rekomendasi berikut untuk mengonfigurasi Key Vault:

  • Untuk mencegah penghapusan sumber daya penting ini secara tidak disengaja atau tidak sah, atur kunci sumber daya pada Key Vault.
  • Aktifkan audit dan pelaporan pada semua kunci enkripsi. Key Vault menyediakan log yang mudah disuntikkan ke alat informasi keamanan dan manajemen peristiwa (SIEM) lainnya. Azure Monitor Logs adalah salah satu contoh layanan yang sudah terintegrasi.
  • Kunci Key Vault dengan memilih Nonaktifkan akses publik dan Izinkan layanan Microsoft tepercaya melewati firewall ini.
  • Aktifkan pembaruan versi kunci otomatis.

Nota

Setelah Anda memilih Nonaktifkan akses publik dan Izinkan layanan Microsoft tepercaya untuk melewati firewall ini, Anda mungkin akan mendapat kesalahan yang mirip dengan yang berikut ketika Anda mencoba menggunakan akses publik untuk mengelola Key Vault melalui portal: "Anda telah mengaktifkan kontrol akses jaringan." Hanya jaringan yang diizinkan yang memiliki akses ke brankas kunci ini." Kesalahan ini tidak menghalangi kemampuan untuk menyediakan kunci selama penyiapan kunci yang dikelola pelanggan atau mengambil kunci dari Key Vault selama operasi server.

  • Simpan salinan kunci yang dikelola pelanggan di tempat yang aman, atau escrow ke layanan escrow.
  • Jika Key Vault menghasilkan kunci, buat cadangan kunci sebelum Anda menggunakan kunci untuk pertama kalinya. Anda hanya dapat memulihkan cadangan ke Key Vault.

Pertimbangan khusus

Pencabutan akses kunci yang tidak disengaja dari Azure Key Vault

Seseorang dengan hak akses yang memadai ke Key Vault, mungkin secara tidak sengaja menonaktifkan akses server ke kunci dengan:

  • Penghapusan peran RBAC Key Vault Crypto Service Encryption User atau pencabutan izin dari identitas yang digunakan untuk mengambil kunci di Key Vault.
  • Menghapus kunci.
  • Menghapus instans Key Vault.
  • Mengubah aturan firewall Key Vault.
  • Menghapus identitas server terkelola di ID Microsoft Entra.

Memantau kunci yang disimpan di Azure Key Vault

Untuk memantau status database, dan mengaktifkan pemberitahuan untuk hilangnya akses ke pelindung enkripsi data, konfigurasikan fitur Azure berikut ini:

  • Kesehatan sumber daya: Database yang kehilangan akses ke CMK muncul sebagai Tidak Dapat Diakses setelah koneksi pertama ke database ditolak.
  • Log aktivitas: Saat akses ke CMK dalam instans Key Vault yang dikelola pelanggan gagal, entri ditambahkan ke log aktivitas. Anda dapat mengembalikan akses jika membuat pemberitahuan untuk peristiwa ini sesegera mungkin.
  • Grup tindakan: Tentukan grup ini untuk menerima pemberitahuan dan pemberitahuan berdasarkan preferensi Anda.

Memulihkan cadangan server yang dikonfigurasi dengan kunci yang dikelola pelanggan

Setelah instans server fleksibel Azure Database for PostgreSQL Anda dienkripsi dengan kunci yang dikelola pelanggan yang disimpan di Key Vault, salinan server yang baru dibuat juga dienkripsi. Anda dapat membuat salinan baru ini melalui operasi pemulihan titik waktu (PITR) atau replika baca.

Saat Anda menyiapkan enkripsi data dengan kunci yang dikelola pelanggan, selama operasi seperti pemulihan cadangan atau pembuatan replika baca, Anda dapat menghindari masalah dengan mengikuti langkah-langkah ini pada server utama dan yang dipulihkan atau replika:

  • Mulai proses pemulihan atau proses pembuatan replika baca dari instans server fleksibel Azure Database for PostgreSQL utama.
  • Di server yang dipulihkan atau replika, Anda dapat mengubah kunci yang dikelola pelanggan dan identitas terkelola yang ditetapkan pengguna yang digunakan untuk mengakses Key Vault. Pastikan bahwa identitas yang ditetapkan di server yang baru dibuat memiliki izin yang diperlukan pada Key Vault.
  • Jangan cabut kunci asli setelah memulihkan. Saat ini, kami tidak mendukung pencabutan kunci setelah Anda memulihkan server dengan kunci yang dikelola pelanggan ke server lain.

HSM Terkelola

Modul keamanan perangkat keras (HSM) adalah perangkat keras tahan perubahan yang membantu mengamankan proses kriptografi dengan menghasilkan, melindungi, dan mengelola kunci yang digunakan untuk mengenkripsi data, mendekripsi data, membuat tanda tangan digital, dan membuat sertifikat digital. HSM diuji, divalidasi, dan disertifikasi ke standar keamanan tertinggi, termasuk FIPS 140 dan Kriteria Umum.

Azure Key Vault Managed HSM adalah layanan cloud yang dikelola sepenuhnya, sangat tersedia, penyewa tunggal, dan sesuai standar. Anda dapat menggunakannya untuk melindungi kunci kriptografi untuk aplikasi cloud Anda melalui HSM yang divalidasi FIPS 140-3.

Saat Anda membuat instans server fleksibel Azure Database for PostgreSQL baru di portal Microsoft Azure dengan kunci yang dikelola pelanggan, Anda dapat memilih Azure Key Vault Managed HSM sebagai penyimpanan kunci, sebagai alternatif untuk Azure Key Vault. Prasyarat, dalam hal identitas dan izin yang ditentukan pengguna, sama dengan Azure Key Vault (seperti yang tercantum sebelumnya dalam artikel ini). Untuk informasi selengkapnya tentang cara membuat instans HSM Terkelola, keuntungan dan perbedaannya dari penyimpanan sertifikat berbasis Key Vault bersama, dan cara mengimpor kunci ke HSM Terkelola, lihat Apa itu Azure Key Vault Managed HSM?.

Kondisi kunci yang dikelola pelanggan yang tidak dapat diakses

Saat Anda mengonfigurasi enkripsi data dengan kunci yang dikelola pelanggan yang disimpan di Key Vault, akses berkelanjutan ke kunci ini diperlukan agar server tetap online. Jika bukan itu masalahnya, server mengubah statusnya menjadi Tidak Dapat Diakses dan mulai menolak semua koneksi.

Beberapa kemungkinan alasan mengapa status server mungkin menjadi Tidak Dapat Diakses adalah:

Penyebab Resolusi
Salah satu kunci enkripsi yang diarahkan oleh server memiliki tanggal dan waktu kedaluwarsa yang dikonfigurasi, dan tanggal dan waktu tersebut tercapai. Anda harus memperpanjang tanggal kedaluwarsa kunci. Kemudian Anda harus menunggu layanan untuk memvalidasi ulang kunci dan secara otomatis transisi status server ke Siap. Hanya ketika server kembali pada status Siap , Anda dapat memutar kunci ke versi yang lebih baru atau membuat kunci baru, dan memperbarui server sehingga merujuk ke versi baru kunci yang sama atau ke kunci baru.
Anda memutar kunci dan lupa memperbarui instans server fleksibel Azure Database for PostgreSQL sehingga menunjuk ke versi kunci baru. Kunci lama, tempat server menunjuk, kedaluwarsa, dan mengubah status server menjadi Tidak dapat diakses. Untuk menghindari situasi ini, setiap kali Anda memutar kunci, pastikan Anda juga memperbarui instans server Anda untuk menunjuk ke versi baru. Untuk melakukannya, Anda dapat menggunakan az postgres flexible-server update, dengan mengikuti contoh yang menjelaskan "Ubah kunci/identitas untuk enkripsi data. Enkripsi data tidak dapat diaktifkan setelah pembuatan server, ini hanya akan memperbarui kunci/identitas.". Jika Anda lebih suka memperbaruinya menggunakan API, Anda dapat memanggil Server - Memperbarui titik akhir layanan.
Anda menghapus instans Key Vault, instans server fleksibel Azure Database for PostgreSQL tidak dapat mengakses kunci dan berpindah ke status Tidak Dapat Diakses . Pulihkan instans Key Vault dan tunggu layanan menjalankan validasi ulang kunci secara berkala, dan secara otomatis transisi status server ke Siap.
Anda menghapus, dari ID Microsoft Entra, identitas terkelola yang digunakan untuk mengambil salah satu kunci enkripsi yang disimpan di Key Vault. Pulihkan identitas dan tunggu layanan menjalankan validasi ulang kunci secara berkala, dan secara otomatis transisi status server ke Siap.
Model izin Key Vault Anda dikonfigurasi untuk menggunakan kontrol akses berbasis peran. Anda menghapus penugasan peran RBAC Pengguna Enkripsi Layanan Kripto Key Vault dari identitas terkelola yang dikonfigurasikan untuk mengambil salah satu kunci. Berikan peran RBAC lagi ke identitas terkelola dan tunggu layanan menjalankan validasi ulang kunci secara berkala, dan secara otomatis transisi status server ke Siap. Pendekatan alternatif terdiri dari memberikan peran pada Key Vault ke identitas terkelola yang berbeda, dan memperbarui server sehingga menggunakan identitas terkelola lainnya ini untuk mengakses kunci.
Model izin Key Vault Anda dikonfigurasi untuk menggunakan kebijakan akses. Anda mencabut kebijakan akses daftar, dapatkan, bungkusKunci, atau bukaKunci dari identitas terkelola yang dikonfigurasi untuk mengambil salah satu kunci. Berikan peran RBAC lagi ke identitas terkelola dan tunggu layanan menjalankan validasi ulang kunci secara berkala, dan secara otomatis transisi status server ke Siap. Pendekatan alternatif terdiri dari memberikan kebijakan akses yang diperlukan pada Key Vault ke identitas terkelola yang berbeda, dan memperbarui server sehingga menggunakan identitas terkelola lainnya ini untuk mengakses kunci.
Anda menyiapkan aturan firewall Key Vault yang terlalu ketat, sehingga instans server fleksibel Azure Database for PostgreSQL Anda tidak dapat berkomunikasi dengan Key Vault untuk mengambil kunci Anda. Saat Mengonfigurasi firewall Key Vault, pastikan Anda memilih opsi untuk mengizinkan layanan Microsoft tepercaya sehingga instans server fleksibel Azure Database for PostgreSQL Anda dapat melewati firewall.

Nota

Ketika kunci dinonaktifkan, dihapus, kedaluwarsa, atau tidak dapat dijangkau, server yang memiliki data yang dienkripsi dengan kunci tersebut menjadi Tidak Dapat Diakses, seperti yang dinyatakan sebelumnya. Status server tidak berubah menjadi Siap lagi hingga dapat memvalidasi ulang kunci enkripsi.

Umumnya, server menjadi Tidak Dapat Diakses dalam waktu 60 menit setelah kunci dinonaktifkan, dihapus, kedaluwarsa, atau tidak dapat dijangkau. Setelah kunci tersedia, server mungkin membutuhkan waktu hingga 60 menit untuk menjadi Siap lagi.

Memulihkan identitas terkelola yang dihapus

Jika identitas terkelola yang ditetapkan pengguna yang digunakan untuk mengakses kunci enkripsi yang disimpan di Key Vault dihapus di ID Microsoft Entra, Anda harus mengikuti langkah-langkah berikut untuk memulihkan:

  1. Pulihkan identitas atau buat identitas ID Entra terkelola baru.
  2. Jika Anda membuat identitas baru, meskipun memiliki nama yang sama persis sebelum dihapus, perbarui Azure Database untuk properti instans server yang fleksibel sehingga tahu harus menggunakan identitas baru ini untuk mengakses kunci enkripsi.
  3. Pastikan identitas ini memiliki izin yang tepat untuk operasi pada kunci di Azure Key Vault (AKV).
  4. Tunggu sekitar satu jam hingga server memvalidasi ulang kunci.

Penting

Membuat identitas ID Entra baru dengan nama yang sama dengan identitas yang dihapus, tidak dapat memulihkan identitas terkelola yang dihapus.

Menggunakan enkripsi data dengan kunci yang dikelola pelanggan dan fitur kelangsungan bisnis geo-redundan

Azure Database for PostgreSQL mendukung fitur pemulihan data tingkat lanjut, seperti replika dan cadangan geo-redundan. Berikut ini adalah persyaratan untuk menyiapkan enkripsi data dengan CMK dan fitur-fitur ini, selain persyaratan dasar untuk enkripsi data dengan CMK:

  • Kunci enkripsi cadangan geo-redundan perlu dibuat dalam instans Key Vault yang harus ada di wilayah tempat cadangan geo-redundan disimpan.
  • Versi REST API Azure Resource Manager untuk mendukung server CMK yang mendukung cadangan geo-redundan adalah pratinjau 2022-11-01. Jika Anda ingin menggunakan templat Azure Resource Manager untuk mengotomatiskan pembuatan server yang menggunakan enkripsi dengan CMK dan fitur cadangan geo-redundan, gunakan versi API ini.
  • Anda tidak dapat menggunakan identitas yang dikelola pengguna yang sama untuk mengautentikasi instans Key Vault database utama dan instans Key Vault yang menyimpan kunci enkripsi untuk cadangan geo-redundan. Untuk menjaga ketahanan regional, kami sarankan Anda membuat identitas yang dikelola pengguna di wilayah yang sama dengan cadangan geo-redundan.
  • Jika Anda menyiapkan database replika baca untuk dienkripsi dengan CMK selama pembuatan, kunci enkripsinya harus berada dalam instans Key Vault di wilayah tempat database replika baca berada. Identitas yang ditetapkan pengguna untuk mengautentikasi terhadap instans Key Vault ini perlu dibuat di wilayah yang sama.

Keterbatasan

Ini adalah batasan saat ini untuk mengonfigurasi kunci yang dikelola pelanggan dalam instans server fleksibel Azure Database for PostgreSQL:

Konten terkait

  • Last updated on