Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Dịch vụ Danh sách kiểm soát quyền truy cập khoá (KACLS) của bạn được định cấu hình mà không có sự tham gia của Google. Dưới đây là thông tin chi tiết về các chế độ cài đặt phổ biến và các phương pháp hay nhất để định cấu hình dịch vụ của bạn.
Chế độ cài đặt hoạt động
API này chỉ được cung cấp qua HTTPS với TLS 1.2 trở lên và có chứng chỉ X.509 hợp lệ.
Máy chủ API phải xử lý CORS để truy cập vào điểm cuối được uỷ quyền của Google: https://client-side-encryption.google.com.
Bạn nên đặt độ trễ tối đa là 200 mili giây cho 99% yêu cầu.
Chế độ cài đặt nhà cung cấp dịch vụ uỷ quyền
Sử dụng các chế độ cài đặt bên dưới để xác thực mã thông báo uỷ quyền do Google phát hành trong quá trình mã hoá phía máy khách (CSE):
Bối cảnh ứng dụng Google Workspace
URL điểm cuối JWKS
Đơn vị phát hành mã thông báo uỷ quyền
Đối tượng mã thông báo uỷ quyền
Google Drive và các công cụ tạo nội dung cộng tác, chẳng hạn như Tài liệu và Trang tính
Bạn phải thiết lập các chế độ cài đặt bên dưới cho mỗi Nhà cung cấp danh tính (IdP) không phải của Google mà dịch vụ của bạn hoạt động cùng:
Phương thức xác thực mã thông báo. Thông thường, mã thông báo được xác thực bằng URL đến tệp JSON Web Key Set (JWKS), nhưng cũng có thể là chính khoá công khai.
Giá trị của đơn vị phát hành và đối tượng: Giá trị của trường iss (đơn vị phát hành) và aud (đối tượng) mà mỗi Nhà cung cấp danh tính sử dụng.
Chế độ cài đặt hàng rào ảo
Khái niệm về ranh giới trong tính năng mã hoá phía máy khách (CSE) của Google Workspace được dùng để cung cấp quyền kiểm soát truy cập vào khoá mã hoá thông qua KACLS. Các ranh giới là những bước kiểm tra bổ sung không bắt buộc được thực hiện trên mã thông báo xác thực và uỷ quyền trong KACLS.
Bạn có thể dùng chu vi để:
Chỉ cho phép người dùng thuộc các miền có trong danh sách cho phép giải mã khoá.
Thêm người dùng vào danh sách chặn, chẳng hạn như quản trị viên Google Workspace.
Đưa ra các hạn chế nâng cao. Ví dụ:
Các quy định hạn chế dựa trên thời gian đối với nhân viên trực điện thoại hoặc người đang đi nghỉ
Quy định hạn chế về vị trí địa lý để ngăn chặn quyền truy cập từ các vị trí hoặc mạng cụ thể
Quyền truy cập dựa trên vai trò hoặc loại người dùng, do Nhà cung cấp danh tính xác nhận
Xác minh cấu hình KACLS
Để kiểm tra xem KACLS có đang hoạt động và được định cấu hình chính xác hay không, hãy gửi một yêu cầu status. Bạn cũng có thể thực hiện các quy trình tự kiểm tra nội bộ, chẳng hạn như khả năng truy cập KMS hoặc tình trạng của hệ thống ghi nhật ký.
[null,null,["Cập nhật lần gần đây nhất: 2025-08-29 UTC."],[[["\u003cp\u003eYour Key Access Control List Service (KACLS) is configured independently by you, allowing you to control access to encryption keys for Google Workspace Client-side encryption (CSE).\u003c/p\u003e\n"],["\u003cp\u003eKACLS requires specific operational settings like HTTPS with TLS 1.2 or later, CORS handling for Google's authorized endpoint, and a recommended latency of under 200ms for most requests.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization settings need to be configured for Google Workspace applications like Drive, Meet, Calendar, and Gmail, enabling validation of Google-issued authorization tokens during CSE.\u003c/p\u003e\n"],["\u003cp\u003ePerimeter settings offer optional but powerful access control by allowing or blocking users based on criteria like domains, user roles, time, and location, enhancing security for encryption keys.\u003c/p\u003e\n"],["\u003cp\u003eIdentity Provider settings are crucial for non-Google Identity Providers, requiring you to specify methods for validating tokens and the issuer and audience values used by each provider.\u003c/p\u003e\n"]]],["KACLS configuration requires the API to use HTTPS with TLS 1.2 or later, handle CORS for `https://client-side-encryption.google.com`, and maintain a maximum 200ms latency. It uses Google-issued authorization tokens, validated via JWKS endpoints specific to Google Workspace applications. Non-Google Identity Provider settings require token validation methods, issuer, and audience values. Perimeters, an optional access control, can allow or block access based on domain, user, time, or location. Verification is done via a status request.\n"],null,["# Configure your service\n\nYour Key Access Control List Service (KACLS) is configured without Google's\ninvolvement. Below are details about common settings and best practices for\nconfiguring your service.\n\nOperational settings\n--------------------\n\n- The API should only be available over HTTPS with TLS 1.2 or later with a valid\n X.509 certificate.\n\n- The API server should handle [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)\n to access Google's authorized end-point: `https://client-side-encryption.google.com`.\n\n- We recommend a maximum latency of 200 ms for 99% of requests.\n\nAuthorization provider settings\n-------------------------------\n\nUse the settings below to validate the Google-issued\n[authorization tokens](/workspace/cse/reference/authorization-tokens) during\nclient-side encryption (CSE):\n\n| Google Workspace application context | JWKS endpoint URL | Authorization token issuer | Authorization token audience |\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------|------------------------------|\n| **Google Drive and collaborative content creation tools, like Docs and Sheets** | `https://www.googleapis.com/service_accounts/v1/jwk/gsuitecse-tokenissuer-drive@system.gserviceaccount.com` | `gsuitecse-tokenissuer-drive@system.gserviceaccount.com` | `cse-authorization` |\n| **Meet CSE** | `https://www.googleapis.com/service_accounts/v1/jwk/gsuitecse-tokenissuer-meet@system.gserviceaccount.com` | `gsuitecse-tokenissuer-meet@system.gserviceaccount.com` | `cse-authorization` |\n| **Calendar CSE** | `https://www.googleapis.com/service_accounts/v1/jwk/gsuitecse-tokenissuer-calendar@system.gserviceaccount.com` | `gsuitecse-tokenissuer-calendar@system.gserviceaccount.com` | `cse-authorization` |\n| **Gmail CSE** | `https://www.googleapis.com/service_accounts/v1/jwk/gsuitecse-tokenissuer-gmail@system.gserviceaccount.com` | `gsuitecse-tokenissuer-gmail@system.gserviceaccount.com` | `cse-authorization` |\n| **KACLS migration** | `https://www.googleapis.com/service_accounts/v1/jwk/apps-security-cse-kaclscommunication@system.gserviceaccount.com` | `apps-security-cse-kaclscommunication@system.gserviceaccount.com` | `cse-authorization` |\n\nIdentity Provider settings\n--------------------------\n\nThe settings below are required for each non-Google Identity Provider (IdP) your\nservice works with:\n\n- **Method to validate tokens.** Tokens are typically validated by the URL to a JSON Web Key Set (JWKS) file, but could also be the public keys themselves.\n- **Issuer and audience values:** The `iss` (issuer) and `aud` (audience) field values used by each Identity Provider.\n\nPerimeter settings\n------------------\n\nThe perimeter concept in Google Workspace Client-side encryption (CSE) is used\nto provide access control to the encryption keys via the KACLS. The perimeters\nare optional additional checks performed on the authentication and authorization\ntokens within the KACLS.\n\nPerimeters can be used to:\n\n- Only allow users in allowlisted domains to decrypt keys.\n- Blocklist users, such as Google Workspace administrators.\n- Provide advanced restrictions. For example:\n - Time-based restrictions for on-call employees or people on vacation\n - Geolocation restrictions to prevent access from specific locations or networks\n - User role- or type-based access, as asserted by an Identity Provider\n\n| **Note:** The takeout perimeter is used when a Google Workspace customer sends a [Google Takeout](https://support.google.com/a/answer/100458) request with [`takeout_unwrap`](/workspace/cse/reference/takeout_unwrap). The takeout perimeter enables KACLS unwrapping, bypassing the normal Google Workspace ACL, so membership should be restricted to trusted individuals. We recommend that the takeout perimeter use an IdP requiring two-factor authentication (2FA).\n\nVerify your KACLS configuration\n-------------------------------\n\nTo check whether your KACLS is active and configured correctly, send a\n[`status`](/workspace/cse/reference/status) request. Internal self checks,\nlike KMS accessibility or logging system health, can also be performed."]]
