サービスアカウント
Service Account ・ さーびすあかうんと
人間でなくプログラムに与えるID。自動化時代の認証・認可の主役。
概要
サービスアカウントは、人間ではなくプログラム — バッチ処理、CI/CD パイプライン、サーバ上のアプリケーション、コンテナ内のワークロードなど — に与えるアカウントです。人間のアカウントと同じように認証を受け、権限を割り当てられ、監査ログに行動が記録されますが、その主体はソフトウェアです。「深夜2時にデータベースをバックアップしているのは誰か？」という問いに「backup-job というサービスアカウントです」と答えられるようにする仕組み、と言えます。
現代のシステムでは、APIを呼ぶ回数も権限を行使する回数も、人間よりプログラムのほうが圧倒的に多くなっています。クラウドの IAM（アクセス管理）、Kubernetes の ServiceAccount リソース、Active Directory のマシンアカウントなど、名前や実装は環境ごとに違っても、「機械にも一人前のIDを持たせて統制する」という考え方は共通です。人間のID（ヒューマンアイデンティティ）に対して、こちらはワークロードアイデンティティ、ノンヒューマンアイデンティティなどと総称されます。
なぜ生まれたか
サービスアカウントが無かった時代、自動処理は誰かの個人アカウントを間借りして動いていました。担当者のIDとパスワードをバッチ処理の設定ファイルに書き込む、という運用です。これは二重に破綻します。まず、その担当者が退職してアカウントを無効化した瞬間、夜間バッチが全滅します。逆に「バッチが動かなくなるから」と退職者のアカウントを残せば、それは所有者不在の生きた侵入口です。さらに監査の面でも、ログに残る「Aさんの操作」が本人の操作なのか自動処理なのか区別できず、「誰が何をしたか」の追跡が成り立ちません。
そこで、人間と自動処理のIDを分離し、プログラムには専用のアカウントを発行するという原則が確立しました。サービスアカウントは特定の個人に紐づかないため退職の影響を受けず、権限はその処理に必要な分だけに絞れ、ログ上でも人間の操作と明確に区別できます。「機械を人間の影として扱うのをやめ、独立した主体として管理する」 — これがサービスアカウントという抽象の本質です。
詳細
人間のアカウントとの対比
サービスアカウントは人間のアカウントと多くの仕組みを共有しますが、性質は対照的です。人間はパスワードと MFA で対話的にログインしますが、サービスアカウントに対話はなく、鍵やトークンによる非対話の認証だけが許されます（むしろ対話ログインは無効化するのが定石です）。人間のIDは入社・異動・退職というライフサイクルを人事と連動して管理しますが、サービスアカウントのライフサイクルはシステムの構築・変更・廃止に連動し、放置すると「何に使われているか誰も知らない」孤児アカウントが溜まっていきます。そして数の面では、今日の組織ではサービスアカウントが人間のIDの数十倍存在するのが普通で、攻撃者にとっても「MFAが無く、権限が強く、監視が甘い」格好の標的になっています。
最小権限が生命線
サービスアカウントの設計原則は最小権限に尽きます。人間と違ってサービスアカウントの職務は明確です。バックアップジョブなら「特定のストレージへの書き込み」だけ、レポート集計なら「特定のテーブルの読み取り」だけが必要で、それ以外の権限を持つ理由がありません。にもかかわらず、現実には「動かないから」と管理者権限を与えたまま放置されるケースが後を絶たず、そのアカウントの資格情報が1つ漏れただけで環境全体が陥落します。用途ごとにアカウントを分ける（1ジョブ1アカウント）、RBAC のロールで職務単位に権限を束ねる、定期的に実際の利用実績と突き合わせて過剰権限を削る — この地道な運用が、認可の設計としてのサービスアカウント管理の中心です。
鍵の管理から「鍵レス」へ
サービスアカウントの認証は伝統的に長命の資格情報 — APIキー、パスワード、秘密鍵 — に頼ってきました。しかしこの方式には根本的な弱点があります。鍵はどこかに置かなければならず、置かれた鍵は漏れうるのです。設定ファイルへの直書き、Git リポジトリへの誤コミット、退職者の手元に残った鍵ファイル。シークレット管理サービスで保管とローテーションを自動化するのが第一の対策ですが、より根本的な解決として近年主流になりつつあるのが、長命の鍵そのものを無くす「鍵レス（keyless）」化です。
代表例がクラウドの Workload Identity（AWS の IAM ロール、Google Cloud の Workload Identity 連携、Azure の Managed Identity など）です。発想はこうです。クラウド基盤は、どの仮想マシン・どのコンテナが動いているかを基盤自身が知っています。ならば、ワークロードが「私は誰か」を鍵で証明しなくても、基盤が身元を保証して短命のトークンを発行すればよい。GitHub Actions から AWS へデプロイする場面なら、CI 側が発行する OIDC の ID トークン（署名付きの JWT）をクラウド側が検証し、数時間で失効する一時的な資格情報と交換します。盗む価値のある長命の鍵が、そもそもどこにも存在しなくなるのです。
Kubernetes とゼロトラストの文脈で
Kubernetes では ServiceAccount が第一級のリソースで、Pod に紐づけられたアカウントのトークンが自動でマウントされ、Pod はそれを使って API サーバや外部サービスに自分の身元を証明します。かつては無期限のトークンが発行されていましたが、現在は有効期限付き・用途限定のトークンへの投影（projected token）が標準になり、ここでも短命化の流れは一貫しています。さらにサービスメッシュでは、ワークロードのIDを証明書として発行し、サービス間を mTLS で相互認証する構成が採られます。「ネットワークの内側だから信用する」のではなく、ワークロード一つひとつが検証可能なIDを持って初めて通信を許す — サービスアカウントは、ゼロトラストアーキテクチャを機械同士の世界で成立させるための土台なのです。