概要

このページでは、Identity and Access Management(IAM)の基本コンセプトについて説明します。

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

IAM の仕組み

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

IAM では、リソースに対するアクセス権を直接エンドユーザーに付与することはありません。複数の権限をロールにまとめて、認証されたメンバーに付与します。IAM ポリシーで、どのメンバーにどのロールを付与するかを定義し、このポリシーをリソースに関連付けます。認証されたメンバーがリソースにアクセスしようとすると、IAM はリソースのポリシーをチェックし、そのアクションが許可されているかどうかを確認します。

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

IAM アーキテクチャ

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

  • メンバーメンバーは、リソースへのアクセスが許可されている Google アカウント(エンドユーザー)、サービス アカウント(アプリまたは仮想マシン)、Google グループ、Google Workspace または Cloud Identity ドメインです。ユーザー、サービス アカウントまたは Google グループに関連付けられているメールアドレス、あるいは Google Workspace または Cloud Identity ドメインのドメイン名がメンバーの ID になります。
  • ロール。ロールは権限のコレクションです。権限によって、リソースに対して許可されているオペレーションが決まります。メンバーに役割を付与すると、その役割に含まれるすべての権限が付与されます。
  • ポリシー。IAM ポリシーは、1 つ以上のメンバーを 1 つのロールにバインドします。リソースに対してどのようなアクセス権(ロール)を誰(メンバー)に許可するのかを定義する場合、ポリシーを作成して、そのポリシーをリソースに接続します。

たとえば、前述の図の IAM ポリシーでは、userid@gmail.com などのメンバーを App Engine 管理者ロール(roles/appengine.appAdmin)などのロールにバインドしています。ポリシーがプロジェクトに接続されている場合、メンバーはプロジェクト内の指定されたロールを取得します。

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

IAM では、メンバーに対してアクセス権を付与します。メンバーには次のタイプがあります。

  • Google アカウント
  • サービス アカウント
  • Google グループ
  • Google Workspace ドメイン
  • Cloud Identity ドメイン

Google アカウント

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

サービス アカウント

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションのアカウントです。Google Cloud にホストされているコードを実行すると、このコードは指定したアカウントとして実行されます。利用するアプリケーションの個別の論理コンポーネントを表すために必要な数だけ、サービス アカウントを作成できます。アプリケーションでサービス アカウントを使用する方法については、認証の開始をご覧ください。

Google グループ

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

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

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

Google Workspace ドメイン

Google Workspace ドメインは、組織の Google Workspace アカウントで作成されたすべての Google アカウントの仮想グループを表します。Google Workspace ドメインは、組織のインターネット ドメイン名(example.com など)を表し、Google Workspace ドメインにユーザーを追加すると、この仮想グループ(username@example.com など)内のユーザー用に新しいアカウントが作成されます。

Google グループと同様に、Google Workspace ドメインを使用して ID を確立することはできませんが、G Suite ドメインを使用すると権限管理が容易になります。

Cloud Identity ドメイン

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

allAuthenticatedUsers

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

allUsers

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

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

このセクションでは、承認プロセスに関連するエンティティとコンセプトについて説明します。

リソース

ユーザーが特定の 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 Console で従来から使用されているロール。オーナー、編集者、閲覧者のロールがあります。

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

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

ユーザーにロールを付与する方法については、アクセス権の付与、変更、取り消しをご覧ください。Cloud IAM で使用可能な事前定義ロールの詳細については、ロールについてをご覧ください。カスタムロールの作成については、カスタムロールについてカスタムロールの作成と管理をご覧ください。

IAM ポリシー

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

IAM ポリシー

IAM ポリシーは、IAM Policy オブジェクトによって表されます。IAM Policy オブジェクトは、バインディング リストで構成されています。Binding は、members のリストを role にバインドします。

  • role: メンバーに付与する役割。role は、roles/service.roleName の形式で指定します。たとえば、Cloud Storage には roles/storage.objectAdminroles/storage.objectCreatorroles/storage.objectViewer などの役割があります。

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

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

{
  "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 リソースの階層

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 に付与します。

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

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

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

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

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

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

次のステップ