Créer un service de clés personnalisé pour le chiffrement côté client
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous pouvez chiffrer les données de votre organisation à l'aide de vos propres clés de chiffrement au lieu d'utiliser le chiffrement fourni par Google Workspace. Avec le chiffrement côté client (CSE) Google Workspace, le chiffrement des fichiers est géré dans le navigateur du client avant leur stockage dans le cloud via Drive. De cette façon, les serveurs Google ne peuvent pas accéder à vos clés de chiffrement et, par conséquent, ne peuvent pas déchiffrer vos données. Pour en savoir plus, consultez À propos du chiffrement côté client.
Cette API vous permet de contrôler les clés de chiffrement de premier niveau qui protègent vos données à l'aide d'un service de clés externes personnalisé. Une fois que vous avez créé un service de clés externe avec cette API, les administrateurs Google Workspace peuvent s'y connecter et activer le CSE pour leurs utilisateurs.
Terminologie importante
Vous trouverez ci-dessous une liste des termes courants utilisés dans l'API Google Workspace Client-side Encryption :
- Chiffrement côté client (CSE)
- Chiffrement géré dans le navigateur du client avant le stockage dans un espace de stockage cloud. Cela empêche le fournisseur de stockage de lire le fichier. En savoir plus
- Service de liste de contrôle d'accès aux clés (KACLS)
- Votre service de clés externe qui utilise cette API pour contrôler l'accès aux clés de chiffrement stockées dans un système externe.
- Fournisseur d'identité (IdP)
- Service qui authentifie les utilisateurs avant qu'ils ne puissent chiffrer des fichiers ou accéder à des fichiers chiffrés.
Chiffrement et déchiffrement
- Clé de chiffrement de données (DEK)
- Clé utilisée par Google Workspace dans le client du navigateur pour chiffrer les données elles-mêmes.
- Clé de chiffrement de clé (KEK)
- Clé de votre service utilisée pour chiffrer une clé de chiffrement des données (DEK).
Contrôle des accès
- Liste de contrôle d'accès (LCA)
- Liste des utilisateurs ou des groupes autorisés à ouvrir ou à lire un fichier.
- Jeton Web JSON (JWT) d'authentification
- Jeton de support (JWT : RFC 7516) émis par le partenaire d'identité (IdP) pour attester de l'identité d'un utilisateur.
- Jeton Web JSON (JWT) d'autorisation
- Jeton du porteur (JWT : RFC 7516) émis par Google pour vérifier que l'appelant est autorisé à chiffrer ou déchiffrer une ressource.
- Ensemble de clés Web JSON (JWKS)
- URL de point de terminaison en lecture seule qui pointe vers une liste de clés publiques utilisées pour valider les jetons Web JSON (JWT).
- Périmètre
- Vérifications supplémentaires effectuées sur les jetons d'authentification et d'autorisation dans le KACLS pour le contrôle des accès.
Processus de chiffrement côté client
Une fois qu'un administrateur a activé le CSE pour son organisation, les utilisateurs pour lesquels le CSE est activé peuvent choisir de créer des documents chiffrés à l'aide des outils de création de contenu collaboratif Google Workspace, comme Docs et Sheets, ou de chiffrer les fichiers qu'ils importent dans Google Drive, comme les PDF.
Une fois que l'utilisateur a chiffré un document ou un fichier :
Google Workspace génère une DEK dans le navigateur client pour chiffrer le contenu.
Google Workspace envoie la clé de chiffrement des données et les jetons d'authentification à votre KACLS tiers pour le chiffrement, à l'aide d'une URL que vous fournissez à l'administrateur de l'organisation Google Workspace.
Votre KACLS utilise cette API pour chiffrer la DEK, puis renvoie la DEK chiffrée et obscurcie à Google Workspace.
Google Workspace stocke les données obscurcies et chiffrées dans le cloud.
Seuls les utilisateurs ayant accès à votre KACLS peuvent accéder aux données.
Pour en savoir plus, consultez Chiffrer et déchiffrer des fichiers.
Étapes suivantes
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/29 (UTC).
[null,null,["Dernière mise à jour le 2025/08/29 (UTC)."],[[["\u003cp\u003eGoogle Workspace Client-side Encryption (CSE) allows you to encrypt your organization's data with your own keys, preventing Google servers from accessing or decrypting it.\u003c/p\u003e\n"],["\u003cp\u003eThis API enables you to manage the encryption keys via an external key service, giving you control over data access.\u003c/p\u003e\n"],["\u003cp\u003eCSE encrypts files in the user's browser before they are stored in Google Drive, ensuring only authorized users with access to your external key service can decrypt them.\u003c/p\u003e\n"],["\u003cp\u003eWhen a file is encrypted, Google Workspace generates a Data Encryption Key (DEK), which is then encrypted by your external key service and stored with the encrypted data.\u003c/p\u003e\n"],["\u003cp\u003eTo get started, you can configure your external key service and learn how to encrypt and decrypt data using the provided guides.\u003c/p\u003e\n"]]],["Google Workspace Client-side Encryption (CSE) allows users to encrypt data in their browser before cloud storage. This is achieved by using your own external Key Access Control List Service (KACLS). Google Workspace generates a Data Encryption Key (DEK) and sends it to your KACLS for encryption with a Key Encryption Key (KEK). Your service then returns the encrypted DEK to Google Workspace. This ensures that only users with KACLS access can decrypt the stored data.\n"],null,["# Build a custom key service for client-side encryption\n\nYou can use your own encryption keys to encrypt your organization's data,\ninstead of using the encryption that Google Workspace provides. With Google Workspace Client-side Encryption (CSE), file encryption is handled in the\nclient's browser before it's stored in Drive's cloud-based storage. That way,\nGoogle servers can't access your encryption keys and, therefore, can't decrypt\nyour data. For more details, see\n[About client-side encryption](https://support.google.com/a/answer/10741897#zippy=%2Cbasic-setup-steps-for-cse).\n\nThis API lets you control the top-level encryption keys that protect your data\nwith a custom external key service. After you create an external key service\nwith this API, Google Workspace administrators can connect to it and enable CSE\nfor their users.\n\nImportant terminology\n---------------------\n\nBelow is a list of common terms used in the Google Workspace Client-side Encryption API:\n\n*Client-side encryption (CSE)*\n: Encryption that's handled in the client's browser before it's stored in\n cloud-based storage. This protects the file from being read by the storage\n provider. [Learn more](https://support.google.com/a/answer/10741897#zippy=%2Chow-is-cse-different-from-end-to-end-ee-encryption)\n\n*Key Access Control List Service (KACLS)*\n: Your external key service that uses this API to control access to encryption\n keys stored in an external system.\n\n*Identity Provider (IdP)*\n: The service that authenticates users before they can encrypt files or access\n encrypted files.\n\n### Encryption \\& decryption\n\n*Data Encryption Key (DEK)*\n: The key used by Google Workspace in the browser client to encrypt the data\n itself.\n\n*Key Encryption Key (KEK)*\n: A key from your service used to encrypt a Data Encryption Key (DEK).\n\n### Access control\n\n*Access Control List (ACL)*\n: A list of users or groups that can open or read a file.\n\n*Authentication JSON Web Token (JWT)*\n: Bearer token ([JWT: RFC 7516](https://tools.ietf.org/html/rfc7516))\n issued by the identity partner (IdP) to attest a user's identity.\n\n*Authorization JSON Web Token (JWT)*\n: Bearer token ([JWT: RFC 7516](https://tools.ietf.org/html/rfc7516))\n issued by Google to verify that the caller is authorized to encrypt or decrypt a resource.\n\n*JSON Web Key Set (JWKS)*\n: A read-only endpoint URL that points to a list of public keys used to verify\n JSON Web Tokens (JWT).\n\n*Perimeter*\n: Additional checks performed on the authentication and authorization tokens\n within the KACLS for access control.\n\nClient-side encryption process\n------------------------------\n\nAfter an administrator enables CSE for their organization, users for whom CSE is\nenabled can choose to create encrypted documents using the Google Workspace\ncollaborative content creation tools, like Docs and Sheets, or encrypt files\nthey upload to Google Drive, such as PDFs.\n\nAfter the user encrypts a document or file:\n\n1. Google Workspace generates a DEK in the client browser to encrypt the\n content.\n\n2. Google Workspace sends the DEK and authentication tokens to your third-party\n KACLS for encryption, using a URL you provide to the\n Google Workspace organization's administrator.\n\n3. Your KACLS uses this API to encrypt the DEK, then sends the obfuscated,\n encrypted DEK back to Google Workspace.\n\n4. Google Workspace stores the obfuscated, encrypted data in the cloud.\n Only users with access to your KACLS are able to access the data.\n\nFor more details, see [Encrypt and decrypt files](/workspace/cse/guides/encrypt-and-decrypt-data).\n\nNext steps\n----------\n\n- Learn how to [configure your service](/workspace/cse/guides/configure-service).\n- Learn how to [encrypt \\& decrypt data](/workspace/cse/guides/encrypt-and-decrypt-data)."]]
