クラウドセキュリティ

サービスアカウントさーびすあかうんと

IAM認証権限管理クラウドAPI最小権限の原則

サービスアカウントについて教えて

簡単に言うとこんな感じ！

「人間じゃなくてアプリやプログラムが使うID」だよ！たとえば夜中に自動でバックアップするスクリプトが「誰として」サーバーにログインするか——それを担うのがサービスアカウントなんだ。人間が毎回ログインする代わりに、プログラム専用のIDを用意しておく仕組みってこと！

サービスアカウントとは

サービスアカウント（Service Account）とは、人間のユーザーではなく、アプリケーション・バッチ処理・マイクロサービスといった「プログラム」が認証・操作を行うために使う専用のアカウントのことです。通常のユーザーアカウントが「人」に紐づくのに対し、サービスアカウントは「システムやプロセス」に紐づきます。

たとえば、夜間に自動でデータベースをバックアップするスクリプト、複数のクラウドサービスを連携するAPI、継続的インテグレーション（CI/CD）ツールがソースコードをデプロイする処理——これらはすべて「誰かの名前」でシステムにアクセスしなければなりません。そこで従業員の個人アカウントを使い回す代わりに、専用のサービスアカウントを発行することで、責任の所在を明確にし、セキュリティを高められます。

クラウド環境（AWS・Google Cloud・Azureなど）では、サービスアカウントはIAM（Identity and Access Management：身元確認と権限管理の仕組み）の中核概念として広く使われており、最小権限の原則（必要最低限の権限だけを与える考え方）と組み合わせることが強く推奨されています。

サービスアカウントの仕組みと種類

サービスアカウントは「認証情報（鍵）」を持ち、その情報を使ってシステムがAPIやリソースへアクセスします。

項目	通常ユーザーアカウント	サービスアカウント
使う主体	人間	アプリ・スクリプト・サービス
認証方法	パスワード・MFA	APIキー・秘密鍵・トークン
ログイン画面	あり	なし（プログラムから直接）
権限付与の考え方	役職・業務に合わせて	処理に必要な最小限のみ
管理の単位	従業員単位	アプリ・機能単位

主要クラウドでの呼称と特徴

クラウド	名称	認証の仕組み
Google Cloud	サービスアカウント	JSON形式の秘密鍵 / Workload Identity
AWS	IAMロール / IAMユーザー	アクセスキー+シークレット / AssumeRole
Azure	サービスプリンシパル	クライアントシークレット / 証明書
オンプレミス	サービスアカウント（AD管理）	パスワード / Kerberos

覚え方：「人の代わりに働くロボット社員」

サービスアカウントは「24時間働けるロボット社員」と覚えると分かりやすいです。ロボットは会社のIDカード（＝サービスアカウント）を持って決まった仕事だけをします。そのIDカードには「倉庫には入れるけど役員室はNG」という権限が設定されている、というイメージです。

歴史と背景

1990年代〜2000年代初頭：Windowsサーバー環境でサービス（IISやSQL Serverなど）を動かすための「サービスアカウント」が一般化。Active Directoryで管理されるようになる
2006年頃〜：AWSのIAMが登場し、クラウドリソースへのアクセス制御が体系化される。「IAMロール」「IAMユーザー」という概念が広まる
2011年：Google Cloud（当時Google App Engine）でもサービスアカウントが整備され始める
2014年〜：DockerやKubernetesの普及でマイクロサービスが増加。サービス同士の認証が大量に必要になり、サービスアカウント管理の重要性が急上昇
2018年〜現在：Workload Identity（サービスアカウントキーを持たずにIDフェデレーションで認証する仕組み）が主要クラウドで普及。鍵の漏洩リスクを減らす方向へ進化

サービスアカウントの構造とアクセスフロー

サービスアカウントがどのようにリソースへアクセスするかを図解します。

よくある誤った使い方と対策

❌ NGな使い方：

個人の社員アカウントでバッチ処理を動かす（退職したらアクセス不能になる）
1つのサービスアカウントを複数のアプリで使い回す（漏洩時の影響範囲が広がる）
管理者権限（Admin）をサービスアカウントに与える（不要な全権限を持たせる）
APIキーをソースコードに直書きする（GitHubに公開されると即アウト）

✅ 正しい使い方：

アプリ・機能ごとに専用のサービスアカウントを1つ作る
必要最小限の権限だけ付与する（最小権限の原則）
鍵はSecret ManagerやVaultに保存し、コードに書かない
定期的に鍵をローテーション（交換）する
可能ならWorkload Identity（鍵不要の認証）を使う

規格・RFC番号	内容
RFC 6749	OAuth 2.0 フレームワーク（サービスアカウントの認可フローの基盤）
RFC 7519	JWT（JSON Web Token）：サービスアカウントの認証トークンとして広く使用
RFC 8693	OAuth 2.0 Token Exchange（Workload Identityのフェデレーション認証に関連）