IBM Guardium Kiểm soát các truy cập vào dữ liệu nhạy cảm và xác định các hành vi bất thường

Kiểm soát các truy cập vào dữ liệu nhạy cảm và xác định các hành vi bất thường​

1. Query Rewrite​

Query Rewrite cung cấp cơ chế kiểm soát truy cập ở mức chi tiết, bằng cách tự động sửa đổi câu truy vấn cơ sở dữ liệu dựa trên chính sách bảo mật đã thiết lập, giúp người dùng vẫn nhận được kết quả từ câu lệnh SQL đã chỉnh sửa mà không gây gián đoạn hay phát sinh độ trễ. Các bước cấu hình:

Bước 1: Đảm bảo tính năng Query Rewrite đã được enable trên S-TAP của DB server cần áp dụng.
Chỉnh sửa dòng qrw_installed=1 và qrw_default_state=0

Xác nhận kết quả:

Dùng GIM tạm thời để STAP tự nhận lại cấu hình mới và xác nhận STAP đã nhật tham số query rewriting trong log

Bước 2: Vào Protect > Security Policies > Policy Builder For Data, tạo một policy mới với thông tin

Bước 3: Tại phần Query Rewrite Builder, tạo một Query Rewrite Definition để định nghĩa cách câu truy vấn sẽ được viết lại

Tạo 1 kịch bản che dấu dữ liệu khi người dùng Select vào các cột trong bảng Customer sẽ che dấu thông tin nhạy cảm như cccd và credit_card.

Kiểm tra xem kết quả sau khi rewriting:

Tạo thử 1 user và thực hiện các câu truy vấn vào dữ liệu nhạy cảm

Bước 4: Quay lại Policy POL_QUERY_REWRITE_RETAIL, vào phần Rules và thêm lần lượt 3 rules theo đúng thứ tự:

• Rule với action QUERY REWRITE: ATTACH - thiết lập điều kiện để bắt đầu theo dõi (watch) một phiên làm việc.

• Rule với action QUERY REWRITE: APPLY DEFINITION - áp dụng định nghĩa rewrite đã tạo ở Bước 3 khi câu truy vấn khớp điều kiện.

• Rule với action QUERY REWRITE: DETACH - thiết lập điều kiện để dừng theo dõi phiên làm việc.

Bước 5: Cài đặt (Install) policy để áp dụng cấu hình.

Bước 6: Kiểm tra: thực hiện một câu truy vấn thử nghiệm từ phía client, xác nhận kết quả trả về đã được viết lại che dấu thông tin nhạy cảm .

-> Nếu người dùng sử dùng lệnh SELECT * FROM RETAIL.CUSTOMERS; thì police sẽ không được kích hoạt nên cần thêm 1 rule dành riêng cho case này

-> Kết quả không làm lộ hết các thông tin nhạy cảm chỉ hiển thị cột id như đã thiết lập

2. Redaction​

• Inspect Returned Data: Cho phép S-TAP bắt gói tin theo chiều từ Database gửi về phía Client (Server-to-Client - S2C) thay vì chỉ giám sát câu lệnh gửi đi. Đây là điều kiện bắt buộc để thực hiện che giấu dữ liệu nhạy cảm (Data Redaction) như CCCD, thẻ tín dụng,...
• Log Records Affected: Bật tính năng đếm và ghi nhận số lượng bản ghi (rows) bị ảnh hưởng bởi câu lệnh SQL trả về.

Ngoài ra cần sửa lại tham số trong guard_tap.ini, thay đổi FIREWALL_INSTALLED=0 sang 1

Khởi động lại STAP:

Redaction là chức năng biên tập nhằm che giấu các mẫu dữ liệu nhạy cảm phổ biến, chẳng hạn số thẻ ngân hàng (creditcard), số Căn cước công dân (CCCD).
Các bước cấu hình:

Bước 1: Vào Protect > Security Policies > Policy Builder for Data, tạo mới một Policy.

Kịch bản 1: Chuẩn PCI-DSS Che Credit card, chỉ giữ 4 số cuối và Chuẩn PII Che số CCCD

Bước 2: Thêm một Rule type: Extrusion.

Bước 3: Tại Rule criteria, ở Data pattern nhập biểu thức chính quy (regular expression) khớp với mẫu dữ liệu nhạy cảm cần che
Truy cập link: https://www.ibm.com/docs/en/gdp/11.5.0?topic=examples-redacting-data-example
Xem cách tạo data pattern nhận dạng dữ liệu CCCD và Credit card

Bước 4: Tại Rule action là REDACT và chọn REDACT và có thể kèm theo LOG FULL DETAIL nếu muốn ghi audit ra log.

Bước 5: Install policy để áp dụng ngay, sau đó bấm Run Once Now.

Bước 6: Kiểm tra: thực hiện một truy vấn có chứa dữ liệu nhạy cảm phù hợp với mẫu đã cấu hình, xác nhận phần dữ liệu tương ứng trong kết quả trả về đã được che bằng ký tự mask trước khi hiển thị cho người dùng.
Tạo 1 người dùng mới thử SELECT bảng credit_card xem kết quả

3. Blocking Action​

Blocking Action cho phép chủ động ngăn chặn truy cập khi phát hiện vi phạm chính sách, thông qua cơ chế S-TAP Terminate. Các bước cấu hình:

Bước 1: Vào Protect > Security Policies > Policy Builder For Data, create một Access Policy.

Kịch bản đặt ra: Khi người dùng có hành vi thực hiện các câu lệnh DELECT/DROP trên bảng chứa dữ liệu quan trọng RETAIL.CUSTOMERS thì sẽ nhận ngay 1 hành động trừng phạt lập tức bị chấm dứt phiên làm việc.

Bước 2: Thêm một rule mới, thiết lập điều kiện xác định vi phạm cần chặn

Bước 3: Chọn rule action tương ứng với cơ chế muốn áp dụng:

• S-TAP Terminate: chấm dứt kết nối/phiên làm việc vi phạm. Cơ chế này luôn có sẵn trong S-TAP, không phụ thuộc vào việc có sử dụng S-GATE hay không.

Bước 4: Cài đặt (Install) policy để áp dụng cấu hình và kiểm tra kết quả.

Dùng tài khoản user bình thường thì thực hiện lệnh vi phạm và kiểm trả kết quả thiết lập

Đối với S-TAP Terminate:

Khi bị vi phạm người dùng ngay bị ngắt kết nối hiện tại với những lâu lệnh sau đó nhờ cơ chế S-TAP TERMINATE, chỉ có thể kích hoạt lại bằng Session mới

Bước 5: Vào Dashboard giám sát để kiểm tra kết quả, xác nhận các phiên vi phạm đã được ghi nhận và chấm dứt theo đúng cấu hình.
Bảng xem Log:

Note: Hiện tại do hạn chế về kịch bạn ít nên dashboard sẽ không thể hiện được đa dạng