概要

このページでは、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 グループ

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 グループと同様に、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 ポリシーをチェックして、アクションが許可されているかどうかを確認します。

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

リソース

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

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 メソッドと 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 オブジェクトは、バインディング リストで構成されています。Binding は、members のリストを 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:)などの接頭辞で識別されます。次のサンプルコードでは、適切な接頭辞を使用して、storage.objectAdmin 役割がメンバー user:alice@example.comserviceAccount:my-other-app@appspot.gserviceaccount.comgroup:admins@example.comdomain:google.com に割り当てられます。objectViewer 役割は 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、Cloud 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 ではアプリ管理者やサービス管理者などの役割が提供されています。従来のオーナー、編集者、閲覧者の役割に加えて、これらの事前定義済みの役割を使用できます。

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

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

次のステップ

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

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

Cloud IAM のドキュメント