Enkripsi Tingkat Kolom di MySQL – Percona Database Performance Blog

Database


Enkripsi tingkat kolom di MySQLDi sebuah Postingan yang ditulis awal tahun ini – Server Percona untuk opsi dan opsi enkripsi MySQL Saya membahas beberapa opsi enkripsi di MySQL. Karena itu adalah topik yang kompleks, postingan itu dimaksudkan untuk mengklarifikasi dan menyoroti berbagai aspek “enkripsi” pada tingkat yang berbeda. Saya mengangkat topik ini lagi baru-baru ini, tetapi secara khusus tentang penyandian tingkat kolom dan berbagai opsi, jadi saya ingin menyentuh ini secara lebih rinci.

Pada rilis Percona Server untuk MySQL saat ini, tidak ada metode bawaan untuk mendefinisikan kolom sebagai terenkripsi. Idealnya, beberapa metadata mungkin diteruskan dalam pernyataan buat dan ini akan terjadi secara otomatis, seperti ini:

Sayangnya, opsi ini tidak tersedia dan kita perlu memanipulasi data pada atau sebelum waktu baca/tulis.

Fungsi enkripsi bawaan MySQL

Salah satu pendekatan yang paling umum adalah dengan menggunakan fungsi enkripsi bawaan MySQL, yang dijelaskan di sini: https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html. Aliran standar kira-kira sebagai berikut:

Ini berfungsi dengan baik dan data disimpan terenkripsi untuk kolom itu. Jika orang yang tidak berwenang mendapatkan akses ke tabel yang sedang berjalan, mereka tidak dapat membaca kolom itu tanpa kunci. Perhatian terbesar dengan pendekatan ini adalah bahwa kunci plaintext dan data plaintext keduanya ditentukan dalam kueri. Hal ini menyebabkan potensi kebocoran dalam file log (kueri lambat, log biner, dll.) serta kemungkinan penyadapan pada jaringan yang tidak aman (yaitu koneksi yang tidak menggunakan SSL).

Juga, penyimpanan kunci bisa menjadi lebih rumit. Jika Anda berencana untuk berbagi kunci yang sama untuk seluruh tabel, rotasi dan manajemen kunci dapat menjadi hal yang sepele. Praktik terbaik umum menyarankan Anda memutar kunci setidaknya setahun sekali. Di meja besar, ini bisa menjadi usaha besar. Mari kita lihat pola enkripsi amplop sebagai alternatif.

Enkripsi amplop

Tidak seperti menggunakan enkripsi internal, enkripsi amplop menggunakan konsep kunci data individual. Meskipun ada banyak cara untuk mendekati ini, pengalaman pribadi saya menggunakan layanan AWS KMS. Di KMS, Anda dapat membuat sesuatu yang disebut “Kunci Master Pelanggan” (CMK). Ini bagus untuk mengenkripsi string kecil seperti kata sandi, tetapi terbatas untuk mengenkripsi string hingga 4KB.

Pendekatan yang lebih fleksibel adalah dengan menggunakan kunci data terpisah, mengenkripsi data secara lokal di aplikasi, dan kemudian menyimpan data terenkripsi dengan kunci data terenkripsi. Ini dapat dilakukan pada berbagai tingkat detail – mulai dari tingkat per baris, hingga tingkat tabel, hingga tingkat basis data. Berikut adalah proses umum untuk mengenkripsi amplop:

Saat Anda perlu mendekripsi data, pertama-tama Anda mendekripsi kunci dan kemudian menggunakannya untuk mendekripsi data:

Karena kunci data dan data dienkripsi, aman untuk menyimpan keduanya bersama-sama. Ini adalah salah satu keuntungan utama dari metode ini. Anda dapat memiliki ratusan hingga jutaan kunci data independen tetapi dilindungi oleh satu kunci utama. Ini memungkinkan Anda untuk menonaktifkan semua kunci individual dengan menonaktifkan satu kunci utama.

Ini juga menyederhanakan rotasi kunci – Anda cukup memutar kunci asli dan mulai menggunakan kunci baru untuk menghasilkan kunci data baru. Perhatikan bahwa ini tidak mengenkripsi ulang data, tetapi memungkinkan Anda untuk mengikuti praktik terbaik memutar kunci secara berkala. Selama Anda tidak menghapus salah satu kunci lama, KMS dapat menentukan kunci mana yang akan digunakan untuk mendekripsi kunci itu sendiri dan secara otomatis mendekripsi data Anda (yaitu Anda tidak perlu menentukan kunci mana yang akan digunakan untuk mengenkripsi data). selesai).

Saya telah menyertakan tautan ke contoh skrip dengan Python yang mendemonstrasikan proses ini secara lebih rinci. Meskipun sebenarnya tidak ada database yang berjalan dalam demo, kode tersebut mencetak pernyataan INSERT dan SELECT yang dapat dijalankan terhadap server langsung: https://github.com/mbenshoof/kms-envelope-demo

Tantangan dengan enkripsi tingkat kolom

Cari

Tak perlu dikatakan, memperkenalkan enkripsi tingkat kolom bukanlah tugas yang sepele. Salah satu tantangan terbesar adalah mencari tahu bagaimana memulihkan data terenkripsi. Misalnya, jika saya menyimpan nomor Jaminan Sosial secara terpisah, bagaimana cara mencari pengguna dengan SSN 123-45-6789? Jika saya menggunakan kunci bersama untuk seluruh tabel/Anda, dimungkinkan dengan pengindeksan yang tepat. Saya hanya perlu meneruskan nilai yang disandikan ke klausa Where dan jika ada, itu harus ditemukan.

Namun, dalam model per baris di mana setiap baris menggunakan kunci unik, hal ini tidak mungkin lagi. Karena saya tidak tahu kunci yang digunakan untuk mengenkripsi nilai, saya tidak dapat mencari nilai terenkripsi dalam tabel. Dalam kasus seperti ini, Anda dapat mempertimbangkan bidang hash satu arah yang dapat dicari. Misalnya, Anda dapat menyimpan hash SHA256 dari SSN sebagai kolom tambahan untuk pencarian, tetapi kemudian mendekripsi informasi sensitif lainnya.

CPU dan ruang overhead

Tantangan lain adalah menambahkan overhead tulis/baca tambahan untuk menangani enkripsi dan dekripsi. Meskipun ini mungkin atau mungkin tidak bermasalah tergantung pada kasus penggunaan, CPU tambahan yang diperlukan di sisi aplikasi atau sisi MySQL dapat ikut bermain. Anda harus mempertimbangkan dan memperhitungkan pemrosesan tambahan yang diperlukan saat merencanakan ukuran sumber daya Anda.

Selain itu, tergantung pada pustaka enkripsi yang digunakan, mungkin ada lebih banyak ruang untuk menyimpan nilai terenkripsi. Dalam beberapa kasus, nilai yang dikodekan (bila disimpan secara khusus di base64) mungkin memerlukan ruang penyimpanan yang lebih tinggi. Jika indeks digunakan dalam kolom hash tambahan, spasi dapat digabungkan. Untuk nilai kecil (seperti SSN), hash mungkin jauh lebih besar dari data sebenarnya. Ketika diterapkan ke jutaan catatan, ini dapat menghasilkan penyimpanan yang jauh lebih tinggi.

Penutupan

Enkripsi dan keamanan adalah masalah yang sangat penting dan kompleks. Saat mempertimbangkan enkripsi tingkat kolom di MySQL, Anda pasti memiliki opsi. Cara termudah adalah dengan hanya menggunakan fungsi enkripsi bawaan di MySQL. Namun, Anda dapat mengambil langkah lebih jauh dan mengelola semua enkripsi dan dekripsi dalam aplikasi Anda sendiri.

Seperti yang selalu terjadi pada topik kompleks seperti ini, pilihan dan pendekatan sepenuhnya bergantung pada kebutuhan dan kasus penggunaan Anda. Ketahuilah bahwa dengan fleksibilitas MySQL, kemungkinan ada desain dan pendekatan yang cocok untuk Anda!





Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.