はじめに

Google Cloudで開発を行う上で避けて通れないのが サービスアカウント（Service Account: SA） です。
Cloud RunやCompute Engineなどのリソースが他のAPIを操作する際に使われる「アプリケーションのための身分証明書」ですが、その強力さゆえに、設定を誤ると重大なセキュリティリスクとなります。

実際、クラウドにおけるセキュリティ事故の多くは、このサービスアカウントの「キー（秘密鍵）」の漏洩に起因しています。
この記事では、サービスアカウントの仕組みを深く理解し、JSONキーを使わない最新の「キーレス認証」を含む、セキュアな運用方法を解説します。

1. 基礎知識：ユーザーアカウントとの決定的な違い

サービスアカウントはIAMの一種ですが、Googleアカウント（人間用）とは明確に異なる特徴を持っています。

特徴	人間用アカウント（Google Account）	サービスアカウント（Service Account）
主体	人間	アプリケーション、VM、CI/CDパイプライン
認証	パスワード + MFA	秘密鍵（JSONキー）、OIDCトークン
ドメイン	`@gmail.com` や企業ドメイン	`@{project-id}.iam.gserviceaccount.com`
管理	Google Workspace等で管理	IAMのAPIで作成・削除

「二面性」という特殊な性質

サービスアカウントには、少し直感に反する「二面性」があります。

アイデンティティとしての側面: リソースに権限を行使する「主体」（Subject）。
リソースとしての側面: 誰かに利用（所有）される「リソース」（Object）。

つまり、サービスアカウント自体にもIAMポリシーを設定できます。「誰がこのサービスアカウントを使えるか（roles/iam.serviceAccountUser）」を制御できるという点が非常に重要です。

2. 認証方式の進化と使い分け

サービスアカウントを利用する方法はいくつかありますが、セキュリティレベルの高い順 に紹介します。

① リソースへのアタッチ（推奨）

Google Cloud上のリソース（Compute Engine, Cloud Run, Cloud Functionsなど）にサービスアカウントを直接紐付ける方法です。
プラットフォーム側が自動的に認証トークンを管理・ローテーションしてくれるため、最も安全で楽な方法 です。

② 権限借用（Impersonation）（推奨・開発時）

ローカルPCで開発する際などに、開発者自身のGoogleアカウント権限を使って、一時的にサービスアカウントに「なりすます」方法です。
永続的なキーを発行する必要がないため、キー漏洩のリスクがありません。

# ローカルでサービスアカウントになりすましてコマンド実行
gcloud storage ls --impersonate-service-account=my-sa@project.iam.gserviceaccount.com

③ JSONキー（非推奨・最終手段）

サービスアカウントキー（JSONファイル）を発行し、環境変数 GOOGLE_APPLICATION_CREDENTIALS で読み込ませる方法です。
かつては一般的でしたが、ファイル管理が必要 であり、GitHubへの誤コミットなどで漏洩するリスクが常につきまといます。
現在では、オンプレミスなど「どうしても他の手段が取れない」場合を除き、利用は推奨されません。

3. Workload Identity 連携（重要）

「Google Cloudの外（GitHub Actions, AWS, CircleCIなど）」からアクセスする場合、かつてはJSONキーを使うのが定石でした。
しかし現在は Workload Identity 連携 がスタンダードです。

なぜ安全なのか？

キー（秘密鍵）を作成・保存する必要がないからです。
代わりに、外部のIDプロバイダ（GitHubなど）が発行するトークンをGoogle Cloud側で検証し、短期間だけ有効なアクセストークンを発行します。

もしまだJSONキーをGitHub Secretsに登録している場合は、早急にWorkload Identityへの移行を検討してください。

4. やってはいけない！危険なアンチパターン

❌ デフォルトのサービスアカウントを本番で利用する

プロジェクト作成時やAPI有効化時に自動作成される「Compute Engine Default Service Account」などには、編集者（Editor）という強力な権限が初期設定されていることが多いです。
これらが漏洩するとプロジェクト全体が危険に晒されます。必ず用途ごとに専用のSAを作成しましょう。

❌ JSONキーをGitにコミットする

これだけは絶対に避けてください。プライベートリポジトリであっても、コードの中に認証情報を含めるのはバッドプラクティスです。
万が一コミットしてしまった場合は、即座にキーを無効化（削除）し、ログから履歴を抹消する必要があります。

❌ 1つのSAを使い回す

「面倒だから」といって、Webサーバー用、バッチ用、CI/CD用の全ての権限を1つの「万能サービスアカウント」にまとめてはいけません。
万が一そのIDが侵害された場合の被害範囲（Blast Radius）を最小限にするため、役割ごとにアカウントを分割しましょう。

5. セキュアな運用のためのチェックリスト

最後に、サービスアカウントを安全に使うためのチェックリストをまとめました。

用途ごとに専用のSAを作成する: 「1アプリ = 1サービスアカウント」が理想。
最小権限の原則: 必要な権限のみを付与する（Editor等の基本ロールは避ける）。
キーレス運用: 可能な限りリソースへのアタッチやWorkload Identityを利用し、JSONキーを発行しない。
使用者の制限: iam.serviceAccountUser 権限を誰に与えるか厳密に管理する。
不要なキーの削除: 定期的に監査を行い、使われていないキーやSAを削除する。

まとめ

サービスアカウントは「機械のためのID」であり、モダンなアプリケーション開発には欠かせない存在です。
利便性が高い反面、セキュリティリスクの温床にもなりやすいため、「キーを持たせない（Keyless）」 運用を徹底することが、クラウドセキュリティ向上の近道です。

安易にキーを発行せず、Workload IdentityやImpersonationを活用して、堅牢なGoogle Cloud環境を構築しましょう。

※本記事の内容は執筆時点（2025年12月）の情報に基づきます。最新の仕様は公式ドキュメントをご確認ください。