拆分信任加密工具
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
分片信任加密工具 (STET) 支持以可验证和加密方式保护密钥数据免受 Google Cloud 内部人员的影响，从而安全地将密钥数据传入和传出 Google Cloud 。
这是通过使用两个密钥管理系统 (KMS) 来实现的，一个在Google Cloud内部，另一个在外部。即使一个 KMS 遭到入侵，第二个 KMS 也能帮助保障您数据的私密性。
以下是一系列示例，涉及传输到 Cloud Storage 并使用 Compute Engine 虚拟机计算得出的数据。这些示例逐步展示了如何提高安全性，有助于说明 STET 如何融入您的安全流程。
第 1 级：Cloud Storage
将数据注入到 Google Cloud时，您可以使用 Cloud Storage 将数据提供给云工作负载。您可以将本地计算环境中的数据上传到 Cloud Storage 存储桶，为您的工作负载授予对该存储桶的访问权限，并让工作负载（或多个工作负载）根据需要使用这些数据。此策略避免了直接创建与工作负载的活跃连接以向其发送所需数据的复杂性。
Cloud Storage 始终会对静态数据进行加密。但是，如果要将 Cloud Storage 委托为您执行该加密，则它必须能够在加密之前访问未加密的数据（明文）以及用于创建加密数据的加密密钥（密文）。根据您的威胁模型，在将数据发送到 Cloud Storage 之前，最好对其进行加密，使 Cloud Storage 始终无法查看明文。
级别 2：客户端加密
使用客户端加密功能时，您可以在数据上传到 Cloud Storage 之前对其进行加密，并仅在数据下载到工作负载后进行解密。因此，Cloud Storage 可以访问密文，但无法访问明文。Cloud Storage 会在存储之前增加另一层加密，但数据的主要保护是在上传之前执行的加密。
使用此方法时，您现在需要向工作负载授予对解密数据所需的加密密钥的访问权限。此操作本身可能是一项棘手的任务，因为加密密钥授予了移除原始加密层并可让您深入了解数据的权限。
级别 3：外部密钥管理
解决密钥管理问题的一种常用方法是使用专用的密钥管理服务 (KMS) 保存密钥并管理其访问权限。每次尝试加密或解密时，都必须向 KMS 发送请求。KMS 可以根据各种条件授予访问权限，以确保只有有关方才能解密数据。
KMS 系统可以要求在授予加密密钥访问权限之前满足许多不同的条件，但它们通常需要与 KMS 上配置的政策匹配的凭据。因此，拥有该凭据的任一方都可以访问加密密钥，并且能够解密数据。
第 4 级：机密计算
机密虚拟机实例可以在加密内存的情况下运行，从而提供额外的保护，以防在使用过程中意外访问数据。对于许多威胁模型，机密虚拟机实例比标准实例更值得信任，从而可用于敏感工作负载。
如果您的威胁模型依赖于机密计算，则有一个问题是确保工作负载在机密虚拟机实例中运行。远程证明是一种方法，工作负载可以通过该方法向远程方证明其在机密虚拟机实例中运行，并确认许多有关工作负载的配置和环境的其他属性。由于证明是由平台生成的，因此工作负载无法创建不反映其实际环境的虚假证明。
KMS 可以先要求和评估这些证明，然后再允许访问密钥。此要求有助于确保即使常规凭据被破解，也仅允许预期的工作负载解密数据。
第 5 级：分片信任
使用单个 KMS 时，KMS 可以完全控制加密密钥。如果 KMS 运维人员要获取加密数据的密文，则他们将具备密文解密为明文所需的一切。虽然在 KMS 由完全受信任的实体操作时，这种风险可能可接受，但某些威胁模型需要从 KMS 中移除单方面控制。
借助 STET，您可以选择在两个 KMS 系统之间拆分此信任关系，并且任何一个 KMS 都没有足够的信息来解密数据。它要求两位 KMS 运维人员之间有冲突（且能够访问密文），才能解密数据。
如果您使用的是机密虚拟机，STET 还可以使用存储在需要证明的 KMS 中的密钥来加密和解密数据。
总而言之，STET 有助于确保只有有权访问明文数据的实体才是数据数据初始所有者（例如，本地系统）和数据使用者（例如，在机密虚拟机实例中运行的工作负载）。
如需详细了解如何使用 STET，请参阅 GitHub 代码库和快速入门指南。
使用 STET 的 Confidential Space
如果您使用Confidential Space，STET 在访问存储在 Cloud KMS 中的密钥加密密钥 (KEK) 时，可以使用 Confidential Space 中的证明令牌作为证明证据。
STET 可处理对工作负载的 Cloud KMS 密钥的访问权限，并支持使用 Confidential Space 对加密工作流、解密工作流或加密和解密工作流执行证明。
您可以创建 STET 配置，其中包含工作负载身份池 (WIP) 名称、Cloud KMS URI 和解密信息等信息。然后，STET 会使用该信息集成到您的 Confidential Space 设置中。
如需了解详情，请参阅 GitHub 代码库和Confidential Space 集成指南。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-18。
[[["易于理解","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。"],[[["\u003cp\u003eSplit-Trust Encryption Tool (STET) enables secure key data transfer in and out of Google Cloud, protecting against insider threats by using both internal and external key management systems (KMS).\u003c/p\u003e\n"],["\u003cp\u003eSTET allows you to split trust between two KMS systems, requiring collusion between both KMS operators to decrypt data, thus removing unilateral control.\u003c/p\u003e\n"],["\u003cp\u003eWhen using STET with Confidential VM instances, data can be encrypted and decrypted using keys stored in a KMS that requires attestations to ensure only intended workloads can access the data.\u003c/p\u003e\n"],["\u003cp\u003eSTET supports integration with Confidential Space, utilizing its attestation token as evidence when accessing the key-encryption-key (KEK) stored in Cloud KMS.\u003c/p\u003e\n"],["\u003cp\u003eThe solution is built in stages, and STET ensures that only the data originator and consumer have access to plaintext, providing enhanced security for sensitive data.\u003c/p\u003e\n"]]],[],null,["# Split-trust Encryption Tool\n\nThe Split-Trust Encryption Tool (STET) allows for secure key data transfer in\nand out of Google Cloud in a way that is verifiably and cryptographically\nprotected from Google Cloud insiders.\n\nThis is achieved by using two key management systems (KMS), one internal to\nGoogle Cloud, the other external. Even if one KMS is compromised, the second is\nin place to help keep your data private.\n\nWhat follows is a series of examples involving data transmitted to\n[Cloud Storage](/storage) and computed using\n[Compute Engine](/compute) VMs. The examples step through increasing\nlevels of security to help explain how STET fits into your security flow.\n\nLevel 1: Cloud Storage\n----------------------\n\nWhen ingesting data into Google Cloud, you can use Cloud Storage to\nmake the data available to your cloud workloads. You can upload the data from\nyour on-premises computing environments to a Cloud Storage bucket, give\nyour workload access to that bucket, and have the workload (or multiple\nworkloads) consume that data when necessary. This strategy avoids the complexity\nof creating an active connection directly to the workload to send it the data it\nneeds.\n\nCloud Storage always encrypts your data at rest. However, if you are\nentrusting Cloud Storage with doing that encryption for you, it has\naccess to the unencrypted data (plaintext) prior to encryption, as well as the\nencryption keys used to create the encrypted data (ciphertext). Depending on\nyour threat model, it might be desirable to encrypt the data before you send it\nto Cloud Storage, so that Cloud Storage never has visibility\nto the plaintext.\n\nLevel 2: Client-side encryption\n-------------------------------\n\nWhen using [client-side encryption](/storage/docs/encryption/client-side-keys),\nyou encrypt the data before it is uploaded to Cloud Storage and only\ndecrypt it after it is downloaded into your workload. As a result,\nCloud Storage has access to the ciphertext but not the plaintext.\nCloud Storage adds another layer of encryption before storing it, but\nthe primary protection for the data is the encryption performed prior to\nuploading.\n\nWith this approach, you now need to give the workload access to the encryption\nkey needed to decrypt the data. This itself is a potentially difficult task, as\nthe encryption key grants the ability to remove your original layer of\nencryption and gain visibility to the data.\n\nLevel 3: External key management\n--------------------------------\n\nA common approach to this key management problem is to use a dedicated Key\nManagement Service (KMS) that holds the keys and manages access to them. On each\nencryption or decryption attempt, a request must be sent to the KMS. The KMS has\nthe ability to grant access based on various criteria to ensure that only\nappropriate parties are able to decrypt the data.\n\nKMS systems have the ability to require a number of different criteria before\nauthorizing access to the encryption key, but they typically require a\ncredential that matches a policy configured on the KMS. Therefore, any party in\npossession of that credential will be able to access the encryption key and\nwould be able to decrypt the data.\n\nLevel 4: Confidential Computing\n-------------------------------\n\n[Confidential VM](/confidential-computing/confidential-vm/docs/confidential-vm-overview)\ninstances run with their memory encrypted, providing additional protections\nagainst unintended access to the data while in use. For many threat models,\nConfidential VM instances are more trusted than standard instances, allowing them\nto be used for sensitive workloads.\n\nIf your threat model relies on Confidential Computing, one issue is ensuring that\na workload is running in a Confidential VM instance.\n[Remote attestation](https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation)\nis a means by which the workload can prove to a remote party that they are\nrunning in a Confidential VM instance and can confirm many other properties about\nthe configuration and environment of the workload. Because the attestations are\ngenerated by the platform, the workload can't create false attestations that\ndon't reflect its actual environment.\n\nA KMS can require and evaluate these attestations before allowing access to\nkeys. This requirement helps ensure that only the intended workload is allowed\nto decrypt the data, even if the normal credentials are compromised.\n\nLevel 5: Split trust\n--------------------\n\nWhen using a single KMS, that KMS has sole control over the encryption keys. If\nthe KMS operator were to acquire the ciphertext of your encrypted data, they\nwould have everything needed to decrypt it into your plaintext. While this risk\nmight be acceptable if the KMS is operated by a completely trusted entity, some\nthreat models create a need to remove unilateral control from the KMS.\n\nWith STET, you have the option to split this trust between two KMS systems, with\nneither KMS having enough information to decrypt your data. It would require\ncollusion between both KMS operators (and access to the ciphertext) in order to\ndecrypt your data.\n\nIf you're using Confidential VM, STET also facilitates the encryption and\ndecryption of data using keys stored in a KMS that requires attestations.\n\nAll together, STET helps ensure that the only entities that have access to your\nplaintext data are the originator of the data (for example, an on-premises\nsystem) and the consumer of the data (for example, a workload running in a\nConfidential VM instance).\n\nFor more information on using STET, see the\n[GitHub repository](https://github.com/GoogleCloudPlatform/stet)\nand\n[quickstart guide](https://github.com/GoogleCloudPlatform/stet/blob/main/docs/quickstart_guide.md).\n\n### Confidential Space with STET\n\nIf you use [Confidential Space](/confidential-computing/confidential-space/docs),\nSTET can use the attestation token from Confidential Space as attestation evidence\nwhen accessing the key-encryption-key (KEK) that is stored in\nCloud KMS.\n\nSTET handles access to Cloud KMS keys for your workload, and supports\nusing Confidential Space to perform attestation for the encryption workflow,\nthe decryption workflow, or both the encryption and decryption workflows.\n\nYou can create a STET configuration that includes information such as the\nworkload identity pool (WIP) name, Cloud KMS URIs, and decryption\ninformation. STET then uses that information to integrate into your\nConfidential Space set up.\n\nFor more information, see the\n[GitHub repository](https://github.com/GoogleCloudPlatform/stet)\nand the\n[Confidential Space integration guide](https://github.com/GoogleCloudPlatform/stet/blob/main/docs/confidential_space.md)."]]
