Enkripsi data tidak aktif di server fleksibel Azure Database for PostgreSQL

Azure Database for PostgreSQL server fleksibel selalu mengenkripsi semua data saat disimpan. Data ini mencakup semua database sistem dan pengguna, log server, segmen log write-ahead, dan cadangan. Penyimpanan yang mendasar menangani enkripsi melalui enkripsi sisi server Azure Disk Storage.

Enkripsi saat tidak aktif dengan kunci terkelola 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 server fleksibel Azure Database for PostgreSQL Anda.

Anda hanya dapat memilih mode pada waktu pembuatan server. Anda tidak dapat mengubah mode dari satu 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, Anda bertanggung jawab untuk menyediakan kunci untuk mengenkripsi dan mendekripsi data dalam layanan Blob Storage dan Azure Files. Anda harus menyimpan kunci ini di Azure Key Vault atau Azure Key Vault Managed Hardware Security Module (HSM). 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 manajemen kunci enkripsi (termasuk rotasi reguler mereka) dan manajemen 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

Saat Anda menggunakan kunci enkripsi yang dikelola pelanggan, Anda bertanggung jawab. Anda harus menerapkan 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 server fleksibel Azure Database for PostgreSQL Anda dapat melakukan tindakan yang diperlukan pada kunci. Anda harus mengonfigurasi semua aspek jaringan Azure Key Vault tempat kunci disimpan, sehingga server fleksibel Azure Database for PostgreSQL Anda dapat mengakses kunci. Tanggung jawab Anda juga mencakup mengaudit akses ke kunci. Terakhir, Anda bertanggung jawab untuk merotasi kunci dan, jika diperlukan, memperbarui konfigurasi Azure Database for PostgreSQL flexible server Anda agar merujuk ke versi kunci yang telah dirotasi.

Saat Anda mengonfigurasi kunci yang dikelola pelanggan untuk akun penyimpanan, Azure Storage mengenkripsi kunci enkripsi data utama (DEK) akun tersebut dengan kunci yang dikelola pelanggan dalam key vault 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.

Daftar berikut menjelaskan persyaratan untuk mengonfigurasi enkripsi data untuk Azure Database for PostgreSQL:

• Untuk konfigurasi CMK penyewa tunggal, Key Vault dan server fleksibel Azure Database for PostgreSQL Anda harus termasuk dalam penyewa Microsoft Entra yang sama. Untuk skenario lintas penyewa, lihat Kunci yang dikelola pelanggan lintas penyewa. Memindahkan sumber daya Key Vault setelah itu memerlukan konfigurasi ulang enkripsi data.
• Atur konfigurasi Hari untuk menyimpan vault yang dihapus untuk Key Vault menjadi 90 hari. Jika Anda mengonfigurasi instans Key Vault yang ada dengan angka yang lebih rendah, instans tersebut tetap valid. Namun, jika Anda ingin mengubah pengaturan ini dan meningkatkan nilainya, Anda harus membuat instans Key Vault baru. Setelah instans dibuat, Anda tidak dapat mengubah pengaturan ini.
• Aktifkan fitur yang dihapus sementara di Key Vault untuk membantu melindungi dari kehilangan data jika kunci atau instans Key Vault dihapus secara tidak sengaja. Key Vault mempertahankan sumber daya yang dihapus secara lunak selama 90 hari kecuali pengguna memulihkan atau menghapusnya secara permanen sebelum itu. Tindakan pemulihan dan pembersihan memiliki izin tersendiri yang terkait dengan Key Vault, peran RBAC, atau izin kebijakan akses. Fitur penghapusan lunak secara otomatis diaktifkan. Jika Anda memiliki sebagian Key Vault yang sudah diterapkan sejak lama, soft-delete mungkin masih dinonaktifkan. Dalam hal ini, Anda dapat mengaktifkannya dengan menggunakan Azure CLI.
• Aktifkan proteksi penghapusan permanen untuk menerapkan periode retensi wajib bagi vault yang dihapus dan objek di dalamnya.
• Berikan akses ke kunci untuk identitas terkelola yang ditetapkan pengguna pada server fleksibel Azure Database for PostgreSQL dengan:
• Pilihan: Konfigurasikan Azure Key Vault dengan model izin RBAC dan tetapkan identitas terkelola 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. 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

Anda dapat mengonfigurasi CMK untuk rotasi dan pembaruan kunci manual, atau untuk pembaruan versi kunci otomatis setelah rotasi kunci manual atau otomatis di Key Vault.

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

Rotasi dan pembaruan kunci manual

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

Setiap kali Anda memutar kunci secara manual atau AKV secara otomatis merotasi kunci berdasarkan kebijakan rotasinya, Anda harus memperbarui properti CMK di server 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. Pendekatan ini menghilangkan kebutuhan untuk memperbarui properti versi CMK di server PostgreSQL Anda setelah rotasi kunci. PostgreSQL secara otomatis mengambil versi kunci baru dan mendekripsi ulang kunci enkripsi data. Pendekatan ini secara signifikan menyederhanakan manajemen siklus hidup utama Anda, terutama jika dikombinasikan dengan autorotasi Key Vault.

Untuk menerapkan pendekatan ini dengan menggunakan Azure Resource Manager, Bicep, Terraform, Azure PowerShell, atau Azure CLI, hilangkan versi GUID dari URI kunci Anda.

Di portal, pilih kotak centang untuk mengarahkan UI agar menyembunyikan 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:

• Atur kunci sumber daya pada Key Vault untuk mencegah penghapusan sumber daya penting yang tidak disengaja atau tidak sah ini.
• 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.

• Simpan salinan kunci yang dikelola pelanggan di tempat yang aman, atau titipkan salinan tersebut 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 untuk 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:

• 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 Anda mengenkripsi server fleksibel Azure Database for PostgreSQL Anda 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 ke titik waktu tertentu (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 server fleksibel utama Azure Database for PostgreSQL.
• 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, pencabutan kunci tidak didukung setelah Anda memulihkan server yang menggunakan kunci yang dikelola pelanggan ke server yang lain.

Modul Keamanan Perangkat Keras (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, memiliki ketersediaan tinggi, untuk satu penyewa, dan sesuai standar. Anda dapat menggunakannya untuk melindungi kunci kriptografi untuk aplikasi cloud Anda melalui HSM yang divalidasi FIPS 140-3.

Saat Anda membuat server fleksibel Azure Database for PostgreSQL baru di portal Azure dengan kunci yang dikelola pelanggan, Anda dapat memilih Azure Key Vault Managed HSM sebagai penyimpanan kunci, sebagai alternatif dari 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 tidak dapat diakses

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

Beberapa kemungkinan alasan status server menjadi Tidak Dapat Diakses meliputi:

Memulihkan identitas terkelola yang terhapus

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

1. Pulihkan identitas atau buat identitas ID Entra terkelola baru.
2. Jika Anda membuat identitas baru, bahkan jika memiliki nama yang sama persis dengan identitas yang dihapus, perbarui database Azure untuk properti server 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.

Gunakan enkripsi data dengan kunci yang dikelola pelanggan dan fitur keberlangsungan bisnis geo-redundan

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

• Anda perlu membuat kunci enkripsi cadangan geo-redundan dalam instans Key Vault yang harus ada di wilayah tempat cadangan geo-redundan disimpan.
• Versi Azure Resource Manager REST API untuk mendukung server CMK dengan pencadangan geo-redundan yang diaktifkan adalah 2022-11-01-preview. 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, buat 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. Anda perlu membuat identitas yang ditetapkan pengguna untuk mengautentikasi terhadap instans Key Vault ini di wilayah yang sama.

Kunci yang dikelola pelanggan lintas penyewa (CMK) (pratinjau)

Kunci yang dikelola pelanggan antar-tenant memungkinkan Anda menggunakan kunci enkripsi yang disimpan di Key Vault atau instans Managed HSM yang berada di bawah Microsoft Entra ID yang berbeda dari Azure Database for PostgreSQL Flexible Server Anda. Penyiapan CMK lintas penyewa memerlukan konfigurasi dan koordinasi tambahan antar penyewa. Dalam skenario lintas penyewa, sumber daya Azure Database for PostgreSQL berada di penyewa yang dikelola oleh Vendor Perangkat Lunak Independen (ISV) yang disebut sebagai penyedia layanan. Kunci yang digunakan untuk enkripsi sumber daya Azure Database for PostgreSQL berada di brankas kunci di penyewa lain yang dikelola pelanggan.

Gambaran umum penyiapan

Pada tenant ISV

• Membuat aplikasi multipenyewa

  • Mengonfigurasi identitas terkelola yang ditetapkan pengguna sebagai kredensial federasi pada aplikasi

Pada penyewa klien

1. Menginstal aplikasi multipenyewa

2. Buat atau gunakan key vault atau HSM terkelola yang sudah ada dan berikan izin kunci kepada aplikasi multitenan

   1. Membuat baru atau menggunakan kunci yang sudah ada

   2. Ambil kunci dari Azure Key Vault atau Azure Managed HSM dan rekam Pengidentifikasi Kunci

Pada tenant ISV

Hingga saat ini, Anda mengonfigurasi aplikasi multipenyewa pada penyewa penyedia layanan. Anda juga menginstal aplikasi pada penyewa pelanggan dan mengonfigurasi brankas kunci dan kunci pada penyewa pelanggan. Selanjutnya, Anda dapat membuat server Azure Database for PostgreSQL pada tenant penyedia layanan dan mengonfigurasi kunci yang dikelola pelanggan menggunakan kunci dari tenant pelanggan.

Saat Anda membuat server Azure Database for PostgreSQL dengan kunci yang dikelola pelanggan, Anda harus memastikan bahwa server tersebut memiliki akses ke kunci yang digunakan pelanggan. Dalam skenario penyewa tunggal, Anda memberikan akses langsung ke Key Vault kepada identitas terkelola pengguna dari server Azure Database for PostgreSQL. Dalam skenario lintas tenant, Anda tidak lagi dapat mengandalkan akses langsung ke Key Vault karena berada di tenant lain yang dikelola oleh pelanggan. Batasan ini adalah alasan Anda membuat aplikasi lintas penyewa dan mendaftarkan identitas terkelola dalam aplikasi tersebut agar identitas tersebut dapat mengakses brankas kunci pelanggan pada bagian sebelumnya. Identitas terkelola ini, bersama dengan ID aplikasi lintas penyewa, digunakan saat Anda membuat CMK lintas penyewa untuk server Azure Database for PostgreSQL.

Setiap kali versi baru kunci tersedia di brankas kunci, server Azure Database for PostgreSQL secara otomatis mengambil versi baru.

Menggunakan portal Microsoft Azure

Untuk mengonfigurasi kunci yang dikelola pelanggan lintas penyewa untuk server Azure Database for PostgreSQL yang baru di portal Azure, ikuti langkah-langkah berikut:

1. Di Azure Database for PostgreSQL buat sumber daya, pilih tab Keamanan di portal Azure, lalu pilih kunci yang dikelola Kustomer.

2. Tetapkan identitas terkelola yang ditetapkan pengguna yang dibuat sebagai Identitas terkelola yang ditetapkan pengguna.

3. Tetapkan aplikasi multitenant menggunakan nama aplikasi.

4. Masukkan Pengidentifikasi Kunci di metode Pemilihan Kunci dengan menggunakan Pengidentifikasi Kunci milik pelanggan yang diperoleh dari tenant klien.

Menggunakan templat JSON Azure Resource Manager dan REST API

Sebarkan templat ARM dengan parameter tertentu berikut:

Berikut adalah contoh REST API dengan tiga parameter yang dikonfigurasi:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Contoh isi permintaan:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Berikut adalah contoh REST API untuk rotasi kunci. Contoh PATCH hanya memperbarui URI kunci CMK untuk memutar kunci enkripsi tanpa membuat ulang server.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Isi permintaan (contoh kunci putar):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Batasan pratinjau kunci yang dikelola pelanggan (CMK) lintas penyewa

• Azure PowerShell dan Azure CLI belum mendukung fitur ini.
• Pembuatan server dengan cadangan geo-redundan dan pengaktifan operasi cadangan retensi jangka panjang saat ini tidak didukung.
• Pratinjau ini saat ini hanya didukung di wilayah berikut:
  • US Timur 2
  • Barat AS 2
  • US Tengah
  • Australia Tenggara
  • Australia Timur
  • Eropa Utara

Batasan kunci yang dikelola pelanggan (CMK)

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

• Anda dapat mengonfigurasi enkripsi kunci yang dikelola pelanggan hanya selama pembuatan server baru, bukan sebagai pembaruan ke server fleksibel Azure Database for PostgreSQL yang ada. Sebagai gantinya, Anda dapat memulihkan cadangan PITR ke server baru dengan enkripsi CMK.
• Setelah mengonfigurasi enkripsi kunci yang dikelola pelanggan, Anda tidak dapat kembali ke kunci yang dikelola sistem. Jika ingin kembali, Anda harus memulihkan server ke server baru dengan enkripsi data yang dikonfigurasi dengan kunci yang dikelola sistem.
• Instans Azure Key Vault Managed HSM atau instans Azure Key Vault tempat Anda berencana untuk menyimpan kunci enkripsi harus ada di wilayah yang sama tempat Anda membuat Database Azure untuk server fleksibel.

Konten terkait

• Mengonfigurasi enkripsi data di Azure Database for PostgreSQL