Encripta y desencripta datos

En esta guía, se describe el funcionamiento de 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 proveedor de identidad (IdP) que usan los usuarios que comparten archivos encriptados. Por lo general, puedes encontrar los detalles del IdP requeridos en su archivo .well-known disponible de forma pública. De lo contrario, comunícate con el administrador de Google Workspace de la organización para obtener los detalles de su IdP.

Encripta datos

Cuando un usuario de Google Workspace solicita guardar o almacenar datos con encriptación del cliente (CSE), Google Workspace envía una solicitud wrap a la URL de extremo de KACLS para la encriptación. Además de las verificaciones de seguridad opcionales, como las verificaciones de perímetro y basadas en reclamaciones de JWT, tus KACLS deben realizar 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, busca 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, debe compararse con la reclamación de correo electrónico del token de autorización mediante un enfoque que no distingue mayúsculas de minúsculas. No uses la reclamación de correo electrónico dentro del token de autenticación para esta comparación.
    • Cuando 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 debe compararse con la reclamación de correo electrónico del token de autorización mediante un método que no distingue mayúsculas de minúsculas.
    • En los casos en que Google emite un token de autorización para un correo electrónico no asociado con una Cuenta de Google, debe estar presente la reclamación email_type. Esto es una parte fundamental de la función de acceso de invitado, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales a los usuarios externos.
      • Estos son algunos ejemplos de cómo los KACLS pueden utilizar esta información:
      • Imponer requisitos de registro adicionales.
      • Restringir el emisor de tokens de autenticación a un IdP invitado dedicado.
      • Solicitar reclamaciones 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é configurado como google-visitor o customer-idp. Se deben seguir aceptando las solicitudes con un email_type de google o con un email_type no establecido.
    • Verifica que la reclamación role en el token de autorización sea de “escritor” o “actualizador”.
    • Verifica que la reclamación kacls_url en el token de autorización coincida con la URL de KACLS actual. Esta verificación permite detectar posibles servidores de intermediarios configurados por usuarios con información privilegiada o administradores de dominio fraudulentos.
    • Realiza una verificación perimetral con reclamos 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
    • Datos sensibles adicionales
  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 que Google Workspace almacenará junto con el objeto encriptado y se enviará tal como está en cualquier operación posterior de separación de claves. También puedes mostrar una respuesta de error estructurada.

    • El objeto binario debe contener la única copia de la DEK encriptada. Se pueden almacenar datos específicos de 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 la URL de extremo de KACLS para su desencriptación. Además de las verificaciones de seguridad opcionales, como las verificaciones de perímetro y basadas en reclamaciones de JWT, tus KACLS deben realizar 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, busca 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, debe compararse con la reclamación de correo electrónico del token de autorización mediante un enfoque que no distingue mayúsculas de minúsculas. No uses la reclamación de correo electrónico dentro del token de autenticación para esta comparación.
    • Cuando 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 debe compararse con la reclamación de correo electrónico del token de autorización mediante un método que no distingue mayúsculas de minúsculas.
    • En los casos en que Google emite un token de autorización para un correo electrónico no asociado con una Cuenta de Google, debe estar presente la reclamación email_type. Esto es una parte fundamental de la función de acceso de invitado, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales a los usuarios externos.
      • Estos son algunos ejemplos de cómo los KACLS pueden utilizar esta información:
      • Imponer requisitos de registro adicionales.
      • Restringir el emisor de tokens de autenticación a un IdP invitado dedicado.
      • Solicitar reclamaciones 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é configurado como google-visitor o customer-idp. Se deben seguir aceptando las solicitudes con un email_type de google o con un email_type no establecido.
    • Verifica que la reclamación role en el token de autorización sea “reader” o “escritor”.
    • Verifica que la reclamación kacls_url en el token de autorización coincida con la URL de KACLS actual. Esto permite detectar posibles servidores intermediarios 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. Comprueba que el resource_name del token de autorización y el BLOB desencriptado coincidan.

  4. Realiza una verificación de perímetro con 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.