「暗号化はコンプライアンスのためのチェックボックスではない。分散システムの心臓部を守る、アーキテクチャそのものだ」
いいか、よく聞いてくれ。Cloud Spannerを単なる「スケールするリレーショナルデータベース」だと思っているなら、君の設計はまだ甘い。真のプロフェッショナルは、その裏側で蠢くデータ保護のメカニズム――すなわち暗号鍵の階層構造（Key Hierarchy）が、いかにして分散ストレージのパフォーマンスとトレードオフなしに成立しているかを理解している。
今日は、多くのエンジニアが「なんとなく」で済ませているDEKとKEK、そしてCMEK（カスタマー管理暗号鍵）が、Spannerの分散原理とどう噛み合っているのか、その深淵を解説する。
—
1. エンベロープ暗号化：なぜ「階層」が必要なのか
Spannerは、保存されるすべてのデータをデフォルトで暗号化する。ここで使われるのがエンベロープ暗号化だ。なぜ直接マスターキーでデータを叩かないのか？ 理由は単純、「巨大なデータの再暗号化を避けるため」であり、そして「鍵管理の局所性を確保するため」だ。
鍵の階層構造（The Hierarchy）
Spannerの鍵階層は、大きく分けて以下の3層で構成されている。
1. DEK (Data Encryption Key): 実際にデータを暗号化する対称鍵（AES-256）。データのごく近い場所（ストレージチャンク単位）に存在し、高速なI/Oを実現する。
2. KEK (Key Encryption Key): DEKを暗号化（ラップ）するための鍵。DEKが平文で露出するのを防ぐ。
3. MEK (Master Encryption Key / KMS Key): 階層の頂点に立つ。Googleが管理するか、君たちがCloud KMSで管理（CMEK）する鍵だ。
この構造の肝は、「データ本体を触らずに、鍵のアクセス権だけを制御できる」という点にある。
—
2. 分散データとDEKのライフサイクル
Spannerのデータは「Split」という単位で分割され、複数のレプリカに分散されている。ここで、君たちが意識すべきは「DEKはどこで生きているか」だ。
Spannerの下層ストレージであるColossus（Googleの分散ファイルシステム）では、ファイル（SSTable）が作成されるたびに新しいDEKが生成される。
- 分散書き込み時の挙動:
データが書き込まれる際、Spannerはそのチャンク専用のDEKを生成し、データを暗号化する。そのDEKはKEKによってラップされ、データのメタデータとして保存される。
- 読み取り時の挙動:
コンピュートノード（Spannerサーバー）は、まずラップされたDEKを取得し、KEKを用いて復号（アンラップ）する。復号されたDEKはメモリ上にキャッシュされ、実際のデータ復号に使用される。
「KMSへの通信がボトルネックになるのでは？」という懸念を持つかもしれない。だが、Spannerは賢い。DEKのアンラップ結果をセキュアにキャッシュすることで、リクエストごとのKMS叩きを回避している。ここが、ミリ秒以下のレイテンシを維持する鍵だ。
—
3. 鍵のローテーションが分散データに与える「真の影響」
ここからが実務で最も重要なポイントだ。鍵をローテーション（更新）したとき、Spannerの内部で何が起きているか？
多くの人間は「鍵を変えたら、ペタバイト級のデータがすべて再暗号化されるのではないか」と怯えるが、それは誤解だ。
遅延再暗号化（Lazy Re-encryption）のメカニズム
KEKやMEKが更新されても、既存のDEKで暗号化されたデータブロックが即座に書き換えられることはない。
1. 新規データ: 新しいバージョンの鍵で暗号化される。
2. 既存データ: 古いバージョンの鍵でラップされたDEKを保持し続ける。
3. バックグラウンドでの収束: Spannerの「Compaction（データのマージ・再配置）」プロセスが走る際、古い鍵で暗号化されていたデータが読み出され、最新の鍵で再暗号化されて書き込まれる。
つまり、ローテーションによるI/O負荷のスパイクは発生しない。アーキテクチャが「定常的なバックグラウンド処理」として再暗号化を吸収するように設計されているからだ。
—
4. CMEK（カスタマー管理暗号鍵）の設計パターンと罠
エンタープライズ要件では、Google管理の鍵（GMEK）ではなく、自分たちのCloud KMSで管理する鍵（CMEK）を使いたいという要求が必ず出る。この時、リードエンジニアとして以下の2点を死守せよ。
① 可用性の連鎖
CMEKを採用した瞬間、君たちのSpannerの可用性は「Cloud KMSの可用性」に依存する。KMSが死ねば、SpannerはDEKを復号できず、すべてのリクエストに対して `FAILED_PRECONDITION` を返す「高価な文鎮」と化す。
② 鍵の無効化（Kill Switch）の威力
CMEKの最大の利点（かつリスク）は、KMSで鍵を無効化した際の挙動だ。
鍵を無効化するコマンド（極めて慎重に実行せよ）
gcloud kms keys versions disable [VERSION] \
–key [KEY_NAME] \
–location [LOCATION] \
–keyring [KEYRING_NAME]
これを実行すると、Spannerは数分以内にデータを読み取れなくなる。これは、法的なデータ消去要件や、万が一のインシデント時の緊急停止には有効だが、設定ミスによる「自爆」のリスクを孕んでいる。
—
5. パフォーマンスと運用の極限知見
最後に、現場で役立つチェックリストを授ける。
- KMSのクォータ監視:
CMEKを使用する場合、Spannerインスタンスの起動時やノードのスケール時に、一斉にKMSへの `Decrypt` リクエストが飛ぶ。KMSのクォータ（Requests per minute）が不足していると、インスタンスの立ち上がりが遅れる。
- マルチリージョン構成での鍵配置:
Spannerがマルチリージョンなら、KMSもそれに合わせた場所に配置しなければならない。物理的な距離は、暗号化のオーバーヘッド以上に、鍵の取得レイテンシとして跳ね返ってくる。
- ログの監査:
「誰が、いつ、どのデータにアクセスするための鍵を復号したか」はCloud Audit Logsに記録される。これをSIEMと連携させるのが、モダンなセキュリティ設計だ。
結論
Cloud Spannerの暗号鍵階層は、「高度なセキュリティ」と「極限の分散パフォーマンス」を両立させるための芸術的なトレードオフの産物だ。
DEKがデータの傍らにあり、KEK/MEKがそれを統治する。この構造を理解していれば、鍵のローテーションを恐れる必要はないし、CMEKを導入する際のリスクも正しく管理できる。
「データは常に暗号化されている」という安心感に甘んじるな。その暗号化がどう動いているかを知って初めて、君は真に信頼に足るシステムを構築できる。
以上だ。次の設計レビューでは、この視点からチームの設計を問い直してみてくれ。
コメント