Google Cloud のリソースは階層別にまとめられています。組織ノードが階層のルートノードで、プロジェクトは組織の子ノード、その他のリソースはプロジェクトの子孫になります。許可ポリシーは、リソース階層のさまざまなレベルに設定できます。リソースは親リソースの許可ポリシーを継承します。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーとその親リソースから継承された許可ポリシーを組み合わせたものです。
この記事では、許可ポリシーの継承の仕組みを示す例をいくつか紹介し、Identity and Access Management（IAM）のデプロイ時にリソースを作成する際に考慮する必要があるベスト プラクティスについて説明します。
前提条件
- IAM の基本コンセプト、特に Google Cloud リソース階層を理解していること。
背景
次の図に、Google Cloud のリソース階層の例を示します。
IAM では、リソース階層の次のレベルで許可ポリシーを設定できます。
組織レベル。組織リソースは会社を表しています。このレベルで付与された IAM ロールは、組織内のすべてのリソースに継承されます。詳しくは、IAM を使用した組織のアクセス制御をご覧ください。
フォルダレベル。フォルダ内には、プロジェクトや他のフォルダが存在します。最上位のフォルダレベルで付与されたロールは、親フォルダに含まれているプロジェクトやその他のフォルダに継承されます。詳しくは、IAM を使用したフォルダのアクセス制御をご覧ください。
プロジェクト レベル。プロジェクトは組織内の信頼境界を表します。同一プロジェクト内のサービスには、デフォルトの信頼レベルが設定されています。プロジェクト レベルで付与された IAM のロールは、そのプロジェクト内のリソースに継承されます。詳細については、IAM を使用したプロジェクトのアクセス制御をご覧ください。
リソースレベル。既存の Cloud Storage と BigQuery ACL システムに加えて、Pub/Sub トピックや Compute Engine インスタンスなどの追加のリソースでは低レベルのロールがサポートされます。これにより、プロジェクト内の単一のリソースに特定のユーザー権限を付与できます。
許可ポリシーは階層構造になっており、階層の上から下に伝播されます。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーとその親リソースから継承された許可ポリシーを組み合わせたものです。
次の例は、許可ポリシーの継承が実際にどのように機能するかを示しています。
例: Pub/Sub
Pub/Sub では、トピックとサブスクリプションがプロジェクト内のリソースとなります。たとえばプロジェクト 1 内にトピック A がある場合、bob@example.com に編集者のロールを付与する許可ポリシーをプロジェクト 1 で設定し、alice@example.com にパブリッシャーのロールを付与する許可ポリシーをトピック A で設定すれば、トピック A の編集者のロールを bob@example.com に、パブリッシャーのロールを alice@example.com に効率的に付与できます。
以下の図は、上記の例を表しています。
オーナー、編集者、閲覧者の役割は入れ子構造になっています。つまり、オーナーの役割には編集者の役割の権限が含まれており、編集者の役割には閲覧者の役割の権限が含まれています。権限が広範囲な役割と限定的な役割（編集者と閲覧者など）の両方を 1 人のユーザーに付与すると、広範囲な役割のみが付与されます。たとえば、トピック A の編集者の役割をプロジェクト レベルで bob@example.com に付与し、トピック A の閲覧者の役割を bob@example.com に付与した場合、Bob にはトピック A の編集者の役割が付与されます。これは、プロジェクト A に設定した許可ポリシーが継承され、Bob に対してトピック A の編集者のロールがすでに付与されているためです。
以下の図は、上記の例を表しています。
例: Cloud Storage
Cloud Storage では、バケットとオブジェクトがリソースであり、オブジェクトがバケットに格納されます。Cloud Storage で IAM を使用する例として、アップロードされたファイルへの読み取りアクセスを許可する場合があります。
1 つのシナリオを考えてみましょう。多くのユーザーがファイルをバケットにアップロードしますが、他のユーザーがアップロードしたファイルの読み取りや削除を行うのは不適切です。データ処理担当者にはアップロードされたファイルの読み取りと削除を許可すべきですが、バケットを削除させるべきではありません。これは、他のユーザーが自分のファイルをアップロードする場所としてそのバケットを使用しているためです。このシナリオではプロジェクトの許可ポリシーを次のように設定します。
- ストレージ オブジェクト管理者のロールをデータ処理担当者である Alice（alice@example.com）に付与します。
- Alice にはプロジェクト レベルのオブジェクト管理者権限があるので、プロジェクトのすべてのバケット内のすべてのオブジェクトの読み取り、追加、削除ができます。
- ストレージ オブジェクト作成者のロールをユーザー グループ data_uploaders@example.com に付与します。
- この許可ポリシーでは、data_uploaders@example.com のグループ メンバーであれば誰でもファイルをバケットにアップロードできます。
- グループ メンバーは、自分がアップロードしたファイルのオーナーとなりますが、他のユーザーがアップロードしたファイルの読み取りや削除はできません。
以下の図は、上記の例を表しています。
例: Compute Engine
通常、大企業ではネットワークとセキュリティのリソース（ファイアウォールなど）の管理は開発チームとは別の専門チームが行います。開発チームは、インスタンスを起動してプロジェクトのインスタンスに関連する操作を実行するうえで柔軟性を必要とする場合があります。bob@example.com に対して組織レベルの Compute ネットワーク管理者の役割を付与し、alice@example.com に対してプロジェクト project_2 の Compute インスタンス管理者の役割を付与すると、Alice はインスタンスに対するあらゆる操作を行うことができますが、そのプロジェクトに関連付けられたネットワーク リソースに変更を加えることはできません。この場合、Bob だけが組織内のネットワーク リソースやその組織内のプロジェクトに変更を加えることができます。
継承されたポリシーを表示する権限
親リソースから継承された IAM ポリシーを表示するには、親リソースの IAM ポリシーを表示する権限が必要です。たとえば、プロジェクトで継承されたすべての IAM ポリシーを表示するには、プロジェクトの親組織の IAM ポリシーを表示する権限と、親フォルダの IAM ポリシーを表示する権限が必要です。
親リソースから継承された IAM ポリシーの表示に必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。
- 組織から継承された IAM ポリシーを表示する: 該当する組織の組織管理者（
roles/resourcemanager.organizationAdmin） - フォルダから継承された IAM ポリシーを表示する: 該当するフォルダのフォルダ管理者（
roles/resourcemanager.folderAdmin） - プロジェクトから継承された IAM ポリシーを表示する: 該当するプロジェクトのプロジェクト IAM 管理者（
roles/resourcemanager.projectIamAdmin）
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
これらの事前定義ロールには、親リソースから継承された IAM ポリシーを表示するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。
必要な権限
親リソースから継承された IAM ポリシーを表示するには、次の権限が必要です。
-
組織から継承された IAM ポリシーを表示する: 該当する組織の
resourcemanager.organizations.getIamPolicy -
フォルダから継承された IAM ポリシーを表示する: 該当するフォルダの
resourcemanager.folders.getIamPolicy -
プロジェクトから継承された IAM ポリシーを表示する: 該当するプロジェクトの
resourcemanager.projects.getIamPolicy
カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。
おすすめの方法
Google Cloud のリソース階層構造に組織の構造を反映させてください。たとえば、Google Cloud のリソース階層に、新興企業、中小企業、大企業といった組織の構成を反映させます。新興企業であれば、組織リソースがないフラットなリソース階層構造からスタートします。プロジェクトの協力者やプロジェクトの数が増えてきてはじめて、組織リソースを導入する意味が生まれます。複数の部門やチームがあり、それぞれが独自のアプリケーションやサービスのセットを運用している大企業では、組織リソースの使用が推奨されます。
プロジェクトを使用して、同じ信頼境界を共有するリソースをグループ化してください。たとえば、同じプロダクトやマイクロサービスのリソースは、同じプロジェクトに含めることができます。
可能であれば、個々のユーザーではなくグループにロールを付与してください。許可ポリシーを更新するよりも、グループのメンバーを管理するほうが簡単です。許可ポリシーで使用しているグループのオーナー権限を制御してください。
Google グループを管理する方法については、Google グループヘルプをご覧ください。
最小権限のセキュリティ原則に従って IAM のロールを付与してください。これは、リソースが必要とする最小限のアクセス権限を付与するということです。
適切な事前定義ロールを確認するには、事前定義ロールのリファレンスをご覧ください。適切な事前定義ロールがない場合は、独自のカスタムロールを作成することもできます。
必要最小限の範囲のロールを付与します。たとえば、Pub/Sub トピックでメッセージをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーの役割を付与します。
子リソースの許可ポリシーは、親リソースの許可ポリシーを継承します。たとえば、プロジェクトの許可ポリシーでユーザーに Compute Engine 仮想マシン（VM）インスタンスを管理する権限が付与されている場合、ユーザーは各 VM で設定した許可ポリシーに関係なく、そのプロジェクトのすべての Compute Engine VM を管理できます。
すべてのプロジェクトで、少なくとも 2 つのプリンシパルがオーナーのロール（
roles/owner）を持っていることを確認します。または、2 つ以上のプリンシパルを含むグループにオーナーのロールを付与します。この方法により、プリンシパルの 1 つが退職しても、引き続きプロジェクトを管理できます。
複数のプロジェクトにまたがる役割をユーザーやグループに付与する必要がある場合は、プロジェクト レベルではなくフォルダレベルでその役割を設定してください。
ラベルを使って、リソースのアノテーション付け、グループ化、フィルタリングを行ってください。
許可ポリシーを監査してコンプライアンスを確保してください。監査ログにはすべての
setIamPolicy()呼び出しが記録されるため、許可ポリシーがいつ作成または変更されたかを追跡できます。許可ポリシーで使用しているグループの所有権とメンバーシップを監査してください。
組織内でプロジェクトの作成を制限する必要がある場合は、組織のアクセス ポリシーを変更して、管理対象のグループにプロジェクト作成者のロールを付与してください。