サービスアカウントの鍵、何個配りましたか — 鍵レス連携という選択 | GH Media
URLがコピーされました

サービスアカウントの鍵、何個配りましたか — 鍵レス連携という選択

URLがコピーされました
サービスアカウントの鍵、何個配りましたか — 鍵レス連携という選択

「請求データを毎晩バッチで集計するのに、サービスアカウントの鍵ファイルを使っています。その鍵、開発を頼んだ会社が置いていったもので、たしかサーバーと、担当者のノートPCと、あとGitHubのどこかにも入っている……はずです」——ある企業の情シス担当に外部連携の棚卸しをお願いしたとき、こう返ってきました。何個の鍵が、どこに、何のためにあるのか分からない。これは自動化を外注してきた会社で驚くほどよく見る状態で、そして最も危うい状態でもあります。

Google Cloud や Google Workspace の API を使った自動化では、長らく「サービスアカウントの鍵ファイル(JSONキー)」を発行して各所に配る方式が使われてきました。しかし2026年現在、GitHub Actions などの処理から鍵を一切ダウンロードせずに認証する「鍵レス」方式(Workload Identity 連携)が実用の標準になっています。本記事では、なぜ鍵ファイルが事故のもとになるのか、鍵レスに移すと何が変わるのかを、社内資料の自動配信という身近な例で解きほぐします。

「鍵ファイル」がなぜ事故のもとになるのか

サービスアカウントの鍵ファイルは、要するにそのアカウントになりすませる合鍵です。便利な反面、次の性質がリスクを生みます。

  • 有効期限が長い:一度発行すると、明示的に失効させない限り何年でも使える。漏れても気づきにくい
  • コピーできてしまう:ファイルなので、PCからPCへ、リポジトリへ、チャットの添付へと簡単に広がる
  • 棚卸しが効かない:どの鍵がどこにあるかを台帳で追い切れず、「使っていない鍵」が放置される
  • 漏洩=即なりすまし:GitHub に誤ってコミットされた鍵が自動収集され、悪用されるのは典型的な事故パターン

ソースコードやシークレットの漏洩がどれだけ広範囲に波及するかは、受託開発における秘密情報と信頼境界の設計でも繰り返し問題になるテーマです。鍵ファイルは、その中でも「配って回った分だけ攻撃面が広がる」性質を持っています。

鍵を配らない「鍵レス」という考え方

鍵レス(Workload Identity 連携)は、ダウンロードする鍵そのものをなくすアプローチです。仕組みをかみ砕くと、こうなります。処理を実行する側(たとえば GitHub Actions)が「私はこのリポジトリのこのワークフローです」という身元証明を提示し、Google 側がその証明を検証したうえで、その場限り・短時間だけ有効なトークンを発行します。作業が終わればトークンは失効し、手元には何も残りません。

つまり、盗まれて困る長期の鍵ファイルが最初から存在しない。漏れる対象がないので、「鍵が流出した」という事故カテゴリそのものが消えます。認証の一元化という点ではSSO によるログイン集約と発想が似ていますが、あちらが「人のログイン」を束ねるのに対し、鍵レスは「プログラム同士の認証」を鍵なしにする、という違いがあります。

分かりやすい効き方 — 社内資料の自動配信

抽象的なので、身近な例で見てみます。「社内マニュアルを Markdown で書いて GitHub にプッシュすると、自動で PDF に変換され、常に最新版が Google ドライブの共有フォルダに置かれる」という仕組みを作るとします。

従来の方式なら、ドライブに書き込むためのサービスアカウント鍵を発行し、それを GitHub の設定に貼り付けることになります。この鍵が漏れれば、ドライブに書き込み放題です。鍵レスにすると、GitHub Actions がその都度短命トークンを取得してドライブへ書き込むため、貼り付ける鍵がありません。「プッシュするだけで最新資料が配られる」という利便性はそのままに、漏れて困る合鍵を持たずに済みます。こうした「地味だが毎回発生する配布・更新」を仕組みに載せる話は、前任者が残した自動化を誰も触れなくなる問題を防ぐうえでも意味があります——属人的なスクリプトと配りっぱなしの鍵は、いつも同じところで詰まるからです。

移行で決めておくこと

鍵レスは強力ですが、既存環境を一気に切り替えるものではありません。実際の進め方としては、次の順序が現実的です。まず既存の鍵の棚卸し——今どのサービスアカウント鍵が発行されていて、それぞれ何に使われているかを洗い出します。セキュリティ設定チェックリストの一項目として、使われていない鍵はこの機会に失効させます。次に、新規の連携から鍵レスで組む方針を決め、リスクの高い(=権限の強い)連携から順に移していきます。あわせて「どのリポジトリの・どのワークフローだけが」トークンを取得できるかという信頼条件を絞り込み、範囲を最小化します。

自動化を外注してきた結果、鍵がどこにいくつあるか分からなくなっている——これは放置するほど棚卸しが難しくなります。外部連携やバッチ処理の鍵を棚卸ししたい、新しい自動化を鍵レスで安全に組みたい、とお考えなら、グリームハブの開発・自動化のご相談へお気軽にお問い合わせください。既存の鍵の洗い出しから、鍵レスへの移行設計までご一緒に進めます。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「TECH」の記事一覧を見る