Sau bài học trước đó, các bạn đã được tiếp cận với những kiến thức cơ bản về Unified Policy Audit trong hệ thống Oracle. Bên cạnh đó, bạn cũng đã nắm được cách lưu trữ và ghi nhận các hoạt động, cũng như cách tạo, kích hoạt hoặc hủy kích hoạt Unified Policy Audit trong cơ sở dữ liệu Oracle.

Trong phần tiếp theo này, chúng ta sẽ tập trung vào các vấn đề sau:

• Thực hiện cài đặt chế độ ghi cho các bản ghi Audit Trail
• Đặt Policy FGA (Fine-Grained Auditing)
• Kiểm soát việc Audit các câu lệnh DML (Data Manipulation Language)
• Tuân thủ hướng dẫn FGA (FGA Guidelines)

Cấu hình chế độ ghi cho bản ghi của Audit Trail là rất quan trọng. 

Hệ thống Oracle sử dụng một cơ sở hạ tầng hàng đợi trong bộ nhớ để tạm thời lưu trữ các bản ghi audit trước khi ghi chúng vào bảng AUDSYS. Tuy nhiên, trong trường hợp xảy ra sự cố như sập hệ thống, các bản ghi audit trong hàng đợi có thể bị mất đi.

Để giảm thiểu rủi ro này, Audit Trail cần được cấu hình để xác định mức độ chịu đựng mất mát. Có hai chế độ khác nhau để lựa chọn:

Chế độ Ghi Ngay (Immediate-Write mode): Các bản ghi audit được ghi ngay lập tức vào bảng AUDSYS. Điều này đảm bảo rằng không có dữ liệu audit nào bị mất đi. Để kích hoạt chế độ này, bạn có thể sử dụng câu lệnh sau:

Chế độ Ghi Hàng Đợi (Queued-Write mode): Các bản ghi audit được lưu trữ tạm thời trong hàng đợi của bộ nhớ. Nội dung của hàng đợi này sẽ được ghi lên đĩa định kỳ. Đây là chế độ mặc định. Dùng câu lệnh sau để chuyển sang chế độ này:

Chọn chế độ phù hợp với yêu cầu của bạn để đảm bảo rằng dữ liệu audit được ghi và bảo vệ an toàn trong Oracle.

Value-based auditing trong Oracle Database

Audit dựa trên giá trị (value-based auditing) sử dụng các database trigger (cấu trúc PL/SQL dựa trên sự kiện) để ghi lại các giá trị đã thay đổi trong đối tượng.

Khi người dùng thực hiện thao tác insert, update hoặc delete dữ liệu từ một bảng có trigger phù hợp được gắn kết, trigger này sẽ làm việc ẩn danh để sao chép thông tin audit vào một bảng được thiết kế để chứa thông tin audit.

Audit dựa trên giá trị thường làm giảm hiệu suất hơn so với audit cơ sở dữ liệu tiêu chuẩn vì mã trigger audit phải được thực thi mỗi khi thực hiện thao tác insert, update hoặc delete. Mức độ suy giảm hiệu suất phụ thuộc vào hiệu quả của mã trigger.

Audit dựa trên giá trị chỉ nên được sử dụng trong những tình huống mà thông tin được ghi lại bởi audit cơ sở dữ liệu tiêu chuẩn là không đủ. Audit dựa trên giá trị được thực hiện bằng mã người dùng hoặc mã của bên thứ ba. Ngoài ra, db oracle cũng cung cấp các cấu trúc PL/SQL cho phép xây dựng hệ thống audit dựa trên giá trị.

Chìa khóa của audit dựa trên giá trị là trigger audit, đó chỉ đơn giản là một trigger PL/SQL được xây dựng để ghi lại thông tin audit. Dưới đây là ví dụ về một trigger audit thông thường:

CREATE OR REPLACE TRIGGER system.hrsalary_audit
                 AFTER UPDATE OF salary
                 ON hr.employees
                 REFERENCING NEW AS NEW OLD AS OLD
                 FOR EACH ROW
BEGIN
                 IF :old.salary != :new.salary THEN
                       INSERT INTO system.audit_employees
                       VALUES (sys_context('userenv', 'os_user')
                                       , sysdate
                                       , sys_context('userenv', 'ip_address')
                                       , :new.employee_id || ' salary changed from ' || :old.salary || ' to ' ||                                                        :new.salary);
                 END IF;
END;

Trigger này tập trung vào việc audit để ghi lại các thay đổi trong cột lương (salary) của bảng hr.employees. Khi một dòng được cập nhật, trigger sẽ audit cột lương.

Nếu lương cũ không bằng lương mới, trigger sẽ chèn một bản ghi audit vào bảng audit_employees (được tạo ra thông qua một thao tác riêng trong schema SYSTEM).

Bản ghi audit bao gồm tên người dùng, địa chỉ IP từ đó thay đổi được thực hiện, khóa chính xác định xem bản ghi nào đã bị thay đổi và các giá trị lương thực tế đã thay đổi.

Các trigger cơ sở dữ liệu cũng có thể được sử dụng để ghi lại thông tin về kết nối người dùng trong trường hợp audit cơ sở dữ liệu tiêu chuẩn không thu thập đủ dữ liệu. Với trigger login, người quản trị có thể thu thập dữ liệu để xác định người dùng đang kết nối vào cơ sở dữ liệu.

Ví dụ bao gồm:

• Địa chỉ IP của người đăng nhập.
• 48 ký tự đầu tiên của tên chương trình được sử dụng để kết nối với cơ sở dữ liệu.
• Tên thiết bị đầu cuối được sử dụng để kết nối với cơ sở dữ liệu.

Trong nhiều trường hợp, các trigger dựa trên giá trị đã được thay thế bằng tính năng audit FGA (fine-grained auditing - FGA).

Fine-Grained auditing(FGA)

Audit FGA (Fine-Grained auditing) là việc giám sát truy cập dữ liệu dựa trên nội dung, audit các thao tác select, insert, update, delete và merge. Nó có thể liên kết với một hoặc nhiều cột trong một bảng hoặc view, có thể thực thi một Procedure và được quản lý bằng Package DBMS_FGA.

Trong audit FGA, chúng ta có thể xác định các quy tắc audit tùy biến cho một bảng hoặc view cụ thể. Khi các thao tác truy cập dữ liệu được thực hiện trên các cột liên quan, hệ thống sẽ ghi lại các hoạt động này vào một bảng audit được chỉ định.

Việc thiết lập audit FGA liên quan đến việc định nghĩa các Policy audit và áp dụng chúng cho các đối tượng dữ liệu cụ thể. Điều này cho phép chúng ta tùy chỉnh cách mà dữ liệu được audit và ghi lại, cũng như xác định người dùng hoặc vai trò người dùng nào có quyền truy cập vào thông tin audit.

Quản lý audit FGA có thể được thực hiện thông qua Package DBMS_FGA. Package này cung cấp các Procedure và hàm để Create, Alter và Drop các Policy audit, cũng như truy xuất các thông tin audit đã được ghi lại.

Tóm lại, Audit cơ sở dữ liệu ghi lại thực tế rằng một hoạt động đã xảy ra, nhưng không ghi lại thông tin cụ thể về câu lệnh gây ra hoạt động đó. Audit FGA (Fine-grained auditing - FGA) mở rộng khả năng này để cho phép ghi lại các câu lệnh SQL thực tế truy vấn hoặc thao tác dữ liệu.

FGA cũng cho phép audit tập trung hơn so với audit cơ sở dữ liệu tiêu chuẩn hoặc dựa trên giá trị. Tùy chọn FGA có thể focus vào các cột riêng lẻ trong một bảng hoặc view và thậm chí có thể có điều kiện, chỉ ghi lại audit nếu các điều kiện do quản trị viên xác định được đáp ứng.

Một Policy FGA có thể hỗ trợ nhiều cột liên quan. Mặc định, nếu bất kỳ một trong các cột này xuất hiện trong câu lệnh SQL, nó sẽ được audit. Có DBMS_FGA.ALL_COLUMNS và DBMS_FGA.ANY_COLUMNS để audit dựa trên việc sử dụng tất cả hoặc bất kỳ cột liên quan nào trong câu lệnh.

Sử dụng package DBMS_FGA để tạo một Policy audit trên bảng hoặc view đích. Nếu bất kỳ hàng nào được trả về từ một khối truy vấn khớp với cột được audit và điều kiện audit được chỉ định, một sự kiện audit sẽ tạo ra một bản ghi audit và lưu trữ trong hệ thống audit.

Tạo FGA Policy trong Oracle Database

Ví dụ trong hình trên là mô tả cho việc tạo một Policy audit FGA bằng procedure DBMS_FGA.ADD_POLICY, Procedure này nhận các đối số sau:

Policy Name:

Bạn gán cho mỗi Policy audit FGA một tên khi bạn tạo nó. Ví dụ trong hình trên đang đặt tên Policy là AUDIT_EMPS_SALARY bằng cách sử dụng đối số: policy_name => 'audit_emps_salary'

Audit Condition:

Điều kiện audit là một biểu thức SQL xác định khi sự kiện audit phải kích hoạt. Trong ví dụ trên, tất cả các hàng trong phòng ban có ID là 10 được audit bằng cách sử dụng đối số điều kiện: audit_condition => 'department_id = 10'

Lưu ý: Audit FGA xem xét tập kết quả của truy vấn, vì vậy với Policy FGA được hiển thị trong hình trên, các truy vấn trả về các hàng khớp với các quy định Policy sẽ tạo ra một bản ghi audit.

Ví dụ, trong truy vấn "select * from employees", tất cả các hàng bao gồm cả những hàng có "10" trong DEPARTMENT_ID có thể được trả về, do đó một bản ghi audit cũng được tạo ra.

Audit Column:

Cột audit xác định dữ liệu đang được audit. Một sự kiện audit xảy ra nếu cột này được bao gồm trong câu lệnh SELECT hoặc nếu điều kiện audit cho phép lựa chọn. Ví dụ trong hình trên là đang audit hai cột bằng cách sử dụng đối số: audit_column => 'SALARY, COMMISION_PCT'. Đối số này là tùy chọn. Nếu không được chỉ định, chỉ định AUDIT_CONDITION xác định liệu sự kiện audit có xảy ra hay không.

Object:

Đối tượng là bảng hoặc view đang được audit. Nó được truyền dưới dạng hai đối số:

- Schema chứa đối tượng

- Tên của đối tượng

Ví dụ trong hình trên đang audit bảng hr.employees bằng cách sử dụng các đối số: object_schema => 'hr', object_name => 'employees'.

Bộ xử lý (Handler):

Một bộ xử lý sự kiện tùy chọn là một Procedure PL/SQL xác định các hành động bổ sung cần được thực hiện trong quá trình audit.

Ví dụ, bộ xử lý sự kiện có thể gửi thông báo cảnh báo đến quản trị viên. Nếu không được định nghĩa, một bản ghi sự kiện audit sẽ được chèn vào hệ thống audit. Nếu một bộ xử lý sự kiện audit được định nghĩa, bản ghi audit sẽ được insert vào hệ thống audit và bộ xử lý sự kiện audit sẽ được thực thi.

Bản ghi sự kiện audit bao gồm Policy FGA gây ra sự kiện, người dùng thực thi câu lệnh SQL và câu lệnh SQL cùng với các biến bind của nó.

Bộ xử lý sự kiện được truyền dưới dạng hai đối số:

• Schema chứa đơn vị chương trình PL/SQL
• Tên của đơn vị chương trình PL/SQL

Ví dụ trong hình trên thực thi Procedure SECURE.LOG_EMPS_SALARY bằng cách sử dụng các đối số: handler_schema => 'secure', handler_module => 'log_emps_salary'.

Mặc định, hệ thống audit luôn ghi văn bản SQL và thông tin bind SQL vào LOB (Large Object). Mặc định này có thể thay đổi (ví dụ, nếu hệ thống gặp sự suy giảm hiệu suất).

Status:

Trạng thái chỉ ra xem Policy FGA có được kích hoạt hay không. Trong ví dụ trên, đối số sau kích hoạt Policy: enable => TRUE.

Audit DML statements: Considerations

Với một Policy FGA được định nghĩa cho các câu lệnh DML, một câu lệnh DML sẽ được audit nếu các hàng dữ liệu (cả hàng mới và hàng cũ) đang được thao tác đáp ứng các tiêu chí của mệnh đề Policy.

Tuy nhiên, nếu các cột liên quan cũng được chỉ định trong định nghĩa Policy, câu lệnh sẽ được audit khi dữ liệu đáp ứng mệnh đề Policy FGA và câu lệnh tham chiếu đến các cột liên quan đã được xác định.

Đối với câu lệnh DELETE, việc chỉ định các cột liên quan trong quá trình định nghĩa Policy không hữu ích vì tất cả các cột trong bảng đều bị ảnh hưởng bởi một câu lệnh DELETE. Do đó, một câu lệnh DELETE luôn được audit dù có liên quan đến các cột liên quan hay không.

Các câu lệnh MERGE được hỗ trợ bởi FGA. Các câu lệnh INSERT, UPDATE và DELETE ẩn sau câu lệnh MERGE sẽ được audit nếu chúng đáp ứng các Policy FGA đã được định nghĩa cho INSERT, UPDATE hoặc DELETE.

Sử dụng Policy FGA đã được định nghĩa trước đó, câu lệnh đầu tiên không được audit trong khi câu lệnh thứ hai được audit. Không có nhân viên nào trong phòng ban 10 nhận hoa hồng, nhưng employee_id=200 xác định một nhân viên trong phòng ban 10.

Hướng dẫn cách khai báo FGA Policy trong Oracle Database

• Để audit tất cả các hàng, hãy sử dụng điều kiện audit trống.
• Để audit tất cả các cột, hãy sử dụng cột audit trống.
• Tên Policy phải là duy nhất.
• Bảng hoặc view cần được audit phải tồn tại trước khi tạo Policy.
• Nếu cú pháp của điều kiện audit không hợp lệ, khi truy cập vào đối tượng audit, sẽ xảy ra lỗi ORA-28112.
• Nếu cột audit không tồn tại trong bảng, không có hàng nào sẽ được audit.
• Nếu trình xử lý sự kiện không tồn tại, sẽ không có lỗi trả về và bản ghi audit vẫn được tạo ra.

Đối với các câu lệnh SELECT, FGA ghi lại chính câu lệnh đó chứ không phải các hàng dữ liệu cụ thể. Tuy nhiên, khi kết hợp FGA với Flashback Query, chúng ta có thể tái tạo các hàng dữ liệu như chúng tồn tại vào thời điểm đó. Để biết thêm thông tin chi tiết về Package DBMS_FGA, xin vui lòng tham khảo.

Để tránh dữ liệu audit trở nên quá lớn, chúng ta cần định kỳ lưu trữ và xóa bỏ dữ liệu đó.

Cách lưu trữ:

• Chúng ta có thể sao chép các bản ghi dữ liệu audit vào một bảng trong cơ sở dữ liệu.
• Một lựa chọn khác là sử dụng công cụ Oracle Audit Vault.

Cách xóa bỏ:

• Chúng ta có thể tạo và đặt lịch chạy một công việc xóa bỏ dữ liệu audit vào thời điểm nhất định, bằng cách sử dụng Procedure PL/SQL DBMS_AUDIT_MGMT.CREATE_PURGE_JOB.
• Hoặc có thể xóa bỏ thủ công, sử dụng Procedure PL/SQL DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL.

Bảo trì cơ bản của dữ liệu audit bao gồm việc xem xét các bản ghi audit và loại bỏ những bản ghi cũ. Nếu không thực hiện việc này định kỳ, dữ liệu audit sẽ tiếp tục tăng lên và chiếm hết không gian lưu trữ. Nếu không gian lưu trữ của cơ sở dữ liệu đầy, các hoạt động audit sẽ không thể tiếp tục thực hiện.

Purging audit trail records

Để xóa dữ liệu audit, chúng ta sử dụng Policy DBMS_AUDIT_MGMT. Để sử dụng Policy này, bạn cần có role AUDIT_ADMIN. Oracle Database sẽ ghi lại tất cả các thao tác sử dụng các Procedure trong Policy DBMS_AUDIT_MGMT.

Procedure DBMS_AUDIT_MGMT.CREATE_PURGE_JOB cho phép xóa bỏ các bản ghi dữ liệu audit. Bạn có thể đặt thuộc tính CONTAINER thành CONTAINER_CURRENT để chỉ xóa bỏ dữ liệu audit cho cơ sở dữ liệu hiện tại.

Nếu đặt CONTAINER thành CONTAINER_ALL, toàn bộ dữ liệu audit sẽ được xóa trong tất cả các cơ sở dữ liệu, và một công việc xóa bỏ sẽ được tạo ra trong cơ sở dữ liệu chính. Quá trình triệu hồi công việc này sẽ kích hoạt việc xóa bỏ dữ liệu audit trong tất cả các cơ sở dữ liệu con.

Thuộc tính USE_LAST_ARCH_TIMESTAMP quyết định liệu chúng ta có sử dụng thời điểm lưu trữ cuối cùng để xác định các bản ghi cần xóa hay không.

Nếu đặt USE_LAST_ARCH_TIMESTAMP thành TRUE, chỉ các bản ghi dữ liệu audit được tạo trước thời điểm lưu trữ cuối cùng sẽ bị xóa. Nếu đặt thành FALSE, tất cả các bản ghi dữ liệu audit sẽ bị xóa. Mặc định, Oracle khuyến nghị sử dụng giá trị TRUE để tránh xóa nhầm các bản ghi quan trọng.

Để tự động hóa quá trình xóa bỏ, bạn có thể tạo và lập lịch chạy một job xóa, hoặc thực hiện công việc xóa bỏ thủ công.

Nếu bạn thực hiện thủ công, sử dụng Procedure thủ tục DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL với giá trị loại là BMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED.