Dalam beberapa proyek yang telah kami kerjakan, pelanggan meminta kami untuk mencatat lebih banyak tindakan pengguna dalam database. Mereka ingin mengetahui semua tindakan yang dilakukan pengguna dalam aplikasi, tetapi menangkap dan merekam semua interaksi manusia dapat menjadi tantangan. Kami harus mencatat semua modifikasi data yang dilakukan melalui sistem. Artikel ini menjelaskan beberapa jebakan yang kami temui dan pendekatan yang kami gunakan untuk mengatasinya.
Pengantar
Saya bekerja sebagai arsitek solusi dalam jasa keuangan. Penting untuk menyimpan catatan pengguna terakhir yang mengubah satu baris. Dalam kasus yang paling sederhana, cukup untuk mencatat stempel waktu modifikasi agar memiliki ketertelusuran dari perubahan. Berikut adalah contoh sederhana dari tabel yang menyimpan perjanjian pelanggan yang menyertakan last_changed kolom untuk pengguna dan stempel waktu.
Namun, dalam beberapa kasus, ini tidak cukup. Kami sering kali harus memiliki keterlacakan penuh (termasuk sebelum dan sesudah "gambar" dari datanya). Dalam beberapa kasus, kami juga membutuhkan kemampuan audit (siapa, apa, kapan).
Sayangnya, banyak dari sistem kami tidak dirancang untuk menyediakan keterlacakan dan kemampuan audit. Kami perlu merekayasa balik persyaratan operasi bisnis ini ke dalam sistem.
Kemamputelusuran
Dalam beberapa kasus, kami menemukan bahwa ketertelusuran mudah dicapai. Sementara, di tempat lain, kami merasa sulit atau bahkan tidak mungkin. Tergantung pada sistem Anda, solusinya mungkin sederhana. Akses data Anda mungkin memungkinkan injeksi logging sederhana sebelum dan sesudah gambar data. Logging ini dapat diimplementasikan sedemikian rupa sehingga hasilnya disimpan dalam tabel database daripada di file log. Di beberapa produk, kami mencapai ini dengan cara yang mudah melalui ketekunan lapisan. Misalnya, ini dimungkinkan dengan Hibernasi .
Di sini Anda dapat melihat entri untuk setiap item jejak audit, ditambah akan ada nilai sebelum dan sesudah untuk setiap kolom yang telah berubah. Juga, jika sebuah baris dihapus, kami menyimpan informasi itu dengan functioncode menunjukkan hapus. Kami telah memilih untuk menggunakan varchar(1) untuk menyimpan kode fungsi (C, R, D) yang menentukan jenis modifikasi, daripada nama atau deskripsi "operasi" (Buat, Perbarui, Hapus) yang dilakukan . instance_key berisi kunci utama item yang ditambahkan, diubah, atau dihapus, untuk keterlacakan.
Namun, mungkin lapisan akses data Anda tidak menyediakan fungsionalitas yang diperlukan untuk Anda. Untuk produk lain, lapisan akses data kami tidak. Dalam kasus tersebut, ketertelusuran membutuhkan perubahan yang kompleks. Misalnya, Anda mungkin memerlukan pengambilan dan pencatatan dari setiap data sebelum modifikasi. Seperti yang saya tulis, ini mungkin tetapi bisa rumit untuk diterapkan. Pengembang harus membuat pengambilan setiap baris sebelum memodifikasi baris. Pembaruan tidak mungkin berjalan tanpa pilihan.
Bagaimana Anda bisa mengatasi ketertelusuran? Salah satu solusi yang mungkin adalah memastikan bahwa Anda mengetahui situasi awal semua data, yaitu situasi awal yang dibuat oleh data statis apa pun yang dimuat ke dalam sistem. Kemudian, Anda harus mencatat semua modifikasi. Dengan kata lain, apakah semua gambar "setelah" dari data? Dengan cara ini, adalah mungkin untuk “berguling ke depan ” dari data statis yang dimuat. Semua pembaruan yang dibuat hingga waktu itu diterapkan. Ini adalah situasi yang kurang ideal, tetapi mungkin dapat diterima.
Tabel sederhana dapat digunakan jika satu-satunya informasi yang tersedia adalah nilai baru dan bukan nilai sebelumnya.
Auditabilitas
Dalam beberapa situasi, kita harus memastikan bahwa semua tindakan yang diambil dalam sistem sepenuhnya dapat diaudit . Siapa yang login jam berapa? Tindakan apa yang dilakukan setiap pengguna dalam sistem, termasuk hanya melihat data? Ini penting karena mungkin signifikan jika pengguna melihat pembayaran.
Untuk mencapai pelacakan halus mungkin sulit melihat hanya pada akses database. Kita harus sering melihat ke tingkat yang lebih tinggi dan memeriksa tindakan atau layanan yang dilakukan. Dalam beberapa kasus, kami dapat melacak setiap panggilan layanan untuk mengetahui apa yang dilakukan pengguna pada jam berapa. Dengan pengontrol input/output layanan web, pencatatan permintaan layanan cukup mudah.
Berikut adalah contoh log audit pengguna sederhana tempat kami merekam tindakan yang dilakukan setiap pengguna. Saya membahas beberapa masalah tentang pendekatan ini di bagian “Bukti” berikutnya.
Deskripsi tabel singkat diberikan di bawah ini:
user_audit tabel berisi entri audit data yang diberi cap waktu. Kunci utama terdiri dari audit_entry_time cap ditambah user_id dan bank_id ditambah nama action dilakukan. Bidang-bidang tersebut memiliki arti yang sesuai dengan namanya. Tabel audit menyimpan result tindakan, ditambah class yang sebenarnya yang mengeksekusi tindakan, masukan parameters dan errors .
Berikut adalah contoh lain dari jejak audit tempat kami merekam gambar sebelum dan sesudah data yang dimodifikasi dalam tabel tertentu (bersama dengan tindakan yang dilakukan, kredensial pengguna, dan stempel waktu).
audit_trail tabel berisi entri audit sebelum dan sesudah gambar data. Kunci utama terdiri dari audit_gen_key itu adalah kunci yang dihasilkan oleh aplikasi. Bidang-bidang tersebut memiliki arti yang sesuai dengan namanya. Nama tabel database tempat entri jejak audit ini dicatat disimpan di modified_table , ditambah gambar "sebelum" disimpan di prev_value dan gambar “setelah” di new_value . module yang melakukan modifikasi dan funct_type modifikasi (Buat, Perbarui, Hapus) juga disimpan. Terakhir, informasi audit user_id (dan bank_id yang sesuai ) ditambah stempel waktu perubahan (date_last_changed ).
Kemudian kami melakukan tantangan. Saat mencatat informasi keterlacakan dan informasi auditabilitas, pencatatan terjadi dua kali. Dari sudut pandang audit, ini menjengkelkan. Auditor harus memastikan bahwa informasi di antara kedua log ini sama.
Bukti
Satu tantangan lainnya adalah memastikan pencatatan semua tindakan pengguna . Hal ini sering diminta oleh auditor di industri jasa keuangan.
Sekarang kami memiliki tantangan nyata. Solusi kami adalah memastikan keterlacakan terpusat dan pencatatan auditabilitas. "Antarmuka" pusat memastikan bahwa semua implementasi antarmuka itu termasuk logging. Sangat mudah untuk memastikan bahwa semua kelas yang sesuai mengimplementasikan antarmuka.
Tentu saja, ini tidak menjamin 100% bukti logging. Ini adalah pemeriksaan keamanan yang kuat bahwa semua kelas yang sesuai masuk sesuai kebutuhan.
Kesimpulan
Merekayasa balik fungsi bisnis baru ke dalam sistem yang ada selalu menjadi tantangan. Ini mungkin lebih menjadi kasus ketika fungsionalitas yang diimplementasikan masuk ke inti.
