Thực hiện kiểm thử thâm nhập và quét lỗ hổng bảo mật
Chúng ta sẽ sử dụng OpenVAS hoặc Nmap để quét các cổng mở và lỗ hổng trên các node Database. Mục tiêu là đảm bảo chỉ có các cổng cần thiết (như 5432 cho PostgreSQL, 9000 cho Cooja, hoặc cổng quản lý) đang mở và không có lỗ hổng CVE nghiêm trọng.
Trước khi quét, hãy đảm bảo bạn đã cài đặt nmap trên máy kiểm thử (Attacker Machine) hoặc một node quản lý.
Tại sao: Xác minh rằng các quy tắc iptables hoặc firewalld đã được cấu hình đúng từ Phần 2 và Phần 3, chặn truy cập trái phép vào các cổng nhạy cảm.
Kết quả mong đợi: Chỉ thấy các cổng dịch vụ Database và SSH (nếu cần) đang mở. Các cổng khác phải ở trạng thái filtered hoặc closed.
nmap -sS -sV -O --script vuln -p 1-65535
Thay -sS (Stealth Scan) giúp giảm dấu vết, -sV phát hiện phiên bản, và --script vuln quét các lỗ hổng đã biết.
Để kiểm tra sâu hơn về cấu hình mạng và trạng thái lắng nghe, hãy chạy lệnh sau trên chính node Database (yêu cầu quyền root/sudo):
ss -tulpn | grep LISTEN
Kết quả mong đợi: Danh sách các quy trình đang lắng nghe. Nếu bạn thấy bất kỳ dịch vụ nào không nằm trong kiến trúc Database phân tán (ví dụ: httpd, mysql nếu không dùng), đó là lỗ hổng bảo mật cần tắt ngay.
Verify kết quả kiểm thử thâm nhập
Để xác nhận hệ thống an toàn, hãy thử kết nối trực tiếp từ một máy khách không nằm trong mạng tin cậy (hoặc qua SSH tunnel giả lập) vào cổng Database.
nc -zv
Kết quả: Kết nối bị từ chối (Connection refused) hoặc không phản hồi (timeout) nếu firewall hoạt động tốt. Nếu thấy Succeeded, bạn cần rà soát lại quy tắc firewall.
Đo lường hiệu năng dưới tải cao và so sánh với hệ thống chưa hardening
Chúng ta sẽ sử dụng pgbench (nếu dùng PostgreSQL) hoặc sysbench để tạo tải giả lập. Mục tiêu là đo Throughput (lệnh/giây) và Latency (ms) khi hệ thống đang chạy với các tham số Kernel Hardening và TDE (Transparent Data Encryption).
Tại sao: Hardening và mã hóa thường gây ra overhead (chi phí tính toán). Chúng ta cần đảm bảo overhead này nằm trong ngưỡng chấp nhận được (thường dưới 15-20% so với hệ thống "nguyên bản").
Trước tiên, hãy chuẩn bị một script benchmark đơn giản để chạy trên node Database. Giả sử chúng ta dùng PostgreSQL với TDE.
pgbench -i -s 100 -h -U -d
Lệnh này khởi tạo dữ liệu benchmark với 100 scale factor. Sau đó, chạy bài test với tải cao:
pgbench -T 300 -c 20 -j 4 -h -U -d -f /path/to/complex_query.sql
Trong đó: -T 300 chạy trong 300 giây, -c 20 là 20 client song song, -j 4 là 4 thread mỗi client. File complex_query.sql chứa các truy vấn JOIN và tính toán phức tạp để stress CPU và Disk I/O.
Đồng thời, trên một terminal khác, hãy giám sát hiệu năng thời gian thực:
vmstat 1 300 > /var/log/benchmark_vmstat_hardened.log
Kết quả mong đợi: Bạn sẽ có file log vmstat ghi lại bi (block in), bo (block out), us (user CPU), sy (system CPU). So sánh giá trị này với baseline (hệ thống chưa hardening).
Verify kết quả đo lường hiệu năng
Phân tích file log bằng cách tính trung bình tps (transactions per second) từ output của pgbench và so sánh với latency (tỷ lệ % thời gian chờ).
grep "transaction rate" /var/log/pgbench_output.txt | tail -1
Kết quả: Nếu Throughput giảm dưới 80% so với hệ thống không hardening nhưng Latency vẫn dưới 100ms, hệ thống là chấp nhận được. Nếu Latency tăng vọt (>500ms), cần xem xét tối ưu hóa Kernel (phần sau) hoặc phần cứng (SSD tốc độ cao hơn để bù đắp overhead mã hóa).
Mô phỏng mất node và kiểm tra khôi phục khóa (Secret Sharing)
Trong kiến trúc Secret Sharing (Shamir's), chúng ta chia khóa TDE chính thành N phần (shares) và phân phối cho N node. Để mở khóa dữ liệu, cần ít nhất K phần (K < N). Chúng ta sẽ mô phỏng việc mất một hoặc nhiều node để đảm bảo hệ thống vẫn hoạt động hoặc có cơ chế khôi phục.
Tại sao: Xác minh tính bền vững (resilience) của hệ thống. Nếu mất K node, dữ liệu sẽ bị khóa vĩnh viễn trừ khi có backup. Nếu mất K-1 node, hệ thống phải tự động hoặc thủ công khôi phục được.
Giả sử cấu hình: N=5 node, K=3 (cần 3/5 shares để khôi phục). Hãy mô phỏng mất 2 node (vẫn còn 3 node).
Bước 1: Dừng dịch vụ Database trên 2 node để mô phỏng sự cố.
systemctl stop postgresql.service
Chạy lệnh này trên 2 node bị "mất".
Bước 2: Trên node quản lý (Key Manager), chạy script khôi phục khóa sử dụng các shares từ các node còn lại.
python3 /opt/secret_manager/recover_key.py --nodes 192.168.1.10 192.168.1.11 192.168.1.12 --threshold 3
Script này sẽ liên kết với 3 node còn sống, lấy shares, thực hiện thuật toán Shamir để tái tạo khóa gốc, và sau đó inject lại vào Database đang chạy.
Kết quả mong đợi: Script in ra Key recovered successfully và Database có thể thực hiện các truy vấn SELECT/INSERT bình thường mà không báo lỗi Encryption Key Missing.
Verify khả năng khôi phục
Thử truy vấn dữ liệu nhạy cảm ngay sau khi khôi phục khóa.
psql -U -d -c "SELECT COUNT(*) FROM sensitive_table;"
Kết quả: Trả về số lượng hàng chính xác. Nếu trả về lỗi "FATAL: could not open encryption key", quá trình khôi phục chưa thành công.
Tiếp tục thử nghiệm trường hợp xấu nhất: Mất 3 node (chỉ còn 2). Chạy lại script recover.
python3 /opt/secret_manager/recover_key.py --nodes 192.168.1.10 192.168.1.11 --threshold 3
Kết quả mong đợi: Script báo lỗi Insufficient shares: need 3, got 2. Đây là hành vi đúng theo thiết kế bảo mật. Hệ thống không cho phép khôi phục khi không đủ số shares.
Đọc log và phân tích sự cố mã hóa, đồng bộ
Trong hệ thống phân tán, sự cố thường liên quan đến Network Latency, Key Rotation Failure, hoặc Encryption Mismatch. Chúng ta cần biết cách đọc log để định vị nhanh vấn đề.
Tại sao: Log là nguồn thông tin duy nhất để hiểu hành vi của hệ thống khi xảy ra lỗi, đặc biệt là các lỗi liên quan đến mật mã (cryptographic errors) thường không hiển thị rõ ràng trên giao diện.
Vị trí log chính của Database phân tán (ví dụ PostgreSQL) và Kernel:
tail -f /var/log/postgresql/postgresql-14-main.log | grep -i "encrypt\|decrypt\|key"
Để xem log Kernel liên quan đến I/O và mạng (quan trọng cho Distributed DB):
dmesg | grep -i "timeout\|error\|io\|network"
Kịch bản phân tích: Giả sử bạn gặp lỗi "Replication lag" hoặc "Write failed". Hãy kiểm tra log đồng bộ (synchronization log).
grep "wal_send\|replication" /var/log/postgresql/postgresql-14-main.log | tail -50
Nội dung log điển hình cho sự cố mã hóa:
- "FATAL: encryption key not found": Khóa đã bị xóa hoặc chưa được load vào memory.
- "ERROR: checksum verification failed": Dữ liệu bị hỏng hoặc khóa sai (mã hóa bằng khóa A, giải mã bằng khóa B).
- "WARNING: high latency in key rotation": Quá trình xoay vòng khóa gây tắc nghẽn.
Để phân tích sâu hơn về hiệu năng I/O khi xảy ra lỗi:
iostat -x 1 10
Kết quả mong đợi: Nếu thấy %util của disk gần 100% và await cao, vấn đề nằm ở phần cứng hoặc I/O bottleneck do overhead mã hóa quá lớn, không phải lỗi logic.
Verify phân tích sự cố
Để xác nhận nguyên nhân, hãy tạo một lỗi giả lập và xem log phản hồi.
echo "FATAL: test encryption error" >> /var/log/postgresql/postgresql-14-main.log
Rồi chạy lại lệnh grep ở trên.
grep "test encryption error" /var/log/postgresql/postgresql-14-main.log
Kết quả: Dòng log xuất hiện ngay lập tức. Điều này chứng minh pipeline log đang hoạt động và bạn có thể tin tưởng vào các cảnh báo thực tế.
Tối ưu hóa tham số Kernel và giám sát an toàn nâng cao
Dựa trên kết quả benchmark và log, chúng ta sẽ tinh chỉnh các tham số Kernel để cân bằng giữa bảo mật và hiệu năng, đồng thời thiết lập giám sát an toàn (Security Monitoring).
Tại sao: Các tham số mặc định của Linux thường không tối ưu cho workload Database phân tán có mã hóa. Việc điều chỉnh vm.swappiness, net.core.somaxconn và kernel.shmmax có thể cải thiện đáng kể Throughput.
Chỉnh sửa file /etc/sysctl.conf để áp dụng các tối ưu hóa sau:
cat > /etc/sysctl.d/99-distributed-db-tuning.conf
Áp dụng các thay đổi ngay lập tức:
sysctl --system
Kết quả mong đợi: Lệnh chạy thành công, không báo lỗi. Hệ thống đã áp dụng các tham số mới. Cần khởi động lại dịch vụ Database để nhận các thay đổi về shared memory.
Thiết lập giám sát an toàn bằng auditd để theo dõi các truy cập trái phép vào file khóa hoặc thư mục dữ liệu.
auditctl -w /var/lib/secret_manager/keys -p war -k secret_key_access
Lệnh này ghi lại mọi thao tác Write (w) trên thư mục chứa khóa. Để xem log audit:
ausearch -k secret_key_access -i
Kết quả mong đợi: Khi có ai đó cố gắng ghi đè vào file khóa, bạn sẽ thấy log audit hiển thị type=SYSCALL, exe="/bin/bash" hoặc exe="/usr/bin/vim", giúp truy vết hành vi tấn công.
Verify tối ưu hóa và giám sát
Kiểm tra lại hiệu năng sau khi áp dụng sysctl:
sysctl vm.swappiness net.core.rmem_max
Kết quả: Trả về giá trị vm.swappiness = 1 và net.core.rmem_max = 26214400.
Kiểm tra auditd đang chạy và có log:
systemctl status auditd && ausearch -k secret_key_access -i
Kết quả: Dịch vụ active (running) và nếu bạn vừa truy cập thư mục keys, log sẽ hiển thị record mới nhất.
Điều hướng series:
Mục lục: Series: Triển khai Database phân tán với Secret Sharing và Linux Kernel Hardening
« Phần 5: Cài đặt và cấu hình Database phân tán (Distributed DB) với TDE