Mengaudit Basis Data di The Grid Bagian 2: Pengamatan Pasca Penerapan

Dalam posting sebelumnya untuk seri ini, saya berbicara tentang bagaimana kami mengumpulkan persyaratan untuk proyek ini, bagaimana kami membuat keputusan tentang alat apa yang akan digunakan dan bagaimana kami merencanakan penyebaran untuk menghindari gangguan layanan. Seperti yang dijanjikan, pos tindak lanjut ini berfokus pada pengamatan pasca penerapan dan faktor apa yang membuat ini menjadi kisah sukses bagi kami.

Pernyataan yang disiapkan dan pemfilteran kelas perintah

Desain awal kami untuk proyek ini dimaksudkan untuk memanfaatkan fitur dalam plugin percona yang memungkinkan Anda memfilter peristiwa yang dipancarkan untuk menggunakan daftar perintah yang disertakan atau perintah yang dikecualikan sebagai cara untuk membatasi ruang lingkup pada apa yang sebenarnya perlu kami audit.

Fitur ini bergantung pada plugin yang menandai setiap perintah sql yang terdeteksi dengan kelas berdasarkan daftar yang melekat pada mysql dan dari sana memutuskan di lapisan output jika kelas perintah yang terdeteksi harus ditekan atau dipancarkan.

Jadi kami menulis cetak biru awal untuk memanfaatkan fitur audit_log_exclude_commands untuk mengecualikan perintah sql yang tidak menyebabkan penulisan atau perubahan pada data baris. Kami memilih daftar pengecualian karena kami merasa bahwa daftar penyertaan membawa risiko kehilangan kelas perintah apa pun dalam lingkup dan dapat menjadi alasan untuk memiliki celah dalam log audit kami.

Namun, pada cluster pertama yang kami uji, kami melihat bahwa semua perintah yang diaudit diklasifikasikan sebagai kesalahan meskipun jelas bahwa pernyataan ini berjalan dengan sukses dan jika terjadi perubahan data, hal itu juga berhasil dilakukan. Kami juga melihat bahwa semua kueri dipancarkan ke server syslog terpusat terlepas dari daftar pengecualian yang tampaknya berkorelasi dengan klasifikasi kesalahan itu.

Ini berarti bahwa kami menyimpan jauh lebih banyak peristiwa di elasticsearch daripada yang sebenarnya kami butuhkan yang pasti akan memengaruhi kemampuan kami untuk menganalisis dan mendeteksi perilaku yang salah secara tepat waktu. Dengan kolaborasi dengan tim Keamanan, kami memutuskan untuk memberi tahu Percona tentang masalah ini melalui pelacak bug mereka, tetapi juga memindahkan pemfilteran berbasis perintah ke lapisan syslog pusat.

Seperti segala sesuatu di bidang teknik, tradeoff di sini adalah mengirim lebih banyak data melalui lapisan jaringan DB dan membuat pemfilteran di lapisan syslog terpusat lebih kompleks dan sebagai imbalannya membuat penskalaan pencarian elastis kami lebih mudah dikelola dan konfigurasi di sisi basis data lebih sederhana.

Pertunjukan

Salah satu keputusan paling penting dalam proyek ini yang menyelamatkan kami dari banyak sakit hati adalah memutuskan untuk menggunakan fasilitas rsyslog untuk menjebak dan mengirimkan log ini ke server syslog terpusat.

Tapi tidak ada yang tanpa pro dan kontra.

Keputusan ini berarti bahwa waktu aktif sistem terpisah dan keandalan tumpukan jaringan di antaranya menjadi sangat penting untuk menyediakan SLA yang kami butuhkan untuk memberikan kepercayaan kepada tim audit kami dalam solusi audit ini.

Bagi mereka yang tidak mau berkompromi dan perlu menjaga tanggung jawab persistensi log audit dalam tumpukan DB, saya sarankan menggunakan FILE handler di plugin audit kemudian menggunakan logstash lokal untuk mengambil log dan meneruskannya ke sistem analisis mereka. pilihan.

Pilihan terakhir itu berarti lebih banyak IOP disk yang dikonsumsi dari proses database dan diambil oleh plugin audit dan logstash dan itu berarti Anda harus dengan hati-hati menyeimbangkan ruang disk pada instans Anda antara file tabel database, log operasional, dan audit. log plugin. Menimbang pilihan Anda semata-mata bergantung pada mana yang lebih mudah dioperasikan/diterima oleh bisnis, tetapi Anda tetap memiliki pilihan.

Dalam kasus kami, pilihan rsyslog terbukti paling tidak berdampak pada database kami yang lebih sibuk, memuncak pada sekitar 5400 transaksi/dtk, selama operasi normal kami tidak melihat dampak pada kinerja. Plugin audit terus berjalan, mengirimkan acaranya tanpa berdampak pada kinerja database. Semua karena kami telah memilih arsitektur yang menghindari penggunaan operasi berbasis disk di sisi database.

Keputusan masa lalu membuahkan hasil

Salah satu kekhawatiran pertama yang kami miliki ketika kami memulai proyek ini adalah dampaknya terhadap kinerja. Salah satu klaster basis data dalam ruang lingkup telah melihat waktu yang sangat sibuk dan aplikasinya sensitif terhadap kelambatan sehingga kami perlu memastikan bahwa kami terus melacak metrik kinerja seperti transaksi per detik, penggunaan Disk dan CPU untuk membandingkan angka setelah menerapkan plugin dan lihat apa hukuman untuk itu.

Merupakan kejutan yang menyenangkan untuk melihat bahwa kami tidak dikenakan banyak penalti dalam operasi normal. Seperti disebutkan sebelumnya, karena kami memutuskan untuk menggunakan pengendali SYSLOG, itu berarti kami biasanya tidak perlu menggunakan kapasitas disk lokal apa pun untuk melacak peristiwa audit ini.

Namun kami juga tidak ingin membuat perencanaan berdasarkan waktu 'operasi normal' saja.

Kami juga perlu mengetahui bahwa ketika rsyslog perlu melakukan fallback ke file spool lokal, peristiwa ini tidak digabungkan menjadi penghentian yang berdampak pada layanan untuk klaster DB yang lebih kritis. Dengan menguji perilaku rsyslog spooling di bawah pengawasan ketat dalam produksi, kami menyadari bahwa beberapa tahun terakhir bekerja untuk memisahkan database kami secara fungsional telah memberi kami manfaat yang tidak direncanakan dari banyak kapasitas IOP disk untuk menyerap peristiwa seperti rsyslog spooling ke disk kemudian perlu mengirim ulang semua peristiwa ini.

Kami benar-benar mencatat peningkatan pemanfaatan disk selama peristiwa ini tetapi tidak pernah membuat instance db ke status kritis atau memengaruhi aktivitas yang dihadapi pelanggan.

Trade-off

Seperti segala sesuatu dalam rekayasa perangkat lunak, selalu ada pengorbanan. Dalam proyek ini, kami mempertimbangkan metode pengiriman log yang lebih andal dan memiliki potensi kehilangan log yang lebih kecil. Itu akan melibatkan penulisan log ke disk, kemudian menggunakan sesuatu seperti logstash untuk mencerna dan mengirimkannya ke tujuan analisis untuk digunakan oleh tim keamanan.

Tapi itu berarti konsumsi IOP disk yang signifikan di sisi basis data yang kami tahu berpotensi memengaruhi kualitas layanan panggilan yang dihadapi pelanggan ke basis data ini.

Kami memutuskan bahwa kebutuhan bisnis kami akan cukup terpenuhi dengan menggunakan logging tangguh di rsyslog, menggunakan spool berukuran wajar, dan menggunakan TCP untuk mengirim peristiwa ke tumpukan pemantauan log kami. Seperti segala sesuatu dalam hidup, tidak ada yang abadi. Dan kami menyadari bahwa keputusan ini mungkin perlu ditinjau kembali di masa mendatang.

Akhirnya

Proyek ini, meskipun mencakup setengah lusin cluster dan sejumlah besar instans, diselesaikan dalam satu kuartal sementara tim operasi DB masih terus menyalakan lampu dalam bisnis yang masih berkembang pesat. Itu tidak mungkin terjadi tanpa kolaborasi yang erat antara DBE dan tim keamanan dan bukan tanpa manajemen produk yang kuat yang menjaga ruang lingkup terbatas dan diketahui untuk memastikan kita semua tetap fokus pada tujuan akhir untuk membuat bisnis kita lebih aman.