信封加密（Envelope Encryption）是一种应对海量数据的高性能加解密方案。信封加密主要使用 DEK 在客户本地进行数据的加解密，DEK 被 CMK 所保护，由 GenerateDataKey 接口生成，通过 GenerateDataKey 生成 DEK 时需要指定对应 CMK 的 KeyId。
通过 GenerateDataKey 生成 DEK 后，通常建议将 DEK 的密文进行本地落盘存储（存储于 DB 、配置文件等），在使用 DEK 进行数据解密前，通常只需要调用 KMS 的 Decrypt 接口对 DEK 密文进行解密并将得到的 DEK 明文缓存在内存中，后续针对本地海量的数据加解密，只需要使用内存中缓存的 DEK 明文作为密钥。
信封加密优点
减少 KMS 对云 API 的依赖：有效降低云 API 接口调用次数，减少云 API 调用带来的网络开销，降低网络链路抖动带来的影响。
提升本地数据加解密性能：因为 DEK 缓存在本地，在进行本地海量数据的加解密运算时可以有效提升本地数据加解密的性能。
KMS 加密方案对比
对比项 | 敏感信息加密 | 信封加密 |
相关密钥 | CMK | CMK、DEK |
性能 | 对称加密，远程调用 | 少量远程对称加密，海量本地对称加密 |
主要场景 | 密钥、证书、小型数据，适用于调用频率较低的场景 | 海量大型数据，适用于对性能要求较高的场景 |
云 API 调用 | 每次加解密都需要调用云 API | 进程启动后调用1次云 API 对 DEK 密文进行解密 |
示意图
本场景中，KMS 生成的 CMK 作为重要资源，通过 CMK 生成和获取 DEK 的明文和密文。用户根据实际业务场景，首先在内存中通过 DEK 明文来对本地数据进行加密，然后将 DEK 密文和密文数据落盘，其次在业务解密场景中需通过 KMS 来解密 DEK 密文，最后通过解密出来的 DEK 明文在内存中解密。
注意：
注意在实际的使用中，请勿将 DEK 的明文信息进行日志打印。
功能特点
高效：所有的业务数据都是采用高效的本地对称加密处理，对业务的访问体验影响很小。而对于 DEK 的创建和加解密开销，除了非常极端的情况下，您需要采用"一次一钥"的方案，大部分场景下可以在一段时间内复用一个 DEK 的明文和密文，所以大多数情况下这部分开销非常小。
安全易用：信封加密的安全性由 KMS 密钥安全提供保障。由DEK 保护业务数据，而腾讯云 KMS 则保护 DEK 并提供更好的可用性，您的主密钥主要用来生成 DEK，并且只有具备密钥访问权限的对象才能操作。
注意事项
需注意 SecretId 和 SecretKey 的保密存储：
腾讯云接口认证主要依靠 SecretID 和 SecretKey，SecretID 和 SecretKey 是用户的唯一认证凭证。业务系统需要该凭证调用腾讯云接口。
需注意 SecretID 和 SecretKey 的权限控制：
建议使用子账号，根据业务需要进行接口授权的方式管控风险。
需注意业务系统对明文密钥的处理：
信封加密场景中采用的是对称加密，故明文密钥不可落盘，需在业务流程的内存中使用。
需注意后台系统对数据密钥的处理：
信封加密场景中采用的是对称加密，可根据业务需求复用同一个数据密钥或针对不同用户、不同时间使用不同的数据密钥进行加密，避免 DEK 重复。
