Context-Aware Access trong Google Workspace: Khi xác thực cơ bản vẫn chưa đủ để vào cửa

Lời nói đầu

Hãy tưởng tượng một tình huống quen thuộc. Nhân viên của bạn bị lộ mật khẩu Google Workspace qua một trang phishing tinh vi. Kẻ tấn công có trong tay email và mật khẩu hợp lệ, thậm chí đã lừa được cả mã OTP. Chúng mở trình duyệt từ một máy chủ thuê ở nước ngoài, đăng nhập vào Gmail của công ty bạn, và toàn bộ hộp thư, tài liệu trên Drive, lịch họp nội bộ hiện ra trước mắt. Với mô hình xác thực truyền thống, câu chuyện kết thúc ở đó. Đúng tài khoản, đúng mật khẩu, nghĩa là đúng người -> Cửa mở.

Context-Aware Access ra đời để viết lại cái kết ấy. Trong kịch bản trên, hệ thống sẽ nhận ra rằng phiên đăng nhập này đến từ một quốc gia công ty chưa từng hoạt động, trên một thiết bị chưa từng được đăng ký quản lý, không có mã hóa ổ đĩa, và lập tức từ chối dù thông tin đăng nhập hoàn toàn chính xác. Danh tính chỉ là một mảnh ghép. Ngữ cảnh mới là bức tranh đầy đủ.

Bài viết này sẽ đi qua toàn bộ những gì bạn cần biết về Context-Aware Access trong Google Workspace, từ triết lý đằng sau nó, cách nó vận hành, đến kinh nghiệm triển khai thực tế sao cho không tự khóa mình ngoài cửa.

Từ tường lửa đến Zero Trust: câu chuyện đằng sau

Muốn hiểu Context-Aware Access, phải quay lại một thập kỷ trước với dự án nội bộ nổi tiếng của Google mang tên BeyondCorp. Sau sự cố tấn công Aurora năm 2009, Google đi đến một kết luận táo bạo: mô hình bảo mật kiểu lâu đài và hào nước đã chết. Trong mô hình cũ, mọi thứ bên trong mạng công ty được mặc định tin tưởng, mọi thứ bên ngoài bị nghi ngờ, và VPN là cây cầu duy nhất bắc qua hào. Vấn đề là một khi kẻ tấn công vượt qua được hào nước, chúng tự do di chuyển khắp lâu đài. Còn nhân viên hợp pháp thì khổ sở với VPN chậm chạp mỗi khi làm việc từ xa.

BeyondCorp lật ngược giả định đó: không tin tưởng bất kỳ ai chỉ vì vị trí mạng của họ. Mọi yêu cầu truy cập, dù đến từ văn phòng hay quán cà phê, đều phải được đánh giá dựa trên danh tính người dùng và trạng thái thiết bị tại đúng thời điểm đó. Đây chính là tinh thần của Zero Trust mà cả ngành sau này theo đuổi. Context-Aware Access là cách Google đóng gói triết lý BeyondCorp thành tính năng mà mọi quản trị viên Workspace có thể bật lên từ Admin console, không cần xây dựng hạ tầng phức tạp như Google từng làm cho chính mình.

Context-Aware Access thực chất là gì?

Nói ngắn gọn, đây là lớp kiểm soát truy cập cho phép quản trị viên định nghĩa các chính sách chi tiết quyết định ai được vào ứng dụng nào, trong điều kiện nào. Thay vì câu hỏi duy nhất “mật khẩu có đúng không”, hệ thống hỏi thêm một loạt câu hỏi khác trước khi mở cửa: Người này đang ở đâu? Kết nối từ dải IP nào? Thiết bị có được công ty quản lý không? Ổ đĩa đã mã hóa chưa? Hệ điều hành có đủ mới không? Màn hình có đặt khóa không?

Điều đáng chú ý là các chính sách này áp dụng cho cả thiết bị công ty lẫn thiết bị cá nhân, cả bản web trên máy tính, ứng dụng di động lẫn ứng dụng cài trên desktop. Người dùng không cần cài VPN, không cần thay đổi thói quen làm việc. Toàn bộ việc đánh giá diễn ra âm thầm ở phía Google mỗi khi có yêu cầu truy cập.

Về giấy phép, tính năng này thuộc nhóm cao cấp. Nó có mặt trong các gói Enterprise Standard và Enterprise Plus, Education Standard và Education Plus, Frontline Standard và Frontline Plus, Enterprise Essentials Plus, cùng với Cloud Identity Premium. Một điểm tinh tế mà nhiều quản trị viên bỏ qua: chính sách chỉ có hiệu lực với người dùng mang giấy phép thuộc các gói được hỗ trợ. Nếu tổ chức của bạn trộn lẫn nhiều loại giấy phép, những người dùng gói thấp hơn nằm trong cùng đơn vị tổ chức vẫn truy cập bình thường như thể chính sách không tồn tại. Đây là cái bẫy âm thầm tạo ra lỗ hổng trong tấm khiên mà bạn tưởng đã phủ kín.

Những tín hiệu ngữ cảnh mà hệ thống đọc được

Trái tim của Context-Aware Access là khả năng thu thập và đánh giá tín hiệu. Có thể chia chúng thành mấy nhóm chính.

Nhóm thứ nhất là tín hiệu mạng. Bạn có thể định nghĩa các dải IP tin cậy, chẳng hạn dải địa chỉ của văn phòng hoặc của hệ thống VPN công ty, rồi yêu cầu một số ứng dụng nhạy cảm chỉ được truy cập từ các dải này. Đi kèm là tín hiệu vị trí địa lý, cho phép giới hạn truy cập theo quốc gia. Một công ty chỉ hoạt động ở Việt Nam hoàn toàn có thể chặn mọi đăng nhập từ các quốc gia khác, cắt đứt phần lớn các cuộc tấn công chiếm tài khoản tự động vốn xuất phát từ hạ tầng ở nước ngoài.

Nhóm thứ hai là tín hiệu thiết bị, và đây mới là phần tạo nên sức mạnh thật sự. Hệ thống có thể kiểm tra thiết bị có bật mã hóa ổ đĩa không, có đặt khóa màn hình hoặc mật khẩu không, hệ điều hành thuộc loại nào và phiên bản tối thiểu bao nhiêu, thiết bị có thuộc sở hữu công ty không, có được duyệt bởi quản trị viên không, và có tuân thủ chính sách quản lý thiết bị di động của tổ chức không. Với máy tính, các tín hiệu này được thu thập qua Endpoint Verification, một tiện ích mở rộng của Chrome đóng vai trò như con mắt của hệ thống trên từng máy trạm. Không có Endpoint Verification, Google không có cách nào biết ổ đĩa của máy đó đã mã hóa hay chưa, nên việc phủ tiện ích này qua chính sách quản lý Chrome là bước nền tảng của mọi dự án triển khai nghiêm túc.

Nhóm thứ ba là các tín hiệu nâng cao dành cho những kịch bản khắt khe hơn. Bạn có thể giới hạn theo khung giờ và ngày trong tuần, chẳng hạn dữ liệu tài chính chỉ truy cập được trong giờ hành chính. Có thể yêu cầu độ mạnh của phiên xác thực, ví dụ bắt buộc người dùng đã xác minh bằng khóa bảo mật vật lý. Có thể đọc các thuộc tính của trình duyệt Chrome hoặc yêu cầu thiết bị ChromeOS đã được xác minh. Và với các tổ chức đã đầu tư vào hệ sinh thái bảo mật bên thứ ba, tín hiệu từ các đối tác trong liên minh BeyondCorp như các nền tảng quản lý thiết bị hay EDR bên ngoài cũng có thể được đưa vào phương trình đánh giá.

Access level: viên gạch xây nên chính sách

Trong mô hình của Google, đơn vị cấu hình cơ bản gọi là access level, tạm hiểu là một mức truy cập. Mỗi access level là tập hợp các điều kiện mô tả một ngữ cảnh được chấp nhận. Ví dụ bạn tạo một access level tên “Thiết bị chuẩn công ty” với ba điều kiện: thiết bị do công ty sở hữu, ổ đĩa đã mã hóa, và hệ điều hành từ một phiên bản nhất định trở lên. Một access level khác tên “Mạng văn phòng” chỉ chứa điều kiện về dải IP tin cậy.

Có hai chế độ tạo access level. Chế độ cơ bản cho phép ghép các điều kiện bằng giao diện kéo thả với logic và hoặc, đủ dùng cho đa số nhu cầu. Chế độ nâng cao mở ra ngôn ngữ biểu thức CEL, nơi bạn viết điều kiện dưới dạng biểu thức logic thuần túy, cho phép những tổ hợp phức tạp mà giao diện cơ bản không diễn đạt nổi, chẳng hạn kết hợp phủ định, so sánh phiên bản chi tiết hay tham chiếu tín hiệu bên thứ ba.

Sau khi có access level, bước tiếp theo là gán chúng vào phạm vi áp dụng. Một phạm vi là sự kết hợp giữa ứng dụng cần bảo vệ với đơn vị tổ chức hoặc nhóm người dùng chịu chính sách. Chính sự kết hợp linh hoạt này tạo nên độ chi tiết đáng giá: đội kỹ sư có thể truy cập Drive từ bất cứ đâu miễn là thiết bị đạt chuẩn, trong khi tài khoản của đối tác thuê ngoài chỉ mở được đúng một ứng dụng và chỉ từ dải IP đã đăng ký. Khi một người dùng nằm trong nhiều phạm vi chồng lấn, các access level được cộng dồn theo logic và, nghĩa là càng nhiều chính sách áp lên thì điều kiện càng chặt.

Một chi tiết vận hành quan trọng: việc đánh giá không chỉ diễn ra lúc đăng nhập. Hệ thống đánh giá lại ngữ cảnh liên tục trong suốt phiên làm việc. Nếu người dùng đang mở Gmail ở văn phòng rồi mang máy ra quán cà phê với mạng công cộng, và chính sách yêu cầu IP văn phòng, phiên truy cập sẽ bị cắt ngay khi ngữ cảnh thay đổi chứ không đợi đến lần đăng nhập sau. Đây là khác biệt căn bản so với các hệ thống chỉ kiểm tra một lần ở cổng.

Phạm vi bảo vệ: rộng hơn bạn nghĩ

Ban đầu Context-Aware Access chỉ phủ các ứng dụng lõi của Workspace như Gmail, Drive, Docs, Meet, Calendar. Theo thời gian, tấm khiên này được mở rộng đáng kể và giờ đây bao trùm gần như toàn bộ bề mặt truy cập của tổ chức.

Các ứng dụng SAML đăng nhập qua Google làm nhà cung cấp danh tính có thể được gắn chính sách riêng, biến Google thành chốt kiểm soát ngữ cảnh cho cả những phần mềm không thuộc Google. Các ứng dụng bên thứ ba và ứng dụng nội bộ gọi vào API của Workspace để đọc dữ liệu Gmail hay Drive cũng chịu sự kiểm soát, chặn đường vòng mà kẻ tấn công có thể lợi dụng qua các ứng dụng đã được cấp quyền OAuth. Gần đây nhất, chính sách còn áp được lên toàn bộ các ứng dụng dùng OpenID Connect đăng nhập bằng tài khoản Google, với một công tắc duy nhất phủ tất cả và có chế độ giám sát để đo tác động trước khi thực thi. Ngay cả các dịch vụ mới như NotebookLM cũng đã nằm trong phạm vi bảo vệ.

Đặc biệt, chính Admin console cũng có thể được đặt sau lớp Context-Aware Access. Tài khoản quản trị viên là mục tiêu giá trị nhất trong mọi cuộc tấn công vào Workspace, nên việc giới hạn bảng điều khiển quản trị chỉ truy cập được từ thiết bị công ty và mạng tin cậy là một trong những nước đi mang lại giá trị bảo mật lớn nhất trên mỗi phút cấu hình bỏ ra.

Tuy vậy cần biết giới hạn của công cụ. Chính sách chỉ kiểm soát truy cập từ tài khoản người dùng cuối, không áp dụng cho service account gọi API. Nghĩa là các luồng tự động hóa máy với máy cần được bảo vệ bằng cơ chế khác, như giới hạn phạm vi quyền của service account và giám sát hành vi bất thường.

Trải nghiệm người dùng: chặn nhưng vẫn cho cơ hội sửa sai

Một hệ thống kiểm soát truy cập chặt chẽ mà không giải thích gì sẽ nhanh chóng nhấn chìm bộ phận hỗ trợ trong ticket. Google xử lý vấn đề này bằng thông điệp khắc phục, gọi là remediation message. Khi bị chặn, thay vì một màn hình từ chối khô khan, người dùng có thể được hướng dẫn cụ thể lý do và cách tự tháo gỡ: bật mã hóa ổ đĩa, cập nhật hệ điều hành, cài Endpoint Verification, hoặc chuyển sang mạng công ty. Quản trị viên có thể tùy biến các thông điệp này, thậm chí cho phép người dùng tự mở khóa một số ứng dụng trong các tình huống nhất định.

Về phía quản trị, mọi lần đánh giá truy cập đều được ghi vào log sự kiện của Context-Aware Access. Tùy gói giấy phép, các log này có thể đưa vào công cụ điều tra bảo mật để truy vết ai bị chặn, vì điều kiện nào, vào lúc nào. Đây vừa là dữ liệu tinh chỉnh chính sách, vừa là bằng chứng tuân thủ khi kiểm toán.

Triển khai thực tế: lộ trình an toàn để triển khai

Sức mạnh của Context-Aware Access đi kèm một rủi ro rất thật: cấu hình sai có thể khóa chính bạn và toàn bộ công ty khỏi hệ thống. Kinh nghiệm từ các dự án triển khai đúc kết thành một lộ trình khá nhất quán.

Bước chuẩn bị bắt đầu từ việc kiểm kê. Rà soát các loại giấy phép trong tổ chức để biết ai thực sự chịu chính sách. Lập danh sách các dải IP văn phòng và VPN. Đánh giá hiện trạng quản lý thiết bị: bao nhiêu máy đã có Endpoint Verification, bao nhiêu điện thoại đã vào diện quản lý di động. Đồng thời chuẩn bị phương án thoát hiểm, gồm ít nhất một tài khoản super admin được miễn trừ khỏi các chính sách ngặt nghèo nhất và thông tin liên hệ hỗ trợ của Google phòng khi sự cố khóa nhầm xảy ra.

Bước thiết kế nên đi từ mục tiêu nghiệp vụ chứ không phải từ tính năng. Hãy viết ra các câu chính sách bằng ngôn ngữ thường trước: dữ liệu nhân sự chỉ mở từ thiết bị công ty, Admin console chỉ vào từ mạng văn phòng, đối tác ngoài chỉ truy cập ứng dụng X từ quốc gia Y. Rồi mới dịch từng câu thành access level và phạm vi áp dụng. Cách làm này giữ cho bộ chính sách gọn gàng, dễ giải thích với lãnh đạo và dễ bảo trì về sau.

Bước thử nghiệm là nơi chế độ monitor mode phát huy giá trị. Ở chế độ này, hệ thống ghi nhận những ai lẽ ra sẽ bị chặn nhưng chưa chặn thật. Chạy giám sát vài tuần trên một đơn vị tổ chức thí điểm, bạn sẽ phát hiện đủ thứ bất ngờ: nhóm kinh doanh hay công tác nước ngoài, vài máy cũ chưa từng bật mã hóa, một ứng dụng nội bộ đang gọi API theo cách không ai nhớ. Xử lý hết các trường hợp này trước khi bật thực thi sẽ quyết định dự án được chào đón hay bị từ chối.

Bước mở rộng nên đi theo vòng tròn đồng tâm: từ nhóm thí điểm ra từng phòng ban, từ chính sách lỏng đến chính sách chặt, từ ứng dụng ít nhạy cảm đến ứng dụng cốt lõi. Song song, truyền thông cho người dùng biết trước điều gì sắp thay đổi và họ cần làm gì, kèm thông điệp khắc phục được viết tử tế bằng ngôn ngữ của tổ chức.

Vài kịch bản đáng tham khảo

Để hình dung rõ hơn, đây là mấy cấu hình phổ biến trong thực tế. Một công ty dịch vụ tài chính yêu cầu mọi truy cập vào Drive và Gmail phải đến từ thiết bị công ty đã mã hóa, riêng hệ thống báo cáo tài chính trên SAML còn thêm điều kiện giờ hành chính và xác thực bằng khóa bảo mật. Một doanh nghiệp sản xuất cho phép công nhân dùng điện thoại cá nhân xem lịch và mail, nhưng tài liệu kỹ thuật trên Drive chỉ mở từ máy trạm trong nhà máy. Một startup toàn cầu không giới hạn địa điểm nhưng bắt buộc mọi thiết bị phải có khóa màn hình, mã hóa và hệ điều hành còn được hỗ trợ, đổi lại nhân viên làm việc từ bất cứ đâu mà không cần VPN. Một tổ chức giáo dục chặn toàn bộ đăng nhập của khối văn phòng từ ngoài quốc gia sở tại, trong khi giảng viên đi hội thảo quốc tế được xếp vào nhóm riêng với chính sách mềm hơn nhưng yêu cầu thiết bị chặt hơn.

Điểm chung của các kịch bản này là không có một chính sách đúng cho tất cả. Ngữ cảnh của tổ chức quyết định ngữ cảnh nào của người dùng là chấp nhận được.

Lời kết

Context-Aware Access không phải là một giải pháp quyết định tất cả. Nó không thay thế xác thực đa yếu tố, không quét mã độc, không ngăn người dùng chia sẻ nhầm tài liệu. Thứ nó làm, và làm rất tốt, là thu hẹp triệt để không gian mà một tài khoản bị đánh cắp có thể gây hại. Trong thời đại mà phần lớn các vụ xâm nhập bắt đầu bằng một tài khoản hợp lệ rơi vào tay kẻ xấu, khả năng nói không với mật khẩu đúng nhưng ngữ cảnh sai chính là lằn ranh giữa một sự cố suýt xảy ra và một cuộc khủng hoảng rò rỉ dữ liệu.

Nếu tổ chức của bạn đang dùng gói Workspace có hỗ trợ tính năng này mà chưa bật, thì tấm khiên ấy đang nằm sẵn trong kho, đã trả tiền, chỉ chờ được nhấc lên. Hãy bắt đầu từ những bước nhỏ nhất: bật Endpoint Verification, tạo access level đầu tiên cho Admin console, chạy monitor mode và để dữ liệu dẫn đường. Zero Trust nghe có vẻ là hành trình lớn lao, nhưng với Google Workspace, nó bắt đầu bằng vài cú nhấp chuột mà thôi (nhớ tính toán kỹ).