概要

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

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

Cloud IAM の仕組み

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

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

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

Cloud IAM アーキテクチャ

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

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

たとえば、前述の図の Cloud IAM ポリシーでは、userid@gmail.com で識別されるエンドユーザーを App Engine 管理者ロール(roles/appengine.appAdmin)にバインドしています。このポリシーをプロジェクトに適用すると、そのプロジェクトでの App Engine 管理者ロールがユーザー userid@gmail.com に付与されます。このユーザーは、App Engine でプロジェクト レベルのアプリの構成と設定をすべて表示し、作成または更新できます。

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

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

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

Google アカウント

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

サービス アカウント

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

Google グループ

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

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

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

G Suite ドメイン

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

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

Cloud Identity ドメイン

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

allAuthenticatedUsers

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

allUsers

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

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

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

リソース

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

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

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

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

権限

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

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

ユーザーに直接権限を付与することはできません。代わりに、必要な権限を含むロールを指定し、そのロールをユーザーに付与します。

ロール

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

ロール マッピングの権限

Cloud IAM では、次の 3 種類のロールがあります。

  • 基本ロール: Google Cloud Console で従来から使用されているロール。 オーナー、編集者、閲覧者のロールがあります。これらのロールは、すべての Google Cloud サービスでさまざまな権限を持つため、使用を控えてください。

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

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

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

Cloud IAM ポリシー

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

Cloud IAM ポリシー。

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

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

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

次のサンプルコードは、Cloud IAM ポリシーの構造を示しています。

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

Cloud IAM とポリシー API

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

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

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

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

ポリシー階層

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

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

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

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

Cloud IAM リソースの階層。

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

Cloud IAM ポリシー階層は、Google Cloud リソース階層と同じパスをたどります。リソース階層を変更すると、ポリシー階層も変更されます。たとえば、ある組織にプロジェクトを移動すると、そのプロジェクトの Cloud IAM ポリシーは、その組織の Cloud IAM ポリシーから継承するように更新されます。

高いレベルで付与されたアクセス権を子のポリシーで制限することはできません。たとえば、プロジェクトで編集者のロールをユーザーに付与していて、その子リソースで閲覧者のロールを同じユーザーに付与している場合、そのユーザーは子リソースでも編集者のロールを持つことになります。

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

Cloud IAM では、Google Cloud サービスに API メソッドが実行されるたびに、API リクエストを実行するアカウントにリソースを使用するための適切な権限があるかどうか確認します。

Cloud IAM が導入される前は、オーナー、編集者、閲覧者のロールだけを付与できました。これらのロールは、プロジェクトに対して非常に幅広いアクセス権を付与するため、きめ細かい職掌分散を行うことができません。Google Cloud サービスに、オーナー、編集者、閲覧者のロールよりも細かいアクセス制御を可能にする事前定義ロールが追加されました。たとえば、Compute Engine ではインスタンス管理者やネットワーク管理者、App Engine ではアプリ管理者やサービス管理者などのロールが提供されています。オーナー、編集者、閲覧者の基本ロールに加えて、これらの事前定義ロールを使用できます。

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

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

次のステップ