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

背景

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションや仮想マシン(VM)に属している特別な種類の Google アカウントです。アプリケーションは、サービス アカウントの ID を持つ Google API を呼び出すため、ユーザーが直接関わることはありません。サービス アカウントには、Google の認証を受けるために使用する 0 組以上のサービス アカウント キーを割り当てることができます。

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

  • サービス アカウントでアクセス可能なリソース
  • サービス アカウントに必要な権限
  • サービス アカウントの ID を持つコードが実行される場所(Google Cloud Platform またはオンプレミスのどちらか)

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

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

IAM サービス アカウントの特徴のひとつは、リソースとしても ID としても扱うことができることです。

サービス アカウントを ID として扱うことで、サービス アカウントに対して、リソース(プロジェクトなど)にアクセスするための役割を付与することができます。

サービス アカウントをリソースとして扱うことで、ユーザーに対して、そのサービス アカウントにアクセスするための権限を付与することができます。ユーザーには、サービス アカウントにアクセスするため役割として、オーナー、編集者、閲覧者、サービス アカウント アクターのいずれかを付与できます。

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

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

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

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

サービス アカウントとしての動作

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

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

  1. サービス アカウントを作成し、そのサービス アカウントを使用する従業員にサービス アカウント アクターの役割を付与します。この役割を、ジョブの開始権限が与えられる従業員に付与する必要があります。この役割を従業員に付与すると、サービスアカウントはリソースになります。

  2. これで、サービス アカウント アクターの役割を割り当てられた従業員は、ジョブを開始するサービス アカウントとして動作できます。この場合、サービス アカウントは ID です。

この方法は、サービス アカウントを使ってオペレーションを実行する場合に利用できます。まずサービス アカウントをリソースとして扱い、誰がそのリソースを使用できるかを決定します。これにより、サービス アカウント アクターの役割を割り当てられた従業員は、サービス アカウントを ID として使用し、そのサービス アカウントとして動作して、オペレーションを実行できます。

次の図は、この例を示しています。

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

サービス アカウントのサービス アカウント アクターとなったユーザーは、そのサービス アカウントがアクセス権限を持つすべてのリソースにアクセスできます。そのため、サービス アカウント アクターの役割をユーザーに付与する際は十分な注意が必要です。

Google Cloud Platform へのデータの移行

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

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

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

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

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

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

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

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

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

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

  • GCP が管理するキー。これらのキーは、App Engine や Compute Engine などの Cloud Platform サービスによって使用されます。これらのキーをダウンロードすることはできません。これらのキーは Google によって管理され、毎日、自動的にローテーションされます。

  • ユーザーが管理するキー。これらのキーは、ユーザーによって作成、ダウンロード、管理されます。

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

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

キーに対するアクセス権を持つすべてのユーザーは、サービス アカウント経由でリソースにアクセスできるようになります。デベロッパーがサービス アカウント キーをソースコードに組み込んだり、ダウンロード ディレクトリに置いたままにしたりしないように指示してください。

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

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

  • serviceAccount.keys.list() メソッドを使用して、サービス アカウントとキーの監査を行います。

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

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

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

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

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

おすすめの方法

  • サービス アカウントとして活動できるユーザーの数を制限してください。サービス アカウントのサービス アカウント アクターとなったユーザーは、そのサービス アカウントがアクセス権限を持つすべてのリソースにアクセスできます。そのため、serviceAccountActor の役割をユーザーに付与する際は十分な注意が必要です。

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

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

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

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

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

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

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

  • Google App Engine または Google Compute Engine でインスタンスが実行されており使用中になっているサービス アカウントを削除しないでください。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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

Cloud Identity and Access Management のドキュメント