なぜ「地域制限キー管理」が注目されるのか
データ主権（Data Sovereignty）規制は、金融・医療・防衛にとどまらず、一般的なSaaSにも現実的な制約となりつつあります。そこに「Harvest Now, Decrypt Later」という脅威が重なります。攻撃者が今のうちに暗号文を収集しておき、将来量子コンピュータで復号する戦略です。
Cloudflareが先日公開した PQ GeoKey Manager は、この2つの課題を同時に扱います。核となる考え方はシンプルです。「復号鍵は指定地域のサーバでのみアンラップできるようにする」。さらにポスト量子暗号（ML-KEM-768）を組み合わせ、将来の量子脅威にも備えます。
本記事はCloudflareエンジニアリングブログの設計ドキュメントを、実務者視点で再構成したものです。根拠資料は Cloudflare公式ブログ で確認できます。
なお本システムは現在closed betaで、GAは2027年Q1を予定しています。導入検討中の方は、まずアーキテクチャの理解から始めることをお勧めします。
アーキテクチャの核心：グローバル配布される「wrapped key」と地域に紐づく「root key」
本システムの本質は 鍵階層の分離 です。顧客の秘密鍵をそのまま配布せず、2層に分けて管理します。
1) 鍵階層の構造
| 構成要素 | 性質 | 配布範囲 |
|---|---|---|
| Regional Root Key | 256-bit 対称シークレット | 指定地域のedgeサーバのみ |
| Application-specific Key Pair | Rootから派生した非対称鍵（HPKE） | メタデータで識別 |
| Wrapped Customer Private Key | 顧客秘密鍵をapp keyでラップしたもの | Quicksilverでグローバル配布 |
顧客秘密鍵は application-specific public key でラップされ、世界中に配布されます。しかしこれを解くには、該当地域の regional root key が必要です。つまり、グローバルに配布されても指定地域外では絶対に復号できません。
2) メタデータの3点セット
すべてのwrapped keyには以下のメタデータが付与されます：
- Service context: Tunnel、Gateway、Accessなど、どのサービス向けか
- Regional boundary: Germany、EUなど許可地域
- Epoch: root keyの世代（ローテーション管理用）
同じ (service, region, epoch) の組み合わせは同一のapplication key pairを共有します。ここがトレードオフで、Tunnel-Germany鍵が漏洩すると同組合せの全顧客鍵が影響を受けます。代わりに管理オーバーヘッドが削減されます。
3) 暗号仕様：HPKE + Hybrid KEM
Cloudflare One経路ではRFC 9180のHPKEを使用します：
KEM: ML-KEM-768 + X25519 (hybrid)
KDF: HKDF-SHA-256
AEAD: AES-256-GCM
ハイブリッド構成の理由は明確です。どちらか一方が安全であれば機密性が保たれるからです。ML-KEM-768はNIST標準であるため規制産業の顧客にも訴求でき、X25519は従来のクラシック暗号による保証を担います。
4) Fail-Closedポリシー（実務で最も重要な部分）
本システムは 決してfail-openしません。リクエストメタデータの地域とローカルにロードされたroot keyが一致しなければ、そのリクエストは単純に拒否されます。例えばドイツ向けのリクエストがスペインやフランスのedgeで復号を試みると即座に失敗します。
サーバ起動時も同様です。設定されたregional root keyが存在しない、またはmalformedであれば、edge key service自体が起動しません。運用視点ではかなり攻撃的な選択で、可用性よりもセキュリティを優先した設計です。
注意事項とトレードオフ
1) 可用性 vs セキュリティの明確な選択
Fail-closedは規制産業では必須ですが、一般サービスでは障害伝播経路になり得ます。Regional membershipが更新される過程で一時的にroot keyへのアクセスが途切れると、該当地域のリクエストがすべて失敗する可能性があります。Cloudflareはprovisioning layerが1日数回membershipをrefreshすると述べていますが、日本国内でこのアーキテクチャを参考にするなら、membership syncとkeyring reloadの間のギャップを必ず設計に反映すべきです。
2) ローテーション戦略：Soft vs Hard
| 区分 | 動作 | 影響 |
|---|---|---|
| Soft rotation | 新epochを生成、旧epochを一定期間保持 | サービス停止なし（クレジットカード再発行の猶予に類似） |
| Hard rotation | 旧epochを即時廃棄、全鍵をrewrap | 強制マイグレーション、ダウンタイムリスク |
実務ではsoft rotationを基本とし、セキュリティインシデント発生時のみhard rotationをトリガーするパターンが現実的です。
3) カーネルキーリングの使用
Regional root keyはディスクに保存されず、Linux kernel keyringにのみロードされます。プロセスレベルのアクセス制御で隔離され、再起動時に消えます。セキュリティ上は良好ですが、再起動のたびにTPMベースの再認証＋provisioningが必要ということを意味します。障害復旧シナリオではこの部分がボトルネックになり得ます。
4) 信頼境界（Trust Boundary）
Root keyにアクセス可能なサービスは key-management service、provisioning service、authorized edge key services の3つです。Quicksilverはwrapped keyのみを受け取るため境界外にあります。国内規制対応システムを設計するなら、この境界を明確に文書化し、監査ログを残すことを推奨します。
関連して、AIエージェントアーキテクチャの信頼境界設計にご関心があれば Gemini 3ベースのエージェントフレームワーク実践ガイド も併せてご参照ください。
結論：今、何を準備すべきか
本システムのGAは2027年Q1ですが、今すぐ実務に反映できるポイントは明確です。
1. データ主権要件を鍵管理階層まで下ろして定義する 「EUリージョンに保存」というレベルではなく、「復号がEU外で発生しない」というレベルまで要件を具体化すべきです。規制当局が実際に問うのはこのレベルです。
2. ポスト量子マイグレーションのロードマップに「鍵管理」を含める 多くの組織がTLSライブラリのアップグレードだけを考えがちですが、実際にはroot keyのローテーションとepoch管理の方が複雑です。Soft/Hard rotationポリシーをあらかじめ定めておいてください。
3. Fail-closedポリシー導入時は障害対応マニュアルを併せて整備する セキュリティ優先の設計は正しいですが、運用チームがその結果を扱える必要があります。Regional membershipの更新、keyring reload、TPM再認証フローをランブックに明記してください。
次の学習ステップとしては、NIST FIPS 203（ML-KEM）仕様の原文、RFC 9180（HPKE）、そしてTPM 2.0ベースのリモートアテステーション文書をお勧めします。特にTPMベースのハードウェアアイデンティティ検証はFIPS 140-3コンプライアンスと直結するため、規制産業向けにサービスを提供されているなら必ず目を通すべきです。
データ主権と併せて、顧客ジャーニーデータの評価指標設計にもご関心があれば CDPメトリクス完全ガイド をご参照ください。