Criptografar e descriptografar dados

Neste guia, descrevemos como a criptografia e a descriptografia funcionam com a API Google Workspace Client-side Encryption.

Você precisa autorizar todos os serviços de provedor de identidade (IdP) usados pelos usuários compartilhar arquivos criptografados. Geralmente, é possível encontrar os detalhes necessários do IdP na arquivo .well-known disponível publicamente, caso contrário, entre em contato com o administrador do Google Workspace para conferir os detalhes do IdP.

Criptografar dados

Quando um usuário do Google Workspace pede para salvar ou armazenar arquivos criptografados do lado do cliente (CSE), o Google Workspace envia um wrap solicitação ao URL do endpoint do KACLS para criptografia. Além de opções de segurança, como verificações baseadas em declarações de perímetro e JWT, o KACLS precisa siga estas etapas:

  1. Validar o usuário solicitante

    • Valide o token de autenticação e o token de autorização.
    • Verifique se os tokens de autorização e autenticação são para o mesmo usuário fazer uma correspondência que não diferencia maiúsculas de minúsculas nas declarações de e-mail.
    • Quando o token de autenticação contém a declaração google_email opcional, ele precisa ser comparado com a declaração por e-mail no token de autorização usando uma abordagem que não diferencia maiúsculas de minúsculas. Não use a reivindicação por e-mail no token de autenticação para esta comparação.
    • Em cenários em que o token de autenticação não tem o token Declaração google_email, a declaração do e-mail no token de autenticação deve ser comparado com a declaração do e-mail no token de autorização, usando um método que não diferencia maiúsculas de minúsculas.
    • Nos casos em que o Google emite um token de autorização para um e-mail que não associadas a uma Conta do Google, a reivindicação email_type deve estar presente. Isso é uma parte crucial do recurso Acesso para convidados, oferecendo informações para a KACLS aplicar outras medidas de segurança em sistemas usuários.
      • Alguns exemplos de como um KACLS pode usar essas informações:
      • Para impor outros requisitos de geração de registros.
      • Restringir o emissor do token de autenticação a um IdP convidado dedicado.
      • Para exigir mais declarações no token de autenticação.
      • Se um cliente não tiver configurado o acesso de convidado, todas as solicitações em que email_type é definido como google-visitor ou customer-idp pode ser recusados. Solicitações com um email_type de google ou sem definição email_type deve continuar sendo aceito.
    • Verifique se a declaração role no token de autorização é "writer" ou "upgrader".
    • Verifique se a declaração kacls_url no token de autorização corresponde à URL atual do KACLS. Essa verificação permite detectar servidores "man-in-the-middle" configurados por pessoas com informações privilegiadas ou domínios não autorizados administradores.
    • Executar uma verificação de perímetro usando autenticação e autorização reivindicações.

  2. Criptografe as seguintes partes usando um algoritmo de criptografia autenticado:

    • Chave de criptografia de dados (DEK)
    • Os valores resource_name e perimeter_id do token de autorização
    • Outros dados sensíveis

  3. Registre a operação, incluindo o usuário que a originou, os resource_name e o motivo informado na solicitação.

  4. Retorne um objeto binário opaco para ser armazenado pelo Google Workspace junto com o objeto criptografado e enviado como está em qualquer desencapsulamento de chave subsequente operação Outra opção é exibir uma resposta de erro estruturada.

    • O objeto binário deve conter a única cópia da DEK criptografada, dados específicos da implementação podem ser armazenados nela.
.

Descriptografar dados

Quando um usuário do Google Workspace solicita a abertura de dados criptografados do lado do cliente (CSE), O Google Workspace envia uma solicitação unwrap. ao URL do endpoint do KACLS para descriptografia. Além da segurança opcional de perímetro e com base em declarações JWT, o KACLS precisa realizar as seguintes etapas:

  1. Validar o usuário solicitante

    • Valide o token de autenticação e o token de autorização.
    • Verifique se os tokens de autorização e autenticação são para o mesmo usuário fazer uma correspondência que não diferencia maiúsculas de minúsculas nas declarações de e-mail.
    • Quando o token de autenticação contém a declaração google_email opcional, ele precisa ser comparado com a declaração por e-mail no token de autorização usando uma abordagem que não diferencia maiúsculas de minúsculas. Não use a reivindicação por e-mail no token de autenticação para esta comparação.
    • Em cenários em que o token de autenticação não tem o token Declaração google_email, a declaração do e-mail no token de autenticação deve ser comparado com a declaração do e-mail no token de autorização, usando um método que não diferencia maiúsculas de minúsculas.
    • Nos casos em que o Google emite um token de autorização para um e-mail que não associadas a uma Conta do Google, a reivindicação email_type deve estar presente. Isso é uma parte crucial do recurso Acesso para convidados, oferecendo informações para a KACLS aplicar outras medidas de segurança em sistemas usuários.
      • Alguns exemplos de como um KACLS pode usar essas informações:
      • Para impor outros requisitos de geração de registros.
      • Restringir o emissor do token de autenticação a um IdP convidado dedicado.
      • Para exigir mais declarações no token de autenticação.
      • Se um cliente não tiver configurado o acesso de convidado, todas as solicitações em que email_type é definido como google-visitor ou customer-idp pode ser recusados. Solicitações com um email_type de google ou sem definição email_type deve continuar sendo aceito.
    • Verifique se a declaração role no token de autorização é "reader" ou "escritor".
    • Verifique se a declaração kacls_url no token de autorização corresponde à URL atual do KACLS. Com isso, é possível detectar servidores configurados por pessoas com informações privilegiadas ou administradores de domínio não autorizados.

  2. Descriptografe as seguintes partes usando um algoritmo de criptografia autenticado:

    • Chave de criptografia de dados (DEK)
    • Os valores resource_name e perimeter_id do token de autorização
    • Outros dados sensíveis

  3. Verificar se o resource_name no token de autorização e no blob descriptografado são correspondentes.

  4. Executar uma verificação de perímetro usando declarações de autenticação e autorização.

  5. Registre a operação, incluindo o usuário que a originou, os resource_name e o motivo informado na solicitação.

  6. Retorne a DEK desencapsulada ou uma resposta de erro estruturada.

.