TMGS
Black box, gray box và white box mô tả mức thông tin mà nhóm kiểm thử được cung cấp trước khi đánh giá hệ thống. Chọn đúng cách tiếp cận giúp doanh nghiệp làm rõ mục tiêu pentest, chuẩn bị đầu vào và hiểu giới hạn của kết quả. Bài viết này tập trung vào cách lựa chọn phạm vi. Để tìm hiểu tổng quan, doanh nghiệp có thể xem dịch vụ kiểm thử xâm nhập của TMGS . Ba cách tiếp cận khác nhau ở điểm nào? Black box: ít thông tin ban đầu Nhóm kiểm thử bắt đầu với thông tin hạn chế về cấu trúc bên trong. Với ứng dụng web, đầu vào có thể là tên miền và phạm vi được phép đánh giá. Cách tiếp cận này giúp xem xét những gì có thể quan sát từ bên ngoài, trong giới hạn thời gian và quyền kiểm thử đã thống nhất. Cần cân nhắc: thời gian tìm hiểu bề mặt hệ thống có thể làm giảm thời gian dành cho các luồng nghiệp vụ phía sau đăng nhập. Không nên diễn giải một lần kiểm thử black box không phát hiện lỗi thành kết luận toàn bộ hệ thống an toàn. Gray box: cung cấp một phần thông tin Nhóm kiểm thử có một phần hiểu biết hoặc quyền truy cập, chẳng hạn tài khoản thử nghiệm và mô tả chức năng. Cách gọi gray box không tự xác định quyền hạn cụ thể; doanh nghiệp cần ghi rõ tài khoản, vai trò và tài liệu nào sẽ được cung cấp. Tình huống minh họa: với cổng quản lý đơn hàng, doanh nghiệp có thể chuẩn bị hai tài khoản người dùng thử nghiệm và dữ liệu giả để đánh giá việc phân quyền giữa các tài khoản. Đây là ví dụ lựa chọn phạm vi, không phải kết quả kiểm thử của một khách hàng. White box: hiểu rõ hơn cấu trúc bên trong Nhóm đánh giá được cung cấp thông tin sâu hơn, có thể gồm mã nguồn, kiến trúc và tài liệu kỹ thuật. Điều này hỗ trợ đối chiếu hành vi quan sát được với thiết kế hoặc phần triển khai trong phạm vi được tiếp cận. Cần làm rõ: có mã nguồn không đồng nghĩa mọi thành phần đều đã được rà soát. Hợp đồng và kế hoạch kiểm thử nên xác định phiên bản, thành phần, quyền truy cập cùng phần việc thực sự bao gồm đọc mã nguồn. Chọn phương án theo câu hỏi doanh nghiệp cần trả lời Không có phương án tốt nhất cho mọi hệ thống. Thay vì chọn theo tên gọi, hãy viết ra câu hỏi cần được giải đáp trước khi mời đơn vị kiểm thử đề xuất phạm vi: Muốn hiểu bề mặt công khai: cân nhắc một phần việc black box có phạm vi tên miền, ứng dụng và thời gian rõ ràng. Muốn đánh giá chức năng sau đăng nhập: cân nhắc gray box với tài khoản đủ vai trò, dữ liệu thử nghiệm và các luồng nghiệp vụ ưu tiên. Muốn xem xét sâu một ứng dụng do mình phát triển: cân nhắc white box hoặc kết hợp kiểm thử vận hành với rà soát mã nguồn được xác định riêng. Có nhiều mục tiêu: chia thành các phần việc và ghi rõ đầu vào, thời lượng, kết quả bàn giao cho từng phần. Ví dụ, một ứng dụng đặt hàng có thể cần kiểm tra cả chức năng công khai lẫn ranh giới giữa người mua, nhân viên hỗ trợ và quản trị viên. Trong trường hợp đó, chỉ ghi “pentest website” chưa đủ để biết các vai trò và luồng nào sẽ được đánh giá. Những đầu vào nên thống nhất trước khi bắt đầu Danh sách sau là gợi ý chuẩn bị để trao đổi phạm vi, không phải yêu cầu pháp lý hay cam kết dịch vụ: Tài sản và giới hạn: tên miền, API, môi trường, thành phần được phép kiểm thử và các hệ thống ngoài phạm vi. Mục tiêu nghiệp vụ: chức năng quan trọng, loại dữ liệu cần bảo vệ và các vai trò cần đánh giá. Đầu vào kỹ thuật: tài khoản thử nghiệm, tài liệu, phiên bản mã nguồn nếu có và cách bàn giao an toàn. Điều kiện vận hành: thời gian thực hiện, đầu mối phối hợp, thao tác bị hạn chế và điều kiện dừng khi ảnh hưởng dịch vụ. Kết quả bàn giao: báo cáo, cách mô tả bằng chứng, khuyến nghị xử lý và phạm vi kiểm tra lại sau khắc phục. Thông tin đăng nhập và tài liệu nội bộ nên được trao đổi bằng kênh đã thống nhất với nhóm phụ trách. Không gửi mật khẩu hoặc dữ liệu khách hàng qua biểu mẫu liên hệ công khai. Đọc báo cáo theo phạm vi đã thực hiện Khi nghiệm thu, doanh nghiệp nên đối chiếu báo cáo với kế hoạch: tài sản và vai trò nào đã được kiểm tra, có giới hạn truy cập nào, phát hiện nào cần ưu tiên và phần nào chưa được đánh giá. Kết quả kiểm thử phản ánh phạm vi cùng điều kiện tại thời điểm thực hiện. Số lượng phát hiện không phải thước đo duy nhất để so sánh hai đợt pentest khác phạm vi. Một báo cáo có ích cần giúp đội phụ trách hiểu vấn đề, tác động và hướng khắc phục, thay vì chỉ cung cấp danh sách cảnh báo. Trao đổi phạm vi kiểm thử với TMGS Doanh nghiệp có thể bắt đầu bằng mô tả hệ thống, chức năng ưu tiên và mục tiêu đánh giá. Xem thông tin dịch vụ Pentest hoặc liên hệ TMGS để trao đổi nhu cầu . Phương án thực hiện cần được thống nhất theo hệ thống và phạm vi cụ thể. Tài liệu tham khảo OWASP WSTG v4.2 — Introduction : nền tảng về cách tiếp cận kiểm thử ứng dụng. OWASP MASTG — Mobile Application Security Testing : giải thích mức thông tin trong black box, gray box và white box; tài liệu này tập trung vào ứng dụng di động. OWASP WSTG v4.2 — Reporting : phạm vi, giới hạn và cách trình bày kết quả đánh giá. Các ví dụ và câu hỏi lựa chọn phạm vi trong bài là hướng dẫn thực hành do TMGS biên soạn cho người đọc, không phải trích dẫn quy định hay tình huống khách hàng. Nguồn được đối chiếu ngày 27/10/2026.