Chiffrer et déchiffrer des données

Ce guide décrit le fonctionnement du chiffrement et du déchiffrement à l'aide de l'API Google Workspace Client-side Encryption.

Vous devez ajouter à la liste d'autorisation tous les services du fournisseur d'identité (IdP) utilisés par les utilisateurs partager des fichiers chiffrés. Vous trouverez généralement les informations sur le fournisseur d'identité requis dans son fichier .well-known accessible au public Sinon, contactez le administrateur Google Workspace pour obtenir les informations sur son IdP.

Chiffrer des données

Lorsqu'un utilisateur Google Workspace demande à enregistrer ou à stocker des données chiffrées côté client (CSE), Google Workspace envoie une requête wrap à l'URL de votre point de terminaison KACLS pour le chiffrement. En plus des contrôles de sécurité, tels que les contrôles basés sur le périmètre et les revendications JWT, vos KACLS doivent procédez comme suit:

  1. Validez l'utilisateur demandeur.

    • Validez à la fois le jeton d'authentification et le jeton d'autorisation.
    • Vérifiez que les jetons d'autorisation et d'authentification sont pour le même utilisateur en une correspondance non sensible à la casse pour les revendications envoyées par e-mail.
    • Lorsque le jeton d'authentification contient la revendication facultative google_email, il doit être comparé à la revendication par e-mail du jeton d'autorisation en utilisant une approche non sensible à la casse. N'utilisez pas la revendication par e-mail dans le d'authentification unique pour cette comparaison.
    • Dans les cas où le jeton d'authentification ne dispose pas Revendication google_email, la revendication de l'adresse e-mail dans le jeton d'authentification doit être comparé à la revendication par e-mail du jeton d'autorisation, à l'aide d'une méthode non sensible à la casse.
    • Dans les cas où Google émet un jeton d'autorisation pour un e-mail associé à un compte Google, la revendication email_type doit être présente. Il s'agit d'un élément essentiel de la fonctionnalité d'accès invité, permettant à KACLS d'appliquer des mesures de sécurité supplémentaires sur les utilisateurs.
      • Voici quelques exemples de la façon dont une KACLS peut utiliser ces informations:
      • Pour imposer des exigences de journalisation supplémentaires
      • Pour limiter l'émetteur de jetons d'authentification à un fournisseur d'identité invité dédié.
      • Exiger des revendications supplémentaires sur le jeton d'authentification.
      • Si un client n'a pas configuré l'accès invité, toutes les demandes où email_type est défini sur google-visitor ou customer-idp peut être refusé. Requêtes dont l'attribut email_type est google ou dont la valeur n'est pas définie email_type devrait toujours être accepté.
    • Vérifiez que la revendication role du jeton d'autorisation est "writer" ou « upgrader ».
    • Vérifiez que la revendication kacls_url du jeton d'autorisation correspond à URL KACLS actuelle. Cette vérification permet de détecter des serveurs man-in-the-middle configurés par des initiés ou des domaines dont l'accès est frauduleux. les administrateurs.
    • Effectuer une vérification de périmètre à l'aide de l'authentification et de l'autorisation des revendications.

  2. Chiffrez les éléments suivants à l'aide d'un algorithme de chiffrement authentifié:

    • Clé de chiffrement des données (DEK)
    • Les valeurs resource_name et perimeter_id du jeton d'autorisation
    • Toute donnée sensible supplémentaire

  3. Consigner l'opération, y compris l'utilisateur à l'origine de l'opération, les resource_name et le motif transmis dans la demande.

  4. Renvoyez un objet binaire opaque à stocker par Google Workspace en même temps que celui-ci. l'objet chiffré et envoyé tel quel lors de toute désencapsulation de clé ultérieure opération. Vous pouvez également diffuser une réponse d'erreur structurée.

    • L'objet binaire doit contenir la seule copie de la clé DEK chiffrée, des données spécifiques à l'implémentation peuvent y être stockées.

Déchiffrer des données

Lorsqu'un utilisateur Google Workspace demande à ouvrir des données chiffrées côté client (CSE), Google Workspace envoie une requête unwrap à l'URL du point de terminaison KACLS pour le déchiffrement. En plus des options de sécurité telles que les vérifications de périmètre et basées sur les revendications JWT, votre KACLS doit effectuer procédez comme suit:

  1. Validez l'utilisateur demandeur.

    • Validez à la fois le jeton d'authentification et le jeton d'autorisation.
    • Vérifiez que les jetons d'autorisation et d'authentification sont pour le même utilisateur en une correspondance non sensible à la casse pour les revendications envoyées par e-mail.
    • Lorsque le jeton d'authentification contient la revendication facultative google_email, il doit être comparé à la revendication par e-mail du jeton d'autorisation en utilisant une approche non sensible à la casse. N'utilisez pas la revendication par e-mail dans le d'authentification unique pour cette comparaison.
    • Dans les cas où le jeton d'authentification ne dispose pas Revendication google_email, la revendication de l'adresse e-mail dans le jeton d'authentification doit être comparé à la revendication par e-mail du jeton d'autorisation, à l'aide d'une méthode non sensible à la casse.
    • Dans les cas où Google émet un jeton d'autorisation pour un e-mail associé à un compte Google, la revendication email_type doit être présente. Il s'agit d'un élément essentiel de la fonctionnalité d'accès invité, permettant à KACLS d'appliquer des mesures de sécurité supplémentaires sur les utilisateurs.
      • Voici quelques exemples de la façon dont une KACLS peut utiliser ces informations:
      • Pour imposer des exigences de journalisation supplémentaires
      • Pour limiter l'émetteur de jetons d'authentification à un fournisseur d'identité invité dédié.
      • Exiger des revendications supplémentaires sur le jeton d'authentification.
      • Si un client n'a pas configuré l'accès invité, toutes les demandes où email_type est défini sur google-visitor ou customer-idp peut être refusé. Requêtes dont l'attribut email_type est google ou dont la valeur n'est pas définie email_type devrait toujours être accepté.
    • Vérifiez que la revendication role du jeton d'autorisation est "reader" (lecteur) ou "writer".
    • Vérifiez que la revendication kacls_url du jeton d'autorisation correspond à URL KACLS actuelle. Cela permet de détecter d'éventuels "man-in-the-middle" configurés par des initiés ou des administrateurs de domaines dont l'accès est frauduleux.

  2. Déchiffrez les parties suivantes à l'aide d'un algorithme de chiffrement authentifié:

    • Clé de chiffrement des données (DEK)
    • Les valeurs resource_name et perimeter_id du jeton d'autorisation
    • Toute donnée sensible supplémentaire

  3. Vérifiez que resource_name dans le jeton d'autorisation et l'objet blob déchiffré correspond.

  4. Effectuez une vérification du périmètre à l'aide des revendications d'authentification et d'autorisation.

  5. Consigner l'opération, y compris l'utilisateur à l'origine de l'opération, les resource_name et le motif transmis dans la demande.

  6. Renvoyez la DEK désencapsulée ou une réponse d'erreur structurée.