概要

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

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

IAM

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

また Cloud IAM は Cloud Identity-Aware Proxy(Cloud IAP)と連携して、アプリケーションへのアクセスを保護します。Cloud IAP については、Cloud Identity-Aware Proxy の概要をご覧ください。

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 ドメインは、1 つの組織内のすべてのメンバーの仮想グループを表します。G Suite のユーザーはメール アカウントをインターネット ドメイン名と関連付けることができます。関連付ける際に、各メール アカウントは username@yourdomain.com の形式をとります。G Suite アカウントに関連付けられている任意のインターネット ドメイン名を使用することによって、ID を指定できます。

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

Cloud Identity ドメイン

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

allAuthenticatedUsers

これは、Google アカウントまたはサービス アカウントで認証されたユーザー全員を表す特殊な識別子です。

allUsers

これは、Google アカウントの有無を問わず、インターネット上の全員を表す特殊な識別子です。API の中には、サービスにアクセスするすべてのユーザーの認証を必要とするものがあること、および、その場合、allUsers は認証されたすべてのユーザーの承認のみを表すことに注意してください。

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

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

リソース

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

権限

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

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

役割

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

役割マッピングの権限

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

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

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

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

Cloud IAM で使用できる細かな役割の詳細については、役割についてをご覧ください。

ポリシー

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

IAM ポリシー

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

role はユーザーに割り当てる役割です。roleroles/<name of the role> という形式で指定します。たとえば、roles/ownerroles/editorroles/viewer のようになります。

次のコード スニペットは、Cloud IAM ポリシーの構造を示しています。このポリシーでは、owner の役割を alice@example.comadmins@example.comgoogle.commy-other-app@appspot.gserviceaccount.com に割り当て、viewer の役割を bob@example.com に割り当てます。

{
  "bindings": [
   {
     "role": "roles/owner",
     "members": [
       "user:alice@example.com",
       "group:admins@example.com",
       "domain:google.com",
       "serviceAccount:my-other-app@appspot.gserviceaccount.com"]
   },
   {
     "role": "roles/viewer",
     "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 つだけです。

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

リソース階層

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

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

たとえば上記の図で、topic_a は example-test プロジェクトの下位にある Pub/Sub リソースです。example-test で micah@gmail.com に編集者の役割を付与し、topic_a で song@gmail.com にパブリッシャーの役割を付与した場合、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 では App Engine 管理者やサービス管理者などの役割が提供されています。従来のオーナー、編集者、閲覧者の役割に加えて、これらの事前定義済みの役割を使用できます。

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

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

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

次のステップ

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

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

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