Mysql
 sql >> Teknologi Basis Data >  >> RDS >> Mysql

Keamanan Basis Data - Enkripsi Cadangan Saat Transit &Saat Istirahat

Mengamankan data Anda adalah salah satu tugas terpenting yang harus kami prioritaskan. Munculnya peraturan yang memerlukan kepatuhan keamanan seperti GDPR, HIPAA, PCI DSS, atau PHI mengharuskan data Anda disimpan dengan aman atau dikirim melalui kabel.

Di ClusterControl, kami menghargai pentingnya keamanan dan menawarkan sejumlah fitur untuk mengamankan akses database dan data yang disimpan. Salah satunya adalah mengamankan cadangan database Anda, baik saat istirahat maupun dalam perjalanan. In-transit adalah saat cadangan sedang ditransfer melalui internet atau jaringan dari sumber ke tujuannya, sedangkan saat istirahat adalah saat data disimpan di penyimpanan persisten. Di blog ini, kami akan menunjukkan kepada Anda bagaimana Anda dapat menggunakan ClusterControl untuk mengenkripsi data cadangan Anda saat istirahat dan dalam perjalanan.

Enkripsi Dalam Transit

Saat mengelola cadangan melalui ClusterControl, menggunakan mysqldump atau Percona Xtrabackup/Mariabackup dikelola secara default tanpa enkripsi saat dikirimkan melalui kabel. Namun, penggunaan TLS/SSL untuk enkripsi transmisi data didukung oleh Server MySQL/MariaDB/Percona, begitu pula Percona Xtrabackup yang menawarkan opsi SSL saat menjalankan perintah.

ClusterControl memang mengaktifkan SSL secara default ketika Anda menggunakan sebuah cluster tetapi tidak memiliki kontrol untuk beralih secara instan dan membuat data Anda dienkripsi melalui kabel selama pembuatan cadangan. Anda dapat melihat blog kami sebelumnya untuk pendekatan manual menggunakan ClusterControl saat membuat cluster Anda atau menggunakan cara lama untuk menyiapkan TLS/SSL di MySQL secara manual.

Di ClusterControl, saat Anda menerapkan cluster, Anda dapat memeriksa tab keamanan atau ikon ini .

Mengklik akan memungkinkan Anda untuk mengganti sertifikat yang saat ini sedang digunakan atau digunakan oleh ClusterControl selama penerapan yang baru Anda sediakan gugus. Anda dapat memeriksa blog ini "Diperbarui:Menjadi ClusterControl DBA - Manajemen Kunci SSL dan Enkripsi Data MySQL dalam Transit" yang kami tunjukkan bagaimana kami menangani kuncinya. Pada dasarnya, Anda dapat melalui navigasi sisi kiri ClusterControl dan klik “Manajemen Kunci”.

Di bawah ini adalah contoh Manajemen Kunci di mana Anda dapat membuat dan mengimpor kunci yang ada.

Saat membuat cadangan menggunakan mysqldump sebagai cadangan logis Anda, untuk mengenkripsi data Anda, pastikan Anda telah menyetel opsi SSL yang sesuai.

Apa selanjutnya?

Karena kami memiliki sertifikat yang kami buat, kami perlu mengaktifkan dan mengatur SSL yang sesuai. Untuk memastikan ini, Anda dapat memeriksa melalui ClusterControl atau command prompt mysql. Lihat gambar di bawah ini:

atau bisa cek juga di tab Performance dan klik DB Variables seperti di bawah ini:

Perhatikan bahwa mungkin perlu beberapa waktu untuk mengisi di bawah Performance -> DB Variables. Jadi jika ingin mengecek secara manual bisa menggunakan command prompt mysql seperti di bawah ini:

Mendefinisikan ssl_cipher Anda dapat menambah lebih banyak penguatan keamanan. Ada daftar cipher suite jika Anda menjalankan SHOW GLOBAL STATUS LIKE 'Ssl_cipher_list'\G atau cek di sini. Sebuah cipher suite adalah kombinasi dari otentikasi, enkripsi dan algoritma kode otentikasi pesan (MAC). Ini digunakan selama negosiasi setelan keamanan untuk koneksi TLS/SSL serta untuk transfer data yang aman.

Karena ClusterControl akan menjalankan mysqldump secara lokal ke host tersebut, tambahkan parameter berikut (lihat di bawah) di file konfigurasi MySQL Anda (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) akan mengenkripsi tindakan apa pun untuk SQL dump. Lihat di bawah:

[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pem

Anda dapat mencoba memantau menggunakan tcpdump dan Anda dapat melihat di bawah ini dibandingkan dengan lapisan tidak terenkripsi vs terenkripsi menggunakan TLS.

Dengan TLS/SSL:

Tanpa TLS/SSL:

Saat menggunakan Percona XtraBackup atau Mariabackup di bawah ClusterControl, tidak ada dukungan TLS/SSL saat ini ketika cadangan dikirimkan melalui jaringan. Ini menggunakan socat yang pada dasarnya hanya membuka port ke node lain sebagai sarana komunikasi.

mis.

[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.

Jika Anda membutuhkan lapisan aman selama pengangkutan, Anda dapat melakukannya secara manual menggunakan opsi --ssl* selama pemanggilan perintah. Lihat di sini untuk manual Percona XtraBackup untuk info lebih lanjut. Kami tetap menyarankan untuk mendapatkan sertifikat/kunci Anda dari otoritas sertifikat terdaftar.

Atau, menggunakan ClusterControl, Anda dapat mengenkripsi data Anda sebelum mengirim melalui jaringan, paket yang dikirim bukan data mentah tetapi data terenkripsi. Meskipun, enkripsi bergantung pada keadaan diam, kita akan membahasnya di bagian selanjutnya mengenai hal ini.

Enkripsi Saat Istirahat

Di ClusterControl, saat membuat cadangan, Anda memiliki opsi untuk membuat data Anda dienkripsi. Lihat di bawah:

Saat dienkripsi, ClusterControl akan menggunakan “Advance Encryption Standard” AES-256-CBC. Lihat contoh log di bawah ini:

[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.

Jika Anda menyimpan cadangan ke cloud, misalnya dengan AWS S3, S3 menawarkan tiga mode enkripsi sisi server (SSE) yang berbeda. Ini adalah SSE-S3, SSE-C, atau SSE-KMS. Amazon memiliki fitur SSE hebat untuk ditawarkan yang menangani enkripsi data saat istirahat. Anda dapat mulai di sini yang menangani bagaimana S3 menggunakan AWS KMS. Jika Anda memindahkan cadangan ke penyimpanan berbasis volume atau blok, AWS juga memiliki enkripsi EBS menggunakan AWS KMS. Anda dapat memeriksa di sini untuk info lebih lanjut tentang ini.

Microsoft Azure juga memiliki fitur keren saat menangani data saat istirahat. Lihat halaman di "Enkripsi Layanan Penyimpanan Azure untuk data saat istirahat". Azure menangani kunci di Azure Key Vault mereka, sama seperti AWS KMS. Untuk enkripsi Google untuk data tidak aktif, Anda dapat memeriksa di sini.

Saat menyimpan cadangan data di tempat, Anda dapat menggunakan LUKS (Linux Unified Key Setup) dengan kombinasi crypt atau dmcrypt. Saya tidak akan membahas tentang ini di blog ini tetapi ini adalah sumber yang bagus untuk dilihat:Enkripsi MySQL saat Istirahat – Bagian 1 (LUKS). Untuk info lebih lanjut tentang enkripsi disk, halaman ArchLinux "Enkripsi disk" ini adalah sumber yang bagus untuk memulai .

Yang terpenting, saat data Anda telah dienkripsi saat istirahat dan dalam perjalanan, selalu pastikan bahwa cadangan Anda berfungsi. Cadangan yang belum diuji bukanlah cadangan jika tidak berfungsi saat pemulihan diperlukan. Menyimpan cadangan Anda juga saat dienkripsi harus didekripsi tanpa masalah, oleh karena itu, kunci Anda harus disimpan secara pribadi dan dengan cara yang seaman mungkin. Selain itu, menambahkan enkripsi ke data Anda juga seperti enkripsi InnoDB atau SST (untuk Galera) menambahkan lebih banyak keamanan, tetapi kami tidak akan membahasnya di blog ini.

Kesimpulan

Mengenkripsi data cadangan saat istirahat dan dalam perjalanan merupakan komponen penting untuk kepatuhan terhadap PHI, HIPAA, PCI DSS, atau GDPR, untuk memastikan bahwa data sensitif yang dikirimkan melalui kabel atau disimpan pada disk tidak dapat dibaca oleh pengguna atau aplikasi mana pun tanpa kunci yang valid. Beberapa peraturan kepatuhan seperti PCI DSS dan HIPAA mengharuskan data diam dienkripsi sepanjang siklus hidup data.

Di sini, kami menunjukkan bagaimana ClusterControl menawarkan opsi ini kepada pengguna akhir. Kepatuhan adalah tugas besar, menyentuh banyak bidang yang berbeda. Peraturan juga sering diperbarui, dan proses/alat juga perlu diperbarui. Kami terus meningkatkan berbagai area di ClusterControl untuk memfasilitasi kepatuhan. Kami ingin mendengar pendapat Anda tentang hal ini dan bagaimana kami dapat meningkatkannya.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Kesalahan MySQL 1241:Operan harus berisi 1 kolom

  2. Buat variabel tabel di MySQL

  3. Impor Data dari Excel Spreadsheet atau CVS ke MySQL

  4. Bagaimana cara menambahkan batasan bukan nol ke kolom yang ada di MySQL

  5. Ubah teks menjadi angka dalam kueri MySQL