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

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

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

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

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

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

    • Проверьте подлинность как токена аутентификации , так и токена авторизации .
    • Убедитесь, что токены авторизации и аутентификации принадлежат одному и тому же пользователю, выполнив поиск по адресам электронной почты без учета регистра.
    • Если токен аутентификации содержит необязательное поле google_email , его необходимо сравнить с полем email в токене авторизации, используя подход без учета регистра. Не используйте поле email из токена аутентификации для этого сравнения.
    • В случаях, когда токен аутентификации не содержит необязательного поля google_email , поле email в токене аутентификации следует сравнивать с полем email в токене авторизации, используя метод, нечувствительный к регистру.
    • В сценариях, когда Google выдает токен авторизации для адреса электронной почты, не связанного с учетной записью Google, необходимо наличие поля email_type . Это важная часть функции гостевого доступа, предоставляющая KACLS ценную информацию для обеспечения дополнительных мер безопасности для внешних пользователей.
      • Вот несколько примеров того, как KACLS может использовать эту информацию:
      • Ввести дополнительные требования к лесозаготовкам.
      • Чтобы ограничить использование эмитента токенов аутентификации только выделенным поставщиком идентификации для гостей.
      • Для того чтобы требовать дополнительных утверждений в токене аутентификации.
      • Если клиент не настроил гостевой доступ, то все запросы, в которых 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. Эта проверка позволяет обнаружить потенциальные серверы, используемые для атак типа «человек посередине», настроенные инсайдерами или недобросовестными администраторами домена.
    • Выполните проверку периметра, используя как подтверждения подлинности, так и авторизации.

  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 , поле email в токене аутентификации следует сравнивать с полем email в токене авторизации, используя метод, нечувствительный к регистру.
    • В сценариях, когда Google выдает токен авторизации для адреса электронной почты, не связанного с учетной записью Google, необходимо наличие поля email_type . Это важная часть функции гостевого доступа, предоставляющая KACLS ценную информацию для обеспечения дополнительных мер безопасности для внешних пользователей.
      • Вот несколько примеров того, как KACLS может использовать эту информацию:
      • Ввести дополнительные требования к лесозаготовкам.
      • Чтобы ограничить использование эмитента токенов аутентификации только выделенным поставщиком идентификации для гостей.
      • Для того чтобы требовать дополнительных утверждений в токене аутентификации.
      • Если клиент не настроил гостевой доступ, то все запросы, в которых 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. Это позволяет обнаруживать потенциальные серверы, используемые для атак типа «человек посередине», настроенные инсайдерами или недобросовестными администраторами домена.

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

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

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

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

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

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