Memikirkan desain database untuk audit logging? Ingat apa yang terjadi pada Hansel dan Gretel:mereka pikir meninggalkan jejak remah roti adalah cara yang baik untuk melacak langkah mereka.
Saat mendesain model data, kita dilatih untuk menerapkan filosofi bahwa sekarang adalah segalanya . Misalnya, jika kita merancang skema untuk menyimpan harga untuk katalog produk, kita mungkin berpikir bahwa database hanya perlu memberi tahu kita harga setiap produk pada saat ini. Tapi kalau kita ingin tahu apakah harganya diubah dan, jika ya, kapan dan bagaimana modifikasi itu terjadi, kita akan kesulitan. Tentu saja, kami dapat merancang database secara khusus untuk menyimpan catatan kronologis perubahan – umumnya dikenal sebagai jejak audit atau log audit.
Pencatatan audit memungkinkan database memiliki 'memori' peristiwa masa lalu. Melanjutkan contoh daftar harga, log audit yang tepat akan memungkinkan database memberi tahu kami dengan tepat kapan suatu harga diperbarui, berapa harga sebelum diperbarui, siapa yang memperbaruinya, dan dari mana.
Solusi Pencatatan Audit Basis Data
Akan sangat bagus jika database dapat menyimpan snapshot statusnya untuk setiap perubahan yang terjadi pada datanya. Dengan cara ini, Anda dapat kembali ke titik waktu mana pun dan melihat bagaimana data berada pada saat yang tepat seperti Anda sedang memutar ulang film. Tapi cara menghasilkan logging audit itu jelas tidak mungkin; volume informasi yang dihasilkan dan waktu yang diperlukan untuk menghasilkan log akan terlalu tinggi.
Strategi logging audit didasarkan pada pembuatan jejak audit hanya untuk data yang dapat dihapus atau dimodifikasi. Setiap perubahan di dalamnya harus diaudit untuk mengembalikan perubahan, menanyakan data dalam tabel riwayat, atau melacak aktivitas yang mencurigakan.
Ada beberapa teknik logging audit yang populer, tetapi tidak satupun dari mereka melayani setiap tujuan. Yang paling efektif seringkali mahal, intensif sumber daya, atau menurunkan kinerja. Lainnya lebih murah dalam hal sumber daya tetapi tidak lengkap, rumit untuk dipelihara, atau membutuhkan pengorbanan dalam kualitas desain. Strategi mana yang Anda pilih akan bergantung pada persyaratan aplikasi dan batas kinerja, sumber daya, dan prinsip desain yang perlu Anda hormati.
Solusi Pencatatan Log Out-of-the-Box
Solusi logging audit ini bekerja dengan mencegat semua perintah yang dikirim ke database dan membuat log perubahan di repositori terpisah. Program tersebut menawarkan beberapa konfigurasi dan opsi pelaporan untuk melacak tindakan pengguna. Mereka dapat mencatat semua tindakan dan kueri yang dikirim ke database, bahkan jika itu berasal dari pengguna dengan hak istimewa tertinggi. Alat-alat ini dioptimalkan untuk meminimalkan dampak kinerja, tetapi ini sering kali harus dibayar mahal.
Harga solusi jejak audit khusus dapat dibenarkan jika Anda menangani informasi yang sangat sensitif (seperti catatan medis) di mana setiap perubahan data harus dipantau dan diaudit dengan sempurna dan jejak audit tidak boleh diubah. Namun ketika persyaratan jejak audit tidak terlalu ketat, biaya solusi logging khusus bisa menjadi berlebihan.
Alat pemantauan asli yang ditawarkan oleh sistem basis data relasional (RDBMS) juga dapat digunakan untuk menghasilkan jejak audit. Opsi penyesuaian memungkinkan pemfilteran peristiwa mana yang direkam, agar tidak menghasilkan informasi yang tidak perlu atau membebani mesin basis data dengan operasi pencatatan yang tidak akan digunakan nanti. Log yang dihasilkan dengan cara ini memungkinkan pelacakan terperinci dari operasi yang dijalankan pada tabel. Namun, mereka tidak berguna untuk menanyakan tabel riwayat, karena hanya merekam peristiwa.
Pilihan paling ekonomis untuk mempertahankan jejak audit adalah dengan mendesain database Anda secara khusus untuk pencatatan audit. Teknik ini didasarkan pada tabel log yang diisi oleh pemicu atau mekanisme khusus untuk aplikasi yang memperbarui database. Tidak ada pendekatan yang diterima secara universal untuk desain database logging audit, tetapi ada beberapa strategi yang umum digunakan, yang masing-masing memiliki pro dan kontra.
Teknik Desain Pencatatan Log Audit Basis Data
Versi Baris untuk Audit Logging Di Tempat
Salah satu cara untuk mempertahankan jejak audit untuk tabel adalah dengan menambahkan bidang yang menunjukkan nomor versi setiap catatan. Sisipan ke dalam tabel disimpan dengan nomor versi awal. Setiap modifikasi atau penghapusan sebenarnya menjadi operasi penyisipan, di mana catatan baru dihasilkan dengan data yang diperbarui dan nomor versi bertambah satu. Anda dapat melihat contoh desain audit logging in place di bawah ini:
Catatan:Desain tabel dengan versi baris yang disematkan tidak dapat ditautkan dengan hubungan kunci asing.
Selain nomor versi, beberapa bidang tambahan harus ditambahkan ke tabel untuk menentukan asal dan penyebab setiap perubahan yang dibuat pada catatan:
- Tanggal/waktu saat perubahan direkam.
- Pengguna dan aplikasi.
- Tindakan yang dilakukan (menyisipkan, memperbarui, menghapus), dll. Agar jejak audit efektif, tabel hanya boleh mendukung penyisipan (pembaruan dan penghapusan tidak boleh diizinkan). Tabel juga memerlukan kunci primer pengganti, karena kombinasi bidang lainnya akan mengalami pengulangan.
Untuk mengakses data tabel yang diperbarui melalui kueri, Anda harus membuat tampilan yang hanya mengembalikan versi terbaru dari setiap rekaman. Kemudian, Anda harus mengganti nama tabel dengan nama tampilan di semua kueri kecuali yang secara khusus ditujukan untuk melihat kronologi rekaman.
Keuntungan opsi pembuatan versi ini adalah tidak memerlukan penggunaan tabel tambahan untuk menghasilkan jejak audit. Plus, hanya beberapa bidang yang ditambahkan ke tabel yang diaudit. Tetapi ini memiliki kelemahan besar:ini akan memaksa Anda untuk membuat beberapa kesalahan desain database yang paling umum. Ini termasuk tidak menggunakan integritas referensial atau kunci primer alami ketika diperlukan untuk melakukannya, sehingga tidak mungkin untuk menerapkan prinsip-prinsip dasar desain diagram hubungan entitas. Anda dapat mengunjungi sumber daya yang berguna ini tentang kesalahan desain basis data, sehingga Anda akan diperingatkan tentang praktik lain yang harus dihindari.
Tabel Bayangan
Pilihan jejak audit lainnya adalah membuat tabel bayangan untuk setiap tabel yang perlu diaudit. Tabel bayangan berisi bidang yang sama dengan tabel yang mereka audit, ditambah bidang audit tertentu (yang sama disebutkan untuk teknik versi baris).
Tabel bayangan mereplikasi bidang yang sama dengan tabel yang mereka audit, ditambah bidang khusus untuk tujuan audit.
Untuk menghasilkan jejak audit di tabel bayangan, opsi teraman adalah membuat pemicu penyisipan, pembaruan, dan penghapusan, yang untuk setiap rekaman yang terpengaruh di tabel asli menghasilkan rekaman di tabel audit. Pemicu harus memiliki akses ke semua informasi audit yang perlu Anda rekam di tabel bayangan. Anda harus menggunakan fungsi khusus mesin database untuk mendapatkan data seperti tanggal dan waktu saat ini, pengguna yang masuk log, nama aplikasi, dan lokasi (alamat jaringan atau nama komputer) tempat operasi berasal.
Jika menggunakan pemicu bukanlah pilihan, logika untuk menghasilkan jejak audit harus menjadi bagian dari tumpukan aplikasi, di lapisan yang idealnya terletak tepat sebelum lapisan persistensi data, sehingga dapat mencegat semua operasi yang diarahkan ke database.
Jenis tabel log ini seharusnya hanya mengizinkan penyisipan record; jika mereka mengizinkan modifikasi atau penghapusan, jejak audit tidak akan lagi memenuhi fungsinya. Tabel juga harus menggunakan kunci primer pengganti, karena dependensi dan hubungan tabel asli tidak dapat diterapkan padanya.
Jika tabel yang Anda buat jejak auditnya memiliki tabel yang menjadi sandarannya, tabel tersebut juga harus memiliki tabel bayangan yang sesuai. Ini agar jejak audit tidak menjadi yatim piatu jika ada perubahan pada tabel lain.
Tabel bayangan nyaman karena kesederhanaannya dan karena tidak mempengaruhi integritas model data; jejak audit tetap dalam tabel terpisah dan mudah untuk ditanyakan. Kekurangannya adalah skema ini tidak fleksibel:setiap perubahan dalam struktur tabel utama harus tercermin dalam tabel bayangan yang sesuai, yang membuat sulit untuk mempertahankan model. Selain itu, jika logging audit perlu diterapkan ke sejumlah besar tabel, jumlah tabel bayangan juga akan tinggi, sehingga pemeliharaan skema menjadi lebih sulit.
Tabel Umum untuk Pencatatan Audit
Opsi ketiga adalah membuat tabel umum untuk log audit. Tabel tersebut memungkinkan logging tabel lain dalam skema. Hanya dua tabel yang diperlukan untuk teknik ini:
Tabel header yang mencatat:
- Tanggal dan waktu perubahan.
- Nama tabel.
- Kunci dari baris yang terpengaruh.
- Data pengguna.
- Jenis operasi yang dilakukan.
Tabel detail yang mencatat:
- Nama setiap bidang yang terpengaruh.
- Nilai bidang sebelum modifikasi.
- Nilai bidang setelah modifikasi. (Anda dapat menghilangkan ini jika perlu, karena dapat diperoleh dengan melihat catatan berikut dalam jejak audit atau catatan terkait dalam tabel yang diaudit.)
Penggunaan tabel log audit umum membatasi jenis data yang dapat diaudit.
Keuntungan dari strategi logging audit ini adalah tidak memerlukan tabel selain dua yang disebutkan di atas. Juga, catatan disimpan di dalamnya hanya untuk bidang yang dipengaruhi oleh operasi. Ini berarti bahwa tidak perlu mereplikasi seluruh baris tabel ketika hanya satu bidang yang dimodifikasi. Selain itu, teknik ini memungkinkan Anda untuk menyimpan log tabel sebanyak yang Anda inginkan – tanpa mengacaukan skema dengan sejumlah besar tabel tambahan.
Kerugiannya adalah bahwa bidang yang menyimpan nilai harus bertipe tunggal – dan cukup lebar untuk menyimpan bahkan bidang terbesar dari tabel yang ingin Anda buat log auditnya. Paling umum menggunakan bidang tipe VARCHAR yang menerima karakter dalam jumlah besar.
Jika, misalnya, Anda perlu membuat log audit untuk tabel yang memiliki satu bidang VARCHAR dengan 8.000 karakter, bidang yang menyimpan nilai dalam tabel audit juga harus memiliki 8.000 karakter. Ini benar bahkan jika Anda hanya menyimpan satu bilangan bulat di bidang itu. Di sisi lain, jika tabel Anda memiliki bidang tipe data yang kompleks, seperti gambar, data biner, BLOB, dll., Anda perlu membuat serialisasi kontennya sehingga dapat disimpan di bidang VARCHAR tabel log.
Pilih Desain Log Audit Basis Data Anda dengan Bijak
Kami telah melihat beberapa alternatif untuk menghasilkan logging audit, tetapi tidak ada yang benar-benar optimal. Anda harus mengadopsi strategi logging yang tidak secara substansial mempengaruhi kinerja database Anda, tidak membuatnya tumbuh berlebihan, dan dapat memenuhi persyaratan keterlacakan Anda. Jika Anda hanya ingin menyimpan log untuk beberapa tabel, tabel bayangan mungkin merupakan opsi yang paling nyaman. Jika Anda menginginkan fleksibilitas untuk mencatat tabel apa pun, tabel logging generik mungkin yang terbaik.
Sudahkah Anda menemukan cara lain untuk menyimpan log audit untuk database Anda? Bagikan di bagian komentar di bawah – rekan desainer database Anda akan sangat berterima kasih!
