【入門編】サービスアカウントのなりすましと権限委譲 – Cloud Spanner

みなさん、こんにちは！Cloud Spannerの世界へようこそ。

普段は大規模なデータベースの設計や、コンマミリ秒の遅延を削るためのアーキテクチャと格闘している私ですが、今日は少し趣向を変えて、皆さんに「Cloud Spannerを最も安全に、かつスマートに使いこなすためのセキュリティの基本」を、どこよりも分かりやすくお話ししようと思います。

テーマは「サービスアカウントのなりすまし（Impersonation）」と「権限委譲」です。

一見すると「なりすまし」なんて、なんだか物騒な言葉に聞こえますよね（笑）。でも実はこれ、Google Cloud（GCP）の世界、そしてCloud Spannerを安全に運用する上で、最も美しく、最も推奨されている超重要テクニックなのです。

「ここをクリアすれば、Cloud Spannerの基本はバッチリマスターできますよ」

難しい専門用語はできるだけ日常の出来事に置き換えて、優しくステップ・バイ・ステップで解説していきますね。リラックスして、コーヒーでも飲みながら読んでみてください。

—

1. なぜ「直接、鍵を渡す」のがダメなのか？（日常の例えで考える）

まずは、イメージしやすいように日常の例え話から始めましょう。

あなたが、超高級ホテル（Google Cloud）のVIPルーム（Cloud Spanner）に泊まっているとします。部屋には、世界に一つしかない大切な宝物（データベースのデータ）が入った金庫があります。

ある日、あなたは「部屋の掃除と、金庫の中の書類の整理」を、信頼できるホテルのコンシェルジュ（アプリケーションや他のGoogleサービス）に頼むことにしました。

このとき、あなたならどうしますか？

バッドパターン：

自分の部屋のマスターキーと、金庫の暗証番号を紙に書いて、そのままコンシェルジュに手渡す。

これ、すごく怖いですよね？もしコンシェルジュがその鍵を落としたり、悪い人に盗まれたりしたら、ホテルの全員があなたの部屋に入り放題になってしまいます。
グッドパターン（今回のテーマ）：

フロント（IAMというセキュリティの番人）にこう伝えます。
「今から1時間だけ、コンシェルジュの〇〇さんに、私の代理として部屋に入る許可（一時的な通行証）を出してあげて」
フロントはコンシェルジュの身元を確認し、「1時間だけ使える使い捨てのカードキー」を渡します。

この「グッドパターン」こそが、今回のテーマである「サービスアカウントのなりすまし（Impersonation）」と「権限委譲」の正体です。

—

2. 登場人物の整理

Cloud Spannerの世界に置き換えて、登場人物を整理してみましょう。

—

3. 「なりすまし」の美しいステップ（内部の検証プロセス）

では、実際にアプリがCloud Spannerにアクセスするとき、裏側でどのような「信頼のバトンリレー（検証プロセス）」が行われているのか、その美しい流れを覗いてみましょう。

[開発者 / アプリ]
│
│ 1. 「サービスアカウントの仮面を被らせて！」と申請
▼
[ IAM (門番) ] ── 2. 「君は信頼できるから、1時間だけ仮面を貸そう」
│
│ 3. 一時的なトークン（使い捨ての鍵）を発行
▼
[開発者 / アプリ] (仮面を装着完了！)
│
│ 4. 「Spannerさん、データを読ませて」とリクエスト
▼
[ Cloud Spanner ] ── 5. 「よし、本物のトークンだな。アクセス許可！」

ステップ1：申請（私はコンシェルジュになります）

あなたのプログラム（または開発者であるあなた自身）が、Google Cloudの門番（IAM）に対して、
「私は `spanner-reader` というサービスアカウントになりすましたいです」と申請します。

ステップ2：門番（IAM）のチェック

IAMは、申請してきたあなた自身が「そのサービスアカウントになりすます資格（権限）を持っているか」を厳格にチェックします。

※この資格のことを `Service Account Token Creator`（サービスアカウントトークン作成者）ロールと呼びます。

ステップ3：一時的な鍵（トークン）の発行

チェックが通ると、IAMは「分かりました。では1時間だけ有効な使い捨ての鍵（アクセストークン）を差し上げます」と、鍵を渡してくれます。
これで、あなたのプログラムは晴れて「サービスアカウントの仮面」を被ることができました。

ステップ4：Spannerへのアクセス

プログラムはその「使い捨ての鍵」を持って、Cloud Spannerにデータを読みに行きます。

ステップ5：Spannerによる検証

Cloud Spannerは、渡された鍵を見て「うん、これはIAMが公式に発行した、有効期限内の本物の鍵だね」と検証し、安全にデータを返します。

—

4. なぜこの方法が「極限に安全」なのか？

昔ながらのやり方では、サービスアカウントの「秘密鍵（JSONファイル）」をダウンロードして、サーバーのどこかに保存していました。

しかし、これは「マスターキーをその辺に放置する」のと同じくらい危険です。もしソースコードと一緒にGitHubにうっかり公開してしまったり、サーバーがハッキングされたりしたら、一発でアウトです。

「なりすまし（Impersonation）」を使えば：
1. 秘密鍵ファイル（JSON）がこの世に存在しない： 盗まれる対象そのものがありません。
2. 有効期限がめちゃくちゃ短い： 万が一、一時的な鍵が漏洩しても、最大1時間（設定によっては数分）で自動的にゴミ屑になります。
3. 監査ログが完璧に残る： 「誰が、いつ、どのサービスアカウントになりすましたか」が全てGoogle Cloudのログに残るため、悪いことができません。

—

5. 【実践】どうやって設定するの？（イメージで掴む）

「概念は分かったけれど、設定が難しそう…」と思うかもしれませんね。でも安心してください。Google Cloudのツール（gcloudコマンド）を使えば、驚くほどシンプルに実現できます。

例えば、あなたがローカルのパソコンから、本番環境のSpannerに安全にアクセスしたいときの設定例です。

手順A：門番（IAM）に「なりすまし」の許可を与える

まずは、あなた（`you@example.com`）が、サービスアカウント（`spanner-admin-sa`）になりすますことを許可します。

これは管理者が1回だけ実行するコマンドです
gcloud iam service-accounts add-iam-policy-binding \
spanner-admin-sa@your-project.iam.gserviceaccount.com \
–member=”user:you@example.com” \
–role=”roles/iam.serviceAccountTokenCreator” # 「なりすまし」を許可する魔法のロール

手順B：なりすました状態でSpannerのデータを覗いてみる

許可がもらえたら、あとはコマンドを叩くだけです。裏側で自動的に「一時的な鍵」が発行され、Spannerにアクセスします。

`–impersonate-service-account` オプションをつけるだけ！
秘密鍵のファイルをダウンロードする必要は一切ありません。
gcloud spanner databases execute-sql my-database \
–instance=my-spanner-instance \
–sql=”SELECT FROM Users WHERE UserStatus = ‘Active’ LIMIT 5;” \
–impersonate-service-account=”spanner-admin-sa@your-project.iam.gserviceaccount.com”

コードの解説：
`–impersonate-service-account`：これが「今からこのアカウントの仮面を被ります」という宣言です。
コマンドが実行される瞬間だけ、裏側で「一時的な通行証」が発行され、Spannerがそれを検証してデータを安全に返してくれます。

—

まとめ：安全なSpanner運用の第一歩を踏み出したあなたへ

お疲れ様でした！難しそうに見えた「サービスアカウントのなりすましと権限委譲」が、実は「安全に、かつスマートに鍵を貸し借りするための、思いやりに満ちた仕組み」であることが伝わったでしょうか？

今回のポイントを3行で振り返りましょう。

1. 秘密鍵（JSON）はもうダウンロードしない！（これが最大のセキュリティリスク）
2. 「一時的な通行証（トークン）」を門番（IAM）に発行してもらう。
3. Cloud Spannerはその通行証を厳格に、かつ一瞬で検証してアクセスを許可する。

この仕組みを理解し、実践できるようになれば、Cloud Spannerのセキュリティ設計はもう初心者卒業、立派な中級者への第一歩を踏み出しています。

「大切なデータを守るために、最もスマートな方法を選択する。これこそが、一流のエンジニアへの道ですよ」

これからも、Cloud Spannerの美しくパワフルな世界を一緒に楽しんでいきましょう。また次のステップでお会いできるのを楽しみにしています！