このページは Cloud Translation API によって翻訳されました。

IAM の概要

このページでは、 Google Cloudの Identity and Access Management（IAM）システムの仕組みと、IAM を使用して Google Cloudでアクセスを管理する方法について説明します。

IAM は、Google Cloudのきめ細かい認可を管理するためのツールです。つまり、どのリソースで誰が何をできるかを制御できます。

Google Cloudでのアクセス

Google Cloud のすべてのアクションには特定の権限が必要です。ユーザーが Google Cloudでアクション（VM インスタンスの作成やデータセットの表示など）を実行しようとすると、IAM はまず、ユーザーに必要な権限があるかどうかを確認します。ない場合、IAM はアクションの実行をブロックします。

IAM でユーザーに権限を付与するには、次の 3 つのコンポーネントが必要です。

プリンシパル: 権限を付与するユーザーまたはシステムの ID
ロール: プリンシパルに付与する権限のコレクション
リソース: プリンシパルがアクセスできるようにするリソース Google Cloud

プリンシパルにリソースへのアクセス権を付与するには、リソースに対するロールを付与します。これらのロールは、許可ポリシーを使用して付与します。

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

プリンシパル

Google Cloud では、プリンシパルのアクセスを制御します。プリンシパルは、 Google Cloudに対して認証された 1 つ以上の ID を表します。

これまで、プリンシパルはメンバーと呼ばれていました。一部の API では、まだこの用語が使用されています。

IAM にはさまざまなタイプのプリンシパルがありますが、大きく 2 つのカテゴリに分けることができます。

人間のユーザー: 一部の IAM プリンシパルタイプは人間のユーザーを表します。これらのプリンシパルタイプは、Google Cloud リソースに対する社員のアクセス権を管理するために使用します。

人間のユーザーを表すプリンシパルタイプには、Google アカウント、Google グループ、Workforce Identity プール内の連携 ID があります。
ワークロード: 一部の IAM プリンシパルタイプはワークロードを表します。これらのプリンシパルタイプは、ワークロードのアクセスGoogle Cloud リソースを管理するときに使用します。

ワークロードを表すプリンシパルタイプには、Workload Identity プール内のサービスアカウントとフェデレーション ID があります。

プリンシパルの詳細については、IAM プリンシパルをご覧ください。

権限とロール

権限によって、リソースに対して許可されているオペレーションが決まります。IAM では、権限は通常 service.resource.verb の形式で表されます。多くの場合、権限は REST API メソッドと 1 対 1 で対応しています。たとえば、resourcemanager.projects.list 権限を使用すると、Resource Manager プロジェクトを一覧表示できます。

プリンシパルに直接権限を付与することはできません。代わりに、プリンシパルにロールを付与して権限を付与します。

ロールは、権限をまとめたものである。プリンシパルにロールを付与すると、そのプリンシパルはそのロールのすべての権限を取得します。

ロールには次の 3 種類があります。

事前定義ロール: サービスによって管理されるロール。 Google Cloud これらのロールには、特定のサービスごとに一般的なタスクを実行するために必要な権限が含まれています。たとえば、Pub/Sub パブリッシャーのロール（roles/pubsub.publisher）は、Pub/Sub トピックにメッセージをパブリッシュするためのアクセス権を付与します。
カスタムロール: 指定した権限のみを含むロール。これらのロールの権限は完全に管理できます。ただし、事前定義ロールよりもメンテナンスの負担が高く、プロジェクトと組織で使用できるカスタムロールの数には上限があります。
基本ロール:Google Cloud サービスへの幅広いアクセス権を付与する、非常に許可が緩いロール。これらのロールはテスト目的には便利ですが、本番環境では使用しないでください。

ロールと権限の詳細については、ロールと権限をご覧ください。

リソース

ほとんどの Google Cloud サービスには独自のリソースがあります。たとえば、Compute Engine には、インスタンス、ディスク、サブネットワークなどのリソースがあります。

IAM では、リソースに対するロールを付与します。プリンシパルにリソースに対するロールを付与すると、プリンシパルはそのロールの権限を使用してリソースにアクセスできます。

Google Cloud リソースのサブセットにロールを付与できます。ロールを付与できるリソースの一覧については、許可ポリシーを受け入れるリソースタイプをご覧ください。

Google Cloud には、プロジェクト、フォルダ、組織など、いくつかのコンテナリソースもあります。プリンシパルにコンテナリソースに対するロールを付与すると、プリンシパルはコンテナリソースとそのコンテナ内のリソースにアクセスできるようになります。この機能を使用すると、単一のロールの付与を使用して、プリンシパルに複数のリソースへのアクセス権を付与できます。これには、ロールを直接付与できないリソースも含まれます。詳細については、このページのポリシーの継承をご覧ください。

許可ポリシー

プリンシパルにロールを付与するには、許可ポリシーを使用します。以前、これらのポリシーは IAM ポリシーと呼ばれていました。

許可ポリシーは、リソースに接続されている YAML または JSON オブジェクトです。 Google Cloud

次の図は、許可ポリシーの構造を示しています。

2 つのロールバインディングを含む許可ポリシー。ロールバインディングは、特定のプリンシパルを特定のロールに関連付けます。

各許可ポリシーには、IAM ロールをそれらのロールが付与されたプリンシパルに関連付けるロールバインディングのリストが含まれています。

認証されたプリンシパルがリソースにアクセスしようとすると、IAM はリソースの許可ポリシーをチェックして、プリンシパルに必要な権限があるかどうかを確認します。プリンシパルが、必要な権限を持つロールを含むロールバインディングに属している場合、リソースへのアクセスが許可されます。

許可ポリシーの例とその構造については、許可ポリシーについてをご覧ください。

ポリシーの継承

Google Cloud には、プロジェクト、フォルダ、組織などのコンテナリソースがあり、リソースを親子階層に整理できます。この階層はリソース階層と呼ばれます。

Google Cloud リソース階層の構造は次のとおりです。

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

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

IAM リソースの階層

コンテナリソースに許可ポリシーを設定すると、そのコンテナ内のすべてのリソースにも許可ポリシーが適用されます。子リソースは祖先リソースの許可ポリシーを効果的に継承するため、このコンセプトはポリシーの継承と呼ばれます。

ポリシーの継承には次の意味があります。

1 つのロールバインディングを使用して、複数のリソースへのアクセス権を付与できます。プリンシパルにコンテナ内のすべてのリソースへのアクセス権を付与する場合は、コンテナ内のリソースではなく、コンテナに対するロールを付与します。

たとえば、セキュリティ管理者に組織内のすべてのリソースの許可ポリシーを管理させる場合は、組織に対するセキュリティ管理者ロール（roles/iam.securityAdmin）を付与します。
独自の許可ポリシーがないリソースへのアクセス権を付与できます。すべてのリソースが許可ポリシーを受け入れるわけではないが、すべてのリソースは祖先から許可ポリシーを継承します。独自の許可ポリシーを持てないリソースへのアクセス権をプリンシパルに付与するには、リソースの祖先のいずれかに対するロールを付与します。

たとえば、ログバケットにログを書き込む権限をユーザーに付与するとします。ログバケットには独自の許可ポリシーがないため、この権限をユーザーに付与するには、ログバケットを含むプロジェクトでログバケット書き込みロール（roles/logging.bucketWriter）を付与します。
リソースにアクセスできるユーザーを確認するには、リソースに影響する許可ポリシーをすべて表示する必要があります。リソースにアクセスできるプリンシパルの完全なリストを取得するには、リソースの許可ポリシーとリソースの祖先の許可ポリシーを表示する必要があります。これらのポリシーをすべて結合したものを、有効な許可ポリシーといいます。

許可ポリシーのポリシー継承の詳細については、リソース階層を使用したアクセス制御をご覧ください。

高度なアクセス制御

IAM には、許可ポリシーに加えて、次のアクセス制御メカニズムがあり、どのリソースにアクセスできるユーザーを絞り込むことができます。

その他のポリシータイプ: IAM には、許可ポリシーに加えて、次のポリシータイプがあります。
- 拒否ポリシー: 拒否ポリシーを使用すると、プリンシパルが権限を持つロールを付与されている場合でも、プリンシパルが特定の権限を使用できないようにできます。
- プリンシパルアクセス境界（PAB）ポリシー: プリンシパルアクセス境界ポリシーは、プリンシパルがアクセスできるリソースを定義して適用します。プリンシパルは、リソースに対するロールが付与されている場合でも、アクセス権がないリソースにアクセスできません。
これらのポリシーの詳細については、ポリシーの種類をご覧ください。

IAM Conditions: IAM Conditions を使用すると、条件付きの属性ベースのアクセス制御を定義して適用できます。条件はさまざまなポリシータイプで使用できます。たとえば、許可ポリシーのロールバインディングに条件を追加して、条件が満たされた場合にのみロールが付与されるようにできます。

リクエスト内のリソースやリクエストの時間などの属性に基づいて条件を記述できます。

IAM Conditions の詳細については、IAM Conditions の概要をご覧ください。

Privileged Access Manager（PAM）: Privileged Access Manager を使用すると、プリンシパルがリソースへの一時的な監査可能なアクセス権をリクエストして付与できます。たとえば、プリンシパルに IAM ロールを永続的に付与するのではなく、機密リソースを表示するたびにアクセスをリクエストするように要求できます。

また、プリンシパルがアクセスをリクエストする際に理由を示す必要があるか、承認を得る必要があるかを構成することもできます。

Privileged Access Manager の詳細については、Privileged Access Manager の概要をご覧ください。

IAM API の整合性モデル

IAM API では結果整合性が維持されます。つまり、IAM API を使用してデータを書き込んだ直後にそのデータを読み取ると、読み取りオペレーションで古いデータが返される場合があります。また、加えた変更がアクセスチェックに影響するまでには、時間がかかる場合があります。

この整合性モデルは IAM API の動作に影響します。たとえば、サービスアカウントを作成し、そのすぐ後に別のリクエストでそのサービスアカウントを参照した場合、サービスアカウントが見つからないという結果が返される場合があります。この動作は、オペレーションが結果整合性に基づいているためです。新しいサービスアカウントが読み取りリクエストで利用可能になるまで時間がかかることがあります。

次のステップ

Google Cloudの ID を構成する方法については、 Google Cloudの ID 管理をご覧ください。
プリンシパルに IAM のロールを付与、変更、取り消す方法については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
使用可能な IAM ロールの一覧については、事前定義ロールをご覧ください。
事前定義ロールの選択で、最適な事前定義ロールを選択する方法を確認する。
IAM で使用できるポリシータイプの詳細については、ポリシータイプをご覧ください。

使ってみる

Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

無料で開始