6.Audit Log & System Metadata

6.1. Mục tiêu chương

Chương này quy định cách quản lý dữ liệu audit nhằm:

• Đảm bảo khả năng truy vết toàn bộ hoạt động hệ thống
  
  

• Phục vụ kiểm tra, giám sát và điều tra sự cố
  
  

• Đáp ứng yêu cầu kiểm toán và tuân thủ
  
  

• Bảo vệ dữ liệu hệ thống khỏi việc chỉnh sửa trái phép

6.2. Khái niệm / phạm vi áp dụng

Audit log là dữ liệu ghi nhận:

• Hành động của người dùng
  
  

• Thay đổi dữ liệu quan trọng
  
  

• Sự kiện hệ thống
  
  

• Hoạt động bảo mật
  
  

Các bảng audit:

• audit_log
  
  

• action_history
  
  

• system_event
  
  

Các bảng này được coi là dữ liệu core của hệ thống.

Quy định này áp dụng cho:

• Tất cả module trong hệ thống
  
  

• Core Team và Partner Team
  
  

Mọi thay đổi liên quan đến audit

6.3. Quy định chính

Partner không được phép:

• Thay đổi cấu trúc bảng audit
  
  

• Thêm hoặc xóa cột trong bảng audit
  
  

• Xóa dữ liệu audit
  
  

• Chỉnh sửa dữ liệu audit thủ công
  
  

• Thay đổi logic ghi log
  
  

Các bảng audit được coi là:

Core system data

Mọi thay đổi liên quan đến:

• Cấu trúc bảng audit
  
  

• Logic ghi log
  
  

• Cơ chế lưu trữ audit
  
  

phải được:

Core Team phê duyệt

6.4. Cách thực hiện / quy trình

Trường hợp 1: Module cần ghi thêm audit

Bước 1: Sử dụng cơ chế audit có sẵn của hệ thống

Ví dụ:

• AuditService
  
  

• Annotation audit
  
  

• Event audit
  
  

Bước 2: Không được tự tạo bảng audit riêng

Bước 3: Nếu cần mở rộng dữ liệu audit:

Tạo ticket:

[AUDIT CHANGE REQUEST] <mô tả thay đổi>

Bước 4: Core Team review:

• Xem xét nhu cầu
  
  

• Đánh giá ảnh hưởng hệ thống
  
  

• Quyết định phương án mở rộng
  
  

Trường hợp 2: Cần thay đổi cấu trúc bảng audit

Bước 1: Tạo ticket:

[DB CORE CHANGE REQUEST] Audit table change

Bước 2: Cung cấp thông tin:

• Bảng audit bị ảnh hưởng
  
  

• Field cần thêm/sửa
  
  

• Lý do thay đổi
  
  

• Migration script
  
  

Bước 3: Core Team review và quyết định

6.5. Ví dụ minh họa

Trường hợp hợp lệ

Module planning muốn ghi log khi tạo kế hoạch:

auditService.logCreate("PLANNING", planningId, userId);

→ Sử dụng cơ chế audit có sẵn → hợp lệ.

Trường hợp không hợp lệ

Partner tự tạo bảng:

CREATE TABLE planning_audit (

    id BIGINT,

    action VARCHAR(50)

);

→ Sai quy định vì:

• Tự tạo bảng audit riêng
  
  

• Không dùng hệ thống audit chung
  
  

Trường hợp bị cấm

Partner chạy trực tiếp:

DELETE FROM audit_log WHERE created_at < '2024-01-01';

→ Không được phép xóa dữ liệu audit.

6.6. Checklist áp dụng

Trước khi commit hoặc tạo PR:

• Có thay đổi bảng audit không?
  
  

• Nếu có → phải xin Core Team
  
  

• Có xóa dữ liệu audit không?
  
  

• Nếu có → không được phép
  
  

• Có tự tạo bảng audit riêng không?
  
  

• Nếu có → phải chuyển sang audit chung
  
  

• Có thay đổi logic audit không?
  
  

• Nếu có → phải tạo Audit Change Request