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 autoriser tous les services de fournisseur d'identité (IdP) utilisés par les utilisateurs qui partagent des fichiers chiffrés. Les informations sur l'IdP requis se trouvent généralement dans leur fichier .well-known accessible au public. Sinon, contactez l'administrateur Google Workspace de l'organisation pour connaître les détails de l'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 chiffrement. En plus des contrôles de sécurité facultatifs, tels que les vérifications de périmètre et basées sur des revendications JWT, votre KACLS doit effectuer les étapes suivantes:

1. Validez l'utilisateur à l'origine de la demande.

   • Validez le jeton d'authentification et le jeton d'autorisation.
   • Vérifiez que les jetons d'autorisation et d'authentification correspondent au même utilisateur en effectuant une correspondance non sensible à la casse avec les revendications d'e-mail.
   • Lorsque le jeton d'authentification contient la revendication google_email facultative, elle doit être comparée à 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 jeton d'authentification pour cette comparaison.
   • Dans les cas où le jeton d'authentification ne dispose pas de la revendication google_email facultative, la revendication d'adresse e-mail au sein du jeton d'authentification doit être comparée à la revendication d'adresse 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 une adresse e-mail qui n'est pas associée à un compte Google, la revendication email_type doit être présente. Il s'agit d'un élément crucial de la fonctionnalité d'accès invité, car il fournit des informations précieuses à KACLS pour appliquer des mesures de sécurité supplémentaires aux utilisateurs externes.
     • Voici quelques exemples de la manière dont un KACLS peut utiliser ces informations:
     • Imposer des exigences de journalisation supplémentaires
     • Limiter l'émetteur du jeton d'authentification à un IdP invité dédié.
     • Pour exiger des revendications supplémentaires sur le jeton d'authentification
     • Si un client n'a pas configuré l'accès invité, toutes les requêtes pour lesquelles email_type est défini sur google-visitor ou customer-idp peuvent être refusées. Les requêtes dont l'état (email_type) est défini sur google ou dont l'état (email_type) n'est pas défini doivent continuer à être acceptées.
   • Vérifiez que la revendication role dans le jeton d'autorisation est "writer" ou "upgrader".
   • Vérifiez que la revendication kacls_url dans le jeton d'autorisation correspond à l'URL KACLS actuelle. Cette vérification permet de détecter les serveurs man-in-the-middle potentiels configurés par des initiés ou des administrateurs de domaine malveillants.
   • Effectuez une vérification du périmètre à l'aide de revendications d'authentification et d'autorisation.

2. 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. Consignez l'opération, y compris son auteur, la resource_name et le motif transmis dans la requête.

4. Renvoie un objet binaire opaque qui sera stocké par Google Workspace avec l'objet chiffré et sera envoyé tel quel lors de toute opération de désencapsulation de clé ultérieure. 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.

Remarque :Ne stockez pas la DEK dans votre système KACLS. À la place, chiffrez-le et renvoyez-le dans l'objet wrapped_key pour éviter tout écart pendant toute la durée de vie du fichier. Google n'envoie pas de demandes de suppression au système KACLS lorsque des objets sont supprimés.

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 de votre point de terminaison KACLS pour le déchiffrement. En plus des vérifications de sécurité facultatives, telles que les vérifications de périmètre et basées sur des revendications JWT, votre liste KACLS doit effectuer les étapes suivantes:

1. Validez l'utilisateur à l'origine de la demande.

   • Validez le jeton d'authentification et le jeton d'autorisation.
   • Vérifiez que les jetons d'autorisation et d'authentification correspondent au même utilisateur en effectuant une correspondance non sensible à la casse avec les revendications d'e-mail.
   • Lorsque le jeton d'authentification contient la revendication google_email facultative, elle doit être comparée à 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 jeton d'authentification pour cette comparaison.
   • Dans les cas où le jeton d'authentification ne dispose pas de la revendication google_email facultative, la revendication d'adresse e-mail au sein du jeton d'authentification doit être comparée à la revendication d'adresse 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 une adresse e-mail qui n'est pas associée à un compte Google, la revendication email_type doit être présente. Il s'agit d'un élément crucial de la fonctionnalité d'accès invité, car il fournit des informations précieuses à KACLS pour appliquer des mesures de sécurité supplémentaires aux utilisateurs externes.
     • Voici quelques exemples de la manière dont un KACLS peut utiliser ces informations:
     • Imposer des exigences de journalisation supplémentaires
     • Limiter l'émetteur du jeton d'authentification à un IdP invité dédié.
     • Pour exiger des revendications supplémentaires sur le jeton d'authentification
     • Si un client n'a pas configuré l'accès invité, toutes les requêtes pour lesquelles email_type est défini sur google-visitor ou customer-idp peuvent être refusées. Les requêtes dont l'état (email_type) est défini sur google ou dont l'état (email_type) n'est pas défini doivent continuer à être acceptées.
   • Vérifiez que la revendication role dans le jeton d'autorisation est "Lecteur" ou "Rédacteur".
   • Vérifiez que la revendication kacls_url dans le jeton d'autorisation correspond à l'URL KACLS actuelle. Cela permet de détecter les serveurs man-in-the-middle potentiels configurés par des initiés ou des administrateurs de domaine malveillants.

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 la valeur resource_name du jeton d'autorisation et du blob déchiffré correspondent.

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

5. Consignez l'opération, y compris son auteur, la resource_name et le motif transmis dans la requête.

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

Remarque :Pour déchiffrer les requêtes Google Takeout, consultez takeout_unwrap.