В этом руководстве описывается, как работает шифрование и дешифрование с помощью API шифрования на стороне клиента Google Workspace.
Вы должны внести в белый список все службы поставщика удостоверений (IdP), используемые пользователями, передающими зашифрованные файлы. Обычно необходимые данные IdP можно найти в общедоступном файле .well-known; в противном случае обратитесь к администратору Google Workspace организации за информацией об поставщике удостоверений.
Шифрование данных
Когда пользователь Google Workspace запрашивает сохранение или хранение данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос wrap
на URL-адрес конечной точки KACLS для шифрования. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:
Подтвердите запрашивающего пользователя.
- Проверьте токен аутентификации и токен авторизации .
- Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
- Если токен аутентификации содержит необязательное утверждение
google_email
, его необходимо сравнить с утверждением электронной почты в токене авторизации, используя подход без учета регистра. Не используйте утверждение электронной почты в токене аутентификации для этого сравнения. - В сценариях, где в токене аутентификации отсутствует необязательное утверждение
google_email
, утверждение электронной почты в токене аутентификации следует сравнить с утверждением электронной почты в токене авторизации, используя метод без учета регистра. - В сценариях, когда Google выдает токен авторизации для электронного письма, не связанного с учетной записью Google, утверждение
email_type
должно присутствовать. Это является важной частью функции гостевого доступа, предоставляя KACLS ценную информацию для обеспечения дополнительных мер безопасности для внешних пользователей.- Некоторые примеры того, как KACLS может использовать эту информацию, включают:
- Наложить дополнительные требования к ведению журнала.
- Чтобы ограничить эмитента токена аутентификации выделенным гостевым IdP.
- Требовать дополнительных утверждений для токена аутентификации.
- Если клиент не настроил гостевой доступ, все запросы, в которых для
email_type
установлено значениеgoogle-visitor
илиcustomer-idp
могут быть отклонены. Запросы сemail_type
отgoogle
или с неустановленнымemail_type
должны продолжать приниматься.
- Убедитесь, что утверждение
role
в токене авторизации — «писатель» или «обновитель». - Убедитесь, что утверждение
kacls_url
в токене авторизации соответствует текущему URL-адресу KACLS. Эта проверка позволяет обнаружить потенциальные серверы-посредники, настроенные инсайдерами или мошенническими администраторами домена. - Выполните проверку периметра, используя утверждения аутентификации и авторизации.
Зашифруйте следующие части, используя проверенный алгоритм шифрования:
- Ключ шифрования данных (DEK)
- Значения
resource_name
иperimeter_id
из токена авторизации. - Любые дополнительные конфиденциальные данные
Зарегистрируйте операцию, включая пользователя, инициировавшего ее,
resource_name
и причину, переданную в запросе.Верните непрозрачный двоичный объект, который будет храниться в Google Workspace вместе с зашифрованным объектом и отправляться «как есть» при любой последующей операции развертывания ключа. Или отправьте структурированный ответ об ошибке .
- Бинарный объект должен содержать единственную копию зашифрованного DEK, в нем могут храниться данные, специфичные для реализации.
Расшифровать данные
Когда пользователь Google Workspace запрашивает открытие данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос unwrap
на URL-адрес вашей конечной точки KACLS для расшифровки. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:
Подтвердите запрашивающего пользователя.
- Проверьте токен аутентификации и токен авторизации .
- Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
- Если токен аутентификации содержит необязательное утверждение
google_email
, его необходимо сравнить с утверждением электронной почты в токене авторизации, используя подход без учета регистра. Не используйте утверждение электронной почты в токене аутентификации для этого сравнения. - В сценариях, где в токене аутентификации отсутствует необязательное утверждение
google_email
, утверждение электронной почты в токене аутентификации следует сравнить с утверждением электронной почты в токене авторизации, используя метод без учета регистра. - В сценариях, когда Google выдает токен авторизации для электронного письма, не связанного с учетной записью Google, утверждение
email_type
должно присутствовать. Это является важной частью функции гостевого доступа, предоставляя KACLS ценную информацию для обеспечения дополнительных мер безопасности для внешних пользователей.- Некоторые примеры того, как KACLS может использовать эту информацию, включают:
- Наложить дополнительные требования к ведению журнала.
- Чтобы ограничить эмитента токена аутентификации выделенным гостевым IdP.
- Требовать дополнительных утверждений для токена аутентификации.
- Если клиент не настроил гостевой доступ, все запросы, в которых для параметра
email_type
установлено значениеgoogle-visitor
илиcustomer-idp
могут быть отклонены. Запросы сemail_type
отgoogle
или с неустановленнымemail_type
должны продолжать приниматься.
- Убедитесь, что утверждение
role
в маркере авторизации — «читатель» или «писатель». - Убедитесь, что утверждение
kacls_url
в токене авторизации соответствует текущему URL-адресу KACLS. Это позволяет обнаруживать потенциальные серверы «посредника», настроенные инсайдерами или мошенническими администраторами домена.
Расшифруйте следующие части, используя проверенный алгоритм шифрования:
- Ключ шифрования данных (DEK)
- Значения
resource_name
иperimeter_id
из токена авторизации. - Любые дополнительные конфиденциальные данные
Убедитесь, что
resource_name
в токене авторизации и расшифрованном большом двоичном объекте совпадают.Выполните проверку периметра, используя утверждения аутентификации и авторизации.
Зарегистрируйте операцию, включая пользователя, инициировавшего ее,
resource_name
и причину, переданную в запросе.Верните развернутый DEK или структурированный ответ об ошибке .