Ringkasan melakukan hardening MySQL

Tidak ada yang perlu ditutup-tutupi: Ada penyerang yang dapat dengan mudah memindai seluruh internet dalam hitungan menit dan memecahkan sandi dalam hitungan detik. Meskipun terkadang perlu membuat database yang dapat diakses melalui jaringan IP publik, hal ini membuat database Anda secara eksponensial lebih rentan. Salah satu cara untuk mengurangi risiko IP publik adalah dengan membatasi akses database ke sekumpulan alamat IP yang terbatas.

Meskipun demikian, solusi yang lebih baik adalah dengan hanya mengizinkan akses di dalam virtual private cloud (VPC), serta hanya mengizinkan koneksi operator di dalam bastion host. Di Google Cloud, solusi ini disebut IP pribadi. Jika instance MySQL Anda hanya dapat diakses di dalam VPC, penyerang harus menembus VPC terlebih dahulu sebelum mencoba meretas instance Anda.

Setiap versi minor MySQL memiliki catatan rilis, dan hampir selalu berisi bagian terkait update keamanan. Jika ada beberapa versi yang sudah tidak berlaku untuk instance Anda, ada beberapa versi perbaikan keamanan yang tidak dimiliki database Anda.

Selain memperbaiki masalah keamanan dari waktu ke waktu, MySQL juga secara berkala memperkenalkan beberapa fitur keamanan yang sepenuhnya baru. Misalnya, MySQL 8.0 memperkenalkan banyak cara untuk memperkuat skema dan pengguna MySQL, seperti peran, pelacakan login yang gagal, dan pembuatan sandi acak.

Anggap Anda bekerja di kedai kopi, dan ingin menjalankan beberapa kueri. Kemudian, Anda terhubung ke MySQL melalui jaringan Wi-Fi gratis di toko tersebut. Jika tidak menggunakan TLS (Transport Layer Security), berarti secara tidak langsung, Anda mengirimkan nama pengguna dan sandi secara terang-terangan melalui TCP (Transmission Control Protocol, salah satu protokol utama internet). Terapkan TLS pada instance MySQL, sehingga Anda dapat menyiapkan latte tanpa perlu khawatir jika ada pelanggan lain yang menyusupi jaringan.

Injeksi SQL

Sering kali bukan database tetapi aplikasi yang paling rentan terhadap serangan. Banyak aplikasi menjadi korban serangan injeksi SQL, yaitu saat penyerang menyisipkan input berbahaya yang dianggap sebagai pernyataan SQL yang valid oleh aplikasi Anda. Perlindungan terbaik dari serangan ini adalah menggunakan pernyataan yang sudah disiapkan saat membuat pernyataan SQL, dan bukan menggabungkan input pengguna dengan pernyataan SQL.

Secret di repositori Anda

Banyak database yang telah diretas karena developer secara tidak sengaja memasukkan nama pengguna dan sandi mereka ke dalam repositori kode sumber. Sebagai gantinya, gunakan alat seperti Secret Manager Google Cloud, yang mengelola semua jenis secret, termasuk sandi database Anda.

Logging sandi

Terakhir, gunakan alat pemfilteran framework logging untuk memfilter sandi database dari log aplikasi Anda. Contohnya meliputi Filter Log4j atau Rails ParameterFilter, tetapi sebagian besar framework logging seharusnya memiliki padanan yang setara. Jika tidak, Anda harus memastikan bahwa log aplikasi Anda aman agar database tetap aman.

Pertimbangkan untuk menggunakan validasi sandi guna memastikan semua sandi di database Anda cukup kompleks. Untuk sandi aplikasi, buat sandi yang panjang, kompleks, dan ubah sesering mungkin. Secret manager sangat berguna sehingga Anda tidak perlu menghafal sandi yang kompleks dan sering berubah. 

Jika manusia (dan bukan aplikasi) akan menggunakan pengguna database, ikuti standar NIST dan prioritaskan panjang sandi terlebih dahulu. Tanggal habis masa berlaku sandi dan persyaratan sandi yang terlalu kompleks sering menyebabkan orang mendelegasikan memori mereka ke file teks biasa dan sticky note, yang menggugurkan seluruh tujuan aturan ini. 

Lebih baik lagi, pertimbangkan untuk memanfaatkan autentikasi IAM untuk pengguna non-aplikasi. Autentikasi IAM mendelegasikan pembentukan koneksi ke penawaran IAM Google Cloud, yang berarti risiko dimitigasi hanya untuk pengguna IAM, bukan pengguna IAM dan pengguna database.

Terakhir, hash default MySQL, bukan salt, pada sandi database Anda. Artinya, pengguna yang memiliki sandi yang sama akan memiliki string autentikasi yang identik, sehingga memudahkan pemecahan sandi yang lemah dengan serangan rainbow-table. Perhatikan bagaimana dua pengguna MySQL berikut memiliki authentication_string yang sama.

Sebaiknya tetapkan flag default_authentication_plugin ke caching_sha2_password. Cara ini memastikan bahwa dua pengguna dengan sandi yang sama akan memiliki hash yang berbeda. Perhatikan bagaimana kedua pengguna ini memiliki nilai authentication_string yang berbeda dalam contoh berikut.

Membatasi akses bukan berarti mengamankan akses dari luar saja; tetapi juga berarti mengaudit akses secara teratur dari dalam.

Mengaudit aplikasi: Jika hanya membaca dari tabel penagihan, produk, dan pelanggan, apakah aplikasi benar-benar memerlukan akses ke hal yang lain? Membiarkan akses root tersedia ke database Anda berarti penyerang dapat menyebabkan kerusakan yang sangat luar biasa pada database. Maka dari itu, ingat setiap persyaratan yang dimiliki instance Anda, rinci hak istimewa yang diperlukan, lalu buat pengguna database untuk setiap persyaratan tersebut. Jika penyerang meretas database Anda dengan salah satu pengguna database ini, maka cakupan kerusakan dapat dibatasi.

Mengaudit pengguna: Berapa banyak pengguna database yang benar-benar memerlukan hak istimewa admin di instance Anda? Berapa banyak dari pengguna tersebut yang masih berada di organisasi, atau masih terikat dengan project yang tidak aktif, atau pengguna sudah tidak bekerja lagi? Token akses dapat bocor, dan ancaman orang dalam selalu menjadi perhatian bagi sebagian besar sistem. Memastikan bahwa Anda memiliki sesedikit mungkin pengguna dapat membantu instance Anda terlindung dari masalah seperti ini.

Mengaudit 'admin': Pertimbangkan untuk menghapus atau mengganti nama pengguna seperti 'root' atau 'admin'. Nama pengguna ini adalah target mudah bagi penyerang, dan jika tidak memiliki nama tersebut, sistem Anda akan sedikit lebih sulit untuk dibobol. Hal ini disebut security through obscurity, dan meskipun tidak seharusnya menjadi garis pertahanan pertama, cara ini dapat menambahkan lapisan keamanan tipis pada database MySQL Anda.

Pencadangan data rutin dan rencana pemulihan data yang dapat diverifikasi sangat penting untuk pengelolaan database yang baik. Bahkan dengan pencadangan rutin sekalipun, Anda masih berpotensi kehilangan semua data yang ditulis setelah pencadangan terakhir. Salah satu manfaat ekosistem MySQL adalah pemulihan point-in-time (PITR), yang memungkinkan Anda memulihkan data kapan saja. Untuk menggunakan PITR, aktifkan log biner di instance Cloud SQL untuk MySQL Anda.

Jika sudah melakukan semua hal di atas, berarti Anda sudah dipersiapkan dengan baik dan terlindungi. Meskipun demikian, desain keamanan tidak akan lengkap tanpa kewaspadaan yang berkelanjutan—audit database. Plugin Audit Cloud SQL untuk MySQL membantu Anda melacak perilaku yang tidak wajar jika terjadi pelanggaran.

Dengan menerapkan hal di atas, Anda akan membuat jalur peretasan database menjadi jauh lebih sulit bagi penyerang. Penyerang harus meretas aplikasi Anda dan berharap pengguna database aplikasi tersebut memiliki hak istimewa yang cukup untuk bisa melakukan serangan. Jika tidak, penyerang tersebut harus menembus VPC Anda, menemukan nama pengguna yang sudah ada, memecahkan sandi tersebut, dan berharap pengguna memiliki hak istimewa yang cukup untuk menjalankan serangan. Sementara itu, Anda dapat melihat log database MySQL atau log audit untuk memantau perilaku umum pada database dan memberikan respons yang sesuai.

Inilah yang dimaksud dengan keamanan melalui desain. Penyerang akan terus menemukan cara untuk mengeksploitasi mesin. Itulah pentingnya untuk merancang sistem dengan perlindungan sebanyak mungkin guna menjaga database Anda tetap terlindungi.