Security acceptance testing là gì - Kiểm thử chấp nhận bảo mật là gì

1. Định nghĩa:

Security acceptance testing

là quá trình kiểm thử các tiêu chí bảo mật được xác định trong user story hoặc definition of done (DoD) để đảm bảo tính năng chỉ được chấp nhận khi đáp ứng yêu cầu an toàn.

→ Ví dụ: Một user story “Đăng nhập” chỉ được chấp nhận khi kiểm thử brute force protection và logging sự kiện đăng nhập đều pass.

2. Mục đích sử dụng:
→ Đảm bảo tính năng đáp ứng cả chức năng và bảo mật trước khi release.
→ Giúp team agile kiểm soát chất lượng bảo mật ngay tại sprint.
→ Giảm thiểu rủi ro lỗ hổng lọt ra production.

3. Các bước áp dụng và ví dụ thực tiễn:
Bối cảnh: Một công ty fintech phát triển tính năng chuyển tiền.
→ Bước 1: Xác định security acceptance criteria (MFA, encryption, transaction logging).
→ Bước 2: Viết test case bảo mật cho từng tiêu chí.
→ Bước 3: Thực thi test trong sprint (manual, automated).
→ Bước 4: Chỉ chấp nhận story nếu pass toàn bộ security tests.
→ Bước 5: Lưu kết quả làm bằng chứng audit.

4. Lưu ý thực tiễn:
→ Acceptance test phải ngắn gọn, đo lường được.
→ Nên kết hợp test thủ công và tự động hóa.
→ Không được coi nhẹ tiêu chí bảo mật “ẩn” (ví dụ: secure session handling).

5. Ví dụ minh họa:
→ Cơ bản: Test “Không cho phép mật khẩu < 8 ký tự” trước khi accept story.
→ Nâng cao: Test “Tất cả API phải reject request không có JWT hợp lệ”.

6. Case Study Mini:
→ Tình huống: Một app thương mại điện tử phát hiện XSS sau khi release.
→ Giải pháp: Bổ sung security acceptance test “Input validation for checkout form”.
→ Kết quả: Sprint sau đó không còn XSS lọt vào production.

7. Câu hỏi kiểm tra nhanh (Quick Quiz):
Security acceptance testing giúp ích gì?
→ a. Đảm bảo chỉ release tính năng an toàn ←
→ b. Thay thế hoàn toàn penetration testing
→ c. Giúp bỏ qua DoD bảo mật
→ d. Giảm nhu cầu test automation

8. Câu hỏi tình huống (Scenario-Based Question):
Trong sprint review, story “Upload file” chưa qua acceptance test kiểm tra malware. Bạn sẽ xử lý thế nào để đảm bảo story không bị accept sai chuẩn?

9. Vì sao bạn nên quan tâm đến khái niệm này:
→ Acceptance test là “cửa ngõ cuối cùng” trước khi release tính năng.
→ Giúp tổ chức tránh tình trạng phát hành nhanh nhưng mất an toàn.
→ Là yêu cầu của nhiều chuẩn compliance (PCI-DSS, HIPAA).

10. Ứng dụng thực tế trong công việc:
→ Product Owner: chấp nhận story dựa trên cả functional & security tests.
→ Developer: viết test automation cho security criteria.
→ QA: thực hiện security acceptance test trước khi close ticket.
→ Security Champion: hỗ trợ xác định và validate criteria.

11. Sai lầm phổ biến khi triển khai:
→ Chỉ test chức năng mà bỏ qua security criteria.
→ Acceptance test quá mơ hồ, không đo lường được.
→ Không lưu lại kết quả test cho compliance.

12. Đối tượng áp dụng:
→ Product Owner, Developer, QA, Security Champion.
→ Áp dụng trong sprint review, DoD validation và release acceptance.

13. Giới thiệu đơn giản dễ hiểu:
Security acceptance testing giống như “kiểm tra an ninh trước khi lên máy bay” – chỉ ai đủ điều kiện an toàn mới được phép bay (release).

14. Câu hỏi thường gặp (FAQ):
Q1 → Có cần security acceptance test cho mọi story không?
→ Có, nhưng mức độ chi tiết tùy theo rủi ro của story.
Q2 → Ai viết security acceptance test?
→ QA và Developer, với input từ Security Champion.
Q3 → Có công cụ nào hỗ trợ không?
→ Selenium, OWASP ZAP, Burp Suite, CI/CD scanners.
Q4 → Acceptance test có thay thế pentest không?
→ Không, nó là lớp kiểm tra sớm và thường xuyên.
Q5 → Khi nào chạy security acceptance test?
→ Ngay trong sprint, trước khi PO accept story.

15. Gợi ý hỗ trợ:
→ Gửi email: info@fmit.vn
→ Nhắn tin Zalo: 0708 25 99 25
© Bản quyền thuộc về Viện FMIT – Từ điển quản trị chuẩn mực quốc tế