Pentest là gì?

Mục lục

1. Pentest là gì và nó trả lời câu hỏi nào?
2. Một cuộc pentest diễn ra qua những giai đoạn nào?
3. Pentest có những loại nào?
4. Pentest khác gì quét lỗ hổng, red team và bug bounty?
5. Ví dụ minh hoạ: một chuỗi lỗi nhỏ dẫn tới chiếm quyền
6. Doanh nghiệp Việt Nam nên pentest khi nào?
7. Làm sao chuẩn bị và nghiệm thu một cuộc pentest?
8. Pentest có tự động hoá được không?
9. Ưu điểm và hạn chế của pentest
10. Khi nào nên và chưa nên pentest?
11. Câu hỏi thường gặp

Pentest là gì và nó trả lời câu hỏi nào?

Pentest là viết tắt của penetration testing, tiếng Việt thường gọi là kiểm thử xâm nhập hoặc kiểm thử thâm nhập. Theo hướng dẫn NIST SP 800-115, đây là hình thức kiểm thử bảo mật trong đó người đánh giá mô phỏng tấn công thực tế để tìm cách vượt qua các cơ chế bảo vệ của ứng dụng, hệ thống hoặc mạng. NIST công bố tài liệu này năm 2008, và nó vẫn được nhiều đơn vị dùng làm khung tham chiếu.

Câu hỏi mà pentest trả lời không phải “hệ thống có bao nhiêu lỗi”. Câu hỏi đúng là: “Nếu một người có động cơ và kỹ năng nhắm vào chúng ta, họ đi được tới đâu, bằng đường nào, và lấy được gì?”. Một báo cáo quét tự động có thể liệt kê 300 cảnh báo mà không cho bạn biết cảnh báo nào dẫn tới việc đọc được cơ sở dữ liệu khách hàng. Pentest đi ngược lại: chọn mục tiêu (ví dụ quyền quản trị, dữ liệu thanh toán), rồi tìm đường ngắn nhất tới đó.

Yếu tố pháp lý quan trọng nhất là sự cho phép. Pentester phải được chủ sở hữu hệ thống đồng ý; nếu không, hành vi xâm nhập bị coi là hack trái phép. Vì vậy mọi cuộc pentest đều bắt đầu bằng một văn bản thoả thuận nêu rõ đối tượng, thời gian, địa chỉ IP nguồn của đội kiểm thử và những việc không được làm.

Pentest thuộc nhóm hoạt động rộng hơn là đánh giá an toàn thông tin. Nếu bạn cần nền tảng về các mục tiêu bảo vệ dữ liệu, hãy xem bài khái niệm an toàn thông tin trước khi đi vào phần kỹ thuật bên dưới.

Một cuộc pentest diễn ra qua những giai đoạn nào?

Có nhiều khung quy trình. Chuẩn PTES (Penetration Testing Execution Standard) chia thành 7 giai đoạn: tương tác trước kiểm thử, thu thập thông tin, mô hình hoá mối đe doạ, phân tích lỗ hổng, khai thác, hậu khai thác và báo cáo. NIST SP 800-115 gọn hơn, chỉ có bốn giai đoạn: lập kế hoạch, khám phá, tấn công và báo cáo. Hai khung này nhìn cùng một công việc ở mức chi tiết khác nhau.

Những giai đoạn đáng chú ý trong thực tế

• Thoả thuận phạm vi: liệt kê tên miền, dải IP, ứng dụng, môi trường (production hay staging), khung giờ, đầu mối liên lạc khẩn cấp và các hành vi bị cấm như tấn công từ chối dịch vụ hay xoá dữ liệu.
• Thu thập thông tin: gồm cả thụ động (bản ghi DNS, chứng chỉ công khai, thông tin tuyển dụng, mã nguồn bị lộ trên kho công khai) và chủ động (quét cổng, nhận diện dịch vụ). Wikipedia mô tả các hoạt động ngoại vi như dò thông tin DNS, WHOIS và nhật ký minh bạch chứng chỉ. Xem thêm cách hệ thống tên miền hoạt động nếu bạn muốn hiểu vì sao DNS lộ nhiều thông tin.
• Khai thác và hậu khai thác: sau khi vào được một máy, pentester kiểm tra có đi tiếp sang hệ thống khác, nâng quyền, hay lấy được dữ liệu nhạy cảm không. Đây là phần mà công cụ quét không làm được.
• Báo cáo: gồm tóm tắt cho lãnh đạo, chi tiết kỹ thuật kèm các bước tái hiện, mức độ nghiêm trọng và khuyến nghị vá.

Bài này không hướng dẫn kỹ thuật khai thác. Mục tiêu là giúp bạn hiểu pentest đủ để đặt hàng, nghiệm thu và đọc báo cáo.

Pentest có những loại nào?

Bạn có thể phân loại theo hai trục: pentester biết bao nhiêu về hệ thống, và đối tượng bị kiểm thử là gì.

Phân loại theo mức thông tin

Hộp đen cho thấy hình ảnh kẻ tấn công từ Internet. Hộp trắng, theo mô tả của một nguồn trong nước, cung cấp cho pentester mã nguồn, sơ đồ kiến trúc, tài liệu kỹ thuật và quyền truy cập nội bộ, nên phát hiện được lỗi nằm sâu mà kiểm thử từ ngoài khó thấy. Hộp xám thường là lựa chọn thực dụng cho ứng dụng web có đăng nhập: nhiều lỗi nghiêm trọng (như người dùng này xem được dữ liệu người dùng khác) chỉ xuất hiện sau khi đăng nhập.

Phân loại theo đối tượng

Đối tượng	Câu hỏi chính	Ví dụ vấn đề thường gặp
Ứng dụng web / API	Người dùng có vượt quyền, lấy dữ liệu của người khác được không?	Lỗi phân quyền, lỗi xử lý đầu vào như SQL injection
Ứng dụng mobile	Dữ liệu lưu trên máy và kênh gọi API có an toàn không?	Khoá API nhúng trong ứng dụng, lưu token không mã hoá
Mạng bên ngoài	Dịch vụ nào đang mở ra Internet ngoài ý muốn?	Cổng quản trị mở, phần mềm chưa vá
Mạng nội bộ	Một máy bị chiếm thì lan sang đâu?	Mật khẩu quản trị dùng lại, chia vùng mạng kém
Cloud	Cấu hình tài nguyên có công khai hoặc cấp quyền thừa không?	Kho lưu trữ mở, quyền IAM quá rộng
Wi-Fi	Khách có sang được mạng nội bộ không?	Mạng khách và mạng văn phòng không tách
Con người	Nhân viên có bị dụ cung cấp thông tin không?	Email giả mạo, gọi điện giả danh (xem kỹ thuật thao túng con người)

Các hệ thống điều khiển công nghiệp (OT, SCADA) cũng có dịch vụ pentest riêng, nhưng cần quy tắc rất thận trọng vì một gói tin lạ có thể làm dừng dây chuyền. Một nhà cung cấp tại Việt Nam mô tả cách tiếp cận cho nhóm này dựa trên NIST SP 800-82 và IEC 62443.

Pentest khác gì quét lỗ hổng, red team và bug bounty?

Đây là chỗ người mua dịch vụ hay nhầm nhất, vì nhiều báo giá “pentest” thực chất chỉ là chạy công cụ quét rồi đổi tên báo cáo.

Tiêu chí	Quét lỗ hổng	Pentest	Red team	Bug bounty
Cách làm chính	Công cụ tự động	Người dùng công cụ, kiểm tay và khai thác	Mô phỏng đối thủ nhiều tuần, nhiều kênh	Cộng đồng nhà nghiên cứu độc lập
Kết quả	Danh sách điểm yếu nghi ngờ	Lỗi đã được chứng minh kèm đường tấn công	Đánh giá khả năng phát hiện và phản ứng	Báo cáo lỗi lẻ theo chương trình
Phạm vi	Rộng	Xác định trước	Mục tiêu nghiệp vụ, ít ràng buộc	Theo chính sách chương trình
Đội phòng thủ biết trước?	Thường biết	Thường biết	Thường chỉ lãnh đạo biết	Công khai
Tần suất hợp lý	Liên tục	Định kỳ, hoặc trước khi ra mắt	Tổ chức đã có đội giám sát	Liên tục

Về độ tin cậy, NIST nêu một điểm đáng nhớ: công cụ quét có thể gán mức rủi ro thấp cho từng lỗi riêng lẻ khiến người đánh giá tin tưởng sai vào các biện pháp đang có. Theo cùng tài liệu, cách đáng tin hơn để xác định rủi ro tổng hợp của các lỗ hổng là pentest. Nói cách khác, ba lỗi “thấp” có thể nối thành một đường chiếm quyền “nghiêm trọng”.

Bug bounty (thưởng lỗi) bổ sung chứ không thay pentest. Chương trình này tốt khi sản phẩm đã ổn định và có đội xử lý báo cáo nhanh; còn pentest có khung thời gian, phạm vi và báo cáo nghiệm thu rõ ràng, phù hợp khi bạn cần bằng chứng cho đối tác hoặc kiểm toán.

Ví dụ minh hoạ: một chuỗi lỗi nhỏ dẫn tới chiếm quyền

Một công ty bán lẻ có cổng đại lý, đặt tên là hệ thống A. Pentest hộp xám được cấp một tài khoản đại lý bình thường. Đội kiểm thử ghi nhận ba phát hiện, mỗi cái nếu đứng riêng thì quét tự động chỉ gắn mức trung bình hoặc thấp:

1. Trang xuất báo cáo đơn hàng chỉ kiểm tra đã đăng nhập chứ không kiểm tra đại lý nào được xem mã đơn nào, nên đổi mã đơn là xem được đơn của đại lý khác.
2. Báo cáo xuất ra có cột email nhân viên kinh doanh nội bộ.
3. Trang quên mật khẩu của nhân viên nội bộ phản hồi khác nhau tuỳ email có tồn tại hay không, và không giới hạn số lần thử.

Ghép lại, kẻ tấn công có thể thu được danh sách email nhân viên thật, dò tài khoản đang hoạt động, rồi nhắm vào những tài khoản đó bằng thư lừa đảo. Pentest báo cáo đây là một đường tấn công hoàn chỉnh và xếp mức nghiêm trọng cao, dù không lỗi đơn lẻ nào đạt ngưỡng đó. Giá trị của pentest nằm ở bước nối này.

Doanh nghiệp Việt Nam nên pentest khi nào?

Không cần pentest cho mọi thứ mỗi năm. Dưới đây là các thời điểm có lý do rõ ràng:

• Trước khi ra mắt hoặc thay đổi lớn: cổng thanh toán, ứng dụng khách hàng, API mở cho đối tác, tính năng đăng nhập mới.
• Sau thay đổi kiến trúc: chuyển lên cloud, tách microservices, thêm nhà cung cấp bên thứ ba có quyền truy cập dữ liệu.
• Theo yêu cầu đối tác hoặc chuẩn: chuẩn PCI DSS có yêu cầu về kiểm thử xâm nhập; tài liệu của OWASP nhắc rằng yêu cầu 11.3 của PCI DSS định nghĩa việc pentest (đánh số có thể khác ở phiên bản mới). Với tổ chức theo chuẩn ISO 27001, pentest là một bằng chứng cho việc đánh giá lỗ hổng kỹ thuật.
• Sau sự cố: để kiểm tra đường vào đã được bịt hết chưa, không chỉ chỗ đã biết.

Với doanh nghiệp nhỏ ngân sách hạn chế, thứ tự hợp lý thường là: bật xác thực nhiều yếu tố, vá phần mềm, sao lưu, rồi mới pentest tài sản đối ngoại quan trọng nhất. Bài an ninh mạng cho doanh nghiệp nhỏ trình bày lớp phòng thủ cơ bản này.

Về pháp lý, hãy lưu ý một điểm riêng của pentest: nếu phạm vi chạm tới dữ liệu cá nhân thật của khách hàng, hợp đồng nên quy định pentester chỉ chụp bằng chứng tối thiểu (ví dụ che các trường như số điện thoại, số căn cước trong ảnh chụp báo cáo) và nêu thời hạn huỷ dữ liệu thu thập. Hợp đồng cũng cần ràng buộc bảo mật thông tin đối với nhà cung cấp.

Làm sao chuẩn bị và nghiệm thu một cuộc pentest?

Danh sách cần thống nhất trước khi bắt đầu

• Danh sách tài sản trong phạm vi: tên miền, IP, phiên bản ứng dụng, môi trường. Tài sản thuê từ nhà cung cấp cloud hoặc hosting cần kiểm tra chính sách cho phép kiểm thử của họ.
• Môi trường: ưu tiên staging giống production; nếu phải test trên production, thoả thuận khung giờ và ngưỡng dừng.
• Tài khoản thử nghiệm cho từng vai trò (khách, người dùng, quản trị viên) khi làm hộp xám.
• Kênh liên lạc khẩn cấp và quy tắc báo ngay khi gặp lỗi nghiêm trọng, thay vì chờ tới báo cáo cuối.
• Thông báo cho đội vận hành, nhà cung cấp hosting và đội giám sát, trừ khi bài kiểm tra cố ý giữ kín.
• Địa chỉ IP nguồn của đội kiểm thử để phân biệt với tấn công thật trong nhật ký.

Báo cáo tốt trông thế nào

Mỗi phát hiện nên có: mô tả, điều kiện cần để khai thác, các bước tái hiện, bằng chứng (ảnh chụp, đoạn yêu cầu và phản hồi đã che dữ liệu nhạy cảm), tác động nghiệp vụ, mức độ nghiêm trọng và cách khắc phục cụ thể. Báo cáo chỉ dán lại đầu ra của công cụ, không có bước tái hiện, là dấu hiệu dịch vụ làm cho có.

Sau khi vá, hãy yêu cầu kiểm tra lại (retest). Nhiều báo cáo đóng lại với trạng thái “đã vá” nhưng bản vá chỉ chặn đúng mẫu thử ban đầu. Retest xác nhận lỗi thực sự đã hết, và đây là cách hợp lý để tách phần “đã sửa” khỏi phần “tưởng đã sửa”.

Lỗi thường gặp khi mua dịch vụ

• Phạm vi quá hẹp: chỉ test trang chủ trong khi API di động mới giữ dữ liệu.
• Không có người nhận kết quả: báo cáo gửi cho lãnh đạo, còn đội phát triển không biết để sửa.
• Chạy công cụ rồi gọi là pentest: kiểm tra bằng cách hỏi về phương pháp (PTES, hướng dẫn OWASP, NIST SP 800-115) và yêu cầu xem mẫu báo cáo đã ẩn danh.
• Bỏ qua phát hiện ở môi trường thật: nếu một lỗi bị phát hiện dưới dạng tấn công thật, hãy đối chiếu với nhật ký trong trung tâm giám sát an ninh để xem đội giám sát có thấy tín hiệu hay không.

Pentest có tự động hoá được không?

Một phần. Công cụ giúp quét cổng, nhận diện dịch vụ, thử các cấu hình sai đã biết và xác minh lại lỗi. NIST ghi nhận các kỹ thuật xác minh lỗ hổng như thế có thể làm thủ công hoặc bằng công cụ tự động, tuỳ kỹ thuật và kỹ năng của đội kiểm thử. Phần khó tự động hoá là lỗi logic nghiệp vụ: đổi giá trong giỏ hàng, bỏ qua bước phê duyệt, hoặc gộp quyền giữa hai chức năng. Những lỗi này cần người hiểu nghiệp vụ của chính ứng dụng. Gần đây các nhóm nghiên cứu cũng thử dùng mô hình ngôn ngữ lớn để hỗ trợ pentest, nhưng đó vẫn chủ yếu là hướng nghiên cứu hơn là thay thế được người kiểm thử có kinh nghiệm.

Ưu điểm và hạn chế của pentest

Ưu điểm	Hạn chế
Chứng minh được tác động thật, giúp ưu tiên vá	Chỉ phản ánh tình trạng tại thời điểm test; sau một lần cập nhật mã là có thể khác
Tìm được lỗi logic và lỗi nối chuỗi mà công cụ bỏ sót	Phụ thuộc kỹ năng và thời gian của đội; cùng phạm vi, hai đội có thể ra kết quả khác nhau
Cung cấp bằng chứng cho đối tác, kiểm toán	Không chứng minh hệ thống “an toàn”, chỉ cho biết đã không tìm thấy gì thêm trong phạm vi và thời gian đó
Kiểm tra cả quy trình phát hiện và phản ứng nếu có phối hợp	Có rủi ro ảnh hưởng dịch vụ nếu không có quy tắc an toàn

Khi nào nên và chưa nên pentest?

Nên khi hệ thống đã ổn định đủ để kiểm thử, có dữ liệu hoặc giao dịch đáng bảo vệ, và đội kỹ thuật có thời gian sửa lỗi trong vòng vài tuần sau báo cáo. Pentest vào đúng thời điểm trước ra mắt thường rẻ hơn sửa kiến trúc sau khi đã có khách.

Chưa nên khi chưa có danh sách tài sản (không biết mình có những máy chủ nào), khi chưa vá những lỗi đã biết từ quét tự động, hoặc khi ứng dụng đang thay đổi hàng ngày mà không có bản dựng ổn định để kiểm thử. Trong các trường hợp này, quét lỗ hổng và dọn tài sản sẽ có ích hơn, vì pentester sẽ mất công vào những lỗi mà công cụ rẻ hơn cũng tìm được.

Pentest cũng không thay thế phòng thủ liên tục như tường lửa ứng dụng web (WAF) hay giám sát. Nó là phép thử định kỳ để xem các lớp phòng thủ đó có hoạt động như bạn tưởng không.

Câu hỏi thường gặp

Pentest có hợp pháp không?

Có, khi chủ sở hữu hệ thống đồng ý bằng văn bản và pentester làm trong phạm vi đã thoả thuận. Vượt phạm vi hoặc kiểm thử hệ thống của bên thứ ba mà không có phép (ví dụ máy chủ của nhà cung cấp hosting) có thể bị coi là xâm nhập trái phép. Hãy hỏi pháp chế hoặc luật sư của bạn khi hợp đồng có yếu tố đặc thù.

Pentest và ethical hacking có phải một không?

Không hoàn toàn. Một nguồn trong nước giải thích rằng ethical hacking là lĩnh vực rộng hơn, gồm mọi hoạt động dùng kỹ năng tấn công để cải thiện bảo mật. Pentest là một hoạt động cụ thể, có phạm vi và báo cáo, nằm trong lĩnh vực đó.

Bao lâu nên pentest một lần?

Không có con số chung cho mọi doanh nghiệp. Thông lệ là pentest định kỳ (thường hằng năm nếu chuẩn hoặc đối tác yêu cầu) và thêm lần riêng sau thay đổi lớn. Hệ thống phát hành liên tục thường kết hợp quét tự động trong quy trình phát triển và pentest sâu theo mốc.

Pentest có làm gián đoạn hệ thống không?

Có thể, nhất là ở giai đoạn khai thác. Giảm rủi ro bằng cách test trên môi trường staging giống production, thoả thuận khung giờ, loại trừ các thao tác gây từ chối dịch vụ, và có đầu mối liên lạc khẩn cấp hai chiều. Nếu hệ thống đang bị tấn công từ chối dịch vụ, hãy xem thêm bài về tấn công DDoS để phân biệt với hoạt động kiểm thử.

Báo cáo pentest nói hệ thống “sạch” thì có an toàn tuyệt đối không?

Không. Báo cáo chỉ cho biết đội kiểm thử không tìm ra đường xâm nhập khác trong phạm vi, thời gian và mức thông tin đã thoả thuận. Lỗi chưa từng được biết đến vẫn có thể tồn tại; bạn cần phòng thủ nhiều lớp và giám sát liên tục thay vì xem một báo cáo là kết luận.

Pentest có cần nhà cung cấp độc lập không?

Nên có ít nhất một lần do bên không tham gia xây dựng hệ thống thực hiện, vì đội phát triển thường khó nhìn ra giả định sai của chính mình. Đội nội bộ vẫn hữu ích cho kiểm tra thường xuyên, miễn là họ hiểu quy trình và có quyền hạn rõ ràng.