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

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

一つのサービスアカウントに複数用途を載せると、事故の切り分けが難しくなります

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

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

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

長寿命の鍵ファイルは『守る対象』である前に『減らす対象』です

サービスアカウントの鍵ファイルは、平文のパスワードより少し複雑に見えるだけで、実務上は同じく持ち出しや複製の対象です。リポジトリ、成果物保管先、継続的インテグレーションの環境変数、開発者端末、共有ストレージ、メール添付など、置き場所が増えるほど漏えい経路も増えます。つまり鍵ファイルは、「安全に保管する」だけでは不十分で、そもそも長く持たない構成へ寄せることが重要です。

既存の 公開リポジトリの情報漏えいとは？ が扱うように、秘密情報はリポジトリから漏れることがあります。ただしサービスアカウントの問題は、それだけではありません。リポジトリに出ていなくても、成果物保管先やビルドキャッシュ、継続的インテグレーションの実行環境に長寿命の鍵が残っていれば、攻撃者は同じ認証情報を再利用できます。だから本記事の主役は漏えい経路ではなく、長寿命の認証情報を使い続ける設計そのものです。

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

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

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

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

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

付与済みIDと短命の認証情報を優先し、鍵配布を既定にしないことが重要です

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

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

また、フェデレーションや付与済みIDを導入するときも、単に「新しい方式へ移す」だけでは足りません。どのワークロードを対象にし、誰が承認し、鍵ファイルをいつ無効化するかまで決める必要があります。そうしないと、新旧の認証情報が並走し、結果的に攻撃対象の広がりが大きくなることがあります。

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

鍵を減らす設計は、まず機械IDの棚卸しから始まります。どのサービスアカウントが、どのワークロード、どのリポジトリ、どの処理基盤、どの SaaS 連携で使われているのかが見えなければ、削減対象も、最小権限化の対象も決まりません。つまり鍵管理は秘密情報管理の問題である前に、機械IDの台帳管理の問題でもあります。

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

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

加えて、棚卸し結果は一度作って終わりにしないことが重要です。新しい連携が増えるたびに機械IDも増えやすく、暫定運用のまま残ると用途不明の認証情報が再び増えます。月次レビューで「新規追加」「廃止予定」「責任者未確定」を見分けられるようにしておくと、削減計画と最小権限化を継続しやすくなります。 棚卸しの継続そのものが安全性を左右します。ここを止めないことが重要です。

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

実行用、配備用、管理用を分けるだけでも被害の広がり方は大きく変わります

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

代理実行も同様で、誰でも広い権限のサービスアカウントを直接使える状態は危険です。必要なときだけ、限定された経路から、限定された範囲で代理実行させる構成へ寄せると、監査しやすくなります。ここでのポイントは、使う認証情報の数より、高権限の認証情報を誰がいつ使えるかを細くすることです。

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

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

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

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

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

被害は鍵ファイル一つではなく、その認証情報が届く範囲で決まります

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

Google Cloud の認証情報漏えい対応ガイダンス↗でも、侵害が疑われる認証情報については無効化、影響範囲確認、関連する秘密情報やトークンの見直しを並行して進める必要が示されています。これは即時失効だけで終えると、同じ認証情報を参照する処理基盤やワークロードが止まり、復旧判断が混乱するためです。だから初動手順には、失効、代替認証情報、依存先通知、監査ログ確認まで含めておく必要があります。

もう一つの論点は、漏えい経路の特定です。リポジトリから出たのか、成果物に残っていたのか、端末から持ち出されたのか、継続的インテグレーションの環境変数に残っていたのかで、再発防止策は変わります。サービスアカウントの初動対応は、認証情報の停止と設計の見直しを同時にやることが重要です。

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

機械IDの問題は、認証情報管理だけで閉じません。どの継続的インテグレーションの接続先、成果物配信ホスト、管理画面、検証環境、API ホストが外から見えているかも、同時に整理する必要があります。外部公開面が曖昧なままだと、どこから認証情報が参照されうるのかを把握できません。つまりサービスアカウントのセキュリティは、公開面の可視化と分離できないのです。

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

結局のところ、サービスアカウントの事案を小さくするには、機械IDの台帳、鍵削減、最小権限、公開面の把握、失効手順を一つの流れとして回すしかありません。どれか一つだけ整っていても、残りが崩れていれば被害は広がります。だから機械IDのセキュリティは、単発の認証情報管理ではなく、継続運用の問題として扱う必要があります。

機械IDの棚卸しと定期見直しをどう定着させるか

台帳には用途だけでなく、発行元、秘密の置き場、停止手順まで入れるべきです

機械IDの棚卸しが続かない最大の理由は、台帳が「名前の一覧」で終わることです。実務で必要なのは、どの機械IDが、どの実行基盤で、どの秘密情報を使い、誰が停止判断を持ち、停止したときにどの処理が止まるかまで追える状態です。ここが欠けると、棚卸しはしていても、廃止や置き換えの判断へ進みません。

台帳へ最低限入れたいのは、用途、環境、本番か検証か、権限範囲、秘密の保管先、発行元、最終利用日、管理責任者、停止時の連絡先です。これだけでも、用途不明の機械ID、誰も責任を持っていない鍵、長く使われていないのに残っている認証情報が見えやすくなります。

CI、委託先連携、SaaS連携を同じ台帳へ戻すと、削減優先度が見えます

事故時に迷いやすいのは、継続的インテグレーション基盤、業務委託先、SaaS 連携で使う機械IDが別々に管理されているケースです。担当部署が違うため、各チームは自分の範囲しか把握しておらず、全体では同じ権限を重複して持つ機械IDが残りやすくなります。これでは、削減したつもりでも別経路に同等権限が残ります。

ここで効くのは、技術の違いより先に「どの外部接点とどの処理が結び付いているか」で台帳をそろえることです。継続的インテグレーション基盤、外部サービス連携、委託先作業、定時ジョブを一つの視点で見ると、同じ役割を持つ機械IDをまとめて減らせる箇所と、高権限のまま分散している危険箇所が分かります。

月次レビューは『権限が広いもの』より『説明できないもの』から減らすと進みます

定期見直しを始めると、つい権限の大きい機械IDだけに目が向きます。しかし実務では、「誰のものか分からない」「何のために残っているか説明できない」「秘密情報の保管先が複数ある」といった説明不能な機械IDの方が処理しやすく、しかも事故の温床になりやすいです。まず説明できないものを減らすと、全体の台帳品質が上がり、残る高権限機械IDの見直しも進みます。

月次レビューでは、作成数や削除数だけでなく、用途不明件数、長寿命鍵の残数、共有名義の有無、最終利用日が古いままの件数を追ってください。こうした指標を持つと、機械IDの管理は単なる運用負債の整理ではなく、漏えい時の被害面積を毎月小さくする活動として説明しやすくなります。

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

ASM診断 PRO はサービスアカウントの鍵を保管する専用製品でも、IAM 設計専用の製品でもありません。それでも機械IDの見直しに有効なのは、どの公開面が外から見えているか を先にそろえられるからです。継続的インテグレーションの結果配信先、管理画面、公開 API、古い検証環境、用途不明のホストが残っていると、どの機械IDをどこまで切り替えるべきかの判断が難しくなります。

とくにサービスアカウントの事案では、認証情報だけを止めても、外へ出ている接点が残っていれば再発防止になりません。ASM診断 PRO を起点に、外から届くホスト、ログイン画面、API 導線、古いサブドメインを棚卸しすると、「この機械IDはどの公開面を支えているのか」「どの接点はもう止められるのか」が見えやすくなります。つまり機械IDのセキュリティを運用へ落とすには、認証情報の台帳と公開面の台帳をつなげる必要があります。

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

よくある質問（FAQ）

サービスアカウントは一つにまとめた方が管理しやすいですか

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

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

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

機械IDにも多要素認証のような考え方は必要ですか

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

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

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

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

無効化だけでなく、どのワークロード、どの処理基盤、どの公開面へ届く認証情報だったのかを切り分けてください。そこまで見ないと再発防止が弱くなります。

まとめ

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

そのためには、まず機械IDの棚卸しを行い、用途不明のサービスアカウント、共有名義、長寿命の鍵ファイル、広すぎる権限を洗い出してください。次に、鍵を既定にしない設計へ寄せ、付与済みIDや短命の認証情報、限定された代理実行を組み合わせて、実行権限と管理権限を分けます。ここまでできると、漏えい時も「何を止めるか」「どこまで影響するか」を素早く判断しやすくなります。

さらに重要なのは、機械IDの問題を公開面の管理と切り離さないことです。継続的インテグレーションの結果配信先、公開 API、古い検証環境、管理画面、サンプルホストが残っていると、認証情報だけを直しても再発します。だからサービスアカウントのセキュリティは、認証情報台帳、権限設計、外部公開資産の可視化をつないだ継続運用として扱うべきです。ここまで含めて初めて、機械IDを増やしすぎず、漏えい後の被害も小さく抑えやすくなります。