Encripta y desencripta datos

En esta guía, se describe cómo funciona la encriptación y desencriptación con la API de Client-side Encryption de Google Workspace.

Debes incluir en la lista de entidades permitidas todos los servicios de proveedores de identidad (IdP) que usen los usuarios que comparten archivos encriptados. Por lo general, puedes encontrar los detalles del IdP necesarios en su archivo .well-known disponible públicamente. De lo contrario, comunícate con el administrador de Google Workspace de la organización para obtener los detalles del IdP.

Encripta datos

Cuando un usuario de Google Workspace solicita guardar o almacenar datos encriptados del cliente (CSE), Google Workspace envía una solicitud wrap a la URL del extremo de tu servicio de lista de control de acceso a claves (KACLS) para la encriptación. Además de las verificaciones de seguridad opcionales, como las verificaciones perimetrales y las basadas en reclamos de JWT, tu KACLS debe realizar los siguientes pasos:

  1. Valida al usuario solicitante.

    • Valida el token de autenticación y el token de autorización.
    • Verifica que los tokens de autorización y autenticación sean para el mismo usuario realizando una coincidencia que no distinga mayúsculas de minúsculas en las declaraciones de correo electrónico.
    • Cuando el token de autenticación contiene el reclamo opcional google_email, se debe comparar con el reclamo de correo electrónico en el token de autorización con un enfoque que no distinga mayúsculas de minúsculas. No uses la reclamación de correo electrónico dentro del token de autenticación para esta comparación.
    • En situaciones en las que el token de autenticación no incluye el reclamo google_email opcional, el reclamo de correo electrónico dentro del token de autenticación se debe comparar con el reclamo de correo electrónico en el token de autorización, utilizando un método que no distinga mayúsculas de minúsculas.
    • En situaciones en las que Google emite un token de autorización para un correo electrónico que no está asociado a una Cuenta de Google, debe estar presente el reclamo email_type. Esto constituye una parte fundamental de la función de acceso para invitados, ya que proporciona información valiosa para que los KACL apliquen medidas de seguridad adicionales a los usuarios externos.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Imponer requisitos de registro adicionales
      • Restringir el emisor de tokens de autenticación a un IdP para invitados dedicado
      • Para requerir reclamos adicionales en el token de autenticación
      • Si un cliente no configuró el acceso de invitado, se pueden rechazar todas las solicitudes en las que email_type esté establecido en google-visitor o customer-idp. Se deben seguir aceptando las solicitudes con un email_type de google o con un email_type sin configurar.
    • Cuando el token de autenticación contiene el reclamo opcional delegated_to, también debe contener el reclamo resource_name, y estos dos reclamos deben compararse con los reclamos delegated_to y resource_name en el token de autorización. Los reclamos de delegated_to se deben comparar con un enfoque que no distinga mayúsculas de minúsculas, y el resource_name en los tokens debe coincidir con el resource_name de la operación.
    • Verifica que el reclamo role en el token de autorización sea writer o upgrader.
    • Verifica que el reclamo kacls_url en el token de autorización coincida con la URL actual de KACLS. Esta verificación permite detectar posibles servidores de intermediarios configurados por personas internas o administradores de dominio no autorizados.
    • Realiza una verificación del perímetro con las declaraciones de autenticación y autorización.

  2. Encripta las siguientes partes con un algoritmo de encriptación autenticado:

    • Clave de encriptación de datos (DEK)
    • Los valores resource_name y perimeter_id del token de autorización
    • Cualquier otro dato sensible

  3. Registra la operación, incluido el usuario que la originó, el resource_name y el motivo que se pasó en la solicitud.

  4. Devuelve un objeto binario opaco para que Google Workspace lo almacene junto con el objeto encriptado y lo envíe tal cual en cualquier operación posterior de desencriptado de claves. O bien, mostrar una respuesta de error estructurada

    • El objeto binario debe contener la única copia de la DEK encriptada, y se pueden almacenar en él datos específicos de la implementación.

Desencripta datos

Cuando un usuario de Google Workspace solicita abrir datos encriptados del cliente (CSE), Google Workspace envía una solicitud unwrap a la URL del extremo de tu KACLS para la desencriptación. Además de las verificaciones de seguridad opcionales, como las verificaciones perimetrales y las basadas en reclamaciones de JWT, tu KACLS debe realizar los siguientes pasos:

  1. Valida al usuario solicitante.

    • Valida el token de autenticación y el token de autorización.
    • Verifica que los tokens de autorización y autenticación sean para el mismo usuario realizando una coincidencia que no distinga mayúsculas de minúsculas en las declaraciones de correo electrónico.
    • Cuando el token de autenticación contiene el reclamo opcional google_email, se debe comparar con el reclamo de correo electrónico en el token de autorización con un enfoque que no distinga mayúsculas de minúsculas. No uses la reclamación de correo electrónico dentro del token de autenticación para esta comparación.
    • En situaciones en las que el token de autenticación no incluye el reclamo google_email opcional, el reclamo de correo electrónico dentro del token de autenticación se debe comparar con el reclamo de correo electrónico en el token de autorización, utilizando un método que no distinga mayúsculas de minúsculas.
    • En situaciones en las que Google emite un token de autorización para un correo electrónico que no está asociado a una Cuenta de Google, debe estar presente el reclamo email_type. Esto constituye una parte fundamental de la función de acceso para invitados, ya que proporciona información valiosa para que los KACL apliquen medidas de seguridad adicionales a los usuarios externos.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Imponer requisitos de registro adicionales
      • Restringir el emisor de tokens de autenticación a un IdP para invitados dedicado
      • Para requerir reclamos adicionales en el token de autenticación
      • Si un cliente no configuró el acceso de invitado, se pueden rechazar todas las solicitudes en las que email_type esté establecido en google-visitor o customer-idp. Se deben seguir aceptando las solicitudes con un email_type de google o con un email_type sin configurar.
    • Cuando el token de autenticación contiene el reclamo opcional delegated_to, también debe contener el reclamo resource_name, y estos dos reclamos deben compararse con los reclamos delegated_to y resource_name en el token de autorización. Los reclamos de delegated_to se deben comparar con un enfoque que no distinga mayúsculas de minúsculas, y el resource_name en los tokens debe coincidir con el resource_name de la operación.
    • Verifica que el reclamo role en el token de autorización sea reader o writer.
    • Verifica que el reclamo kacls_url en el token de autorización coincida con la URL actual de KACLS. Esto permite detectar posibles servidores de intermediarios configurados por administradores internos o administradores de dominios no autorizados.

  2. Desencripta las siguientes partes con un algoritmo de encriptación autenticado:

    • Clave de encriptación de datos (DEK)
    • Los valores resource_name y perimeter_id del token de autorización
    • Cualquier otro dato sensible

  3. Verifica que el resource_name del token de autorización y el BLOB descifrado coincidan.

  4. Realiza una verificación del perímetro con las declaraciones de autenticación y autorización.

  5. Registra la operación, incluido el usuario que la originó, el resource_name y el motivo que se pasó en la solicitud.

  6. Devuelve la DEK separada o una respuesta de error estructurada.