サービスアカウントのセキュリティとは？機械ID・鍵管理・権限最小化を徹底解説

サービスアカウントが危険になる典型パターン

一つの service account に複数用途を載せると、事故の切り分けが難しくなります

サービスアカウントのセキュリティで最初に崩れやすいのは、用途の分離です。build、deploy、batch、backup、integration のように別々の処理を、一つの機械IDで兼用している環境は少なくありません。しかしこの構成では、どの処理のために権限が付いているのか、どのログがどの用途を示しているのかが混ざります。つまり問題の本質は鍵ファイルの保管場所だけでなく、機械IDの責任境界が曖昧なことにあります。

Google Cloud の service account best practices↗でも、用途の異なるワークロードで同じ service account を共有しないこと、必要最小限の権限に分けることが繰り返し示されています。これはクラウドの種類に関係なく有効な原則です。一つの機械IDへ複数用途を押し込むほど、漏えい時の被害範囲も、監査時の切り分けも広がります。

人間ユーザーのアカウントは部門や職務である程度分離されていても、non-human identity は「裏方だから」という理由で雑にまとめられやすいです。ですが実際には、バックエンド同士が使う credential の方が権限が強いことも珍しくありません。だからサービスアカウントのセキュリティでは、まず「何のための機械IDか」を明確にする必要があります。

長寿命 key file は『守る対象』である前に『減らす対象』です

service account key file は、平文の password より少し複雑に見えるだけで、実務上は同じく持ち出しや複製の対象です。リポジトリ、artifact、CI の環境変数、開発者端末、共有ストレージ、メール添付など、置き場所が増えるほど漏えい経路も増えます。つまり鍵ファイルは、「安全に保管する」だけでは不十分で、そもそも長く持たない構成へ寄せることが重要です。

既存の 公開リポジトリの情報漏えいとは？ が扱うように、secret は repo から漏れることがあります。ただしサービスアカウントの問題は、それだけではありません。repo に出ていなくても、artifact や build cache、CI 実行環境に長寿命 key が残っていれば、攻撃者は同じ credential を再利用できます。だから本記事の主役は leak の経路ではなく、長寿命 credential を使い続ける設計そのものです。

とくに LLM を使った高速実装では、「まず key file でつなぐ」構成が残りやすくなります。ここで気を付けるべきなのは、最初の暫定実装が本番まで残ることです。サービスアカウントの鍵は、暫定的に置いたつもりでも、後から用途不明の credential として残りやすいため、最初から削減計画を持つ前提で設計した方が安全です。

人間用の統制と機械IDの統制は、似ていても同じではありません

人間ユーザーなら、MFA、端末管理、退職時の停止、利用規程などで統制します。しかしサービスアカウントは、ログイン画面も MFA も前提にしないことが多く、同じ統制だけでは足りません。だから セッショントークン窃取 や OAuth 同意フィッシング の対策を、そのまま機械IDに当てはめるのは危険です。

サービスアカウントで見るべきは、ログイン方法ではなく、どの workload が、どの経路で、どの権限を持つ credential を使うかです。つまり人間IDの守り方より、実行主体と権限のひも付きが重要になります。ここを曖昧にすると、機械IDは誰の責任か分からないまま増え続けます。

鍵を減らす / 使わない設計へどう寄せるか

付与済み identity と短命 credential を優先し、鍵配布を既定にしないことが重要です

サービスアカウントの安全性を上げるうえで最も効果が大きいのは、鍵ファイルの保管ルールを厳しくすることより、鍵配布を既定にしないことです。Google Cloud の guidance でも、可能なら service account key を使わず、実行環境に付与された identity や短命 credential、federation を優先する考え方が示されています。これにより、固定ファイルとして残る credential を減らせます。

ここで重要なのは、鍵をゼロにできない環境があっても、「例外だから使っている」のか「何も考えず既定で配っている」のかを分けることです。前者なら削減計画が作れますが、後者は放置されやすく、数カ月後には用途不明の key file が残ります。つまり安全性の差は、技術スタックだけでなく、鍵を例外として扱えているかで決まります。

また、federation や付与済み identity を導入するときも、単に「新しい方式へ移す」だけでは足りません。どの workload を対象にし、誰が承認し、鍵ファイルをいつ無効化するかまで決める必要があります。そうしないと、新旧の credential が並走し、結果的に attack surface が広がることがあります。

機械IDの棚卸しがないと、削減も最小権限化も進みません

鍵を減らす設計は、まず machine identity の棚卸しから始まります。どの service account が、どの workload、どの repo、どの pipeline、どの SaaS 連携で使われているのかが見えなければ、削減対象も、最小権限化の対象も決まりません。つまり鍵管理は secret 管理の問題である前に、機械IDの inventory の問題でもあります。

既存の SaaS台帳管理とは？ が示すように、データの流れと責任境界を一覧化すると管理しやすくなります。サービスアカウントも同じで、機械IDごとに「用途」「依存先」「発行元」「保管先」「置き換え可否」を持つだけで、削減の優先順位が見えます。ここが曖昧だと、不要な key ほど長く残ります。

棚卸しで特に注意したいのは、使われていないように見えるが、定時ジョブや例外運用でだけ呼ばれる credential です。こうした key は誰も日常的に見ていないため、攻撃者に使われても検知が遅れます。だから台帳には「ふだんの利用頻度」だけでなく、呼ばれ方の条件も残した方が、廃止判断や監視の設計がしやすくなります。

権限最小化と impersonation をどう考えるか

runner、deploy、admin を分けるだけでも被害の広がり方は大きく変わります

サービスアカウントの被害が大きくなりやすい理由の一つは、実行権限と管理権限が同じ機械IDに載っていることです。たとえば build runner が deploy や key 管理までできると、その credential が漏れた瞬間に環境横断の変更権限まで奪われます。だから最小権限化では、role の数を減らすより、実行の責任と管理の責任を分けることが重要です。

impersonation も同様で、誰でも広い権限の service account を直接使える状態は危険です。必要なときだけ、限定された経路から、限定された scope で代理実行させる構成へ寄せると、監査しやすくなります。ここでのポイントは、使う credential の数より、高権限 credential を誰がいつ使えるかを細くすることです。

もし build、deploy、backup、incident 対応が同じ機械IDに乗っているなら、最小権限化の前に設計の分離が必要です。role を微調整しても、責任境界が一つに固まっていれば影響範囲は広いままです。だからサービスアカウントの権限設計では、ロール設計より先に、用途単位の分割を優先してください。

最小権限は role の数を減らすことではなく、影響範囲を局所化することです

最小権限というと、権限を少なくすることだけに意識が向きます。しかし実務で重要なのは、漏えい時に何がどこまで広がるかを小さくすることです。たとえば一つの service account が複数環境、複数プロジェクト、複数 SaaS をまたいでいると、role 名が小さく見えても blast radius は広がります。つまり最小権限とは、権限の文字列ではなく、影響範囲の境界を狭める設計です。

そのため、権限見直しでは「この role が広いか狭いか」だけでなく、「この account がどの環境へ届くか」「どの pipeline から使えるか」「代理実行は誰が承認するか」まで見てください。サービスアカウントの security は permission 設定だけでは閉じず、利用経路の設計 とセットで考える必要があります。

漏えい時にどこまで影響が広がるのか

被害は key file 一つではなく、その credential が届く範囲で決まります

サービスアカウントの漏えいで重要なのは、「漏れたかどうか」だけではありません。どの環境、どのデータ、どの管理 API、どの pipeline へ届く credential だったのかで、被害範囲は大きく変わります。つまり service account key の incident は、鍵そのものより、その鍵が接続できる範囲を見なければ判断を誤ります。

Google Cloud の compromised credentials guidance↗でも、侵害が疑われる credential については無効化、影響範囲確認、関連 secret や token の見直しを並行して進める必要が示されています。これは即時失効だけで終えると、同じ credential を参照する pipeline や workload が止まり、復旧判断が混乱するためです。だから runbook には、失効、代替 credential、依存先通知、監査ログ確認まで含めておく必要があります。

もう一つの論点は、漏えい経路の特定です。repo から出たのか、artifact に残っていたのか、端末から持ち出されたのか、CI の環境変数に残っていたのかで、再発防止策は変わります。サービスアカウントの初動対応は、credential の停止と設計の見直しを同時にやることが重要です。

公開面の棚卸しと組み合わせると再発防止が進みやすくなります

機械IDの問題は、認証情報管理だけで閉じません。どの CI endpoint、artifact host、管理画面、staging、API host が外から見えているかも、同時に整理する必要があります。外部公開面が曖昧なままだと、どこから credential が参照されうるのかを把握できません。つまりサービスアカウントの security は、公開面の可視化と分離できないのです。

既存の フロントエンドの API キー露出とは？ や 外部接続点は見えているか？ と合わせて見ると、secret を持つ機械IDと、それが外へ出ていく接点を一緒に見直しやすくなります。漏えい後に「何を止めるか」で迷う組織ほど、credential 台帳と外部公開面の棚卸しを同じ運用へ寄せた方が強くなります。

結局のところ、サービスアカウントの incident を小さくするには、機械IDの inventory、鍵削減、最小権限、公開面の把握、失効 runbook を一つの流れとして回すしかありません。どれか一つだけ整っていても、残りが崩れていれば被害は広がります。だから machine identity の security は、単発の credential 管理ではなく、継続運用の問題として扱う必要があります。

ASM診断 PROで公開面の見直しを始めるなら

ASM診断 PRO は service account key を vault 管理する製品でも、IAM 設計専用の製品でもありません。それでも機械IDの見直しに有効なのは、どの公開面が外から見えているか を先にそろえられるからです。CI の結果配信先、管理画面、公開 API、古い staging、用途不明の host が残っていると、どの機械IDをどこまで切り替えるべきかの判断が難しくなります。

とくにサービスアカウントの incident では、credential だけを止めても、外へ出ている接点が残っていれば再発防止になりません。ASM診断 PRO を起点に、外から届く host、login page、API 導線、古い subdomain を棚卸しすると、「この機械IDはどの公開面を支えているのか」「どの接点はもう止められるのか」が見えやすくなります。つまり machine identity の security を運用へ落とすには、認証情報の台帳と公開面の台帳をつなげる必要があります。

既存の 公開リポジトリの情報漏えいとは？ や SaaS台帳管理とは？ と合わせて見ると、code、artifact、外部公開面、委託先接続のどこに non-human identity の危険が残っているかを横断して確認しやすくなります。機械IDを減らし、鍵を減らし、権限を絞ったあとも、まずは 外から見える接点が今どう残っているか を定期的に把握するところから始めてください。

よくある質問（FAQ）

service account は一つにまとめた方が管理しやすいですか

管理項目は減りますが、用途と権限が混ざって incident 時の切り分けが難しくなります。用途単位で分けた方が、最小権限と監査の両方を回しやすくなります。

鍵ファイルを暗号化して保管すれば十分ですか

十分ではありません。暗号化保管は必要ですが、長寿命 key を配り続ける設計そのものが残ります。可能なら鍵を使わないか、短命 credential へ寄せる方が安全です。

機械IDにも MFA のような考え方は必要ですか

人間ユーザー向けの MFA をそのまま当てるより、利用経路、短命 credential、代理実行、最小権限、ログ監視を重視した方が効果的です。

最初に見直すべきなのは key ですか、それとも権限ですか

どちらも必要ですが、まずは用途単位の棚卸しです。何のための機械IDかが分からなければ、鍵削減も最小権限化も進みません。

漏えいが疑われたら最初に何をすべきですか

無効化だけでなく、どの workload、どの pipeline、どの公開面へ届く credential だったのかを切り分けてください。そこまで見ないと再発防止が弱くなります。

まとめ

サービスアカウントのセキュリティは、秘密を一つ守る話ではありません。機械IDをどの用途で分けるか、長寿命 key をどこまで減らせるか、runner と admin をどう切り分けるか、漏えい時にどこまで影響が広がるかを同時に設計する必要があります。つまり本質は「鍵ファイルを安全に置くこと」ではなく、non-human identity の責任境界を明確にすることです。

そのためには、まず machine identity の棚卸しを行い、用途不明の service account、共有名義、長寿命の key file、広すぎる role を洗い出してください。次に、鍵を既定にしない設計へ寄せ、付与済み identity や短命 credential、限定された代理実行を組み合わせて、実行権限と管理権限を分けます。ここまでできると、漏えい時も「何を止めるか」「どこまで影響するか」を素早く判断しやすくなります。

さらに重要なのは、機械IDの問題を公開面の管理と切り離さないことです。CI の結果配信先、公開 API、古い staging、管理画面、サンプル host が残っていると、credential だけを直しても再発します。だからサービスアカウントの security は、credential 台帳、権限設計、外部公開資産の可視化をつないだ継続運用として扱うべきです。ここまで含めて初めて、機械IDを増やしすぎず、漏えい後の被害も小さく抑えやすくなります。