Ce guide explique le fonctionnement du chiffrement et du déchiffrement à 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 le fichier .well-known public. Sinon, contactez l'administrateur Google Workspace de l'organisation pour obtenir les informations sur 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 point de terminaison 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:
Validez l'utilisateur à l'origine de la demande.
- Validez à la fois le jeton d'authentification et le jeton d'autorisation.
- Vérifiez que les jetons d'autorisation et d'authentification concernent le même utilisateur en effectuant une mise en 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 à l'aide d'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 du jeton d'authentification doit être comparée à celle du jeton d'autorisation, à l'aide d'une méthode insensible à la casse. - Lorsque 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 une partie essentielle de la fonctionnalité d'accès invité, fournissant des informations précieuses pour que KACLS applique 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 du jeton d'authentification à un IdP pour les invités 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 surgoogle-visitor
oucustomer-idp
peuvent être refusées. Les requêtes avec une valeurgoogle
pouremail_type
ou avec unemail_type
non 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
du jeton d'autorisation correspond à l'URL KACLS actuelle. Cette vérification permet de détecter les serveurs potentiels de l'intercepteur configurés par des initiés ou des administrateurs de domaine non autorisés. - Effectuez une vérification du périmètre à l'aide d'affirmations d'authentification et d'autorisation.
Chiffrez les parties suivantes à l'aide d'un algorithme de chiffrement authentifié:
- Clé de chiffrement de données (DEK)
- Les valeurs
resource_name
etperimeter_id
du jeton d'autorisation - Toute autre donnée sensible
Enregistrez l'opération, y compris l'utilisateur à l'origine, le
resource_name
et le motif transmis dans la requête.Renvoie un objet binaire opaque à stocker par Google Workspace avec l'objet chiffré et envoyé tel quel dans toute opération de déballage de clé ultérieure. Vous pouvez également 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.
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 basées sur le périmètre et les revendications JWT, votre KACLS doit effectuer les étapes suivantes:
Validez l'utilisateur à l'origine de la demande.
- Validez à la fois le jeton d'authentification et le jeton d'autorisation.
- Vérifiez que les jetons d'autorisation et d'authentification concernent le même utilisateur en effectuant une mise en 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 à l'aide d'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 du jeton d'authentification doit être comparée à celle du jeton d'autorisation, à l'aide d'une méthode insensible à la casse. - Lorsque 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 une partie essentielle de la fonctionnalité d'accès invité, fournissant des informations précieuses pour que KACLS applique 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 du jeton d'authentification à un IdP pour les invités 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 surgoogle-visitor
oucustomer-idp
peuvent être refusées. Les requêtes avec une valeurgoogle
pouremail_type
ou avec unemail_type
non défini doivent continuer à être acceptées.
- 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 de l'intercepteur configurés par des initiés ou des administrateurs de domaine malveillants.
Déchiffrez les parties suivantes à l'aide d'un algorithme de chiffrement authentifié:
- Clé de chiffrement de données (DEK)
- Les valeurs
resource_name
etperimeter_id
du jeton d'autorisation - Toute autre donnée sensible
Vérifiez que le
resource_name
du jeton d'autorisation et du blob déchiffré correspondent.Effectuez une vérification du périmètre à l'aide d'affirmations d'authentification et d'autorisation.
Enregistrez l'opération, y compris l'utilisateur à l'origine, le
resource_name
et le motif transmis dans la requête.Renvoyez la clé DEK désencapsulée ou une réponse d'erreur structurée.