WordPress có thể được vận hành an toàn hơn khi doanh nghiệp quản lý đúng tài khoản, cập nhật, backup, quyền, log và quy trình thay đổi. Một plugin bảo mật đơn lẻ không thay thế được các lớp kiểm soát này.
Tóm tắt: Checklist dưới đây gồm 15 nhóm kiểm soát: quyền sở hữu tài khoản, admin, 2FA, mật khẩu và application password, cập nhật, plugin/theme, staging, backup, HTTPS, file/config, WAF/rate limit, logging, malware monitoring, kiểm thử hành trình và incident response. Mức ưu tiên phải dựa trên vai trò kinh doanh và rủi ro của website, không phải số plugin đã cài.
1. Doanh nghiệp có giữ quyền kiểm soát các tài khoản chính?
Trước khi nói tới hardening, hãy xác nhận doanh nghiệp có quyền owner/admin với domain, DNS, hosting, CDN, WordPress, analytics và các tài khoản phục hồi. Nếu agency hoặc một cá nhân là người duy nhất giữ quyền, đó là rủi ro vận hành.
Dùng checklist quyền kiểm soát website để rà owner, admin, license và cách bàn giao.
2. Số tài khoản Administrator có được giới hạn?
Administrator có thể cài plugin, chỉnh cấu hình và thay đổi nội dung quan trọng. Chỉ cấp quyền này cho người thực sự cần; dùng tài khoản riêng thay vì chia sẻ một tài khoản chung, và thu hồi quyền khi vai trò thay đổi.
Nếu tổ chức có nhiều vai trò, nên áp dụng nguyên tắc least privilege và RBAC để chuẩn hóa phân quyền.
3. 2FA/MFA đã bật cho tài khoản đặc quyền?
WordPress core không cung cấp 2FA mặc định; doanh nghiệp có thể triển khai qua plugin uy tín hoặc hệ thống SSO/identity provider. Ưu tiên admin, editor quan trọng và các tài khoản hosting/DNS/email có khả năng khôi phục website.
Xem thêm MFA là gì và cách áp dụng.
4. Mật khẩu và Application Password có được quản lý riêng?
- Mật khẩu người dùng phải mạnh và không tái sử dụng.
- Không gửi credential qua chat/tài liệu công khai.
- Integration nên dùng credential riêng có thể revoke thay vì chia sẻ mật khẩu đăng nhập chính.
- Application Password không còn dùng phải được thu hồi.
WordPress mô tả Application Password là credential riêng cho từng ứng dụng và có thể thu hồi độc lập; đây là lựa chọn tốt hơn việc đưa mật khẩu chính cho script hoặc integration.
5. WordPress core, theme và plugin có được cập nhật theo rủi ro?
Website cần biết phiên bản đang chạy, thành phần nào còn được duy trì và bản vá nào ảnh hưởng trực tiếp. Không trì hoãn lỗ hổng quan trọng chỉ vì chưa tới lịch bảo trì định kỳ; cũng không nên bấm Update All trên production mà không có backup và kiểm thử.
Quy trình cập nhật nên đi qua quản lý vòng đời WordPress, theme và PHP.
6. Plugin/theme không dùng hoặc ngừng cập nhật đã được xử lý?
Thành phần không còn sử dụng vẫn tạo thêm bề mặt quản trị nếu tiếp tục tồn tại. Gỡ bỏ sau khi xác minh dependency và backup. Với plugin ngừng cập nhật, cần quyết định giữ, thay thế hay loại bỏ dựa trên chức năng, dữ liệu và khả năng tương thích.
Xem plugin WordPress ngừng cập nhật: khi nào giữ, thay hoặc gỡ.
7. Có staging cho thay đổi rủi ro cao?
Website có checkout, form tạo lead, membership hoặc custom code nên kiểm thử thay đổi quan trọng trên môi trường tách biệt. Staging không phải bản backup và cũng cần được bảo vệ khỏi index, credential dùng lại hoặc truy cập công khai ngoài ý muốn.
Xem Staging WordPress và quy trình test trước production.
8. Backup có thể thực sự restore?
- Backup file và database theo RPO.
- Giữ ít nhất một bản tách khỏi production.
- Kiểm soát quyền xóa/restore.
- Test restore định kỳ trên môi trường phù hợp.
- Biết RTO kỳ vọng khi có sự cố.
Chi tiết tại backup website, RPO/RTO và kiểm tra khôi phục.
9. HTTPS và khu vực quản trị có được bảo vệ đúng?
Admin và login phải đi qua HTTPS. Certificate, redirect và proxy/CDN cần được cấu hình nhất quán để tránh gửi credential hoặc cookie qua kết nối không an toàn.
10. File, cấu hình và secret có được giới hạn quyền?
- Không để file backup, dump database hoặc log nhạy cảm public.
- Không để secret trong repository công khai.
- Giới hạn quyền ghi theo nhu cầu thực tế.
- Không bật debug output có thông tin nhạy cảm trên production.
- Rà thay đổi bất thường ở wp-config.php, .htaccess/nginx config, cron và thư mục upload.
11. Website có cần WAF, rate limit hoặc bot protection?
Website public có login, form, API hoặc traffic lớn nên đánh giá WAF/rate limit như một lớp giảm rủi ro. WAF không thay thế sửa code hoặc phân quyền, nhưng có thể giúp lọc request, rate limit và tạo log trước khi traffic đến ứng dụng.
Xem WAF là gì và khi nào nên triển khai.
12. Login, role, file và sự kiện bất thường có được logging?
Log cần đủ để trả lời ai làm gì, lúc nào và từ đâu. Ưu tiên failed login, admin mới, role/permission thay đổi, update/plugin install, thay đổi file quan trọng và các lỗi ứng dụng liên quan. Log phải có người xem và có thời gian lưu phù hợp.
13. Security monitoring và malware detection có owner?
Scanner không phải bằng chứng website sạch tuyệt đối. Doanh nghiệp cần kết hợp file integrity, account changes, log, WAF/hosting alert, malware scan và baseline để phát hiện bất thường; cảnh báo quan trọng phải có người nhận và runbook xử lý.
Xem Website Security Monitoring.
14. Sau mỗi thay đổi có kiểm thử hành trình thật?
Trang chủ mở được không chứng minh form, checkout, SMTP hoặc API vẫn chạy. Sau update/hardening/WAF tuning, cần test đúng hành trình kinh doanh quan trọng và theo dõi lỗi sau release.
15. Có runbook khi nghi website bị xâm nhập?
Khi xuất hiện redirect lạ, admin không rõ nguồn gốc, file PHP trong upload, nội dung bị chèn hoặc cảnh báo malware, không nên chỉ xóa file rồi tiếp tục. Cần cô lập phù hợp, bảo toàn log, xác định phạm vi, khôi phục từ nguồn tin cậy và vá nguyên nhân.
Dùng quy trình xử lý website bị hack từ cô lập đến phục hồi khi có dấu hiệu compromise.
Bảng ưu tiên nhanh
| Ưu tiên | Hạng mục |
|---|---|
| P1 | Admin/MFA, lỗ hổng đang bị khai thác, backup không dùng được, dấu hiệu compromise |
| P2 | Plugin/theme lỗi thời, quyền thừa, log/monitoring thiếu, staging/rollback yếu |
| P3 | Hardening bổ sung, tuning WAF, tối ưu quy trình và tài liệu |
Kết luận
Checklist bảo mật WordPress tốt không đo bằng số plugin. Nó đo bằng việc doanh nghiệp biết ai có quyền, thành phần nào đang chạy, backup có phục hồi được không, cảnh báo nào được theo dõi và phải làm gì khi có sự cố. Để xem toàn bộ lớp kiểm soát ở cấp doanh nghiệp, đọc bảo mật website doanh nghiệp gồm những gì.
Khi cần biến checklist thành phạm vi bảo mật có owner
Bài này tiếp tục sở hữu intent checklist bảo mật WordPress. Nếu doanh nghiệp cần người phụ trách baseline, access, hardening, vulnerability, monitoring, recovery readiness và incident path thay vì chỉ tự rà checklist, xem dịch vụ bảo mật website / WordPress.
Nguồn tham khảo
- WordPress Developer Resources – Hardening WordPress
- WordPress – Application Passwords
- OWASP Top 10:2025
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
