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

背景

サービス アカウントは特別なタイプの Google アカウントで、Google API のデータにアクセスして認証を受ける必要がある人間以外のユーザーを表します。

通常、サービス アカウントは次のような場合に使用されます。

  • 仮想マシン(VM)でのワークロードの実行。
  • Google API を呼び出すオンプレミスのワークステーションまたはデータセンターでのワークロードの実行。
  • 1 人のユーザーのライフサイクルに結び付けられていないワークロードの実行。

アプリケーションは Google API の呼び出しにサービス アカウントの ID を使用するため、ユーザーは直接関与しません。

サービス アカウントの管理

サービス アカウントが必要になったときは、そのサービス アカウントをどのように使用するかを把握するために次の事項をご確認ください。

  • サービス アカウントでアクセス可能なリソース
  • サービス アカウントに必要な権限
  • サービス アカウントの ID を前提とするコードが実行される場所(Google Cloud Platform かオンプレミスか)

次のフローチャートを使って、上記の確認事項への答えを整理してください。

サービス アカウントのフローチャート

サービス アカウントは、リソースとしても ID としても扱うことができます。

サービス アカウントを ID として考える際は、プロジェクトなどのリソースにアクセスできるようにするために、サービス アカウントに役割を付与できます。

サービス アカウントをリソースとして考える際は、そのサービス アカウントに対するアクセスやアカウント管理を行うために、他のユーザーに役割を付与できます。

サービス アカウントへのアクセス権の付与

リソースにアクセスするためのアクセス権をサービス アカウントに付与する操作は、他の ID にアクセス権を付与する操作と同じです。たとえば、Google Compute Engine 上で実行するアプリケーションに対して、Google Cloud Storage 内でオブジェクトを作成するためのアクセス権のみを付与したい場合は、そのアプリケーションのサービス アカウントを作成し、そのサービス アカウントにストレージのオブジェクト作成者の役割を付与します。次の図は、この例を示しています。

サービス アカウントのフローチャート

詳細については、サービス アカウントへの役割の付与をご覧ください。

サービス アカウントに成り代わる

サービス アカウントに成り代わって Google API にアクセスする方法は 3 つあります。

  • RSA 秘密鍵を使用した認証
  • Cloud IAM ポリシーを使用した認証
  • GCP サービスでジョブをデプロイする

RSA 秘密鍵を使用した認証

すべてのサービス アカウントには、定期的にローテーションされる GCP が管理する鍵ペアがあり、秘密鍵はプラットフォームによってエスクローに保管され、直接アクセスすることはできません。

ユーザー管理の鍵ペアを手動で作成することも可能です。GCP は秘密鍵または公開鍵を生成し、公開鍵を保存し、ユーザーに秘密鍵を提供します。鍵ペアは、作成から 10 年で期限切れとなり、鍵ペアがサービス アカウントから削除されると Google に対して認証を行うことができなくなります。

Cloud IAM ポリシーを使用した認証

すべてのサービス アカウントには、サービス アカウントへのアクセス権を付与する Cloud IAM ポリシーがあります。ユーザーは一部の権限に応じて、そのユーザーの認証情報に基づいたサービス アカウントに成り代わることができます。

GCP でジョブをデプロイする

Compute Engine、App Engine、Cloud Functions などの一部の GCP サービスでは、サービス アカウントの ID として実行される VM またはファンクションのようなジョブをデプロイすることができます。

この方法でジョブをデプロイするには、目的のサービスに必要な権限がサービス アカウントに付与され、サービス アカウントに対する iam.serviceAccounts.actAs 権限がユーザー アカウントに付与されている必要があります。この権限は、サービス アカウント ユーザーの役割に含まれています。GCP サービスが、サービス アカウントの Cloud IAM の権限を維持することも必要ですが、通常は自動的に実施されます。

サービス アカウントで VM を実行する

たとえば、従業員が開始権限を持っている長期間継続するジョブがあり、ジョブを最後に開始した従業員が退社してもそのジョブが終了してしまうことがないようにするとします。

このようなときは、ジョブの開始と終了を行うためのサービス アカウントを作成すれば問題を解決できます。手順は次のとおりです。

  1. サービス アカウントを作成します

  2. ジョブを開始する権限が必要な従業員に、サービス アカウントのサービス アカウント ユーザー(roles/iam.serviceAccountUser)の役割を付与します。このシナリオでは、サービス アカウントはリソースとして扱われます。

  3. Compute インスタンス管理者(roles/compute.instanceAdmin.v1)役割を同じ従業員に付与します。

  4. 従業員は、そのサービス アカウントを実行する Compute Engine インスタンスを作成して接続し、サービス アカウントを使用してジョブを開始できます。次に例を示します。

    gcloud compute instances create my-instance --scopes=cloud-platform \
    --service-account=my-service-account@test9q.iam.gserviceaccount.com \
    --zone=us-central1-a
    

GCP へのデータの移行

別のクラウド プロバイダ上でなんらかのデータ処理を行い、処理されたデータを Google Cloud Platform に転送する必要があるケースを考えてみます。外部クラウド上の仮想マシンのサービス アカウントを使用して、データを Google Cloud Platform に push することができます。それには、サービス アカウントの作成時にサービス アカウント キーを作成およびダウンロードし、そのキーを外部プロセスから使用して Cloud Platform API を呼び出す必要があります。

サービス アカウントの管理

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

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

サービス アカウントの削除と再作成

サービス アカウントを削除した後に、同じ名前で新しいサービス アカウントを作成できます。削除したサービス アカウントの名前を再利用すると、予期しない動作が発生する可能性があります。

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

混乱を避けるため、一意のサービス アカウント名を使用することをおすすめします。それができない場合は、次の方法で新しいサービス アカウントに役割を付与できます。

  1. その役割を古いサービス アカウントに付与しているすべてのバインディングを明示的に削除します。
  2. その役割を新しいサービス アカウントに再度付与します。

役割バインディングは、再度追加する前に削除する必要があります。削除された古いサービス アカウントに役割が付与されていると、その役割を再度付与するだけでは自動的に失敗します。

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

このセクションでは、サービス アカウントに付与される権限、またはサービス アカウントに成り代わる権限があるユーザー アカウントの一般的なシナリオについて説明します。

サービス アカウントに最小限の権限を付与する

サービス アカウントには、そのサービス アカウントの目的を達成するために必要な最低限の権限セットのみ付与するようにします。詳細については、特定のリソースのサービス アカウントへの役割の付与をご覧ください。

サービス アカウントにアクセスするための権限をユーザーに付与する際には、そのサービス アカウントが権限を持つすべてのリソースにユーザーがアクセスできることを念頭に置く必要があります。そのため、サービス アカウントの権限の構成は慎重に行い、チームのどのユーザーがサービス アカウントとして操作できるのか、またはサービス アカウントに成り代わることができるのかを厳密に決める必要があります。

App Engine と Compute Engine のインスタンスを更新する Cloud IAM 役割を付与されたユーザー(App Engine のデプロイ担当者Compute インスタンス管理者など)は、実質的にこうしたインスタンスの実行に使用されるサービス アカウントとしてコードを実行できるため、こうしたサービス アカウントがアクセス権を持つすべてのリソースに間接的にアクセスできます。同様に、Compute Engine インスタンスに対する SSH アクセス権を与えると、そのインスタンスとしてコードを実行できるようになる可能性があります。

一般的なシナリオのサービス アカウント権限

サービス アカウントはさまざまなシナリオで使用でき、それぞれに特定の権限が必要です。このセクションでは、一般的なシナリオと必要な権限について説明します。

長時間実行ジョブの開始

権限:

  • iam.serviceAccounts.actAs

役割:

  • roles/editor(編集者)
  • roles/iam.serviceAccountUser(サービス アカウント ユーザー)

ユーザーまたはサービスは、サービス アカウントを長期間実行ジョブサービスにバインドできます。次にその例を紹介します。

  • Compute Engine VM
  • App Engine アプリ
  • Cloud Functions ファンクション
  • Cloud Dataflow ジョブ

このシナリオでは、サービスごとに異なるジョブをデプロイする権限と、サービス アカウントの iam.serviceAccounts.actAs を介して付与される、サービス アカウントに成り代わる権限の両方をユーザーに付与する必要があります。iam.serviceAccounts.actAs 権限を付与するだけでは、サービスアカウントに成り代わることはできません。

iam.serviceAccounts.actAs 権限がサービス アカウントに付与された後に、サービス アカウントとして実行される長期間実行ジョブを開始できます。ジョブが開始されると、ユーザーはサービス アカウントへのアクセスを保持する必要がなくなります。ユーザーがアクセス権を失っても、ジョブは実行されたままとなります。ジョブサービスは、引き続きサービス アカウントでの独自の権限を利用して、そのサービス アカウント ID でジョブを実行し続けます。

Compute Engine VM でインスタンス メタデータを設定するなど、長時間実行するジョブを変更するには、iam.serviceAccounts.actAs 権限が必要になる場合があります。

このフローの詳細については、Compute Engine ドキュメントのインスタンスのサービス アカウントの作成と有効化をご覧ください。

サービス アカウントに直接成り代わる

権限:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

役割:

  • roles/iam.serviceAccountTokenCreator(サービス アカウント トークン作成者)

必要な権限が付与されると、ユーザーまたはサービスは、いくつかの一般的なシナリオでサービス アカウントの ID を直接成り代わる(表明する)ことができます。

まずユーザーは、iam.serviceAccounts.getAccessToken 権限を使用して、generateAccessToken() メソッドを呼び出すことによって、サービス アカウントの短期認証情報を取得できます。短期認証情報を使用することによって、ユーザーは GCP にコマンドを発行し、そのサービス アカウントがアクセス権を持つすべてのリソースにアクセスできます。たとえば、このフローに従うと、ユーザーは gcloud --impersonate-service-account フラグを使用して、ダウンロードされた外部サービス アカウント キーを使用することなくサービス アカウントになりすますことができます。

次に、ユーザーは、iam.serviceAccounts.signBlob 権限を使用し、signBlob() または signJwt() メソッドを呼び出すことによって、サービス アカウントの Google が管理する秘密鍵で署名されたアーティファクトを取得できます。Google が管理する秘密鍵は常にエスクローに保管され、直接公開されることはありません。signBlob() は、任意のペイロード(Cloud Storage で署名された URL など)の署名を許可しますが、signJwt() は正しい形式の JWT の署名のみを許可します。

最後に、ユーザーはサービス アカウントの認証情報を取得することなく、サービス アカウントを代理操作や表明をすることができます。これは高度な使用例であり、generateAccessToken() メソッドを使用したプログラムによるアクセスでのみサポートされています。少なくとも A、B、C の 3 つのサービス アカウントがあるシナリオでは、サービス アカウント A は、サービス アカウント A が B に対する iam.serviceAccounts.implicitDelegation 権限を付与されている場合にサービス アカウント C のアクセス トークンを取得することができ、B は C に対して iam.serviceAccounts.getAccessToken 権限が付与されます。

OpenID Connect(OIDC)ID トークンの生成

権限:

  • iam.serviceAccounts.getOpenIdToken

役割:

  • roles/iam.serviceAccountTokenCreator(サービス アカウント トークン作成者)

ユーザーまたはサービスは、iam.serviceAccounts.getOpenIdToken 権限を使用してサービス アカウントの ID を表す Google OIDC プロバイダ(accounts.google.com)によって署名された OpenID Connect(OIDC)と互換性のある JWT トークンを生成できます。

これらのトークンは、あなたの組織が Google へのアクセスを許可するために追加の ID 連携をデプロイしないと、ほとんどの Google API に直接受け入れられることはありません。ユーザー実行アプリケーションへの OIDC ベースのアクセスを許可する Cloud Identity-Aware Proxy などのような例外もいくつかあります。

外部秘密鍵の生成

権限:

  • iam.serviceAccountKeys.create

役割:

  • roles/editor(編集者)
  • roles/iam.serviceAccountAdmin(サービス アカウント管理者)

ユーザーまたはサービスは、サービス アカウントとして Google に直接認証する場合に使用できる外部秘密鍵マテリアル(RSA)を生成できます。この鍵マテリアルは、アプリケーションのデフォルト認証情報(ADC)ライブラリまたは gcloud auth activate-service-account コマンドで使用できます。鍵のマテリアルにアクセスできる人は、サービス アカウントが完全アクセス権を持つすべてのリソースに制限なくアクセスできます。そのような秘密鍵のマテリアルは最も注意して扱われるべきであり、マテリアルの存在が長いほど安全性が低くなると想定されます。したがって、秘密鍵のマテリアルをローテーションすることは、強固なセキュリティを維持するためには不可欠です。

サービス アカウント キーの管理

サービス アカウント キーには次の 2 種類があります。

  • GCP が管理するキー。これらのキーは、App Engine や Compute Engine などの Cloud Platform サービスによって使用されます。これらをダウンロードすることはできません。また、これらのキーは自動的にローテーションされ、最長 2 週間署名のために使用されます。ローテーション プロセスは確率論的です。新しいキーの使用期間はキーの存続期間に応じて多少増減します。現在のキーセットに常にアクセスできるように、サービス アカウントの公開鍵セットのキャッシュ保存は、最長 24 時間に設定することをおすすめします。

  • ユーザーが管理するキー。これらのキーは、ユーザーによって作成、ダウンロード、管理されます。作成から 10 年間で期限が切れ、サービス アカウントから削除されると認証を停止します。

ユーザーが管理するキーの場合は、以下のようなキー管理要件に対応するプロセスが用意されていることを確認する必要があります。

  • キーの保管
  • キーの配布
  • キーの取り消し
  • キーのローテーション
  • 不正ユーザーからのキーの保護
  • キーの復旧

サービス アカウントの有効な秘密鍵にアクセスできるユーザーは、サービス アカウントを介してリソースにアクセスできます。サービス アカウントに対するキーのアクセスのライフサイクル、つまりサービス アカウントがアクセスできるデータは、ダウンロードしたユーザーのライフサイクルとは無関係です。

デベロッパーがキーをソースコードに組み込んだり、ワークステーションのダウンロード ディレクトリに置いたままにしたりしないように指示してください。

キーのセキュリティを強化するため、次のガイダンスを遵守してください。

  • IAM Service Account API を使用して、サービス アカウント キーを自動的にローテーションします。キーをローテーションするには、新しいキーを作成し、アプリケーションでその新しいキーを使用するよう切り替えた後、古いキーを削除します。serviceAccount.keys.create() メソッドと serviceAccount.keys.delete() メソッドを組み合わせて使用すると、ローテーションを自動化できます。GCP が管理するキーは、ほぼ毎週ローテーションされます。

Compute Engine でのサービス アカウントの使用

Compute Engine のインスタンスがその他の Cloud Platform のリソースにアクセスするには、同インスタンスをサービス アカウントとして実行する必要があります。Compute Engine のインスタンスを保護するため、次の対応策を講じることをご検討ください。

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

  • サービス アカウントに IAM の役割を付与することで、サービス アカウントでアクセスできるリソースを明確にします。これにより、多くのケースでスコープに依存する必要がなくなり、インスタンスを作成し直さなくても VM のサービス アカウントの権限を変更できるようになります。

  • インスタンスの Cloud Platform リソースへのアクセス権はサービス アカウントによって決まるため、実行中のインスタンスで使用されているサービス アカウントは削除しないようにしてください。サービス アカウントを削除すると、インスタンスのオペレーションが失敗する場合があります。

おすすめの方法

  • サービス アカウントとして活動できるユーザーの数を制限します。サービス アカウントのサービス アカウント ユーザーであるユーザーは、そのサービス アカウントからアクセスできるすべてのリソースにアクセスできるようになります。そのため、serviceAccountUser の役割をユーザーに付与する際は十分な注意が必要です。

  • サービス アカウントには、そのサービス アカウントの目的を達成するために必要な最低限の権限セットのみ付与するようにします。詳細については、特定のリソースのサービス アカウントへの役割の付与をご覧ください。

  • それぞれのサービス向けに、そのサービスで必要な権限のみを持つサービス アカウントを作成してください。

  • サービス アカウントの表示名を使ってサービス アカウントを管理してください。サービス アカウントの作成時に、そのサービス アカウントの使用目的がわかる表示名を入力します。

  • サービス アカウントの命名規則を定義してください。

  • ユーザー管理のサービス アカウント キーのローテーションを自動化するプロセスを実装します。

  • IAM Service Account API を使用して、キーのローテーションを実装します。

  • serviceAccount.keys.list() メソッドまたはコンソールのログビューア ページを使用してサービス アカウントとキーを監査します。

  • アプリケーションがサービス アカウントにアクセスできないようにする場合を除いて、App Engine または Compute Engine で実行中のインスタンスによって使用されているサービス アカウントは削除しないでください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud IAM のドキュメント