Chia sẻ công việc trình duyệt mà không chia sẻ thông tin xác thực thô

Nhóm thường nói cần “chia sẻ đăng nhập” khi nhu cầu thật hẹp hơn: duyệt bản nháp, cập nhật cửa hàng được phép, tái hiện lỗi khu vực hoặc tiếp tục quy trình hỗ trợ. Bắt đầu từ nhiệm vụ tạo nhiều lựa chọn hơn bắt đầu từ mật khẩu.

Những gì được tính là thông tin xác thực thô

Ví dụ rõ nhất là mật khẩu, mã khôi phục, khóa gốc tạo mật khẩu một lần, khóa riêng và mật khẩu proxy. Công việc trình duyệt còn có thông tin xác thực ít thấy hơn:

• cookie xác thực và mã phiên;
• token truy cập, làm mới OAuth;
• bản ghi trình quản lý mật khẩu và dữ liệu tự động điền;
• khóa riêng passkey hoặc quyền vào bộ xác thực giữ khóa;
• dữ liệu thiết bị tin cậy và khôi phục; và
• kho hồ sơ chứa bất kỳ phần nào ở trên.

Hướng dẫn phiên NIST mô tả phiên trình duyệt là sự liên tục dựa vào nắm giữ bí mật phiên. Hướng dẫn quản lý phiên OWASP làm rõ hệ quả: khi còn hiệu lực, token phiên có thể tương đương phương thức xác thực mạnh nhất đã tạo nó.

Gói hồ sơ mã hóa phía máy khách chỉ che giá trị thông tin xác thực khỏi nhà cung cấp lưu trữ khi nhà cung cấp không giữ khóa giải mã. Nó cũng giảm lộ trước người xem tình cờ. Sau khi thiết bị người nhận có quyền giải mã và mở hồ sơ, trình duyệt vẫn sử dụng được phiên. Bàn giao đã chuyển quyền hành động dù người nhận chưa từng đọc cookie.

Tách nhiệm vụ khỏi quyền

Trước khi chọn cách chia sẻ, viết tuyên bố truy cập ngắn:

Người thao tác A được chỉ định có thể làm hành động B trên tài nguyên C, từ thiết bị D được duyệt, đến thời điểm E, với quy tắc phê duyệt và audit F.

Câu đó làm lộ quyền không cần thiết. Nếu nhiệm vụ là “duyệt bản nháp này”, phiên quản trị đầy đủ là quá mức. Nếu dịch vụ đã có vai trò người duyệt, chia sẻ dữ liệu trình duyệt thêm rủi ro mà không thêm khả năng.

Kiến trúc Zero Trust của NIST đề xuất truy cập tài nguyên riêng theo từng phiên với quyền tối thiểu cho nhiệm vụ. Nguyên tắc áp dụng mà không cần mua sản phẩm gắn nhãn “zero trust”. Đây là phép thử thiết kế hữu ích cho mọi lần bàn giao trình duyệt.

Ưu tiên các mô hình theo thứ tự

1. Quyền cá nhân tại dịch vụ đích

Dùng tính năng nhóm, tổ chức, vai trò, ủy quyền hoặc phê duyệt của chủ website/ứng dụng nếu có. Mỗi người xác thực bằng tài khoản và bộ xác thực riêng. Dịch vụ có thể thực thi quyền, gắn hành động với người thực hiện, áp dụng kiểm soát rủi ro và thu hồi một người không cần đổi thông tin xác thực của tất cả.

Đây thường là mô hình mạnh nhất vì quyền nằm nơi hiểu được hành động. Trình quản lý browser không thể tin cậy biến phiên quản trị dùng chung của site thành vai trò người duyệt cấp site.

Tài khoản chung, tài khoản nhóm giảm trách nhiệm cá nhân. NIST SP 800-53 Sửa đổi 5 khuyên tổ chức hạn chế sử dụng và đặt điều kiện rõ trước khi cho phép.

2. Ủy quyền theo phạm vi từ dịch vụ đích

Khi dịch vụ có OAuth hoặc giao thức ủy quyền khác, chỉ cấp máy khách hoặc tác nhân đúng tài nguyên, hành động, thời hạn cần thiết. RFC 9700 đề xuất quyền token tối thiểu và giới hạn bên nhận token vào máy chủ tài nguyên dự kiến.

Ưu tiên quyền ngắn hạn, thu hồi được, giới hạn đúng bên nhận. Token ràng buộc bên gửi giảm phát lại khi token rò rỉ, nhưng không giúp nếu kẻ tấn công lấy cả token lẫn khóa đi kèm. Thiết bị, phần mềm máy khách vẫn nằm trong phạm vi đe dọa.

Ủy quyền đặc biệt hữu ích cho tự động hóa: script nhận quyền thao tác xác định mà không nhận mật khẩu hoặc phiên browser chung của người. Sự kiện audit cần nêu người khởi tạo, tác nhân được ủy quyền, tài nguyên, phạm vi và kết quả.

3. Dùng bí mật được lưu qua trung gian

Một số dịch vụ cũ chỉ có thông tin xác thực dùng chung. Bộ trung gian kiểm soát hoặc trình quản lý mật khẩu có thể giảm sao chép bằng cách cho luồng trình duyệt được duyệt dùng bí mật mà không hiện trong chat, phiếu việc, tài liệu hoặc đầu ra thường.

Điều này cải thiện việc giữ, thay mới và rà soát truy cập, nhưng không sửa mô hình tài khoản của dịch vụ. Sau đăng nhập, mọi người có thể vẫn hành động dưới cùng danh tính site. Phiên sinh ra vẫn nhạy cảm và cần thời gian hết hạn, thu hồi, kiểm soát thiết bị riêng.

Hướng dẫn quản lý bí mật OWASP đề xuất quyền chi tiết, tiếp xúc tối thiểu của người với giá trị bí mật, kiểm soát vòng đời và audit ai yêu cầu, dùng bí mật. Sản phẩm browser nên tích hợp bằng tham chiếu không lộ nội dung khi có thể, thay vì thành kho bí mật đa năng khác.

4. Bàn giao phiên trình duyệt được bảo vệ

Chỉ dùng hồ sơ đã xác thực chung khi dịch vụ không có ủy quyền đủ dùng và công việc được phép thực sự cần phiên liên tục. Đây là dạng bàn giao thông thường rủi ro cao nhất vì người nhận có khả năng hành động qua tài khoản đang hoạt động.

Kiểm soát tối thiểu gồm:

• chủ sở hữu rõ và người nhận được duyệt;
• nhiệm vụ, tài nguyên, thời điểm hết hạn được nêu;
• một bên ghi hoặc mô hình xung đột đã thử;
• mã hóa phía máy khách trước mọi tải lên cloud;
• cấp quyền thiết bị người nhận và bảo vệ cục bộ;
• khóa ngăn làm đồng thời không rõ trách nhiệm;
• sự kiện audit cho cấp, tải xuống, mở, hành động nhạy cảm, đóng, thu hồi và phục hồi;
• giao diện thường trả trạng thái đã che thay vì cookie/token; và
• kế hoạch thu hồi phiên tại dịch vụ đích.

Mô hình này có thể bảo vệ giá trị khỏi sao chép tình cờ, và khỏi nhà cung cấp cloud nếu nhà cung cấp không có khóa giải mã. Nó không khiến dịch vụ phân biệt hai người dùng cùng tài khoản đã xác thực. Nó cũng không bảo vệ phiên trước mã độc, tiện ích ác ý hoặc người nhận có quyền nhưng lạm dụng quyền được cấp.

5. Chuyển thông tin xác thực thô

Sao chép mật khẩu, cookie, mã khôi phục, passkey hoặc kho hồ sơ vào tin nhắn, bảng tính, phiếu việc, script hoặc bản xuất không bảo vệ tạo bí mật tồn tại lâu, không rõ số bản sao và khó thu hồi. Hãy tránh.

Nếu quy trình cũ ngoại lệ cần chuyển, xử lý theo thủ tục thông tin xác thực được tổ chức duyệt, giảm người nhận và thời gian, rồi đổi hoặc thu hồi sau đó. Đừng xem mã hóa tin nhắn thay thế trách nhiệm cá nhân hoặc bản ghi mọi bản sao.

So sánh quyền, không chỉ sự tiện lợi

Mô hình	Dịch vụ xác định người thao tác	Phạm vi khớp nhiệm vụ	Ranh giới thu hồi	Rủi ro còn lại chính
Thành viên cá nhân tại dịch vụ	Thường có	Thường mạnh nhất	Gỡ một thành viên hoặc vai trò	Quyền dịch vụ quá rộng
Token ủy quyền theo phạm vi	Có thể thể hiện người và máy khách	Mạnh nếu scope, bên nhận hẹp	Thu hồi quyền hoặc token	Token, máy khách hoặc khóa bị xâm phạm
Đăng nhập chung qua trung gian	Thường không sau đăng nhập	Bị giới hạn bởi tài khoản chung	Đổi bí mật, kết thúc phiên	Danh tính site chung và phiên còn hoạt động
Phiên browser mã hóa	Thường không tại dịch vụ	Cấp hồ sơ, thường rộng	Thu hồi chia sẻ và phiên đích	Thiết bị người nhận dùng được toàn quyền phiên
Bản sao thông tin xác thực thô	Không có danh tính cá nhân đáng tin	Thường rộng	Tìm bản sao, đổi và kết thúc phiên	Bản sao không rõ, trách nhiệm yếu

Bảng giải thích vì sao “không ai thấy mật khẩu” là tiêu chí thành công chưa đủ. Điều quan trọng là người nhận dùng được bao nhiêu quyền, trong bao lâu và hệ thống nào thu hồi được.

Passkey cải thiện xác thực nhưng cần lưu ý khi chia sẻ

WebAuthn tạo thông tin xác thực khóa công khai theo dịch vụ. Đặc tả WebAuthn Level 3 nói bộ xác thực giữ khóa riêng; script site nhận kết quả có chữ ký, không nhận khóa riêng. Khi triển khai đúng, cơ chế cung cấp xác thực chống phishing.

Passkey không tự tạo vai trò nhóm. Dịch vụ có thể đăng ký thông tin xác thực riêng cho mỗi thành viên, giữ truy cập cá nhân. Nhà cung cấp passkey cũng có thể hỗ trợ đồng bộ hoặc chia sẻ khóa. NIST SP 800-63B-4 công nhận mô hình và nêu rủi ro như dùng khóa trái phép, lan ra nhiều thiết bị, hạ tầng đồng bộ bị xâm phạm, khó thu hồi.

Với nhóm được phép, ưu tiên mỗi người một tài khoản dịch vụ và bộ xác thực riêng. Nếu passkey chung là mô hình duy nhất được hỗ trợ, xem đó là bộ xác thực chung, ghi ai được nhận trên thiết bị quản lý nào và kiểm chứng cách hiển thị, thu hồi, phục hồi khóa. Dịch vụ vẫn có thể ghi mọi hành động dưới một tài khoản.

Xác định bàn giao như một hợp đồng

Bàn giao có kiểm soát cần trả lời trước khi chuyển dữ liệu:

1. Ai thực hiện? Dùng danh tính tổ chức có tên, không dùng nhãn người thao tác chung.
2. Ai cho phép? Ghi chủ sở hữu hoặc quyết định chính sách mà không lưu bí mật phê duyệt.
3. Chia sẻ gì? Nêu hồ sơ, nhiệm vụ. Tránh liệt kê cookie, thông tin xác thực thô.
4. Người nhận được làm gì? Tách quyền mở, sửa, xuất, tự động hóa, chia sẻ, quản trị.
5. Được chạy ở đâu? Giới hạn thiết bị đã đăng ký, tin cậy và phù hợp dữ liệu.
6. Trong bao lâu? Đặt hết hạn, đóng phiên nhàn rỗi.
7. Hai bên được ghi không? Chỉ một bên hoạt động trừ khi hành vi xung đột đã được thiết kế, kiểm thử chủ đích.
8. Ghi gì? Ghi người, thiết bị, tham chiếu hồ sơ, thao tác, kết quả, thời gian. Mặc định loại giá trị bí mật và nội dung trang.
9. Thu hồi thế nào? Bao phủ cả quyền chia sẻ browser và phiên dịch vụ đích.
10. Khôi phục thế nào? Giữ phiên bản tốt gần nhất mà không vô tình phục hồi quyền đã thu hồi.

Mã hóa thuộc hợp đồng này: bảo vệ dữ liệu khi lưu hoặc truyền. Cấp quyền quyết định ai được tiếp cận đường giải mã. Tin cậy thiết bị, cô lập cục bộ bảo vệ lúc dùng. Audit hỗ trợ trách nhiệm và điều tra. Không kiểm soát nào thay được kiểm soát khác.

Giữ tự động hóa ngoài ranh giới bí mật

API, SDK, CLI và tác nhân thường cần mở hồ sơ hoặc làm thao tác vòng đời được duyệt. Hiếm khi cần giá trị cookie, mật khẩu, passkey, thông tin xác thực proxy hoặc kho hồ sơ thô.

Giao diện hẹp có thể nhận tham chiếu hồ sơ hoặc bí mật không lộ nội dung và trả:

• thao tác có được cho phép không;
• trạng thái đã che như sẵn sàng, bị khóa, hết hạn hoặc đã thu hồi;
• tham chiếu tiến trình/phiên có thời hạn;
• lỗi có cấu trúc và bước khôi phục; và
• tham chiếu sự kiện audit.

Không trả thông tin xác thực chỉ vì bên gọi được mở hồ sơ. Xuất, chia sẻ hàng loạt hoặc thao tác chứa bí mật cần chính sách riêng và khi phù hợp, phê duyệt rõ.

Nội dung site và đầu vào tự động hóa vẫn không tin cậy. Chỉ dẫn trên trang không được thuyết phục tác nhân lộ dữ liệu phiên qua log, đầu ra công cụ, ảnh chụp hoặc kênh hỗ trợ.

Thu hồi có hai lớp

Gỡ cộng tác viên khỏi không gian browser ngăn quyền truy cập trong tương lai qua không gian đó. Nó không chứng minh phiên dịch vụ đích đã vô hiệu. Thiết bị có thể đã giữ dữ liệu giải mã; phiên sao chép hoặc vẫn chạy có thể tiếp tục.

Khi truy cập kết thúc bình thường:

1. thu hồi quyền nhóm và kết thúc quyền giữ hồ sơ;
2. xóa dữ liệu cục bộ mã hóa theo chính sách lưu giữ;
3. kết thúc phiên liên quan ở dịch vụ đích khi hỗ trợ;
4. gỡ tư cách thành viên hoặc quyền ủy quyền tại dịch vụ; và
5. giữ bằng chứng audit đã che trong thời hạn được duyệt.

Khi nghi xâm phạm, còn cần cách ly phiên bản bị ảnh hưởng, thu hồi phiên/token hoạt động, gỡ bộ xác thực trái phép, đổi bí mật chung bị lộ và xem sự kiện audit. Phục hồi snapshot cũ có thể đưa lại bí mật phiên cũ, nên khôi phục phải tôn trọng trạng thái thu hồi.

Giới hạn vẫn còn sau bàn giao cẩn thận

• Mã hóa phía máy khách bảo vệ dữ liệu lưu, truyền, nhưng đầu cuối có quyền phải giải mã phần browser cần.
• Khóa browser kiểm soát đồng thời ở cấp sản phẩm, không phải mọi hành động tại dịch vụ.
• Phiên chung thường cho dịch vụ một danh tính tài khoản dù sản phẩm browser có audit phong phú hơn.
• Thiết bị hoặc tiện ích bị xâm phạm có thể hành động qua phiên hợp lệ mà không lấy mật khẩu đọc được.
• Thu hồi quyền không gian và thu hồi phiên website là thao tác riêng.
• Điều khoản dịch vụ, hợp đồng khách hàng và luật áp dụng vẫn quyết định có được ủy quyền quy trình hay không.
• Một số dịch vụ không có thay thế an toàn cho truy cập cá nhân. Khi đó giảm phạm vi hoặc từ chối bàn giao có thể là kết quả có trách nhiệm.

RFC 6265 mô tả cookie là quyền tự gắn vào yêu cầu: browser có thể gắn cookie dù bên gây ra yêu cầu chưa bao giờ biết giá trị. Đây là giới hạn trung tâm của chia sẻ phiên. Giấu thông tin xác thực giảm tiết lộ; không giảm quyền browser thực thi được.