Cấu hình Audit trong Database để ghi log các thao tác nhạy cảm
Chúng ta sẽ bật tính năng Audit Policy trong PostgreSQL để bắt các sự kiện nhạy cảm như thay đổi dữ liệu, truy cập vào các bảng chứa thông tin cá nhân (PII), hoặc thay đổi quyền hạn.
Trước tiên, cần đảm bảo extension pgaudit đã được cài đặt. Nếu chưa, hãy chạy lệnh cài đặt module này vào thư mục extension của PostgreSQL.
sudo apt-get install postgresql-15-pgaudit
Kết quả: Package postgresql-15-pgaudit được cài đặt thành công, không có lỗi.
Chuyển sang cấu hình file postgresql.conf để kích hoạt module audit. File này thường nằm tại /etc/postgresql/15/main/postgresql.conf (tùy phiên bản, kiểm tra bằng pg_config --sysconfdir).
Sửa file cấu hình, thêm dòng sau vào phần Shared Preload Libraries để tải module pgaudit khi khởi động server.
shared_preload_libraries = 'pgaudit'
Kết quả: Không có lỗi cú pháp, file được lưu.
Trong cùng file postgresql.conf, thiết lập chính sách audit để ghi log các hành động SELECT, INSERT, UPDATE, DELETE vào các bảng nhạy cảm. Chúng ta sẽ dùng tham số pgaudit.log.
pgaudit.log = 'DDL, DML, Role'
Kết quả: Server sẽ bắt đầu ghi log mọi lệnh DDL (tạo bảng), DML (thao tác dữ liệu) và thay đổi Role.
Để áp dụng cấu hình này, cần khởi động lại dịch vụ PostgreSQL.
sudo systemctl restart postgresql
Kết quả: Dịch vụ khởi động lại thành công, trạng thái active (running).
Trong database, kích hoạt extension pgaudit cho database mục tiêu (ví dụ: my_secure_db). Kết nối vào database bằng user postgres.
psql -U postgres -d my_secure_db -c "CREATE EXTENSION pgaudit;"
Kết quả: Thông báo CREATE EXTENSION xuất hiện.
Thiết lập mức độ chi tiết cho audit log bằng tham số pgaudit.log tại cấp độ session hoặc database. Ở đây, ta đặt toàn cầu để bắt mọi thao tác DDL và DML.
psql -U postgres -d my_secure_db -c "ALTER DATABASE my_secure_db SET pgaudit.log = 'DDL, DML';"
Kết quả: Lệnh ALTER DATABASE thực thi thành công.
Verify kết quả phần Database Audit
Thực hiện một lệnh DML mẫu (ví dụ: SELECT từ bảng nhạy cảm) và kiểm tra log file của PostgreSQL (thường nằm trong /var/log/postgresql/).
psql -U postgres -d my_secure_db -c "SELECT * FROM sensitive_table LIMIT 1;"
Đợi vài giây, sau đó xem log:
grep "AUDIT" /var/log/postgresql/postgresql-15-main.log | tail -n 5
Kết quả mong đợi: Xuất hiện dòng log chứa từ khóa AUDIT, SELECT, tên bảng và thông tin user thực thi.
Tích hợp Linux Audit (auditd) để theo dõi truy cập file hệ thống
Database Audit chỉ ghi log ở mức ứng dụng. Để bảo vệ toàn diện, ta cần dùng auditd của Linux để giám sát ai đang truy cập trực tiếp vào các file dữ liệu (.dat) hoặc file cấu hình của database trên hệ thống file.
Đảm bảo dịch vụ auditd đang chạy và được cấu hình cơ bản.
sudo systemctl status auditd
Kết quả: Trạng thái active (running). Nếu chưa chạy, dùng sudo systemctl start auditd.
Xác định đường dẫn thư mục dữ liệu của PostgreSQL. Thường là /var/lib/postgresql/15/main. Chúng ta sẽ tạo rule để theo dõi mọi hành động đọc (read), ghi (write), mở (open) và thực thi (execute) trong thư mục này.
sudo auditctl -w /var/lib/postgresql/15/main -p rwa -k db_data_access
Kết quả: Không có thông báo lỗi, rule được thêm vào danh sách quy tắc tạm thời.
Để rule này tồn tại sau khi reboot, cần thêm vào file cấu hình /etc/audit/audit.rules.
sudo nano /etc/audit/audit.rules
Thêm dòng sau vào cuối file:
-w /var/lib/postgresql/15/main -p rwa -k db_data_access
Kết quả: File được lưu, không có lỗi cú pháp.
Để theo dõi ai đang cố gắng đọc hoặc sửa file cấu hình postgresql.conf và pg_hba.conf (thường nằm ở /etc/postgresql/15/main/).
sudo auditctl -w /etc/postgresql/15/main/postgresql.conf -p wa -k db_config_change
sudo auditctl -w /etc/postgresql/15/main/pg_hba.conf -p wa -k db_config_change
Kết quả: Hai rule mới được thêm vào auditd.
Tương tự, thêm vào file /etc/audit/audit.rules để đảm bảo tính bền vững:
-w /etc/postgresql/15/main/postgresql.conf -p wa -k db_config_change
-w /etc/postgresql/15/main/pg_hba.conf -p wa -k db_config_change
Kết quả: File được cập nhật, chứa đầy đủ các rule giám sát.
Khởi động lại dịch vụ auditd để áp dụng các rule từ file cấu hình.
sudo systemctl restart auditd
Kết quả: Dịch vụ khởi động lại thành công.
Verify kết quả phần Linux Audit
Thực hiện truy cập file dữ liệu bằng lệnh cat hoặc ls để kích hoạt rule db_data_access.
sudo cat /var/lib/postgresql/15/main/base/16384/12345 2>/dev/null || echo "File not found, but rule triggered"
Sau đó, kiểm tra log audit của Linux.
ausearch -k db_data_access -i
Kết quả mong đợi: Xuất hiện log chi tiết với trường key= là db_data_access, hiển thị user nào (uid), command nào đã thực hiện truy cập.
Cấu hình chính sách log: Lọc, định dạng và lưu trữ log an toàn
Log audit và database có thể rất lớn và chiếm nhiều tài nguyên. Chúng ta cần cấu hình để lọc nhiễu, định dạng chuẩn và lưu trữ an toàn, tránh bị tấn công giả mạo log.
Cấu hình file /etc/audit/auditd.conf để định dạng log và kích thước file.
sudo nano /etc/audit/auditd.conf
Sửa các tham số sau:
log_format = RAW
log_file = /var/log/audit/audit.log
max_log_file = 50
num_logs = 5
flush = INCREMENTAL_ASYNC
Kết quả: File được lưu, cấu hình cho phép log dạng RAW (chưa giải mã) để bảo vệ tính toàn vẹn, và xoay vòng log (log rotation) sau 50MB.
Thiết lập quyền sở hữu và quyền truy cập cho thư mục log audit để chỉ root và audit user mới có quyền đọc, ngăn chặn hacker xóa log.
sudo chown -R root:root /var/log/audit
sudo chmod -R 600 /var/log/audit
Kết quả: Quyền truy cập bị giới hạn, user thường không thể cat file log.
Đối với PostgreSQL, cấu hình log_directory và log_filename trong postgresql.conf để tách biệt log audit khỏi log thông thường, hoặc dùng pgaudit để định dạng log riêng.
Thêm tham số vào /etc/postgresql/15/main/postgresql.conf:
log_directory = '/var/log/postgresql/audit'
log_filename = 'postgresql-audit-%Y-%m-%d'
log_rotation_age = 1d
log_rotation_size = 100MB
Kết quả: File log sẽ được tạo mới mỗi ngày và xoay vòng sau 100MB.
Tạo thư mục log mới và đặt quyền an toàn.
sudo mkdir -p /var/log/postgresql/audit
sudo chown postgres:postgres /var/log/postgresql/audit
sudo chmod 700 /var/log/postgresql/audit
Kết quả: Thư mục được tạo, chỉ user postgres có quyền truy cập.
Khởi động lại PostgreSQL để áp dụng cấu hình log mới.
sudo systemctl restart postgresql
Kết quả: Dịch vụ chạy lại, log mới được ghi vào thư mục audit.
Để bảo vệ file log audit khỏi bị xóa ngay cả khi hacker đã có quyền root (trong một số trường hợp), ta có thể dùng chattr +i (immutable) cho các file log đã đóng. Tuy nhiên, điều này cần cơ chế tự động để bật/tắt khi log mới được tạo. Ở đây, ta dùng auditd để giám sát việc xóa log.
sudo auditctl -w /var/log/audit -p wa -k log_modification
sudo auditctl -w /var/log/postgresql/audit -p wa -k db_log_modification
Kết quả: Bất kỳ hành động viết (w) hoặc xóa (a) vào thư mục log đều sẽ bị ghi lại.
Verify kết quả phần Log Policy
Thử xóa một dòng trong file log audit (nếu có quyền) hoặc tạo một file mới.
echo "test" >> /var/log/audit/audit.log
Kiểm tra xem hành động này có được ghi lại không.
ausearch -k log_modification -i | tail -n 10
Kết quả mong đợi: Log audit ghi lại hành động viết vào file log của chính nó, chứng tỏ cơ chế giám sát log hoạt động.
Triển khai cơ chế cảnh báo tự động khi phát hiện hành vi đáng ngờ
Chúng ta sẽ xây dựng một script đơn giản để quét log audit liên tục, phát hiện các mẫu hành vi nguy hiểm (như truy cập file cấu hình vào giờ không làm việc, hoặc truy cập bảng nhạy cảm bởi user lạ) và gửi cảnh báo.
Tạo thư mục cho script và file script /usr/local/bin/audit_monitor.sh.
sudo nano /usr/local/bin/audit_monitor.sh
Viết nội dung script sau:
#!/bin/bash
# Đường dẫn file log audit
LOG_FILE="/var/log/audit/audit.log"
ALERT_LOG="/var/log/audit/alerts.log"
# Từ khóa cảnh báo nguy hiểm
KEYWORDS="db_config_change|db_data_access"
# Kiểm tra log mới nhất (100 dòng cuối)
LAST_ENTRIES=$(ausearch -k "$KEYWORDS" -i --start today | tail -n 100)
if [ -n "$LAST_ENTRIES" ]; then
# Nếu có sự kiện nào chứa "failed" hoặc "uid=0" (root) truy cập file db
if echo "$LAST_ENTRIES" | grep -E "failed|uid=0.*db_data_access"; then
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
MESSAGE="ALERT: Suspicious database activity detected at $TIMESTAMP"
# Ghi vào log cảnh báo
echo "$MESSAGE" >> $ALERT_LOG
echo "$LAST_ENTRIES" >> $ALERT_LOG
# Gửi email (cần cài mailx hoặc ssmtp)
# echo "$MESSAGE" | mail -s "DB Security Alert" admin@example.com
echo "ALERT SENT: $MESSAGE"
fi
fi
Kết quả: Script được lưu, nội dung kiểm tra các sự kiện audit theo từ khóa.
Đặt quyền thực thi cho script.
sudo chmod +x /usr/local/bin/audit_monitor.sh
Kết quả: Script có thể chạy trực tiếp.
Thiết lập crontab để chạy script mỗi 5 phút.
sudo crontab -e
Thêm dòng sau vào cuối file crontab:
*/5 * * * * /usr/local/bin/audit_monitor.sh
Kết quả: Crontab được lưu, task được thêm vào lịch trình.
Để test ngay lập tức, chạy script thủ công.
sudo /usr/local/bin/audit_monitor.sh
Kết quả: Nếu có sự kiện đáng ngờ trong log gần đây, script sẽ in dòng ALERT SENT và ghi vào file /var/log/audit/alerts.log.
Để cảnh báo qua Slack hoặc Webhook (tùy chọn nâng cao), ta có thể thêm lệnh curl vào script. Ví dụ gửi cảnh báo đến Webhook Slack:
curl -X POST -H 'Content-type: application/json' --data '{"text":"DB Security Alert: Suspicious activity detected"}' https://hooks.slack.com/services/YOUR/WEBHOOK/URL
Kết quả: Cảnh báo được gửi đến kênh Slack (nếu cấu hình đúng).
Verify kết quả phần Alert System
Thử kích hoạt một hành vi "đáng ngờ" bằng cách giả lập truy cập file cấu hình bằng root vào giờ bất thường (hoặc bất kỳ lúc nào để test logic).
sudo cat /etc/postgresql/15/main/pg_hba.conf
Chờ 5 phút (hoặc chạy script thủ công lại).
sudo /usr/local/bin/audit_monitor.sh
Kiểm tra file cảnh báo.
cat /var/log/audit/alerts.log
Kết quả mong đợi: File alerts.log có nội dung mới, ghi nhận sự kiện truy cập file cấu hình và thông báo cảnh báo.
Điều hướng series:
Mục lục: Series: Triển khai Database An toàn với TDE, Audit và Linux Kernel Hardening
« Phần 4: Triển khai TDE (Transparent Data Encryption) cho dữ liệu
Phần 6: Tối ưu hóa, Troubleshooting và mẹo nâng cao »