Зашифровать и усилить; расшифровать данные

В этом руководстве описывается, как работают шифрование и дешифрование с использованием API шифрования на стороне клиента Google Workspace.

You must add to an allowlist any Identity Provider (IdP) services used by users sharing encrypted files. You can usually find the required IdP details in their publicly-available .well-known file; otherwise, contact the organization's Google Workspace administrator for their IdP details.

Шифрование данных

When a Google Workspace user requests to save or store client-side encrypted (CSE) data, Google Workspace sends a wrap request to your Key Access Control List Service (KACLS) endpoint URL for encryption. In addition to optional security checks, such as perimeter and JWT claim-based checks, your KACLS must perform the following steps:

1. Проверьте личность пользователя, отправившего запрос.

   • Проверьте подлинность как токена аутентификации , так и токена авторизации .
   • Убедитесь, что токены авторизации и аутентификации принадлежат одному и тому же пользователю, выполнив поиск по адресам электронной почты без учета регистра.
   • When the authentication token contains the optional google_email claim, it must be compared against the email claim in the authorization token using a case-insensitive approach. Don't use the email claim within the authentication token for this comparison.
   • In scenarios where the authentication token lacks the optional google_email claim, the email claim within the authentication token should be compared with the email claim in the authorization token, using a case-insensitive method.
   • In scenarios where Google issues an authorization token for an email not associated with a Google Account, the email_type claim must be present. This forms a crucial part of the Guest Access feature, providing valuable information for KACLS to enforce additional security measures on external users.
     • Вот несколько примеров того, как KACLS может использовать эту информацию:
     • Ввести дополнительные требования к лесозаготовкам.
     • Чтобы ограничить использование эмитента токенов аутентификации только выделенным поставщиком идентификации для гостей.
     • Для того чтобы требовать дополнительных утверждений в токене аутентификации.
     • If a customer has not configured Guest Access, then all requests where email_type is set to google-visitor or customer-idp can be rejected. Requests with an email_type of google or with an unset email_type should continue to be accepted.
   • Если токен аутентификации содержит необязательное утверждение delegated_to , он также должен содержать утверждение resource_name , и эти два утверждения должны быть сравнены с утверждениями delegated_to и resource_name в токене авторизации. Утверждения delegated_to следует сравнивать без учета регистра, а resource_name в токенах должен совпадать с resource_name операции.
   • Убедитесь, что в токене авторизации указано значение role writer или upgrader .
   • Check that the kacls_url claim in the authorization token matches the current KACLS URL. This check allows detection of potential man-in-the-middle servers configured by insiders or rogue domain administrators.
   • Выполните проверку периметра, используя как подтверждения подлинности, так и авторизации.

2. Зашифруйте следующие части, используя алгоритм шифрования с аутентификацией:

   • Ключ шифрования данных (DEK)
   • Значения resource_name и perimeter_id из токена авторизации.
   • Любые дополнительные конфиденциальные данные

3. Запишите в журнал операцию, включая пользователя, инициировавшего её, имя resource_name и причину, указанную в запросе.

4. Возвращает непрозрачный двоичный объект, который будет храниться в Google Workspace вместе с зашифрованным объектом и отправляться в неизмененном виде при любой последующей операции распаковки ключа. Или же выдает структурированный ответ об ошибке .

   • Двоичный объект должен содержать единственную копию зашифрованного DEK; в нем могут храниться данные, специфичные для конкретной реализации.

Note: Do not store the DEK in your KACLS system. Instead, encrypt it and return it in the wrapped_key object to prevent discrepancies for the lifetime of the file. Google doesn't send deletion requests to the KACLS when objects are deleted.

Расшифровка данных

When a Google Workspace user requests to open client-side encrypted (CSE) data, Google Workspace sends an unwrap request to your KACLS endpoint URL for decryption. In addition to optional security checks, such as perimeter and JWT claim-based checks, your KACLS must perform the following steps:

1. Проверьте личность пользователя, отправившего запрос.

   • Проверьте подлинность как токена аутентификации , так и токена авторизации .
   • Убедитесь, что токены авторизации и аутентификации принадлежат одному и тому же пользователю, выполнив поиск по адресам электронной почты без учета регистра.
   • When the authentication token contains the optional google_email claim, it must be compared against the email claim in the authorization token using a case-insensitive approach. Don't use the email claim within the authentication token for this comparison.
   • In scenarios where the authentication token lacks the optional google_email claim, the email claim within the authentication token should be compared with the email claim in the authorization token, using a case-insensitive method.
   • In scenarios where Google issues an authorization token for an email not associated with a Google Account, the email_type claim must be present. This forms a crucial part of the Guest Access feature, providing valuable information for KACLS to enforce additional security measures on external users.
     • Вот несколько примеров того, как KACLS может использовать эту информацию:
     • Ввести дополнительные требования к лесозаготовкам.
     • Чтобы ограничить использование эмитента токенов аутентификации только выделенным поставщиком идентификации для гостей.
     • Для того чтобы требовать дополнительных утверждений в токене аутентификации.
     • If a customer has not configured Guest Access, then all requests where email_type is set to google-visitor or customer-idp can be rejected. Requests with an email_type of google or with an unset email_type should continue to be accepted.
   • Если токен аутентификации содержит необязательное утверждение delegated_to , он также должен содержать утверждение resource_name , и эти два утверждения должны быть сравнены с утверждениями delegated_to и resource_name в токене авторизации. Утверждения delegated_to следует сравнивать без учета регистра, а resource_name в токенах должен совпадать с resource_name операции.
   • Убедитесь, что в токене авторизации указана role reader или writer .
   • Check that the kacls_url claim in the authorization token matches the current KACLS URL. This allows detection of potential man-in-the-middle servers configured by insiders or rogue domain administrators.

2. Расшифруйте следующие части, используя алгоритм шифрования с аутентификацией:

   • Data Encryption Key (DEK)
   • Значения resource_name и perimeter_id из токена авторизации.
   • Any additional sensitive data

3. Убедитесь, что resource_name в токене авторизации и расшифрованном BLOB-объекте совпадает.

4. Выполните проверку периметра, используя как подтверждения подлинности, так и авторизации.

5. Запишите в журнал операцию, включая пользователя, инициировавшего её, имя resource_name и причину, указанную в запросе.

6. Возвращает развернутый DEK или структурированный ответ об ошибке .

Примечание: Чтобы расшифровать запросы Google Takeout , см. privilegedunwrap .