Bảo mật database WordPress không bắt đầu bằng việc đổi table prefix. Những control có giá trị hơn là quản lý database credential, quyền của DB user, network exposure, backup/restore integrity, change control và monitoring. Mục tiêu là giảm blast radius nếu application hoặc credential bị compromise, đồng thời vẫn giữ được khả năng update và recovery hợp lệ.
Một cấu hình “chặt” nhưng làm plugin/theme update lỗi, schema migration thất bại hoặc restore không hoạt động không phải hardening tốt. Database security phải bám theo workload thật và có validation/rollback.
Database Security Control Matrix
| Control | Mục tiêu | Evidence cần xem | PASS | FAIL |
|---|---|---|---|---|
| Credential | Không dùng secret chia sẻ/rộng hơn cần thiết | wp-config.php, secret store, account inventory |
Credential riêng, owner và rotation path rõ | Shared/root-like credential hoặc secret xuất hiện trong repo/log |
| Privilege | Least privilege phù hợp workload | GRANT/role output + update process | Không có quyền thừa không owner | Global/admin privilege không cần thiết |
| Network exposure | DB chỉ nhận kết nối từ nguồn cần thiết | Bind/firewall/security group | Scope hẹp, có owner | Public exposure không có lý do |
| Backup | Có recovery path độc lập | Backup job + restore test | Backup tồn tại và restore được | Chỉ có file backup chưa kiểm thử |
| Logging/monitoring | Có evidence khi điều tra | Auth/error/audit log nếu khả dụng | Retention và owner rõ | Không biết log ở đâu/giữ bao lâu |
| Change control | Schema/config change có nguồn gốc | Deploy/change history | Change có owner + rollback | Schema thay đổi không rõ nguồn |
1. Khóa owner và lifecycle của database credential
DB name, user, password và host thường được WordPress đọc từ wp-config.php hoặc từ cơ chế secret injection của môi trường. Trước khi hardening, cần biết credential do ai tạo, ứng dụng nào dùng, có reuse ở site khác không và rotation sẽ ảnh hưởng service nào.
Credential không nên xuất hiện trong source repo, ticket, chat hoặc log. Nếu nghi lộ secret, rotation phải đi cùng validation kết nối và rollback plan; đổi password mà không biết dependency có thể gây outage. Xem thêm bảo vệ wp-config.php, salts và secrets.
2. Least privilege phải theo workload và maintenance process
Không nên áp một tập quyền “chuẩn” cho mọi WordPress. Runtime đọc/ghi dữ liệu khác với schema migration khi update core/plugin/theme. Nếu thu hồi quyền cấu trúc quá mạnh, update hợp lệ có thể thất bại; nếu cấp quyền quá rộng vĩnh viễn, blast radius khi application bị compromise sẽ lớn hơn.
Privilege decision record
| Nhu cầu | Quyền cần xem xét | Câu hỏi validation |
|---|---|---|
| Runtime normal | Đọc/ghi dữ liệu cần cho workload | Ứng dụng có cần quyền vượt quá CRUD không? |
| Plugin/theme update | Có thể cần schema change | Có maintenance window và rollback không? |
| Migration/import | Tùy công cụ | Quyền có thể cấp tạm thời rồi thu hồi không? |
| Administrative DBA | Quyền cao | Có tách khỏi credential ứng dụng và audit access không? |
Nguyên tắc là tách application identity khỏi administrative identity khi hạ tầng cho phép, và không để quyền cao tồn tại lâu chỉ vì “đỡ lỗi update”.
3. Network exposure: giảm trust boundary
Database nên chỉ lắng nghe trên interface/network cần thiết cho application hoặc quản trị. Với managed database, private network, security group/firewall và TLS giữa app–DB có thể là control phù hợp; với shared hosting, khả năng cấu hình sẽ khác.
FAIL nghiêm trọng nếu DB public ra Internet mà không có business requirement và control bù phù hợp. Nhưng cũng không nên thay bind/firewall mù quáng trên production khi chưa biết application route và management path.
4. Table prefix chỉ là chi tiết phụ
Đổi wp_ có thể làm một số automation kém chính xác hơn, nhưng không sửa SQL injection, credential compromise, privilege abuse hay malicious query từ application đã bị chiếm quyền. Không nên chấm một database “an toàn” chỉ vì prefix khác mặc định.
5. Backup database phải được bảo vệ như production data
Database backup có thể chứa user account, order, form lead, settings, token và dữ liệu nhạy cảm. Vì vậy cần kiểm soát access, retention, encryption theo hạ tầng, location và lifecycle. Nhưng backup chỉ thực sự có giá trị recovery khi restore được.
Đối chiếu với backup WordPress và restore integrity. Nếu restore test chưa từng chạy, trạng thái đúng là UNKNOWN, không phải PASS.
6. Restore Verification Matrix
| Kiểm tra | PASS | FAIL |
|---|---|---|
| Backup readable | File/object truy cập được theo quyền dự kiến | Backup corrupt/missing/permission sai |
| Database import | Import hoàn tất trên môi trường kiểm soát | Schema/data import lỗi |
| Application boot | WordPress kết nối DB và route chính hoạt động | Connection/schema/runtime error |
| Data integrity | Record quan trọng khớp kỳ vọng | Thiếu/sai dữ liệu cần recovery |
| Credential isolation | Restore test không làm lộ secret production | Secret bị copy/phơi bày ngoài scope |
7. Monitoring: đừng chỉ nhìn query volume
Tùy hạ tầng, có thể theo dõi authentication failure, connection anomaly, database error, replication/availability, storage growth và query/audit event. Không phải managed DB nào cũng cung cấp cùng mức logging, và không nên bật logging nặng gây performance impact chỉ để “có log”.
Trong incident, database evidence phải được thu theo hypothesis. Nếu nghi spam/malware trong DB, đừng search-replace mù; xem workflow kiểm tra database WordPress mã độc/spam.
8. Database Security Review Record mẫu
Đây là worksheet để điền bằng evidence thật; không chứa username/password/host nội bộ thật.
review_id: DBSEC-YYYY-NNN
asset: wordpress-production
owner: ...
db_platform: mysql|mariadb|managed
credential:
owner_known: yes|no
reused_elsewhere: yes|no|unknown
exposure_found: yes|no
rotation_tested: yes|no
privilege:
runtime_review: PASS|FAIL|UNKNOWN
admin_identity_separate: yes|no|n-a
schema_change_process: ...
network:
public_exposure: yes|no
allowed_sources: ...
backup:
latest_backup_ref: ...
restore_test: PASS|FAIL|UNKNOWN
monitoring:
auth_log: available|unavailable|unknown
error_log: available|unavailable|unknown
retention: ...
open_actions:
- owner: ...
due: ...
evidence_ref: ...
rollback_ref: ...
Checklist triển khai thay đổi an toàn
- Snapshot current DB config, privilege và network rule.
- Xác định application/administrative identity và dependency.
- Backup trước thay đổi có khả năng ảnh hưởng schema/connectivity.
- Thực hiện một thay đổi tại một thời điểm.
- Smoke test frontend, admin, login, write path và background job cần thiết.
- Nếu thay privilege, chạy maintenance/update scenario phù hợp.
- Nếu thay network/credential, verify reconnect/restart behavior.
- Ghi evidence và rollback về state trước nếu validation fail.
PASS/FAIL cho database security
- PASS: credential có owner và rotation path; privilege phù hợp workload; network exposure tối thiểu; backup restore PASS; change có rollback; monitoring/evidence path đủ rõ.
- FAIL: application dùng credential quyền cao không lý do, DB public không owner, secret bị lộ, backup chưa restore được hoặc schema/privilege change không có rollback.
- UNKNOWN: không biết owner, grant, exposure hoặc restore state. UNKNOWN phải được điều tra trước khi coi control là đạt.
Nguồn kỹ thuật
Kết luận
Bảo mật database WordPress nên được đánh giá theo credential → privilege → network → backup/restore → monitoring → change control. Table prefix chỉ là chi tiết phụ. Một database được harden tốt phải vừa giảm blast radius, vừa giữ được update/recovery hợp lệ và có bằng chứng để rollback khi thay đổi gây lỗi.