[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Envelope encryption\n\nIntroduction\n------------\n\nStoring and encrypting data at Google's scale requires using a central\ncryptographic key management service with multiple layers of keys for the\nencrypted data. An example of multiple layer of keys is *envelope encryption*,\nwhich is the process of encrypting a key with another key.\n\nYou can encrypt data at both the *application layer* , which is responsible for\ndisplaying data to users, and the *storage layer*, which provides the physical\nstorage of data.\n\nBy default, at the storage layer, Google Cloud [encrypts\ncustomer content stored at rest](/docs/security/encryption/default-encryption) using envelope encryption, with Google's\ninternal key management service as the central keystore. If you're storing and\nencrypting data yourself, you can use Cloud Key Management Service as your central\nkeystore at the application layer, which is the focus of this topic.\n\nCloud KMS stores keys in a *key hierarchy* designed for ease, with\naccess to resources in the key hierarchy governed by [Identity and Access Management](/kms/docs/iam).\nThe following shows the main levels of a Cloud KMS key hierarchy:\n\nFind out more about the key hierarchy at [object hierarchy](/kms/docs/object-hierarchy).\n\n### Data encryption keys\n\nThe key used to encrypt data itself is called a *data encryption key* (DEK).\n\nHere are best practices for managing DEKs:\n\n- Generate DEKs locally.\n- When stored, always ensure DEKs are encrypted at rest.\n- For easy access, store the DEK near the data that it encrypts.\n- Generate a new DEK every time you write the data. This means you don't need to rotate the DEKs.\n- Do not use the same DEK to encrypt data from two different users.\n- Use a strong algorithm such as 256-bit Advanced Encryption Standard (AES) in Galois Counter Mode (GCM).\n\n### Key encryption keys\n\nThe DEK is encrypted (also known as *wrapped* ) by a *key encryption key* (KEK).\nThe process of encrypting a key with another key is known as *envelope\nencryption*.\n\nHere are best practices for managing KEKs:\n\n- Store KEKs centrally.\n\n- Set the granularity of the DEKs they encrypt based on their use case. For\n example, consider a workload that requires multiple DEKs to encrypt the\n workload's data chunks. You could use a single KEK to wrap all DEKs that\n are responsible for that workload's encryption.\n\n- Rotate keys regularly, and also after a suspected incident. To learn more, see\n [key rotation](/kms/docs/key-rotation).\n\nBalancing DEKs and KEKs\n-----------------------\n\nHaving a smaller number of KEKs than DEKs and using a central key management\nservice makes storing and encrypting data at scale more manageable. A central\nkey service also is a singular point to more easily audit and restrict data\naccess.\n\nDepending on your situation, and the volume of data you are encrypting, you may\nchoose to use a similar model. A single KEK can be used to protect many DEKs;\nthis model permits individual data objects to each have their own DEK without\nmassively increasing the volume of keys stored in a central key management\nservice.\n\nCloud Key Management Service was designed to manage KEKs, and thus the maximum data input\nsize for `Encrypt` and `Decrypt` functions is 64 KiB. However, for data that you\nknow will not approach that limit, you could use Cloud KMS to\nencrypt and decrypt data directly.\n\nHow to encrypt data using envelope encryption\n---------------------------------------------\n\nThe process of encrypting data is to generate a DEK locally, encrypt data with\nthe DEK, use a KEK to wrap the DEK, and then store the encrypted data and the\nwrapped DEK. The KEK never leaves Cloud KMS.\n\nTo encrypt data using envelope encryption:\n\n1. Generate a DEK locally. You could do this with an open source library such as\n [OpenSSL](https://www.openssl.org), specifying a cipher type and a password from which to generate the\n key. You can also specify a salt and digest to use, if desired.\n\n2. Use this DEK locally to encrypt your data.\n\n As an example, you could use OpenSSL as shown in the [encrypting the\n message](https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption#Encrypting_the_message) example. For best practice, use 256-bit Advanced Encryption\n Standard (AES-256) cipher in Galois Counter Mode (GCM).\n3. Generate a new key in Cloud KMS, or use an existing key, which\n will act as the KEK. Use this key to encrypt (wrap) the DEK.\n\n4. Store the encrypted data and the wrapped DEK.\n\n| **Warning:** Do **NOT** store a plaintext DEK.\n\nHow to decrypt data using envelope encryption\n---------------------------------------------\n\nThe process of decrypting data is to retrieve the encrypted data and the wrapped\nDEK, identify the KEK that wrapped the DEK, use the KEK to unwrap the DEK, and\nthen use the unwrapped DEK to decrypt the data. The KEK never leaves\nCloud KMS.\n\nTo decrypt data using envelope encryption:\n\n1. Retrieve the encrypted data and the wrapped DEK.\n\n2. Use the key stored in Cloud KMS to unwrap the encrypted DEK.\n\n3. Use the plaintext DEK to decrypt the encrypted data. If using OpenSSL as\n earlier, see the [decrypting the message](https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption#Decrypting_the_Message) example.\n\nFor sample code that shows how to encrypt and decrypt with envelope\nencryption, see [Client-side encryption with Tink and Cloud KMS](/kms/docs/client-side-encryption).\n\nIntegration with Google Cloud services\n--------------------------------------\n\nSeveral Google Cloud products are integrated with Cloud KMS\nto support Customer-Managed Encryption Key (CMEK) functionality. CMEK with\nCloud KMS adds an extra layer of protection for your data, provides\nyou with control of your encryption keys, and leverages the key management\nbenefits of Cloud KMS. See [Using Cloud KMS with other\nservices](/kms/docs/using-other-products) to see a full list of products that support CMEK.\n\nOther options for Google Cloud services\n---------------------------------------\n\nFor data stored in Google Cloud products that do not support CMEK, you\ncan implement your own application-layer encryption. This requires implementing\nyour own envelope encryption as described above, so that you store data\nencrypted locally in Google Cloud. This is also how you could use\nCloud KMS to encrypt data you store in other cloud service\nproviders or on premises.\n\nIn addition to supporting CMEK, the following products support\nCustomer-Supplied Encryption Key (CSEK) functionality.\n\nWith CSEK, you supply your own AES-256 key to serve as the KEK, and your key\nprotects the DEKs that protect your data. Your CSEK key is protected by an\nadditional layer of protection, using a Cloud KMS key.\n\nNow that you can\n[import keys into Cloud KMS](/kms/docs/importing-a-key), you can\nimport your keys and use them with CMEK-enabled services instead of relying on\nCSEK."]]
