IAM の概要

このページでは、Google Cloud の Identity and Access Management（IAM）システムの仕組みと、IAM を使用して Google Cloud でアクセスを管理する方法について説明します。

IAM を使用すると、特定の Google Cloud リソースに対するアクセス権をきめ細かく設定し、他のリソースへのアクセスを防ぐことができます。IAM を使用すると、最小権限のセキュリティ原則を導入できます。この原則では、必要以上に多くの権限を付与しないことが規定されています。

IAM の仕組み

IAM では、誰（ID）がどのリソースに対してどのようなアクセス権（ロール）を持つかを定義することにより、アクセス制御を管理します。たとえば、Compute Engine の仮想マシン インスタンス、Google Kubernetes Engine（GKE）クラスタ、Cloud Storage バケットはすべて Google Cloud のリソースです。リソースの整理に使用する組織、フォルダ、プロジェクトもリソースになります。

IAM では、リソースに対するアクセス権を直接エンドユーザーに付与することはありません。複数の権限をロールにまとめて、認証されたプリンシパルに付与します（これまで、IAM ではプリンシパルをメンバーと呼んでいました。一部の API では、まだこの用語が使用されています）。

許可ポリシー（IAM ポリシー）は、どのプリンシパルにどのロールが付与されるのかを定義し、適用します。各許可ポリシーはリソースに適用されます。認証されたプリンシパルがリソースにアクセスしようとすると、IAM はリソースの許可ポリシーをチェックし、そのアクションが許可されているかどうかを確認します。

次の図に、IAM で権限を管理する仕組みを示します。

2 つのロール バインディングを含む許可ポリシー。ロール バインディングは、特定のメンバーを特定のロールに関連付けます。

このアクセス管理モデルは、次の 3 つの主要な部分から構成されています。

  • プリンシパル。プリンシパルは、リソースにアクセスできる ID を表します。各プリンシパルには、固有の識別子があります。
  • ロール。ロールは権限のコレクションです。権限によって、リソースに対して許可されているオペレーションが決まります。プリンシパルにロールを付与すると、そのロールに含まれるすべての権限が付与されます。
  • ポリシー。許可ポリシーは、1 つ以上のプリンシパルを個々のロールにバインドするロール バインディングの集合です。リソースに対してどのようなアクセス権（ロール）を誰（プリンシパル）に許可するのかを定義する場合、許可ポリシーを作成して、そのポリシーをリソースに接続します。

たとえば、前述の図の許可ポリシーでは、user@example.com などのプリンシパルを App Engine 管理者ロール（roles/appengine.appAdmin）などのロールにバインドしています。許可ポリシーがプロジェクトに適用されている場合、プリンシパルはプロジェクト内の指定されたロールを取得します。

以降では、これらのコンセプトについて詳しく説明します。

IAM では、リソースにアクセスできる ID を表すプリンシパルに対してアクセス権を付与します。アクセス管理のコンテキストでは、プリンシパルは次のいずれかのタイプになります。

各プリンシパル タイプの ID の形式については、プリンシパル ID をご覧ください。

Google アカウント

Google アカウントは、Google で作成したアカウントを使用して Google Cloud を操作するデベロッパー、管理者、または他のユーザーを表します。Google アカウントに関連付けられているメールアドレス（gmail.com メールアドレスや他のドメインのメールアドレスなど）はプリンシパルとして使用できます。新規ユーザーは、Google アカウントの登録ページに移動して、Google アカウントに登録できます。

サービス アカウント

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションまたはコンピューティング ワークロードのアカウントです。Google Cloud にホストされているコードを実行する場合は、アプリケーションの ID として使用するサービス アカウントを指定します。必要な数のサービス アカウントを作成して、アプリケーションのさまざまな論理コンポーネントを表すことができます。サービス アカウントを使用してアプリケーションの認証を行う方法については、サービス アカウントをご覧ください。

Google グループ

Google グループは、Google アカウントとサービス アカウントの名前付きコレクションです。Google グループには、グループ固有のメールアドレスが関連付けられています。Google グループのホームページで [情報] をクリックすると、Google グループに関連付けられているメールアドレスを確認できます。Google グループの詳細については、Google グループのホームページをご覧ください。

Google グループを使用すると、ユーザーの集合に対してアクセス制御を簡単に適用できます。個々のユーザーまたはサービス アカウントごとにアクセス制御を付与または変更する代わりに、グループ全体に対して一度にアクセス制御を付与または変更できます。許可ポリシーを更新してユーザーを追加または削除するのではなく、Google グループにプリンシパルを追加または削除することもできます。

Google グループにはログイン認証情報がありません。Google グループでは、リソースへのアクセスをリクエストする ID を設定することはできません。

Google Workspace アカウント

Google Workspace アカウントは、そこに含まれるすべての Google アカウントの仮想グループを表します。Google Workspace アカウントは、example.com などの組織のインターネット ドメイン名に関連付けられています。新しいユーザーに Google アカウント（username@example.com など）を作成すると、その Google アカウントが Google Workspace アカウントの仮想グループに追加されます。

Google グループと同様に、Google Workspace アカウントを使用して ID を確立することはできませんが、権限の管理が容易になります。

Cloud Identity ドメイン

Cloud Identity ドメインは、1 つの組織内のすべての Google アカウントの仮想グループを表すため、Google Workspace アカウントに似ています。ただし、Cloud Identity ドメイン ユーザーは、Google Workspace のアプリケーションと機能にアクセスできません。詳細については、Cloud Identity についてをご覧ください。

allAuthenticatedUsers

allAuthenticatedUsers は、すべてのサービス アカウント、および Google アカウントで認証されたユーザー全員を表す特殊な識別子です。この ID には、個人用 Gmail アカウントなど、Google Workspace アカウントまたは Cloud Identity のドメインに接続していないアカウントも含まれます。認証されていないユーザー（匿名の訪問者など）は含まれません。

このプリンシパル タイプには、外部 ID プロバイダ（IdP）によって管理されるフェデレーション ID は含まれません。Workforce Identity 連携または Workload Identity 連携を使用する場合は、allAuthenticatedUsers を使用しないでください。代わりに、次のいずれかを使用します。

このプリンシパル タイプは、一部のリソースタイプでサポートされていません。

allUsers

allUsers は、認証されたユーザーと認証されていないユーザーの両方を含めて、インターネット上のユーザーを表す特殊な識別子です。

このプリンシパル タイプは、一部のリソースタイプでサポートされていません。

Workforce Identity プール内のフェデレーション ID

Workforce Identity プール内のフェデレーション ID は、外部 IdP で管理され、Workforce Identity 連携を使用して連携されたユーザー ID です。Workforce Identity プールで特定の ID を使用することも、特定の属性を使用して Workforce Identity プールでユーザー ID のグループを指定することもできます。フェデレーション ID のプリンシパル ID については、プリンシパル ID をご覧ください。

Workload Identity プール内のフェデレーション ID

Workload Identity プールのフェデレーション ID は、外部 IdP によって管理され、Workload Identity 連携を使用して連携されるワークロード ID です。Workload Identity プールで特定のワークロード ID を使用することも、特定の属性を使用して Workload Identity プールのワークロード ID のグループを指定することもできます。フェデレーション ID のプリンシパル ID については、プリンシパル ID をご覧ください。

GKE Pod

GKE で実行されているワークロードは、Workload Identity Federation for GKE を使用して Google Cloud サービスにアクセスします。GKE Pod のプリンシパル ID の詳細については、IAM ポリシーで Kubernetes リソースを参照するをご覧ください。

リソース

ユーザーが特定の Google Cloud リソースにアクセスする必要がある場合、そのリソースのロールをユーザーに付与できます。リソースの例として、プロジェクト、Compute Engine インスタンス、Cloud Storage バケットなどがあります。

一部のサービスでは、プロジェクト レベルよりもきめ細かく IAM 権限を付与できます。たとえば、特定の Cloud Storage バケットのユーザーにストレージ管理者ロール（roles/storage.admin）を付与できます。また、特定の Compute Engine インスタンスのユーザーに Compute インスタンス管理者ロール（roles/compute.instanceAdmin）を付与することもできます。

それ以外の場合は、プロジェクト レベルで IAM 権限を付与できます。権限は、そのプロジェクト内のすべてのリソースに継承されます。たとえば、プロジェクト内のすべての Cloud Storage バケットへのアクセスを許可するには、個々のバケットごとではなく、プロジェクトへのアクセスを許可します。プロジェクト内のすべての Compute Engine インスタンスへのアクセスを許可するには、個々のインスタンスごとではなく、プロジェクトへのアクセスを許可します。

どのリソースにどのロールを付与できるかについては、ロールについてをご覧ください。また、特定のロールについては、最下位のリソースの列をご覧ください。

権限

権限によって、リソースに対して許可されているオペレーションが決まります。IAM では、権限を service.resource.verb の形式で表します（例: pubsub.subscriptions.consume）。

多くの場合、権限は REST API メソッドと 1 対 1 で対応しています。つまり、Google Cloud の各サービスには、各 REST API メソッドに対して関連付けられている権限のセットがあります。そのメソッドの呼び出し元は、そのメソッドを呼び出すための権限を持っている必要があります。たとえば、Pub/Sub を使用し、topics.publish() メソッドを呼び出す必要がある場合は、そのトピックに対して pubsub.topics.publish 権限が必要になります。

ユーザーに直接権限を付与することはできません。代わりに、必要な権限を含むロールを指定し、そのロールをユーザーに付与します。使用可能なすべての権限と、それを含むロールのリストについては、権限のリファレンスをご覧ください。

ロール

ロールは権限のコレクションです。ユーザーに直接権限を付与することはできません。代わりに、ロールを付与します。ユーザーにロールを付与する際には、そのロールに含まれているすべての権限がユーザーに付与されます。

ロール マッピングの権限。

IAM にはいくつかのロールがあります。

  • 基本ロール: Google Cloud コンソールで従来から使用されているロール。オーナー、編集者、閲覧者のロールがあります。

  • 事前定義ロール: 基本ロールよりも詳細なアクセス制御が可能なロール。たとえば、Pub/Sub パブリッシャー（roles/pubsub.publisher）は事前定義ロールです。このロールは、Pub/Sub トピックへのメッセージの公開のみを許可します。

  • カスタムロール: 事前定義ロールがニーズを満たしていない場合に、組織のニーズに応じて権限を調整するために作成するロールです。

ロールの詳細については、次のリソースをご覧ください。

許可ポリシー

認証されたプリンシパルがリソースにアクセスしようとすると、IAM はリソースの許可ポリシーをチェックして、アクションが許可されているかどうかを確認します。

許可ポリシーは、誰がどの種類のアクセス権を持つかを定義するステートメントの集合です。これを作成することによって、ユーザーにロールを付与できます。許可ポリシーはリソースに関連付けられ、そのリソースがアクセスされると常にアクセス制御が適用されます。

IAM ポリシー

許可ポリシーは、ロール バインディング リストで構成されています。ロール バインディングはプリンシパルのリストをロールにバインドします。

  • role: プリンシパルに付与するロール。role は、roles/service.roleName の形式で指定します。たとえば、Cloud Storage には roles/storage.objectAdmin、roles/storage.objectCreator、roles/storage.objectViewer などのロールがあります。

  • members: このドキュメントの ID に関するコンセプトで説明しているプリンシパルから構成されたリスト。各プリンシパル タイプは接頭辞で識別されます。たとえば、Google アカウントには user:、サービス アカウントには serviceAccount:、Google グループには group:、Google Workspace アカウントまたは Cloud Identity ドメインには domain: が付いています。次のサンプルコードでは、プリンシパル user:ali@example.com、serviceAccount:my-other-app@appspot.gserviceaccount.com、group:admins@example.com、domain:google.com に storage.objectAdmin ロールを付与しています（各プリンシパルには所定の接頭辞が付いています）。user:maria@example.com には objectViewer ロールを付与します。

次のコード スニペットは、許可ポリシーの構造を示しています。

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:ali@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:admins@example.com",
        "domain:google.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

IAM とポリシー API

IAM には、Google Cloud のリソースに許可ポリシーを作成し、これを管理するための一連のメソッドが用意されています。これらのメソッドは、IAM をサポートするサービスによって公開されます。たとえば、IAM メソッドは、Resource Manager、Pub/Sub、Cloud Life Sciences API で公開されます。

IAM のメソッドは次のとおりです。

  • setIamPolicy(): リソースに許可ポリシーを設定します。
  • getIamPolicy(): 以前に設定された許可ポリシーを取得します。
  • testIamPermissions(): 呼び出し元にリソースに対する特定の権限があるかどうかをテストします。

これらのメソッドの API リファレンス トピックは、IAM をサポートする各サービスのドキュメントに記載されています。

リソース階層

Google Cloud のリソースは階層的に編成されます。

  • 組織は階層内のルートノードです。
  • フォルダは組織または他のフォルダの子です。
  • プロジェクトは組織またはフォルダの子です。
  • 各サービスのリソースはプロジェクトの子孫です。

各リソースの親は 1 つだけです。詳細については、Resource Manager のリソース階層をご覧ください。

次の図に、Google Cloud のリソース階層の例を示します。

IAM リソースの階層

許可ポリシーは、リソース階層の任意のレベル（組織レベル、フォルダレベル、プロジェクト レベル、リソースレベル）で設定できます。リソースは親リソースの許可ポリシーをすべて継承します。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーと、上位階層から継承された許可ポリシーを組み合わせたものです。

このポリシーの継承は推移的です。つまり、リソースではプロジェクトから許可ポリシーが継承され、そのプロジェクトではフォルダから許可ポリシーが継承され、そのフォルダでは組織から許可ポリシーが継承されます。したがって、組織レベルの許可ポリシーはリソースレベルでも適用されます。

たとえば、前の図で topic_a はプロジェクト example-prod 内に存在する Pub/Sub リソースです。example-prod の編集者のロールを micah@example.com に付与し、topic_a のパブリッシャーのロールを song@example.com に付与する場合は、topic_a の編集者のロールを micah@example.com に付与し、パブリッシャーのロールを song@example.com に付与します。

子リソースの許可ポリシーは、親リソースの許可ポリシーから継承されます。たとえば、あるユーザーに対してプロジェクトで編集者のロールを付与し、その子リソースでは同じユーザーに対して閲覧者のロールを付与している場合でも、そのユーザーは子リソースに対して編集者のロールを持つことになります。リソース階層を変更すると、ポリシーの継承も変更されます。たとえば、プロジェクトを組織に移動すると、そのプロジェクトは組織の許可ポリシーを継承することになります。

Google Cloud サービスの IAM サポート

IAM では、API リクエストを発行するアカウントがリソースを利用するための適切な権限を持っているかを確認するため、Google Cloud のすべてのサービスにおける各 API メソッドが確認されます。

Google Cloud サービスには事前定義ロールがあり、きめ細かいアクセス制御が可能です。たとえば、Compute Engine では Compute インスタンス管理者や Compute ネットワーク管理者などのロールを指定できます。また、Cloud Storage ではストレージ フォルダ管理者やストレージ オブジェクト ユーザーなどのロールを指定できます。

事前定義ロールは、ほとんどの Google Cloud サービスで使用できます。詳細については、事前定義ロールのリストをご覧ください。権限をより詳細に制御する必要がある場合は、カスタムロールの作成を検討してください。

特定のロールは、リソースへのアクセス権をプロジェクト レベルより細分化して、ユーザーに付与できます。たとえば、特定の Pub/Sub トピックに対するサブスクライバーのロールをユーザーに付与する許可ポリシーを作成できます。事前定義ロールのリストには、それぞれのロールを受け入れる最低レベル（きめ細かい）リソースタイプの説明が記載されています。

IAM API の整合性モデル

IAM API では結果整合性が維持されます。つまり、IAM API を使用してデータを書き込んだ直後にそのデータを読み取ると、読み取りオペレーションで古いデータが返される場合があります。また、加えた変更がアクセス チェックに影響するまでには、時間がかかる場合があります。

この整合性モデルは IAM API の動作に影響します。たとえば、サービス アカウントを作成し、そのすぐ後に別のリクエストでそのサービス アカウントを参照した場合、サービス アカウントが見つからないという結果が返される場合があります。この動作は、オペレーションが結果整合性に基づいているためです。新しいサービス アカウントが読み取りリクエストで利用可能になるまで時間がかかることがあります。

次のステップ

使ってみる

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

無料で開始