Encripta y desencripta datos

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

Debes incluir en la lista de entidades permitidas cualquier servicio de proveedor de identidad (IdP) que usen los usuarios compartir archivos encriptados. Por lo general, puedes encontrar los detalles del IdP requeridos en su archivo .well-known disponible públicamente; De lo contrario, comunícate con el administrador de Google Workspace para conocer los detalles de su IdP.

Encripta datos

Cuando un usuario de Google Workspace solicita guardar o almacenar la encriptación del cliente (CSE), Google Workspace envía un wrap a tu URL de extremo de KACLS para la encriptación. Además de las ofertas como verificaciones de perímetro y JWT, tu KACLS debe realiza los siguientes pasos:

  1. Valida al usuario solicitante.

    • Valida el token de autenticación y el token de autorización.
    • Comprueba que los tokens de autorización y autenticación sean para el mismo usuario. Para ello, haz lo siguiente: buscar coincidencias en los reclamos por correo electrónico que no distingan mayúsculas de minúsculas.
    • Cuando el token de autenticación contiene la reclamación opcional google_email, debe compararse con la reclamación de correo electrónico en el token de autorización. con un enfoque que no distingue mayúsculas de minúsculas. No uses el reclamo por correo electrónico en el de autenticación para esta comparación.
    • En situaciones en las que el token de autenticación carece de la configuración La reclamación google_email, la reclamación de correo electrónico dentro del token de autenticación debe compararse con la reclamación de correo electrónico en el token de autorización. con un método que no distingue mayúsculas de minúsculas.
    • En situaciones en las que Google emite un token de autorización para un correo electrónico que no asociado a una Cuenta de Google, debe estar presente el reclamo de email_type. Esto es una parte fundamental de la función Acceso de invitados, ya que proporciona información para que el KACLS aplique medidas de seguridad adicionales a los recursos usuarios.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Imponer requisitos de registro adicionales.
      • Para restringir la entidad emisora del token de autenticación a un IdP para invitados dedicado.
      • Requerir reclamaciones adicionales en el token de autenticación
      • Si un cliente no configuró el acceso de invitado, todas las solicitudes donde email_type se configura como google-visitor, o customer-idp puede ser rechazadas. Solicitudes con una email_type de google o con una no establecida Se debe seguir aceptando email_type.
    • Comprueba que la reclamación role en el token de autorización sea "writer" o “actualizador”.
    • Comprueba que la reclamación kacls_url en el token de autorización coincida con el URL de KACLS actual. Esta verificación permite detectar posibles Servidores de intermediario configurados por usuarios con información privilegiada o dominios fraudulentos de Google Workspace for Education.
    • Realiza una verificación del perímetro con autenticación y autorización reclamos.

  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
    • Datos sensibles adicionales

  3. Registra la operación, incluido el usuario que la originó, los 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 se envía tal como está en cualquier desenvolvimiento de clave posterior una sola operación. O bien, entrega una respuesta de error estructurada.

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

Desencripta datos

Cuando un usuario de Google Workspace solicita abrir datos con encriptación del cliente (CSE), Google Workspace envía una solicitud unwrap a tu URL de extremo de KACLS para la desencriptación. Además de las funciones de seguridad como verificaciones de perímetro y JWT, tu KACLS debe realizar sigue estos pasos:

  1. Valida al usuario solicitante.

    • Valida el token de autenticación y el token de autorización.
    • Comprueba que los tokens de autorización y autenticación sean para el mismo usuario. Para ello, haz lo siguiente: buscar coincidencias en los reclamos por correo electrónico que no distingan mayúsculas de minúsculas.
    • Cuando el token de autenticación contiene la reclamación opcional google_email, debe compararse con la reclamación de correo electrónico en el token de autorización. con un enfoque que no distingue mayúsculas de minúsculas. No uses el reclamo por correo electrónico en el de autenticación para esta comparación.
    • En situaciones en las que el token de autenticación carece de la configuración La reclamación google_email, la reclamación de correo electrónico dentro del token de autenticación debe compararse con la reclamación de correo electrónico en el token de autorización. con un método que no distingue mayúsculas de minúsculas.
    • En situaciones en las que Google emite un token de autorización para un correo electrónico que no asociado a una Cuenta de Google, debe estar presente el reclamo de email_type. Esto es una parte fundamental de la función Acceso de invitados, ya que proporciona información para que el KACLS aplique medidas de seguridad adicionales a los recursos usuarios.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Imponer requisitos de registro adicionales.
      • Para restringir la entidad emisora del token de autenticación a un IdP para invitados dedicado.
      • Requerir reclamaciones adicionales en el token de autenticación
      • Si un cliente no configuró el acceso de invitado, todas las solicitudes donde email_type se configura como google-visitor, o customer-idp puede ser rechazadas. Solicitudes con una email_type de google o con una no establecida Se debe seguir aceptando email_type.
    • Comprueba que la reclamación role en el token de autorización sea "reader" o "escritor".
    • Comprueba que la reclamación kacls_url en el token de autorización coincida con el URL de KACLS actual. Esto permite detectar posibles intermediarios servidores configurados por usuarios con información privilegiada o administradores de dominio fraudulentos.

  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
    • Datos sensibles adicionales

  3. Verifica que el resource_name en el token de autorización y el BLOB desencriptado la coincidencia.

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

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

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