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 Google Workspace.

Vous devez ajouter à la 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 leur 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 requête wrap à l'URL de point de terminaison de votre service de liste de contrôle d'accès aux clés (KACLS) pour le chiffrement. En plus des vérifications de sécurité facultatives, telles que les vérifications basées sur le périmètre et les 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 sont destinés au même utilisateur en effectuant une correspondance insensible à la casse sur les revendications d'adresse e-mail.
    • Lorsque le jeton d'authentification contient la revendication google_email facultative, il doit être comparé à la revendication d'adresse e-mail dans le jeton d'autorisation en utilisant une approche insensible à 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 comporte pas la revendication google_email facultative, la revendication d'adresse e-mail dans le jeton d'authentification doit être comparée à la revendication d'adresse e-mail dans le jeton d'autorisation, à l'aide d'une méthode insensible à la casse.
    • Dans les cas 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. Cela constitue un élément essentiel de la fonctionnalité d'accès invité, car cela fournit des informations précieuses aux 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.
      • Pour limiter l'émetteur de jetons 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 où email_type est défini sur google-visitor ou customer-idp peuvent être refusées. Les requêtes avec un email_type de google ou avec un email_type non défini doivent continuer à être acceptées.
    • Lorsque le jeton d'authentification contient la revendication delegated_to facultative, 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 insensible à la casse, et le resource_name dans les jetons doit correspondre au resource_name de l'opération.
    • Vérifiez que la revendication role dans le jeton d'autorisation est writer ou upgrader.
    • Vérifiez que la revendication kacls_url du jeton d'autorisation correspond à l'URL KACLS actuelle. Cette vérification permet de détecter les serveurs d'attaque de l'homme du milieu potentiels configurés par des personnes internes ou des administrateurs de domaine malveillants.
    • Effectuez une vérification du périmètre à l'aide des 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 autre donnée sensible

  3. Consignez 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 qui sera stocké par Google Workspace à côté de l'objet chiffré et envoyé tel quel lors de toute opération de déchiffrement de clé ultérieure. Vous pouvez également fournir 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.

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 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. 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 sont destinés au même utilisateur en effectuant une correspondance insensible à la casse sur les revendications d'adresse e-mail.
    • Lorsque le jeton d'authentification contient la revendication google_email facultative, il doit être comparé à la revendication d'adresse e-mail dans le jeton d'autorisation en utilisant une approche insensible à 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 comporte pas la revendication google_email facultative, la revendication d'adresse e-mail dans le jeton d'authentification doit être comparée à la revendication d'adresse e-mail dans le jeton d'autorisation, à l'aide d'une méthode insensible à la casse.
    • Dans les cas 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. Cela constitue un élément essentiel de la fonctionnalité d'accès invité, car cela fournit des informations précieuses aux 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.
      • Pour limiter l'émetteur de jetons 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 où email_type est défini sur google-visitor ou customer-idp peuvent être refusées. Les requêtes avec un email_type de google ou avec un email_type non défini doivent continuer à être acceptées.
    • Lorsque le jeton d'authentification contient la revendication delegated_to facultative, 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 insensible à la casse, et le resource_name dans les jetons doit correspondre au resource_name de l'opération.
    • Vérifiez que la revendication role dans le jeton d'autorisation est reader ou writer.
    • Vérifiez 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é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 autre donnée sensible

  3. Vérifiez que le 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 l'utilisateur à l'origine de l'opération, le resource_name et le motif transmis dans la requête.

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