Split-Trust 加密工具
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
分割信任加密工具 (STET) 可安全地將金鑰資料移入及移出 Google Cloud ，並以可驗證的加密方式保護資料，避免內部人員存取 Google Cloud 。
為此，我們採用了兩個金鑰管理系統 (KMS)，一個是內部系統，另一個是外部系統。Google Cloud即使其中一個 KMS 遭到入侵，第二個 KMS 也能確保資料隱私。
以下是一系列範例，說明如何將資料傳輸至 Cloud Storage，並使用 Compute Engine VM 進行運算。這些範例會逐步說明如何提高安全性，協助您瞭解 STET 如何融入安全流程。
第 1 級：Cloud Storage
將資料擷取至 Google Cloud時，您可以使用 Cloud Storage，讓雲端工作負載存取資料。您可以將資料從內部部署運算環境上傳至 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 級：機密運算
機密 VM 執行個體會加密記憶體，進一步防範使用中的資料遭到未經授權的存取。在許多威脅模型中，機密 VM 執行個體比標準執行個體更值得信賴，因此可用於處理機密工作負載。
如果您的威脅模型依賴機密運算，其中一個問題是確保工作負載在機密 VM 執行個體中執行。遠端認證：工作負載可藉此向遠端證明自己是在 Confidential VM 執行個體中執行，並確認工作負載設定和環境的許多其他屬性。由於認證是由平台產生，工作負載無法建立與實際環境不符的虛假認證。
KMS 可以要求並評估這些認證，再允許存取金鑰。這項規定可確保只有預期工作負載能解密資料，即使一般憑證遭到盜用也一樣。
第 5 級：信任分割
使用單一 KMS 時，該 KMS 會獨自控管加密金鑰。如果 KMS 運算子取得加密資料的密文，他們就能解密成明文。如果 KMS 由完全值得信賴的實體運作，或許可以接受這項風險，但有些威脅模型需要從 KMS 移除單方面控制權。
使用 STET 時，您可以選擇將這項信任關係拆分為兩個 KMS 系統，這樣一來，兩個 KMS 系統都不會有足夠的資訊來解密資料。需要兩個 KMS 運算子互相勾結 (並存取密文)，才能解密您的資料。
如果您使用機密 VM，STET 也會使用儲存在需要認證的 KMS 中的金鑰，協助加密及解密資料。
總而言之，STET 可確保只有資料來源 (例如內部部署系統) 和資料消費者 (例如在機密 VM 執行個體中執行的工作負載) 能夠存取純文字資料。
如要進一步瞭解如何使用 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 存放區和私密空間整合指南。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-09-04 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\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)."]]
