Crea un servizio chiavi personalizzato per la crittografia lato client
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Puoi utilizzare le tue chiavi di crittografia per criptare i dati della tua organizzazione,
anziché utilizzare la crittografia fornita da Google Workspace. Con la crittografia lato client di Google Workspace, la crittografia dei file viene gestita nel browser del client prima che vengano archiviati nello spazio di archiviazione basato su cloud di Drive. In questo modo,
i server di Google non possono accedere alle tue chiavi di crittografia e, pertanto, non possono decriptare
i tuoi dati. Per maggiori dettagli, vedi
Informazioni sulla crittografia lato client.
Questa API ti consente di controllare le chiavi di crittografia di primo livello che proteggono i tuoi dati
con un servizio chiavi esterno personalizzato. Dopo aver creato un servizio chiavi esterno
con questa API, gli amministratori di Google Workspace possono connettersi e attivare la crittografia lato client
per i loro utenti.
Terminologia importante
Di seguito è riportato un elenco di termini comuni utilizzati nell'API crittografia lato client di Google Workspace:
- Crittografia lato client
- Crittografia gestita nel browser del client prima di essere archiviata nello spazio di archiviazione basato su cloud. In questo modo, il file non può essere letto dal provider di spazio di archiviazione. Scopri di più
- Key Access Control List Service (KACLS)
- Il tuo servizio chiavi esterno che utilizza questa API per controllare l'accesso alle chiavi di crittografia archiviate in un sistema esterno.
- Provider di identità (IdP)
- Il servizio che autentica gli utenti prima che possano criptare file o accedere a file criptati.
Crittografia e decrittografia
- Chiave di crittografia dei dati (DEK)
- La chiave utilizzata da Google Workspace nel client browser per criptare i dati.
- Chiave di crittografia della chiave (KEK)
- Una chiave del tuo servizio utilizzata per criptare una chiave di crittografia dei dati (DEK).
Controllo degli accessi
- Elenco di controllo dell'accesso (ACL)
- Un elenco di utenti o gruppi che possono aprire o leggere un file.
- Token web JSON (JWT) di autenticazione
- Token di autenticazione (JWT: RFC 7516)
emesso dal partner di identità (IdP) per attestare l'identità di un utente.
- JSON Web Token (JWT) di autorizzazione
- Token di autenticazione (JWT: RFC 7516)
emesso da Google per verificare che il chiamante sia autorizzato a criptare o decriptare una risorsa.
- Set di chiavi web JSON (JWKS)
- Un URL endpoint di sola lettura che rimanda a un elenco di chiavi pubbliche utilizzate per verificare
i token web JSON (JWT).
- Perimetro
- Controlli aggiuntivi eseguiti sui token di autenticazione e autorizzazione
all'interno di KACLS per il controllo dell'accesso.
Procedura di crittografia lato client
Dopo che un amministratore ha attivato la crittografia lato client per la propria organizzazione, gli utenti per i quali è attiva possono scegliere di creare documenti criptati utilizzando gli strumenti di creazione di contenuti collaborativi di Google Workspace, come Documenti e Fogli, o criptare i file caricati su Google Drive, ad esempio i PDF.
Dopo che l'utente ha criptato un documento o un file:
Google Workspace genera una DEK nel browser client per criptare i contenuti.
Google Workspace invia la DEK e i token di autenticazione al tuo KACLS di terze parti
per la crittografia, utilizzando un URL che fornisci all'amministratore
dell'organizzazione Google Workspace.
Il tuo KACLS utilizza questa API per criptare la DEK, quindi invia la DEK offuscata e criptata a Google Workspace.
Google Workspace archivia i dati offuscati e criptati nel cloud.
Solo gli utenti con accesso ai tuoi KACLS possono accedere ai dati.
Per maggiori dettagli, vedi Criptare e decriptare i file.
Passaggi successivi
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-08-29 UTC.
[null,null,["Ultimo aggiornamento 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)."]]