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 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 requeridos 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 KACLS para la encriptación. Además de las verificaciones de seguridad opcionales, como las verificaciones perimetrales y 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 del mismo usuario. Para ello, realiza una coincidencia sin distinción de mayúsculas o minúsculas en los reclamos 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 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.
    • En situaciones en las que el token de autenticación no tiene el reclamo opcional de google_email, 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, con 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 que no está asociado con una Cuenta de Google, debe estar presente el reclamo email_type. Esto forma parte fundamental de la función de acceso de invitados, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales en los usuarios externos.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Para imponer requisitos de registro adicionales.
      • Restringir el emisor del token de autenticación a un IdP para invitados exclusivo
      • 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é 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 declaración role en el token de autorización sea "writer" o "upgrader".
    • Verifica que la declaració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 personas internas o administradores de dominio no autorizados.
    • Realiza una verificación del perímetro con reclamos de autenticación y autorización.

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

    • 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 enviará tal como está en cualquier operación de desencriptación de claves posterior. O bien, publica una respuesta de error estructurada.

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

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 KACLS para desencriptarlos. Además de las verificaciones de seguridad opcionales, como las verificaciones perimetrales y 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.
    • Para verificar que los tokens de autorización y autenticación sean del mismo usuario, realiza una coincidencia sin distinción de mayúsculas o minúsculas en los reclamos 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 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.
    • En situaciones en las que el token de autenticación no tiene el reclamo opcional de google_email, 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, con 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 que no está asociado con una Cuenta de Google, debe estar presente el reclamo email_type. Esto forma parte fundamental de la función de acceso de invitados, ya que proporciona información valiosa para que KACLS aplique medidas de seguridad adicionales en los usuarios externos.
      • Estos son algunos ejemplos de cómo un KACLS puede usar esta información:
      • Para imponer requisitos de registro adicionales.
      • Restringir el emisor del token de autenticación a un IdP para invitados exclusivo
      • 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é 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 declaración role en el token de autorización sea "reader" o "writer".
    • Verifica que la declaración kacls_url en el token de autorización coincida con la URL de KACLS actual. Esto permite detectar posibles servidores de intermediarios configurados por personas internas o administradores de dominios no autorizados.

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

    • 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 descifrado coincidan.

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