Nhảy đến nội dung chính

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