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

他のプリンシパルと同様に、サービス アカウントは Google に対して自身の認証を行い、OAuth 2.0 アクセス トークンを取得して、Google API を呼び出すことができます。ただし、このプロセスはユーザー アカウントとサービス アカウントで動作が異なります。

サービス アカウントは、次のいずれかの方法で認証を行います。

有効期間の短いサービス アカウント認証情報

サービス アカウントとして認証する最も安全な方法は、OAuth 2.0 アクセス トークンの形式でサービス アカウントに対して有効期間の短い認証情報を取得することです。デフォルトでは、これらのトークンは 1 時間で期限切れになります。

有効期間の短いサービス アカウント認証情報は、信頼できるサービス アカウントに対してリソースへのアクセスを制限する必要がある場合に便利です。また、サービス アカウント キーなど、長期間有効な認証情報よりもリスクが低くなります。

多くの場合、これらの認証情報は自動的に取得されるため、ご自身で作成または管理する必要はありません。次に例を示します。

  • Google Cloud CLI コマンドを実行する際に --impersonate-service-account フラグを指定すると、gcloud CLI はサービス アカウントに有効期間の短い認証情報を作成して、これらの認証情報を使用してコマンドを実行します。

  • Compute Engine 仮想マシン（VM）インスタンスにサービス アカウントを接続すると、そのインスタンスのワークロードは Cloud クライアント ライブラリを使用して Google Cloud サービスにアクセスできます。Cloud クライアント ライブラリは、アプリケーションのデフォルト認証情報（ADC）を使用して、サービス アカウントに有効期間の短い認証情報を取得します。

    このプロセスの詳細については、サービス アカウントの認証情報を使用したアプリケーションの認証をご覧ください。

  • Workload Identity 連携を構成した場合、Cloud クライアント ライブラリは ID プロバイダの認証情報を使用して、有効期間の短いサービス アカウントの認証情報を生成できます。

また、Service Account Credentials API を使用して、有効期間の短い認証情報を手動で作成することもできます。たとえば、有効期間の短いサービス アカウント認証情報をユーザーに提供するサービスを作成して、Google Cloud リソースに一時的にアクセスできるようにします。

Service Account Credentials API では、次のタイプの認証情報を作成できます。

  • OAuth 2.0 アクセス トークン
  • OpenID Connect（OIDC）ID トークン
  • 自己署名 JSON ウェブトークン（JWT）
  • 自己署名バイナリ blob

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

監査ログの解釈

Cloud Audit Logs を使用すると、Google Cloud リソースに対して「いつ誰がどこで何をしたか」を調べることができます。

有効期間の短い認証情報を使用してサービス アカウントの権限を借用すると、ほとんどの Google Cloud サービスのログエントリには次の ID が表示されます。

  • 有効期間の短い認証情報が権限を借用するサービス アカウント
  • 有効期間の短い認証情報を作成した ID

これらのログエントリを使用して、有効期間が短い認証情報を作成したプリンシパルと、プリンシパルが権限を借用したサービス アカウントを特定できます。

サービス アカウントの権限借用を示す監査ログエントリの例については、サービス アカウントの権限を借用して Google Cloud にアクセスするをご覧ください。

自己権限借用

自己権限借用とは、サービス アカウント独自の認証情報を使用して、サービス アカウントの新しい認証情報を生成することです。

Service Account Credentials API では、次の種類の自己権限借用が禁止されています。

Google Cloud では、この種類の自己権限借用が有効な場合、悪意のある人物が盗まれたトークンを無期限に更新できるため、この自己権限借用を禁止しています。

禁止された方法で自己権限借用を使用しようとすると、次のエラーが発生することがあります。

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

このエラーが発生した場合は、別の認証情報を使用してサービス アカウントに新しい有効期間の短い認証情報を生成してください（エンドユーザー認証情報や別のサービス アカウントの認証情報など）。

サービス アカウント キー

各サービス アカウントは、公開 / 秘密 RSA 鍵ペアに関連付けられています。Service Account Credentials API は、この内部鍵ペアを使用して有効期間が短いサービス アカウント認証情報を作成し、blob と JSON ウェブトークン（JWT）に署名します。この鍵ペアは Google が管理する鍵ペアと呼ばれます。

また、複数の 公開 / 秘密 RSA 鍵ペア（ユーザーが管理する鍵ペア）を作成し、秘密鍵を使用して Google API で認証することもできます。この秘密鍵はサービス アカウント キーと呼ばれています。

Google が管理する鍵ペア

Google が管理する鍵ペアは、Service Account Credentials API や、Google Cloud サービス（App Engine や Compute Engine など）によって使用され、有効期間が短いサービス アカウント認証情報を生成します。

署名に使用されている Google 管理の鍵は、セキュリティのベスト プラクティスに従って定期的にローテーションされます。ローテーション プロセスは確率論的です。新しい鍵の使用期間は鍵の存続期間に応じて多少増減します。

Google が管理する鍵ペアの秘密鍵は常にエスクローに保管され、直接アクセスすることはできません。

Google が管理する鍵ペアの公開鍵は一般公開されているため、秘密鍵を使用して作成された署名は誰でも確認できます。公開鍵には、さまざまな形式でアクセスできます。

  • X.509 証明書: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • JSON Web Key（JWK）: https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • RAW 形式: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

公開鍵をダウンロードしてキャッシュに保存する場合は、常に現在の鍵を保持できるように最長 24 時間キャッシュに保存することをおすすめします。公開鍵を取得するタイミングに関係なく、取得した公開鍵は少なくとも 24 時間有効です。

ユーザーが管理する鍵ペア

サービス アカウントのユーザー管理鍵ペアを作成し、各鍵ペアの秘密鍵を使用して Google API で認証できます。この秘密鍵はサービス アカウント キーと呼ばれています。

Cloud クライアント ライブラリは、サービス アカウント キーを使用して OAuth 2.0 アクセス トークンを自動的に取得できます。また、サービス アカウント キーを使用して JWT に手動で署名し、署名された JWT を使用してアクセス トークンをリクエストすることもできます。詳しくは、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。

各サービス アカウントには、最大 10 個のサービス アカウント キーを設定できます。Google では、ユーザーが管理する鍵ペアの公開部分のみを格納します。

サービス アカウントでユーザーが管理する鍵ペアを作成するには、いくつかの方法があります。

ユーザーが管理する鍵は非常に強力な認証情報です。ユーザーが管理する鍵の使用を制限するには、次の組織ポリシー制約を組織、プロジェクト、またはフォルダに適用します。

  • constraints/iam.disableServiceAccountKeyCreation: プリンシパルがユーザー管理のサービス アカウント キーを作成できないようにします。
  • constraints/iam.disableServiceAccountKeyUpload: プリンシパルがサービス アカウントの公開鍵をアップロードできないようにします。

Workload Identity 連携を使用するために、これらの制約を適用する場合は、Workload Identity 連携に関する組織ポリシー制約を使用して許可する ID プロバイダを指定することを検討してください。

ユーザーが管理する鍵の有効期限

デフォルトでは、ユーザー管理のサービス アカウント キーを作成するときに、鍵の有効期限は設定されません。このデフォルトを変更するには、プロジェクト、フォルダまたは組織で新たに作成したすべての鍵に有効期限を設定します。有効期限は、新しく作成された鍵が何時間有効であるかを示します。

サービス アカウント キーを必要とするシステムに一時的にアクセスする必要がある場合は、有効期限を使用します。たとえば、次のような場合に有効期限を使用します。

  • サービス アカウント キーでのみ認証できるアプリケーションのコードを非本番環境で開発する
  • サービス アカウント キーでのみ認証できるサードパーティ製ツールを使用する

以下のシナリオでは、有効期限を使用しないでください。

  • 本番環境ワークロード。本番環境では、サービス アカウント キーが期限切れになると、誤ってサービスが停止する可能性があります。代わりに有効期限のない鍵を使用し、鍵のローテーションでライフサイクルを管理します。
  • 継続的インテグレーション（CI）パイプラインなど、永続的にアクセスする必要がある非本番環境ワークロード。
  • 指定した時間の経過後に鍵が使用されないようにする鍵のローテーション システム。推奨の鍵のローテーション戦略については、サービス アカウント キーのローテーションをご覧ください。

サービスの停止を防ぐため、constraints/iam.disableServiceAccountKeyCreation 組織ポリシーの制約が長期間適用されていない限り、有効期限を設定しないことをおすすめします。有効期限を設定する場合は、constraints/iam.disableServiceAccountKeyCreation 制約の適用も停止する必要があります。この制約の詳細については、サービス アカウント キーの存続期間を制限するをご覧ください。

有効期限を設定するには、次のようにします。

  1. サービス アカウント キーの有効期限を設定するプロジェクト、フォルダ、または組織を特定します。
  2. constraints/iam.serviceAccountKeyExpiryHours 制約を適用する組織のポリシーを追加します。この制約をプロジェクト、フォルダまたは組織に適用すると、その親リソース内で新しく作成されたすべてのサービス アカウント キーに有効期限が適用されます。既存の鍵は影響を受けません。

有効期限は時間単位です。8 時間、24 時間（1 日）または 168 時間（7 日）など、短い有効期限を使用することをおすすめします。有効期限を短くすることで、チームが鍵の更新プロセスを十分にテストできるようになります。まず、最も短い有効期限を設定し、その後、必要に応じて有効期限を長くしていきます。