Tworzenie niestandardowej usługi kluczy na potrzeby szyfrowania po stronie klienta
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Do szyfrowania danych organizacji możesz używać własnych kluczy szyfrowania zamiast szyfrowania udostępnianego przez Google Workspace. Szyfrowanie po stronie klienta Google Workspace (CSE) szyfruje pliki w przeglądarce klienta, zanim zostaną one zapisane w chmurze na Dysku. Dzięki temu serwery Google nie mogą uzyskać dostępu do Twoich kluczy szyfrowania, a tym samym nie mogą odszyfrować Twoich danych. Więcej informacji znajdziesz w artykule Informacje o szyfrowaniu po stronie klienta.
Ten interfejs API umożliwia sterowanie kluczami szyfrowania najwyższego poziomu, które chronią Twoje dane, za pomocą niestandardowej zewnętrznej usługi kluczy. Po utworzeniu zewnętrznej usługi kluczy za pomocą tego interfejsu API administratorzy Google Workspace mogą się z nią połączyć i włączyć szyfrowanie po stronie klienta dla użytkowników.
Ważna terminologia
Poniżej znajdziesz listę typowych terminów używanych w interfejsie Google Workspace Client-side Encryption API:
- Szyfrowanie po stronie klienta
- Szyfrowanie odbywa się w przeglądarce klienta, zanim dane zostaną zapisane w chmurze. Chroni to plik przed odczytaniem przez dostawcę usługi przechowywania. Więcej informacji
- Usługa listy kontroli dostępu do kluczy (KACLS)
- Zewnętrzna usługa kluczy, która używa tego interfejsu API do kontrolowania dostępu do kluczy szyfrowania przechowywanych w systemie zewnętrznym.
- Dostawca tożsamości
- Usługa, która uwierzytelnia użytkowników, zanim zaszyfrują pliki lub uzyskają dostęp do zaszyfrowanych plików.
Szyfrowanie i odszyfrowywanie
- Klucz szyfrujący dane (DEK)
- Klucz używany przez Google Workspace w kliencie przeglądarki do szyfrowania danych.
- Klucz szyfrujący klucze (KEK)
- Klucz z Twojej usługi używany do szyfrowania klucza szyfrującego dane (DEK).
Kontrola dostępu
- Lista kontroli dostępu (ACL)
- Lista użytkowników lub grup, które mogą otwierać lub odczytywać plik.
- Token internetowy JSON (JWT) do uwierzytelniania
- Token dostępu (JWT: RFC 7516)
wydany przez partnera ds. tożsamości (IdP) w celu potwierdzenia tożsamości użytkownika.
- Token internetowy JSON (JWT) autoryzacji
- Token dostępu (JWT: RFC 7516) wydany przez Google w celu potwierdzenia, że podmiot wywołujący jest uprawniony do szyfrowania lub odszyfrowywania zasobu.
- Zestaw kluczy internetowych JSON (JWKS)
- Adres URL punktu końcowego tylko do odczytu, który wskazuje listę kluczy publicznych używanych do weryfikacji tokenów internetowych JSON (JWT).
- Obwód
- Dodatkowe sprawdzanie tokenów uwierzytelniania i autoryzacji w KACLS pod kątem kontroli dostępu.
Proces szyfrowania po stronie klienta
Gdy administrator włączy szyfrowanie po stronie klienta w organizacji, użytkownicy, dla których jest ono włączone, będą mogli tworzyć zaszyfrowane dokumenty za pomocą narzędzi Google Workspace do tworzenia treści we współpracy, takich jak Dokumenty i Arkusze, lub szyfrować pliki przesyłane na Dysk Google, takie jak pliki PDF.
Po zaszyfrowaniu dokumentu lub pliku przez użytkownika:
Google Workspace generuje w przeglądarce klienta klucz DEK, aby zaszyfrować treść.
Google Workspace wysyła klucz DEK i tokeny uwierzytelniania do zewnętrznego systemu KACLS w celu zaszyfrowania ich za pomocą adresu URL, który podasz administratorowi organizacji Google Workspace.
Twój serwer KACLS używa tego interfejsu API do szyfrowania klucza DEK, a następnie wysyła zaciemniony, zaszyfrowany klucz DEK z powrotem do Google Workspace.
Google Workspace przechowuje zaciemnione i zaszyfrowane dane w chmurze.
Dostęp do danych mają tylko użytkownicy, którzy mają dostęp do Twojego KACLS.
Więcej informacji znajdziesz w artykule Szyfrowanie i odszyfrowywanie plików.
Dalsze kroki
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-08-29 UTC.
[null,null,["Ostatnia aktualizacja: 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)."]]
