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

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

Вы должны внести в белый список все службы поставщика удостоверений (IdP), используемые пользователями, передающими зашифрованные файлы. Обычно необходимые данные IdP можно найти в общедоступном файле .well-known; в противном случае обратитесь к администратору Google Workspace организации за информацией об поставщике удостоверений.

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

Когда пользователь Google Workspace запрашивает сохранение или хранение данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос wrap на URL-адрес конечной точки KACLS для шифрования. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:

1. Подтвердите запрашивающего пользователя.

   • Проверьте токен аутентификации и токен авторизации .
   • Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
   • Если токен аутентификации содержит необязательное утверждение 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. Эта проверка позволяет обнаружить потенциальные серверы-посредники, настроенные инсайдерами или мошенническими администраторами домена.
   • Выполните проверку периметра, используя утверждения аутентификации и авторизации.

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

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

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

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

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

Расшифровать данные

Когда пользователь Google Workspace запрашивает открытие данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос unwrap на URL-адрес вашей конечной точки KACLS для расшифровки. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:

1. Подтвердите запрашивающего пользователя.

   • Проверьте токен аутентификации и токен авторизации .
   • Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
   • Если токен аутентификации содержит необязательное утверждение 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. Это позволяет обнаруживать потенциальные серверы «посредника», настроенные инсайдерами или мошенническими администраторами домена.

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

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

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

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

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

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

,

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

Вы должны внести в белый список все службы поставщика удостоверений (IdP), используемые пользователями, передающими зашифрованные файлы. Обычно необходимые данные IdP можно найти в общедоступном файле .well-known; в противном случае обратитесь к администратору Google Workspace организации за информацией об IdP.

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

Когда пользователь Google Workspace запрашивает сохранение или хранение данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос wrap на URL-адрес конечной точки KACLS для шифрования. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:

1. Подтвердите запрашивающего пользователя.

   • Проверьте токен аутентификации и токен авторизации .
   • Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
   • Если токен аутентификации содержит необязательное утверждение 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. Эта проверка позволяет обнаружить потенциальные серверы-посредники, настроенные инсайдерами или мошенническими администраторами домена.
   • Выполните проверку периметра, используя утверждения аутентификации и авторизации.

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

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

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

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

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

Расшифровать данные

Когда пользователь Google Workspace запрашивает открытие данных, зашифрованных на стороне клиента (CSE), Google Workspace отправляет запрос unwrap на URL-адрес вашей конечной точки KACLS для расшифровки. В дополнение к дополнительным проверкам безопасности, таким как проверки периметра и проверки на основе утверждений JWT, ваш KACLS должен выполнить следующие шаги:

1. Подтвердите запрашивающего пользователя.

   • Проверьте токен аутентификации и токен авторизации .
   • Убедитесь, что токены авторизации и аутентификации предназначены для одного и того же пользователя, выполнив сопоставление утверждений электронной почты без учета регистра.
   • Если токен аутентификации содержит необязательное утверждение 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. Это позволяет обнаруживать потенциальные серверы «посредника», настроенные инсайдерами или мошенническими администраторами домена.

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

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

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

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

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

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