Bagikan melalui

Enkripsi data transparan Azure SQL dengan kunci yang dikelola pelanggan

Berlaku untuk:Azure SQL Database Azure SQL Managed InstanceAzure Synapse Analytics (hanya kumpulan SQL khusus)

Enkripsi data transparan (TDE) di Azure SQL dengan kunci yang dikelola pelanggan (CMK) memungkinkan skenario Bring Your Own Key (BYOK) untuk perlindungan data tidak aktif, dan memungkinkan organisasi menerapkan pemisahan tugas dalam pengelolaan kunci dan data. Dengan TDE yang dikelola pelanggan, pelanggan bertanggung jawab atas dan memiliki kontrol penuh atas manajemen siklus hidup kunci (pembuatan kunci, pengunggahan, rotasi, penghapusan), izin penggunaan kunci, dan audit operasi pada kunci.

Dalam skenario ini, pelindung Enkripsi Data Transparan (TDE) —kunci asimetris yang dikelola pelanggan yang digunakan untuk mengamankan Kunci Enkripsi Database (DEK)—disimpan di Azure Key Vault atau Azure Key Vault Managed HSM. Ini adalah layanan manajemen kunci berbasis cloud yang aman yang dirancang untuk ketersediaan dan skalabilitas tinggi. Azure Key Vault mendukung kunci RSA dan dapat didukung oleh HSM tervalidasi FIPS 140-2 Level 2. Untuk pelanggan yang membutuhkan jaminan yang lebih tinggi, Azure Key Vault Managed HSM menawarkan perangkat keras tervalidasi FIPS 140-2 Level 3. Kunci dapat dihasilkan dalam layanan, diimpor, atau ditransfer dengan aman dari HSM lokal. Akses langsung ke kunci dibatasi—layanan yang berwenang melakukan operasi kriptografi tanpa mengekspos material kunci.

Untuk Azure SQL Database dan Azure Synapse Analytics, pelindung TDE diatur di tingkat server dan diwarisi oleh semua database terenkripsi yang terkait dengan server tersebut. Untuk Azure SQL Managed Instance, pelindung TDE diatur pada tingkat instans dan diwarisi oleh semua database terenkripsi pada instans tersebut. Istilah server mengacu pada server di SQL Database dan Azure Synapse dan ke instans terkelola di SQL Managed Instance di seluruh artikel ini, kecuali dinyatakan berbeda.

Mengelola pelindung TDE di tingkat database di Azure SQL Database tersedia. Untuk informasi selengkapnya, lihat Enkripsi data transparan (TDE) dengan kunci yang dikelola pelanggan di tingkat database.

Nota

Artikel ini berlaku untuk Azure SQL Database, Azure SQL Managed Instance, dan Azure Synapse Analytics (kumpulan SQL khusus (sebelumnya SQL DW)). Untuk informasi selengkapnya tentang enkripsi data transparan untuk kumpulan SQL khusus di dalam ruang kerja Synapse, lihat Enkripsi Azure Synapse Analytics.

Nota

MICROSOFT Entra ID sebelumnya dikenal sebagai Azure Active Directory (Azure AD).

Kunci yang Dikelola Pelanggan (CMK) dan Bring Your Own Key (BYOK)

Dalam artikel ini, istilah Customer Managed Key (CMK) dan Bring Your Own Key (BYOK) digunakan secara bergantian, tetapi mewakili beberapa perbedaan.

  • Customer Managed Key (CMK) - Pelanggan mengelola siklus hidup utama, termasuk pembuatan kunci, rotasi, dan penghapusan. Kunci disimpan di Azure Key Vault atau Azure Managed HSM dan digunakan untuk enkripsi Kunci Enkripsi Database (DEK) di Azure SQL, SQL Server di Azure VM, dan SQL Server lokal.

  • Bring Your Own Key (BYOK) - Pelanggan dengan aman membawa atau mengimpor kunci mereka sendiri dari modul keamanan perangkat keras (HSM) lokal ke Azure Key Vault atau Azure Managed HSM. Kunci yang diimpor tersebut dapat digunakan sebagai kunci lain di Azure Key Vault, termasuk sebagai Kunci yang Dikelola Pelanggan untuk enkripsi DEK. Untuk informasi selengkapnya, lihat Mengimpor kunci yang dilindungi HSM ke Managed HSM (BYOK).

Manfaat TDE yang dikelola pelanggan

TDE yang dikelola pelanggan memberikan manfaat berikut kepada pelanggan:

  • Kontrol penuh dan terperinci atas penggunaan dan manajemen pelindung TDE.

  • Transparansi penggunaan pelindung TDE.

  • Kemampuan untuk menerapkan pemisahan tugas dalam pengelolaan kunci dan data dalam organisasi.

  • Administrator Azure Key Vault dapat mencabut izin akses kunci untuk membuat database terenkripsi tidak dapat diakses.

  • Manajemen pusat kunci di Azure Key Vault.

  • Kepercayaan yang lebih besar dari pelanggan akhir Anda, karena Azure Key Vault dirancang sed sehingga Microsoft tidak dapat melihat atau mengekstrak kunci enkripsi.

Penting

Bagi mereka yang menggunakan TDE yang dikelola layanan yang ingin mulai menggunakan TDE yang dikelola pelanggan, data tetap dienkripsi selama proses pengalihan, dan tidak ada waktu henti atau enkripsi ulang file database. Beralih dari kunci yang dikelola layanan ke kunci yang dikelola pelanggan hanya memerlukan enkripsi ulang DEK, yang merupakan operasi cepat dan online.

Izin untuk mengonfigurasi TDE yang dikelola pelanggan

Diagram memperlihatkan penyiapan dan fungsi TDE yang dikelola pelanggan.

Pilih jenis Azure Key Vault yang ingin Anda gunakan.

Agar server logis di Azure menggunakan pelindung TDE yang disimpan di Azure Key Vault untuk enkripsi DEK, Administrator Key Vault perlu memberikan hak akses ke server menggunakan identitas Microsoft Entra yang unik. Identitas server dapat berupa identitas terkelola yang ditetapkan oleh sistem atau identitas terkelola yang ditetapkan oleh pengguna ke server. Ada dua model akses untuk memberikan akses server ke brankas kunci:

  • Kontrol akses berbasis peran Azure (RBAC) - Gunakan Azure RBAC untuk memberikan akses pengguna, grup, atau aplikasi ke brankas kunci. Metode ini direkomendasikan karena fleksibilitas dan granularitasnya. Peran Pengguna Enkripsi Layanan Kripto Key Vault diperlukan oleh identitas server untuk dapat menggunakan kunci untuk operasi enkripsi dan dekripsi.

  • Kebijakan akses vault - Gunakan kebijakan akses brankas kunci untuk memberikan akses server ke brankas kunci. Metode ini lebih sederhana dan lebih mudah, tetapi kurang fleksibel. Identitas server harus memiliki izin berikut pada brankas kunci:

    • get - untuk memperoleh bagian publik dan properti kunci di Azure Key Vault
    • wrapKey - untuk dapat melindungi (mengenkripsi) DEK
    • unwrapKey - untuk dapat membuka proteksi (dekripsi) DEK

Di menu portal Microsoft Azure Konfigurasi akses dari brankas kunci, Anda memiliki opsi untuk memilih kontrol akses berbasis peran Azure atau kebijakan akses Vault. Untuk instruksi langkah demi langkah tentang menyiapkan konfigurasi akses Azure Key Vault untuk TDE, lihat Menyiapkan SQL Server TDE Extensible Key Management dengan menggunakan Azure Key Vault. Untuk informasi selengkapnya tentang model akses, lihat Keamanan Azure Key Vault.

Administrator Key Vault juga dapat mengaktifkan pengelogan peristiwa audit brankas kunci, sehingga dapat diaudit nanti.

Saat server dikonfigurasi untuk menggunakan pelindung TDE dari Azure Key Vault, server mengirim DEK dari setiap database berkemampuan TDE ke brankas kunci untuk enkripsi. Brankas kunci mengembalikan DEK terenkripsi, yang kemudian disimpan dalam database pengguna.

Jika diperlukan, server mengirim DEK yang dilindungi ke brankas kunci untuk dekripsi.

Auditor dapat menggunakan Azure Monitor untuk meninjau log AuditEvent key vault, jika pencatatan diaktifkan.

Nota

Mungkin perlu waktu sekitar 10 menit agar perubahan izin berlaku untuk brankas kunci. Ini termasuk mencabut izin akses ke pelindung TDE di AKV, dan pengguna dalam jangka waktu ini mungkin masih memiliki izin akses.

Persyaratan untuk mengonfigurasi TDE yang dikelola pelanggan

  • Fitur perlindungan penghapusan sementara dan penghapusan menyeluruh harus diaktifkan pada Azure Key Vault. Ini membantu mencegah skenario brankas kunci atau penghapusan kunci yang tidak disengaja atau berbahaya yang dapat menyebabkan database masuk ke status Tidak Dapat Diakses . Saat mengonfigurasi pelindung TDE di server yang ada atau selama pembuatan server, Azure SQL memvalidasi bahwa brankas kunci yang digunakan telah mengaktifkan penghapusan sementara dan perlindungan pembersihan total. Jika perlindungan penghapusan sementara dan penghapusan menyeluruh tidak diaktifkan pada brankas kunci, penyiapan pelindung TDE gagal dengan kesalahan. Dalam hal ini, perlindungan penghapusan sementara dan penghapusan menyeluruh harus terlebih dahulu diaktifkan pada brankas kunci dan kemudian penyiapan pelindung TDE harus dilakukan.

  • Saat menggunakan firewall dengan Azure Key Vault, Anda harus mengaktifkan opsi Izinkan layanan Microsoft tepercaya untuk melewati firewall, kecuali Anda menggunakan titik akhir privat untuk Azure Key Vault. Untuk informasi selengkapnya, lihat Mengonfigurasi firewall dan jaringan virtual di Azure Key Vault.

Persyaratan untuk mengonfigurasi pelindung TDE

  • Pelindung TDE hanya dapat berupa kunci asimetris, RSA, atau RSA HSM. Panjang kunci yang didukung adalah 2.048 bit dan 3.072 bit.

  • Tanggal aktivasi kunci (jika ditetapkan) harus berupa tanggal dan waktu di masa lalu. Tanggal kedaluwarsa (jika ditetapkan) harus merupakan tanggal dan waktu mendatang.

  • Kunci harus dalam status Aktfkan.

  • Jika Anda mengimpor kunci yang ada ke brankas kunci, pastikan kunci tersebut disediakan dalam salah satu format file yang didukung: .pfx, , .byokatau .backup. Untuk mengimpor kunci yang dilindungi HSM ke Azure Managed HSM, lihat Mengimpor kunci yang dilindungi HSM ke Managed HSM (BYOK).

Nota

Masalah dengan versi Thales CipherTrust Manager sebelum v2.8.0 mencegah kunci yang baru diimpor ke Azure Key Vault digunakan dengan Azure SQL Database atau Azure SQL Managed Instance untuk skenario TDE yang dikelola oleh pelanggan. Detail selengkapnya tentang masalah ini dapat ditemukan di sini. Untuk kasus seperti itu, tunggu 24 jam setelah mengimpor kunci ke Azure Key Vault untuk mulai menggunakannya sebagai pelindung TDE untuk server atau instans terkelola. Masalah ini diselesaikan di Thales CipherTrust Manager v2.8.0.

Rekomendasi saat mengonfigurasi TDE yang dikelola pelanggan

  • Untuk memastikan performa dan keandalan yang optimal, sangat disarankan untuk menggunakan Azure Key Vault khusus untuk Azure SQL. Key vault ini tidak boleh dibagikan dengan layanan lain. Jika brankas kunci berada di bawah beban berat, karena penggunaan bersama atau operasi kunci yang berlebihan, itu dapat berdampak negatif pada performa database, terutama selama akses kunci enkripsi. Azure Key Vault menerapkan batas pengendalian. Ketika batas ini terlampaui, operasi mungkin tertunda atau gagal. Ini sangat penting selama failover server, yang memicu operasi kunci untuk setiap database di server.

    Untuk informasi selengkapnya tentang perilaku pembatasan, lihat Panduan pembatasan Azure Key Vault.

    Untuk mempertahankan ketersediaan tinggi dan menghindari masalah pembatasan, ikuti panduan ini per langganan:

    • Gunakan Azure Key Vault khusus untuk sumber daya Azure SQL.

    • Kaitkan tidak lebih dari 500 database Tujuan Umum dengan satu Azure Key Vault.

    • Kaitkan tidak lebih dari 200 database Business Critical dengan satu Azure Key Vault.

    • Jumlah database Hyperscale yang dapat dikaitkan dengan satu Azure Key Vault ditentukan oleh jumlah server halaman. Setiap server halaman ditautkan ke file data logis. Untuk menemukan jumlah server halaman, jalankan kueri berikut.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Jangan kaitkan lebih dari 500 server halaman dengan satu Azure Key Vault. Seiring bertambahnya database, jumlah server halaman meningkat secara otomatis, jadi penting untuk memantau ukuran database secara teratur. Jika jumlah server halaman melebihi 500, gunakan Azure Key Vault khusus untuk setiap database Hyperscale yang tidak dibagikan dengan sumber daya Azure SQL lainnya.

    • Memantau dan mengonfigurasi alert Azure Key Vault. Untuk informasi selengkapnya tentang pemantauan dan pemberitahuan, lihat Memantau Azure Key Vault dan Mengonfigurasi pemberitahuan Azure Key Vault.

  • Atur kunci sumber daya pada brankas kunci untuk mengontrol siapa yang dapat menghapus sumber daya penting ini dan mencegah penghapusan yang tidak disengaja atau tidak sah. Pelajari selengkapnya tentang kunci sumber daya.

  • Aktifkan audit dan pelaporan pada semua kunci enkripsi: Azure Key Vault menyediakan log yang mudah disuntikkan ke informasi keamanan dan alat manajemen peristiwa lainnya. Operations Management Suite Log Analytics adalah salah satu contoh layanan yang sudah terintegrasi.

  • Gunakan brankas kunci dari wilayah Azure yang dapat mereplikasi kontennya ke wilayah berpasangan untuk ketersediaan maksimum. Untuk informasi selengkapnya, lihat praktik terbaik untuk menggunakan Azure Key Vault dan ketersediaan dan redundansi Azure Key Vault.

Nota

Untuk memungkinkan fleksibilitas yang lebih besar dalam mengonfigurasi TDE yang dikelola pelanggan, Azure SQL Database dan Azure SQL Managed Instance di satu wilayah sekarang dapat ditautkan ke Azure Key Vault di wilayah lain. Server dan brankas kunci tidak harus dikolokasikan di wilayah yang sama.

Rekomendasi saat mengonfigurasi pelindung TDE

  • Simpan salinan pelindung TDE di tempat yang aman atau simpan di layanan penjaminan.

  • Jika kunci dihasilkan di brankas kunci, buat cadangan kunci sebelum menggunakan kunci di Azure Key Vault untuk pertama kalinya. Pencadangan hanya dapat dipulihkan ke Azure Key Vault. Pelajari selengkapnya tentang perintah Backup-AzKeyVaultKey . Azure Managed HSM mendukung pembuatan cadangan penuh seluruh konten HSM termasuk semua kunci, versi, atribut, tag, dan penetapan peran. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan penuh dan pemulihan kunci selektif.

  • Buat cadangan baru setiap kali perubahan dilakukan pada kunci (misalnya, atribut kunci, tag, ACL).

  • Pertahankan versi kunci sebelumnya di brankas kunci atau HSM Terkelola saat memutar kunci, sehingga cadangan database yang lebih lama dapat dipulihkan. Ketika pelindung TDE diubah untuk database, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru. Pada waktu pemulihan, setiap cadangan membutuhkan pelindung TDE yang dienkripsi pada waktu pembuatan. Rotasi kunci dapat dilakukan mengikuti instruksi dalam artikel Memutar pelindung Enkripsi data transparan (TDE).

  • Simpan semua kunci yang digunakan sebelumnya di Azure Key Vault atau Azure Managed HSM bahkan setelah beralih ke kunci yang dikelola layanan. Ini memastikan cadangan database dapat dipulihkan dengan pelindung TDE yang disimpan di Azure Key Vault atau Azure Managed HSM. Pelindung TDE yang dibuat dengan Azure Key Vault atau Azure Managed HSM harus dipertahankan hingga semua cadangan tersimpan yang tersisa telah dibuat dengan kunci yang dikelola layanan. Buat salinan cadangan yang dapat dipulihkan dari kunci ini menggunakan Backup-AzKeyVaultKey.

  • Untuk menghapus kunci yang berpotensi disusupi selama insiden keamanan tanpa risiko kehilangan data, ikuti langkah-langkah dalam artikel Menghapus pelindung Enkripsi Data Transparan (TDE) menggunakan PowerShell.

Rotasi pelindung TDE

Memutar pelindung TDE untuk server berarti beralih ke kunci asimetris baru yang melindungi database di server. Rotasi kunci adalah operasi online dan hanya perlu beberapa detik untuk diselesaikan. Operasi ini hanya mendekripsi dan mengenkripsi ulang kunci enkripsi database, bukan seluruh database.

Rotasi pelindung TDE dapat dilakukan secara manual atau dengan menggunakan fitur rotasi otomatis.

Rotasi otomatis pelindung TDE dapat diaktifkan saat mengonfigurasi pelindung TDE untuk server. Rotasi otomatis dinonaktifkan secara default. Saat diaktifkan, server terus memeriksa gudang kunci atau HSM Terkelola untuk semua versi baru dari kunci yang digunakan sebagai pelindung TDE. Jika versi baru kunci terdeteksi, pelindung TDE di server atau database secara otomatis diputar ke versi kunci terbaru dalam waktu 24 jam.

Saat digunakan dengan rotasi kunci otomatis di Azure Key Vault atau autorotasi di Azure Managed HSM, fitur ini memungkinkan rotasi tanpa sentuh dari awal hingga akhir untuk protektor TDE di Azure SQL Database, dan Azure SQL Managed Instance.

Nota

Mengatur TDE dengan CMK menggunakan rotasi kunci manual atau otomatis selalu menggunakan versi terbaru kunci yang didukung. Pengaturan tidak memungkinkan penggunaan versi kunci sebelumnya atau yang lebih rendah. Selalu gunakan versi kunci terbaru sesuai dengan kebijakan keamanan Azure SQL yang melarang versi kunci sebelumnya yang mungkin disusupi. Versi kunci sebelumnya mungkin diperlukan untuk tujuan pencadangan atau pemulihan database, terutama untuk cadangan retensi jangka panjang, di mana versi kunci yang lebih lama harus dipertahankan. Untuk penyiapan replikasi geografis, semua kunci yang diperlukan oleh server sumber perlu ada di server target.

Pertimbangan replikasi geografis saat mengonfigurasi rotasi otomatis pelindung TDE

Untuk menghindari masalah saat membuat atau selama replikasi geografis, ketika rotasi otomatis pelindung TDE diaktifkan di server utama atau sekunder, penting untuk mengikuti aturan ini saat mengonfigurasi replikasi geografis:

  • Server utama dan sekunder harus memiliki izin Get, wrapKey , dan unwrapKey ke brankas kunci server utama (brankas kunci yang menyimpan kunci pelindung TDE server utama).

  • Untuk server dengan rotasi kunci otomatis diaktifkan, sebelum memulai replikasi geografis, tambahkan kunci enkripsi yang digunakan sebagai pelindung TDE di server utama ke server sekunder. Server sekunder memerlukan akses ke kunci di brankas kunci yang sama atau HSM terkelola yang digunakan dengan server utama (dan bukan kunci lain dengan materi kunci yang sama). Atau, sebelum memulai replikasi geografis, pastikan bahwa identitas terkelola server sekunder (ditetapkan pengguna atau ditetapkan sistem) memiliki izin yang diperlukan pada brankas kunci server utama atau HSM terkelola, dan sistem mencoba menambahkan kunci ke server sekunder.

  • Untuk penyiapan replikasi geografis yang ada, sebelum mengaktifkan rotasi kunci otomatis di server utama, tambahkan kunci enkripsi yang digunakan sebagai pelindung TDE di server utama ke server sekunder. Server sekunder memerlukan akses ke kunci di brankas kunci yang sama atau HSM terkelola yang digunakan dengan server utama (dan bukan kunci lain dengan materi kunci yang sama). Atau, sebelum mengaktifkan kunci otomatis, pastikan bahwa identitas terkelola server sekunder (ditetapkan pengguna atau ditetapkan sistem) memiliki izin yang diperlukan pada brankas kunci server utama, dan sistem mencoba menambahkan kunci ke server sekunder.

  • Skenario replikasi geografis menggunakan kunci yang dikelola pelanggan (CMK) untuk TDE didukung. TDE dengan rotasi kunci otomatis harus dikonfigurasi di semua server jika Anda mengonfigurasi TDE di portal Microsoft Azure. Untuk informasi selengkapnya tentang menyiapkan rotasi kunci otomatis untuk konfigurasi replikasi geografis dengan TDE, lihat Rotasi kunci otomatis untuk konfigurasi replikasi geografis.

Pelindung TDE tidak dapat diakses

Ketika TDE dikonfigurasi untuk menggunakan kunci yang dikelola pelanggan, akses berkelanjutan ke pelindung TDE diperlukan agar database tetap online. Jika server kehilangan akses ke pelindung TDE yang dikelola pelanggan di Azure Key Vault atau Azure Managed HSM, dalam waktu hingga 10 menit database mulai menolak semua koneksi dengan pesan kesalahan yang sesuai dan mengubah statusnya menjadi Tidak Dapat Diakses. Satu-satunya tindakan yang diizinkan pada database dalam status Tidak Dapat Diakses adalah menghapusnya.

Status tidak dapat diakses

Jika database tidak dapat diakses karena pemadaman jaringan terputus-terputus (seperti kesalahan 5XX), tidak ada tindakan yang diperlukan, karena database kembali online secara otomatis. Untuk mengurangi efek kesalahan jaringan atau pemadaman saat mengakses pelindung TDE di Azure Key Vault atau Azure Managed HSM, buffer 24 jam diperkenalkan sebelum layanan mencoba memindahkan database ke status yang tidak dapat diakses. Jika failover terjadi sebelum mencapai status tidak dapat diakses, database menjadi tidak tersedia karena hilangnya cache enkripsi.

Jika server kehilangan akses ke pelindung TDE yang dikelola pelanggan di Azure Key Vault atau Azure Managed HSM karena kesalahan Azure Key Vault (seperti kesalahan 4XX), database dipindahkan ke status yang tidak dapat diakses setelah 30 menit.

Memulihkan akses database setelah kesalahan Azure Key Vault atau Azure Managed HSM

Setelah akses ke kunci dipulihkan, membawa database kembali online memerlukan waktu dan langkah tambahan, yang mungkin bervariasi berdasarkan durasi tidak tersedianya kunci dan ukuran data dalam database.

Jika akses kunci dipulihkan dalam waktu 30 menit, database akan dipulihkan secara otomatis dalam satu jam berikutnya. Namun, jika akses kunci dipulihkan setelah lebih dari 30 menit, penyembuhan otomatis database tidak dimungkinkan. Dalam kasus seperti itu, memulihkan database melibatkan prosedur tambahan melalui portal Microsoft Azure dan dapat memakan waktu, tergantung pada ukuran database.

Setelah database kembali online, pengaturan tingkat server yang dikonfigurasi sebelumnya, termasuk konfigurasi grup failover, tag, dan pengaturan tingkat database seperti konfigurasi kumpulan elastis, skala baca, jeda otomatis, riwayat pemulihan titik waktu, kebijakan penyimpanan jangka panjang, dan lainnya hilang. Oleh karena itu, disarankan agar pelanggan menerapkan sistem pemberitahuan untuk mendeteksi hilangnya akses kunci enkripsi dalam waktu 30 menit. Setelah jendela 30 menit kedaluwarsa, kami menyarankan untuk memvalidasi semua pengaturan tingkat server dan database pada database yang dipulihkan.

Berikut ini adalah tampilan langkah-langkah tambahan yang diperlukan di portal untuk membawa database yang tidak dapat diakses kembali online.

Cuplikan layar database TDE BYOK yang tidak dapat diakses.

Pencabutan akses pelindung TDE yang tidak disengaja

Mungkin saja seseorang yang memiliki akses memadai ke brankas kunci atau HSM terkelola secara tidak sengaja menonaktifkan akses server ke kunci dengan:

  • mencabut izin get, wrapKey, unwrapKey dari key vault atau HSM terkelola dari server

  • menghapus kunci

  • menghapus key vault atau HSM (Hardware Security Module) terkelola

  • mengubah aturan firewall key vault atau HSM terkelola

  • menghapus identitas server terkelola di ID Microsoft Entra

Pelajari selengkapnya tentang penyebab umum database menjadi tidak dapat diakses.

Konektivitas yang diblokir antara SQL Managed Instance dan Azure Key Vault atau Azure Managed HSM

Blok konektivitas jaringan antara SQL Managed Instance dan brankas kunci atau HSM terkelola sebagian besar terjadi ketika brankas kunci atau sumber daya HSM terkelola ada tetapi titik akhirnya tidak dapat dicapai dari instans terkelola. Semua skenario di mana brankas kunci atau titik akhir HSM terkelola dapat dicapai tetapi koneksi ditolak, izin yang hilang, dll., menyebabkan database mengubah statusnya menjadi Tidak Dapat Diakses.

Penyebab paling umum untuk kurangnya konektivitas jaringan ke Azure Key Vault atau Azure Managed HSM adalah:

  • Azure Key Vault atau Azure Managed HSM diekspos melalui titik akhir privat dan alamat IP privat layanan Azure Key Vault atau Azure Managed HSM tidak diizinkan dalam aturan keluar Grup Keamanan Jaringan (NSG) yang terkait dengan subnet instans terkelola.

  • Resolusi DNS buruk, seperti ketika Key Vault atau HSM Terkelola FQDN tidak dapat diselesaikan atau mengarah ke IP yang tidak valid.

Uji konektivitas dari SQL Managed Instance ke Azure Key Vault atau Azure Managed HSM yang menghosting pelindung TDE.

  • Titik akhir adalah FQDN vault Anda, seperti <vault_name.vault.azure.net> (tanpa https://).
  • Port yang akan diuji adalah 443.
  • Hasil untuk RemoteAddress harus ada dan menjadi alamat IP yang benar
  • Hasil untuk pengujian TCP harus TcpTestSucceeded: True.

Jika pengujian menampilkan TcpTestSucceeded: False, tinjau konfigurasi jaringan:

  • Periksa alamat IP yang ditetapkan dan konfirmasikan apakah alamat tersebut valid. Nilai yang hilang berarti ada masalah dengan resolusi DNS.

    • Pastikan bahwa grup keamanan jaringan pada instans terkelola memiliki aturan keluar yang mencakup alamat IP yang dipecahkan pada port 443, terutama ketika alamat yang dipecahkan termasuk dalam key vault atau titik akhir privat HSM terkelola.

    • Periksa konfigurasi jaringan lain seperti tabel rute, keberadaan appliance virtual dan konfigurasinya, dll.

Memantau TDE yang dikelola pelanggan

Untuk memantau status database dan mengaktifkan pemberitahuan kehilangan akses pelindung TDE, konfigurasikan fitur Azure berikut:

  • Azure Resource Health. Database yang tidak dapat diakses yang kehilangan akses ke pelindung TDE ditampilkan sebagai "Tidak Tersedia" setelah koneksi pertama ke database ditolak.

  • Log Aktivitas saat akses ke pelindung TDE di brankas kunci yang dikelola pelanggan gagal, entri ditambahkan ke log aktivitas. Membuat pemberitahuan untuk peristiwa ini memungkinkan Anda mengembalikan akses sesegera mungkin.

  • Grup Tindakan dapat didefinisikan untuk mengirimi Anda pemberitahuan dan pemberitahuan berdasarkan preferensi Anda, misalnya, Email/SMS/Push/Voice, Logic App, Webhook, ITSM, atau Automation Runbook.

Database backup dan restore dengan TDE yang dikelola pelanggan

Setelah database dienkripsi dengan TDE menggunakan kunci dari Azure Key Vault atau Azure Managed HSM, cadangan yang baru dibuat juga dienkripsi dengan pelindung TDE yang sama. Ketika pelindung TDE diubah, cadangan lama database tidak diperbarui untuk menggunakan pelindung TDE terbaru.

Untuk memulihkan cadangan yang dienkripsi dengan pelindung TDE dari Azure Key Vault atau Azure Managed HSM, pastikan bahwa materi kunci tersedia untuk server target. Oleh karena itu, kami sarankan Anda menyimpan semua versi lama pelindung TDE di brankas kunci atau HSM terkelola, sehingga cadangan database dapat dipulihkan.

Penting

Tidak boleh ada lebih dari satu pelindung TDE yang ditetapkan untuk server pada satu waktu. Kunci yang ditandai dengan Jadikan kunci sebagai pelindung TDE default di panel portal Microsoft Azure adalah pelindung TDE. Namun, beberapa kunci dapat ditautkan ke server tanpa menandainya sebagai pelindung TDE. Kunci ini tidak digunakan untuk melindungi DEK, tetapi dapat digunakan selama pemulihan dari cadangan, jika file cadangan dienkripsi dengan kunci dengan thumbprint yang sesuai.

Jika kunci yang diperlukan untuk memulihkan cadangan tidak lagi tersedia untuk server target, pesan kesalahan berikut dikembalikan pada pemulihan coba: "Server target <Servername> tidak memiliki akses ke semua URI AKV yang dibuat antara <Tanda Waktu #1> dan <Tanda Waktu #2>. Coba lagi operasi setelah memulihkan semua URI AKV."

Untuk menguranginya, jalankan cmdlet Get-AzSqlServerKeyVaultKey untuk server target atau Get-AzSqlInstanceKeyVaultKey untuk instans terkelola target untuk mengembalikan daftar kunci yang tersedia dan mengidentifikasi yang hilang. Untuk memastikan semua cadangan dapat dipulihkan, pastikan server target untuk pemulihan memiliki akses ke semua kunci yang diperlukan. Kunci ini tidak perlu ditandai sebagai pelindung TDE.

Untuk mempelajari selengkapnya tentang pemulihan cadangan untuk SQL Database, lihat Memulihkan database dari cadangan di Azure SQL Database. Untuk mempelajari selengkapnya tentang pemulihan cadangan untuk kumpulan SQL khusus di Azure Synapse Analytics, lihat Memulihkan kumpulan SQL khusus. Untuk pencadangan/pemulihan asli SQL Server dengan SQL Managed Instance, lihat Panduan Cepat: Memulihkan database ke Azure SQL Managed Instance dengan SQL Server Management Studio (SSMS).

Pertimbangan lain untuk file log: File log yang dicadangkan tetap dienkripsi dengan pelindung TDE asli, bahkan jika diputar dan database sekarang menggunakan pelindung TDE baru. Pada waktu pemulihan, kedua kunci diperlukan untuk memulihkan database. Jika file log menggunakan pelindung TDE yang disimpan di Azure Key Vault atau Azure Managed HSM, kunci ini diperlukan pada waktu pemulihan, bahkan jika database diubah untuk menggunakan TDE yang dikelola layanan sementara itu.

Ketersediaan tinggi dengan TDE yang pelanggan kelola

Dengan Azure Key Vault atau Azure Managed HSM yang menyediakan beberapa lapisan redundansi, TDE menggunakan kunci yang dikelola pelanggan dapat memanfaatkan ketersediaan dan ketahanan Azure Key Vault atau Azure Managed HSM, dan mengandalkan sepenuhnya pada solusi redundansi Azure Key Vault atau Azure Managed HSM.

Beberapa lapisan redundansi Azure Key Vault memastikan akses kunci meskipun komponen layanan individual gagal atau wilayah Azure atau zona ketersediaan tidak berfungsi. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault.

Azure Key Vault menawarkan komponen ketersediaan dan ketahanan berikut yang disediakan secara otomatis tanpa intervensi pengguna:

Nota

Untuk semua wilayah pasangan, kunci Azure Key Vault direplikasi ke kedua wilayah dan ada Modul Keamanan Perangkat Keras (HSM) di kedua wilayah yang dapat beroperasi pada kunci tersebut. Untuk informasi selengkapnya, lihat Replikasi data. Ini berlaku untuk tingkat layanan Azure Key Vault Standar dan Premium, dan kunci perangkat lunak atau perangkat keras.

Replikasi multi-wilayah Azure Managed HSM memungkinkan Anda memperluas kumpulan Azure Managed HSM dari satu wilayah Azure (disebut wilayah utama) ke wilayah Azure lain (disebut wilayah yang diperluas). Setelah dikonfigurasi, kedua wilayah aktif, dapat melayani permintaan dan, dengan replikasi otomatis, berbagi materi kunci, peran, dan izin yang sama. Untuk informasi selengkapnya, lihat Mengaktifkan replikasi multi-wilayah di Azure Managed HSM.

Geo-DR dan TDE yang dikelola pelanggan

Dalam skenario replikasi geografis aktif dan grup failover , server utama dan sekunder yang terlibat dapat ditautkan ke Azure Key Vault atau Azure Managed HSM yang terletak di wilayah mana pun. Server dan brankas kunci atau HSM terkelola tidak harus dikolokasi di wilayah yang sama. Dengan ini, untuk kesederhanaan, server utama dan sekunder dapat dihubungkan ke brankas kunci yang sama atau HSM terkelola (di wilayah mana pun). Ini membantu menghindari skenario di mana materi kunci mungkin tidak sinkron jika brankas kunci terpisah atau HSM terkelola digunakan untuk kedua server.

Azure Key Vault dan Azure Managed HSM memiliki beberapa lapisan redundansi untuk memastikan bahwa kunci dan brankas kunci tetap tersedia jika terjadi kegagalan layanan atau wilayah. Redundansi didukung oleh wilayah yang tidak berpasangan dan dipasangkan. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault.

Ada beberapa opsi untuk menyimpan kunci pelindung TDE, berdasarkan persyaratan pelanggan:

  • Gunakan Azure Key Vault dan ketahanan wilayah berpasangan asli atau ketahanan wilayah yang tidak berpasangan.

  • Gunakan HSM pelanggan dan muat kunci pada Azure Key Vault yang terpisah di berbagai wilayah.

  • Gunakan Azure Managed HSM dan opsi replikasi lintas wilayah.

    • Opsi ini memungkinkan pelanggan untuk memilih wilayah yang diinginkan tempat kunci direplikasi.

Diagram berikut ini menunjukkan konfigurasi untuk region berpasangan (primer dan sekunder) untuk cross-failover Azure Key Vault dengan penyiapan Azure SQL untuk replikasi geografis menggunakan grup failover.

Diagram memperlihatkan dukungan failover lintas wilayah Azure Key Vault untuk wilayah yang dipasangkan.

Komentar Azure Key Vault untuk Geo-DR

  • Server utama dan sekunder di Azure SQL mengakses Azure Key Vault di wilayah utama.

  • Failover Azure Key Vault dimulai oleh layanan Azure Key Vault dan bukan oleh pelanggan.

  • Jika Azure Key Vault beralih ke wilayah sekunder, server di Azure SQL masih dapat mengakses Azure Key Vault yang sama. Meskipun secara internal, koneksi Azure Key Vault dialihkan ke Azure Key Vault di wilayah sekunder.

  • Pembuatan kunci baru, impor, dan rotasi kunci hanya dimungkinkan saat Azure Key Vault di lokasi utama tersedia.

  • Setelah failover terjadi, rotasi kunci tidak diizinkan sampai Azure Key Vault di wilayah utama dari wilayah yang berpasangan dapat diakses kembali.

  • Pelanggan tidak dapat terhubung secara manual ke wilayah sekunder.

  • Azure Key Vault berada dalam status baca-saja saat Azure Key Vault di wilayah utama tidak tersedia

  • Pelanggan tidak dapat memilih atau memeriksa wilayah tempat Azure Key Vault saat ini berada.

  • Untuk wilayah yang tidak berpasangan, kedua server Azure SQL mengakses Azure Key Vault di wilayah pertama (seperti yang ditunjukkan pada grafik) dan Azure Key Vault menggunakan penyimpanan zona redundan untuk mereplikasi data dalam wilayah tersebut, di seluruh zona ketersediaan independen dari wilayah yang sama.

Untuk informasi selengkapnya, lihat ketersediaan dan redundansi Azure Key Vault, pasangan wilayah Azure dan wilayah yang tidak berpasangan, dan perjanjian tingkat layanan untuk Azure Key Vault.

Komentar Azure SQL untuk Geo-DR

  • Gunakan opsi redundansi zona Azure SQL Managed Instance dan Azure SQL Database untuk meningkatkan ketahanan. Untuk informasi selengkapnya, lihat Apa itu zona ketersediaan Azure?.

  • Gunakan grup failover untuk Azure SQL Managed Instance dan Azure SQL Database untuk pemulihan bencana ke wilayah sekunder. Untuk informasi selengkapnya, lihat ringkasan grup Failover & praktik terbaik.

  • Ketika database adalah bagian dari replikasi geografis aktif atau grup failover dan menjadi tidak dapat diakses, sarana kontrol SQL memecah tautan dan mengonversi database menjadi database mandiri. Setelah memperbaiki izin kunci, database utama biasanya dapat dibawa kembali secara online. Database sekunder tidak dapat dibawa kembali secara online karena Azure SQL tidak mengambil cadangan penuh untuk database sekunder berdasarkan desain. Rekomendasinya adalah menjatuhkan database sekunder dan membuat ulang tautan.

  • Konfigurasi mungkin memerlukan zona DNS yang lebih kompleks jika titik akhir privat digunakan di Azure SQL (misalnya, tidak dapat membuat dua titik akhir privat ke sumber daya yang sama di zona DNS yang sama).

  • Pastikan aplikasi menggunakan logika coba lagi.

Ada beberapa skenario ketika pelanggan mungkin ingin memilih solusi Azure Managed HSM melalui Azure Key Vault:

  • Persyaratan sambungan manual ke vault sekunder.

  • Membaca persyaratan akses ke vault bahkan jika kegagalan terjadi.

  • Fleksibilitas untuk memilih wilayah mana bahan kunci mereka direplikasi

    • Memerlukan pengaktifan replikasi lintas wilayah, yang membuat kumpulan HSM Terkelola Azure kedua di wilayah kedua.

  • Menggunakan Azure Managed HSM memungkinkan pelanggan untuk membuat replika yang tepat untuk HSM jika aslinya hilang atau tidak tersedia.

  • Penggunaan Azure Managed HSM untuk persyaratan keamanan atau peraturan.

  • Memiliki kemampuan untuk mencadangkan seluruh brankas dibandingkan mencadangkan kunci satu per satu.

Untuk informasi selengkapnya, lihat Mengaktifkan replikasi multi-wilayah pada HSM Terkelola Azure dan Pemulihan bencana HSM Terkelola.

Azure Policy untuk TDE yang dikelola oleh pelanggan

Azure Policy dapat digunakan untuk memberlakukan TDE yang dikelola pelanggan selama pembuatan atau pembaruan server Azure SQL Database atau Azure SQL Managed Instance. Dengan kebijakan ini, setiap upaya untuk membuat atau memperbarui server logis di Azure atau instans terkelola gagal jika tidak dikonfigurasi dengan kunci yang dikelola pelanggan. Azure Policy dapat diterapkan ke seluruh langganan Azure, atau hanya dalam grup sumber daya.

Untuk informasi selengkapnya tentang Azure Policy, lihat Apa itu Azure Policy dan struktur definisi Azure Policy .

Dua kebijakan bawaan berikut ini didukung untuk TDE yang dikelola pelanggan di Azure Policy:

  • Server SQL harus menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data saat tidak aktif
  • Instans terkelola harus menggunakan kunci yang dikelola oleh pelanggan untuk mengenkripsi data yang disimpan

Kebijakan TDE yang dikelola pelanggan dapat dikelola dengan masuk ke portal Microsoft Azure, dan mencari layanan Kebijakan . Di bawah Definisi, cari kunci yang dikelola pelanggan.

Ada tiga efek untuk kebijakan ini:

  • Audit - Pengaturan default, dan hanya mengambil laporan audit di log aktivitas Azure Policy

  • Tolak - Mencegah pembuatan atau pembaruan server logis atau instans terkelola jika kunci yang dikelola pelanggan belum dikonfigurasi

  • Dinonaktifkan - Menonaktifkan kebijakan dan tidak membatasi pengguna untuk membuat atau memperbarui server logis atau instans terkelola tanpa mengaktifkan TDE yang dikelola pelanggan

Jika peraturan Azure Policy untuk TDE yang dikelola pelanggan diatur ke Tolak, pembuatan server logis Azure SQL atau instans terkelola akan gagal. Detail kegagalan ini dicatat dalam log Aktivitas grup sumber daya.

Penting

Versi kebijakan terintegrasi yang lebih lama untuk TDE yang dikelola oleh pelanggan dan berisi AuditIfNotExists efek tidak digunakan lagi. Penetapan kebijakan yang ada menggunakan kebijakan yang tidak digunakan lagi tidak terpengaruh dan terus berfungsi seperti sebelumnya.

Konten terkait

  • Last updated on