Website có cổng web công khai là tài sản Internet-facing: người dùng hợp lệ có thể truy cập từ Internet, nhưng bot, scanner và kẻ tấn công cũng có thể thử truy cập liên tục. Checklist bảo mật vì vậy cần bao phủ tài khoản, ứng dụng, API, hạ tầng, log, backup và khả năng ứng cứu — không chỉ cài SSL hoặc một plugin bảo mật.
Tóm tắt nhanh
- Lập inventory domain, subdomain, login, API và dịch vụ đang public.
- Bật MFA và least privilege cho tài khoản quản trị.
- Quản lý bản vá, dependency và secret.
- Kiểm tra authentication, authorization, session, input, upload và API.
- Dùng WAF/rate limit/DDoS protection theo threat model, không xem chúng là thay thế cho sửa code.
- Giám sát log, kiểm thử backup và có incident response rõ.
Lưu ý: checklist này là tài liệu tham khảo để tổ chức công việc, không phải chứng nhận tuân thủ, pentest report hoặc kết luận hệ thống “an toàn”. Mức kiểm soát cần chọn theo dữ liệu, chức năng, mức ảnh hưởng và yêu cầu pháp lý/hợp đồng của từng hệ thống.
1. Lập inventory tài sản Internet-facing
- Domain/subdomain nào đang trỏ tới hệ thống?
- Trang login/admin nào có thể truy cập từ Internet?
- API, webhook, upload endpoint và form nào public?
- CMS, framework, plugin, theme và dịch vụ bên thứ ba nào đang chạy?
- Dữ liệu nào được xử lý: public, account data, hồ sơ, payment-related hay dữ liệu nhạy cảm?
- Ai là người phụ trách vận hành và người có quyền thay đổi production?
Không thể bảo vệ tốt tài sản mà doanh nghiệp không biết đang tồn tại. Inventory nên được cập nhật khi launch domain mới, thêm integration hoặc thay đổi hạ tầng.
2. Khóa tài khoản và quyền quản trị
- Bật MFA cho domain/DNS, cloud/hosting, CMS, email recovery và tài khoản deploy quan trọng.
- Không dùng chung admin account cho nhiều người.
- Xóa/khóa tài khoản nhân sự hoặc agency đã rời dự án.
- Dùng least privilege; tách tài khoản vận hành hàng ngày khỏi quyền admin khi có thể.
- Dùng password manager và credential duy nhất.
- Review API keys, SSH/SFTP keys, token và secret định kỳ.
Nếu dùng WordPress, xem thêm checklist bảo mật WordPress và MFA là gì.
3. Quản lý bản vá và dependency
- CMS/framework/plugin/theme còn được nhà cung cấp hỗ trợ.
- Patch được đánh giá theo mức nghiêm trọng và exposure, không chỉ theo lịch cố định.
- Có backup/snapshot và phương án rollback trước thay đổi quan trọng.
- Staging hoặc pilot được dùng khi update có rủi ro cao.
- Dependency không dùng được gỡ bỏ; secret không commit vào repository.
- Sau update phải kiểm tra login, form, API, checkout và chức năng trọng yếu.
4. Kiểm tra security control của ứng dụng
OWASP Top 10 là tài liệu awareness về các nhóm rủi ro ứng dụng web phổ biến; WSTG cung cấp hướng dẫn kiểm thử chi tiết hơn; ASVS cung cấp yêu cầu để thiết kế và xác minh security controls. Không nên dùng riêng Top 10 như một checklist “đạt/không đạt” cho toàn bộ hệ thống.
| Nhóm | Câu hỏi kiểm tra | Bằng chứng |
|---|---|---|
| Authentication | MFA/admin, brute-force protection, reset flow có an toàn? | Cấu hình, test case, log. |
| Authorization | User A có đọc/sửa dữ liệu của user B bằng cách đổi ID không? | Role matrix và test theo vai trò. |
| Session | Token hết hạn, logout và rotation hoạt động đúng? | Session policy + test. |
| Input/output | Input được validate/encode phù hợp? | Code review, automated + manual test. |
| File upload | Type, size, storage, execution và access được kiểm soát? | Upload policy + test. |
| Error handling | Có lộ stack trace, path, secret hoặc version không? | 4xx/5xx test. |
| API | Authn/authz, rate limit, object-level access và logging rõ? | API inventory + test cases. |
Lỗi authorization/business logic thường cần kiểm thử theo tình huống thật; scanner tự động không đủ để chứng minh hệ thống không có lỗi.
5. WAF, rate limit và DDoS protection
WAF có thể giảm một số request độc hại và cung cấp telemetry; rate limit giúp hạn chế brute force hoặc API abuse; DDoS protection giúp tăng khả năng chịu tải trước traffic bất thường. Nhưng các lớp này không thay thế sửa lỗi authorization, business logic hoặc code.
- Thiết kế rate limit riêng cho login, reset password, API và form nhạy cảm.
- Bắt đầu WAF rule ở chế độ log/monitor khi có nguy cơ false positive, rồi mới tăng enforcement.
- Theo dõi 403/429/5xx và latency sau thay đổi rule.
- Không whitelist IP quá rộng hoặc để bypass tồn tại không có người quản lý.
- Kiểm tra origin không bị bypass nếu kiến trúc yêu cầu chỉ đi qua CDN/WAF.
Với website có login/API hoặc yêu cầu availability cao, xem thêm WAF là gì.
6. Logging, monitoring và alerting
- Log login thành công/thất bại và thay đổi quyền quan trọng.
- Log lỗi ứng dụng và security event nhưng không ghi secret/password/token ở dạng rõ.
- Đồng bộ thời gian và giữ context đủ để điều tra.
- Cảnh báo uptime, 5xx, login anomaly, traffic spike và WAF/rate-limit anomaly.
- Phân quyền log và đặt retention theo nhu cầu điều tra/compliance.
7. Backup và khả năng khôi phục
Backup chỉ có giá trị khi có thể khôi phục. Tần suất phụ thuộc RPO/RTO và tốc độ thay đổi dữ liệu, không nên dùng một lịch chung cho mọi hệ thống.
- Có bản sao tách khỏi server chính khi phù hợp.
- Mã hóa và kiểm soát quyền truy cập backup.
- Thử restore định kỳ và ghi kết quả.
- Xác định thứ tự khôi phục database, file, config, DNS/CDN và integration.
- Không ghi đè bằng backup chưa xác minh nếu đang điều tra incident.
8. Incident response: khi đã có dấu hiệu bị tấn công
Nếu xuất hiện admin lạ, redirect bất thường, malware warning, file bị chèn, dữ liệu bị truy cập trái phép hoặc traffic attack, hãy chuyển từ “hardening” sang incident response: xác định phạm vi, bảo toàn bằng chứng, cô lập khi cần, khóa credential, xử lý nguyên nhân và xác minh trước khi đưa hệ thống trở lại bình thường.
Xem làm gì khi website bị hack hoặc tấn công. Không xóa log hoặc “clean malware” vội nếu việc đó làm mất bằng chứng cần cho điều tra.
9. Khi nào cần rà soát ATTT theo cấp độ?
Nếu hệ thống thuộc phạm vi yêu cầu an toàn hệ thống thông tin theo cấp độ hoặc có yêu cầu từ cơ quan quản lý/hợp đồng, cần đối chiếu văn bản pháp luật hiện hành và hồ sơ hệ thống cụ thể. Checklist web security này không thay thế hồ sơ xác định cấp độ, thẩm định hoặc phê duyệt.
Có thể bắt đầu từ hướng dẫn xác định cấp độ ATTT và checklist ATTT cấp độ 2, sau đó xác minh yêu cầu pháp lý với đơn vị chuyên môn phù hợp.
Checklist trước khi launch hoặc thay đổi lớn
- Inventory Internet-facing đã cập nhật.
- MFA/least privilege đã bật cho tài khoản trọng yếu.
- Patch/dependency/secret đã kiểm tra.
- Authentication, authorization, session, upload và API đã test.
- WAF/rate-limit/DDoS controls đã kiểm tra nếu threat model yêu cầu.
- Logging và alerting hoạt động.
- Backup gần nhất đã xác minh và có restore plan.
- Incident contact/escalation đã rõ.
- Security findings có severity, evidence, owner xử lý và retest.
Nguồn kỹ thuật chính thức
- OWASP Top 10:2025 — tài liệu awareness về nhóm rủi ro web application.
- OWASP Web Security Testing Guide (WSTG) — khung và hướng dẫn kiểm thử web application.
- OWASP Application Security Verification Standard (ASVS) — yêu cầu xác minh security controls.
- OWASP API Security Project — tài liệu rủi ro và kiểm soát cho API.
Kết luận
Bảo mật website có cổng web công khai là hoạt động liên tục: biết tài sản đang mở, khóa identity, quản lý dependency, kiểm tra application controls, bảo vệ edge, theo dõi log và chứng minh khả năng khôi phục. Checklist giúp tổ chức công việc; mức bảo vệ thực tế phải dựa trên threat model, dữ liệu và tác động của từng hệ thống.
Đ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ả.
