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

Google Cloud のリソースは階層別にまとめられています。組織ノードが階層のルートノードで、プロジェクトは組織の子ノード、その他のリソースはプロジェクトの子孫となります。Identity and Access Management(IAM)ポリシーは、リソース階層のさまざまなレベルに設定できます。各リソースは親リソースのポリシーを継承します。リソースで有効なポリシーは、そのリソースに設定されたポリシーとその親リソースから継承されたポリシーの和です。

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

前提条件

背景

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

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

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

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

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

  • プロジェクト レベル。プロジェクトは組織内の信頼境界を表します。同じプロジェクト内のサービスには、デフォルトの信頼レベルがあります。たとえば、App Engine インスタンスは同じプロジェクト内の Cloud Storage バケットにアクセスできます。プロジェクト レベルで付与された IAM のロールは、そのプロジェクト内のリソースに継承されます。詳しくは、IAM を使用したプロジェクトのアクセス制御をご覧ください。

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

IAM ポリシーは階層構造になっており、階層の上から下に伝播されます。リソースで有効なポリシーは、そのリソースに設定されたポリシーとその親リソースから継承されたポリシーの和です。

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

例: Pub/Sub

Pub/Sub では、トピックとサブスクリプションがプロジェクト内のリソースとなります。たとえばプロジェクト A 内にトピック A がある場合、bob@example.com に編集者の役割を付与するポリシーをプロジェクト A で設定し、alice@example.com にパブリッシャーの役割を付与するポリシーをトピック A で設定すれば、トピック A の編集者の役割を bob@example.com に、パブリッシャーの役割を alice@example.com に効率的に付与できます。

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

Pub/Sub の例。

オーナー、編集者、閲覧者の役割は入れ子構造になっています。つまり、オーナーの役割には編集者の役割の権限が含まれており、編集者の役割には閲覧者の役割の権限が含まれています。権限が広範囲な役割と限定的な役割(編集者と閲覧者など)の両方を 1 人のユーザーに付与すると、広範囲な役割のみが付与されます。たとえば、トピック A の編集者の役割をプロジェクト レベルで bob@example.com に付与し、トピック A の閲覧者の役割を bob@example.com に付与した場合、Bob にはトピック A の編集者の役割が付与されます。これは、プロジェクト A に設定したポリシーが継承され、そのユーザーに対しトピック A の編集者の役割がすでに付与されているためです。

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

Pub/Sub の例。

例: Cloud Storage

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

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

  • ストレージ オブジェクト管理者の役割をデータ処理担当者である Alice(alice@example.com)に付与します。
    • Alice にはプロジェクト レベルのオブジェクト管理者権限があるので、プロジェクトのすべてのバケット内のすべてのオブジェクトの読み取り、追加、削除ができます。
  • ストレージ オブジェクト作成者の役割をユーザー グループ data_uploaders@example.com に付与します。
    • このポリシーでは、data_uploaders@example.com のメンバーであれば誰でもファイルをバケットにアップロードできます。
    • グループ メンバーは、自分がアップロードしたファイルのオーナーとなりますが、他のユーザーがアップロードしたファイルの読み取りや削除はできません。

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

Cloud Storage の例。

例: Compute Engine

通常、大企業ではネットワークとセキュリティのリソース(ファイアウォールなど)の管理は開発チームとは別の専門チームが行います。開発チームは、インスタンスを起動してプロジェクトのインスタンスに関連する操作を実行するうえで柔軟性を必要とする場合があります。bob@example.com に対して組織レベルの Compute ネットワーク管理者の役割を付与し、alice@example.com に対してプロジェクト project_2 の Compute インスタンス管理者の役割を付与すると、Alice はインスタンスに対するあらゆる操作を行うことができますが、そのプロジェクトに関連付けられたネットワーク リソースに変更を加えることはできません。この場合、Bob だけが組織内のネットワーク リソースやその組織内のプロジェクトに変更を加えることができます。

Cloud Storage の例。

おすすめ

  • Google Cloud のリソース階層構造に組織の構造を反映させてください。たとえば、Google Cloud のリソース階層に、新興企業、中小企業、大企業といった組織の構成を反映させます。新興企業であれば、組織リソースがないフラットなリソース階層構造からスタートします。プロジェクトの協力者やプロジェクトの数が増えてきてはじめて、組織リソースを導入する意味が生まれます。複数の部門やチームがあり、それぞれが独自のアプリケーションやサービスのセットを運用している大企業では、組織リソースの使用が推奨されます。

  • プロジェクトを使用して、同じ信頼境界を共有するリソースをグループ化してください。たとえば、同じプロダクトやマイクロサービスのリソースは、同じプロジェクトに含めることができます。

  • リソースレベルではなく、組織レベルまたはプロジェクト レベルでポリシーを設定してください。新しいリソースが追加されたとき、それらが親リソースからポリシーを自動的に継承すると便利です。たとえば、新しい仮想マシンが自動スケーリングによってプロジェクトに追加されたときに、それらが自動的にプロジェクトのポリシーを継承するようにします。

    ポリシーを設定する方法については、アクセス権の付与、変更、取り消しをご覧ください。

  • 可能であれば、個々のユーザーではなく Google グループにロールを付与してください。IAM ポリシーを更新するより、Google グループのメンバーを管理するほうが簡単です。IAM ポリシーで使用している Google グループのオーナー権限を制御してください。

    Google グループを管理する方法については、Google グループヘルプをご覧ください。

  • 最小権限のセキュリティ原則に従って IAM のロールを付与してください。これは、リソースが必要とする最小限のアクセス権限を付与するということです。

    適切な事前定義ロールを確認するには、事前定義ロールのリファレンスをご覧ください。適切な事前定義ロールがない場合は、独自のカスタムロールを作成することもできます。

  • 必要最小限の範囲の役割を付与してください。たとえば、Pub/Sub トピックでメッセージをパブリッシュするアクセス権だけを必要とするユーザーには、そのトピックのパブリッシャーのロールを付与します。

  • 子リソースのポリシーは親リソースから継承されることにご注意ください。たとえば、プロジェクトのポリシーでユーザーに Compute Engine 仮想マシン(VM)インスタンスを管理する権限が付与されている場合、ユーザーは各 VM で設定したポリシーに関係なく、そのプロジェクトのすべての Compute Engine VM を管理できます。

  • 複数のプロジェクトにまたがるロールをユーザーやグループに付与する必要がある場合は、プロジェクト レベルではなくフォルダレベルでそのロールを設定してください。

  • ラベルを使って、リソースのアノテーション付け、グループ化、フィルタリングを行ってください。

  • ポリシーを監査してコンプライアンスを確保してください。監査ログにはすべての setIamPolicy() 呼び出しが記録されるため、ポリシーがいつ作成または変更されたかを追跡できます。

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

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