Mengaudit Database di The Grid

Karena SendGrid baru-baru ini menjadi perusahaan publik, kami perlu memiliki log audit lengkap dari semua perubahan pada subset database kami. Subkumpulan ini mencakup beberapa contoh kecil yang tidak melihat lalu lintas volume besar, tetapi juga beberapa kluster lama kami yang penting bagi waktu aktif dan alur pendaftaran portal pelanggan kami.

Hal ini juga berdampak pada beberapa datastore yang memiliki tuntutan uptime tinggi dan peluncuran online (tanpa downtime untuk menulis) diinginkan. Dengan tenggat waktu eksternal di tangan dan mengetahui ruang lingkup proyek, kami mulai membuat rencana.

Pada fase perencanaan, kami mengidentifikasi beberapa pertanyaan terbuka yang kami perlukan jawabannya:

1. Pilihan apa yang kita miliki sejauh perangkat lunak yang dapat melakukan ini?
2. Dampak kinerja apa yang diharapkan dan seberapa besar kita dapat mengujinya terlebih dahulu?
3. Bisakah kita melakukan ini tanpa downtime untuk ketersediaan tulis?

Pilihan, pilihan

Di SendGrid, kami mengikuti proses cetak biru desain untuk proyek besar atau lintas tim. Proyek ini melibatkan sejumlah tim sebagai pemangku kepentingan antara lain:

• Audit Internal sebagai tim yang bertanggung jawab untuk menentukan penyimpanan data mana yang termasuk dalam cakupan kontrol kepatuhan ini dan untuk mengumpulkan bukti, tibalah waktu audit
• InfoSec sebagai tim yang menganalisis dan menangani respons insiden yang berasal dari log audit basis data ini
• DB Ops sebagai tim yang menulis kode yang menyebarkan, mengelola, dan menyesuaikan fitur baru ini ke database dalam cakupan

Saya mulai menulis cetak biru ini dan memastikannya ditinjau oleh semua pemangku kepentingan dan disetujui oleh tim arsitektur kami. Meskipun saya telah melakukan beberapa penelitian tentang topik audit logging di MySQL beberapa tahun yang lalu dan memiliki beberapa gagasan seperti apa lanskap untuk opsi, saya tidak ingin mendekati proyek dengan prasangka dan ingin tetap menyelidiki lebih dari satu pilihan, dan memberikan semua orang kasus yang solid tentang mengapa kami akan memilih satu solusi di atas yang lain.

Cetak biru ini tidak biasa karena saya secara bersamaan menulisnya sambil menyelidiki apa solusi untuk kebutuhan bisnis itu nantinya. Jadi saya tahu bahwa banyak detail akan diisi saat kami melakukan riset.

Pilihan kami adalah:

• Plugin audit Percona
• Audit MySQL McAfee

Meskipun ini bukan satu-satunya pilihan di pasar, kami merasa mereka adalah yang paling dekat dengan skala kami dan mengembangkan praktik untuk menjamin dimasukkan dalam memanggang yang sebenarnya. Pilihan komersial lainnya di pasar tidak lulus standar untuk dimasukkan dalam benchmark.

Yang terakhir adalah solusi yang lebih baru yang baru saja dibuka bersumber dari Mcafee dan cukup menarik untuk dilihat karena diklaim mendukung pemfilteran tingkat tabel yang tidak dilakukan oleh plugin Percona. Karena kami tahu salah satu kluster dalam lingkup kami benar-benar perlu mengaudit sekitar 24 tabel dari total 300, ini tampaknya menjadi fitur yang cukup berharga untuk menjadikan plugin Mcafee sebagai pesaing.

Di sisi lain, plugin Percona Audit adalah solusi open source yang paling banyak digunakan untuk fitur ini. Itu sudah ada di dalamnya tetapi dinonaktifkan di Percona Server-yang sudah kami gunakan. Namun, itu tidak menyediakan pemfilteran tingkat tabel dari peristiwa yang berarti kami perlu melakukannya di luar lapisan basis data.

Pembakaran

Dengan bantuan tim mitra kami di Pythian, kami memulai perbandingan pemanggangan. Pada awalnya, kami membandingkan cara memasang dan menyetel setiap opsi. Tim dengan cepat menentukan bahwa kami memiliki tradeoff di tangan kami. Meskipun plugin Mcafee mendukung filter tabel secara asli, plugin ini tidak mendukung penggunaan rsyslog sebagai metode streaming acaranya. Ini berarti jika kita menggunakannya, kita harus menulis file secara lokal ke disk dan harus mengatur pengirimannya ke tumpukan pemantauan.

Ini dianggap tidak diinginkan karena kemungkinan besar akan meningkatkan penalti kinerja menggunakan plugin audit. Menulis peristiwa audit secara lokal kemudian membacanya lagi dengan proses terpisah menghilangkan kapasitas IOPS dari lalu lintas produksi aktual kami dan meningkatkan risiko ke instance basis data karena itu berarti kami harus mengelola ukuran file ini pada disk agar tidak membengkak dan menyebabkan basis data waktu henti.

Di sisi lain kompromi adalah plugin Percona. Ini mendukung pengiriman acara ke syslog secara asli tetapi tidak menawarkan filter tabel apa pun. Kami tahu ini berarti cluster yang lebih sibuk dalam cakupan akan mengirim sejumlah besar peristiwa, yang sebagian besar sebenarnya bukan dari tabel yang ingin kami audit. Ini menimbulkan risiko pada lapisan syslog-receive/logstash dari tumpukan pemantauan InfoSec. Karena operasi DB tidak memiliki akses ke sana, itu berarti keberhasilan proyek ini adalah upaya kepemilikan bersama.

Pada akhirnya, kami memutuskan untuk menggunakan solusi dengan lebih sedikit bagian yang bergerak dan merencanakan penerapan kami untuk mengetahui sedini mungkin jika logstash perlu ditingkatkan untuk menangani pemfilteran ribuan peristiwa per detik. Jadi keputusan dibuat untuk bergerak maju dengan plugin audit Percona.

Perencanaan penyebaran

Lingkup pemasangan

Kami memutuskan untuk menjaga penerapan ini tetap sederhana dengan menginstal dan mengaktifkan plugin pada semua node dalam kluster tertentu yang berarti bahwa kami menghilangkan kebutuhan untuk mengatur pengaktifan atau penonaktifan fasilitas audit ketika node penulis dalam kluster berubah. Kami tidak memiliki kekhawatiran tentang aliran replikasi yang menyebabkan peristiwa duplikat saat perubahan diterapkan karena plugin, secara desain, tidak mencatat perubahan aliran replikasi.

Tidak ada waktu henti

Kami ingin menjadikan ini sebagai penerapan yang mulus tanpa downtime di cluster yang terpengaruh. Itu akan sangat mengurangi jumlah perencanaan dan orkestrasi yang perlu kami lakukan dengan tim pengiriman yang menggunakan cluster ini dan sangat mengurangi dampak pelanggan. Tetapi kami juga ingin plugin mengirim acaranya ke rsyslog, pada fasilitas tertentu, dengan konfigurasi khusus yang akan mengirim acara ke server agregasi syslog tim InfoSec. Beberapa dari konfigurasi ini didokumentasikan sebagai tidak dinamis oleh Percona dan itu menunjukkan kemungkinan bahwa setiap instance dalam cakupan proyek ini akan mengalami waktu henti saat kami memulai ulang instance mysql dengan konfigurasi plugin audit yang diperlukan.

Kami mulai menguji urutan operasi yang berbeda dalam menerapkan plugin dengan contoh pengujian khusus di lingkungan pementasan kami dan dapat menunjukkan bahwa jika kami memiliki manajemen konfigurasi kami meletakkan semua konfigurasi yang diperlukan pada awalnya kemudian jalankan perintah load plugin , perintah itu akan mulai dengan konfigurasi yang diinginkan.

Hal ini terbukti berperan dalam menyederhanakan rencana untuk menyelesaikan proyek ini dan mempersingkat waktu untuk merilisnya dalam produksi, memberi kami waktu untuk menyempurnakan pemfilteran acara dan bekerja dengan tim keamanan dalam analisis dan deteksi.

Gunakan manajemen konfigurasi

Kami menggunakan buku masak chef untuk mengelola database kami, jadi jelas kami berencana menggunakan chef untuk menyebarkan, menyetel, dan memantau plugin audit. Tetapi karena ini hanya perlu diaktifkan di sebagian klaster kami, ini berarti kami memerlukan cara untuk mengontrol di mana itu diaktifkan agar tidak membebani penyimpanan log kami dengan data yang tidak terkait dengan tujuan bisnis kami di sini.

Untuk mengelola database MySQL, kami menggunakan model buku masak pembungkus untuk mengelola konfigurasi. Buku masak 'dasar' inti mendefinisikan sebagian besar bagaimana instance database akan terlihat kemudian buku masak per cluster membungkusnya untuk memodifikasi atribut atau menambahkan konfigurasi yang berkaitan dengan cluster tertentu. Desain itu memudahkan untuk menambahkan sebagian besar kode yang akan membuat file konfigurasi yang diperlukan kemudian memuat plugin dalam satu resep baru yang kemudian dapat kita aktifkan dan nonaktifkan berdasarkan atribut chef. Kami juga memutuskan dengan mempertimbangkan ruang lingkup perubahan yang kami buat, bahwa ini menjamin pelepasan kode ini sebagai versi minor baru dari buku masak.

Kami juga memastikan agar koki menghapus pemeriksaan sensu terkait dan mematikan streaming audit saat atribut disetel ke false. Ini untuk memastikan bahwa chef dapat melakukan hal yang benar jika sebuah cluster dianggap tidak lagi dalam cakupan atau perlu dihentikan karena alasan yang terputus-putus, jadi kami tidak perlu mengubah node secara manual untuk mencerminkan perubahan atribut.

Pemantauan

Anda tidak dapat menyatakan keberhasilan sesuatu yang tidak Anda pantau. Tetapi juga pemantauan lebih dari sekadar menampar beberapa pemeriksaan sensu tanpa memikirkan kasus kegagalan apa yang kami pantau dan tindakan apa yang kami harapkan sebagai tanggapan terhadap pemeriksaan ini yang gagal suatu hari nanti. Jadi saya mulai merencanakan pemantauan di saluran ini dengan 2 hal dalam pikiran

• Kita semua harus menyepakati ruang lingkup kepemilikan eksplisit dalam sistem ini, terutama karena sistem ini mengangkangi tanggung jawab 2 tim dengan rotasi panggilan yang terpisah.
• Setiap pemeriksaan baru yang ditambahkan untuk keperluan ini harus disertai dengan runbook yang kami tautkan dalam pemeriksaan, menjelaskan apa yang gagal pada pemeriksaan ini dan bagaimana cara memperbaikinya

Mengingat 2 aturan itu, saya melanjutkan untuk menambahkan pemeriksaan yang sangat spesifik. Pada titik ini, saya mempertimbangkan untuk menambahkan pemeriksaan 'sintetis' ujung ke ujung, tetapi sejak itu saya menahan diri untuk tidak melakukan itu karena pemeriksaan ujung ke ujung di sini akan gagal memberi tahu kami dengan tepat bagian mana dari sistem yang gagal yang berarti kami akan kesulitan waktu bahkan paging tim yang tepat dengan itu. Dan saya bukan pendukung paging orang di malam hari 'berjaga-jaga'

Kami memutuskan untuk memantau hal-hal berikut:

• Periksa konfigurasi mysql langsung dari plugin audit untuk memastikan bahwa
  • Plugin dalam keadaan aktif
  • audit_log_policy disetel ke QUERIES

Pemeriksaan ini mengkonfirmasi bahwa DB dalam ruang lingkup tidak memiliki konfigurasi yang diubah dengan cepat karena pengaturan ini dinamis dan dapat berubah di luar file my.cnf pada disk .

• Periksa port tempat kami mengirim log ke tumpukan pemantauan untuk memastikan data mengalir. Pada dasarnya, pastikan ujung lain dari aliran syslog berfungsi. Pemeriksaan ini ditangani sebagai apa yang disebut pemeriksaan agregat sehingga tidak secara berlebihan membuka halaman tim InfoSec

Rintangan di sepanjang jalan

Konfigurasi plugin audit

Salah satu iterasi awal proyek ini dimaksudkan untuk memanfaatkan fitur audit_log_exclude_commands untuk membatasi peristiwa yang kami pancarkan hanya pada manipulasi data atau skema. Kami dengan cepat mengetahui bahwa daftar yang menjadi dasar konfigurasi ini jauh lebih panjang dari yang diharapkan.

konfigurasi rsyslog

Berikut adalah sesuatu yang saya tidak tahu sebelum proyek ini. Konfigurasi Rsyslog hampir merupakan bahasanya sendiri. Sebagai contoh:

• Gunakan @ kedua di depan tujuan jarak jauh untuk mengirim log melalui TCP alih-alih UDP. Kami ingin memanfaatkan fasilitas ini untuk memberikan sedikit lebih banyak jaminan bahwa log sedang dikirimkan.
• rsyslog memiliki halaman khusus tentang cara mengonfigurasinya untuk penerusan yang andal, yang terbukti sangat berguna bagi pemula untuk alat seperti saya.
• rsyslog akan, secara default, juga mengirimkan datanya ke /var/log/messages yang tidak diinginkan dalam kasus saya karena ini BANYAK acara. Jika Anda perlu membuat fasilitas yang Anda gunakan TIDAK melakukannya, Anda harus menambahkan local5.* ~ di akhir konfigurasi Anda

Latihan menghadapi kebakaran

Saya akan berbicara tentang implikasi kinerja untuk database dalam ruang lingkup nanti, tetapi karena rsyslog digunakan sebagai bagian penting untuk desain ini, kami juga perlu mempelajari bagaimana rsyslog akan berperilaku ketika tujuan jarak jauh tidak tersedia atau tidak merespons. Cara terbaik untuk melakukannya adalah dengan menyebabkan gangguan pada komunikasi tersebut menggunakan aturan iptables dalam produksi di salah satu database dalam cakupan yang kami tahu memiliki throughput transaksi yang tinggi dan oleh karena itu, volume besar peristiwa audit per detik. Berikut adalah bagaimana latihan kebakaran itu dimainkan.

• Konfirmasikan bahwa peristiwa audit mengalir melalui port TCP yang ditunjuk
• Gunakan aturan iptables untuk menghapus semua lalu lintas pada port itu /sbin/iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP
• Tonton aktivitas penulisan disk dan file di WorkDirectory yang dikonfigurasi dalam konfigurasi rsyslog. Nama file akan didasarkan pada ActionQueueFileName dari fasilitas yang menerima peristiwa ini

Seperti yang diharapkan, file mulai menumpuk di direktori ini. Kami melihat lonjakan aktivitas IOP disk. Setelah jumlah file yang mendefinisikan nama antrian dijumlahkan ukurannya dengan nilai ActionQueueMaxDiskSpace , rsyslog berhenti membuat file-file ini, IOP disk dinormalisasi dan jelas bahwa kami sekarang menjatuhkan acara di lantai di lapisan rsyslog. Yang lebih mengesankan untuk dilihat adalah bahwa setelah kami menghapus aturan yang dapat diminum, rsyslog mengirim ulang semua peristiwa yang telah di-spool ke disk sehingga kami tidak kehilangan peristiwa untuk penyimpanan analisis kami selama kami tidak melebihi ukuran spool. Kami belajar beberapa hal berdasarkan eksperimen itu

• rsyslog berperilaku seperti yang didokumentasikan. Selalu lebih baik untuk membuktikannya dengan eksperimen tangan pertama
• Kami sangat mungkin perlu mendefinisikan ruang disk antrian yang berbeda per cluster tergantung pada volume peristiwa yang dihasilkan masing-masing. Karena antrian pada disk menambah risiko pada kapasitas IOP dan kapasitas disk, ini adalah hal yang perlu kita tinjau kembali secara berkala dan periksa kembali

Dalam posting berikutnya, saya akan berbicara tentang apa pengamatan kami setelah menerapkan proyek ini ke produksi dan hal-hal apa yang membuat ini tidak mengganggu produksi semaksimal mungkin.