Keamanan Pre-Emptive dengan Audit Logging untuk MongoDB

Keamanan database adalah subjek yang luas yang membentang dari pengukuran pre-emptive untuk menjaga pengunjung yang tidak diinginkan keluar. Bahkan jika Anda dapat mengamankan server MongoDB Anda sepenuhnya, Anda masih ingin tahu apakah ada orang yang mencoba membobol sistem Anda. Dan jika mereka berhasil menembus keamanan Anda dan menginstal peretasan uang tebusan MongoDB, Anda akan memerlukan jejak audit untuk pemeriksaan mayat atau untuk mengambil tindakan pencegahan baru. Log audit akan memungkinkan Anda melacak siapa pun yang mencoba masuk dan melihat apa yang mereka lakukan di sistem Anda.

Versi MongoDB Enterprise berisi kemampuan untuk mengaktifkan log audit, tetapi versi komunitas tidak memiliki fungsi ini. Percona membuat fungsionalitas logging audit mereka sendiri di Server Percona turunan MongoDB untuk MongoDB. Pendekatan MongoDB dan Percona berbeda satu sama lain dan kami akan menjelaskan cara mengonfigurasi dan menggunakan keduanya.

Pencatatan Audit MongoDB

Log audit MongoDB mudah diatur:untuk mengaktifkan audit logging ke file JSON, cukup tambahkan bagian berikut ke file konfigurasi Anda dan mulai ulang MongoDB:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDB mendukung file, konsol, dan syslog sebagai tujuan. Untuk format file ada dua pilihan:JSON dan BSON. Di JSON, baris log audit terlihat seperti ini:

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

Konfigurasi di atas akan mengaktifkan log audit untuk setiap tindakan oleh pengguna sistem Anda. Jika Anda memiliki konkurensi tinggi, ini akan secara dramatis menurunkan kinerja klaster MongoDB Anda. Untungnya, ada opsi untuk memfilter peristiwa yang akan dicatat.

Filter untuk logging audit dapat ditempatkan pada jenis kueri, kueri pengguna/peran, atau pada koleksi yang ditanyakan. Dokumentasi tentang audit logging di MongoDB sangat luas dan panjang dengan banyak contoh. Kami akan memberikan beberapa contoh terpenting di bawah ini.

Mengautentikasi terhadap koleksi tertentu:

    filter: '{ atype: "authenticate", "param.db": "test" }'

Log untuk beberapa jenis audit:

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Catat semua pemeriksaan autentikasi untuk penyisipan/pembaruan/penghapusan pada koleksi tertentu:

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Seperti yang Anda lihat, filter bisa sangat fleksibel, dan Anda dapat memfilter pesan yang Anda perlukan untuk jejak audit Anda.

Server Percona untuk Pencatatan Audit MongoDB

Server Percona untuk pencatatan audit MongoDB terbatas pada file JSON. Sebagian besar pengguna hanya akan masuk ke file JSON, tetapi tidak jelas apakah Percona akan menambahkan fasilitas pencatatan lainnya di masa mendatang.

Tergantung pada versi Server Percona untuk MongoDB, konfigurasi Anda mungkin berbeda. Pada saat penulisan, semua versi memiliki sintaks berikut:

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Namun perbedaan konfigurasi ini baru-baru ini telah diselesaikan, tetapi masih harus dirilis. Setelah rilis, itu harus mengikuti direktif auditLog MongoDB lagi:

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Format oleh Percona sedikit berbeda:

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

Berbeda dengan MongoDB yang mencatat semuanya, Percona memilih untuk hanya mencatat perintah penting saja. Dilihat dari sumber plugin audit Percona, kueri berikut didukung:autentikasi, buat/perbarui/hapus pengguna, tambah/perbarui/hapus peran, buat/jatuhkan database/indeks, dan sebagian besar perintah admin penting.

Juga pemfilteran Server Percona untuk log audit MongoDB tampaknya tidak mengikuti standar yang sama seperti yang dimiliki MongoDB. Sangat tidak jelas apa sintaks dan opsi filter yang tepat karena dokumentasi Percona sangat ringkas tentangnya.

Mengaktifkan auditlog tanpa memfilter akan memberi Anda lebih dari cukup entri dalam file log Anda. Dari sini Anda dapat mempersempit filter, karena mengikuti sintaks JSON dari entri log.

Memanfaatkan Log Audit

Untuk memudahkan Anda sendiri, mungkin yang terbaik adalah memasukkan log audit ke dalam kerangka analisis log. Tumpukan ELK adalah lingkungan yang sangat baik untuk melakukan analisis Anda dan memungkinkan Anda untuk menelusuri ke tingkat yang lebih rinci dengan cukup mudah. Menggunakan field mapper bahkan memungkinkan Anda melakukan audit trail di dalam ELK.

Seperti yang dijelaskan dalam pendahuluan, kita dapat menggunakan log audit untuk berbagai tujuan keamanan. Yang paling jelas adalah ketika Anda membutuhkannya sebagai referensi selama pemeriksaan mayat. Log audit MongoDB memberikan gambaran rinci tentang apa yang sebenarnya terjadi. Log audit Percona berisi sedikit informasi, tetapi harus cukup untuk sebagian besar pemeriksaan mayat. Menggunakan log audit untuk post-mortem itu bagus, meskipun kami lebih suka mencegah masalah ini sejak awal.

Tujuan lain dari log audit adalah untuk melihat tren yang terjadi dan Anda dapat mengatur jebakan pada pesan log audit tertentu. Contoh yang baik adalah memeriksa tingkat upaya otentikasi (gagal) dan jika ini melebihi ambang batas tertentu, tindak lanjuti. Tergantung pada situasinya, tindakan yang diambil dapat berbeda. Salah satu tindakannya adalah memblokir secara otomatis alamat ip tempat permintaan berasal, tetapi dalam kasus lain, Anda dapat berkonsultasi dengan pengguna tentang mengapa kata sandi dilupakan. Ini sangat tergantung pada kasus dan lingkungan tempat Anda bekerja.

Pengukuran pre-emptive lanjutan lainnya akan menggunakan MongoDB sebagai honeypot dan memanfaatkan log audit untuk menangkap pengguna yang tidak diinginkan. Buka saja MongoDB dan izinkan siapa saja untuk terhubung ke server MongoDB Anda. Kemudian gunakan log audit untuk mendeteksi apa yang akan dilakukan pengguna jika mereka diizinkan melakukan hal-hal di luar kekuatan normal mereka dan memblokirnya jika perlu. Kebanyakan manusia lebih suka mengambil jalan yang mudah daripada jalan yang sulit, sehingga honeypot dapat menangkis serangan dan peretas akan berpindah ke target berikutnya.

Kesimpulan

Selain menjelaskan cara menyiapkan log audit untuk MongoDB Enterprise dan Server Percona untuk MongoDB, kami juga menjelaskan apa yang berpotensi Anda lakukan dengan data yang dicatat di dalam log audit.

Secara default ClusterControl tidak akan mengaktifkan log audit, tetapi relatif mudah untuk mengaktifkannya di seluruh cluster menggunakan Config Manager kami. Anda juga dapat mengaktifkannya di dalam template konfigurasi, sebelum men-deploy cluster baru.

Selamat mengelompokkan!