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

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

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

前提条件

バックグラウンド

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

リソース階層

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

  • 組織レベル。組織リソースは会社を表しています。このレベルで付与された IAM の役割は、その組織内のすべてのリソースによって継承されます。

  • プロジェクト レベル。プロジェクトは組織内の信頼境界を表します。同じプロジェクト内のサービスには、信頼のデフォルト レベルがあります。たとえば、App Engine インスタンスは同じプロジェクト内の Cloud Storage バケットにアクセスできます。プロジェクト レベルで付与された 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 にはプロジェクト レベルでオブジェクト管理者の権限が付与されるため、Alice はプロジェクトのすべてのバケット内のすべてのオブジェクトを読み取り、追加、削除できます。
  • ストレージのオブジェクト作成者を、ユーザー グループ(data_uploaders@example.com)に付与します。
    • このポリシーでは、data_uploaders@example.com のメンバーであれば誰でもファイルをバケットにアップロードできます。
    • グループ メンバーは、自分がアップロードしたファイルを所有しますが、他のユーザーがアップロードしたファイルを読み取ったり削除したりできません。

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

Cloud Storage の例

例: Compute Engine

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

Cloud Storage の例

おすすめの方法

  • IAM ポリシーの階層構造には、組織の構造を反映させてください。IAM ポリシーの階層には、会社の組織構造(新興企業、中小企業、大企業など)が反映されている必要があります。新興企業であれば、まず組織リソースなしの一律の階層構造にします。プロジェクトの協力者やプロジェクト数が増えてきたら、組織リソースを導入する効果を期待できるようになります。組織リソースの使用は、複数の部門やチームがあり、各チームがチーム固有のアプリケーションやサービスの責任を負う形態の大企業の場合に推奨されます。

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

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

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

  • 可能なときは、個々のユーザーではなく Google グループに対して役割を付与してください。ユーザーを追加または削除する場合、Cloud IAM ポリシーを変更するよりも Google グループにおいてそのユーザーを追加または削除するほうが簡単です。

  • IAM ポリシーで使用している Google グループの所有権を管理してください。

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

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

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

  • ラベルを使って、リソースの注釈追加、グループ化、フィルタリングを行ってください。

  • ポリシーを監査してコンプライアンスを確保してください。クラウド監査ログには、setIamPolicy へのすべての呼び出しが記録されているため、ポリシーがいつ実行されたかを追跡することができます。

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

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

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

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

Cloud Identity and Access Management のドキュメント