Khởi tạo và cấu hình gói auditd trên hệ điều hành
Bước đầu tiên là cài đặt và kích hoạt dịch vụ auditd để hệ thống Linux bắt đầu ghi lại các sự kiện truy cập.
Tại sao: Auditd là kernel module chịu trách nhiệm thu thập và ghi log các sự kiện hệ thống. Nếu không chạy, không có dữ liệu audit nào được tạo ra.
Kết quả mong đợi: Dịch vụ auditd đang chạy (active) và tự động khởi động khi reboot.
Trên các hệ thống dựa trên Debian/Ubuntu (như PostgreSQL thường chạy), thực hiện lệnh cài đặt:
sudo apt-get update && sudo apt-get install -y auditd audispd-plugins
Kiểm tra trạng thái dịch vụ:
sudo systemctl status auditd
Nếu dịch vụ chưa chạy, bật và khởi động ngay:
sudo systemctl enable auditd && sudo systemctl start auditd
Trên các hệ thống dựa trên RHEL/CentOS/AlmaLinux, sử dụng lệnh:
sudo dnf install -y audit
sudo systemctl enable auditd && sudo systemctl start auditd
Cấu hình định dạng log và vị trí lưu trữ tập tin audit
Chúng ta cần cấu hình file chính của auditd để xác định nơi lưu log và kích thước file tối đa, tránh tràn disk.
Tại sao: Cấu hình mặc định có thể lưu log vào /var/log/audit/audit.log với kích thước không giới hạn hoặc quá lớn, gây ảnh hưởng đến disk I/O của database server.
Kết quả mong đợi: File cấu hình /etc/audit/auditd.conf được chỉnh sửa, log được lưu theo quy tắc vòng xoay (rotate) định kỳ.
Chỉnh sửa file cấu hình chính tại đường dẫn đầy đủ /etc/audit/auditd.conf. Sử dụng nano hoặc vi để mở file:
sudo nano /etc/audit/auditd.conf
Sửa các dòng sau trong file để phù hợp với môi trường Production:
log_format = ENRICHED
log_group = audit
max_log_file = 128
num_logs = 5
max_log_file_action = ROTATE
space_left = 75
space_left_action = SUSPEND
action_mail_acct = root
admin_mail_action = SUSPEND
flush = INCREMENTAL_ASYNC
Giải thích các tham số quan trọng:
- max_log_file = 128: Giới hạn kích thước mỗi file log là 128 MB để tránh file quá lớn.
- num_logs = 5: Giữ lại 5 file log cũ (tổng dung lượng tối đa khoảng 640MB).
- max_log_file_action = ROTATE: Tự động xoay vòng log khi đạt giới hạn kích thước.
- space_left = 75: Ngừng ghi log khi disk còn dưới 75% dung lượng trống để tránh làm hệ thống treo.
- flush = INCREMENTAL_ASYNC: Ghi log không đồng bộ để giảm tác động đến hiệu năng I/O của PostgreSQL.
Sau khi lưu file, cần khởi động lại dịch vụ auditd để áp dụng cấu hình mới:
sudo systemctl restart auditd
Verify kết quả: Kiểm tra xem file log mới được tạo và đường dẫn đúng như cấu hình:
ls -lh /var/log/audit/audit.log
Nếu thấy file có kích thước ban đầu (thường là 0 hoặc vài KB) và group là audit, cấu hình thành công.
Thiết lập quy tắc ghi log cho các lệnh SQL nhạy cảm
Bước này là cốt lõi: chúng ta sẽ thêm các quy tắc (rules) để auditd bắt các cuộc gọi hệ thống (system calls) liên quan đến truy xuất dữ liệu nhạy cảm của PostgreSQL.
Tại sao: Auditd không hiểu cú pháp SQL trực tiếp. Nó hoạt động ở mức kernel. Để audit các lệnh SQL, ta cần theo dõi các file mở (open/read) hoặc các cuộc gọi execve của quá trình postgres đối với các file dữ liệu hoặc lệnh shell đặc thù, hoặc theo dõi các syscall liên quan đến I/O của tiến trình postgres.
Kết quả mong đợi: Các file log audit sẽ ghi lại sự kiện khi tiến trình postgres truy cập vào các file nhạy cảm hoặc thực thi các lệnh cụ thể.
Trước tiên, cần tìm ra User ID (UID) của người dùng đang chạy PostgreSQL. Thường là 'postgres' hoặc 'pgsql'. Giả sử user là postgres:
id postgres
Ghi nhớ UID (ví dụ: 26) để dùng trong lệnh audit.
Sử dụng công cụ auditctl để thêm quy tắc theo dõi việc mở file (syscall openat, open) đối với tiến trình postgres. Quy tắc này sẽ ghi lại mọi lần tiến trình postgres mở một file.
Thêm quy tắc cho syscall 'openat' và 'open' với mức độ lọc là 'exit' (khi lệnh kết thúc) và theo dõi tất cả các file:
sudo auditctl -a exit,always -F arch=b64 -S openat -F a0=0 -F uid=26 -k pg_file_access
Giải thích:
- -a exit,always: Ghi log khi syscall kết thúc.
- -F arch=b64: Áp dụng cho kiến trúc 64-bit (dùng b32 nếu server 32-bit).
- -S openat: Theo dõi syscall openat (dùng cho mở file).
- -F uid=26: Chỉ theo dõi user có UID là 26 (postgres).
- -k pg_file_access: Đặt tên khóa (key) là pg_file_access để dễ tìm kiếm trong log sau này.
Tương tự, thêm quy tắc cho syscall 'execve' để theo dõi các lệnh shell được chạy bởi postgres (ví dụ: nếu có script backup hoặc maintenance chạy):
sudo auditctl -a exit,always -F arch=b64 -S execve -F uid=26 -k pg_process_exec
Để theo dõi các lệnh SQL nhạy cảm cụ thể (như DROP TABLE, TRUNCATE, GRANT), cách tiếp cận hiệu quả nhất qua auditd là theo dõi các file log của PostgreSQL hoặc các file data page nếu muốn audit ở mức độ sâu hơn. Tuy nhiên, với yêu cầu "cấu hình cơ bản", chúng ta sẽ tập trung vào việc audit các thao tác trên file cấu hình hoặc file data của DB.
Giả sử chúng ta muốn audit việc truy cập vào thư mục data của PostgreSQL (thường là /var/lib/postgresql/14/main). Thêm quy tắc theo dõi việc mở file trong thư mục này:
sudo auditctl -w /var/lib/postgresql/14/main -p rwa -k pg_data_dir_access
Giải thích:
- -w /path/to/dir: Watch (giám sát) thư mục cụ thể.
- -p rwa: Ghi log khi có hành động Read (r), Write (w), hoặc Attribute change (a).
- -k pg_data_dir_access: Key để lọc log.
Để các quy tắc này tồn tại vĩnh viễn (không mất khi restart), cần thêm chúng vào file cấu hình rules:
sudo nano /etc/audit/rules.d/pg_audit.rules
Dán nội dung các lệnh auditctl trên vào file này, nhưng bỏ từ "sudo auditctl" ở đầu, chỉ giữ lại các tham số:
-a exit,always -F arch=b64 -S openat -F a0=0 -F uid=26 -k pg_file_access
-a exit,always -F arch=b64 -S execve -F uid=26 -k pg_process_exec
-w /var/lib/postgresql/14/main -p rwa -k pg_data_dir_access
Lưu file và áp dụng lại rules:
sudo auditctl -R /etc/audit/rules.d/pg_audit.rules
Verify kết quả cấu hình Audit
Cần thực hiện các bước kiểm tra để đảm bảo auditd đang hoạt động và ghi đúng các sự kiện chúng ta mong đợi.
1. Kiểm tra danh sách các quy tắc đang active:
sudo auditctl -l
Kết quả mong đợi: Xuất hiện 3 quy tắc với các key pg_file_access, pg_process_exec, pg_data_dir_access.
2. Thực hiện một hành động thử nghiệm trên PostgreSQL để tạo sự kiện audit. Ví dụ: tạo một file test trong thư mục data hoặc truy cập file cấu hình:
sudo -u postgres touch /var/lib/postgresql/14/main/test_audit_file.txt
3. Xem log audit để xác nhận sự kiện đã được ghi lại:
ausearch -k pg_data_dir_access -i
Kết quả mong đợi: Xuất hiện dòng log chứa thông tin về user postgres (uid=26), tiến trình (pid=...), và tên file test_audit_file.txt đã được tạo với hành động write (w).
4. Kiểm tra log file trực tiếp nếu ausearch không trả về kết quả ngay:
grep "pg_data_dir_access" /var/log/audit/audit.log
Nếu thấy dòng log có cấu trúc như sau, cấu hình thành công:
type=SYSCALL msg=audit(1678888888.123:456): arch=c000003e syscall=257 success=yes exit=0 comm="touch" pid=12345 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 ses=1 cap=0000000000000000
Điều hướng series:
Mục lục: Series: Triển khai Database an toàn với Transparent Data Encryption và Audit trên Linux
« Phần 1: Chuẩn bị môi trường và yêu cầu hệ thống
Phần 3: Triển khai Transparent Data Encryption (TDE) với pgcrypto »