Chiffrer et déchiffrer des données

Ce guide explique comment le chiffrement et le déchiffrement fonctionnent à l'aide de l'API de chiffrement côté client de Google Workspace.

Vous devez ajouter à une liste d'autorisation tous les services de fournisseur d'identité (IdP) utilisés par les utilisateurs qui partagent des fichiers chiffrés. Vous trouverez généralement les informations requises sur l'IdP dans son fichier .well-known public. Sinon, contactez l'administrateur Google Workspace de l'organisation pour obtenir ces informations.

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 wrap requête à l'URL de votre point de terminaison du service de liste de contrôle d'accès aux clés (KACLS) pour le chiffrement. En plus des contrôles de sécurité facultatifs, tels que les contrôles basés sur le périmètre et les revendications JWT, votre KACLS doit effectuer les étapes suivantes :

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

   • Valider le jeton d'authentification et le jeton d'autorisation.
   • Vérifier que les jetons d'autorisation et d'authentification concernent le même utilisateur en effectuant une correspondance non sensible à la casse sur les revendications d'adresse e-mail.
   • Lorsque le jeton d'authentification contient la revendication facultative google_email, il doit être comparé à la revendication d'adresse e-mail du jeton d'autorisation à l'aide d'une approche non sensible à la casse. N'utilisez pas la revendication d'adresse e-mail dans le jeton d'authentification pour cette comparaison.
   • Dans les scénarios où le jeton d'authentification ne contient pas la revendication facultative google_email, la revendication d'adresse e-mail 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 scénarios où Google émet un jeton d'autorisation pour une adresse e-mail non associée à un compte Google, la revendication email_type doit être présente. Elle constitue un élément essentiel de la fonctionnalité d'accès invité, car elle fournit des informations précieuses au KACLS pour appliquer des mesures de sécurité supplémentaires aux utilisateurs externes.
     • Voici quelques exemples d'utilisation de ces informations par un KACLS :
     • Imposer des exigences de journalisation supplémentaires.
     • Restreindre l'émetteur du jeton d'authentification à un IdP 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 requêtes pour lesquelles email_type est défini sur google-visitor ou customer-idp peuvent être rejetées. Les requêtes avec un email_type défini sur google ou non défini email_type doivent continuer à être acceptées.
   • Lorsque le jeton d'authentification contient la revendication facultative delegated_to, il doit également contenir la revendication resource_name. Ces deux revendications doivent être comparées aux revendications delegated_to et resource_name du jeton d'autorisation. Les revendications delegated_to doivent être comparées à l'aide d'une approche non sensible à la casse, et le resource_name des jetons doit correspondre au resource_name de l'opération.
   • Vérifier que la revendication role du jeton d'autorisation est writer ou upgrader.
   • Vérifier que la revendication kacls_url du jeton d'autorisation correspond à l'URL KACLS actuelle. Cette vérification permet de détecter les serveurs potentiels d'attaque de l'homme du milieu configurés par des personnes internes ou des administrateurs de domaine malveillants.
   • Effectuer une vérification du périmètre à l'aide des revendications d'authentification et d'autorisation.

2. Chiffrer 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
   • Toutes les données sensibles supplémentaires

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

4. Renvoie un objet binaire opaque à stocker par Google Workspace avec l'objet chiffré et à envoyer tel quel dans toute opération de déchiffrement de clé ultérieure. Ou renvoyer une réponse d'erreur structurée.

   • L'objet binaire doit contenir la seule copie de la 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. Chiffrez-la et renvoyez-la dans l'objet wrapped_key pour éviter les écarts pendant la durée de vie du fichier. Google n'envoie pas de requêtes de suppression au 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 unwrap requête à l'URL de votre point de terminaison KACLS pour le déchiffrement. En plus des contrôles de sécurité facultatifs, tels que les contrôles basés sur le périmètre et les revendications JWT, votre KACLS doit effectuer les étapes suivantes :

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

   • Valider le jeton d'authentification et le jeton d'autorisation.
   • Vérifier que les jetons d'autorisation et d'authentification concernent le même utilisateur en effectuant une correspondance non sensible à la casse sur les revendications d'adresse e-mail.
   • Lorsque le jeton d'authentification contient la revendication facultative google_email, il doit être comparé à la revendication d'adresse e-mail du jeton d'autorisation à l'aide d'une approche non sensible à la casse. N'utilisez pas la revendication d'adresse e-mail dans le jeton d'authentification pour cette comparaison.
   • Dans les scénarios où le jeton d'authentification ne contient pas la revendication facultative google_email, la revendication d'adresse e-mail 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 scénarios où Google émet un jeton d'autorisation pour une adresse e-mail non associée à un compte Google, la revendication email_type doit être présente. Elle constitue un élément essentiel de la fonctionnalité d'accès invité, car elle fournit des informations précieuses au KACLS pour appliquer des mesures de sécurité supplémentaires aux utilisateurs externes.
     • Voici quelques exemples d'utilisation de ces informations par un KACLS :
     • Imposer des exigences de journalisation supplémentaires.
     • Restreindre l'émetteur du jeton d'authentification à un IdP 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 requêtes pour lesquelles email_type est défini sur google-visitor ou customer-idp peuvent être rejetées. Les requêtes avec un email_type défini sur google ou non défini email_type doivent continuer à être acceptées.
   • Lorsque le jeton d'authentification contient la revendication facultative delegated_to, il doit également contenir la revendication resource_name. Ces deux revendications doivent être comparées aux revendications delegated_to et resource_name du jeton d'autorisation. Les revendications delegated_to doivent être comparées à l'aide d'une approche non sensible à la casse, et le resource_name des jetons doit correspondre au resource_name de l'opération.
   • Vérifier que la revendication role du jeton d'autorisation est reader ou writer.
   • Vérifier que la revendication kacls_url du jeton d'autorisation correspond à l'URL KACLS actuelle. Cela permet de détecter les serveurs potentiels d'attaque de l'homme du milieu configurés par des personnes internes ou des administrateurs de domaine malveillants.

2. Déchiffrer 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
   • Toutes les données sensibles supplémentaires

3. Vérifier que le resource_name du jeton d'autorisation et le blob déchiffré correspondent.

4. Effectuer 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, le resource_name et le motif transmis dans la requête.

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

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