Grup Ketersediaan sangat bagus untuk solusi Ketersediaan Tinggi/Pemulihan Bencana, dan saya yakin sesama DBA akan setuju dengan saya. Namun, ada saatnya kita harus mempertimbangkan tindakan pencegahan tertentu dan langkah ekstra dengan hati-hati untuk menghindari kejutan yang tidak diinginkan. Misalnya, Replika Sekunder apa pun menjadi Replika Utama saat ini karena alasan apa pun, dan tujuan kami adalah untuk tidak membiarkannya terjadi.
Ada dua opsi enkripsi yang disediakan oleh SQL:sql tde vs selalu dienkripsi. Dalam artikel ini, saya akan menunjukkan satu skenario yang mengharuskan DBA memberikan perhatian ekstra pada detail. Seperti judulnya, ini akan memandu Anda melalui cara yang tepat untuk menangani enkripsi data dalam database yang merupakan bagian dari penyiapan AlwaysOn Availability Group.
Pertimbangan Awal
Saya akan menggunakan Enkripsi Data Transparan (TDE) sebagai teknologi untuk membangun kasus saya. Ini berlaku untuk semua versi SQL Server yang didukung. Penting untuk disebutkan bahwa fitur ini hanya tersedia dalam Edisi SQL Server berikut:
- Evaluasi SQL Server 2019, Standar, Pengembang, Perusahaan
- Evaluasi, Pengembang, Perusahaan SQL Server 2017,
- Evaluasi, Pengembang, Perusahaan SQL Server 2016,
- Evaluasi, Pengembang, Perusahaan SQL Server 2014,
- Evaluasi SQL Server 2012, Pengembang, Perusahaan
- Pusat Data SQL Server 2008R2, Evaluasi, Pengembang, Perusahaan
- Evaluasi SQL Server 2008, Pengembang, Perusahaan
Mari kita lihat bagaimana kita dapat menggunakan TDE (Transparent Data Encryption) di SQL Server Standard Edition. Pertama-tama, kita perlu membuat DMK (Database Master Key) untuk mengenkripsi data. Kemudian, kami membuat sertifikat dan kunci untuk dapat mendekripsi data saat mengaksesnya. Jangan lupa untuk membuat cadangan sertifikat dan, terakhir, aktifkan enkripsi.
Catatan: Fitur TDE tidak didukung di SQL Server Express Edition.
Posting ini tidak akan membahas langkah-langkah untuk membangun Grup Ketersediaan, dan saya mengandalkan yang sudah dibuat untuk tujuan pengujian. Anda dapat membaca selengkapnya tentang cara menerapkan grup ketersediaan SQL Server AlwaysOn di Linux.
Lingkungannya berbasis Windows, tetapi prinsipnya akan sangat mirip jika Anda menggunakan platform yang berbeda (mis. SQL Server di Linux atau Azure SQL Managed Instances).
Apa itu Enkripsi Data Sementara
Alasan utama mengapa kami menggunakan TDE adalah keamanan data dan file log untuk database SQL Anda. Untuk mencegah data pribadi Anda dicuri, ada baiknya untuk mempertahankannya, ditambah lagi proses enkripsi ini sangat mudah. Sebelum halaman ditulis dalam disk, file dienkripsi pada tingkat halaman. Setiap kali Anda ingin mengakses data Anda, itu akan didekripsi. Setelah implementasi TDE, Anda memerlukan sertifikat dan kunci khusus untuk memulihkan atau melampirkan database. Itulah yang dimaksud dengan algoritma enkripsi.
Microsoft Contoh Grup Ketersediaan SQL Server
Grup Ketersediaan pengujian saya terdiri dari 2 replika, masing-masing dalam VM-nya sendiri. Berikut adalah properti dasarnya:
Seperti yang Anda lihat, tidak ada yang mewah, hanya beberapa replika menggunakan mode komit sinkron dan di bawah mode failover manual.
Tangkapan layar berikut menunjukkan database yang disebut "tes." Itu ditambahkan ke SQL Server AlwaysOn Availability Group dan berada dalam status tersinkronisasi.
Cara Mengaktifkan TDE di SQL Server
Berikut adalah langkah-langkah untuk mengaktifkan SQL Server TDE untuk database “test”. Catatan :kami akan menjalankan langkah-langkah berikut di Replika Utama saat ini.
Langkah 1
Buat kunci master di database master.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Langkah 2
Buat sertifikat yang dilindungi oleh kunci master.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Langkah 3
Buat Kunci Enkripsi Basis Data (DEK) dan lindungi dengan sertifikat yang dibuat di Langkah 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Langkah 4
Atur database “test” untuk menggunakan enkripsi.
ALTER DATABASE test
SET ENCRYPTION ON;
Bagaimana Cara Memeriksa apakah TDE Diaktifkan?
Setelah selesai, Anda perlu mengonfirmasi bahwa Enkripsi Data Transparan di SQL Server diaktifkan untuk database “tes”.
Di Properti Basis Data bagian, buka Opsi halaman. Di sana, perhatikan Negara area di bagian bawah jendela. Enkripsi Diaktifkan nilainya harus Benar .
Anda juga dapat menjalankan kode TSQL berikut untuk mengonfirmasinya:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Masalah Manajemen dan Sertifikasi Kunci
Catatan: Jangan kaget jika Anda mengetahui bahwa tempdb juga dienkripsi. Itu karena tempdb adalah tempat semua jenis operasi berlangsung (misalnya pengurutan, penggabungan hash, dll.), menggunakan data dari semua basis data. Oleh karena itu, jika setidaknya satu basis data pengguna dienkripsi, operasi dari basis data tertentu itu mungkin masuk ke tempdb yang perlu mengembalikan data itu ke basis data pengguna. Oleh karena itu, mengirimkan kembali data yang tidak terenkripsi akan menunjukkan masalah tersebut.
Anda dapat membaca lebih lanjut tentang enkripsi cadangan di SQL Server untuk meningkatkan keamanan database Anda.
Anda dapat menggunakan Kode TSQL berikut untuk mengonfirmasi bahwa ada Database Master Key yang ada untuk database "tes" yang dienkripsi oleh sertifikat (seperti yang dijalankan pada Langkah 3):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Sejauh ini bagus, setidaknya untuk Replika Utama. Tapi apa yang terjadi jika kita menanyakan sys.databases tampilan sistem untuk mengonfirmasi status enkripsi database "tes" di Replika Sekunder?
Grup Ketersediaan mereplikasi semua yang terkait dengan database dari satu replika ke replika lainnya. Namun, Replika Sekunder dengan jelas menyatakan bahwa itu tidak dienkripsi.
Mari kita periksa Replika Sekunder kami untuk mengetahui petunjuk tentang itu:
Status database adalah “Tidak Menyinkronkan / Tersangka” – tidak terlihat bagus sama sekali. Namun, setelah memeriksa Log Kesalahan Replika Sekunder, saya dapat melihat yang berikut:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Masalah utama adalah bahwa sertifikat yang digunakan untuk mengenkripsi Kunci Enkripsi Basis Data dari basis data “tes” (Langkah 3) tidak ada di Replika Sekunder.
Mengapa?
Karena Grup Ketersediaan tidak mereplikasi data dari database sistem. Sertifikat server yang hilang berada di database master Replika Utama.
Cara Memeriksa dan Menyiapkan Sertifikat TDE di SQL Server
Mari buat cadangan sertifikat server di database master Replika Utama. Kemudian mari kita pulihkan di database master Replika Sekunder.
Gunakan kode TSQL berikut untuk membuat cadangan dari Replika Utama saat ini yang memiliki database "test" dengan TDE diaktifkan:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Sebelum mencoba memulihkan sertifikat di Replika Sekunder, periksa terlebih dahulu apakah Kunci Master Basis Data ada di dalam basis data master. Jika tidak, buat persis seperti pada Langkah 1.
Gunakan kode TSQL berikut untuk memulihkan sertifikat di Replika Sekunder. Catatan :Pastikan untuk menyalin file .cer dan .pvk ke direktori target terlebih dahulu.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Jadi, bahkan setelah memulihkan sertifikat di Replika Sekunder, status database "pengujian" tetap sama:
Karena perpindahan data untuk database "tes" dijeda, mari kita lanjutkan secara manual untuk melihat apakah kita beruntung kali ini:
Ya! Operasi berhasil. Basis data “test” tidak hanya sepenuhnya tersinkronisasi dan sehat tetapi juga dienkripsi dengan TDE.
Selain itu, setelah kinerja failover manual untuk menukar peran replika, semuanya terus bekerja dengan baik.
Kesimpulan
Solusi yang dipamerkan bekerja dengan sangat baik. Namun, itu mungkin tidak ideal dalam semua kasus, terutama jika Anda adalah seorang DBA yang suka merencanakan dan melakukan sesuatu dengan cara yang "benar". Saya melihat "benar" sebagai berikut:
- Hapus database dari Grup Ketersediaan
- Jalankan semua langkah untuk mengaktifkan Enkripsi Data Transparan di replika tempat database dibaca/ditulis.
- Cadangkan sertifikat server dari Replika Utama.
- Salin file cadangan ke lokasi Replika Sekunder.
- Pulihkan sertifikat di database master.
- Tambahkan database kembali ke Grup Ketersediaan.
- Pastikan bahwa status operasional database sudah benar dan sesuai yang diinginkan (bergantung pada penyiapan khusus Anda).
Saya memberikan tanda kutip ganda untuk "benar" karena dalam cara saya menyajikan solusi, saya mendapatkan database di Replika Sekunder yang ditandai sebagai Tersangka. Ini saja mungkin akan menimbulkan banyak tanda/peringatan/tunjuk jari yang tidak diinginkan. Ini adalah kebisingan yang tidak perlu yang dapat Anda hindari dengan mudah dengan mempertimbangkan semua pertimbangan untuk merencanakan dan mengimplementasikan TDE dengan benar dalam pengaturan Always On Availability Group.
Untuk menyelesaikan posting ini, saya meninggalkan Anda dengan Hirarki Enkripsi resmi yang digunakan untuk TDE, yang telah diposting Microsoft di situs web mereka. Yang saya ingin Anda ingat adalah di mana setiap elemen dibuat (baik di master atau database pengguna), sehingga Anda dapat mengatasi potensi masalah/kejutan dengan Grup Ketersediaan.
Jika Anda tidak mengetahuinya, SQL Complete dapat sangat membantu Anda untuk mengonfigurasi Always Encrypted, yang merupakan teknologi lain yang berguna untuk melindungi data sensitif.
Ingatlah bahwa Anda perlu mempertimbangkan hal yang sama yang dibahas dalam artikel ini jika Anda berencana untuk menangani Always Encrypted dalam skenario Always On Availability Group. Namun, fitur yang diperkenalkan SQL Complete v6.7 dirancang untuk memastikan bahwa Anda langsung berhasil.
