Đánh giá trình duyệt nhóm: danh sách kiểm tra thực tế

Xác định quyết định trước khi mở trang giá

Đánh giá hữu ích bắt đầu từ công việc, không phải danh sách nhà cung cấp. Ghi:

• quy trình được phép và hệ thống cho phép chúng;
• số người, hồ sơ lưu, hồ sơ đồng bộ, phiên chạy đồng thời;
• hệ điều hành, kiến trúc bộ xử lý cần hỗ trợ;
• nền tảng trình duyệt, tiện ích, proxy, nhà cung cấp danh tính, máy khách tự động hóa bắt buộc;
• nghĩa vụ nơi lưu, thời hạn giữ, xuất, xóa, audit dữ liệu;
• mục tiêu thời gian phục hồi, mức mất dữ liệu chấp nhận được;
• nhu cầu trợ năng của người vận hành, quản trị;
• ngân sách, kỳ thanh toán, hỗ trợ, điều kiện rời dịch vụ; và
• quy trình bị cấm mà sản phẩm không được tạo điều kiện cho nhóm.

Tách loại tài nguyên. Gói có 500 hồ sơ lưu, 100 hồ sơ cloud, năm thành viên và mười phiên đồng thời không cung cấp 500 phiên nhóm đồng thời. Đổi mỗi giới hạn sang đơn vị quy trình thực sự tiêu thụ.

Sau đó xác định điều kiện bắt buộc không thể thỏa hiệp. Bộ phổ biến gồm:

1. build browser được hỗ trợ, cập nhật;
2. không âm thầm hỏng hồ sơ hoặc ghi đồng thời;
3. danh tính riêng, quyền tối thiểu thu hồi được;
4. không bí mật thô trong log thường hay đầu ra tự động hóa;
5. bằng chứng audit dùng được;
6. đường khôi phục, rời dịch vụ đã thử; và
7. sử dụng hợp pháp, được phép, đúng điều khoản liên quan.

Đừng đưa điều kiện bắt buộc thất bại vào điểm trung bình để làm mờ nó. Giao diện đẹp không bù được bộ cập nhật chưa xác minh hoặc khôi phục làm mất dữ liệu.

Dùng thang bằng chứng đơn giản

Với từng mục, ghi kết quả và bằng chứng mạnh nhất có được.

Kết quả

• Đạt: yêu cầu đã được chứng minh trong môi trường thử xác định.
• Cần lưu ý: hành vi trái yêu cầu hoặc tạo đánh đổi đáng kể.
• Chưa xác minh: thiếu bằng chứng, không truy cập được, đã cũ hoặc quá mơ hồ.
• Không áp dụng: yêu cầu thực sự không liên quan, có lý do ghi lại.

Bằng chứng

1. Tuyên bố công khai: nội dung marketing hoặc bán hàng.
2. Tài liệu kỹ thuật: tài liệu sản phẩm, bảo mật, API hoặc hỗ trợ có phiên bản.
3. Demo đã quan sát: nhà cung cấp trình diễn trực tiếp theo kịch bản của bạn.
4. Thử có kiểm soát: nhóm tái hiện bằng dữ liệu dùng thử, ghi phiên bản và kết quả.
5. Bằng chứng độc lập hoặc hợp đồng: đánh giá có phạm vi, cam kết ký hoặc điều khoản hỗ trợ bao phủ yêu cầu.

Mức cao hơn không tự tốt hơn trong mọi trường hợp. Báo cáo độc lập có thể loại browser desktop, còn thử kiểm soát kiểm tra trực tiếp được. Ghi phạm vi, ngày, phiên bản, giới hạn mỗi artefact.

1. Trạng thái sản phẩm và giới hạn tuyên bố

• □ Có build thật cài được cho mọi nền tảng, kiến trúc cần không?
• □ Nhà cung cấp nêu được phiên bản ứng dụng, browser, ngày phát hành hiện tại không?
• □ Beta, preview, thử nghiệm, phát hành rộng rãi được phân biệt không?
• □ Tài liệu và thử thực tế thống nhất giới hạn, hành vi không?
• □ Tuyên bố bảo mật, sẵn sàng, mã hóa, hiệu năng có giới hạn theo thành phần, bằng chứng cụ thể không?
• □ Có công khai giới hạn, quy trình không hỗ trợ, quy tắc kết thúc hỗ trợ không?
• □ Có tránh bảo đảm vô hình, tài khoản luôn sống hoặc quyền truy cập bên thứ ba không?

Giữ installer, màn hình phiên bản, ghi chú phát hành và tài liệu vào ngày đánh giá. Câu trả lời bán hàng không có tham chiếu ổn định vẫn là tuyên bố, không phải hành vi đã xác minh.

2. Cô lập và toàn vẹn hồ sơ

Định nghĩa sản phẩm gọi gì là hồ sơ: thư mục dữ liệu lâu dài, context tạm, kho đồng bộ, phiên từ xa hay tập cài đặt. Chúng không tương đương.

Chromium mô tả thư mục dữ liệu và cách chọn đường riêng, cũng lưu ý trường hợp hai instans không được dùng chung. Dùng tài liệu upstream làm đầu, rồi yêu cầu bằng chứng sản phẩm.

• □ Mỗi hồ sơ có ranh giới lưu trữ, tiến trình rõ không?
• □ Có ngăn hai bên ghi mở cùng dữ liệu thay đổi được không?
• □ Cookie, lưu trữ, cache, lịch sử, tiện ích, tải xuống, quyền, tùy chọn được tách đúng tài liệu không?
• □ Phiên tạm và hồ sơ lâu dài có nhãn khác không?
• □ Mở sạch chỉ dùng đúng dữ liệu dự kiến không?
• □ Mở lại giữ đúng dữ liệu sản phẩm hứa không?
• □ Quyền tiện ích, nguồn cài có được kiểm soát không?
• □ Hồ sơ nhập có bị xem không tin cậy, kiểm tra trước dùng không?
• □ Có cách ly hồ sơ hỏng/không tương thích mà không ghi đè bản tốt không?

Thử phải có kiểm tra chéo hồ sơ. Đặt dấu hiệu không gây hại ở A, xác nhận vắng ở B, mở lại cả hai và lặp sau cập nhật ứng dụng. Dùng tài khoản thử, dữ liệu giả lập.

3. Cập nhật browser, sandbox và phân phối

Trình duyệt là thành phần có ảnh hưởng đến bảo mật và cần được bảo trì liên tục. Từ Chrome 153, phát hành ngày 8 tháng 9 năm 2026, Chrome chuyển sang chu kỳ phát hành Stable hai tuần một lần. Nhịp phát hành này không quy định chính xác mức dịch vụ của từng nhà cung cấp, nhưng cho thấy vì sao tuyên bố “dựa trên Chromium” là chưa đủ nếu không có bằng chứng về phiên bản và các bản cập nhật.

• □ Có ánh xạ build tới đúng phiên bản upstream không?
• □ Có mục tiêu hoặc lịch sử công khai tiếp nhận bản vá không?
• □ Ai theo dõi phát hành, sửa khẩn upstream?
• □ Cập nhật ứng dụng/browser có chữ ký, xác thực độc lập với đường tải không?
• □ Xác minh được digest, nguồn gốc phát hành hoặc chuỗi quản lý tương đương không?
• □ Triển khai có theo đợt, theo dõi, dừng được không?
• □ Quay lại có tránh phiên bản không an toàn theo chính sách hiện tại không?
• □ Chuyển schema hồ sơ có thử đường nâng/hạ được hỗ trợ không?
• □ Sandbox vẫn bật khi dùng bình thường không?
• □ Nhà cung cấp giải thích được tiến trình ngoài sandbox/quyền cao và vì sao cần không?

Chromium mô tả sandbox là ranh giới hạn chế mã không tin cậy, áp dụng quyền tối thiểu cho mã trong đó và bộ điều khiển. Xem thiết kế sandbox, rồi yêu cầu cấu hình sản xuất thật. “Dùng Chromium” không chứng minh mọi biện pháp upstream còn bật.

The Update Framework hữu ích cho toàn vẹn cập nhật vì xử lý rõ kho phát hành, khóa ký bị xâm phạm. Provenance SLSA định nghĩa thông tin kiểm chứng được về nơi, lúc, cách tạo artefact. Nhà cung cấp không bắt buộc dùng đúng dự án, nhưng phải giải thích danh tính artefact, khóa bị xâm phạm, quay lại, đóng băng và nguồn gốc build.

4. Danh tính, thiết bị và quyền tối thiểu

NIST SP 800-53 Sửa đổi 5 tổ chức các nhóm truy cập, audit, xác thực, dự phòng, ứng phó, rủi ro chuỗi cung ứng. Dùng để đặt câu hỏi, không coi phù hợp khung là chứng minh triển khai.

• □ Mỗi người có danh tính riêng thay đăng nhập nhóm chung không?
• □ Có xác thực nhiều yếu tố, buộc được với quản trị và vai trò nhạy cảm không?
• □ Có tùy chọn mạnh hơn, chống phishing khi mức rủi ro yêu cầu không?
• □ Liên kết nhà cung cấp danh tính nếu cần mà không bỏ quyền sản phẩm được không?
• □ Vai trò đủ tách xem, mở, sửa, chia sẻ, xuất, xóa, thanh toán, quản trị không?
• □ Giới hạn được theo tổ chức, không gian, thư mục, tập hồ sơ không?
• □ Thu hồi nhanh thiết bị, phiên, người, thông tin xác thực dịch vụ, lời mời được không?
• □ Tài khoản dịch vụ có danh tính, hết hạn, scope, giới hạn tốc độ riêng không?
• □ Đổi quyền, cấp quyền thất bại có trong audit không?
• □ Kết thúc truy cập không cần đổi mật khẩu chung không?

Xem NIST SP 800-63B-4, hoàn tất ngày 31/7/2025, cho thuật ngữ và mức bảo đảm hiện tại. Xác nhận tuyên bố bao phủ phần nào: đăng nhập web, mở khóa desktop, API cục bộ/cloud, khôi phục, hỗ trợ có thể dùng cơ chế khác.

5. Dữ liệu nhạy cảm và ranh giới tin cậy

Vẽ luồng dữ liệu: ứng dụng quản lý desktop, tiến trình browser, dịch vụ cục bộ, điều khiển cloud, kho đồng bộ, bộ cập nhật, báo crash, hỗ trợ, tích hợp bên thứ ba. Với mỗi ranh giới hỏi gì đi qua, vì sao.

• □ Nội dung nào mặc định ở máy?
• □ Metadata, nội dung nhạy cảm nào tải lên khi bật đồng bộ?
• □ Mã hóa ở đâu, ai lấy được khóa giải mã?
• □ Khóa cục bộ bảo vệ, sao lưu, thay, khôi phục thế nào?
• □ Quản trị tổ chức, hỗ trợ, người vận hành hạ tầng, máy khách tự động hóa đọc được gì?
• □ Cookie, mật khẩu, thông tin xác thực proxy, bí mật hai yếu tố, khóa có bị loại khỏi UI thường, log, telemetri, API, đầu ra tác nhân không?
• □ Báo crash/chẩn đoán xem trước được, che dữ liệu, xét đồng ý và giới hạn giữ không?
• □ Hỗ trợ làm được không cần kho hồ sơ thô hoặc thông tin xác thực không?
• □ Tiện ích nhập, kho, tải browser, metadata cập nhật có được coi không tin cậy không?
• □ Xóa có định nghĩa cho bản cục bộ, đối tượng cloud, sao lưu, log, artefact hỗ trợ không?

Không nhận “được mã hóa” là câu trả lời đủ. Ghi loại dữ liệu, nơi, ranh giới mã hóa, người giữ khóa, đường phục hồi và trường hợp có bản rõ.

6. Cộng tác và audit

• □ Trách nhiệm hồ sơ rõ khi phân công, bàn giao không?
• □ Ngăn hoặc xử lý có hiển thị việc sửa đồng thời không?
• □ Lời mời, đổi vai trò, mở, dừng, chia sẻ, xuất, xóa, gọi tự động hóa, khôi phục được ghi không?
• □ Sự kiện nêu người thật, tác vụ ủy quyền, tài nguyên, giờ, quyết định, kết quả không?
• □ Thay cấu hình quan trọng có giá trị trước/sau, che bí mật không?
• □ Đồng hồ, múi giờ, thứ tự và mã yêu cầu không mơ hồ không?
• □ Có tài liệu quyền audit, định dạng xuất, giữ, xóa không?
• □ Quản trị viên có sửa/xóa chính bản ghi dùng đánh giá mình được không?
• □ Nhóm xuất log tới hệ thống giám sát/điều tra được không?
• □ Khi đích audit mất, log tiếp tục, đệm an toàn hay chặn hành động?

OWASP khuyên ghi thất bại quyền, hành động rủi ro cao, khi nào/đâu/ai/gì, kiểm soát truy cập và tránh bí mật. Áp dụng với sự kiện xuất thực tế, không chỉ ảnh trang bảo mật.

7. Khôi phục, gián đoạn và rời dịch vụ

Tuyên bố về sao lưu chưa đủ đến khi thử khôi phục. NIST CSF 2.0 nêu kết quả tạo, bảo vệ, duy trì, thử sao lưu và xác minh vật liệu, hệ thống được phục hồi.

• □ Tạo bản nhất quán mà vẫn tôn trọng khóa hồ sơ được không?
• □ Bản cục bộ, đồng bộ nhận diện và sắp thứ tự được không?
• □ Khôi phục bản chọn không phá bản hiện tại được không?
• □ Xác minh dữ liệu, tương thích browser trước dùng lại không?
• □ Điều gì xảy ra khi cưỡng bức dừng browser, mất mạng, hết đĩa, ngắt tải lên hoặc crash?
• □ Bản tốt cuối được bảo vệ trước sửa lỗi thất bại không?
• □ Gỡ thiết bị mất/bị thu hồi mà không mất đường khôi phục duy nhất được không?
• □ Khóa/mã khôi phục được bảo vệ khỏi thất lạc và quyền quản trị vô hạn không?
• □ Xuất dữ liệu định dạng có tài liệu, kiểm chứng trước hủy dịch vụ được không?
• □ Có quy trình xóa/đóng tài khoản với thông tin giữ lại rõ không?

Chỉ thử bằng dữ liệu dùng thử trừ khi nhà cung cấp, quy trình thay đổi của bạn cho phép diễn tập sản xuất rõ. Ghi thời gian, dữ liệu mất, bước thủ công, cảnh báo, phiên bản. Demo thành công một hồ sơ nhỏ không chứng minh hiệu năng/toàn vẹn quy mô sản xuất.

8. Tự động hóa và công cụ phát triển

• □ Có thao tác nghiệp vụ có phiên bản thay vì quyền tệp/tiến trình không hạn chế không?
• □ API, CLI, SDK, Playwright, CDP, WebDriver, webhook, tác nhân được ghi riêng không?
• □ Có ma trận browser/máy khách chính xác không?
• □ Giới hạn thông tin xác thực theo tenant, hồ sơ, hành động, bên nhận, hạn, tốc độ, phí được không?
• □ Hành động phá hủy, hàng loạt, công khai, chứa bí mật, tạo phí cần chính sách/duyệt mạnh hơn không?
• □ Bản xem trước gắn đúng yêu cầu thực thi không?
• □ Lệnh sửa có idempotency hoặc nói rõ kết quả chưa biết không?
• □ Hủy, tiếp tục an toàn thao tác dài được không?
• □ Thu hồi có hiệu lực khi tác vụ đang chạy không?
• □ Truy vết quyết định tự động trong cùng audit với người được không?
• □ Đầu ra thường hữu ích mà không trả dữ liệu phiên thô được không?
• □ Lỗi đủ cụ thể để phục hồi, không lộ bí mật không?

Thử đường từ chối. Token chỉ đọc phải không mở được hồ sơ. Token giới hạn hồ sơ phải bị chặn ở thư mục khác. Thông tin xác thực hết hạn không được âm thầm làm mới thành quyền rộng hơn. Tác nhân không được biến yêu cầu bị từ chối thành quản trị duyệt bằng viết lại yêu cầu.

9. Trải nghiệm và khả năng tiếp cận

• □ Bàn phím tới, thao tác, rời mọi điều khiển, dialog, bảng, menu, hành động được không?
• □ Tiêu điểm rõ, đúng thứ tự sau điều hướng, lỗi, đổi modal không?
• □ Nhãn, lỗi, trạng thái, xác nhận phá hủy dùng được với trình đọc màn hình không?
• □ Phóng to, tăng chữ vẫn dùng được không?
• □ Màu, chuyển động, thời hạn chỉnh được hoặc không thiết yếu không?
• □ Phân biệt tổ chức, hồ sơ, proxy, môi trường, rủi ro không chỉ nhờ màu được không?
• □ Xem xét thao tác hàng loạt không bị ép qua bảng dày khó tiếp cận không?
• □ Hành vi native, thông báo, chọn tệp, nhắc xác thực, dialog cập nhật nhất quán không?

WCAG 2.2 có tiêu chí web kiểm thử được: bàn phím, thứ tự/hiển thị tiêu điểm, kích thước mục tiêu, nhận diện lỗi, xác thực. Desktop có thể trộn native/web, nên kết hợp tiêu chuẩn liên quan với công nghệ trợ giúp trên mỗi hệ điều hành hỗ trợ.

10. Phù hợp thương mại và vận hành

• □ Thành viên, hồ sơ lưu/đồng bộ, dung lượng, lưu lượng, phiên đồng thời, tốc độ API, tác vụ tự động, mức hỗ trợ có giá riêng rõ không?
• □ Giới hạn nào chặn cứng, tính vượt hoặc theo sử dụng hợp lý?
• □ Đổi thanh toán/công suất có thể không cần quản trị duyệt không?
• □ Giao thức proxy, xác thực, tiện ích, mạng hỗ trợ có tài liệu không?
• □ Hỗ trợ bao phủ lỗi cập nhật, hồ sơ hỏng, khôi phục lỗi, báo bảo mật, phục hồi tài khoản không?
• □ Trạng thái dịch vụ, thông báo sự cố, đường chuyển cấp có thật, được theo dõi không?
• □ Hợp đồng định nghĩa trả dữ liệu, xóa, đổi giá, đình chỉ, kết thúc không?
• □ Rời đi mà không mất bằng chứng chuyển đổi an toàn được không?

Tính chi phí theo đỉnh việc đồng thời, dữ liệu đồng bộ dự kiến, lượng tự động hóa, nhu cầu hỗ trợ. Ghi thuế, cam kết năm, vượt mức và công di chuyển. Đừng chỉ so con số hồ sơ lớn nhất trên trang giá.

Kế hoạch thử có kiểm soát

Dùng tài khoản thử, thông tin xác thực giả lập và hồ sơ tạo cho đánh giá. Không nhập cookie sản xuất chỉ để trông thật.

1. Ghi môi trường. Phiên bản app/browser, hệ điều hành, phần cứng, mạng, loại proxy, tiện ích, gói tài khoản, ngày.
2. Tạo hai vai trò, nhiều hồ sơ. Có quản trị, người hạn chế, thư mục riêng và ít nhất một hồ sơ người hạn chế không được vào.
3. Chạy việc thường. Mở, dùng, dừng, bàn giao, mở lại; ghi trạng thái dự kiến/thực.
4. Thử từ chối. Với danh tính hạn chế, thử hồ sơ ngoài quyền, xuất, đổi vai trò, lệnh tự động.
5. Thử gián đoạn. Với dữ liệu thử, ngắt bước dừng/đồng bộ bằng cách được hỗ trợ hoặc an toàn; kiểm tra khôi phục.
6. Khôi phục, so sánh. Đưa snapshot biết trước vào bản mới, kiểm toàn vẹn, giữ bản hiện tại đến nghiệm thu.
7. Thu hồi quyền. Gỡ người, thiết bị, phiên, thông tin xác thực dịch vụ; kiểm UI và API từ chối, xem audit.
8. Kiểm tra khả năng chuyển. Xuất dữ liệu được phép, xem định dạng, nhập lại vào đích thử nếu hỗ trợ, xác định phần thiếu.
9. Rà soát trợ năng. Làm nhiệm vụ lõi bằng bàn phím, công nghệ trợ giúp trên từng nền tảng cần.
10. Đối chiếu phí, tuyên bố. So sử dụng tài nguyên, phản hồi hỗ trợ với đề xuất, hợp đồng.

Mẫu bản ghi quyết định

Yêu cầu	Ưu tiên	Kết quả	Bằng chứng và ngày	Giới hạn/rủi ro	Người phụ trách, bước tiếp
Ví dụ: người thao tác không xuất được phiên	Bắt buộc	Đạt	Thử kiểm soát, bản X, YYYY-MM-DD	Chỉ API; chưa thử CLI	Người phụ trách bảo mật thử CLI

Kết thúc đánh giá bằng bốn danh sách rõ:

• điều kiện bắt buộc đạt với bằng chứng đủ;
• điểm cần lưu ý được người có tên chấp nhận, kèm ngày xem lại;
• mục chưa xác minh;
• điều kiện kích hoạt đánh giá lại: engine, nhà cung cấp danh tính, bộ cập nhật, giá hoặc định dạng hồ sơ mới.

Dấu hiệu đáng lo thường gặp

Tạm dừng quyết định khi:

• không xác định được phiên bản browser;
• dùng bình thường phải tắt sandbox;
• quản trị, tự động hóa dùng chung thông tin xác thực vĩnh viễn;
• bàn giao phụ thuộc chia cookie/mật khẩu thô;
• API xuất được bí mật UI nói bảo vệ;
• audit thiếu người hoặc không xuất được;
• “sao lưu” chỉ là có bản cloud, chưa chứng minh phục hồi;
• không giải thích được ghi gián đoạn hoặc dùng đồng thời;
• quy trình quan trọng khó tiếp cận, không thay thế;
• báo bảo mật phải gửi bí mật qua email thường; hoặc
• hứa không thể phát hiện, bảo đảm tài khoản vào được, né thực thi nền tảng.

“Chưa xác minh” không phải cáo buộc. Đó là mô tả chính xác bằng chứng thiếu. Giữ hiển thị đến khi nhà cung cấp bổ sung, nhóm thử hoặc người quyết định chấp nhận rủi ro.