サービスアカウントキーは、アプリケーションや自動処理が人の代わりにクラウド資源へアクセスするときに使う、秘密の認証情報です。特に Google Cloud では、サービスアカウントという「ユーザーではない主体」を識別し、その主体として API にアクセスさせるために使われます。扱い方を誤ると権限の乗っ取りにつながるため、便利さと同じくらい管理の厳しさが重要になります。
キーの中身と役割
サービスアカウントキーは、一般には JSON 形式の秘密鍵ファイル として配布されます。中にはサービスアカウントの識別情報、秘密鍵、認証に必要な各種メタデータが入っています。これを使ってプログラムは「自分はこのサービスアカウントです」と証明し、Google Cloud の API や IAM 管理下の資源にアクセスします。
認証の流れは、ざっくり言うと次のようになります。
1. プログラムがキーを読み込む2. 署名付きのトークンを作る3. 認証サーバーがそのトークンを検証する4. 付与された権限の範囲で API を呼び出す
つまりキーそのものが「権限」ではなく、権限を証明するための材料 です。実際に何ができるかは、サービスアカウントに割り当てられた IAM ロールで決まります。
JSON キーの扱い方
Google Cloud のサービスアカウントキーは、一般にダウンロードした JSON ファイルとして保存されます。開発環境では環境変数や設定ファイルから読み込ませることが多く、ライブラリが自動的に認証情報として利用します。
from google.cloud import storage
client = storage.Client.from_service_account_json(
"service-account-key.json"
)
for bucket in client.list_buckets():
print(bucket.name)このようなコードでは、`service-account-key.json` を使って API クライアントを作成しています。実務では、ファイル名をソースコードに直書きするより、環境変数やシークレット管理機能でパスを渡すほうが安全です。リポジトリに誤ってコミットすると、第三者にそのまま使われる危険があります。
権限はキーではなく IAM で決まる
サービスアカウントキーを理解するときに大事なのは、キーを持っているだけで何でもできるわけではない という点です。Google Cloud では、サービスアカウントに IAM ロールを付与し、そのロールがアクセス可能な範囲を定めます。キーはそのサービスアカウントとしてログインするための手段であり、ロールが実際の権限境界になります。
たとえば、同じキーを使っていても、読み取り専用ロールしか付いていなければ、オブジェクト削除や設定変更はできません。逆に、広いロールを付けていると、漏えい時の被害が大きくなります。したがって、運用では最小権限を基本に設計します。
長期キーと一時認証の考え方
サービスアカウントキーの特徴は、基本的に長期利用できる秘密情報であることです。ここが便利な反面、リスクの中心にもなります。漏えいした場合、失効しない限り攻撃者が継続的に使えてしまうため、鍵の保管、配布、更新、失効の管理が必要です。
このため、最近のクラウド運用では、可能なら長期キーを減らし、より短命な認証方式を使う設計が好まれます。たとえば、実行環境側のワークロードID連携や、OAuth 2.0 系の短期トークンを使う構成です。とはいえ、ローカル開発や外部システム連携など、どうしてもキーが必要な場面は残ります。その場合は用途を限定し、保管場所を厳重に分けます。
作成・保管・失効の運用
サービスアカウントキーは「作って終わり」の情報ではありません。実務では、次のような運用ルールが重要です。
- 必要最小限の数だけ発行する
- 人が読める場所や Git リポジトリに置かない
- 共有サーバーではアクセス権を絞る
- 定期的に棚卸しして不要なキーを削除する
- 漏えいの疑いがあればすぐに失効する
特に、古いキーが残り続ける状態は危険です。アプリケーション側が別のキーへ切り替わったあとも、過去の鍵が有効なままだと、攻撃面が増えます。運用では、発行日・用途・所有者・失効予定日を記録しておくと管理しやすくなります。
OAuth 2.0 やユーザー認証との違い
サービスアカウントキーは、ユーザー本人のログインを表すものではありません。あくまで機械対機械の認証で、個人の同意画面を経る OAuth 2.0 の利用とは役割が異なります。
| 項目 | サービスアカウントキー | OAuth 2.0 のユーザー認証 |
|---|---|---|
| 主体 | アプリケーション | 人間のユーザー |
| 目的 | 自動処理・バックエンド連携 | ユーザーの操作を伴う連携 |
| 形 | 秘密鍵を含む JSON など | アクセストークン / リフレッシュトークン |
| 管理 | 鍵の保管と失効が重要 | 同意・スコープ・セッション管理が重要 |
この違いを取り違えると、設計が不自然になります。たとえば、ユーザー本人の操作を必要とする機能なのにサービスアカウントで代用すると、監査や権限分離が難しくなることがあります。
つまずきやすい点
サービスアカウントキーでよくあるつまずきは、認証と認可を混同することです。キーが正しくても、IAM ロールが不足していれば API は失敗します。また、キーが正しいのにアクセスできない場合、対象プロジェクトの設定違い、API の有効化忘れ、組織ポリシー制限などが原因になることがあります。
もう一つの注意点は、キーを「環境変数に入れているから安全」と思い込むことです。環境変数はソースコードよりはましでも、ログ、ダンプ、設定表示、CI/CD の出力などを通じて漏れる可能性があります。安全性は保管場所だけでなく、周辺の運用まで含めて考える必要があります。
サービスアカウントキーは、自動化やクラウド連携を支える重要な道具ですが、同時に漏えい時の影響が大きい情報です。便利さを優先して広く配るのではなく、権限を絞り、保管を厳格にし、不要になったらすぐ失効させる、という基本が最も重要です。
