Audit adalah pemantauan dan perekaman tindakan database pengguna yang dipilih. Biasanya digunakan untuk menyelidiki aktivitas mencurigakan atau memantau dan mengumpulkan data tentang aktivitas basis data tertentu. Misalnya, administrator database dapat mengumpulkan statistik tentang tabel mana yang sedang diperbarui, berapa banyak operasi yang dilakukan, atau berapa banyak pengguna secara bersamaan yang terhubung pada waktu tertentu.
Dalam posting blog ini, kita akan membahas aspek fundamental dari audit sistem database open-source kita, terutama MySQL, MariaDB, PostgreSQL, dan MongoDB. Artikel ini ditujukan untuk para insinyur DevOps yang umumnya memiliki lebih sedikit pengalaman atau paparan dalam praktik terbaik kepatuhan audit dan tata kelola data yang baik saat mengelola infrastruktur terutama untuk sistem database.
Audit Pernyataan
Audit Pernyataan MySQL
MySQL memiliki log kueri umum (atau general_log), yang pada dasarnya mencatat apa yang dilakukan mysqld. Server menulis informasi ke log ini ketika klien terhubung atau terputus, dan mencatat setiap pernyataan SQL yang diterima dari klien. Log kueri umum bisa sangat berguna saat memecahkan masalah tetapi tidak benar-benar dibuat untuk audit berkelanjutan. Ini memiliki dampak kinerja yang besar dan hanya boleh diaktifkan selama slot waktu singkat. Ada opsi lain untuk menggunakan tabel performance_schema.events_statements* atau Plugin Audit.
Audit Pernyataan PostgreSQL
Untuk PostgreSQL, Anda dapat mengaktifkan log_statment ke "semua". Nilai yang didukung untuk parameter ini adalah none (nonaktif), ddl, mod, dan all (semua pernyataan). Untuk "ddl", ia mencatat semua pernyataan definisi data, seperti pernyataan CREATE, ALTER, dan DROP. Untuk "mod", ia mencatat semua pernyataan DDL, ditambah pernyataan modifikasi data seperti INSERT, UPDATE, DELETE, TRUNCATE, dan COPY FROM.
Anda mungkin perlu mengonfigurasi parameter terkait seperti log_directory, log_filename, logging_collector dan log_rotation_age, seperti yang ditunjukkan pada contoh berikut:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes Perubahan di atas memerlukan restart PostgreSQL, jadi harap rencanakan dengan cermat sebelum menerapkan ke lingkungan produksi Anda. Anda kemudian dapat menemukan log saat ini di bawah direktori pg_log. Untuk PostgreSQL 12, lokasinya ada di /var/lib/pgsql/12/data/pg_log/ . Perhatikan bahwa file log cenderung bertambah banyak seiring waktu, dan mungkin memakan ruang disk secara signifikan. Anda juga dapat menggunakan log_rotation_size sebagai gantinya jika Anda memiliki ruang penyimpanan terbatas.
Audit Pernyataan MongoDB
Untuk MongoDB, ada 3 level logging yang dapat membantu kami mengaudit pernyataan (operasi atau operasi dalam istilah MongoDB):
-
Level 0 - Ini adalah level profiler default di mana profiler tidak mengumpulkan data apa pun. Mongod selalu menulis operasi lebih lama dari ambang slowOpThresholdMs ke lognya.
-
Level 1 - Mengumpulkan data profil untuk operasi lambat saja. Secara default, operasi lambat adalah yang lebih lambat dari 100 milidetik. Anda dapat mengubah ambang batas untuk operasi "lambat" dengan opsi runtime slowOpThresholdMs atau perintah setParameter.
-
Level 2 - Mengumpulkan data pembuatan profil untuk semua operasi database.
Untuk mencatat semua operasi, setel db.setProfilingLevel(2, 1000), di mana ia harus membuat profil semua operasi dengan operasi yang memakan waktu lebih lama dari milidetik yang ditentukan, dalam hal ini, adalah 1 detik (1000 mdtk) . Kueri untuk mencari di kumpulan profil sistem untuk semua kueri yang membutuhkan waktu lebih dari satu detik, akan diurutkan berdasarkan stempel waktu. Untuk membaca operasi, kita dapat menggunakan query berikut:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Juga, ada proyek Mongotail, yang menyederhanakan proses pembuatan profil operasi dengan alat eksternal alih-alih menanyakan langsung ke kumpulan profil.
Ingatlah bahwa tidak disarankan untuk menjalankan audit pernyataan lengkap di server database produksi karena biasanya memberikan dampak signifikan pada layanan database dengan volume logging yang sangat besar. Cara yang disarankan adalah dengan menggunakan plugin audit database (seperti yang ditunjukkan lebih jauh di bawah), yang menyediakan cara standar untuk menghasilkan log audit yang sering kali diperlukan untuk mematuhi sertifikasi pemerintah, keuangan, atau ISO.
Audit Hak Istimewa untuk MySQL, MariaDB, dan PostgreSQL
Audit hak istimewa mengaudit hak istimewa dan kontrol akses ke objek database. Kontrol akses memastikan bahwa pengguna yang mengakses database diidentifikasi secara positif dan dapat mengakses, memperbarui, atau menghapus data yang menjadi hak mereka. Area ini biasanya diabaikan oleh insinyur DevOps yang membuat kesalahan umum yang berlebihan saat membuat dan memberikan pengguna basis data.
Contoh kelebihan hak istimewa adalah:
-
Host akses pengguna diizinkan dari rentang yang sangat luas, misalnya memberikan host pengguna [email protected]' %', bukan alamat IP individual.
-
Hak istimewa administratif diberikan kepada pengguna basis data non-administratif, misalnya, pengguna basis data untuk aplikasi sedang ditetapkan dengan hak istimewa SUPER atau RELOAD.
-
Kurangnya kontrol sumber daya terhadap segala jenis penggunaan berlebihan seperti Koneksi Pengguna Maks, Kueri Maks Per Jam, atau Maks Koneksi Per Jam.
-
Izinkan pengguna database tertentu untuk mengakses skema lain juga.
Untuk MySQL, MariaDB, dan PostgreSQL, Anda dapat melakukan audit hak istimewa melalui Skema Informasi dengan menanyakan tabel terkait hibah, peran, dan hak istimewa. Untuk MongoDB, gunakan kueri berikut (memerlukan tindakan viewUser untuk database lain):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl memberikan ringkasan yang bagus tentang hak istimewa yang diberikan kepada pengguna database. Buka Kelola -> Skema dan Pengguna -> Pengguna dan Anda akan mendapatkan laporan tentang hak istimewa pengguna, bersama dengan opsi lanjutan seperti Memerlukan SSL, Koneksi Maks Per Jam, dan seterusnya.
ClusterControl mendukung pengauditan hak istimewa untuk MySQL, MariaDB, dan PostgreSQL di bawah pengguna yang sama antarmuka.
Audit Objek Skema
Objek skema adalah struktur logis yang dibuat oleh pengguna. Contoh objek skema adalah tabel, indeks, tampilan, rutinitas, peristiwa, prosedur, fungsi, pemicu, dan lain-lain. Ini pada dasarnya objek yang menyimpan data atau dapat terdiri dari definisi saja. Biasanya, seseorang akan mengaudit izin yang terkait dengan objek skema untuk mendeteksi pengaturan keamanan yang buruk dan memahami hubungan dan ketergantungan antar objek.
Untuk MySQL dan MariaDB, ada information_schema dan performance_schema yang dapat kita gunakan untuk mengaudit objek skema pada dasarnya. Performance_schema sedikit mendalam dalam instrumentasi seperti namanya. Namun, MySQL juga menyertakan skema sys sejak versi 5.7.7, yang merupakan versi performance_schema yang mudah digunakan. Semua database ini dapat diakses secara langsung dan dapat ditanyakan oleh klien.
Plugin/Ekstensi Audit Basis Data
Cara yang paling direkomendasikan untuk melakukan audit pernyataan adalah dengan menggunakan plugin atau ekstensi audit, yang dibuat khusus untuk teknologi database yang digunakan. MariaDB dan Percona memiliki implementasi plugin Audit mereka sendiri, yang sedikit berbeda dari plugin Audit MySQL yang tersedia di MySQL Enterprise. Catatan audit mencakup informasi tentang operasi yang diaudit, pengguna yang melakukan operasi, serta tanggal dan waktu operasi. Catatan dapat disimpan dalam tabel kamus data, yang disebut jejak audit basis data, atau dalam file sistem operasi, yang disebut jejak audit sistem operasi.
Untuk PostgreSQL, ada pgAudit, ekstensi PostgreSQL yang menyediakan logging sesi dan/atau audit objek mendetail melalui fasilitas logging PostgreSQL standar. Ini pada dasarnya adalah versi yang disempurnakan dari fitur log_statement PostgreSQL dengan kemampuan untuk dengan mudah mencari dan mencari data yang diambil untuk diaudit dengan mengikuti log audit standar.
MongoDB Enterprise (berbayar) dan Percona Server untuk MongoDB (gratis) menyertakan kemampuan audit untuk instans mongod dan mongos. Dengan mengaktifkan audit, server akan menghasilkan pesan audit yang dapat masuk ke syslog, konsol, atau file (format JSON atau BSON). Dalam kebanyakan kasus, lebih baik untuk masuk ke file dalam format BSON, di mana dampak kinerjanya lebih kecil daripada JSON. File ini berisi informasi tentang berbagai peristiwa pengguna termasuk otentikasi, kegagalan otorisasi, dan sebagainya. Lihat dokumentasi Audit untuk detailnya.
Jejak Audit Sistem Operasi
Penting juga untuk mengonfigurasi jejak audit sistem operasi. Untuk Linux, orang biasanya akan menggunakan auditd. Auditd adalah komponen ruang pengguna dari Sistem Audit Linux dan bertanggung jawab untuk menulis catatan audit ke disk. Melihat log dilakukan dengan utilitas ausearch atau aureport. Konfigurasi aturan audit dilakukan dengan utilitas auditctl, atau dengan memodifikasi file aturan secara langsung.
Langkah penginstalan berikut adalah praktik umum kami saat menyiapkan segala jenis server untuk penggunaan produksi:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartPerhatikan bahwa layanan baris terakhir auditd restart adalah wajib karena audit tidak bekerja dengan baik saat memuat aturan dengan systemd. Namun, systemd masih diperlukan untuk memantau layanan yang diaudit. Selama startup, aturan di /etc/audit/audit.rules dibaca oleh auditctl. Daemon audit itu sendiri memiliki beberapa opsi konfigurasi yang mungkin ingin disesuaikan oleh admin. Mereka ditemukan di file auditd.conf.
Baris berikut adalah output yang diambil dari log audit yang dikonfigurasi:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Seperti yang Anda lihat di atas, mudah untuk menemukan kata sandi teks yang jelas untuk MySQL ("--password=S3cr3tPassw0rdKP") menggunakan utilitas ausearch seperti yang ditangkap oleh auditd. Penemuan dan audit semacam ini sangat penting untuk mengamankan infrastruktur basis data kami, di mana kata sandi cleartext tidak dapat diterima di lingkungan yang aman.
Pemikiran Terakhir
Log atau jejak audit adalah aspek vital yang biasanya diabaikan oleh para insinyur DevOps ketika mengelola infrastruktur dan sistem, apalagi sistem database yang merupakan sistem yang sangat penting untuk menyimpan data sensitif dan rahasia. Setiap paparan atau pelanggaran data pribadi Anda dapat sangat merusak bisnis dan tidak ada yang menginginkan hal itu terjadi di era teknologi informasi saat ini.
