サービス アカウントの概要

このページでは、サービス アカウントの概要と、ライフサイクルの各段階でサービス アカウントを管理する際の重要な考慮事項について説明します。

サービス アカウントとは

サービス アカウントは、ユーザーではなく、アプリケーションや Compute Engine インスタンスなどのコンピューティング ワークロードで通常使用される特別なアカウントです。サービス アカウントは、アカウント固有のメールアドレスで識別されます。

アプリケーションはサービス アカウントを使用して、認可された API 呼び出しを行います。これは、サービス アカウント自体として認証されるか、ドメイン全体の委任により Google Workspace または Cloud Identity ユーザーとして認証されます。アプリケーションがサービス アカウントとして認証されると、アプリケーションはサービス アカウントにアクセス権が付与されているすべてのリソースにアクセスできます。

アプリケーションをサービス アカウントとして認証する最も一般的な方法は、アプリケーションを実行しているリソースにサービス アカウントを関連付けることです。たとえば、サービス アカウントを Compute Engine インスタンスに関連付けると、そのインスタンスで実行されているアプリケーションがサービス アカウントとして認証されるようにできます。その後、サービス アカウントに IAM ロールを付与すると、サービス アカウントは（さらにはインスタンス上の）アプリケーションが Google Cloud リソースにアクセスできるようになります。

サービス アカウントを関連付ける以外にも、アプリケーションをサービス アカウントとして認証させる方法があります。たとえば、Workload Identity 連携を設定して、外部ワークロードがサービス アカウントとして認証されるようにしたり、サービス アカウント キーを作成して、任意の環境でこれを使用して、OAuth 2.0 アクセス トークンを取得できます。

注意: サービス アカウント キーが正しく管理されていない場合は、セキュリティ リスクが発生します。可能であれば、サービス アカウント キーよりも安全な代替手段を選択してください。サービス アカウント キーで認証する必要がある場合は、秘密鍵のセキュリティと、サービス アカウント キーを管理するためのベスト プラクティスで説明されているその他の操作は、ユーザーの責任で実施してください。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。

アプリケーションのサービス アカウント認証の詳細については、ワークロードの ID の概要をご覧ください。

ユーザーや他のサービス アカウントなどのプリンシパルをサービス アカウントとして認証することもできます。詳細については、このページのサービス アカウントの権限借用をご覧ください。

サービス アカウントのタイプ

Google Cloud には、いくつかの異なるタイプのサービス アカウントがあります。

• ユーザー管理のサービス アカウント: ユーザーが作成して管理するサービス アカウント。多くの場合、これらのサービス アカウントはワークロードの ID として使用されます。

• デフォルトのサービス アカウント: 特定の Google Cloud サービスを有効にするときに自動的に作成される、ユーザー管理のサービス アカウント。これらのサービス アカウントは、ユーザーの責任で管理する必要があります。

• サービス エージェント: Google Cloud によって作成および管理され、サービスがユーザーに代わってリソースにアクセスできるようにするサービス アカウント。

それぞれのタイプのサービス アカウントの詳細については、サービス アカウントのタイプをご覧ください。

サービス アカウント認証情報

アプリケーションとプリンシパルは、次のいずれかの方法でサービス アカウントとして認証されます。

• 有効期間の短い認証情報を取得する多くの場合、gcloud CLI の --impersonate-service-account フラグで関連付けられたサービス アカウントとコマンドでは、認証情報が自動的に取得されるため、これらをユーザー自身で作成または管理する必要はありません。
• サービス アカウント キーを使用して JSON Web Token（JWT）に署名し、アクセス トークンと交換します。サービス アカウント キーを正しく管理しないと、セキュリティ上のリスクが生じるため、可能な限りサービス アカウント キーよりも安全な代替手段を選択する必要があります。

サービス アカウント認証の詳細については、サービス アカウントの認証情報をご覧ください。

サービス アカウントの権限借用

認証されたプリンシパル（ユーザーやサービス アカウントなど）がサービス アカウントとして認証され、サービス アカウントの権限が取得される場合、これはサービス アカウントの権限借用と呼ばれます。サービス アカウントの権限を借用すると、認証されたプリンシパルは、そのサービス アカウントが許可されているすべてのものにアクセスできます。サービス アカウントの権限を借用できるのは、適切な権限を持つ認証済みのプリンシパルのみです。

権限借用は、Identity and Access Management（IAM）ポリシーを変更せずにユーザーの権限を変更する場合に便利です。たとえば、権限借用を使用して、一時的に昇格されたアクセス権をユーザーに付与したり、特定の権限セットがタスクに十分かどうかをテストできます。また、権限借用を使用して、サービス アカウントとしてのみ実行できるアプリケーションをローカルで開発したり、Google Cloud の外部で実行されるアプリケーションを認証することもできます。

サービス アカウントの権限借用の詳細については、サービス アカウントの権限借用をご覧ください。

サービス アカウントと Google Workspace ドメイン

ユーザー アカウントとは異なり、サービス アカウントは Google Workspace ドメインに属していません。ドキュメントやイベントなどの Google Workspace アセットを Google Workspace ドメイン全体で共有しても、サービス アカウントとは共有されません。同様に、サービス アカウントによって作成された Google Workspace アセットは、Google Workspace ドメインには作成されません。そのため、Google Workspace と Cloud Identity 管理者はこれらのアセットを所有することも、管理することもできません。

注: ドメイン全体の委任を使用して作成された Google Workspace アセットは、Google Workspace ドメインに作成されます。API 呼び出しは、サービス アカウント自体ではなく、権限を借用したユーザーとして認可されるためです。

サービス アカウントの権限

サービス アカウントはプリンシパルです。これにより、サービス アカウントに Google Cloud リソースへのアクセス権を付与できます。たとえば、サービス アカウントに、プロジェクトに対する Compute 管理者のロール（roles/compute.admin）を付与できます。これにより、サービス アカウントはそのプロジェクト内の Compute Engine リソースを管理できるようになります。

ただし、サービス アカウントはリソースでもあります。つまり、サービス アカウントにアクセスする権限を他のプリンシパルに付与できます。たとえば、サービス アカウントに対するサービス アカウント ユーザーロール（roles/iam.serviceAccountUser）をユーザーに付与して、そのサービス アカウントをリソースにアタッチする許可をユーザーに与えることができます。また、ユーザーにサービス アカウント管理者のロール（roles/iam.serviceAccountAdmin）を付与して、サービス アカウントの表示、編集、無効化、削除などを行う許可をユーザーに与えることもできます。

以降のセクションでは、サービス アカウントをプリンシパルまたはリソースとして管理する方法について説明します。

プリンシパルとしてのサービス アカウント

サービス アカウントはプリンシパルであるため、他のプリンシパルと同様に、ロールを付与することでプロジェクト内のリソースにアクセスできます。たとえば、アプリケーションのサービス アカウントに Cloud Storage バケット内のオブジェクトへのアクセスを許可する場合は、サービス アカウントにバケットに対するストレージ オブジェクト閲覧者のロール（roles/storage.objectViewer）を付与できます。

他のタイプのプリンシパルと同様に、サービス アカウントには、そのサービス アカウントの目的を達成するために必要な最低限の権限セットのみ付与するようにします。

他のプリンシパルと同様に、Google グループにサービス アカウントを追加して、グループにロールを付与できます。ただし、サービス アカウントをグループに追加することはおすすめしません。サービス アカウントはアプリケーションによって使用され、各アプリケーションが独自のアクセス要件を持つ可能性があります。

サービス アカウントを含むプリンシパルにロールを付与する方法については、プロジェクト、フォルダ、組織へのアクセス権を管理するをご覧ください。

注: デフォルトの Compute Engine と App Engine のサービス アカウントには、作成時にプロジェクトに対する編集者ロール（roles/editor）が付与されます。セキュリティを向上させるため、デフォルトのサービス アカウントのロールの自動付与を無効にすることで、この動作を無効にすることを強くおすすめします。詳細については、デフォルトのサービス アカウントをご覧ください。

リソースとしてのサービス アカウント

また、サービス アカウントは独自の許可ポリシーを持つことが可能なリソースです。つまり、サービス アカウントまたはサービス アカウントの親リソースの 1 つに対するロールを他のプリンシパルに付与することで、そのプリンシパルがサービス アカウントにアクセスできるようになります。たとえば、ユーザーにサービス アカウントの権限借用を許可するには、そのサービス アカウントに対するサービス アカウント トークン作成者ロール（roles/iam.serviceAccountTokenCreator）を付与します。

ユーザーにサービス アカウントの権限借用を許可するためにロールを付与すると、ユーザーはそのサービス アカウントがアクセスできるすべてのリソースにアクセスできるようになります。Compute Engine と App Engine のデフォルト サービス アカウントなど、高度な権限を付与されたサービス アカウントの権限借用をユーザーに許可する場合は注意してください。

プリンシパルに付与できるサービス アカウントのロールの詳細については、サービス アカウントの権限をご覧ください。

プリンシパルにサービス アカウントのロールを付与する方法については、サービス アカウントに対するアクセス権を管理するをご覧ください。

サービス アカウントのライフサイクル

プロジェクトを管理する際に、さまざまなサービス アカウントの作成、管理、削除を行います。このセクションでは、ライフサイクルのさまざまな段階でサービス アカウントを管理する際の主な考慮事項について説明します。

サービス アカウントの作成場所

各サービス アカウントはプロジェクト内にあります。サービス アカウントは、作成後、別のプロジェクトに移動することはできません。

サービス アカウントをプロジェクトにまとめるには、いくつかの方法があります。

• 同じプロジェクトにサービス アカウントとリソースを作成する。

  この手法を使用すると、サービス アカウントを簡単に使い始めることができます。ただし、多数のプロジェクトにまたがるサービス アカウントを追跡するのは困難な場合があります。

• サービス アカウントを別々のプロジェクトで一元管理する。

  このアプローチでは、組織のすべてのサービス アカウントを少数のプロジェクトに分けて割り当てるため、サービス アカウントを管理しやすくします。ただし、他のプロジェクト内のリソースにサービス アカウントを接続して、プロジェクトが異なるこれらのリソースでサービス アカウントを ID として使用できようにする場合、追加の設定作業が必要になります。

  あるプロジェクト内にあるサービス アカウントが別のプロジェクトのリソースにアクセスする場合、通常は両方のプロジェクトでそのリソースの API を有効にする必要があります。たとえば、サービス アカウントがプロジェクト my-service-accounts 内にあり、Cloud SQL インスタンスがプロジェクト my-application 内にある場合、my-service-accounts と my-application の両方で Cloud SQL API を有効にする必要があります。

  デフォルトでは、プロジェクト内に最大 100 個のサービス アカウントを作成できます。追加のサービス アカウントを作成する必要がある場合は、割り当ての増加をリクエストします。

サービス アカウントの作成方法については、サービス アカウントを作成するをご覧ください。

サービス アカウントの作成を防止する

サービス アカウントの作成場所をより適切に制御するには、組織内の一部のプロジェクトでサービス アカウントの作成を禁止することをおすすめします。

組織、プロジェクト、またはフォルダで constraints/iam.disableServiceAccountCreation 組織ポリシー制約を適用することで、サービス アカウントの作成を防止できます。

この制約を適用する前に、次の制限事項について検討してください。

• この制約をプロジェクトまたは組織内のすべてのプロジェクトで適用すると、一部の Google Cloud サービスはデフォルトのサービス アカウントを作成できなくなります。そのため、プロジェクトでサービス アカウントとしての認証が必要なワークロードを実行すると、ワークロードが使用できるサービス アカウントがプロジェクトに含まれない場合があります。

  この問題を解決するには、プロジェクト間でサービス アカウントの権限借用を有効にします。この機能を有効にすると、一元化されたプロジェクトでサービス アカウントを作成し、他のプロジェクトのリソースにサービス アカウントを接続できます。これらのリソースで実行されるワークロードは、関連付けられたサービス アカウントを使用して認証できるため、デフォルトのサービス アカウントは不要です。

• Workload Identity 連携などの一部の機能では、サービス アカウントを作成する必要があります。

  Workload Identity 連携を使用しない場合は、組織のポリシー制約を使用して、すべての ID プロバイダで連携をブロックすることを検討してください。

サービス アカウントを追跡する

時間の経過とともに、作成したサービス アカウントの数が増えてくると、どのサービス アカウントがどのような目的に使われているかの区別が難しくなることがあります。

サービス アカウントの表示名は、サービス アカウントの目的や担当者など、そのサービス アカウントに関する追加情報を管理するために利用できます。新しいサービス アカウントの場合は、サービス アカウントの作成時に表示名を入力できます。既存のサービス アカウントの場合は、serviceAccounts.update() メソッドを使用して表示名を変更します。

Compute Engine でサービス アカウントを使用する

Compute Engine のインスタンスがその他の Google Cloud のリソースにアクセスするには、同インスタンスをサービス アカウントとして実行する必要があります。Compute Engine インスタンスを保護するには、次の点を考慮してください。

• 同じプロジェクトの複数のインスタンスをそれぞれ異なるサービス アカウントで作成します。作成後にインスタンスのサービス アカウントを変更するには、instances.setServiceAccount メソッドを使用します。

• 関連付けられたサービス アカウントの認証を設定するには、IAM ロールの構成だけでなく、アクセス スコープの構成も必要になります。

• インスタンスの Google Cloud リソースへのアクセス権はサービス アカウントによって決まるため、実行中のインスタンスで使用されているサービス アカウントは削除しないようにしてください。

Compute Engine でサービス アカウントを使用する方法については、Compute Engine ドキュメントのサービス アカウントをご覧ください。

未使用のサービス アカウントを特定する

不要になったサービス アカウントがプロジェクトにしばらく存在していることがあります。

未使用のサービス アカウントは不要なセキュリティ リスクをもたらすため、未使用のサービス アカウントを無効にすることをおすすめします。また、サービス アカウントが不要になった場合は、そのサービス アカウントを削除するようにしてください。未使用のサービス アカウントは次の方法で識別できます。

• サービス アカウントの分析情報。プロジェクトで過去 90 日間に認証されていないサービス アカウントを確認できます。
• Activity Analyzer を使用すると、サービス アカウントまたはキーが最後に使用された日時を確認できます。

また、サービス アカウントの使用状況の指標を使用して、サービス アカウントとキーの全般的な使用状況を追跡することもできます。

Security Command Center Premium のお客様は、Event Threat Detection を使用して、休止状態のサービス アカウントがアクションをトリガーしたときに通知を受け取ることができます。休止状態のサービス アカウントとは、180 日以上アクティブでないサービス アカウントのことです。サービス アカウントが使用されると休止状態でなくなります。

サービス アカウントを削除する

サービス アカウントを削除する前に、サービス アカウントを無効にする必要があります。無効になっているサービス アカウントがまだ使用中の場合は、再度有効にできます。

サービス アカウントが必要でないことを確認したら、サービス アカウントを削除できます。

削除されたサービス アカウントを再作成する

サービス アカウントを削除した後に、同じ名前で新しいサービス アカウントを作成できます。

サービス アカウントを削除しても、そのアカウントのロール バインディングがすぐに削除されるわけではありません。代わりに、ロール バインディングはサービス アカウントの先頭に deleted: という接頭辞を付けます。例については、削除されたプリンシパルを含むポリシーをご覧ください。

最近削除されたサービス アカウントと同じ名前で新しいサービス アカウントを作成した場合、古いバインディングが削除されていない可能性があります。ただし、両方のアカウントのメールアドレスが同じでも、新しいサービス アカウントに古いバインディングは適用されません。この現象は、作成時にサービス アカウントに Identity and Access Management（IAM）内で一意の ID が付与されるために発生します。内部的には、すべてのロール バインディングはサービス アカウントのメールアドレスではなく、これらの ID を使用して付与されます。したがって、削除されたサービス アカウントのロール バインディングは、同じメールアドレスを使用する新しいサービス アカウントには適用されません。

同様に、リソースに対するサービス アカウントの関連付けを行ってからそのサービス アカウントを削除し、同じ名前で新しいサービス アカウントを作成した場合、新しいサービス アカウントはリソースに関連付けられません。

予期しない動作を回避するには、サービス アカウントごとに新しい一意の名前を使用します。サービス アカウントを誤って削除した場合は、新しいサービス アカウントを作成せずにサービス アカウントの削除を取り消すこともできます。

元のサービス アカウントの削除を取り消すことができないときに、同じ名前とロールで新しいサービス アカウントを作成する必要がある場合は、そのロールを新しいサービス アカウントに付与する必要があります。詳細については、削除されたプリンシパルを含むポリシーをご覧ください。

新しいサービス アカウントを元のサービス アカウントと同じリソースに関連付ける必要がある場合は、次のいずれかを行います。

• Compute Engine インスタンスについては、インスタンスに関連付けられているサービス アカウントを変更して、元のサービス アカウントを新しいサービス アカウントに置き換えられます。
• その他のリソースについては、既存のリソースを削除してから、同じタイプの新しいリソースを作成して、新しいサービス アカウントを関連付ける必要があります。

次のステップ

• サービス アカウントの作成方法を学習する。
• サービス アカウントを操作するためのベスト プラクティスについて確認する
• サービス アカウント キーを管理するためのベスト プラクティスについて確認する。

使ってみる

Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

無料で開始