Microsoft memiliki sejumlah fitur keamanan di SQL Server 2017 yang berguna untuk tujuan yang berbeda, tergantung pada apa yang Anda coba lindungi dan ancaman apa yang Anda coba lindungi. Beberapa fitur keamanan ini dapat memiliki implikasi kinerja yang harus Anda waspadai saat memutuskan mana yang ingin Anda terapkan. Sebagai pengantar, saya akan membahas beberapa hal penting dari beberapa fitur keamanan ini.
Enkripsi Database Transparan (TDE)
Enkripsi Data Transparan (TDE) adalah bentuk enkripsi SQL Server saat istirahat, yang berarti bahwa file data, file log, file tempdb, dan cadangan penuh, diferensial, dan log SQL Server Anda akan dienkripsi saat Anda mengaktifkan TDE pada database pengguna . Ini melindungi data Anda dari seseorang yang mendapatkan akses ke database atau file cadangan database tersebut selama orang tersebut juga tidak memiliki akses ke sertifikat dan kunci enkripsi Anda.
Pemindaian enkripsi TDE awal untuk database pengguna akan menggunakan satu utas CPU latar belakang per file data dalam database (jika file data berada di drive logis yang terpisah), untuk secara perlahan membaca seluruh konten file data ke dalam memori dengan kecepatan sekitar 52MB/detik per file data (jika file data berada di drive logis yang terpisah).
Data kemudian dienkripsi dengan algoritme enkripsi yang Anda pilih, dan kemudian ditulis kembali ke file data dengan kecepatan sekitar 55MB/per detik (per file data, jika berada di drive logis yang terpisah). Kecepatan baca dan tulis berurutan ini tampaknya sengaja dibatasi dan konsisten dalam pengujian saya pada beberapa sistem dengan berbagai jenis penyimpanan.
Proses enkripsi TDE awal terjadi pada tingkat halaman, di bawah SQL Server, sehingga tidak menyebabkan penguncian atau menghasilkan aktivitas log transaksi seperti yang akan Anda lihat dengan membangun kembali indeks. Anda dapat menjeda pemindaian enkripsi TDE dengan mengaktifkan global TF 5004, dan membatalkan jeda dengan menonaktifkan TF 5004 dan menjalankan perintah ALTER DATABASE dbNAME SET ENCRYTION ON Anda lagi, tanpa kehilangan kemajuan.
Dampak enkripsi/dekripsi CPU sangat berkurang pada SQL Server 2016 dan yang lebih baru jika Anda memiliki prosesor yang mendukung instruksi perangkat keras AES-NI. Di ruang server, ini diperkenalkan dalam keluarga produk Intel Xeon 5600 (Westmere-EP) untuk server dua soket dan rangkaian produk Intel Xeon E7-4800/8800 (Westmere-EX) untuk server empat dan delapan soket. Setiap keluarga produk Intel yang lebih baru juga akan memiliki dukungan AES-NI. Jika Anda ragu apakah prosesor Anda mendukung AES-NI, Anda dapat mencari "AES" di bidang instruksi keluaran dari CPU-Z, seperti yang Anda lihat pada Gambar 1.
Gambar 1:Output CPU-Z Menampilkan Dukungan Instruksi AES
Setelah Anda mengenkripsi database dengan TDE, dampak runtime dari TDE sulit diprediksi karena hal itu sangat bergantung pada beban kerja Anda. Jika misalnya, beban kerja Anda sepenuhnya sesuai dengan kumpulan buffer SQL Server, maka pada dasarnya tidak akan ada overhead dari TDE. Jika di sisi lain beban kerja Anda seluruhnya terdiri dari pemindaian tabel di mana halaman dibaca dan kemudian segera dihapus, itu akan memberikan hukuman maksimum. Hukuman maksimum untuk beban kerja volatil I/O biasanya kurang dari 5% dengan perangkat keras modern dan dengan SQL Server 2016 atau yang lebih baru.
Pekerjaan ekstra dekripsi TDE terjadi saat Anda membaca data ke buffer pool dari penyimpanan, dan pekerjaan ekstra enkripsi TDE terjadi saat Anda menulis data kembali ke penyimpanan. Memastikan Anda tidak berada di bawah tekanan memori, dengan memiliki kumpulan buffer yang cukup besar dan dengan melakukan penyetelan indeks dan kueri jelas akan mengurangi dampak kinerja TDE. TDE tidak mengenkripsi data FILESTREAM, dan database terenkripsi TDE tidak akan menggunakan inisialisasi file instan untuk file datanya.
Sebelum SQL Server 2016, TDE dan kompresi cadangan asli tidak bekerja sama dengan baik. Dengan SQL Server 2016 dan yang lebih baru, Anda dapat menggunakan TDE dan kompresi cadangan asli bersama-sama selama Anda menentukan MAXTRANSFERSIZE yang lebih besar dari 64K dalam perintah pencadangan. Hal ini juga sangat penting bahwa Anda saat ini dengan pembaruan kumulatif Anda, karena ada beberapa perbaikan terbaru terkait TDE penting untuk SQL Server 2016 dan SQL Server 2017. Akhirnya, TDE masih dan hanya fitur Enterprise Edition, bahkan setelah SQL Server 2016 SP1 (yang menambahkan banyak fitur khusus Perusahaan ke Edisi Standar).
Keamanan Tingkat Baris (RLS)
Keamanan Tingkat Baris (RLS) membatasi akses baca dan sebagian besar akses tingkat tulis berdasarkan atribut pengguna. RLS menggunakan apa yang disebut kontrol akses berbasis predikat. SQL Server menerapkan pembatasan akses di tingkat basis data, dan pembatasan itu akan diterapkan setiap kali akses data dicoba dari tingkat mana pun.
RLS bekerja dengan membuat fungsi predikat yang membatasi baris yang dapat diakses pengguna, lalu menggunakan kebijakan keamanan dan predikat keamanan untuk menerapkan fungsi tersebut ke tabel.
Ada dua jenis predikat keamanan, yaitu predikat filter dan predikat blok. Predikat filter akan secara diam-diam memfilter baris yang tersedia untuk operasi baca (SELECT, UPDATE, dan DELETE), dengan menambahkan klausa WHERE yang mencegah baris yang difilter muncul di kumpulan hasil. Predikat filter diterapkan saat membaca data dari tabel dasar, dan pengguna atau aplikasi tidak akan tahu bahwa baris sedang difilter dari hasil. Dari perspektif kinerja, penting untuk memiliki indeks penyimpanan baris yang mencakup predikat filter RLS Anda.
Predikat blok secara eksplisit, (dengan pesan kesalahan) blok operasi tulis (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, dan BEFORE DELETE) yang akan melanggar predikat blok.
Predikat filter dan blok dibuat sebagai fungsi bernilai tabel sebaris. Anda juga perlu menggunakan pernyataan T-SQL CREATE SECURITY POLICY untuk menerapkan dan mengaktifkan fungsi pemfilteran ke tabel dasar yang relevan
RLS telah ditambahkan di SQL Server 2016 dan tersedia di semua edisi SQL Server 2016 dan yang lebih baru. RLS tidak akan berfungsi dengan Filestream, Polybase, dan tampilan yang diindeks. RLS dapat merusak kinerja Pencarian Teks Lengkap dan dapat memaksa kueri indeks penyimpanan kolom untuk berakhir menggunakan mode baris alih-alih mode batch. Posting blog Microsoft ini memiliki informasi lebih lanjut tentang dampak kinerja RLS. Contoh bagus tentang cara menggunakan Query Store untuk menyempurnakan kinerja RLS ada di sini.
Penutupan Data Dinamis (DDM)
Penyembunyian data dinamis (DDM) dapat membantu membatasi paparan data sensitif dengan menutupinya ke pengguna yang tidak memiliki hak istimewa. DDM diterapkan pada tingkat tabel sehingga semua kueri dipengaruhi oleh penyembunyian data, sedangkan aturan penyembunyian yang sebenarnya diterapkan di masing-masing kolom dalam tabel.
Ada empat jenis topeng data yang dapat Anda gunakan, yang meliputi default, email, string khusus, dan acak. Mask default menyediakan masking default penuh dari data tergantung pada tipe data. Misalnya, tipe data string akan mendapatkan topeng 'XXXX' alih-alih data aktual. Masker email akan mengembalikan huruf pertama dari alamat email yang sebenarnya, diikuti dengan [email protected], terlepas dari akhiran domain yang sebenarnya. Masker string khusus akan menampilkan huruf pertama dan terakhir dari string, dengan bantalan khusus di tengahnya. Akhirnya, topeng acak digunakan untuk menutupi data numerik dan memberikan nilai acak dalam rentang yang ditentukan. Masker data dapat dibuat dalam pernyataan CREATE TABLE atau dengan pernyataan ALTER COLUMN.
Penyembunyian data dinamis tidak memberikan penyembunyian bagi pengguna yang memiliki hak istimewa yang masih dapat secara langsung menanyakan tabel Anda dan melihat data yang dibuka penyamarannya. Aturan penyembunyian tidak dapat digunakan dengan kolom terenkripsi (Selalu Dienkripsi), kolom yang dihitung, atau dengan data Filestream. Jika sudah ada indeks pada kolom yang ingin Anda sembunyikan, Anda harus menghapus indeks, membuat topeng di kolom, lalu membuat ulang indeks. Dimungkinkan juga untuk menyimpulkan nilai untuk kolom data bertopeng dengan menulis kueri yang memungkinkan pengguna akhirnya menebak nilai untuk kolom bertopeng.
Penyembunyian Data Dinamis diperkenalkan di SQL Server 2016, dan tersedia di semua edisi SQL Server. DDM tidak dimaksudkan untuk menjadi ukuran keamanan yang kuat seperti enkripsi yang sebenarnya, tetapi di sisi lain, dampak kinerjanya tampaknya cukup kecil.
