【実務・中級編】 暗号鍵のキャッシュ戦略 – Cloud Spanner

Cloud SpannerにおけるCMEK鍵キャッシュの深層：レイテンシを破綻させない分散暗号化アーキテクチャ

設計レビューで「顧客管理暗号鍵（CMEK）を導入します」という変更要求が上がってきたとき、君は即座にその裏にある分散システムの挙動を頭の中でレンダリングできているだろうか？

「GCPのKMSと連携するだけだから、ボタンを一つ押せば完了だ」――もしチームのメンバーがそう考えているなら、致命的なパフォーマンス障害や可用性インシデントへのカウントダウンは既に始まっている。

Cloud Spannerは、強整合性とグローバルスケールを両立するモンスター級の分散RDBMSだ。その足元を支える暗号化機構、特に顧客管理暗号鍵（CMEK）使用時におけるノード内の鍵キャッシュ戦略は、セキュリティとパフォーマンスという相反する要件を高次元でバランスさせるための極めて緻密な数学的・構造的トレードオフの上に成り立っている。

本稿では、一般のリファレンスには書かれていない「Spannerノード内部でのKMS鍵の振る舞い」「有効期限（TTL）が引き起こす可用性とセキュリティの極限状態」「実務で踏みがちなアンチパターン」を、チーフアーキテクトの視点から解剖する。

—

1. なぜ「鍵のノード内キャッシュ」が不可避なのか？

まず、分散ストレージの原理から思考をスタートさせよう。

Spannerはデータを「Split（スプリット）」と呼ばれる単位に分割し、Paxosグループを構成して複数ノードに分散保持している。ストレージの最下層（Colossus）に書き込まれるデータは、すべて暗号化される。

ここでエンベロープ暗号化（Envelope Encryption）が登場する。

[ データ (Plaintext) ]
│
▼ (データ暗号化鍵: DEK で高速暗号化)
[ 暗号化データ (SSTable / Colossus) ]
▲
│
[ データ暗号化鍵 (DEK) ] ── (KMSの鍵管理鍵: KEK で暗号化) ──► [ 暗号化されたDEK (Wrapped DEK) ]

1. DEK（Data Encryption Key）: 実際のデータを暗号化する鍵。高速な対称暗号（AES-256など）を使用。
2. KEK（Key Encryption Key）: Cloud KMS上に存在するマスターキー。DEK自体を暗号化（Wrap）する。

問題はここだ。Spannerが毎秒数万〜数十万QPSのRead/Write処理を行う際、データブロックをデコード・エンコードするたびにCloud KMSへネットワークAPI（RPC）を飛ばしてKEKによるUnwrap処理を行ったらどうなるか？

答えは「即死」だ。

• レイテンシの跳ね上がり: KMSへの1リクエストごとに数十ミリ秒のRTT（Round Trip Time）が加算される。Spannerのミリ秒未満〜数ミリ秒のリードレイテンシ目標は崩壊する。
• KMSクォータの枯渇: Cloud KMSのAPIリクエスト制限（QPS上限）に一瞬で達し、データベース全体のI/Oがスロットリングされる。
• カスケード障害: KMS側の短時間のレイテンシ増大やマイクロアウトが、Spanner全体のPaxosコミットを停止させる。

だからこそ、Spannerはノード内部（メモリ上）にKMS鍵の文脈および復号済みDEKの状態をキャッシュしなければならない。しかし、この「キャッシュ」こそが、セキュリティ監査人とインフラエンジニアを悩ませる諸刃の剣となる。

—

2. Spannerノード内キャッシュの内部メカニズムとライフサイクル

SpannerノードがCMEK対応データベースのデータを読み書きする際、内部では以下のようなキャッシュ制御が行われている。

【Spanner Node Internal Architecture】

Client Request (Read/Write)
│
▼
┌────────────────────────────────────────────────────────┐
│ Spanner Node (Memory) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Key State Cache │ │
│ │ – Decrypted DEK (Data Encryption Key) │ │
│ │ – KEK Version & Access Permission State │ │
│ │ – Cache TTL (e.g., up to 5 minutes – 24 hours) │ │
│ └──────────────────────────────────────────────────┘ │
│ │ │
└───────────────────────────┼────────────────────────────┘
│ (Cache Miss / Refresh)
▼
┌──────────────────┐
│ Cloud KMS API │
└──────────────────┘

キャッシュの動作フロー

1. 初期ロード（Cache Miss）:
Spannerノードが特定のSplitを担当する際、Colossusから「Wrapped DEK」を読み込む。ノードはCloud KMS APIを呼び出し、KEKを用いてDEKを復号（Unwrap）する。
2. ノード内保持（Cached State）:
復号されたDEKおよび「KMSキーが有効であり、アクセス権限が存在する」という状態が、Spannerノードのメモリ内に保持される。
3. 高速I/O実行:
後続のRead/Writeリクエストは、ノード内キャッシュされたDEKを使用するため、KMSへの追加RPCは発生せず、オーバーヘッドは実質ゼロとなる。
4. 非同期リフレッシュとTTL:
Spannerはバックグラウンドで定期的にKMSの権限状態や鍵の有効性を再検証（Re-validation）する。この検証間隔が「キャッシュのTTL（有効期限）」となる。

—

3. 「有効期限（TTL）」が引き起こすトレードオフの極致

ここが設計レビューで最も議論すべき核心部だ。
「KMSの鍵を無効化（Disable/Revoke）したとき、Spanner上のデータは『いつ』アクセス不能になるのか？」

Google Cloudの標準仕様では、KMS鍵の状態変更（権限剥奪や鍵の無効化）がSpannerのデータアクセス遮断に反映されるまで、最大で5分〜24時間程度の遅延（Propagation Delay）が生じる可能性がある（内部コンポーネントのキャッシュ設計に依存）。

この挙動がもたらすトレードオフを正しく理解せよ。

A. 可用性の隔離（Fault Isolation）

KMSが一瞬のネットワークスパイクや一時的な障害でダウンした場合でも、Spannerノード内に有効な鍵キャッシュが存在する限り、データベースのRead/Writeは影響を受けずに動き続ける。
これは、ミッションクリティカルなシステムにおいて「外部Dependency（KMS）の障害を遮断する」という分散システムの原則（Decoupling）に合致する。

B. セキュリティ・アジリティの遅延（Revocation Latency）

万が一、セキュリティ侵害が発生し「今すぐKMSの鍵を無効化してデータ漏洩を止めろ！」とインシデント対応を行ったとする。
KMS側で鍵をDisableにしても、Spannerノードのキャッシュが切れるまでは既存のノード経由でデータアクセスが継続できてしまう。

> チーフアーキテクトの視点:
> 「KMSの鍵を切れば即座に1ミリ秒でデータベースがロックされる」と思い込んでいるセキュリティ担当者がいたら、今すぐその認識を正せ。分散システムにおけるStateの即時無効化（Instant Revocation）は、可用性を完全に破壊するトレードオフなしには成り立たない。

—

4. 実務で遭遇するアンチパターンと破綻シナリオ

設計レビューで私が即座に却下する、CMEK構成の典型的な失敗例を挙げる。

アンチパターン1: マルチリージョンSpanner × 単一リージョンKMS

Spannerを `nam-eur-asia1` などのマルチリージョン構成にしているにもかかわらず、CMEKの鍵（KEK）を `us-central1` の単一リージョンKMSに配置するケース。

• 何が起きるか？:

キャッシュミス時（ノード起動時、Splitの再配置時、定期リフレッシュ時）に、欧州やアジアのSpannerノードから米国のKMSへ大陸間RPCが発生する。

• 結果:

キャッシュが活きている間は問題ないように見えるが、ノードの再起動や負荷高騰によるSplit移動が発生した瞬間に、特定のリーダーノードのレイテンシが数十〜数百ミリ秒にスパイクし、Paxosアライアンスの形成が遅延する。

アンチパターン2: KMS APIクォータの考慮不足

新規のSpannerデータベースを立ち上げ、大量のデータを一括ロード（Bulk Load）する際、大量のノード・Splitが同時に立ち上がる。

• 何が起きるか？:

全ノードが一斉にKMSへ `Unwrap` リクエストを送る。これを「Thundering Herd問題」と呼ぶ。

• 結果:

Cloud KMSの `cryptoKeyVersions.unwrap` APIクォータを超慢し、HTTP 429（Too Many Requests）が発生。Spannerノードのデータロードがストールし、最悪の場合データベースの初期化やリカバリが失敗する。

—

5. 堅牢なインフラ設計コードパターン

上記の課題を回避するため、Terraformを用いたIaC（Infrastructure as Code）で正しいCMEK配置とSpanner構築パターンを示す。

マルチリージョンや高度な可用性を考慮する場合、KMS鍵も適切にMulti-RegionまたはSpannerの構成に合致したロケーションを選択しなければならない。

==============================================================================
1. KMS Key Ring & Key Configuration (Multi-Region / Location-matched)
==============================================================================
resource “google_kms_key_ring” “spanner_keyring” {
name = “spanner-cmek-keyring”
# Spannerのインスタンス配置に合わせ、適切なマルチリージョンまたはリージョンを指定
location = “us”
}

resource “google_kms_crypto_key” “spanner_key” {
name = “spanner-cmek-key”
key_ring = google_kms_key_ring.spanner_keyring.id
rotation_period = “7776000s” # 90日ごとに自動回転（鍵のローテーション中も古い鍵キャッシュは有効に機能する）

purpose = “ENCRYPT_DECRYPT”

version_template {
algorithm = “GOOGLE_SYMMETRIC_ENCRYPTION”
protection_level = “SOFTWARE” # または要件に応じて “HSM”
}
}

==============================================================================
2. IAM Binding for Spanner Service Agent
Spannerサービスアカウントに、KMS鍵の復号・暗号化権限を付与
==============================================================================
data “google_project” “project” {}

resource “google_kms_crypto_key_iam_member” “spanner_cmek_user” {
crypto_key_id = google_kms_crypto_key.spanner_key.id
role = “roles/cloudkms.cryptoKeyEncrypterDecrypter”

# Spanner独自のサービスエージェントアカウントを指定
member = “serviceAccount:service-${data.google_project.project.number}@gcp-sa-spanner.iam.gserviceaccount.com”
}

==============================================================================
3. CMEK-enabled Spanner Database
==============================================================================
resource “google_spanner_instance” “main” {
config = “nam3” # Dual-region / Multi-region
display_name = “Production Spanner Instance”
num_nodes = 3
}

resource “google_spanner_database” “cmek_db” {
instance = google_spanner_instance.main.name
name = “orders-db”

# 暗号化設定に作成したKMSキーを指定
encryption_config {
kms_key_name = google_kms_crypto_key.spanner_key.id
}

# 権限伝播のタイムラグによる作成失敗を防ぐため、IAM設定に明示的に依存させる
depends_on = [
google_kms_crypto_key_iam_member.spanner_cmek_user
]
}

—

6. 運用とモニタリング：異常検知スクリプト

「鍵が無効化されている」「KMSクォータが枯渇している」といった状態は、アプリケーションのデータベース接続エラーとして間接的に発現する。これらを素早く診断するためのCloud Monitoring CLIコマンド（`gcloud`）およびメトリクス監視設計を理解しておく必要がある。

KMSエラーとSpannerレイテンシの相関を調査するコマンド例

!/usr/bin/env bash
==============================================================================
Cloud KMS API のエラーおよびクォータ超過（429）をモニタリングするスクリプト
==============================================================================
set -euo pipefail

PROJECT_ID=”your-gcp-project-id”
START_TIME=$(date -u -d ‘1 hour ago’ +%Y-%m-%dT%H:%M:%SZ)

echo “=== [1] Cloud KMS API Call Volume & Errors (Last 1 Hour) ===”
gcloud logging read \
“resource.type=\”cloudkms_cryptokey\” AND timestamp >= \”${START_TIME}\” AND severity>=ERROR” \
–project=”${PROJECT_ID}” \
–format=”table(timestamp, resource.labels.crypto_key_id, protoPayload.status.code, protoPayload.status.message)” \
–limit=10

echo “”
echo “=== [2] Checking Spanner System Latency Spikes ===”
Cloud Monitoring API経由でSpannerのI/Oレイテンシメトリクスを取得（概念例）
gcloud monitoring time-series list \
“filter=metric.type=\”spanner.googleapis.com/api/request_latencies\” AND resource.type=\”spanner_instance\”” \
–project=”${PROJECT_ID}” \
–interval-start=”${START_TIME}” \
–format=”csv(metric.labels.method, points.value.distributionValue.mean)” \
–limit=5

監視すべきコア・メトリクス

1. `kms.googleapis.com/api/request_count` (Filter: `status != OK`)

• KMS側のアクセスエラー。これが跳ね上がっている場合、IAM権限の剥奪や鍵の無効化が不意に行われた可能性がある。

2. `spanner.googleapis.com/init_shard_count` 及び Split移動ログ

• リバランス時にKMS鍵のキャッシュミスが発生し、一時的にレスポンスが劣化していないかを監視する。

—

7. まとめ：チーフアーキテクトからの設計原則

Cloud SpannerにおけるCMEKと暗号鍵のキャッシュ戦略を設計する際、君が胸に刻むべき原則は以下の3点だ。

1. キャッシュは性能のための「必須の悪」である
KMSへの全件アクセスは物理的に不可能。ノード内キャッシュが存在することを前提とし、鍵の無効化（Revocation）には最大数時間のタイムラグ（伝播遅延）が発生することをセキュリティ要件（SLA/SLO）に明記せよ。
2. トポロジーの整合性を保て
Spannerのノード配置（リージョン/マルチリージョン）と、KMS鍵の配置（Location）を絶対に乖離させるな。ネットワークRTTの数ミリ秒の差が、Paxosコミットのレイテンシを直接破壊する。
3. 障害時のデカップリングを肯定せよ
KMSの一時的障害時にSpannerが即座に落ちないのは「キャッシュというクッション」があるおかげだ。セキュリティと可用性のどちらにどれだけ体重をかけるのか、アーキテクチャのトレードオフを論理的に説明できるように準備しておけ。

このレベルの内部構造とトレードオフを把握して初めて、プロフェッショナルな分散データベースの設計と言える。次の設計レビューでは、自信を持って「鍵キャッシュのTTLと伝播遅延の設計方針」をチームに提示してほしい。