キー管理と
フェデレーション
鍵を配って守るか、身元を短命のトークンに替えるか。
5S LABのWebアプリの構成で比べる。
鍵は、持っている人なら誰でも使える。
盗まれた鍵と本物の鍵を、相手のサービスは見分けられない。
2025年に、公開GitHubへ新たに漏れたシークレット（前年比34%増）
2022年に見つかった、まだ使えたシークレットのうち、2026年1月の時点でも使えたもの
だから各社は、長く使う鍵より短命の資格情報を勧めている
2024年5月3日以降に作った組織では、サービスアカウントキーの作成を既定で止めている
本番でクライアントシークレットを使わないよう求めている
いずれも、外部の身元を短命の資格情報に替える方式を用意している
合鍵を配るか、受付で入館証をもらうか。
鍵を保管して使う ＝ 合鍵
- 管理人が合鍵を作り、使う人に配る
- 誰が持っていても、扉は開く
- なくしたら、鍵を替えて全員に配り直す
フェデレーション ＝ 入館証
- 受付で社員証を見せ、その日だけ使える入館証をもらう
- 社員証は、会社（発行元）が保証している
- 入館証は夕方には切れる。なくしても翌日は使えない
アプリの身元（サービスアカウント）を、実行環境が証明する
相手側に登録する、受け入れる身元
既定で1時間ほどで切れる
鍵は、発行・保管・配布・取り替えを、使うあいだ続ける。
身元のIDトークンを、相手が短命のトークンに替える。
- 実行環境の窓口に、相手向けのIDトークンを頼む。窓口は環境の中からしか呼べない
- Googleが「誰が・誰に向けて・いつまで」を署名して返す。長く使う秘密ではないが、期限内は持っている人が使えるので、ログや応答に出さない
- IDトークンを、相手の交換窓口に渡す
- 相手は署名を確かめ、登録した信頼の設定と照らす。一致すれば短命のトークンを返す
- そのトークンを付けてAPIを呼ぶ
- 結果が返る。切れる前に1から取り直す（5S LABは期限の5分前まで使い回す）
漏れたときの被害と、続く手間が違う。
| 観点 | 鍵を保管して使う | フェデレーション |
|---|---|---|
| 漏れたら | 消すまで、誰でも使える | 既定で1時間ほどで切れる |
| アプリが持つ物 | 長く使える鍵の写し | 身元だけ。盗まれる長期の値が無い |
| 取り替え | 使うあいだ、ずっと続く | 要らない |
| 絞り方 | 持つ人を区別できないので、APIや送信元で絞る | 環境・身元ごとに絞れる（stgだけ止める、もできる） |
| 最初の手間 | 小さい。発行して配るだけ | 相手ごとに信頼の設定を作る。作り方は相手ごとに違う |
| ローカル開発 | 鍵を渡せば動く | 手元にメタデータサーバが無い。開発者のログインや開発用の鍵を使う |
漏れたあと使える時間が、桁で違う。
シークレット
Claude API
寿命は相手ごとに決められる
Anthropicは60秒〜24時間（既定1時間）、AWSは15分〜12時間（既定1時間）。5S LABはClaude APIを10分にしている。
取り消せないトークンもある
Googleのサービスアカウントのトークンは、期限の前に取り消せない。だから寿命は短く、権限は小さく保つ。
同じ構成でも、アプリが持つ秘密の数が変わる。
外部APIの鍵5個に、対応していない相手の鍵とアプリ自身の鍵の4個を足して9個。配備のため、GitHubにもGoogleのサービスアカウントキーを置く。
身元はメタデータサーバがその場で発行する。残る4個はDB・Googleログイン・LINE・セッションの署名鍵。
渡す身元は1つ。交換のしかたは相手ごとに違う。
身元は、環境ごとの実行用サービスアカウント（SA）。人ではなくアプリに割り当てる、Google Cloudのアカウントのこと。
| 相手 | 交換のしかた | 返ってくる物 | 許可を決める所 |
|---|---|---|---|
| GoogleGemini・TTS・地図 | 交換しない。メタデータサーバから直接もらう | アクセストークン | 実行用サービスアカウントのロール |
| MicrosoftAzure AI・ログイン | Entra IDのFICで交換 | Entraのトークン | 環境ごとのマネージドIDのロールAzure AIはキー認証を無効にしている |
| AWSSESのメール送信 | IAMロールを引き受ける（AssumeRoleWithWebIdentity） | 一時的な資格情報 | ロールの信頼（実行用SAだけ）と権限送信元は no-reply@5slab.jp に限る |
| AnthropicClaude API | WIFのルールで交換 | 10分で切れるトークン | ルール（発行元・audience・subject・メール）環境ごとに分ける |
| GitHub Actions配備 | Google CloudのWIFで交換 | 配備用SAのトークン | 5slab/universal の main からの実行だけ |
信頼の設定は、身元をぴったり指す。
IDトークンの中身
相手側の信頼の設定
- 発行元が accounts.google.com と一致する
- subject が、この環境の実行用SAだけに一致する
- audience が、自分宛ての値と一致する
!subjectとaudienceを固定する
発行元が同じなら、ほかの人も同じ形のトークンを持てる。5S LABはsubjectの前方一致に「*」を使わない（Googleのsubjectは数字だけで、ほかのプロジェクトのSAまで通る）。
!環境ごとに分ける
stgとprodで、サービスアカウント・FIC・ルールを別にする。片方だけ止められる。
!権限を最小にし、見張る
実行環境を乗っ取られると、その身元で呼ばれる。フェデレーションは鍵の漏えいを防ぐが、アプリの脆弱性は防がない。
残るのは、相手が対応していない鍵と、ブラウザで使う鍵。
| 鍵 | なぜ残るか | どう守るか |
|---|---|---|
| 地図のキーブラウザ | ブラウザに置かないと地図が動かない | 参照元・使えるAPI・1日の上限・8割で通知 |
| DBのパスワードPlanetScale | パスワード認証しか無い | Secret Manager。接続元のIPで絞る予定 |
| Googleログインクライアントシークレット | Googleの窓口が client_secret（post／basic）しか受け付けない | Secret Manager。定期的に取り替える |
| LINEのトークンMessaging API | チャネルアクセストークンで呼ぶ作り。フェデレーションに未対応 | Secret Manager。prodだけに置く |
| セッションの署名鍵アプリ自身 | 外部の認証ではない（減らす対象ではない） | 環境ごとに生成し、Secret Manager |
見られる前提の鍵は、使い道と量で絞る。
地図（Maps JavaScript API）は、ブラウザにキーを置かないと動かない（2026年10月時点）。
それでも残ること
スクリプトからなら参照元は偽装できる。ただし上限があるので費用は増えない。残る被害は、上限を使い切られてその日の地図が止まることだけ。
Firebase App Checkは入れていない
偽装まで防げるが、読み込みの重さ・プライバシー・設定の手間に見合わないと判断した。
対応していればフェデレーション。鍵は残すものだけ。
対応している？
鍵を守る仕事を、身元の設定に置き換える。
- 相手が対応していれば、鍵ではなくフェデレーション。アプリは秘密の値を持たず、トークンは既定で1時間ほどで切れる。
- 信頼の設定は、発行元・subject・audienceで身元をぴったり指し、環境ごとに分ける。
- 残す鍵は、絞る・隠す・取り替える・見張るを重ね、どこで使っているかを記録する。
- Googleサービスアカウントキーの扱い
- Google安全な既定の組織
- Microsoftアプリ登録のセキュリティ
- MicrosoftGoogle Cloudの身元を信頼する
- AWSAssumeRoleWithWebIdentity
- AnthropicWorkload identity federation
- GitHubOpenID Connect
- GoogleMaps APIのセキュリティ
- GitGuardianThe State of Secrets Sprawl 2026
- IETFRFC 8693・RFC 7523