Tin tức bảo mật mới từ Chrome trên Windows cho thấy Device Bound Session Credentials (DBSC) đã được Google đưa lên trạng thái general availability, nhằm giảm rủi ro session cookie theft và các kỹ thuật chiếm quyền phiên đăng nhập thường gặp trong môi trường doanh nghiệp.
Trước đây, DBSC chỉ có sẵn ở bản beta cho người dùng Google Workspace. Hiện tại, tính năng này được bật mặc định cho toàn bộ khách hàng Workspace, người dùng Individual và tài khoản Google cá nhân trên Chrome dành cho Windows.
DBSC thay đổi cách session cookie được sử dụng sau xác thực. Thay vì để cookie có thể tái sử dụng trên nhiều thiết bị, cơ chế này ràng buộc cookie vào thiết bị cụ thể mà người dùng đã đăng nhập. Nếu mã độc trích xuất được cookie từ endpoint bị xâm nhập, cookie đó sẽ gần như vô hiệu khi bị dùng trên máy khác.
Cách tiếp cận này làm tăng đáng kể chi phí vận hành cho các chiến dịch dựa trên token bị đánh cắp, đặc biệt trong bối cảnh cuộc tấn công mạng sử dụng cookie để duy trì truy cập sau khi đã vượt qua bước xác thực ban đầu.
Session cookie là tệp nhỏ mà website dùng để ghi nhớ người dùng đã xác thực. Trong thực tế, chúng là mục tiêu hấp dẫn của các họ infostealer trojans, vốn thường thu thập cookie, token và thông tin phiên làm việc để chiếm quyền truy cập mà không cần mật khẩu.
Kỹ thuật này thường được gọi là pass-the-cookie attack. Khi cookie hợp lệ bị đánh cắp, kẻ tấn công có thể đăng nhập lại vào phiên đang hoạt động, vượt qua multi-factor authentication trong nhiều kịch bản, vì phiên đã được xác thực từ trước.
DBSC không ngăn việc đánh cắp cookie ở cấp endpoint, nhưng làm giảm khả năng sử dụng lại cookie đó trên thiết bị khác. Đây là điểm khác biệt quan trọng trong chuỗi phòng thủ sau xác thực, nơi rủi ro bảo mật thường tăng cao nếu phiên đăng nhập không được ràng buộc chặt với thiết bị gốc.
Khả năng tích hợp với Context-Aware Access
Google cũng mở rộng giá trị phòng thủ của DBSC bằng cách tích hợp với Context-Aware Access (CAA). Khi kết hợp hai cơ chế này, tổ chức có thể áp dụng chính sách truy cập chi tiết hơn dựa trên thuộc tính thiết bị, hành vi người dùng và tín hiệu môi trường.
Điều này bổ sung một lớp kiểm tra sau bước xác thực ban đầu, giúp giảm nguy cơ xâm nhập trái phép trong các trường hợp kẻ tấn công cố gắng duy trì phiên bằng token bị lộ. Với mô hình này, bảo mật không còn phụ thuộc hoàn toàn vào đăng nhập ban đầu mà được duy trì xuyên suốt vòng đời phiên.
Audit log và phát hiện bất thường
Quản trị viên Workspace có thể theo dõi các sự kiện ràng buộc DBSC trực tiếp trong security investigation tool và audit logs. Đây là nguồn dữ liệu hữu ích để phát hiện xâm nhập hoặc các dấu hiệu bất thường liên quan đến tính toàn vẹn của phiên.
Trong thực tế, các đội an ninh mạng nên dùng audit log để baseline hành vi bình thường của DBSC, sau đó đối chiếu với các mẫu truy cập lạ, ví dụ phiên bị tái sử dụng từ thiết bị không tương thích hoặc có biến động bất thường trong chuỗi xác thực.
- DBSC binding events: Sự kiện ràng buộc cookie với thiết bị.
- Audit logs: Nhật ký kiểm tra để theo dõi toàn vẹn phiên.
- Behavior deviation: Sai lệch so với hành vi chuẩn có thể chỉ ra session hijacking.
Triển khai mặc định và phạm vi áp dụng
DBSC không yêu cầu thao tác quản trị để bật thủ công. Tính năng này hoạt động mặc định và không thể tắt từ Admin console. Google bắt đầu triển khai dần từ 25/05/2026, áp dụng cho cả Rapid Release và Scheduled Release, với thời gian hiển thị đầy đủ dự kiến trong vòng 60 ngày.
Thông tin liên quan có thể tham khảo thêm tại tài liệu công bố của Google Workspace: Google Workspace Updates.
Ở góc độ kỹ thuật, đây là một thay đổi kiến trúc đáng chú ý trong tin bảo mật mới nhất về xác thực sau đăng nhập. Thay vì chỉ dựa vào kiểm soát biên hoặc MFA tại thời điểm login, DBSC kéo cơ chế tin cậy xuyên suốt toàn bộ vòng đời phiên.
Ảnh hưởng đến hệ thống và rủi ro bảo mật
DBSC làm giảm bề mặt tấn công đối với các kỹ thuật dựa trên cookie bị đánh cắp, từ đó hạn chế khả năng di chuyển ngang và duy trì truy cập sau khai thác. Đây là điểm quan trọng với hệ thống doanh nghiệp nơi hệ thống bị xâm nhập thường không bị phát hiện ngay trong giai đoạn đầu.
Với các đội vận hành, việc theo dõi trạng thái phiên và đối chiếu audit log sẽ hỗ trợ phát hiện tấn công sớm hơn. Nếu thấy cookie bị ràng buộc không khớp với thiết bị gốc, đó có thể là chỉ báo cho hành vi chiếm quyền phiên hoặc nỗ lực tái sử dụng token trái phép.
DBSC không thay thế hoàn toàn các lớp kiểm soát khác như MFA, EDR hay chính sách truy cập theo ngữ cảnh. Tuy nhiên, trong chuỗi bảo mật thông tin, đây là một biện pháp giảm thiểu hiệu quả đối với mối đe dọa liên quan đến session hijacking và token replay.
Điểm chính cần theo dõi trong vận hành
- DBSC đang được bật mặc định trên Chrome for Windows.
- Cookie được ràng buộc theo thiết bị, giảm khả năng tái sử dụng trên máy khác.
- Hỗ trợ phát hiện các dấu hiệu session hijacking qua audit logs.
- Tích hợp với Context-Aware Access để tăng mức kiểm soát truy cập.
- Không cần bật thủ công và không thể vô hiệu hóa từ Admin console.
Góc nhìn kỹ thuật về bảo vệ sau xác thực
Trong môi trường có rủi ro an toàn thông tin cao, việc một phiên đăng nhập vẫn có thể bị lạm dụng sau khi MFA hoàn tất là vấn đề phổ biến. DBSC giải quyết trực tiếp lớp rủi ro này bằng cách gắn cookie với bối cảnh thiết bị, thay vì chỉ xác minh người dùng tại thời điểm đăng nhập.
Điều đó đặc biệt quan trọng với các kịch bản xâm nhập mạng dựa trên mã độc đánh cắp thông tin. Khi cookie không còn có thể sao chép và sử dụng linh hoạt, khả năng duy trì chỗ đứng của kẻ tấn công sẽ bị suy giảm rõ rệt.
Đối với đội ngũ quản trị, ưu tiên hiện tại là rà soát audit log, chuẩn hóa baseline hành vi DBSC và so khớp các phiên bất thường. Cách làm này giúp tăng năng lực phát hiện xâm nhập mà không cần thay đổi quy trình đăng nhập của người dùng.
