Keamanan adalah yang terpenting saat ini di seluruh TI. Dari waktu ke waktu kami mendengar tentang serangan ransomware atau kebocoran data yang berasal dari basis data atau infrastruktur TI yang tidak aman. Anda mungkin bertanya-tanya:apa praktik terbaik dalam merancang lingkungan MySQL sehingga Anda dapat merasa aman tentang data Anda? Jika demikian, blog ini adalah untuk Anda. Harap diingat bahwa kami tidak akan membahas topik ini sepenuhnya - ini akan lebih cocok untuk whitepaper daripada blog. Kami akan melakukan yang terbaik untuk menyebutkan aspek terpenting dalam mengamankan database MySQL Anda. Ide di balik blog ini adalah agar pembaca mengetahui apa yang tidak diketahuinya dan membantu mengidentifikasi topik dan kata kunci untuk penelitian lebih lanjut. Kami akan mengilustrasikannya dengan tangkapan layar dari produk kami, ClusterControl, yang hadir dengan serangkaian fitur yang luas, termasuk beberapa seputar keamanan basis data.
Jaringan
Pertama-tama, kita harus men-deploy MySQL di suatu tempat. Baik itu instans mandiri, replikasi primer - replika asinkron, atau salah satu topologi replikasi sinkron yang lebih canggih seperti Galera atau InnoDB Cluster. Tidak peduli apa itu, itu harus dilindungi di tingkat jaringan. Basis data berisi data, yang biasanya merupakan aset paling berharga dari keseluruhan organisasi.
Mengamankan akses
Instance database tidak boleh berada di jaringan publik. Segmen jaringan di mana database dikonfigurasi harus dapat diakses hanya dari sejumlah jaringan lain. Aturan praktisnya adalah - haruskah node tertentu dapat mengakses jaringan database? Jika jawabannya tidak, jaringan harus dipisahkan.
Tentu saja, itu semua tergantung pada pengaturan yang tepat tetapi dalam kasus yang paling umum, di mana Anda memiliki lapisan aplikasi, proxy, cache dan basis data, pengaturan yang paling umum adalah bahwa hanya proxy yang dapat untuk mengakses database. Semua entitas lain harus dikonfigurasi sedemikian rupa sehingga mereka mengakses database hanya melalui lapisan proxy. Desain ini bagus dalam banyak hal. Selain peningkatan keamanan, ini juga membantu menyembunyikan kompleksitas tingkat basis data dari aplikasi.
Lapisan proxy harus mengikuti topologi database dan harus menangani kegagalan node database dan perubahan topologi. Aplikasi, yang terhubung ke lapisan proxy, harus selalu dapat menjangkau node database yang berfungsi yang relevan dengan jenis permintaan. Hal yang sama dengan lapisan cache. Itu dapat diimplementasikan di lapisan proxy, beberapa proxy seperti ProxySQL mengizinkan permintaan cache di dalam proxy, tetapi jika itu adalah lapisan terpisah yang dibangun di sekitar, misalnya, memcache atau Redis, itu harus selalu menjangkau database melalui lapisan proxy.
Satu lagi jenis node yang mungkin perlu memiliki akses langsung ke lapisan database adalah node manajemen - node yang digunakan oleh tim operasional untuk mengelola database. Alasannya sederhana:beberapa tugas pemeliharaan mungkin memerlukan akses langsung ke database. Ini bisa berupa skrip otomatisasi tugas, menggulirkan buku pedoman yang memungkinkan di seluruh armada basis data atau tugas lainnya. Dalam hal ini, tentu saja, langkah-langkah keamanan harus dilakukan untuk memastikan bahwa hanya orang yang memiliki akses yang dapat masuk ke node manajemen tersebut.
Jenis node lain yang mungkin (walaupun node manajemen juga dapat digunakan untuk itu) yang mungkin memerlukan akses ke database adalah node yang terlibat dalam pengumpulan metrik dan menyajikannya kepada pengguna - kita berbicara di sini tentang pemantauan dan aktivitas peringatan.
VPN
Untuk segala jenis tingkat basis data yang mencakup beberapa pusat data, Anda harus mempertimbangkan untuk menggunakan VPN untuk menghubungkannya. Koneksi terbuka dan tidak terenkripsi melalui jaringan WAN adalah sesuatu yang seharusnya tidak pernah terjadi. Bahkan menyiapkan enkripsi SSL bukanlah pilihan terbaik karena akan memerlukan akses terbuka antara tingkat database dan WAN - koneksi SSL antara node database mengharuskan mereka untuk dapat terhubung secara langsung. VPN memecahkan masalah ini dengan menambahkan perantara yang menciptakan cara aman untuk menghubungkan segmen jaringan tingkat basis data.
VPN juga harus diwajibkan untuk semua jenis akses pengguna ke jaringan organisasi karena VPN ini mengimplementasikan konektivitas aman antara stasiun kerja dan jaringan produksi.
Firewall
Tentu saja, saat mengamankan jaringan, kita harus mempertimbangkan untuk menggunakan firewall. Secara umum, setiap node basis data hanya boleh menerima koneksi dari kumpulan sumber yang ditentukan - nama host dan port. Bahkan segmen jaringan yang "diperlukan" tidak boleh memiliki akses penuh ke jaringan basis data tetapi hanya ke port yang diperlukan. Jika proxy hanya perlu terhubung ke port database, maka tidak ada alasan untuk dapat mengakses port lain di node database. Harap perhatikan juga bahwa Anda tidak boleh menggunakan port default. Ini, jelas, keamanan oleh ketidakjelasan - setelah semua port terbuka di suatu tempat, tetapi membantu untuk menangani setidaknya beberapa gangguan keamanan yang menggunakan skrip otomatis. Ini tidak akan mencegah seseorang yang bertekad untuk mendapatkan akses tetapi dapat memperlambatnya (bila digabungkan dengan deteksi pemindaian port dan tindakan anti-pemindaian) sekaligus mencegah serangan otomatis agar tidak berhasil.
Keamanan Basis Data
Jaringan adalah garis pertahanan pertama, ada langkah-langkah keamanan lain dan praktik baik yang dapat Anda gunakan untuk meningkatkan keamanan Anda lebih jauh lagi. Beberapa di antaranya dapat diimplementasikan pada database itu sendiri.
Pengguna dan host
Basis data itu sendiri dapat digunakan untuk menerapkan kontrol dan pembatasan akses. Sebagai permulaan, Anda dapat menerapkan kontrol akses berbasis host, mencegah host selain dari daftar pendek node untuk masuk ke database. Tentu saja, jika Anda menggunakan firewall untuk membatasi akses, ini mungkin terdengar seperti duplikat tetapi tetap merupakan ide yang baik untuk membatasi akses pada database itu sendiri - Anda tidak pernah tahu kapan, secara tidak sengaja, firewall akan dinonaktifkan. Dalam kasus seperti itu, Anda masih memiliki perlindungan lapis kedua.
Yang ingin Anda terapkan di sini adalah daftar pengguna dan host database yang diizinkan untuk mengakses database. Kemungkinan besar yang harus Anda miliki adalah satu atau lebih pengguna yang diberikan akses dari host yang terletak di lapisan proxy. Seberapa detail kontrol akses yang Anda miliki bergantung pada sistem database yang Anda miliki. MySQL, misalnya, tidak mengizinkan kontrol mendetail atas network mask - hanya menggunakan /32, /24, /16 atau /8. Di PostgreSQL, di sisi lain, Anda dapat menggunakan semua jenis network mask.
Hibah
Jika ini yang diizinkan oleh basis data Anda, setiap pengguna harus memiliki seperangkat hibah yang ditentukan - memastikan bahwa hak istimewa yang diberikan kepada mereka adalah minimal yang diperlukan pengguna untuk melakukan tindakan yang harus dia lakukan . Sistem basis data mungkin memiliki serangkaian hak istimewa dan tingkat yang berbeda. Biasanya kami memiliki beberapa tingkat hak istimewa - global, memengaruhi seluruh server basis data, tingkat skema - pengguna yang diberikan mungkin memiliki hak istimewa yang berbeda yang ditetapkan untuk skema yang berbeda. Anda dapat memiliki hak istimewa pada tabel atau bahkan tingkat kolom. Seperti yang kami sebutkan sebelumnya, tujuannya adalah untuk membuat set hak istimewa minimal untuk setiap pengguna. Anda mungkin ingin memiliki setidaknya satu pengguna dengan hak istimewa tinggi - ini akan digunakan untuk mengelola database. Pengguna seperti itu harus dibatasi secara ketat dalam hal konektivitas. Seharusnya tidak (dan pada kenyataannya tidak satu pun dari pengguna tidak boleh) diizinkan untuk terhubung dari lokasi mana pun - itu harus berupa localhost, atau beberapa node manajemen tertentu, yang didedikasikan untuk melakukan operasi pada database.
Manajemen kata sandi
Setiap pengguna dalam database harus memiliki kata sandi yang ditentukan. Ini adalah tidak punya otak. Kata sandi harus disimpan dalam bentuk hash. Anda harus memastikan bahwa untuk menyimpan kata sandi Anda menggunakan algoritma hash teraman yang ditawarkan database Anda. Kata sandi tidak boleh mudah ditebak atau tidak rentan terhadap serangan kamus. Beberapa sistem database, seperti MySQL, memungkinkan Anda untuk secara tepat menentukan persyaratan yang harus dipenuhi oleh kata sandi Anda agar dapat digunakan. Huruf kecil dan besar, angka, karakter khusus, panjang kata sandi - semuanya penting dan jika Anda dapat menerapkan beberapa kebijakan seputar kekuatan kata sandi, Anda harus melakukannya. Bit penting lainnya adalah rotasi kata sandi. Kata sandi tidak boleh dibuat sekali dan untuk semua masa pakai basis data, Anda harus memiliki kebijakan rotasi kata sandi. Sekali lagi, beberapa sistem database dapat menerapkan ini untuk Anda. Pengguna administratif mungkin dapat membuat akun pengguna baru dengan rotasi kata sandi yang diberlakukan. Dia mungkin juga dapat menerapkan rotasi kata sandi untuk pengguna tertentu.
Log audit
Beberapa sistem database menawarkan log audit - idenya adalah untuk mengumpulkan sebanyak mungkin informasi tentang aktivitas dalam database. Siapa dan kapan melakukan apa? Kueri mana yang telah dieksekusi, oleh siapa? Siapa yang mencoba masuk tetapi gagal? Dari tuan rumah yang mana? Idealnya, log yang berisi informasi tersebut akan disimpan di luar node database. Anda dapat mengalirkannya ke server log pusat untuk diamankan, diproses lebih lanjut, dan kemampuan pencarian yang lebih baik.
Keamanan SQL
Kami menyebutkan pengguna dan host tetapi serangan juga dapat terjadi dari sumber yang berbeda. Jika aplikasi Anda tidak diamankan dengan benar dan input tidak divalidasi dengan benar, Anda mungkin menghadapi serangan yang berasal dari situs web Anda. Kita berbicara di sini tentang injeksi SQL. Dalam kasus seperti itu, firewall tidak terlalu berguna mengingat kueri berasal dari sumber yang valid (server web Anda dan kemudian node proxy). Menetapkan hibah sebenarnya dapat membantu mencegah beberapa jenis serangan ini, tetapi ini bukanlah solusi yang ideal - setelah semua aplikasi Anda, dalam sebagian besar kasus, akan membutuhkan pengguna yang dapat menghapus atau memodifikasi konten database. Pengguna seperti itu, ketika dieksploitasi, dapat digunakan untuk merugikan. Ada beberapa cara yang bisa Anda coba untuk melawannya.
Firewall SQL
Cara paling sederhana untuk melakukannya adalah dengan menerapkan firewall SQL. Hal ini dapat dicapai pada tingkat yang berbeda dan di tempat yang berbeda. Salah satu opsinya adalah menggunakan penyeimbang beban untuk itu. Beberapa dari mereka datang dengan fungsi ini setidaknya mudah dicapai jika belum diimplementasikan. Ide di baliknya adalah untuk membuat daftar kueri yang dijalankan aplikasi Anda dan kemudian mengonfigurasi proxy Anda agar hanya melewati jenis lalu lintas ini. Ini tidak ideal karena Anda harus mempertahankannya tepat waktu, menambahkan kueri baru dan menghapus kueri lama yang tidak digunakan lagi. Di sisi lain, seperangkat aturan seperti itu akan mencegah kueri apa pun yang tidak diotorisasi, mencapai database.
Deteksi injeksi SQL
Opsi lain yang memungkinkan adalah menerapkan deteksi injeksi SQL di lapisan proxy. Ada beberapa solusi, antara lain ProxySQL, yang dapat dikonfigurasi untuk mencoba mendeteksi injeksi SQL dalam lalu lintas yang melewatinya. Tentu saja, semuanya didasarkan pada heuristik sehingga dapat menghasilkan kesalahan positif, tetapi ini dapat menjadi tambahan yang bagus untuk firewall SQL.
Di masa lalu kita telah membahas bagaimana Anda dapat menerapkan firewall SQL dan deteksi injeksi SQL menggunakan ProxySQL, sebuah loadbalancer yang dapat digunakan dari ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Keamanan Data
Terakhir, keamanan data. Kami telah membahas sejauh ini bagaimana seseorang dapat mengeraskan basis data, bagaimana membatasi aksesnya dan bagaimana mencegah berbagai jenis serangan yang datang dari aplikasi itu sendiri. Kita tetap harus mempertimbangkan perlindungan data itu sendiri. Ini dapat memiliki beberapa lapisan. Keamanan fisik - jika Anda memiliki pusat data, pastikan pusat data tersebut terkunci dengan benar. Jika Anda menggunakan ISP eksternal atau penyedia cloud, pastikan mereka memiliki protokol keamanan yang tepat saat mengakses perangkat keras. Kemudian kami memiliki server, VM atau apa pun yang Anda gunakan. Data berada di disk, disimpan secara lokal di server. Data sedang ditransfer antara aplikasi, proxy dan database. Data ditransfer antara node database dengan cara replikasi. Data disimpan di luar kantor sebagai cadangan. Data ini harus dilindungi.
Cadangan
Cadangan harus selalu dienkripsi. Kunci enkripsi harus dijaga dengan hati-hati dan diputar secara teratur.
Data dalam perjalanan
Data yang ditransfer harus dienkripsi. Pastikan Anda telah mengonfigurasi aplikasi, lapisan proxy, dan database Anda untuk menggunakan SSL atau TSL. Setiap cara mentransfer data antara node database juga harus diamankan dan dienkripsi. Tujuannya adalah untuk membuat segala jenis sniffing jaringan menjadi sia-sia.
Data diam
Akhirnya, data itu sendiri, disimpan di node database. Itu juga harus dienkripsi. Ada beberapa metode yang dapat Anda gunakan ketika mendekati topik ini. Pertama, enkripsi pada tingkat host. Volume di mana database memiliki direktori datanya dapat dienkripsi (dan didekripsi saat boot). Basis data juga cenderung datang dengan kemampuan enkripsi. Apa yang dapat dienkripsi tergantung pada solusi yang tepat dan jenis serta versi database, tetapi dalam beberapa kasus pilihannya cukup luas. Enkripsi tablespace, enkripsi log, terkadang bahkan enkripsi struktur dalam memori. Jika Anda melakukannya dengan benar, mengakses node database tidak akan cukup untuk mengakses data.
Kesimpulan
Seperti yang kami sebutkan sebelumnya, blog ini tidak dimaksudkan untuk menjadi panduan praktis untuk keamanan basis data tetapi kami telah menyentuh sebagian besar aspek yang harus Anda pertimbangkan ketika merancang lingkungan basis data Anda dan kami berharap Anda akan menemukan panduan ini berguna.
