分割信頼暗号化ツール（STET）は、 Google Cloud の内部関係者から検証可能かつ暗号化された方法で保護されるように、 Google Cloud との間で安全な鍵データの送受信を可能にする配布メカニズムを提供します。
これは、2 つの鍵管理システム（KMS）を使用して実現されます。1 つはGoogle Cloud内部にあり、もう 1 つは外部にあります。1 つの KMS が侵害された場合でも、2 つ目の KMS がデータの機密性を維持します。
以下では、Cloud Storage に送信され、Compute Engine VM を使用して計算されるデータに関する一連の例を示します。これらの例では、セキュリティ レベルを段階的に高めながら、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: Confidential Computing
Confidential VM インスタンスはメモリを暗号化して実行されるため、使用中のデータへの意図しないアクセスを防ぐ追加の保護機能があります。多くの脅威モデルでは、Confidential VM インスタンスは標準インスタンスよりも信頼性が高いため、機密性の高いワークロードに使用できます。
脅威モデルが Confidential Computing を使用している場合、一つの問題は、ワークロードが Confidential VM インスタンスで必ず実行されているようにすることです。リモート認証とは、ワークロードが Confidential VM インスタンスで実行されていることをリモート当事者に証明し、ワークロードの構成と環境についての他の多くのプロパティを確認する手段です。証明書はプラットフォームによって生成されるため、ワークロードは実際の環境を反映していない誤った証明書を作成することはできません。
KMS は鍵へのアクセスを許可する前に、これらの証明書を要求および評価できます。この要件により、通常の認証情報が不正使用された場合でも、対象のワークロードのみがデータを復号できます。
レベル 5: スプリットの信頼
単一の KMS を使用する場合、その KMS は暗号鍵を単独で制御できます。KMS オペレーターが暗号化されたデータの暗号テキストを取得すると、平文に復号するために必要なすべてのものが生成されます。このリスクは、KMS が完全に信頼できるエンティティによって運用されている場合には許容できる可能性がありますが、一部の脅威モデルでは KMS から一方的な制御を削除する必要があります。
STET を使用すると、この信頼を 2 つの KMS システムに分割するオプションがあります。どちらの KMS にもデータの復号に十分な情報がありません。データを復号するには、両方の KMS オペレーターの結託（および暗号テキストへのアクセス）が必要になります。
Confidential VM を使用している場合、STET は、証明書を必要とする KMS に保存されている鍵を使用してデータの暗号化と復号を容易にします。
まとめると、STET を使用すると、平文データにアクセスできるエンティティは、データの送信元（たとえば、オンプレミス システム）と、データのコンシューマ（たとえば、Confidential VM インスタンスで実行されているワークロードなど）のみです。
STET の使用について詳しくは、GitHub リポジトリとクイックスタート ガイドをご覧ください。
STET を使用した Confidential Space
Confidential Space を使用する場合、STET は Cloud KMS に保存されている鍵暗号鍵（KEK）にアクセスするときに、Confidential Space の構成証明トークンを構成証明の証拠として使用できます。
STET は、ワークロードの Cloud KMS 鍵へのアクセスを処理し、Confidential Space を使用して暗号化ワークフロー、復号ワークフロー、または暗号化ワークフローと復号ワークフローの両方の構成証明を実行します。
ワークロード ID プール（WIP）名、Cloud KMS URI、復号情報などの情報が含まれる STET 構成を作成できます。STET は、その情報を使用して、Confidential Space の設定に統合します。
詳細については、GitHub リポジトリと Confidential Space 統合ガイドをご覧ください。