Trong một số dự án mà chúng tôi đã thực hiện, khách hàng đã yêu cầu chúng tôi ghi lại nhiều hành động của người dùng hơn trong cơ sở dữ liệu. Họ muốn biết tất cả các hành động mà người dùng thực hiện trong ứng dụng, nhưng việc nắm bắt và ghi lại tất cả các tương tác của con người có thể là một thách thức. Chúng tôi đã phải ghi lại tất cả các sửa đổi dữ liệu được thực hiện qua hệ thống. Bài viết này mô tả một số cạm bẫy mà chúng tôi gặp phải và các phương pháp mà chúng tôi đã sử dụng để vượt qua chúng.
Giới thiệu
Tôi làm việc với tư cách là kiến trúc sư giải pháp trong các dịch vụ tài chính. Điều quan trọng là phải giữ một bản ghi về người dùng cuối cùng đã sửa đổi một hàng. Trong các trường hợp đơn giản nhất, chỉ cần ghi lại dấu thời gian của việc sửa đổi để có khả năng truy nguyên thay đổi. Dưới đây là một ví dụ đơn giản về bảng lưu trữ các thỏa thuận của khách hàng bao gồm last_changed cột cho người dùng và dấu thời gian.
Tuy nhiên, trong một số trường hợp, điều này là không đủ. Chúng tôi thường phải có khả năng truy xuất nguồn gốc đầy đủ (bao gồm trước và sau “hình ảnh” của dữ liệu). Trong một số trường hợp, chúng tôi cũng cần khả năng kiểm tra (ai, cái gì, khi nào).
Thật không may, nhiều hệ thống của chúng tôi không được thiết kế để cung cấp khả năng truy xuất nguồn gốc và khả năng kiểm tra. Chúng tôi cần thiết kế đối chiếu các yêu cầu hoạt động kinh doanh này vào hệ thống.
Truy xuất nguồn gốc
Trong một số trường hợp, chúng tôi nhận thấy việc truy xuất nguồn gốc dễ dàng đạt được. Trong khi, ở những người khác, chúng tôi thấy khó hoặc thậm chí là không thể. Tùy thuộc vào hệ thống của bạn, giải pháp có thể đơn giản. Quyền truy cập dữ liệu của bạn có thể cho phép ghi nhật ký hình ảnh trước và sau của dữ liệu một cách đơn giản. Việc ghi nhật ký này có thể được thực hiện sao cho kết quả được lưu trữ trong bảng cơ sở dữ liệu chứ không phải trong tệp nhật ký. Trong một số sản phẩm, chúng tôi đã đạt được điều này một cách dễ dàng thông qua sự bền bỉ lớp. Ví dụ:điều này có thể thực hiện được với Hibernate .
Tại đây, bạn có thể thấy mục nhập cho từng mục đường dẫn kiểm tra, ngoài ra sẽ có các giá trị trước và sau cho mỗi cột đã thay đổi. Ngoài ra, trong trường hợp một hàng bị xóa, chúng tôi lưu thông tin đó bằng functioncode cho biết xóa. Chúng tôi đã chọn sử dụng varchar (1) để lưu trữ mã của hàm (C, R, D) chỉ định loại sửa đổi, thay vì tên hoặc mô tả của “hoạt động” (Tạo, Cập nhật, Xóa) đã được thực hiện . instance_key chứa khóa chính của mặt hàng đã được thêm, sửa đổi hoặc xóa để truy xuất nguồn gốc.
Tuy nhiên, có thể lớp truy cập dữ liệu của bạn không cung cấp chức năng cần thiết cho bạn. Đối với các sản phẩm khác, lớp truy cập dữ liệu của chúng tôi không. Trong những trường hợp đó, việc xác định nguồn gốc cần có những thay đổi phức tạp. Ví dụ:bạn có thể cần truy xuất và ghi nhật ký của bất kỳ dữ liệu nào trước khi sửa đổi. Như tôi đã viết, điều này là có thể nhưng có thể phức tạp. Các nhà phát triển sẽ phải tạo truy xuất từng hàng trước khi sửa đổi một hàng. Bản cập nhật sẽ không thể chạy nếu không có lựa chọn.
Làm thế nào bạn có thể giải quyết vấn đề truy xuất nguồn gốc? Một giải pháp khả thi là đảm bảo rằng bạn biết tình huống bắt đầu của tất cả dữ liệu, tức là tình huống bắt đầu được tạo bởi bất kỳ dữ liệu tĩnh nào được tải vào hệ thống. Sau đó, bạn sẽ phải ghi lại tất cả các sửa đổi. Nói cách khác, tất cả các hình ảnh “sau” của dữ liệu là gì? Bằng cách này, có thể “ di chuyển về phía trước ”Từ dữ liệu tĩnh đã tải. Tất cả các bản cập nhật được thực hiện cho đến thời điểm đó đều được áp dụng. Đây là một tình huống ít lý tưởng hơn, nhưng có thể chấp nhận được.
Một bảng đơn giản có thể được sử dụng nếu thông tin duy nhất có sẵn là giá trị mới chứ không phải giá trị trước đó.
Khả năng kiểm toán
Trong một số tình huống, chúng tôi phải đảm bảo rằng tất cả các hành động được thực hiện trong hệ thống đều hoàn toàn có thể kiểm tra được . Ai đăng nhập vào thời gian nào? Mỗi người dùng đã thực hiện những hành động nào trong hệ thống, bao gồm cả việc chỉ xem dữ liệu? Điều này rất quan trọng vì nó có thể rất quan trọng nếu người dùng xem một khoản thanh toán.
Để đạt được truy tìm chi tiết có thể khó khăn khi chỉ nhìn vào quyền truy cập cơ sở dữ liệu. Chúng ta phải thường xuyên nhìn vào cấp độ cao hơn và kiểm tra các hành động hoặc dịch vụ được thực hiện. Trong một số trường hợp, chúng tôi có thể theo dõi từng cuộc gọi dịch vụ để biết người dùng đã làm gì vào thời điểm nào. Với bộ điều khiển đầu vào / đầu ra của dịch vụ web, việc ghi nhật ký các yêu cầu dịch vụ khá dễ dàng.
Dưới đây là một ví dụ về nhật ký kiểm tra người dùng đơn giản, nơi chúng tôi ghi lại hành động mà mỗi người dùng thực hiện. Tôi thảo luận một số vấn đề về cách tiếp cận này trong phần tiếp theo “Bằng chứng”.
Dưới đây là mô tả bảng ngắn gọn:
user_audit bảng chứa các mục kiểm tra dữ liệu được đánh dấu thời gian. Khóa chính bao gồm audit_entry_time đóng dấu cộng với user_id và bank_id cộng với tên của action đã thực hiện. Các trường có nghĩa tương ứng với tên của chúng. Bảng kiểm tra lưu trữ result của hành động, cộng với class thực tế đã thực thi hành động, các tham số parameters đầu vào của nó và bất kỳ errors .
Dưới đây là một ví dụ khác về dấu vết kiểm tra trong đó chúng tôi ghi lại hình ảnh trước và sau của dữ liệu đã được sửa đổi trong một bảng cụ thể (cùng với hành động đã thực hiện, thông tin đăng nhập của người dùng và dấu thời gian).
audit_trail bảng chứa các mục kiểm tra của hình ảnh trước và sau của dữ liệu. Khóa chính bao gồm audit_gen_key đó là một khóa do ứng dụng tạo ra. Các trường có nghĩa tương ứng với tên của chúng. Tên của bảng cơ sở dữ liệu mà mục nhập đường mòn kiểm tra này được ghi lại được lưu trữ trong modified_table , cộng với hình ảnh “trước đây” được lưu trữ trong prev_value và hình ảnh “sau” trong new_value . Mô-đun parameters đang thực hiện sửa đổi và funct_type của sửa đổi (Tạo, Cập nhật, Xóa) cũng được lưu trữ. Cuối cùng, thông tin kiểm tra của user_id (và bank_id tương ứng ) cộng với dấu thời gian của thay đổi (date_last_changed ).
Sau đó, chúng tôi đạt được một thử thách. Khi ghi nhật ký cả thông tin xác định nguồn gốc và thông tin kiểm toán, việc ghi nhật ký xảy ra hai lần. Theo quan điểm kiểm toán, điều này thật khó chịu. Kiểm toán viên phải đảm bảo rằng thông tin giữa hai nhật ký này là giống nhau.
Bằng chứng
Một thách thức khác là đảm bảo ghi lại tất cả các hành động của người dùng . Điều này thường được yêu cầu bởi các kiểm toán viên trong ngành dịch vụ tài chính.
Bây giờ chúng tôi có một thách thức thực sự. Giải pháp của chúng tôi là đảm bảo truy xuất nguồn gốc trung tâm và ghi nhật ký khả năng kiểm toán. “Giao diện” trung tâm đảm bảo rằng tất cả các triển khai của giao diện đó đều bao gồm ghi nhật ký. Thật dễ dàng để đảm bảo rằng tất cả các lớp thích hợp đang triển khai giao diện.
Tất nhiên, điều này không đảm bảo 100% bằng chứng đăng nhập. Đây là một kiểm tra an toàn mạnh mẽ rằng tất cả các lớp thích hợp đã được ghi nhật ký theo yêu cầu.
Kết luận
Thiết kế ngược chức năng kinh doanh mới vào một hệ thống hiện có luôn là một thách thức. Điều này có thể xảy ra nhiều hơn khi chức năng được triển khai đi vào cốt lõi.
