サービス アカウントの使用と管理のベスト プラクティス

サービス アカウントは人間以外のユーザーを表します。これは、カスタム アプリケーションなどのワークロードで、エンドユーザーの関与なしにリソースにアクセスする場合や、アクションを実行する必要がある場合を対象としています。

サービス アカウントは、通常のユーザー アカウントと次の点で異なります。

  • パスワードが設定されていないため、ブラウザベースのログインには使用できません。
  • Google Cloud プロジェクトに属するリソースとして作成され、管理されます。これに対して、ユーザーは Cloud Identity または Google Workspace のアカウントで管理されます。
  • Google Cloud に固有です。一方、Cloud Identity または Google Workspace で管理されるユーザーは、Google の多数のプロダクトとサービスで動作します。

このガイドでは、サービス アカウントを管理、使用、保護するためのベスト プラクティスについて説明します。

サービス アカウントを使用するタイミングの選択

サービス アカウントは多くの異なる目的で使用できますが、常に最適な選択肢であるとは限りません。次のセクションでは、サービス アカウントを使用することが適切なケースと回避する必要があるケースについて説明します。

手動操作を必要としないシナリオにサービス アカウントを使用する

すべてのアプリケーションが人間のユーザーとやり取りを行うわけではありません。アプリケーションがバックグラウンドで人手を介さず自動的に実行されている場合もあります。ユーザー不在で実行されるアプリケーションには、バッチジョブ、キューから読み取られたメッセージがディスパッチされるワーカー プロセス、リソース モニタリング エージェントなどがあります。

ユーザー不在のアプリケーションで Cloud Storage バケットなどのリソースにアクセスが必要となった場合、アプリケーションはエンドユーザーではなく、自身の代理として動作する必要があります。アプリケーションが自身の代理で動作するには、エンドユーザー ID と無関係の独自の ID が必要です。

アプリケーションに独自の ID を付与するには、アプリケーションのサービス アカウントを作成し、アプリケーションがアクセスする必要があるリソースへのアクセス権をサービス アカウントに付与します。アプリケーションに独自のサービス アカウントの使用を許可すると、ユーザーが操作しなくてもアプリケーションが動作できるようになります。さらに、アプリケーションによって開始されたリソースへのアクセスを、同じアプリケーションに関連付けられるようにします。

サービス アカウントを使用してプリンシパル間の移行を行う

エンドユーザーとやり取りするアプリケーションは、Google ログインを使用してユーザーを認証できます。ただし、認証を行うことは必須ではありません。アプリケーションがサードパーティ ID プロバイダを使用する場合や、カスタム認証スキームを実装してユーザーを認証する場合があります。

サードパーティ ID またはカスタム ID を使用するアプリケーションで、BigQuery データセットや Cloud Storage バケットなどのリソースにアクセスする必要がある場合は、プリンシパル間の移行を実行する必要があります。Google Cloud APIs はサードパーティ ID またはカスタム ID を認識しないため、アプリケーションはエンドユーザーの ID を BigQuery や Cloud Storage に伝播できません。アプリケーションは別の Google ID を使用してアクセスを実行する必要があります。

アプリケーションがプリンシパル間で移行を実行できるようにするには、アプリケーションのサービス アカウントを作成し、アプリケーションがアクセスする必要があるリソースへのアクセス権を付与します。アプリケーションが Google Cloud リソースにアクセスする必要性が生じるたびに、アプリケーションがエンドユーザーを認証した後に、サービス アカウントを使用してリソースにアクセスできるようにします。

プリンシパル間の移行により、影響を受ける Google Cloud リソースの Cloud Audit Logs の有用性が制限される可能性があります。これは、アプリケーションがサービス アカウントを使用してリソースにアクセスするため、アクションが特定のエンドユーザーに代わって実行されたものであるかどうかが Cloud Audit Logs で明確に示されない場合があるためです。責任追及性を確保するため、プリンシパル間の移行が発生するたびにカスタム ログレコードを書き込むようにアプリケーションを拡張します。これにより、どのユーザーがリソースへのアクセスをトリガーしたかをトレースできます。

アプリケーションで、機密性の高いユーザーデータへのアクセスが必要になる場合があります。このようなデータの例としては、ユーザーのメールボックスやカレンダー、ドライブに保存されたドキュメント、機密データを含む BigQuery データセットなどがあります。

ユーザー不在のアプリケーションで、インデックス登録やデータ損失防止(DLP)のスキャンなどのバックグラウンド タスクが実行される場合や、エンドユーザーが Google ID で認証されていない場合には、サービス アカウントを使用してユーザーデータにアクセスできます。アプリケーションがエンドユーザーに代わって動作するその他のシナリオでは、サービス アカウントを使用しないことをおすすめします。

ユーザーデータにアクセスする際には、サービス アカウントではなく(プリンシパルの移行を実行している可能性あるため)、OAuth 同意フローを使用してエンドユーザーの同意をリクエストします。その後、アプリケーションがエンドユーザー ID で処理を行うことができるようにします。サービス アカウントの代わりに OAuth を使用すると、次のことができるようになります。

  • ユーザーは、アプリケーションにアクセス権を付与しようとしているリソースを確認し、自身の同意または拒否を明示的に表明できます。
  • ユーザーは随時、[アカウント情報] ページで同意を取り消すことができます。
  • すべてのユーザーのデータに対して無制限のアクセス権を付与されたサービス アカウントは必要ありません。

アプリケーションにエンドユーザー認証情報の使用を許可することで、Google Cloud APIs に対する権限チェックを延期します。これにより、コーディング エラーが原因でユーザーがアクセスすることを許可しないようにする必要があるデータが、誤って公開されてしまうリスク(混乱した使節に関する問題)を低減できます。

開発中にサービス アカウントを使用しない

日常業務で、gcloud コマンドライン ツール、gsutilterraform などのツールを使用する場合があります。これらのツールの実行でサービス アカウントを使用しないでください。代わりに、gcloud auth logingcloud ツールと gsutil の場合)または gcloud auth application-default loginterraform などのサードパーティ ツールの場合)を実行して、ツールがユーザーの認証情報を使用することを許可します。

Google Cloud にデプロイする予定のアプリケーションの開発とデバッグにも、同様の方法を使用できます。デプロイ後、アプリケーションでサービス アカウントが必要になる場合がありますが、ローカル ワークステーションで実行する場合は、個人用の認証情報を使用できます。

アプリケーションで個人の認証情報とサービス アカウント認証情報の両方をサポートするには、Cloud クライアント ライブラリを使用して認証情報を自動的に検索します。

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

一般に、Google Cloud のユーザー認証方法としては、ユーザー名とパスワードによるログインか、シングル サインオン(SSO)を使用します。サービス アカウントにはパスワードがなく、SSO を使用できません。サービス アカウントに対しては別の認証方法がサポートされています。次のセクションでは、認証方法を選択する際のベスト プラクティスについて説明します。

サービス アカウントの使用方法

可能な場合には接続されたサービス アカウントを使用する

Google Cloud にデプロイされたアプリケーションでサービス アカウントを使用できるようにするには、基盤となるコンピューティング リソースにサービス アカウントを接続します。サービス アカウントを接続すると、アプリケーションはサービス アカウントのトークンを取得し、そのトークンを使用して Google Cloud APIs とリソースにアクセスできます。

アプリケーションでアクセス トークンを取得するには、可能であればクライアント ライブラリを使用します。クライアント ライブラリは、サービス アカウントが接続されているコンピューティング リソースでアプリケーションが実行されているかどうかを自動的に検出します。

クライアント ライブラリの使用が現実的でない場合は、メタデータ サーバーからトークンをプログラムで取得するようにアプリケーションを調整します。メタデータ サーバーへのアクセスをサポートするコンピューティング リソースには次のものがあります。

サービス アカウントを接続できるコンピューティング リソースの一覧については、サービス アカウントの権限借用の管理をご覧ください。

Workload Identity を使用してサービス アカウントを Kubernetes Pod に接続する

Google Kubernetes Engine を使用する場合は、1 つの GKE クラスタで異なるアプリケーションを組み合わせて実行できます。アクセスする必要があるリソースと API は、アプリケーションごとに異なる可能性があります。

サービス アカウントを GKE クラスタまたはそのいずれかのノードプールに接続する場合、デフォルトでは、クラスタまたはノードプールで実行されているすべての Pod がサービス アカウントの権限を借用できます。異なるアプリケーション間で単一のサービス アカウントを共有すると、サービス アカウントに正しい権限セットを割り当てるのが難しくなります。

  • すべてのアプリケーションが必要とするリソースへのアクセス権のみを付与すると、一部のアプリケーションが特定のリソースにアクセスできず、動作しないことがあります。
  • 特定のアプリケーションが必要とするすべてのリソースへのアクセス権を付与すると、過剰なアクセス権を付与してしまう可能性があります。

GKE 環境内のリソースへのアクセスを管理する場合は Workload Identity を使用するのが良い方法です。

  1. GKE クラスタまたはノードプールにサービス アカウントを接続しないでください。
  2. Google API またはリソースへのアクセスが必要な Kubernetes Pod ごとに専用のサービス アカウントを作成します。
  3. Google API またはリソースにアクセスする必要がある Kubernetes Pod ごとに Kubernetes サービス アカウントを作成し、Pod に接続します。
  4. Workload Identity を使用して、サービス アカウントと対応する Kubernetes サービス アカウント間のマッピングを作成します。

Workload Identity 連携を使用して、オンプレミスまたは他のクラウド プロバイダで実行されているアプリケーションがサービス アカウントを使用できるようにする

オンプレミスまたは別のクラウド プロバイダでアプリケーションを実行する場合は、基盤となるコンピューティング リソースにサービス アカウントを接続することはできません。ただし、アプリケーションが次のような環境固有の認証情報にアクセスできる場合があります。

  • AWS の一時的な認証情報
  • Azure Active Directory アクセス トークン
  • Active Directory フェデレーション サービス(AD FS)や KeyCloak などのオンプレミス ID プロバイダが発行する OpenID アクセス トークンまたは ID トークン

アプリケーションがこれらの認証情報のいずれかへのアクセス権を付与されており、Google Cloud APIs またはリソースへのアクセス権を必要とする場合は、Workload Identity の連携を使用します。

Workload Identity 連携を使用すると、Google Cloud プロジェクトと外部 ID プロバイダ間の一方向の信頼関係を作成できます。信頼を確立すると、アプリケーションは、信頼できる ID プロバイダによって発行された認証情報を使用して、次の 3 つのステップで構成されるプロセスに沿ってサービス アカウントの権限を借用できます。

  1. 信頼できる ID プロバイダから認証情報(OpenID Connect ID トークンなど)を取得します。
  2. Security Token Service(STS)API を使用して、有効期間の短い Google STS トークンと認証情報を交換します。
  3. STS トークンを使用して、IAM Service Account Credentials API に対する認証を行い、サービス アカウントには有効期間の短い Google アクセス トークンを取得します。

Workload Identity 連携を使用することで、外部環境に用意された認証メカニズムをアプリケーションが使用することを許可できます。これにより、サービス アカウント キーを保存して管理する必要がなくなります。

IAM Credentials API を使用して認証情報を仲介する

アプリケーションによっては、特定のタイミングや状況下でのみ特定のリソースへのアクセスが必要になることがあります。次に例を示します。

  • アプリケーションの起動時に構成データにアクセスする必要があり、初期化後はアクセスする必要がなくなる場合があります。
  • スーパーバイザー アプリケーションが、アクセス要件が異なるバックグラウンド ジョブを定期的に開始する場合があります。

このようなシナリオでは、1 つのサービス アカウントを使用してすべてのリソースにアクセス権を付与することは、最小権限の原則に反します。アプリケーションがいつでも必要以上に多くのリソースにアクセスできてしまう可能性があります。

アプリケーションのさまざまな部分が、必要なリソースのみにアクセスできるようにするには、IAM Credentials API を使用して有効期間の短い認証情報を仲介します。

  • アプリケーションまたはユースケースごとに専用のサービス アカウントを作成し、必要なリソースにのみサービス アカウントへのアクセス権を付与します。
  • スーパーバイザーとして機能する別のサービス アカウントを作成します。他のサービス アカウントにサービス アカウント トークン作成者のロールを付与し、これらのサービス アカウントに有効期間の短いアクセス トークンをリクエストできるようにします。
  • アプリケーションを分割して、アプリケーションの 1 つの部分をトークン ブローカーとして機能させ、この部分のみがスーパーバイザー サービス アカウントを使用できるようにします。
  • トークン ブローカーを使用して、有効期間の短いサービス アカウントをアプリケーションの別の部分に発行します。

他に有効な方法がない場合にサービス アカウント キーを使用する

サービス アカウントの接続が不可能で、Workload IdentityWorkload Identity 連携のいずれも使用できない状況が発生することもあります。たとえば、オンプレミス アプリケーションの 1 つが Google Cloud リソースへのアクセスを必要としていても、オンプレミスの ID プロバイダが OpenID Connect と互換性がなく、Workload Identity 連携に使用できない場合があります。

他の認証方法を使用できない場合は、アプリケーションのサービス アカウント キーを作成します。サービス アカウント キーを使用すると、ユーザーがユーザー名とパスワードを使用して認証する方法と同様に、サービス アカウントでアプリケーションの認証を行うことができます。サービス アカウント キーはシークレットの一つで、不正アクセスから保護する必要があります。これらは Key Vault などの安全な場所に保存し、頻繁にローテーションすることをおすすめします。

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

サービス アカウントは通常のユーザー アカウントとは異なり、使用方法だけでなく、管理方法も異なります。以降のセクションでは、サービス アカウントを管理する際のベスト プラクティスについて説明します。

サービス アカウントをリソースとして管理する

通常のユーザー アカウントは組織の joiner-mover-leaver プロセスで管理されます。新しい従業員が入社すると、新しいユーザー アカウントが作成されます。従業員が異動した場合は、そのユーザー アカウントが更新されます。退職した場合、そのユーザー アカウントは一時停止または削除されます。

これに対し、サービス アカウントは特定の従業員に関連付けられていません。サービス アカウントはリソースとして考えてください。このアカウントは、特定の VM インスタンスやアプリケーションなど、別のリソースまたはその一部に属しています。

サービス アカウントを効果的に管理するには、サービス アカウントを単独では捉えないでください。関連付けられているリソースのコンテキストでサービス アカウントを考慮し、サービス アカウントと関連付けられているリソースを 1 つのユニットとして管理します。サービス アカウントと関連付けられているリソースに同じプロセス、同じライフサイクル、同じデュー デリジェンスを適用し、同じツールで管理します。

単一目的のサービス アカウントを作成する

複数のアプリケーションで単一のサービス アカウントを共有すると、サービス アカウントの管理が複雑になる場合があります。

  • アプリケーションによってライフサイクルが異なる場合があります。アプリケーションが廃止された場合、サービス アカウントを廃止可能かどうか、必要かどうか判断できない場合があります。
  • アプリケーションのアクセス要件は時間とともに変化する可能性があります。アプリケーションが同じサービス アカウントを使用している場合、サービス アカウントにアクセス権を付与する必要がある対象リソースの数が増加すると、全般的なリスクが増大する可能性があります。
  • Cloud Audit Logs には、データの変更またはデータへのアクセスを行ったサービス アカウントの名前が含まれますが、サービス アカウントを使用したアプリケーションの名前は表示されません。複数のアプリケーションが 1 つのサービス アカウントを共有している場合は、アクティビティを適切なアプリケーションに対してトレースできない可能性があります。

このような厄介な事態を回避するには、デフォルトのサービス アカウントを使用せず、アプリケーションごとに専用のサービス アカウントを作成します。

命名とドキュメントの規則に従う

サービスとアプリケーションまたはリソースの関連付けを追跡できるように、新しいサービス アカウントを作成する際は、命名規則に従います。

  • アカウントの使用方法を表すプレフィックスをサービス アカウントのメールアドレスに追加します。例:
    • VM インスタンスに接続されているサービス アカウントには vm-
    • Workload Identity で使用されるサービス アカウントには wi-
    • Workload Identity 連携で使用されるサービス アカウントには wif-
    • オンプレミス アプリケーションで使用されるサービス アカウントには onprem-
  • アプリケーションの名前をサービス アカウントのメールアドレスに埋め込みます。たとえば、VM が出張費用に関連するアプリケーションを実行している場合は、vm-travelexpenses@ を使用します。
  • 説明フィールドを使用して、担当者の連絡先、関連ドキュメントへのリンク、その他のメモを追加します。

サービス アカウントのメールアドレスに機密情報を埋め込まないでください。

未使用のサービス アカウントを特定して無効にする

サービス アカウントを使用しなくなった場合は、サービス アカウントを無効にします。未使用のサービス アカウントを無効にすると、攻撃者によるラテラル ムーブメントや権限昇格などの不正行為に悪用されるリスクを軽減できます。

VM インスタンスなどの特定のリソースに関連付けられている単一目的のサービス アカウントの場合は、関連付けられたリソースが無効化または削除されたときにすぐサービス アカウントを無効にします。

複数の目的で使用されているサービス アカウントや複数のリソースで共有されているサービス アカウントの場合、サービス アカウントが引き続き使用されているかどうかを特定できないことがあります。このような場合は、次の方法を使用します。

未使用のサービス アカウントを削除する前にサービスを無効にする

サービス アカウントを削除した後、同じ名前で新しいサービス アカウントを作成した場合、新しいサービス アカウントには別の ID が割り当てられます。そのため、元の IAM バインディングが新しいサービス アカウントに適用されることはありません。これに対して、サービス アカウントを無効にして再度有効にした場合は、すべての IAM バインディングがそのまま残ります。

IAM バインディングが誤って失われないようにするには、サービス アカウントを直ちに削除しないことをおすすめします。代わりに、不要になったサービス アカウントを無効にし、特定の時間が経過した後に削除します。

App EngineCompute Engine のデフォルトのサービス アカウントなど、デフォルトのサービス アカウントは削除しないでください。これらのサービスは、それぞれの API を無効にして再度有効にしない限り再作成できません。このため、既存のデプロイが中断される可能性があります。デフォルトのサービス アカウントを使用しない場合は、これらのアカウントを無効にします。

次のステップ