Checklist bảo mật WordPress trước khi go-live

Checklist bảo mật WordPress trước khi go-live giúp đội dự án kiểm tra các control quan trọng trước khi website bắt đầu nhận traffic thật. Mục tiêu không phải đạt một “điểm bảo mật” tuyệt đối, mà là loại các lỗi cấu hình dễ tránh, xác nhận đường phục hồi và biết rõ ai chịu trách nhiệm nếu có sự cố sau launch.

Checklist chuẩn bị WordPress trước go-live

1. Khóa phạm vi trước go-live

Ghi production URL, hosting, DNS/CDN, repository, owner kỹ thuật, account Administrator, plugin/theme chính, integration và thời điểm dự kiến launch. Không chạy checklist trên staging rồi mặc định production giống hệt.

2. Account và quyền

Xóa hoặc khóa account test không còn cần thiết.
Mỗi privileged account có owner rõ.
Không dùng chung một Administrator cho nhiều người.
Role/capability theo nhu cầu công việc.
MFA/2FA cho account quan trọng nếu hệ thống hỗ trợ.
Recovery method đã được kiểm tra.

Tham khảo least privilege WordPress và MFA/2FA WordPress.

3. Core, plugin và theme

WordPress core ở version được hỗ trợ phù hợp.
Plugin/theme có source và owner.
Xóa component không dùng.
Không dùng plugin/theme nulled hoặc nguồn không xác minh.
Đã review update pending và dependency.
Có rollback trước update quan trọng.

4. Production không để debug artifact

Kiểm tra debug configuration, log path và khả năng public access. Không để error/debug output làm lộ filesystem path, query, token hoặc dữ liệu nhạy cảm. Nếu cần logging production, log phải có retention và quyền truy cập phù hợp. Xem bảo mật debug log WordPress.

5. Secret và wp-config.php

Không để credential production trong tài liệu công khai, repository không phù hợp hoặc staging copy. Review database credential, API key, salts/secrets và quyền đọc file cấu hình theo hosting model. Rotation chỉ thực hiện khi có owner và biết tác động tới session/integration.

6. HTTPS/TLS và URL production

Production URL dùng HTTPS.
Certificate hợp lệ cho hostname cần phục vụ.
HTTP redirect sang HTTPS đúng route.
Không có mixed-content quan trọng.
Callback/webhook/API URL đã chuyển sang production endpoint.

Xem HTTPS/TLS WordPress an toàn.

Review các header phù hợp như HSTS, CSP, X-Content-Type-Options và chính sách framing theo ứng dụng. Cookie nhạy cảm cần thuộc tính Secure/HttpOnly/SameSite phù hợp với flow đăng nhập và integration. Không copy một CSP quá chặt từ website khác rồi deploy thẳng production.

8. REST API, XML-RPC và upload

Không tắt REST API hoặc XML-RPC chỉ vì checklist chung. Xác định integration nào đang phụ thuộc, sau đó giới hạn theo nhu cầu thực tế. Với upload, kiểm tra MIME/type validation, quyền user và nơi lưu file. Xem REST API security và file upload security.

9. Backup và restore

Backup production hoặc pre-launch snapshot tồn tại.
Biết backup gồm database/file nào.
Backup không chỉ nằm cùng một failure domain với production.
Đã test restore hoặc ít nhất có restore procedure được xác minh.
Owner biết RPO/RTO kỳ vọng của dự án.

10. DNS, domain và email

Xác minh registrar/DNS owner, MFA, nameserver, A/CNAME, MX/TXT và renewal. Nếu website gửi email, kiểm tra sender/domain authentication theo mail provider. Không sửa DNS hàng loạt ngay trước launch nếu chưa có rollback và baseline.

11. Monitoring và audit

Ít nhất cần biết ai nhận alert cho uptime, login anomaly, privileged change và các tín hiệu security quan trọng. Nếu có WAF/CDN, xác nhận log/event có thể truy xuất. Monitoring không có owner chỉ tạo thêm noise.

12. Smoke test sau launch

Mở homepage và route quan trọng qua HTTPS.
Test login/logout bằng account kiểm thử phù hợp.
Test form, checkout hoặc flow kinh doanh chính.
Test email/webhook/API cần thiết.
Kiểm tra browser console/network cho lỗi nghiêm trọng.
Xác minh backup/monitoring vẫn chạy sau chuyển production.

Go/No-Go, evidence và theo dõi sau launch

Evidence pack trước khi bấm Go-Live

Checklist có giá trị hơn khi mỗi mục quan trọng có bằng chứng thay vì chỉ đánh dấu checkbox. Một evidence pack tối thiểu có thể gồm snapshot user/role, inventory plugin/theme/version, kết quả smoke test HTTPS, thời điểm backup gần nhất, kết quả restore test gần nhất, danh sách integration production và người nhận alert. Không đưa secret thật vào evidence pack.

Risk acceptance: khi nào được phép launch dù còn finding?

Không phải finding nào cũng buộc trì hoãn launch. Với finding không critical, cần ghi rõ impact, likelihood, owner, mitigation tạm thời, deadline remediation và người chấp nhận rủi ro. Việc “biết có lỗi nhưng vẫn launch” chỉ có thể kiểm soát khi quyết định đó được ghi nhận và có thời hạn xử lý.

Go/No-Go gate

Điều kiện	Quyết định
Không có backup/rollback	NO-GO
Privileged account không rõ owner	NO-GO
Secret production bị lộ	NO-GO cho đến khi xử lý
HTTPS hoặc flow kinh doanh chính lỗi	NO-GO
Minor issue có owner và workaround	Đánh giá theo risk acceptance

24 giờ đầu sau launch cần quan sát gì?

Availability và lỗi 5xx trên route quan trọng.
Failed/successful login bất thường.
Admin, role, plugin/theme hoặc configuration change ngoài kế hoạch.
Webhook, email và API integration thất bại.
WAF/access-log spike khác baseline.
Backup job đầu tiên sau launch.

Nếu có anomaly, giữ timeline deployment để phân biệt lỗi release với security event. Không tự động coi mọi spike sau launch là attack.

Rollback trigger nên được định nghĩa trước

Đừng chờ sự cố mới tranh luận khi nào rollback. Trước launch nên thống nhất trigger như flow kinh doanh chính hỏng, authentication lỗi diện rộng, dữ liệu ghi sai hoặc security control quan trọng không hoạt động. Rollback trigger phải gắn với người có quyền quyết định và snapshot có thể phục hồi.

Nguồn kỹ thuật

Kết luận

Checklist go-live tốt phải kết thúc bằng bằng chứng: account đã review, component có owner, secret không lộ, HTTPS hoạt động, backup có đường restore, monitoring có người nhận và smoke test PASS. Sau launch, 24 giờ đầu cần được coi là một cửa sổ validation có chủ đích chứ không phải thời điểm “xong dự án”.