Penetration Testing là gì? Khi nào doanh nghiệp cần và chuẩn bị như thế nào

“Hệ thống của chúng tôi đã có firewall, có WAF, đội dev cũng cẩn thận — vậy có cần pentest không?” Đây là câu hỏi chúng tôi nghe thường xuyên nhất khi trao đổi với các doanh nghiệp. Câu trả lời ngắn gọn: firewall và WAF là biện pháp phòng thủ, còn pentest là cách duy nhất để kiểm chứng các biện pháp đó có thực sự chặn được một kẻ tấn công có chủ đích hay không. Bài viết này giải thích pentest là gì, khi nào doanh nghiệp cần, và quan trọng nhất — làm sao để một đợt pentest mang lại giá trị thực thay vì một bản báo cáo dày để 'cất tủ'.

Penetration Testing là gì — và khác gì quét lỗ hổng?

Penetration testing (kiểm thử xâm nhập) là hoạt động mô phỏng tấn công có kiểm soát vào hệ thống, do chuyên gia bảo mật thực hiện với sự cho phép bằng văn bản của chủ sở hữu hệ thống. Mục tiêu là tìm ra các lỗ hổng mà kẻ tấn công thật có thể khai thác, chứng minh tác động thực tế và đưa ra khuyến nghị khắc phục.

Nhiều doanh nghiệp nhầm lẫn pentest với quét lỗ hổng tự động (vulnerability scanning). Hai hoạt động này bổ trợ nhau nhưng khác nhau căn bản:

Một ví dụ điển hình: công cụ quét tự động gần như không bao giờ phát hiện được lỗi phân quyền ngang (người dùng A xem được đơn hàng của người dùng B bằng cách đổi mã đơn trên URL) hay lỗi logic nghiệp vụ (áp mã giảm giá nhiều lần, thao túng giá trị giỏ hàng). Đây lại chính là nhóm lỗ hổng gây thiệt hại trực tiếp nhất cho doanh nghiệp thương mại điện tử và tài chính — và chỉ con người mới tìm ra.

Các hình thức và phạm vi kiểm thử phổ biến

Theo lượng thông tin cung cấp trước cho đội kiểm thử, pentest chia thành ba hình thức:

• Black box — đội kiểm thử không có thông tin gì ngoài tên miền/dải IP, mô phỏng kẻ tấn công bên ngoài. Sát thực tế nhất nhưng tốn thời gian và có thể bỏ sót lỗ hổng nằm sâu.
• Grey box — đội kiểm thử được cấp tài khoản người dùng và tài liệu cơ bản. Đây là hình thức cân bằng tốt nhất giữa chi phí và độ phủ cho đa số doanh nghiệp: mô phỏng kẻ tấn công đã có tài khoản (hoặc nhân viên), đồng thời đủ thông tin để đào sâu vào logic nghiệp vụ.
• White box — đội kiểm thử tiếp cận mã nguồn, tài liệu kiến trúc. Độ phủ cao nhất, phù hợp với hệ thống xử lý giao dịch tài chính hoặc dữ liệu đặc biệt nhạy cảm.

Về phạm vi, các đối tượng kiểm thử phổ biến gồm: ứng dụng web, API (ngày càng quan trọng khi kiến trúc microservices và mobile-first phổ biến), ứng dụng di động, hạ tầng mạng (external và internal), cấu hình cloud (AWS, Azure, GCP) và social engineering (kiểm thử con người qua phishing mô phỏng).

Khi nào doanh nghiệp cần pentest?

• Trước khi ra mắt hệ thống quan trọng — sản phẩm mới, cổng thanh toán, ứng dụng khách hàng. Sửa lỗ hổng trước khi go-live luôn rẻ hơn sửa khi đã có người dùng thật và dữ liệu thật.
• Sau thay đổi lớn về kiến trúc — chuyển lên cloud, thay đổi hệ thống xác thực, tích hợp đối tác mới, sáp nhập hệ thống sau M&A.
• Định kỳ hằng năm — hệ thống không đứng yên: code mới được triển khai mỗi tuần, lỗ hổng mới được công bố mỗi ngày. Kết quả pentest có 'hạn sử dụng'.
• Khi khách hàng hoặc đối tác yêu cầu — ngày càng nhiều doanh nghiệp lớn yêu cầu nhà cung cấp xuất trình báo cáo đánh giá bảo mật độc lập như điều kiện hợp tác. Có sẵn báo cáo pentest gần nhất giúp rút ngắn đáng kể chu kỳ bán hàng B2B.
• Để đáp ứng yêu cầu tuân thủ — nhiều khung tuân thủ (PCI DSS, ISO 27001) yêu cầu kiểm thử xâm nhập định kỳ; nghĩa vụ bảo đảm an toàn dữ liệu cá nhân theo pháp luật Việt Nam cũng khó chứng minh nếu chưa từng đánh giá độc lập.

Tiêu chí chọn đơn vị kiểm thử

Chất lượng pentest phụ thuộc gần như hoàn toàn vào con người thực hiện. Khi đánh giá nhà cung cấp, hãy xem xét:

• Năng lực kiểm thử viên — các chứng chỉ thực hành được công nhận rộng rãi (OSCP, OSWE, OSEP, CREST, GPEN...) là chỉ báo tốt, cùng với hồ sơ nghiên cứu công khai (CVE, bug bounty, công bố kỹ thuật).
• Phương pháp luận rõ ràng — đơn vị chuyên nghiệp làm việc theo chuẩn công khai như OWASP WSTG (ứng dụng web), OWASP MASTG (mobile), PTES, và giải thích được quy trình của họ từng bước.
• Quy trình bảo mật của chính họ — NDA ký trước khi trao đổi chi tiết, kênh trao đổi và bàn giao báo cáo được mã hóa, chính sách xóa dữ liệu sau engagement. Đơn vị giữ dữ liệu kiểm thử của bạn vô thời hạn chính là một rủi ro bảo mật mới.
• Chất lượng báo cáo — yêu cầu xem báo cáo mẫu (đã ẩn danh). Báo cáo tốt có executive summary cho lãnh đạo, mô tả kỹ thuật đủ chi tiết để tái hiện, đánh giá mức độ theo CVSS kèm bối cảnh kinh doanh, và khuyến nghị khắc phục cụ thể.
• Chính sách re-test — phát hiện lỗ hổng chỉ là một nửa công việc. Đơn vị có trách nhiệm sẽ xác minh lại miễn phí (hoặc với chi phí rõ ràng) sau khi bạn khắc phục.

Chuẩn bị cho một đợt pentest

1. Xác định phạm vi (scope) rõ ràng. Liệt kê các tên miền, dải IP, ứng dụng, API trong phạm vi — và quan trọng không kém, những gì ngoài phạm vi. Ưu tiên các hệ thống xử lý dữ liệu nhạy cảm và giao dịch giá trị cao.
2. Thống nhất rules of engagement. Cửa sổ thời gian kiểm thử (giờ hành chính hay ngoài giờ), các kỹ thuật bị loại trừ (ví dụ denial-of-service), đầu mối liên hệ khẩn cấp hai bên, và điều kiện dừng kiểm thử.
3. Chọn môi trường. Kiểm thử trên staging an toàn hơn cho vận hành nhưng chỉ có giá trị khi staging giống production. Nếu kiểm thử trên production, đảm bảo backup mới nhất và thống nhất quy trình xử lý nếu có gián đoạn.
4. Chuẩn bị tài khoản kiểm thử. Với grey box, tạo sẵn các tài khoản ở những vai trò khác nhau (người dùng thường, quản trị viên...) để đội kiểm thử đánh giá phân quyền giữa các vai trò.
5. Thông báo nội bộ đúng người. Đội vận hành và SOC cần biết để không xử lý nhầm thành sự cố thật — nhưng đôi khi việc *không* thông báo rộng lại là một phần của bài kiểm thử khả năng phát hiện.

Đọc báo cáo pentest đúng cách

Khi nhận báo cáo, đừng chỉ đếm số lỗ hổng hay nhìn vào điểm CVSS. Một lỗ hổng 'Medium' trên hệ thống xử lý thanh toán có thể cấp bách hơn một lỗ hổng 'High' trên trang nội bộ ít dùng. Hãy đọc theo ba câu hỏi: lỗ hổng nào có đường khai thác thực tế từ internet, lỗ hổng nào chạm đến dữ liệu hoặc tiền, và lỗ hổng nào là triệu chứng của vấn đề hệ thống (ví dụ: 5 lỗi phân quyền khác nhau thường có nghĩa là ứng dụng thiếu một lớp kiểm soát truy cập tập trung — sửa gốc tốt hơn vá từng chỗ).

Sau đó, lập kế hoạch khắc phục có thời hạn theo mức ưu tiên, phân công rõ người chịu trách nhiệm, và đặt lịch re-test để xác minh. Một chu trình pentest chỉ thực sự khép lại khi lỗ hổng được xác nhận đã đóng.