Một Website Security Audit có thể bị chậm hoặc giảm coverage chỉ vì khâu chuẩn bị thiếu: asset chưa rõ, account test không hoạt động, staging khác production quá nhiều, không có emergency contact hoặc tester không biết kỹ thuật nào bị cấm.
Chuẩn bị trước Website Security Audit là quá trình làm sạch đầu vào của assessment để tester biết chính xác cần kiểm tra gì, ở đâu, với quyền nào và trong giới hạn nào.
Bài này tập trung vào checklist chuẩn bị trước audit. Việc xác định phạm vi chi tiết được giải thích tại Security Audit Scope; còn tiêu chí chọn nhà cung cấp được tách riêng tại Cách chọn đơn vị Security Audit website.
Vì sao cần chuẩn bị trước Security Audit?
Preparation tốt giúp:
- giảm thời gian discovery lặp lại;
- tránh bỏ sót asset quan trọng;
- giảm rủi ro tester vượt scope;
- có account/context cần cho authenticated testing;
- giảm nguy cơ ảnh hưởng production;
- giúp evidence và finding traceable hơn;
- rút ngắn thời gian từ report đến remediation.
Preparation không phải để “dọn sạch website trước khi audit” đến mức che mất trạng thái thật. Mục tiêu là cung cấp context, không phải làm đẹp kết quả.
Checklist tổng quan trước Website Security Audit
- Xác định mục tiêu assessment.
- Lập asset inventory.
- Khóa in-scope / out-of-scope.
- Xác định environment.
- Chuẩn bị test account và role.
- Chuẩn bị architecture overview.
- Kiểm tra backup/rollback readiness.
- Thống nhất Rules of Engagement.
- Xác định data handling.
- Chuẩn bị emergency contact.
- Ghi known issue và limitation.
- Xác định remediation owner.
18 hạng mục cần chuẩn bị trước khi Audit bắt đầu
1. Xác định mục tiêu Audit trước
Đừng bắt đầu bằng câu “scan toàn bộ website”.
Cần xác định assessment đang phục vụ mục tiêu nào:
- pre-launch;
- baseline security review;
- post-migration;
- post-incident control review;
- handover vendor;
- customer assurance;
- review một application/API cụ thể.
Mục tiêu quyết định scope, methodology và mức access cần chuẩn bị.
2. Chuẩn bị Asset Inventory
Asset inventory nên đủ để tester hiểu attack surface cơ bản.
Có thể gồm:
- domain chính;
- subdomain;
- public IP;
- origin server;
- CDN/WAF;
- CMS/framework;
- plugin/theme/component;
- API;
- admin portal;
- database;
- DNS/registrar;
- backup storage;
- third-party integration.
Không nhất thiết tất cả asset đều in-scope. Nhưng việc biết chúng tồn tại giúp tránh blind spot và scope creep.
3. Khóa In-Scope và Out-of-Scope
Danh sách in-scope nên dùng định danh cụ thể.
Ví dụ:
https://example.com/– production;https://staging.example.com/– staging;https://api.example.com/v1/– API v1;- origin server cụ thể;
- WordPress admin workflow.
Out-of-scope cũng cần ghi rõ, ví dụ:
- third-party payment provider;
- corporate email;
- ERP;
- social engineering;
- DoS/load testing;
- physical security.
4. Chọn Production, Staging hay cả hai
Production phản ánh trạng thái thật nhưng có risk vận hành cao hơn. Staging an toàn hơn cho state-changing test nhưng chỉ hữu ích nếu đủ tương đồng.
Trước audit nên xác nhận:
- staging có cùng code/config quan trọng không;
- có dùng dữ liệu thật không;
- WAF/CDN có giống production không;
- authentication/role có tương đương không;
- test nào chỉ được phép trên staging.
Nếu staging khác production đáng kể, limitation phải được ghi trước.
5. Chuẩn bị Test Account theo Role
Nhiều control không thể đánh giá tốt nếu chỉ có unauthenticated access.
Tùy website, có thể cần:
- 1 account user thường;
- 1 account role khác để kiểm tra authorization;
- 1 admin test account;
- account đối tác/vendor nếu workflow có role riêng.
Nên dùng account riêng cho audit, không dùng credential cá nhân của nhân viên nếu không cần thiết.
6. Xác nhận Account hoạt động trước khi bắt đầu
Một lỗi vận hành rất phổ biến là đến ngày audit mới phát hiện:
- password hết hạn;
- MFA không provision;
- IP tester chưa allowlist;
- role bị sai;
- account staging không đồng bộ;
- captcha hoặc SSO chặn testing.
Kiểm tra account trước engagement giúp tránh mất thời gian assessment window.
7. Chuẩn bị Architecture Overview
Không cần sơ đồ hoàn hảo. Một sơ đồ đủ tốt nên thể hiện:
User → DNS/CDN/WAF → Origin → Application → Database → Third-party services
Nên bổ sung:
- authentication provider;
- admin access path;
- API/webhook;
- storage;
- backup;
- logging/monitoring;
- trust relationship quan trọng.
Architecture context giúp tester phân biệt edge response với origin behavior và hiểu boundary.
8. Chuẩn bị Component / Dependency Inventory
Với CMS hoặc application, nên có danh sách:
- CMS/framework version;
- plugin/module/theme;
- runtime như PHP/Node/Java nếu liên quan;
- web server;
- package/dependency chính;
- component custom.
Không nên cố “update tất cả” ngay trước audit chỉ để có báo cáo đẹp. Nếu update là hoạt động maintenance bình thường thì thực hiện có kiểm soát; nếu không, audit nên phản ánh trạng thái thực tế.
9. Kiểm tra Backup và Rollback Readiness
Dù Rules of Engagement giới hạn destructive testing, production assessment vẫn có thể trùng với sự cố vận hành không liên quan.
Trước audit nên biết:
- backup gần nhất ở đâu;
- backup có độc lập với server không;
- ai có quyền restore;
- rollback deployment như thế nào;
- restore đã từng được test chưa.
Không nên tuyên bố “đã có backup” nếu chưa biết khả năng recovery thực tế.
10. Xác định Rules of Engagement
RoE nên thống nhất trước khi testing bắt đầu.
Có thể gồm:
- assessment window;
- tester IP;
- request rate;
- có được tạo account/test data không;
- có được upload file không;
- có được thay đổi state không;
- có được controlled exploitation không;
- kỹ thuật bị cấm;
- stop condition;
- emergency contact.
RoE càng rõ, tester càng dễ validation mà không vượt authorization.
11. Xác định Emergency Contact
Phải có ít nhất một contact có thể phản hồi khi:
- website bất ổn;
- WAF block tester;
- phát hiện dấu hiệu compromise thật;
- finding nghiêm trọng cần escalation;
- scope cần thay đổi;
- account bị lock.
Contact nên có quyền quyết định hoặc biết ai có quyền quyết định.
12. Thống nhất Data Handling
Audit có thể chạm vào PII, token, log hoặc dữ liệu thật.
Cần thống nhất:
- evidence được lưu ở đâu;
- dữ liệu nào phải redact;
- có được chụp screenshot dữ liệu thật không;
- retention bao lâu;
- ai được nhận report/evidence;
- cleanup test data/account thế nào.
Nguyên tắc tốt là thu đủ bằng chứng để chứng minh finding nhưng không nhiều hơn mức cần thiết.
13. Chuẩn bị Known Issues và Known Constraints
Đừng giấu known issue khỏi tester.
Nên cung cấp:
- component đang chờ patch;
- legacy integration;
- staging khác production;
- planned migration;
- WAF rule tạm;
- account đặc biệt;
- known outage window.
Known issue không nên mặc định bị loại khỏi audit; nó giúp tester tránh mất thời gian rediscovery và có thể kiểm tra control/impact sâu hơn.
14. Chuẩn bị Previous Audit / Incident Context
Nếu có assessment cũ, nên cung cấp:
- finding ID;
- status;
- remediation;
- finding đã retest chưa;
- residual risk;
- systemic pattern.
Điều này giúp tester nhận diện regression và finding tái diễn.
15. Xác định Business-Critical Flow
Tester không thể biết workflow nào quan trọng nếu không được cung cấp.
Ví dụ:
- đăng nhập;
- checkout;
- upload hồ sơ;
- reset password;
- admin publish;
- API integration;
- customer data export.
Business-critical flow giúp ưu tiên manual testing và impact analysis.
16. Xác định Remediation Owner trước khi Audit
Đừng đợi report xong mới tìm người sửa.
Nên xác định owner của:
- application;
- hosting/server;
- DNS/CDN/WAF;
- CMS/plugin;
- IAM;
- backup;
- third-party integration.
Điều này giúp finding được handoff nhanh sau report.
17. Không nên “Hardening quá mức” ngay trước Audit
Nếu doanh nghiệp tạm thời bật control chỉ trong thời gian audit rồi tắt sau đó, kết quả không phản ánh trạng thái vận hành thật.
Nên:
- thực hiện maintenance bình thường;
- ghi lại change vừa diễn ra;
- không tạo environment giả chỉ để pass assessment;
- để tester biết control nào là temporary.
18. Chuẩn bị lịch làm việc và Change Freeze nếu cần
Nếu website deploy liên tục trong assessment, evidence có thể bị stale.
Có thể:
- đặt assessment window;
- thông báo major deployment;
- freeze một số change quan trọng trong testing;
- ghi version/build đang được audit.
Không nhất thiết phải freeze toàn bộ, nhưng tester cần biết khi state thay đổi.
Pre-Audit Package và kiểm tra cuối trước khi bắt đầu
Mẫu Pre-Audit Package tối thiểu
| Nhóm | Nội dung |
|---|---|
| Objective | Mục tiêu assessment |
| Assets | Domain, API, server, integration |
| Scope | In / Out |
| Environment | Production / Staging |
| Accounts | Role + access |
| Architecture | Sơ đồ và trust boundary |
| RoE | Allowed / prohibited tests |
| Contacts | Technical + emergency |
| Data | Handling/redaction requirement |
| History | Previous audit/incident/known issue |
Checklist 24 giờ trước Audit
- Test account đăng nhập được.
- MFA/allowlist đã sẵn sàng.
- Asset list không thay đổi đáng kể.
- Backup/rollback owner đã rõ.
- Emergency contact online trong window.
- Major deploy đã được thông báo.
- Tester nhận đúng tài liệu qua kênh an toàn.
- Không gửi password/token trong kênh không phù hợp.
Những lỗi chuẩn bị thường gặp
- Scope ghi “toàn bộ website” nhưng không có asset list.
- Không có out-of-scope.
- Account test không hoạt động.
- Staging khác production nhưng không nói.
- Không có emergency contact.
- Không biết origin/CDN/WAF relationship.
- Không có business flow.
- Không có remediation owner.
- Gửi secret trong email/chat không phù hợp.
- Thay đổi production giữa assessment mà không báo tester.
Kết luận
Chuẩn bị tốt giúp Website Security Audit có coverage rõ, ít gián đoạn và finding dễ hành động hơn. Các đầu vào quan trọng nhất là objective, asset inventory, scope, environment, account, architecture, Rules of Engagement, data handling, emergency contact và remediation owner.
Preparation không nhằm làm website “trông an toàn hơn” trước audit. Nó nhằm giúp assessment phản ánh trạng thái thật trong phạm vi được kiểm soát.
Nếu đang chuẩn bị engagement bên ngoài, sau checklist này nên tiếp tục với checklist chọn đơn vị Security Audit. Nếu scope vẫn chưa rõ, quay lại Security Audit Scope.
Nếu cần đi từ bước chuẩn bị sang scope, methodology, testing, finding và report, xem hub Website Security Audit.