Cara Mengamankan Cluster Galera - 8 Tips

Sebagai sistem database terdistribusi, Galera Cluster membutuhkan langkah-langkah keamanan tambahan dibandingkan dengan database terpusat. Data didistribusikan di beberapa server atau bahkan pusat data mungkin. Dengan komunikasi data yang signifikan terjadi di seluruh node, dapat terjadi paparan yang signifikan jika tindakan keamanan yang sesuai tidak dilakukan.

Dalam posting blog ini, kita akan melihat beberapa tips tentang cara mengamankan Cluster Galera kita. Perhatikan bahwa blog ini dibuat berdasarkan posting blog kami sebelumnya - Cara Mengamankan Basis Data Sumber Terbuka Anda dengan ClusterControl.

Firewall &Grup Keamanan

Port berikut sangat penting untuk Cluster Galera:

• 3306 - MySQL
• 4567 - Komunikasi dan replikasi Galera
• 4568 - Galera IST
• 4444 - Galera SST

Dari jaringan eksternal, disarankan untuk hanya membuka akses ke port MySQL 3306. Tiga port lainnya dapat ditutup dari jaringan eksternal, dan hanya mengizinkannya untuk akses internal antara node Galera. Jika Anda menjalankan proxy terbalik yang berada di depan node Galera, misalnya HAProxy, Anda dapat mengunci port MySQL dari akses publik. Pastikan juga port pemantauan untuk skrip pemantauan HAProxy dibuka. Port default adalah 9200 pada node Galera.

Diagram berikut mengilustrasikan contoh penyiapan kami pada Galera Cluster tiga simpul, dengan HAProxy menghadap jaringan publik dengan port terkait:

Berdasarkan diagram di atas, perintah iptables untuk node database adalah:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

Saat berada di penyeimbang beban:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Pastikan untuk mengakhiri aturan firewall Anda dengan tolak semua, jadi hanya lalu lintas seperti yang ditentukan dalam aturan pengecualian yang diizinkan. Anda dapat lebih ketat dan memperluas perintah untuk mengikuti kebijakan keamanan Anda - misalnya, dengan menambahkan antarmuka jaringan, alamat tujuan, alamat sumber, status koneksi, dan lainnya.

Enkripsi Server Klien MySQL

MySQL mendukung enkripsi antara klien dan server. Pertama kita harus membuat sertifikat. Setelah dikonfigurasi, Anda dapat menerapkan akun pengguna untuk menentukan opsi tertentu untuk terhubung dengan enkripsi ke server MySQL.

Langkah-langkahnya mengharuskan Anda untuk:

1. Buat kunci untuk Otoritas Sertifikat (ca-key.pem)
2. Buat sertifikat CA yang ditandatangani sendiri (ca-cert.pem)
3. Buat kunci untuk sertifikat server (server-key.pem)
4. Buat sertifikat untuk server dan tandatangani dengan ca-key.pem (server-cert.pem)
5. Buat kunci untuk sertifikat klien (client-key.pem)
6. Buat sertifikat untuk klien dan tandatangani dengan ca-key.pem (client-cert.pem)

Selalu berhati-hati dengan kunci pribadi CA (ca-key.pem) - siapa pun yang memiliki akses ke kunci tersebut dapat menggunakannya untuk membuat sertifikat klien atau server tambahan yang akan diterima sebagai sah saat verifikasi CA diaktifkan. Intinya adalah semua kunci harus dijaga kerahasiaannya.

Anda kemudian dapat menambahkan variabel terkait SSL di bawah arahan [mysqld], misalnya:

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Mulai ulang server MySQL untuk memuat perubahan. Kemudian buat pengguna dengan pernyataan REQUIRE SSL, misalnya:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

Pengguna yang dibuat dengan REQUIRE SSL akan dipaksa untuk terhubung dengan file SSL klien yang benar (client-cert.pem, client-key.pem dan ca-cert.pem).

Dengan ClusterControl, enkripsi SSL client-server dapat dengan mudah diaktifkan dari UI, menggunakan fitur "Buat Enkripsi SSL".

Enkripsi Galera

Mengaktifkan enkripsi untuk Galera berarti IST juga akan dienkripsi karena komunikasi terjadi melalui soket yang sama. SST, di sisi lain, harus dikonfigurasi secara terpisah seperti yang ditunjukkan pada bagian berikutnya. Semua node dalam cluster harus diaktifkan dengan enkripsi SSL dan Anda tidak dapat memiliki campuran node di mana beberapa telah mengaktifkan enkripsi SSL, dan yang lainnya tidak. Waktu terbaik untuk mengonfigurasi ini adalah saat menyiapkan cluster baru. Namun, jika Anda perlu menambahkan ini pada sistem produksi yang sedang berjalan, sayangnya Anda perlu me-rebootstrap cluster dan akan ada waktu henti.

Semua node Galera di cluster harus menggunakan kunci, sertifikat, dan CA yang sama (opsional). Anda juga dapat menggunakan kunci dan sertifikat yang sama yang dibuat untuk enkripsi server-klien MySQL, atau membuat set baru hanya untuk tujuan ini. Untuk mengaktifkan enkripsi di dalam Galera, kita harus menambahkan opsi dan nilai di bawah wsrep_provider_options di dalam file konfigurasi MySQL pada setiap node Galera. Misalnya, pertimbangkan baris berikut yang ada untuk simpul Galera kami:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Tambahkan variabel terkait di dalam kutipan, dibatasi oleh titik koma:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Untuk info lebih lanjut tentang parameter terkait SSL Galera, lihat di sini. Lakukan modifikasi ini pada semua node. Kemudian, hentikan cluster (satu node pada satu waktu) dan bootstrap dari node terakhir yang dimatikan. Anda dapat memverifikasi apakah SSL dimuat dengan benar dengan melihat ke log kesalahan MySQL:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Dengan ClusterControl, enkripsi Replikasi Galera dapat dengan mudah diaktifkan menggunakan fitur "Buat Enkripsi Galera SSL".

Enkripsi SST

Ketika SST terjadi tanpa enkripsi, komunikasi data diekspos saat proses SST sedang berlangsung. SST adalah proses sinkronisasi data lengkap dari donor ke node joiner. Jika penyerang dapat "melihat" transmisi data lengkap, orang tersebut akan mendapatkan cuplikan lengkap dari database Anda.

SST dengan enkripsi hanya didukung untuk metode mysqldump dan xtrabackup-v2. Untuk mysqldump, pengguna harus diberikan "REQUIRE SSL" di semua node dan konfigurasinya mirip dengan enkripsi SSL client-server MySQL standar (seperti yang dijelaskan di bagian sebelumnya). Setelah enkripsi client-server diaktifkan, buat pengguna SST baru dengan SSL yang diberlakukan:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

Untuk rsync, kami sarankan menggunakan galera-secure-rsync, skrip SST rsync rsync drop-in yang diamankan SSL untuk Galera Cluster. Ini beroperasi hampir persis seperti wsrep_sst_rsync kecuali bahwa itu mengamankan komunikasi aktual dengan SSL menggunakan socat. Buat kunci klien/server dan file sertifikat yang diperlukan, salin ke semua node dan tentukan "secure_rsync" sebagai metode SST di dalam file konfigurasi MySQL untuk mengaktifkannya:

wsrep_sst_method=secure_rsync

Untuk xtrabackup, opsi konfigurasi berikut harus diaktifkan di dalam file konfigurasi MySQL di bawah direktif [sst]:

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Restart basis data tidak diperlukan. Jika node ini dipilih oleh Galera sebagai donor, opsi konfigurasi ini akan diambil secara otomatis saat Galera memulai SST.

SELinux

Security-Enhanced Linux (SELinux) adalah mekanisme kontrol akses yang diterapkan di kernel. Tanpa SELinux, hanya metode kontrol akses tradisional seperti izin file atau ACL yang digunakan untuk mengontrol akses file pengguna.

Secara default, dengan mode penegakan ketat diaktifkan, semuanya ditolak dan administrator harus membuat serangkaian kebijakan pengecualian untuk elemen sistem yang diperlukan agar berfungsi. Menonaktifkan SELinux sepenuhnya telah menjadi praktik buruk yang umum bagi banyak instalasi berbasis RedHat saat ini.

Bergantung pada beban kerja, pola penggunaan, dan proses, cara terbaik adalah membuat modul kebijakan SELinux Anda sendiri yang disesuaikan untuk lingkungan Anda. Yang benar-benar perlu Anda lakukan adalah menyetel SELinux ke mode permisif (hanya masuk tanpa penegakan), dan memicu peristiwa yang dapat terjadi pada simpul Galera agar SELinux dapat masuk. Semakin luas semakin baik. Contoh acara seperti:

• Memulai node sebagai donor atau joiner
• Mulai ulang simpul untuk memicu IST
• Gunakan metode SST yang berbeda
• Cadangkan dan pulihkan database MySQL menggunakan mysqldump atau xtrabackup
• Mengaktifkan dan menonaktifkan log biner

Salah satu contohnya adalah jika node Galera dipantau oleh ClusterControl dan fitur monitor kueri diaktifkan, ClusterControl akan mengaktifkan/menonaktifkan variabel log kueri lambat untuk menangkap kueri yang berjalan lambat. Dengan demikian, Anda akan melihat penolakan berikut di audit.log:

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

Idenya adalah untuk membiarkan semua kemungkinan penolakan masuk ke log audit, yang nantinya dapat digunakan untuk membuat modul kebijakan menggunakan audit2allow sebelum memuatnya ke SELinux. Codership telah membahas ini secara rinci di halaman dokumentasi, Konfigurasi SELinux.

Akun dan Hak Istimewa SST

SST adalah proses sinkronisasi awal yang dilakukan oleh Galera. Ini membawa node joiner up-to-date dengan sisa anggota di cluster. Proses pada dasarnya mengekspor data dari node donor dan mengembalikannya pada node joiner, sebelum joiner diizinkan untuk mengejar sisa transaksi dari antrian (yaitu, yang terjadi selama proses sinkronisasi). Tiga metode SST didukung:

• mysqldump
• rsinkronkan
• xtrabackup (atau xtrabackup-v2)

Untuk penggunaan mysqldump SST, hak istimewa berikut diperlukan:

• PILIH, TAMPILKAN TAMPILAN, PEMICU, KUNCI TABEL, MUAT ULANG, FILE

Kami tidak akan melangkah lebih jauh dengan mysqldump karena mungkin tidak sering digunakan dalam produksi sebagai metode SST. Selain itu, ini adalah prosedur pemblokiran pada donor. Rsync biasanya merupakan pilihan kedua yang lebih disukai setelah xtrabackup karena waktu sinkronisasi yang lebih cepat, dan lebih sedikit rawan kesalahan dibandingkan dengan mysqldump. Otentikasi SST diabaikan dengan rsync, oleh karena itu Anda dapat melewati konfigurasi hak akun SST jika rsync adalah metode SST yang dipilih.

Bergerak bersama dengan xtrabackup, hak istimewa berikut disarankan untuk prosedur pencadangan dan pemulihan standar berdasarkan halaman dokumentasi Xtrabackup:

• BUAT, BUAT TABLESPACE, EVENT, INSERT, LOCK TABLE, PROCESS, RELOAD, REPLICATION CLIENT, SELECT, SHOW VIEW, SUPER

Namun untuk penggunaan SST xtrabackup, hanya hak istimewa berikut yang penting:

• PROSES, RELOAD, REPLICATION CLIENT

Dengan demikian, pernyataan GRANT untuk SST dapat diminimalkan sebagai:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Kemudian, konfigurasikan wsrep_sst_auth sesuai di dalam file konfigurasi MySQL:

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Hanya berikan pengguna SST untuk localhost dan gunakan kata sandi yang kuat. Hindari menggunakan pengguna root sebagai akun SST, karena akan mengekspos kata sandi root di dalam file konfigurasi di bawah variabel ini. Selain itu, mengubah atau menyetel ulang kata sandi root MySQL akan merusak SST di masa mendatang.

Pengerasan Keamanan MySQL

Galera Cluster adalah plugin replikasi multi-master untuk mesin penyimpanan InnoDB, yang berjalan di fork MySQL dan MariaDB. Oleh karena itu, rekomendasi pengerasan keamanan MySQL/MariaDB/InnoDB standar juga berlaku untuk Galera Cluster.

Topik ini telah dibahas dalam banyak posting blog di luar sana. Kami juga telah membahas topik ini dalam posting blog berikut:

• Sepuluh Tips Cara Mencapai Keamanan MySQL dan MariaDB
• Tips &Trik ClusterControl:Mengamankan Instalasi MySQL Anda
• Cara Mengamankan Database Open Source Anda dengan ClusterControl

Postingan blog di atas merangkum perlunya mengenkripsi data saat istirahat dan data dalam perjalanan, memiliki plugin audit, pedoman keamanan umum, praktik terbaik keamanan jaringan, dan sebagainya.

Gunakan Penyeimbang Beban

Ada sejumlah penyeimbang beban basis data (proksi terbalik) yang dapat digunakan bersama dengan Galera - HAProxy, ProxySQL, dan MariaDB MaxScale untuk menyebutkan beberapa di antaranya. Anda dapat mengatur penyeimbang beban untuk mengontrol akses ke node Galera Anda. Ini adalah cara yang bagus untuk mendistribusikan beban kerja database di antara instans database, serta membatasi akses, misalnya, jika Anda ingin membuat node offline untuk pemeliharaan, atau jika Anda ingin membatasi jumlah koneksi yang dibuka di node Galera. Penyeimbang beban harus dapat mengantrekan koneksi, dan oleh karena itu memberikan perlindungan kelebihan beban ke server database Anda.

ProxySQL, database reverse-proxy yang kuat yang memahami MySQL dan MariaDB, dapat diperluas dengan banyak fitur keamanan yang berguna seperti firewall kueri, untuk memblokir kueri yang menyinggung dari server database. Mesin aturan kueri juga dapat digunakan untuk menulis ulang kueri buruk menjadi sesuatu yang lebih baik/aman, atau mengarahkannya ke server lain yang dapat menyerap beban tanpa memengaruhi node Galera mana pun. MariaDB MaxScale juga mampu memblokir kueri berdasarkan ekspresi reguler dengan filter Database Firewall-nya.

Keuntungan lain memiliki penyeimbang beban untuk Galera Cluster Anda adalah kemampuan untuk meng-host layanan data tanpa memaparkan tingkat basis data ke jaringan publik. Server proxy dapat digunakan sebagai bastion host untuk mendapatkan akses ke node database di jaringan pribadi. Dengan mengisolasi kluster basis data dari dunia luar, Anda telah menghapus salah satu vektor penyerang yang penting.

Itu dia. Selalu tetap aman dan terlindungi.