Versi Kunci di Kluster Big Data SQL Server
Berlaku untuk: 
SQL Server 2019 (15.x)
Penting
Add-on Kluster Big Data Microsoft SQL Server 2019 akan dihentikan. Dukungan untuk SQL Server 2019 Kluster Big Data akan berakhir pada 28 Februari 2025. Semua pengguna SQL Server 2019 yang ada dengan Jaminan Perangkat Lunak akan didukung sepenuhnya pada platform dan perangkat lunak akan terus dipertahankan melalui pembaruan kumulatif SQL Server hingga saat itu. Untuk informasi selengkapnya, lihat posting blog pengumuman dan Opsi big data di platform Microsoft SQL Server.
Artikel ini menyediakan detail tentang bagaimana versi kunci digunakan di SQL Server Kluster Big Data untuk manajemen kunci dan rotasi kunci untuk kunci HDFS dan SQL Server. Artikel ini mencakup detail tentang bagaimana versi dapat menggabungkan kunci pelanggan.
Untuk informasi umum tentang mengamankan Kluster Big Data SQL Server, lihat Konsep keamanan untuk SQL Server Kluster Big Data.
Untuk informasi tentang mengonfigurasi dan menggunakan fitur enkripsi saat tidak aktif, lihat panduan berikut:
- Konsep enkripsi saat istirahat dan panduan konfigurasi
- Panduan penggunaan Zona Enkripsi SQL Server Kluster Big Data HDFS
- SQL Server Kluster Big Data enkripsi data transparan (TDE) saat tidak digunakan
Kunci HDFS
Untuk menggunakan enkripsi saat tidak aktif dalam HDFS, konsep berikut terlibat:
- Zona enkripsi (EZ): Zona enkripsi adalah folder dalam HDFS yang terkait dengan kunci. Semua file dalam folder ini dienkripsi. EZ yang disediakan default di SQL Server Kluster Big Data disebut "securelake".
- Kunci Zona Enkripsi (Kunci EZ): Kunci simetris bernama. Default yang dikelola sistem yang disediakan di SQL Server Kluster Big Data adalah "securelakekey". Kunci zona enkripsi dikelola menggunakan Hadoop KMS (Key Management Server) yang berjalan di dalam pod simpul nama SQL Server Kluster Big Data. Kunci EZ dilindungi lebih lanjut oleh kunci enkripsi utama yang disimpan dalam controldb (dibahas dalam bagian di bawah). Kunci EZ dienkripsi di Hadoop KMS dengan mengambil bagian publik dari kunci enkripsi utama dan permintaan dekripsi dikirim ke sarana kontrol.
- Kunci Enkripsi Data Terenkripsi: Setiap file di zona Enkripsi dienkripsi oleh Kunci Enkripsi Data (DEK) yang dihasilkan untuk file tersebut. Setelah DEK dibuat, DEK akan bertahan dengan data. Untuk mempertahankan DEK, pertama-tama Dienkripsi oleh Kunci Zona Enkripsi lalu dipertahankan dengan data. DEK dihasilkan secara acak per file dan kekuatan DEK simetris sama dengan kekuatan Kunci EZ.
Grafik di bawah ini menjelaskan bagaimana file dilindungi oleh DEK dan bagaimana DEK dilindungi oleh kunci EZ securelakekey.
Kunci SQL Server
Kunci enkripsi utama yang dikelola sistem dan kunci HDFS EZ disimpan di dalam controldb, yang akan diberi nama controldb-<#>, misalnya controldb-0. Untuk informasi selengkapnya, lihat Sumber Daya yang disebarkan dengan Kluster Big Data.
Database SQL Server dienkripsi oleh kunci konten, juga dikenal sebagai kunci enkripsi Database (DEK). DEK dipertahankan dengan database dalam format terenkripsi. Pelindung DEK dapat berupa sertifikat atau kunci asimetris. Untuk mengubah pelindung DEK, gunakan pernyataan ALTER DATABASE ENCRYPTION KEY . Kunci asimetris di SQL Server memiliki metadata yang berisi tautan URL ke kunci di dalam sarana kontrol. Oleh karena itu semua operasi enkripsi dan dekripsi Kunci Enkripsi Database (DEK) dilakukan di dalam pengontrol. SQL Server menyimpan kunci publik, tetapi hanya untuk mengidentifikasi kunci asimetris dan tidak mengenkripsi menggunakan kunci publik.
Kunci enkripsi utama Kluster Big Data SQL Server
Di sarana kontrol SQL Server Kluster Big Data, untuk melindungi kunci zona Enkripsi dan untuk menyediakan kunci asimetris di SQL Server, ada konsep kunci enkripsi utama. Ada dua kunci enkripsi utama, satu untuk SQL Server dan satu untuk HDFS. Konsep ini memungkinkan SQL Server Kluster Big Data sarana kontrol untuk memungkinkan kunci enkripsi utama berada di luar kluster juga. Properti kunci enkripsi utama adalah:
- Kunci enkripsi utama adalah kunci RSA asimetris.
- Kunci enkripsi utama dibuat untuk instans master SQL Server dan yang lain untuk HDFS.
- Kunci publik yang sesuai dengan kunci enkripsi utama selalu disimpan dalam database pengontrol atau controldb. Kunci privat disimpan dalam database pengontrol untuk kunci enkripsi utama yang dikelola sistem. Untuk kunci enkripsi dari Modul Keamanan Perangkat Keras (HSM) atau penyedia eksternal lainnya, kunci privat tidak disimpan di dalam database pengontrol (kecuali aplikasi untuk kunci eksternal membawa kunci privat dengannya). Namun, kunci privat tidak diperlukan di dalam Kluster Big Data controldb dan SQL Server tidak akan memerlukan materi kunci privat.
- Operasi enkripsi menggunakan kunci publik kunci enkripsi utama dapat dilakukan di dalam pengontrol itu sendiri, atau, pengontrol dapat mendistribusikan kunci publik ke Hadoop KMS sehingga Hadoop KMS dapat melakukan enkripsi secara lokal. Operasi dekripsi diharapkan ditangani oleh penyedia kunci eksternal, seperti HSM. Desain ini memungkinkan kami untuk menyimpan bagian sensitif dari kunci asimetris di luar kluster dan dalam perlindungan pelanggan. Ini memastikan bahwa akar enkripsi untuk mendekripsi semua data tidak pernah tersedia di ekosistem SQL Server Kluster Big Data untuk kunci yang dikonfigurasi pelanggan.
Perlindungan penyimpanan kunci yang berbeda
DEK untuk file HDFS dan untuk SQL Server disimpan bersama dengan data yang dilindungi DEK. DEK dilindungi oleh kunci HDFS EZ atau kunci asimetris di SQL Server masing-masing.
Kunci asimetris di SQL Server memiliki metadata termasuk URL kunci dalam sarana kontrol. SQL Server hanya menyimpan kunci publik kunci asimetris, untuk korelasi dengan kunci di sarana kontrol.
Penyimpanan kunci dalam controldb, dilindungi oleh kunci enkripsi kolom dalam controldb. Controldb menyimpan informasi sensitif tentang kluster dan semua informasi sensitif dilindungi oleh Kunci Enkripsi Kolom SQL Server di controldb, yang lebih dilindungi oleh kata sandi yang disimpan dalam Rahasia Kubernetes. Untuk informasi selengkapnya, lihat Rahasia dalam Dokumentasi Kubernetes.
Perlindungan dirangkum dalam diagram di bawah ini. Pertama, perlindungan penyimpanan kunci HDFS EZ:
Perlindungan penyimpanan kunci enkripsi utama:
Rotasi kunci
Kunci zona enkripsi HDFS
Ketika SQL Server Kluster Big Data disebarkan dengan Direktori Aktif, HDFS disediakan dengan zona enkripsi default yang disebut securelake, dilindungi oleh securelakekey. Kami akan menggunakan default dalam contoh, namun zona dan kunci baru dapat disediakan menggunakan azdata. Securelakekey dilindungi oleh kunci enkripsi utama untuk HDFS, yang disimpan di sarana kontrol. Dimulai dengan SQL 2019 CU9, azdata dapat digunakan untuk memutar kunci EZ untuk HDFS. Rotasi kunci EZ menyebabkan materi kunci baru dihasilkan, dengan nama yang sama dengan "securelakekey", tetapi dengan versi baru kunci yang menunjuk ke materi kunci. Setiap operasi enkripsi baru dalam HDFS (misalnya, penulisan file), EZ selalu menggunakan versi terbaru kunci yang terkait dengan EZ. Untuk file dalam EZ, dilindungi oleh versi kunci yang lebih lama, azdata bdc hdfs encryption-zone reencrypt perintah dapat digunakan, sehingga semua file dapat dilindungi oleh versi terbaru kunci EZ.
Pertimbangkan file bernama file2 yang ditempatkan di /securelake. Berikut ini menggambarkan rantai perlindungan.
Securelakekey dapat diputar ke versi baru menggunakan azdata bdc hdfs key roll -n securelakekey. Rotasi tidak menyebabkan enkripsi ulang DEK yang melindungi file. Rotasi kunci Hadoop menyebabkan materi kunci baru dihasilkan, dan dilindungi oleh versi terbaru kunci enkripsi utama. Diagram berikut menunjukkan status sistem setelah rotasi securelakekey.
Untuk memastikan bahwa file di zona enkripsi dilindungi oleh securelakekey yang diputar, azdata bdc hdfs encryption-zone -a start -p /securelake.
Diagram berikut menggambarkan status sistem setelah enkripsi ulang zona enkripsi.
SQL Server
Kunci yang melindungi SQL Database adalah DEK, yang dapat diregenerasi. Proses regenerasi akan menyebabkan seluruh database dienkripsi ulang.
Rotasi kunci enkripsi utama
Catatan
Sebelum SQL Server 2019 CU10 tidak ada cara untuk memutar kunci enkripsi utama. Dimulai dengan SQL Server 2019 CU10, azdata perintah diekspos untuk memungkinkan rotasi kunci enkripsi utama.
Kunci enkripsi utama adalah kunci RSA 2048-bit. Rotasi kunci enkripsi utama akan melakukan salah satu hal berikut tergantung pada sumber kunci:
- Buat kunci baru jika permintaan telah dibuat untuk memutar kunci utama ke kunci yang dikelola sistem. Kunci yang dikelola sistem adalah kunci asimetris, dihasilkan dan disimpan di dalam pengontrol.
- Buat referensi ke kunci yang disediakan secara eksternal, di mana kunci privat asimetris akan dikelola oleh aplikasi pelanggan. Aplikasi pelanggan tidak perlu memiliki kunci privat, tetapi harus tahu cara mengambil kunci privat berdasarkan konfigurasi aplikasi yang disediakan.
Rotasi kunci utama tidak mengenkripsi ulang apa pun. Kunci SQL Server dan HDFS kemudian harus diputar:
- Setelah kunci utama diputar, pelindung DEK database SQL Server perlu diputar ke versi baru kunci utama yang dibuat.
- Konsep serupa berlaku untuk HDFS. Ketika kunci HDFS diputar, materi baru dienkripsi oleh versi terbaru kunci utama. Versi lama kunci EZ akan tetap tidak tersentuh. Setelah kunci HDFS EZ diputar, zona enkripsi yang terkait dengan kunci EZ perlu dienkripsi ulang sehingga dienkripsi ulang oleh versi kunci EZ terbaru.
Rotasi kunci utama untuk HDFS
Diagram berikut mengilustrasikan proses memutar kunci enkripsi utama untuk HDFS. Pertama, status awal HDFS:
Kunci enkripsi utama akan diputar menggunakan azdata bdc kms set –key-provider SystemManaged. (Perhatikan perintah menyebabkan rotasi kunci enkripsi utama untuk SQL dan HDFS, meskipun mereka adalah kunci yang berbeda di dalam sarana kontrol.) Setelah menggunakan azdata bdc kms perintah:
Untuk menggunakan versi baru kunci enkripsi utama HDFS, azdata bdc hdfs key roll perintah dapat digunakan, yang kemudian membawa sistem ke status berikut. Setelah memutar securelakekey:
Memutar securelakekey akan menyebabkan versi baru securelakekey dibuat, dan dilindungi oleh kunci enkripsi utama. Untuk memastikan bahwa file dalam securelake dienkripsi oleh securelakekey@2, zona enkripsi securelake perlu dienkripsi ulang. Setelah mengenkripsi ulang zona enkripsi:
Rotasi kunci utama untuk SQL Server
Kunci enkripsi utama SQL Server diinstal dalam database master instans master SQL Server.
Diagram berikut mengilustrasikan proses memutar kunci enkripsi utama untuk SQL Server.
Pada penginstalan baru SQL Server Kluster Big Data, tidak akan ada kunci asimetris yang disediakan di SQL Server. Dalam Status awal SQL Server, database dapat dienkripsi menggunakan sertifikat, namun admin instans master SQL Server mengontrol aspek ini.
Kunci enkripsi utama akan diputar menggunakan azdata bdc kms set –key-provider SystemManaged. (Perhatikan perintah menyebabkan rotasi [atau membuat jika tidak ada] kunci enkripsi utama untuk SQL dan HDFS keduanya, meskipun keduanya adalah kunci yang berbeda di dalam sarana kontrol.)
Kunci asimetris dapat dilihat menggunakan kueri T-SQL berikut, dengan sys.asymmetric_keys tampilan katalog sistem.
USE master;
select * from sys.asymmetric_keys;
Kunci asimetris akan muncul dengan konvensi penamaan "tde_asymmetric_key_<versi>". Administrator SQL Server kemudian dapat mengubah pelindung DEK ke kunci asimetris menggunakan ALTER DATABASE ENCRYPTION KEY. Misalnya, gunakan perintah T-SQL berikut:
USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;
Sekarang, pelindung DEK diubah untuk menggunakan kunci asimetris:
Jika azdata bdc kms set perintah dijalankan kembali, maka kunci asimetris di SQL Server akan menampilkan entri lain dengan sys.asymmetric_keys format "tde_asymmetric_key_<versi>". Perintah ini azdata dapat digunakan untuk kembali mengubah pelindung DEK database SQL Server.
Kunci yang disediakan pelanggan
Dengan kemampuan untuk membawa kunci eksternal di SQL Server Kluster Big Data, kunci enkripsi utama mengambil kunci publik menggunakan Aplikasi yang disebarkan pelanggan. Ketika kunci HDFS diputar dan digunakan, panggilan untuk mendekripsi kunci HDFS akan dikirim ke sarana kontrol dan kemudian dialihkan ke aplikasi menggunakan pengidentifikasi kunci yang disediakan oleh pelanggan. Untuk SQL Server, permintaan untuk mengenkripsi dikirim dan dipenuhi oleh sarana kontrol, karena memiliki kunci publik. Permintaan untuk mendekripsi DEK dari SQL, dikirim ke sarana kontrol juga, dan kemudian dialihkan ke aplikasi KMS.
Diagram berikut menjelaskan interaksi saat mengonfigurasi kunci eksternal di sarana kontrol:
Setelah kunci diinstal, enkripsi dan dekripsi payload yang berbeda dilindungi oleh kunci enkripsi utama. Perlindungan ini mirip dengan kunci yang dikelola sistem, kecuali bahwa panggilan dekripsi dirutekan ke sarana kontrol, kemudian dirutekan ke aplikasi plugin KMS. Aplikasi plugin KMS merutekan permintaan ke lokasi yang sesuai, seperti HSM atau produk lain.