リソース階層を使用したアクセス制御

Google Cloud リソースは階層別にまとめられています。組織ノードが階層のルートノードで、プロジェクトは組織の子ノード、その他のリソースはプロジェクトの子孫になります。許可ポリシーは、リソース階層のさまざまなレベルに設定できます。リソースは親リソースの許可ポリシーを継承します。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーとその親リソースから継承された許可ポリシーを組み合わせたものです。

この記事では、許可ポリシーの継承の仕組みを示す例をいくつか紹介し、Identity and Access Management(IAM)のデプロイ時にリソースを作成する際に考慮する必要があるベスト プラクティスについて説明します。

前提条件

背景

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

階層の上から順に、組織、フォルダ、プロジェクト、サービス固有のリソースがあります。

IAM では、リソース階層の次のレベルで許可ポリシーを設定できます。

  • 組織レベル。組織リソースは会社を表しています。このレベルで付与された IAM ロールは、組織内のすべてのリソースに継承されます。詳しくは、IAM を使用した組織のアクセス制御をご覧ください。

  • フォルダレベル。フォルダ内には、プロジェクトや他のフォルダが存在します。最上位のフォルダレベルで付与されたロールは、親フォルダに含まれているプロジェクトやその他のフォルダに継承されます。詳しくは、IAM を使用したフォルダのアクセス制御をご覧ください。

  • プロジェクト レベル。プロジェクトは組織内の信頼境界を表します。同一プロジェクト内のサービスには、デフォルトの信頼レベルが設定されています。プロジェクト レベルで付与された IAM のロールは、そのプロジェクト内のリソースに継承されます。詳細については、IAM を使用したプロジェクトのアクセス制御をご覧ください。

  • リソースレベル。既存の Cloud Storage と BigQuery ACL システムに加えて、Pub/Sub トピックや Compute Engine インスタンスなどの追加のリソースでは低レベルのロールがサポートされます。これにより、プロジェクト内の単一のリソースに特定のユーザー権限を付与できます。

許可ポリシーは階層構造になっており、階層の上から下に伝播されます。リソースで有効な許可ポリシーは、そのリソースに設定された許可ポリシーとその親リソースから継承された許可ポリシーを組み合わせたものです。

次の例は、許可ポリシーの継承が実際にどのように機能するかを示しています。

例: Pub/Sub

Pub/Sub では、トピックとサブスクリプションがプロジェクト内のリソースとなります。project_1 の下にトピック topic_a があるとします。Kalani に編集者のロールを付与する許可ポリシーを project_1 で設定し、Nur にパブリッシャーのロールを付与する許可ポリシーを topic_a で設定すると、topic_a の編集者のロールを Kalani に、パブリッシャーのロールを Nur に付与できます。

以下の図は、上記の例を表しています。

Pub/Sub の例。

継承されたロールにプリンシパルに必要なすべての権限がすでに付与されている場合は、リソース自体に追加のロールを付与する必要はありません。同じ権限またはそれ以下の権限を含む別のロールを付与することは冗長であり、効果はありません。

たとえば、オーナー、編集者、閲覧者の基本ロールについて考えてみましょう。オーナー、編集者、閲覧者の各ロールは入れ子構造になっています。つまり、オーナーロールには編集者ロールの権限が含まれており、編集者ロールには閲覧者ロールの権限が含まれています。そのため、Kalani にプロジェクト レベルで編集者のロールを付与する場合、topic_a に対する閲覧者のロールを付与することは冗長です。これは、Kalani が、プロジェクトの許可ポリシーから継承された編集者のロールを通じて、閲覧者のロールのすべての権限をすでに持っているためです。

以下の図は、上記の例を表しています。

Pub/Sub の例。

例: Cloud Storage

Cloud Storage では、バケットとオブジェクトがリソースであり、オブジェクトがバケットに格納されます。Cloud Storage で IAM を使用する例として、アップロードされたファイルへの読み取りアクセスを許可する場合があります。

1 つのシナリオを考えてみましょう。多くのユーザーがファイルをバケットにアップロードしますが、他のユーザーがアップロードしたファイルの読み取りや削除を行うのは不適切です。データ処理担当者にはアップロードされたファイルの読み取りと削除を許可すべきですが、バケットを削除させるべきではありません。これは、他のユーザーが自分のファイルをアップロードする場所としてそのバケットを使用しているためです。このシナリオではプロジェクトの許可ポリシーを次のように設定します。

  • データ処理担当者である Nur に ストレージ オブジェクト管理者ロールroles/storage.objectAdmin)を付与します。このロールにより、Nur はプロジェクト内の任意のバケット内の任意のオブジェクトの読み取り、追加、削除を行うことができます。
  • data-uploaders グループに ストレージ オブジェクト作成者のロールroles/storage.objectCreator)を付与します。このロールにより、グループ メンバーはバケットにファイルをアップロードできますが、他のユーザーがアップロードしたファイルを読み取ったり削除したりすることはできません。

以下の図は、上記の例を表しています。

Cloud Storage の例。

例: Compute Engine

通常、大企業ではネットワークとセキュリティのリソース(ファイアウォールなど)の管理は開発チームとは別の専門チームが行います。開発チームは、インスタンスを起動してプロジェクトのインスタンスに関連する操作を実行するうえで柔軟性を必要とする場合があります。

このような状況では、許可ポリシーを次のように構成できます。

  • ネットワーク管理者とセキュリティ管理者の Kalani に、組織レベルで Compute ネットワーク管理者のロールroles/compute.networkAdmin)を付与します。このロールにより、Kalani は組織内のネットワーク リソースと、その組織内のプロジェクトに変更を加えることができます。
  • プロジェクト project_2 の開発チームリードである Nur に Compute インスタンス管理者のロールroles/compute.instanceAdmin)を付与します。このロールにより、Nur はインスタンスに対して任意のアクションを実行できますが、プロジェクトに関連付けられたネットワーク リソースに変更を加えることはできません。ただし、他のプロジェクトのネットワーク リソースを変更することはできません。

Compute Engine の例。

継承されたポリシーを表示する権限

親リソースから継承された 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() 呼び出しが記録されるため、許可ポリシーがいつ作成または変更されたかを追跡できます。

  • 許可ポリシーで使用しているグループの所有権とメンバーシップを監査してください。

  • 組織内でプロジェクトの作成を制限する必要がある場合は、組織のアクセス ポリシーを変更して、管理対象のグループにプロジェクト作成者のロールを付与してください。