概要

このページでは、Cloud Identity and Access Management の基本概念について説明します。

Google Cloud Platform(GCP)に備わっている Cloud IAM を使用すると、誰(ID)がどのリソースに対するどのようなアクセス権限(役割)を持つかを定義することで、アクセス権限を管理できます。

IAM

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

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

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

Google アカウント

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

サービス アカウント

サービス アカウントは、個々のエンドユーザーではなく、アプリケーションに属するアカウントです。GCP でホストされているコードを実行する際には、そのコードの実行で使用されるアカウントを指定します。利用するアプリケーションの個別の論理コンポーネントを表すために必要な数だけ、サービス アカウントを作成できます。詳細については、Google Cloud Platform Console のサービス アカウントに関するドキュメントをご覧ください。

Google グループ

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

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

Google グループにはログイン認証情報がないため、Google グループを使用して、リソースへのアクセス権のリクエストを行うための ID を確立することはできません。

G Suite ドメイン

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

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

Cloud Identity ドメイン

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

allAuthenticatedUsers

これは、Google アカウントまたはサービス アカウントで認証されたユーザー全員を表す特殊な識別子です。認証されていないユーザー(匿名の訪問者など)は含まれません。

allUsers

これは、認証されたユーザーと認証されていないユーザーの両方を含めて、インターネット上のユーザーを表す特殊な識別子です。GCP API の中には、サービスにアクセスするすべてのユーザーの認証を必要とするものがあること、その場合、allUsers は認証されたすべてのユーザーの承認のみを表すことに注意してください。

認証されたメンバーがリクエストを作成しようとすると、リソースに対するオペレーションの実行が許可されているかどうかの承認が Cloud IAM によって判断されます。

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

リソース

GCP リソースに関するアクセス権をユーザーに付与できます。リソースの例として、プロジェクトCompute Engine インスタンスCloud Storage バケットなどがあります。

Cloud Pub/Sub などの一部のサービスでは、プロジェクト レベルよりもきめ細かく IAM 権限を付与できます。たとえば、特定の Cloud/Sub トピックに関するサブスクライバーの役割をユーザーに付与できます。ただし、ほとんどの場合はプロジェクトに対する IAM 権限を付与し、プロジェクト内のすべてのリソースにその権限が適用されます。たとえば、Compute Engine インスタンスへのアクセス権を付与するには、そのインスタンスを含むプロジェクトへのアクセス権を付与する必要があります。どのリソースに関してどの役割を付与できるかについては、役割についてをご覧ください。

権限

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

権限は通常、REST メソッドと 1:1 に対応しています(そうでない場合もあります)。つまり、GCP の各サービスには、公開されている各 REST メソッドに関連付けられている権限のセットがあります。そのメソッドの呼び出し元は、そのメソッドを呼び出すための権限を持っている必要があります。たとえば、Publisher.Publish() の呼び出し元には pubsub.topics.publish 権限が必要です。

ユーザーには権限を直接割り当てるのではなく、1 つ以上の権限を含む役割を割り当てます。

役割

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

役割マッピングの権限

Cloud IAM では、次の 3 種類の役割があります。

  • 基本の役割: Google Cloud Platform Console で従来使用されていた役割は継続して使用できます。オーナー編集者閲覧者の役割があります。

  • 事前定義済みの役割: 基本の役割より詳細なアクセス制御が可能な Cloud IAM の役割です。たとえば、事前定義済みの役割 Pub/Sub パブリッシャー(roles/pubsub.publisher)では、単に Cloud Pub/Sub トピックにメッセージをパブリッシュするだけのアクセス権が提供されます。

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

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

IAM ポリシー

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

IAM ポリシー

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

role はメンバーに割り当てる役割です。roleroles/<name of the role> という形式で指定します。たとえば、roles/storage.objectAdminroles/storage.objectCreatorroles/storage.objectViewer となります。

members には、上記の ID に関する概念セクションで説明した 1 つ以上の ID のリストが含まれます。各メンバータイプは、Google アカウント(user:)、サービス アカウント(serviceAccount:)、Google グループ(group:)、G Suite または Cloud Identity ドメイン(domain:)などの接頭辞で識別されます。次のサンプルコードでは、適切な接頭辞を使用して、owner 役割がメンバー user:alice@example.comserviceAccount:my-other-app@appspot.gserviceaccount.comgroup:admins@example.com、および domain:google.com に割り当てられます。viewer 役割は user:bob@example.com に割り当てられます。

次のサンプルコードは、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 には、GCP リソースのアクセス制御ポリシーの作成と管理に使用できる一連のメソッドがあります。これらのメソッドは、Cloud IAM をサポートするサービスによって公開されます。たとえば、Resource Manager、Cloud Pub/Sub、Genomics の API で Cloud IAM メソッドが公開されています。

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

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

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

ポリシー階層

GCP のリソースは階層別に編成されています。階層のルートノードは組織ノードで、プロジェクトは組織の子、その他のリソースはプロジェクトの子孫になります。各リソースの親は 1 つだけです。詳細については、Resource Manager のリソース階層をご覧ください。

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

リソース階層

Cloud IAM ポリシーを、リソース階層の任意のレベル(組織レベル、フォルダレベル、プロジェクト レベル、リソースレベル)で設定できます。各リソースは親リソースのポリシーを継承します。組織レベルで設定されたポリシーはすべての子プロジェクトに自動的に継承され、プロジェクト レベルで設定されたポリシーはすべての子リソースに継承されます。リソースに対して有効なポリシーは、そのリソースに設定されたポリシーと階層内で上位にあるポリシーの和です。

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

たとえば、上の図では、topic_a がプロジェクト example-prod の下にある Cloud Pub/Sub リソースです。micah@gmail.com に example-prod に対する編集者の役割を付与し、song@gmail.com に topic_a に対するパブリッシャーの役割を付与すると、topic_a に対する編集者の役割が micah@gmail.com に、パブリッシャーの役割が song@gmail.com に効率的に付与されます。

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

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

GCP サービスでの Cloud IAM サポート

Cloud IAM では、すべての GCP サービスのすべての API メソッドが検査され、API リクエストを行うアカウントに、リソースを使用するための適切な権限があることを確認します。

Cloud IAM が導入される前は、オーナー、編集者、閲覧者の役割だけを付与できました。これらの役割では、プロジェクトに関する非常に広範なアクセス権が与えられるため、作業を分離することができませんでした。現在、GCP サービスではオーナー、編集者、閲覧者の役割よりも詳細なアクセス制御が可能な事前定義された役割が追加されています。たとえば、Compute Engine ではインスタンス管理者やネットワーク管理者、App Engine ではアプリ管理者やサービス管理者などの役割が提供されています。従来のオーナー、編集者、閲覧者の役割に加えて、これらの事前定義済みの役割を使用できます。

権限をより詳細に制御する必要がある場合は、カスタムの役割を作成することを検討してください。

Cloud IAM の事前定義済みの役割は次のプロダクトで提供されています。

事前定義済みの役割の一覧については、役割についてをご覧ください。

特定の役割は、リソースへのアクセス権をプロジェクト レベルより細分化して、ユーザーに付与することができます。たとえば、特定の Cloud/Sub トピックに関するサブスクライバーの役割をユーザーに付与する Cloud IAM アクセス制御ポリシーを作成できます。どのリソースに関してどの役割を付与できるかについては、役割についてをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

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