Một Security Audit có thể thất bại ngay từ đầu nếu scope không rõ. Không phải vì tester thiếu công cụ, mà vì không ai chắc asset nào được kiểm tra, boundary nằm ở đâu, kỹ thuật nào được phép và điều gì phải dừng lại.
Security Audit Scope là phần xác định phạm vi của assessment trước khi bắt đầu kiểm thử. Nó giúp tránh hai rủi ro đối nghịch: bỏ sót asset quan trọng và kiểm tra vượt quá phạm vi được cho phép.
Bài này tập trung vào cách xác định asset, boundary, in-scope, out-of-scope, environment, access level và Rules of Engagement. Phương pháp kiểm thử chi tiết được tách riêng tại Website Security Audit Methodology.
Security Audit Scope là gì?
Security Audit Scope là mô tả có cấu trúc về những gì assessment được phép xem xét và giới hạn của hoạt động đó.
Một scope tốt thường trả lời được:
- Asset nào nằm trong phạm vi?
- Asset nào bị loại trừ?
- Kiểm tra production, staging hay cả hai?
- Tester có account hay chỉ kiểm tra từ bên ngoài?
- Loại kiểm tra nào được phép?
- Có giới hạn với exploitation, load, upload hoặc dữ liệu nhạy cảm không?
- Ai có quyền phê duyệt thay đổi scope?
- Khi phát hiện rủi ro nghiêm trọng thì escalation cho ai?
Scope không phải checklist finding. Nó là hợp đồng kỹ thuật cho phạm vi assessment.
Phân biệt Asset, Boundary và Scope
| Khái niệm | Ý nghĩa | Ví dụ |
|---|---|---|
| Asset | Thành phần có giá trị hoặc có thể bị tác động | domain, API, admin portal, server, database |
| Boundary | Ranh giới logic hoặc kỹ thuật của hệ thống được xem xét | website public + origin server, không gồm ERP nội bộ |
| Scope | Tập asset, boundary và điều kiện kiểm tra đã được cho phép | example.com, api.example.com và admin trên staging trong khung giờ xác định |
Một asset có thể thuộc kiến trúc website nhưng vẫn nằm ngoài scope nếu không có quyền kiểm tra hoặc không liên quan đến objective của engagement.
Cách xác định Security Audit Scope từng bước
Bước 1: Bắt đầu từ mục tiêu assessment
Không nên liệt kê toàn bộ domain rồi “scan tất cả”. Trước tiên cần biết assessment đang cố trả lời câu hỏi nào: baseline trước go-live, review sau handover, đánh giá exposure sau migration, review WordPress/plugin, kiểm tra portal có account hay review control sau incident.
Mục tiêu quyết định asset nào đáng đưa vào scope. Nếu chưa biết nên chọn Audit, Vulnerability Assessment hay Penetration Test, xem bài so sánh ba loại assessment.
Bước 2: Lập Asset Inventory trước khi khóa phạm vi
Scope không thể chính xác hơn asset inventory. Với website, inventory có thể gồm domain, subdomain, origin server, CDN/WAF, CMS, plugin/theme quan trọng, API, admin portal, authentication provider, database, object storage, DNS/registrar, backup storage và third-party integration.
Không nhất thiết tất cả asset đều được kiểm tra. Mục tiêu của inventory là biết chúng tồn tại để chủ động quyết định in-scope hay out-of-scope.
Bước 3: Xác định In-Scope Asset bằng định danh rõ ràng
Mỗi asset trong scope nên được mô tả đủ cụ thể để tester và owner hiểu giống nhau.
https://example.com/– website production;https://staging.example.com/– staging;https://api.example.com/v1/– API v1;- WordPress administrator account cấp riêng cho assessment;
- origin server IP cụ thể.
Cụm từ mơ hồ như “toàn bộ hệ thống website” dễ gây tranh cãi nếu sau đó xuất hiện subdomain, API hoặc server mà owner không định cho phép kiểm tra.
Bước 4: Ghi rõ Out-of-Scope và Exclusions
Danh sách out-of-scope quan trọng không kém in-scope. Có thể loại trừ payment provider, SaaS bên thứ ba, corporate email, ERP/CRM, production database, social engineering, denial-of-service testing hoặc physical security.
Nếu một out-of-scope asset ảnh hưởng trực tiếp đến finding, report có thể ghi dependency hoặc limitation nhưng không nên tự ý mở rộng kiểm thử.
Bước 5: Xác định Boundary theo luồng dữ liệu và trust
Boundary không chỉ là domain. Một website có thể có luồng:
User → CDN/WAF → Origin → Application → Database → Third-party API
Khi xác định boundary, cần hỏi dữ liệu đi qua những thành phần nào, credential được dùng ở đâu, component nào trust component khác, admin truy cập qua đường nào và third party nào có quyền gọi API hoặc nhận webhook.
OWASP WSTG đặt information gathering và mapping application architecture ở đầu quá trình web testing chính vì lý do này.
Bước 6: Chọn Production, Staging hay cả hai
Staging giảm nguy cơ ảnh hưởng user thật và có thể cho phép test sâu hơn, nhưng chỉ đại diện tốt nếu code/config/control đủ gần production.
Production cho bằng chứng sát trạng thái thật hơn nhưng cần giới hạn kỹ thuật chặt hơn, đặc biệt với request volume, exploitation, upload, state change và dữ liệu nhạy cảm.
Một mô hình thực dụng là production cho passive/safe review, còn kỹ thuật có nguy cơ thay đổi trạng thái chuyển sang staging tương đương.
Bước 7: Xác định mức độ truy cập của tester
| Mức truy cập | Coverage tốt hơn về |
|---|---|
| Không account | public attack surface, authentication entry point, exposed configuration |
| User account | authorization, session, user workflow, data isolation |
| Admin account | privileged workflow, role configuration, admin control |
| Server/config access | permission, service, runtime, logging, secret/configuration |
| Source/config review | control implementation và hidden logic |
Không có access không có nghĩa audit vô giá trị; nó chỉ tạo limitation khác và report phải thể hiện rõ điều đó.
Với privileged access, scope nên bao gồm cả ownership và lifecycle của account chứ không chỉ khả năng đăng nhập. Một ví dụ là case Security Audit phát hiện Admin không còn được quản lý, nơi account vẫn tồn tại nhưng owner đã mơ hồ.
Bước 8: Định nghĩa Rules of Engagement
RoE xác định cách assessment được phép diễn ra. Tối thiểu nên làm rõ thời gian, tester IP/account, request rate, quyền tạo test data, upload file, state change, controlled exploitation, kỹ thuật bị cấm, stop condition và emergency contact.
NIST SP 800-115 nhấn mạnh planning, authorization, logistics và constraints trước khi technical testing bắt đầu.
Bước 9: Xử lý Third-Party Asset đúng cách
Việc website tích hợp payment gateway, CDN, CRM, email, captcha, storage hoặc identity provider không tự động trao quyền kiểm thử hạ tầng của nhà cung cấp đó.
Scope nên phân biệt giữa việc kiểm tra integration/configuration mà website owner kiểm soát và việc kiểm thử trực tiếp hạ tầng third party, vốn cần authorization riêng.
Bước 10: Xác định Data Handling và Evidence Boundary
Assessment có thể gặp dữ liệu nhạy cảm. Nguyên tắc tốt là thu thập đủ để chứng minh finding nhưng không nhiều hơn mức cần thiết.
Cần làm rõ screenshot có chứa dữ liệu thật không, PII/secret có cần redact không, log/request-response lưu ở đâu, retention bao lâu, ai được nhận report và cleanup test account/test data thế nào.
Quản trị Scope trong suốt engagement
Scope Creep là gì?
Scope creep xảy ra khi assessment dần mở rộng ngoài phạm vi ban đầu mà không có phê duyệt rõ ràng, ví dụ phát hiện subdomain mới rồi tự kiểm tra, chuyển từ review sang exploitation, chuyển từ staging sang production hoặc test third-party service chỉ vì nó xuất hiện trong luồng dữ liệu.
Nếu cần mở rộng scope, nên có change control: ghi asset mới, lý do, risk, authorization và cập nhật RoE trước khi tiếp tục.
Mẫu Security Audit Scope tối thiểu
| Trường | Ví dụ nội dung |
|---|---|
| Mục tiêu | Baseline security review sau migration |
| In-scope | example.com, api.example.com, origin server |
| Out-of-scope | Payment provider, corporate email, ERP |
| Environment | Production safe tests + staging cho state-changing tests |
| Accounts | 1 user role, 1 admin test account |
| Allowed | Configuration review, manual testing, controlled validation |
| Prohibited | DoS, destructive action, social engineering |
| Data handling | Redact PII, tối thiểu hóa evidence |
| Escalation | Technical owner + business owner |
| Change control | Asset mới cần phê duyệt trước khi kiểm tra |
Mẫu này không thay thế authorization hoặc RoE đầy đủ, nhưng giúp tránh scope chỉ tồn tại dưới dạng trao đổi miệng.
Quality Gate cho một Scope tốt
7 lỗi thường gặp
- Dùng từ “toàn bộ website” nhưng không liệt kê asset.
- Không ghi out-of-scope.
- Không phân biệt staging và production.
- Không xác định account/role được cấp.
- Không nêu kỹ thuật bị cấm.
- Không có emergency contact.
- Không cập nhật scope khi kiến trúc thay đổi trong assessment.
Scope tốt giúp report đáng tin hơn như thế nào?
Một report chỉ có ý nghĩa khi người đọc biết coverage và limitation.
Câu “không phát hiện vấn đề authorization nghiêm trọng” có ý nghĩa rất khác nếu audit không được cấp user account. Tương tự, “server không có finding” không có giá trị nếu server nằm ngoài scope.
Vì vậy scope nên được ghi lại trong report để người đọc hiểu kết luận áp dụng cho đâu và không áp dụng cho đâu.
Kết luận
Security Audit Scope là nền tảng của một assessment có kiểm soát. Nó phải xác định mục tiêu, asset, boundary, environment, access level, exclusions, Rules of Engagement, data handling và cơ chế thay đổi phạm vi.
Scope càng rõ, việc chọn methodology, thu evidence và đánh giá finding càng đáng tin cậy. Ngược lại, scope mơ hồ có thể dẫn tới blind spot, report khó diễn giải hoặc kiểm tra vượt quyền.
Nếu chưa có baseline, có thể đọc trước Website Security Audit là gì? và Khi nào website cần Security Audit?. Khi đã xác định nhu cầu, trang Website Security Audit là điểm bắt đầu để trao đổi scope theo kiến trúc thực tế.