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

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

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

Шифровать данные

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

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

    • Проверьте как токен аутентификации , так и токен авторизации .
    • Проверьте, что токены авторизации и аутентификации принадлежат одному и тому же пользователю, выполнив сопоставление заявок электронной почты без учета регистра.
    • Если токен аутентификации содержит необязательное утверждение google_email , его необходимо сравнить с утверждением email в токене авторизации без учёта регистра. Не используйте утверждение email в токене аутентификации для этого сравнения.
    • В сценариях, когда в токене аутентификации отсутствует необязательное утверждение google_email , утверждение электронной почты в токене аутентификации следует сравнивать с утверждением электронной почты в токене авторизации, используя метод без учета регистра.
    • В случаях, когда Google выдаёт токен авторизации для адреса электронной почты, не связанного с учётной записью Google, необходимо наличие утверждения email_type . Это критически важный элемент функции гостевого доступа, предоставляющий KACLS ценную информацию для применения дополнительных мер безопасности к внешним пользователям.
      • Вот несколько примеров того, как KACLS может использовать эту информацию:
      • Ввести дополнительные требования по лесозаготовкам.
      • Ограничить эмитента токена аутентификации выделенным гостевым IdP.
      • Требовать дополнительные требования к токене аутентификации.
      • Если клиент не настроил гостевой доступ, все запросы, в которых email_type установлен на google-visitor или customer-idp могут быть отклонены. Запросы с параметром email_type , установленным на google , или с неустановленным параметром email_type должны по-прежнему приниматься.
    • Если токен аутентификации содержит необязательное утверждение delegated_to , он также должен содержать утверждение resource_name , и эти два утверждения необходимо сравнить с утверждениями delegated_to и resource_name в токене авторизации. Сравнение утверждений delegated_to следует выполнять без учёта регистра, а resource_name в токенах должно совпадать с resource_name операции.
    • Проверьте, что в токене авторизации указана role writer или upgrader .
    • Проверьте, соответствует ли утверждение kacls_url в токене авторизации текущему URL-адресу KACLS. Эта проверка позволяет обнаружить потенциальные серверы типа «man-in-the-middle», настроенные инсайдерами или недобросовестными администраторами домена.
    • Выполните проверку периметра, используя как аутентификационные, так и авторизационные заявки.

  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 , его необходимо сравнить с утверждением email в токене авторизации без учёта регистра. Не используйте утверждение email в токене аутентификации для этого сравнения.
    • В сценариях, когда в токене аутентификации отсутствует необязательное утверждение google_email , утверждение электронной почты в токене аутентификации следует сравнивать с утверждением электронной почты в токене авторизации, используя метод без учета регистра.
    • В случаях, когда Google выдаёт токен авторизации для адреса электронной почты, не связанного с учётной записью Google, необходимо наличие утверждения email_type . Это критически важный элемент функции гостевого доступа, предоставляющий KACLS ценную информацию для применения дополнительных мер безопасности к внешним пользователям.
      • Вот несколько примеров того, как KACLS может использовать эту информацию:
      • Ввести дополнительные требования по лесозаготовкам.
      • Ограничить эмитента токена аутентификации выделенным гостевым IdP.
      • Требовать дополнительные требования к токене аутентификации.
      • Если клиент не настроил гостевой доступ, все запросы, в которых email_type установлен на google-visitor или customer-idp могут быть отклонены. Запросы с параметром email_type , установленным на google , или с неустановленным параметром email_type должны по-прежнему приниматься.
    • Если токен аутентификации содержит необязательное утверждение delegated_to , он также должен содержать утверждение resource_name , и эти два утверждения необходимо сравнить с утверждениями delegated_to и resource_name в токене авторизации. Сравнение утверждений delegated_to следует выполнять без учёта регистра, а resource_name в токенах должно совпадать с resource_name операции.
    • Проверьте, что в токене авторизации указана role reader или writer .
    • Убедитесь, что утверждение kacls_url в токене авторизации соответствует текущему URL-адресу KACLS. Это позволяет обнаружить потенциальные серверы типа «man-in-the-middle», настроенные инсайдерами или недобросовестными администраторами домена.

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

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

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

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

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

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