Checklist rà soát và duy trì Website Hardening định kỳ

Website Hardening không phải công việc làm một lần. Tài khoản thay đổi, plugin/theme được cập nhật, certificate gia hạn, firewall rule bị sửa, backup path dịch chuyển và third-party integration thay đổi theo thời gian. Nếu không review định kỳ, một cấu hình từng an toàn có thể dần lệch khỏi baseline.

Checklist này tập trung vào maintenance và configuration drift, khác với checklist trước triển khai thay đổi.

Mục tiêu của hardening review định kỳ

phát hiện asset hoặc account không còn owner;
phát hiện component hết support;
phát hiện permission hoặc firewall drift;
phát hiện backup/log/temp file bị expose;
kiểm recovery evidence còn mới;
kiểm monitoring/alert vẫn hoạt động;
xác nhận security control không bị disable sau update.

Checklist hàng tuần

1. Security alerts và authentication

Review failed login bất thường.
Review privileged login ngoài giờ hoặc location bất thường.
Kiểm account mới được tạo.
Kiểm MFA failure/recovery event nếu có.

2. Update và vulnerability exposure

Kiểm core/framework, plugin/module, theme/library có bản vá security mới.
Ưu tiên component đang exposed ra Internet hoặc có exploit path thực tế.
Không auto-update mù nếu component business-critical; cần validation sau update.

3. File và malware signal

Review file mới/sửa trong executable path.
Kiểm archive, database dump hoặc config backup xuất hiện trong webroot.
Review file extension lạ trong upload directory.

Checklist hàng tháng

4. Account và permission review

Vô hiệu hóa account không còn owner.
Review administrator/editor/service account.
Kiểm database user, SSH key, API token và deployment credential.
Thu hẹp quyền nếu business need đã thay đổi.

5. Component inventory

Plugin/theme/module nào không còn dùng?
Component nào đã EOL?
Dependency nào được cài tạm nhưng chưa gỡ?
Staging/debug tool nào vô tình còn trên production?

6. Security headers và TLS

Kiểm certificate expiry và renewal status.
Kiểm TLS endpoint sau CDN/load balancer change.
Kiểm HSTS/CSP/Referrer-Policy/X-Content-Type-Options trên response thực tế.
Review CSP violation sau update frontend.

Với TLS point-in-time assessment, xem SSL Labs Grade.

7. Backup và recovery

Backup job có chạy đúng cadence không?
Offsite/offline copy còn truy cập được không?
Credential/key để restore còn hợp lệ không?
Restore test gần nhất khi nào?
Backup có chứa compromise cũ hoặc dữ liệu không cần giữ không?

Đừng chỉ kiểm dashboard xanh. Xem Backup Recoverability.

8. Log và file tạm

Retention có đúng policy?
Log có ghi secret/PII quá mức không?
Debug log có bị public không?
Export/import temporary file đã cleanup chưa?

Tham khảo Bảo vệ file backup, log và file tạm.

Checklist hàng quý

9. Review attack surface

So sánh inventory hiện tại với quý trước:

domain/subdomain mới;
API mới;
third-party integration mới;
admin interface mới;
port/service mới;
upload path mới;
CDN/WAF/origin architecture thay đổi.

10. Firewall/WAF/CDN rules

Rule nào không còn owner?
Allowlist IP cũ còn cần không?
Temporary bypass có bị quên?
Rate limit/challenge rule có false positive kéo dài?
Origin có còn bypass được WAF không?

11. Cron và scheduled task

Event nào không rõ owner?
Event nào late hoặc fail lặp lại?
Cleanup job có hoạt động?
Backup/monitoring cron có tạo outcome thật?

Xem WP-Cron Reliability để tách scheduled, spawn, callback và business outcome.

12. Recovery exercise

Với workload quan trọng, thực hiện sample restore hoặc recovery exercise theo risk. Ghi lại:

artifact dùng;
thời gian restore;
dependency lỗi;
functional test;
trusted-state validation;
action item sau exercise.

Checklist hàng năm hoặc sau thay đổi lớn

Review toàn bộ hardening standard.
Kiểm architecture diagram và asset inventory.
Review incident lessons learned.
Rotate credential/key quan trọng theo policy.
Review vendor/third-party access.
Review business continuity và recovery owner.
Review security monitoring use cases.

Configuration drift: thứ cần tìm

Drift là khác biệt giữa baseline mong muốn và trạng thái hiện tại. Ví dụ:

admin account tăng từ 3 lên 7;
CSP bị nới rộng sau khi thêm marketing tag;
HSTS biến mất sau CDN migration;
upload directory trở lại executable;
backup được chuyển vào public path;
firewall temporary allow rule không được gỡ;
debug mode bật lại.

Nên lưu evidence gì?

Mỗi review nên để lại evidence đủ dùng:

ngày review;
scope;
owner;
finding;
severity;
action đã thực hiện;
validation;
rollback nếu có;
next review date.

Không cần log mọi chi tiết vô hạn; cần đủ để biết control được kiểm khi nào và kết quả gì.

Không nên biến checklist thành compliance theater

Tick checkbox mà không kiểm behavior thật không tạo security. Ví dụ:

“backup PASS” nhưng chưa restore;
“CSP present” nhưng policy cực rộng;
“MFA enabled” nhưng còn shared admin account;
“WAF active” nhưng origin bypass trực tiếp;
“monitoring active” nhưng không ai nhận alert.

Mỗi checkbox cần gắn với evidence phù hợp.

Mẫu cadence gợi ý

Cadence	Focus
Hàng tuần	alert, login, update, file change
Hàng tháng	account, component, TLS/header, backup, log
Hàng quý	attack surface, firewall/WAF, cron, recovery exercise
Hàng năm / sau change lớn	architecture, policy, vendor access, continuity

Cadence này là baseline gợi ý; website critical hoặc thay đổi nhanh có thể cần review thường xuyên hơn.

Kết luận

Hardening chỉ có giá trị nếu trạng thái an toàn được duy trì theo thời gian. Review định kỳ giúp phát hiện configuration drift trước khi nó trở thành incident.

Để hiểu nền tảng hardening, xem Website Hardening là gì?. Với thay đổi production, dùng Checklist trước khi triển khai thay đổi.