🔐 技術調査 - Confidential AI

対象スタック: Google Cloud Confidential Space + NVIDIA H100 Confidential Computing + Intel Trust Authority + Confidential Computing Consortium 仕様群
起点記事: Google Cloud Blog (URL slug は "verifiable-trust-in-the-ai-era-…"、現行ページ H1 は "Verifiable, private AI: Google Cloud expands Confidential Computing frontiers"、2026-06-24 公開、著者 Sam Lugani / Ranjit Narjala)
更新日: 2026-06-25

概要

実行時保護という第三の柱

クラウドにおけるデータ保護はこれまで「保存時暗号化」と「転送時暗号化」の 2 層で語られてきました。AI ワークロードでは、モデル推論や学習中にデータが平文でメモリ上に展開されるため、クラウドプロバイダー・ハイパーバイザー・特権 OS 管理者が原理的にデータへアクセスできる状態が続いていました。

Confidential AI はこのギャップを埋める「実行時保護」を体系化した設計領域です。CPU・GPU 上に構築する TEE (Trusted Execution Environment) でワークロードを実行し、Remote Attestation で「何のソフトウェアがどのハードウェア上で動いているか」を暗号学的に証明することで、クラウドプロバイダー自身を信頼境界の外に置きます。

信頼境界の再定義

従来の VM モデルは「クラウドプロバイダーを信頼する」前提でした。Confidential AI は CPU・GPU シリコンの Root of Trust から始まる完全性をハードウェアレベルで起点に置き、Remote Attestation で全スタックの状態を証明することで、クラウドプロバイダーを含む特権ソフトウェアを信頼境界の外に置きます。

関連技術との関係

比較

補足:

• FHE は理論的安全性が最も高い反面、TEE 比で 100 〜 10,000 倍の計算オーバーヘッドが生じます。
• TEE (Confidential Space) は Attestation による完全性証明を持ち、FHE・MPC にはないワークロード検証機能を提供します。
• AWS Nitro Enclaves は外部ネットワークや永続ストレージを持たない設計のため、マルチパーティ AI シナリオへの適用には制約があります。

ユースケース別推奨

特徴

• ハードウェア Root of Trust による第三者 Attestation — CPU・GPU シリコンから始まる信頼チェーンにより、ワークロードの完全性を暗号学的証拠として外部に提示できます。
• GPU TEE 対応 — NVIDIA H100 が GPU として初めて TEE を実装し、AI 推論や学習の計算コアを保護対象に含められます。Blackwell (RTX PRO 6000) は G4 マシンシリーズの Confidential VM / Confidential GKE Node 側で Preview 提供中で、Confidential Space への正式統合は今後の予定です。
• ネイティブ性能への近接 — H100 CC は GPU 内部計算を平文で実行しつつ HBM3 を物理攻撃から保護します。性能オーバーヘッドは主に CPU-GPU 間転送の暗号化に限られ、AI 推論や HPC で実用水準を維持します。
• クラウド KMS との条件付き鍵解放連携 — Attestation Token の検証を条件に Cloud KMS が暗号鍵を解放します。データ協力者はコード本体を見ずにコンテナイメージダイジェストで鍵アクセスを制御できます。
• Workload Identity Federation 統合 — OIDC 準拠の Attestation Token を IAM に直接連携し、サービスアカウントや IAM ポリシーと統合した細粒度アクセス制御を実現します。
• マルチパーティ協調の安全な基盤 — Workload Author / Workload Operator / Data Collaborator を役割分離し、互いに信頼しない複数組織が単一 TEE 上でデータを持ち寄れます。
• 独立 Attestation 検証者の選択 — Intel Trust Authority などのサードパーティ検証サービスをクラウドプロバイダーと独立して利用でき、検証者自体をプロバイダー管理外に置けます。
• Live Migration 対応 — AMD SEV ベースの N2D・C3D で Confidential VM のライブマイグレーションが GA となり、計画メンテナンス中も暗号化されたゲストメモリを保護したまま継続できます。
• エンドツーエンドプロンプト暗号化 — オープンソースの Prompt Encryption SDK により、クライアントが TEE との間に Attested TLS セッションを確立し、プロンプトを TEE 外で平文にさらすことなく推論できます。
• 大規模 AI サービスへの採用実績 — Apple Private Cloud Compute (PCC) が Google Cloud の Intel TDX + NVIDIA Blackwell CC を採用し、コンシューマー向け AI サービスへの Confidential AI 適用の先行事例となりました。
• 規制コンプライアンス証跡としての Attestation — Attestation レポートに含まれるプラットフォームブート設定・ファームウェア測定値・OS 測定値は、規制当局へ提出できる監査証跡として機能します。
• コード変更不要の適用 — NVIDIA H100 CC は既存の CUDA アプリケーションを変更せず CC モードで動作でき、Confidential Space も数クリックの設定で有効化できます。

構造

システムコンテキスト図

コンテナ図

コンポーネント図

Attestation Verifier の内部

GPU TEE (NVIDIA H100) の内部

ネットワーク構成図

データ

概念モデル

Confidential AI スタックの主要エンティティとその関係を、IETF RATS (RFC 9334) のロールモデルに沿って表現します。

情報モデル

Workload と TEE Instance

Evidence

Attestation Token

Reference Integrity Manifest

Attestation Policy と Workload Identity

Key Release Rule と Relying Party

構築方法

前提条件

• GCP プロジェクトと課金: gcloud projects create でプロジェクトを作成し、課金を有効にします。
• 必要な API の有効化: 以下のコマンドで必要なサービスを一括有効化します。

gcloud services enable \
    compute.googleapis.com \
    confidentialcomputing.googleapis.com \
    artifactregistry.googleapis.com \
    cloudkms.googleapis.com \
    iamcredentials.googleapis.com \
    logging.googleapis.com

• IAM 権限: 作業ユーザーには roles/compute.admin、roles/iam.workloadIdentityPoolAdmin、roles/cloudkms.admin が必要です。
• gcloud の最新化: gcloud components update を実行して最新バージョンを使います。

Confidential Space image の選択

confidential-space-images プロジェクトが image を管理します。Production と Debug の 2 バリアントと、3 段階のサポート属性があります。

• confidential-space (Production): ロックダウンされており、Operator はワークロードの処理データにアクセスできません。
• confidential-space-debug (Debug): SSH が有効化されており、ルートアクセスでデバッグできます。Attestation Token にデバッグ状態が記録されます。

gcloud compute images list \
  --project=confidential-space-images \
  --no-standard-images \
  --filter="family~'confidential-space$'"

gcloud compute images list \
  --project=confidential-space-images \
  --no-standard-images \
  --filter="family~'confidential-space-debug$'"

本番環境では image-family=confidential-space を指定し、LATEST/STABLE 属性を持つ image を自動選択させます。

ワークロード用サービスアカウントとロール

gcloud iam service-accounts create workload-sa \
  --display-name="Confidential Space Workload SA" \
  --project=PROJECT_ID

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:workload-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/confidentialcomputing.workloadUser"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:workload-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/artifactregistry.reader"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:workload-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/logging.logWriter"

Workload Identity Pool と Provider の作成

データ協力者は専用プールと OIDC プロバイダーを作成し、Attestation Verifier を登録します。

gcloud iam workload-identity-pools create my-cs-pool \
  --location=global \
  --display-name="Confidential Space Pool"

gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
  --location=global \
  --workload-identity-pool=my-cs-pool \
  --issuer-uri="https://confidentialcomputing.googleapis.com" \
  --allowed-audiences="https://sts.googleapis.com" \
  --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
  --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' && 'STABLE' in assertion.submods.confidential_space.support_attributes && \"workload-sa@PROJECT_ID.iam.gserviceaccount.com\" in assertion.google_service_accounts"

• issuer-uri: Confidential Space の Attestation Verifier エンドポイントです。
• allowed-audiences: STS トークン交換用 URL を固定で指定します。
• attribute-condition: CEL 式で STABLE image のみを許可し、debug image を除外します。サービスアカウントは配列順序に依存する [0] ではなく in assertion.google_service_accounts で membership チェックする方が安全です (tee-impersonate-service-accounts メタデータで複数 SA が入る可能性に対応)。

KMS 鍵の作成と IAM 設定

gcloud kms keyrings create my-keyring \
  --location=global

gcloud kms keys create my-key \
  --location=global \
  --keyring=my-keyring \
  --purpose=encryption

gcloud kms keys add-iam-policy-binding \
  projects/PROJECT_ID/locations/global/keyRings/my-keyring/cryptoKeys/my-key \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-cs-pool/attribute.image_digest/sha256:WORKLOAD_CONTAINER_IMAGE_DIGEST" \
  --role="roles/cloudkms.cryptoKeyDecrypter"

ダイジェストが変わるたびに IAM バインディングを更新する必要があるため、CI/CD パイプラインで自動化することを推奨します。

Artifact Registry へのイメージ登録

gcloud artifacts repositories create my-cs-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Confidential Space workload images"

gcloud auth configure-docker us-central1-docker.pkg.dev

docker build -t us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest .
docker push us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest

docker inspect \
  us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest \
  --format='{{index .RepoDigests 0}}'

Confidential VM のマシンタイプと GPU 対応

注: Confidential Space の現行公式 Deploy workloads ドキュメントが受け付ける --confidential-compute-type の値は SEV と TDX のみです (Confidential VM 一般では SEV_SNP も存在しますが、Confidential Space の公式手順では未掲載のため本表からは外しています)。

CPU のみのワークロードを AMD SEV でデプロイする例:

gcloud compute instances create my-cs-instance \
  --confidential-compute-type=SEV \
  --machine-type=n2d-standard-2 \
  --image-project=confidential-space-images \
  --image-family=confidential-space \
  --shielded-secure-boot \
  --maintenance-policy=MIGRATE \
  --service-account=workload-sa@PROJECT_ID.iam.gserviceaccount.com \
  --metadata="^~^tee-image-reference=us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest~tee-restart-policy=Never~tee-container-log-redirect=true"

Intel TDX + NVIDIA H100 GPU を使用する例:

gcloud compute instances create my-gpu-cs-instance \
  --confidential-compute-type=TDX \
  --machine-type=a3-highgpu-1g \
  --image-project=confidential-space-images \
  --image-family=confidential-space \
  --shielded-secure-boot \
  --maintenance-policy=TERMINATE \
  --provisioning-model=SPOT \
  --zone=us-central1-a \
  --boot-disk-size=30G \
  --service-account=workload-sa@PROJECT_ID.iam.gserviceaccount.com \
  --metadata="^~^tee-image-reference=us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest~tee-restart-policy=Never~tee-container-log-redirect=true"

利用方法

必須パラメータ一覧

ワークロードコンテナの最低要件

• 任意の言語・フレームワーク: Python、Go、Java など制限はありません。
• Artifact Registry への格納: Container Registry は非推奨のため Artifact Registry を使用します。
• デーモン不要: コンテナ自身が entrypoint としてビジネスロジックを実行します。
• ポートの明示: コンテナが公開するポートは EXPOSE ディレクティブで宣言します。
• root 不要: root 以外のユーザーで動作させることを推奨します。

最小構成の Dockerfile 例:

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY workload.py .

RUN useradd -m appuser
USER appuser

ENTRYPOINT ["python", "workload.py"]

Attestation Token の取得方法

ファイルマウント経由 (デフォルト Token)

launcher が自動生成したデフォルト OIDC Token は固定パスにマウントされます。audience は固定値 https://sts.googleapis.com で、Workload Identity Federation 経由で GCP API を呼び出す際に使用します。Token の有効期限は 60 分です。

with open("/run/container_launcher/attestation_verifier_claims_token") as f:
    attestation_token = f.read().strip()

import urllib.request
import json

sts_url = "https://sts.googleapis.com/v1/token"
body = json.dumps({
    "grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
    "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/my-cs-pool/providers/attestation-verifier",
    "requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
    "subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
    "subjectToken": attestation_token,
    "scope": "https://www.googleapis.com/auth/cloud-platform"
}).encode()

req = urllib.request.Request(sts_url, data=body,
    headers={"Content-Type": "application/json"})
with urllib.request.urlopen(req) as resp:
    gcp_access_token = json.loads(resp.read())["access_token"]

Unix socket 経由 (カスタム Token)

任意の audience や nonce を持つカスタム Token は Unix ドメインソケットを経由して取得します。

import socket
import http.client
import json

class UnixSocketHTTPConnection(http.client.HTTPConnection):
    def __init__(self, socket_path):
        super().__init__("localhost")
        self.socket_path = socket_path

    def connect(self):
        self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
        self.sock.connect(self.socket_path)

SOCKET_PATH = "/run/container_launcher/teeserver.sock"

payload = json.dumps({
    "audience": "https://example.com/my-relying-party",
    "nonces": ["base64encodednonce1"],
    "token_type": "OIDC"
}).encode()

conn = UnixSocketHTTPConnection(SOCKET_PATH)
conn.request("POST", "/v1/token",
    body=payload,
    headers={"Content-Type": "application/json"})
response = conn.getresponse()
token_data = json.loads(response.read())
custom_token = token_data["token"]

Attestation Policy (CEL) のサンプル

Workload Identity Pool Provider の --attribute-condition に CEL 式を記述します。

assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"

"workload-sa@my-project.iam.gserviceaccount.com" in assertion.google_service_accounts

assertion.hwmodel == "GCP_INTEL_TDX"

assertion.submods.nvidia_gpu.cc_mode == "ON"

複合条件の例:

assertion.swname == "CONFIDENTIAL_SPACE" &&
"STABLE" in assertion.submods.confidential_space.support_attributes &&
assertion.hwmodel == "GCP_INTEL_TDX" &&
assertion.submods.nvidia_gpu.cc_mode == "ON" &&
"workload-sa@PROJECT_ID.iam.gserviceaccount.com" in assertion.google_service_accounts

hwmodel の値は Google 公式ドキュメント内で表記揺れがあるため、参照面ごとに分けて整理します。

発行 Attestation Token の hwmodel 値 (token-claims リファレンス)

CEL attribute-condition で評価する assertion 側の値 (attestation-assertions リファレンス)

実運用では、CEL ポリシーを本番投入する前に発行された Live Token の hwmodel を gcloud iam workload-identity-pools providers list 等で実測確認し、どちらの表記が evidence 側に乗ってくるかを確かめてから policy を fix することを推奨します。

submods.nvidia_gpu.cc_mode の値は ON / OFF / DEVTOOLS の 3 種類です。本番では ON のみを許可します。

GPU TEE を有効化したワークロードの起動

Confidential GKE ノードプールの例:

gcloud container node-pools create gpu-confidential-pool \
  --cluster=my-gke-cluster \
  --location=us-central1 \
  --confidential-node-type=TDX \
  --node-locations=us-central1-a \
  --machine-type=a3-highgpu-1g \
  --accelerator=type=nvidia-h100-80gb,count=1,gpu-driver-version=latest \
  --maintenance-policy=TERMINATE \
  --spot \
  --num-nodes=1

VM 内での GPU ドライバ初期設定:

sudo apt-get install -y build-essential linux-headers-$(uname -r)
sudo apt-get install -y nvidia-open-kernel-source-580

echo "options nvidia NVreg_EnableGpuFirmware=1" | sudo tee /etc/modprobe.d/nvidia.conf
sudo update-initramfs -u

sudo nvidia-smi -pm 1

sudo reboot

再起動後の確認:

nvidia-smi conf-compute -f

Intel Trust Authority 連携

Intel Trust Authority (ITA) を独立した Attestation プロバイダーとして使うと、インフラプロバイダー (Google Cloud) と Attestation プロバイダーを分離できます。規制業界のゼロトラスト要件に対応した構成です。

gcloud compute instances create my-ita-instance \
  --confidential-compute-type=TDX \
  --machine-type=c3-standard-4 \
  --image-project=confidential-space-images \
  --image-family=confidential-space \
  --shielded-secure-boot \
  --maintenance-policy=TERMINATE \
  --service-account=workload-sa@PROJECT_ID.iam.gserviceaccount.com \
  --metadata="^~^tee-image-reference=us-central1-docker.pkg.dev/PROJECT_ID/my-cs-repo/workload:latest~ita-api-key=YOUR_ITA_API_KEY~ita-region=US~tee-restart-policy=Never"

コンテナ内からの ITA Token 取得:

import socket
import http.client
import json

class UnixSocketHTTPConnection(http.client.HTTPConnection):
    def __init__(self, socket_path):
        super().__init__("localhost")
        self.socket_path = socket_path

    def connect(self):
        self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
        self.sock.connect(self.socket_path)

SOCKET_PATH = "/run/container_launcher/teeserver.sock"

payload = json.dumps({
    "Audience": "https://my-relying-party.example.com",
    "TokenType": "OIDC"
}).encode()

conn = UnixSocketHTTPConnection(SOCKET_PATH)
conn.request("POST", "/v1/intel/token",
    body=payload,
    headers={"Content-Type": "application/json"})
response = conn.getresponse()
ita_token = json.loads(response.read())["token"]

Google Token と ITA Token のエンドポイントが /v1/token と /v1/intel/token で異なる点に注意します。

Google Cloud Attestation と Intel Trust Authority の比較

両者は排他ではなく、同一 VM 上で 両方のトークンを取得して用途別に Relying Party を分けることも可能です。

Prompt Encryption SDK の使い方

google/prompt-encryption-sdk は、クライアントが TEE 内ワークロードへプロンプトをエンドツーエンドで暗号化して送信するための Python ライブラリです。Attested TLS を利用してチャネルとワークロードの正当性を同時に検証します。

git clone https://github.com/google/prompt-encryption-sdk.git
cd prompt-encryption-sdk
pip install .
pip install ".[server]"

サーバー側 (TEE 内ワークロード) の実装:

from fastapi import FastAPI
from prompt_encryption_sdk.server import run_uvicorn_app

app = FastAPI()

@app.post("/v1/completions")
def completions(data: dict):
    prompt = data.get("prompt", "")
    result = {"choices": [{"text": f"Response to: {prompt}"}]}
    return result

if __name__ == "__main__":
    run_uvicorn_app(
        app,
        host="0.0.0.0",
        port=8000,
        ssl_keyfile="key.pem",
        ssl_certfile="cert.pem"
    )

クライアント側の実装:

from prompt_encryption_sdk.client import PromptEncryptionClient
from prompt_encryption_sdk.proto import attestation_pb2

policy = attestation_pb2.AttestationPolicy(
    hw_model=attestation_pb2.HARDWARE_MODEL_TDX,
    workload=attestation_pb2.WorkloadPolicy(
        image_hash="sha256:YOUR_EXPECTED_CONTAINER_IMAGE_HASH"
    )
)

client = PromptEncryptionClient(policy)
target_url = "https://LOAD_BALANCER_IP:8000/v1/completions"

with client.session() as http:
    response = http.post(
        target_url,
        json={"prompt": "機密データについて説明してください"},
        verify="/path/to/ca-bundle.pem"
    )
    print(response.json())

SDK の内部フローは次の手順を踏みます。

1. TCP/TLS 接続を開始します。
2. ハンドシェイク中断中に Attested Connection RPC でノンスを送信します。
3. TEE ハードウェアからクォートを生成します。
4. クライアントは Policy とクォート署名を検証します。
5. チャネルの Exported Keying Material (EKM) がセッション内容と一致することを確認します。
6. 全ての検証が成功した後にのみ、暗号化されたプロンプト本体を送信します。

運用

Confidential Space image のバージョン管理

長期稼働する VM はワークロード終了のたびに削除・再作成することで、常に最新 image を使用できます。image 更新後は assertion.submods.container.image_digest のポリシー値を更新し、IAM バインディングの principal set も新しい digest に対応させます。

gcloud compute images list \
  --project=confidential-space-images \
  --no-standard-images \
  --filter="family~'confidential-space$'"

attestation policy には次の条件を必ず組み込み、debug image を本番から排除します。

'STABLE' in assertion.submods.confidential_space.support_attributes

Attestation Token の有効期限と再取得

Confidential Space の launcher は Workload Identity Pool 向けトークンを 1 時間ごとに自動ローテーションします。Token には次のクレームが含まれます。

• iat: トークン発行時刻
• exp: トークン失効時刻
• nbf: トークン有効開始時刻

KMS の trust path が切れた場合、exp を過ぎたトークンは WIP で拒否され、その時点から鍵 release も失敗します。対処は WIP プロバイダーの再設定と VM の再起動による Token 強制再取得です。

Reference Integrity Manifest の更新

NVIDIA が提供する RIM は GPU ドライバおよび VBIOS ビルド時に生成される TCG SWID 形式の XML ファイルです。SHA384 ハッシュ値と ECDSA-SHA384 署名が含まれており、attestation 時に NVIDIA RIM Service から SDK が自動取得します。

• ドライバまたは VBIOS をアップデートすると、古いバージョン向けの RIM では測定値が一致しなくなります。
• サポート対象バージョンの確認は NVIDIA H100 Confidential Computing ガイドで行います。
• RIM の自動取得に失敗する場合はネットワーク疎通を確認します。RIM Service のエンドポイントへのアクセスが必要です。

Live Migration と attestation の再評価

AMD ベースの N2D マシンタイプは AMD SEV の Live Migration を、C3D-based Confidential VMs は 2026-06-24 の発表で Live Migration の一般提供開始 (GA) が告知されました (起点記事 "Verifiable trust in the AI era")。migration 中もゲストメモリは暗号化されたまま転送されるため、ワークロードへの中断はありません。移行後は attestation の再評価が実施され、移行先ホストの測定値が新しいトークンに反映されます。

AMD SEV-SNP でファームウェアアップデートを行うと v4 attestation レポートが生成されるため、v3 専用のパーサーは破綻します。GKE 環境では対応バージョンへのアップグレード時に live migration が自動有効化されます。

gcloud compute instances stop <VM_NAME>
gcloud compute instances start <VM_NAME>

GPU TEE の cc_mode 切替と本番運用

NVIDIA H100 GPU は 3 つの動作モードを持ちます。

モード切替は GPU リセットを伴うハイパーバイザー特権操作で、エンドユーザー (ワークロード内) からは変更できません。Google Cloud では --confidential-compute-type=TDX + a3-highgpu-1g で起動した VM の GPU は自動的に CC-On が選択され、ワークロード側は nvidia-smi conf-compute -f でモードを確認するのみとなります。オンプレミス環境やセルフマネージドのハイパーバイザーで CC モードを切り替える場合は、NVIDIA/nvtrust リポジトリの host_tools/ 配下に同梱された GPU 管理ツールをホスト側 root 権限で実行し、その後 VM を再起動します (具体的なスクリプト名はリポジトリの README とリリースで都度確認してください)。本番では CC-On を必須とし、attestation policy で assertion.submods.nvidia_gpu.cc_mode == 'ON' を検証します。SPDM セッション確立後にドライバが unload されてセッションキーが破棄されるとデータ保護が破綻するため、ドライバの常駐確保 (代表的には nvidia-persistenced デーモンの起動) を運用上強く推奨します。

nvidia-smi conf-compute -f
nvidia-smi -q | grep -i "confidential"

監視 (Cloud Audit Logs / NVIDIA NRAS)

Confidential Space の attestation に関するイベントは Cloud Audit Logs に記録されます。attestation 失敗は Data Access ログとして出力されます。

resource.type="gce_instance"
protoPayload.serviceName="sts.googleapis.com"
severity>=WARNING

NVIDIA NRAS はクラウドサービスとして提供され、GPU デバイス証明書の OCSP 検証と RIM 照合結果を返します。attestation 失敗時は attestation-support@nvidia.com へエスカレーションします。

鍵ローテーション (Cloud KMS / CMEK)

Cloud KMS は対称鍵の自動ローテーションをサポートします。PCI DSS 準拠などのコンプライアンス要件がある場合は 90 日周期のローテーションが推奨されます。

gcloud kms keys versions create \
  --key=KEY_NAME \
  --keyring=KEYRING_NAME \
  --location=LOCATION \
  --primary

• 非対称鍵は自動ローテーション非対応のため、手動ローテーションが必要です。
• 旧バージョンで暗号化されたデータは旧バージョンで復号できます。再暗号化は明示的な操作が必要です。
• image digest を更新する場合は、IAM バインディングの principal set を新しい digest 値に差し替え、旧 principal set のバインディングを削除します。

ベストプラクティス

Workload Author / Operator / Data Collaborator の役割分離

• Workload Author: コンテナイメージを構築し、launch policy を定義します。ワークロードのセキュリティ仕様を管理しますが、本番データにはアクセスできません。
• Workload Operator: VM のデプロイ、環境変数の設定、サービスアカウントの管理を行います。コンテナ内のデータにはアクセスできません。
• Data Collaborator: WIP プロバイダーと attestation policy を定義します。KMS 鍵の IAM バインディングを管理し、特定の image digest を持つワークロードにのみアクセスを許可します。

CI/CD パターンとして、イメージビルドと署名は Workload Author のパイプラインで完結させ、Operator はビルド済み image の参照のみを行う設計が推奨されます。

Multi-party Computation の trust boundary 設計

3 者以上のデータ提供者が相互不信のまま協業する場合、次の設計原則を適用します。

• 多者認可: 1 者の侵害だけでは秘密にアクセスできない構造にします。複数の WIP プロバイダーが異なるデータセットの鍵を管理し、それぞれが独立して policy を評価します。
• 最小権限: TEE が処理に必要なデータのみを受け取る設計にします。
• Operator 排除: Confidential Space の hardened image は Workload Operator が実行中ワークロードに SSH 接続できない構造になっています。これが multi-party の信頼の起点です。
• 監査可能性: assertion.submods.gce.* クレームをログに記録し、どのプロジェクト・ゾーン・インスタンスで処理されたかの監査証跡を残します。

Defense-in-depth

多層防御は次のレイヤーで構成します。

1. TEE (ハードウェア): AMD SEV-SNP / Intel TDX / NVIDIA H100 CC-On によるメモリ暗号化と測定値記録
2. TCB の縮小: Hardened OS Image は dm-verity による read-only ルートと SSH 無効化で TCB を絞り、ワークロードコンテナ側でも securityContext.capabilities.drop: ["ALL"]、runAsNonRoot: true、seccomp デフォルトプロファイル維持、不要カーネルモジュールの blacklist を適用して攻撃面を縮小する
3. トランスポート暗号化: PCIe 上の CPU-GPU 間通信は SPDM セッションで確立した AES 鍵で暗号化
4. Attestation policy: CEL 式による image digest・サポート属性・ハードウェアモデルの多項目検証
5. Data minimization: ワークロードが処理に必要な最小限のデータのみを受け取る設計
6. Audit logging: Cloud Audit Logs への attestation イベント記録と SIEM 連携

Apple PCC の実装事例から学べる設計として、事前定義された構造化ログのみをノードから出力するアプローチが挙げられます。汎用ログ機構を持たせないことでユーザーデータの漏洩経路を減らせます。

Attestation Policy のテスト

CEL 条件のテストには次のアプローチを用います。

• ローカル検証: gcloud iam workload-identity-pools create-cred-config のドライランで policy の構文エラーを検出します。
• Golden image digest 管理: CI/CD でビルドした image の digest を SBOM と対応付けて管理し、policy に含める digest が意図した image を指していることを確認します。
• Staging 環境での attestation 疎通確認: debug image で動作確認後、production image に切り替えて attestation が成功することをステージング環境で確認します。

Container image の immutable 化

mutable tag (:latest など) をポリシーで禁止し、image_digest による固定参照を必須とします。

gcloud projects add-iam-policy-binding DATA_COLLABORATOR_PROJECT_ID \
  --member="principalSet://iam.googleapis.com/.../attribute.image_digest/sha256:DIGEST" \
  --role=roles/cloudkms.cryptoKeyDecrypter

mutable tag を使用すると、image が差し替えられても既存の policy が通過するリスクがあります。image_digest による固定参照はこのリスクを排除します。

GPU TEE 性能オーバーヘッドの最小化

NVIDIA H100 CC-On モードの性能特性は次の通りです。

• LLM 推論全体: 大部分の典型的なクエリでスループット低下を 7% 未満に抑えられます (arXiv 2409.03992 のベンチマーク報告)。
• 大規模モデル・長シーケンスほど影響小: モデル規模が大きくシーケンス長が長くなるほど CC モードのオーバーヘッドはゼロに近づきます。
• 主なボトルネック: PCIe 越しの暗号化データ転送と、スモールバッチでの RPC レイテンシです。
• CUDA graph 制約: 一部のドライババージョンでは --enforce-eager フラグが必要となり、CC モードのオーバーヘッドに加えてさらに 10〜15% のスループット低下が追加されます。最新ドライバで CUDA graph が許可されれば回避できます。

大バッチ推論では暗号化バウンスバッファのオーバーヘッドが計算コストに対して相対的に小さくなるため、バッチサイズを大きくとることが性能最適化の基本戦略です。

Apple PCC の実装事例から学べる設計

トラブルシューティング

頻出エラーの症状・原因・対処

Attestation 失敗の調査

attestation 失敗は Cloud Audit Logs の sts.googleapis.com サービスの ExchangeToken イベントで検出できます。失敗時のログには assertion の実際の値が含まれるため、policy の期待値と比較することで原因を特定できます。

gcloud logging read \
  'resource.type="iam_workforce_pool" \
   protoPayload.methodName="google.identity.sts.v1.SecurityTokenService.ExchangeToken"' \
  --limit=20

Token expiry / 再取得失敗

launcher による自動更新が停止している場合、メタデータサーバから直接 Token を取得して launcher の動作を診断できます。

curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://sts.googleapis.com"

SPDM セッション確立失敗

systemctl status nvidia-persistenced
systemctl start nvidia-persistenced

CC モードではセッションキーが破棄されると FLR (Function Level Reset) が必要になるため、driver の常駐が前提となります。

Attestation forgery (証明偽造) と Endorser 失効の罠

Attestation の信頼チェーンは Endorser (ハードウェアベンダー) の公開鍵証明書を頂点に持ちます。Verifier が次のいずれかを怠ると、攻撃者が偽造 Evidence を通過させ得る前提崩壊が起こります。

• 証明書チェーンの完全検証: GPU 個体証明書 → Intermediate CA → NVIDIA Root CA までを毎回辿る。中間 CA を省略しない。
• OCSP / CRL 失効チェック: NVIDIA OCSP Service への疎通が前提。エアギャップ環境では OCSP stapling または CRL を定期キャッシュし、失効データなしの Verifier を本番で使わない。
• RIM 署名の検証: NVIDIA が SWID XML に付与する ECDSA-SHA384 署名を必ず検証し、未署名 RIM をフォールバックで受け入れない。
• nonce 検証: Relying Party は自分が発行した nonce が Token の eat_nonce クレームに含まれるかを確認し、過去 Token のリプレイを拒否する。

Google Cloud Attestation と Intel Trust Authority はマネージドサービスとして上記を実施しますが、独自に Verifier を構築する場合 (Veraison / Keylime 等) はこの 4 項目を実装漏れなく担保する必要があります。

TEE が守らないもの — 脅威モデルの外側

TEE はソフトウェア的な攻撃に対して強力な防御を提供しますが、次の脅威カテゴリは明示的にスコープ外です。

• 物理メモリバス傍受 (TEE.Fail): 2025 年 10 月公開の TEE.Fail 攻撃は、安価な機材で DDR5 メモリバスを傍受し、Intel TDX・AMD SEV-SNP の鍵を抽出できると報告されました (BleepingComputer / The Hacker News 報道、tee.fail)。物理アクセスと root 権限が前提のため、クラウド環境での実施難度は高いとされています。各ベンダーの一次 advisory については別途公式リリースで確認してください。
• Cold boot 攻撃 (HBM): GPU の HBM は電源断直後も短時間内容を保持するため、GPU ノードへの物理アクセスを持つ攻撃者がモデル重みや直近の推論データを抽出できる可能性があります。
• ファームウェアダウングレード攻撃: 古いファームウェアに意図的に戻すことで既知の脆弱性を利用する攻撃です。SEV-SNP は悪意ある古い firmware をリモート検出できますが、物理アクセスを伴うケースは保護対象外です。
• サイドチャネル (キューメタデータ): NVIDIA GPU-CC では、コマンドキューの readPtr/writePtr などのメタデータが平文で残ります。これを観測することで RPC のタイプを高精度で推定できます。
• マルチ GPU 間の NVLink 暗号化: Hopper 世代では NVLink トラフィックは暗号化されません (Blackwell 世代で対応予定)。
• OS・ハイパーバイザーの侵害後のゲスト VM: ゲスト OS が侵害されると、TEE 内のデータも攻撃者の支配下に入ります。TEE は「クラウドプロバイダー・Operator からのデータ保護」を提供しますが、ワークロード自体のコード侵害は防げません。

まとめ

Confidential AI は「実行時保護 + 第三者 Attestation」を AI ワークロードの前提に組み込み、クラウドプロバイダーを信頼境界の外に置く新しい運用モデルです。Google Cloud Confidential Space と NVIDIA H100 GPU TEE の GA、Intel Trust Authority による独立検証の選択肢、Apple PCC のような採用事例の積み上がりにより、機密データ AI 案件の調達要件と基盤設計を「保存時/転送時暗号化 + 実行時 TEE + 鍵 release ポリシー」の三層で語ることが現実的になりました。設計段階から CEL ポリシー / image digest 固定 / GPU CC モード必須化 / Attestation forgery 対策 / TEE が守らないもの (TEE.Fail・NVLink 非暗号化等) の境界を明文化し、規制要件を「Attestation トークンの監査証跡」で吸収できるかを早期に検証していくのが要点です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります！

参考リンク

概要・トレンド

• Verifiable trust in the AI era: what's new in Confidential Computing (Google Cloud Blog, 2026-06-24)
• Powering the next era of Confidential AI - Apple PCC on Google Cloud (Google Cloud Blog)
• Confidential Computing Consortium (Linux Foundation)
• CCC Technical Analysis of Confidential Computing v1.3
• About Azure confidential VMs (Microsoft Learn)
• AWS Nitro Enclaves
• Confidential AI on Azure (Microsoft Learn)
• AMD SEV-SNP vs Intel TDX vs NVIDIA GPU TEE 比較 (Phala)
• Confidential Computing vs FHE (Phala)
• Confidential Computing for AI Inference (AppScale Blog)

構造・データモデル

• Confidential Space overview (Google Cloud)
• Confidential Space security overview (Google Cloud)
• Google Cloud Attestation overview
• Confidential VM attestation (Google Cloud)
• Attestation assertions (Confidential Space)
• Attestation token claims (Confidential Space)
• Workload Identity Federation (Google Cloud IAM)
• NVIDIA Attestation Suite Documentation
• NVIDIA Trusted Computing Solutions
• NVIDIA GPU Claims Guide
• Confidential Computing on H100 GPUs (NVIDIA Developer Blog)
• NVIDIA GPU Confidential Computing Demystified (arXiv 2507.02770)
• GPU Remote Attestation With Intel Trust Authority
• RFC 9334: RATS Architecture (IETF)
• RFC 9711: Entity Attestation Token (EAT) (IETF)
• TCG Reference Integrity Manifest (RIM) Information Model

構築・利用

• Deploy workloads (Confidential Space)
• Create a Confidential VM instance with GPU (Google Cloud)
• Confidential GKE Nodes with GPU (Google Cloud)
• Create and grant access to confidential resources
• Create your first Confidential Space environment
• Confidential Space images
• Prompt Encryption SDK (GitHub)
• Prompt Encryption SDK Codelab
• Integrating GCP Confidential Space with Intel Trust Authority
• Intel Trust Authority overview
• NVIDIA Attestation SDK (PyPI)
• NVIDIA nvtrust GitHub Repository
• Confidential Space PKI Codelab

運用・ベストプラクティス

• Confidential Space release notes
• Live migration for Confidential Computing (Google Cloud Blog)
• Key rotation (Cloud KMS)
• NVIDIA Attestation Troubleshooting Guide
• NVIDIA RIM Guide
• Confidential Computing on NVIDIA Hopper GPUs: Performance Benchmark Study (arXiv)
• Apple Private Cloud Compute Security Research Blog
• Confidential GPU Computing on Cloud: Deploy LLMs with NVIDIA TEE (Spheron)
• How Confidential Space and MPC secure digital assets (Google Cloud Blog)

トラブルシューティング・反証・限界

• TEE.Fail Side-Channel Attack (BleepingComputer)
• TEE.Fail Extracts Secrets from DDR5 Enclaves (The Hacker News)
• Confidential AI with GPU Acceleration: Bounce Buffers (Intel Community Blog)
• Understanding the Confidential Containers Attestation Flow (Red Hat)
• Attestation and Key-Release Flow - NVIDIA Enterprise Reference Architecture
• salrashid123/confidential_space (GitHub)
• CCC-Attestation (GitHub Organization)