Encripta y desencripta datos

En esta guía, se describe cómo funcionan la encriptación y la desencriptación con la API de encriptación del cliente de Google Workspace.

Debes agregar a una lista de entidades permitidas cualquier servicio de proveedor 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 wrap solicitud 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 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 haciendo una coincidencia que no distinga mayúsculas de minúsculas en las reclamaciones de correo electrónico.
    • Cuando el token de autenticación contiene la reclamación opcional google_email, se debe comparar con la reclamación 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 tiene la reclamación opcional google_email, la reclamación de correo electrónico dentro del token de autenticación se debe comparar con la reclamación de correo electrónico en el token de autorización con 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 con una Cuenta de Google, debe estar presente la reclamación email_type. Esto forma una parte fundamental de la función de acceso para invitados, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales a los usuarios externos.
      • Algunos ejemplos de cómo un KACLS puede usar esta información incluyen los siguientes:
      • Para imponer requisitos de registro adicionales
      • Para restringir el emisor del token de autenticación a un IdP para invitados dedicado
      • Para requerir reclamaciones adicionales en el token de autenticación
      • Si un cliente no configuró el acceso para invitados, se pueden rechazar todas las solicitudes en las que email_type esté configurado como google-visitor o customer-idp. Las solicitudes con un email_type de google o con un email_type no establecido deben seguir aceptándose.
    • Cuando el token de autenticación contiene la reclamación opcional delegated_to, también debe contener la reclamación resource_name, y estas dos reclamaciones deben compararse con las reclamaciones delegated_to y resource_name en el token de autorización. Las reclamaciones 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 la reclamación role en el token de autorización sea writer o upgrader.
    • Verifica que la reclamación 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 administradores internos o de dominios no autorizados.
    • Realiza una verificación perimetral con las reclamaciones 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 dato sensible adicional

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

  4. Muestra un objeto binario opaco para que Google Workspace lo almacene junto con el objeto encriptado y lo envíe tal como está en cualquier operación posterior de separación de claves. O bien, muestra una respuesta de error estructurada reply.

    • El objeto binario debe contener la única copia de la DEK encriptada, y en él se pueden almacenar 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 unwrap solicitud 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 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 haciendo una coincidencia que no distinga mayúsculas de minúsculas en las reclamaciones de correo electrónico.
    • Cuando el token de autenticación contiene la reclamación opcional google_email, se debe comparar con la reclamación 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 tiene la reclamación opcional google_email, la reclamación de correo electrónico dentro del token de autenticación se debe comparar con la reclamación de correo electrónico en el token de autorización con 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 con una Cuenta de Google, debe estar presente la reclamación email_type. Esto forma una parte fundamental de la función de acceso para invitados, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales a los usuarios externos.
      • Algunos ejemplos de cómo un KACLS puede usar esta información incluyen los siguientes:
      • Para imponer requisitos de registro adicionales
      • Para restringir el emisor del token de autenticación a un IdP para invitados dedicado
      • Para requerir reclamaciones adicionales en el token de autenticación
      • Si un cliente no configuró el acceso para invitados, se pueden rechazar todas las solicitudes en las que email_type esté configurado como google-visitor o customer-idp. Las solicitudes con un email_type de google o con un email_type no establecido deben seguir aceptándose.
    • Cuando el token de autenticación contiene la reclamación opcional delegated_to, también debe contener la reclamación resource_name, y estas dos reclamaciones deben compararse con las reclamaciones delegated_to y resource_name en el token de autorización. Las reclamaciones 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 la reclamación role en el token de autorización sea reader o writer.
    • Verifica que la reclamación 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 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 dato sensible adicional

  3. Verifica que el resource_name en el token de autorización y el blob desencriptado coincidan.

  4. Realiza una verificación perimetral con las reclamaciones 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. Muestra la DEK separada o una respuesta de error estructurada.