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

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

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

前提条件

背景

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

リソース階層

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

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

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

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

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

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

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

例: Cloud Pub/Sub

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

次の図は、上記の例を示しています。

Pub/Sub の例

オーナー、編集者、閲覧者の役割は入れ子構造になっています。つまり、オーナーの役割には編集者の役割の権限が含まれており、編集者の役割には閲覧者の役割の権限が含まれています。権限が広範囲な役割と限定的な役割(編集者と閲覧者など)の両方を 1 人のユーザーに付与すると、広範囲な役割のみが付与されます。たとえば、bob@gmail.com に対しプロジェクト レベルの編集者の役割を付与し、さらに bob@gmail.com にトピック A の閲覧者の役割を付与した場合、そのユーザーにはトピック 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 の例

ベスト プラクティス

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

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

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

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

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

  • Cloud IAM ポリシーで使用している Google グループのオーナー権限を制御してください。

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

  • 子リソースに設定したポリシーで親リソースに付与されたアクセス権を制限することはできない点にご注意ください。それぞれのリソースに付与されたポリシーを確認し、階層継承を把握しておいてください。

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

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

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

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

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

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

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

Cloud IAM のドキュメント