Google Cloud には Identity and Access Management（IAM）機能があり、特定の Google Cloud リソースに対するアクセス権を詳細に設定できるため、他のリソースへの不要なアクセスを防ぐことができます。IAM を使用すると、セキュリティに関する最小権限の原則を導入できるため、リソースに対する必要なアクセス権のみを付与できます。
IAM では、IAM ポリシーを設定して、誰（どのユーザー）に、どのリソースに対するどのアクセス権（役割）を付与するかを制御することができます。IAM ポリシーは、特定の役割をユーザーに付与することで、そのユーザーに特定の権限を付与します。
このページでは、フォルダレベルで使用可能な IAM ロールについて説明し、さらに、Cloud Resource Manager API を使用してフォルダの IAM ポリシーを作成して管理する方法について説明します。IAM の詳細については、IAM のドキュメントをご覧ください。特に、アクセス権の付与、変更、取り消しをご覧ください。
Folders の IAM 役割の概要
IAM 役割を簡単に設定できるように、以下の表に次の項目を示します。
- 有効にするアクションのタイプ
- アクションの実行に必要な役割
- 役割の適用が必要なリソースレベル
| アクションのタイプ | 必要な役割 | リソースレベル |
|---|---|---|
| 組織リソース全体のフォルダの管理 | フォルダ管理者 | 組織リソース |
| 1 つのフォルダと、そのフォルダに含まれるすべてのプロジェクトとフォルダを管理する | フォルダ管理者 | 特定のフォルダ |
| フォルダの IAM ポリシーにアクセスして管理する | フォルダ IAM 管理者 | 特定のフォルダ |
| 新しいフォルダを作成する | フォルダ作成者 | 新しいフォルダの場所の親リソース |
| フォルダとプロジェクトを移動する | フォルダ移動 | 元のフォルダと新しいフォルダの両方の場所の親リソース |
| プロジェクトを新しいフォルダに移動する | プロジェクト編集者またはプロジェクト オーナー | 元のプロジェクトと新しいプロジェクトの両方の場所の親リソース |
| フォルダを削除する | フォルダ編集者またはフォルダ管理者 | 特定のフォルダ |
フォルダで IAM 役割と権限を使用する場合のベスト プラクティス
フォルダで使用する IAM 役割と権限を割り当てる場合には、次の点に注意してください。
- 可能な限り、グループでプリンシパルを管理してください。
- オーナー、編集者、閲覧者など、基本的なロールの使用は最小限にとどめてください。その代わりに、最小権限の原則に従うために事前定義済みの役割を使用します。
- フォルダ全体を管理するには、フォルダレベルで権限を割り当て、権限がプロジェクトで自動的に継承されるようにしてください。たとえば、部門の管理者グループには、フォルダに対するフォルダ管理者の役割を割り当てます。部門全体の権限を必要とするネットワーク管理者には、フォルダに対するネットワーク管理者の役割を割り当てます。
- リソースをフォルダから移動する前に、権限がどのように変更されるかを慎重に確認してください。そうしないと、そのリソースへの権限を必要とする既存のアプリやワークフローが機能しなくなるおそれがあります。
- フォルダに含まれる本番環境のプロジェクトを移動する前に、慎重に計画を立ててリソース階層をテストしてください。このテストを行うには、あらかじめ組織リソースの下にテストフォルダを作成し、対象となる階層のプロトタイプを作成する方法があります。
- フォルダレベルでユーザーにロールを付与すると、そのフォルダの下にあるすべてのリソースに対してもそのロールがユーザーに付与されます。たとえば、ユーザーにフォルダに対する Compute 管理者のロール（
roles/compute.admin）を付与した場合、そのユーザーは、そのフォルダ内のすべてのプロジェクトの Compute Engine リソースを完全に制御できます。
フォルダのロールと権限について
デフォルトの役割
フォルダを作成すると、作成者として完全に制御できるようにするために、フォルダのフォルダ管理者とフォルダ編集者の役割が与えられます。これらの役割が提供する権限については、以下をご覧ください。これらのデフォルトのロールは、IAM ポリシーで通常どおり変更できます。
事前定義ロールの使用
| ロール | 権限 |
|---|---|
フォルダ管理者（ フォルダの操作に関するすべての権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
フォルダ IAM 管理者（ フォルダの許可ポリシーを管理する権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
フォルダ作成者（ 階層の参照とフォルダの作成に必要な権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
フォルダ編集者（ フォルダの変更と、フォルダの許可ポリシーの表示ができる権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
フォルダ移動（ 親の組織またはフォルダとの間でフォルダを移動する権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
フォルダ閲覧者（ フォルダの取得、リソース内のフォルダとプロジェクトの一覧表示ができる権限を付与します。 このロールを付与できる最下位レベルのリソース:
|
|
カスタムロールの作成
このトピックで説明した事前定義の役割を使用するだけでなく、必要に応じて権限を調整してカスタムロールを作成することもできます。Resource Manager で使用するカスタムロールを作成する場合には、次の点に注意してください。resourcemanager.projects.get/listなどのリスト権限と取得権限は、必ずペアで付与する必要があります。- カスタムロールに
folders.list権限とfolders.get権限を含める場合は、projects.listとprojects.getも含める必要があります。 - 組織、フォルダ、プロジェクト リソースに対する
setIamPolicy権限を使用すると、ユーザーに他のすべての権限も付与されます。この権限を割り当てる場合には十分に注意してください。
フォルダの閲覧を許可する役割の付与
リスト権限を使用すると、フォルダの閲覧を許可できます。通常、次の 2 種類のリスト権限の付与が必要となります。1 つは resourcemanager.folders.list で、リソース内にフォルダのリスト作成を許可します。もう 1 つは resourcemanager.projects.list で、組織リソースまたはフォルダ内のプロジェクトの閲覧を許可します。組織管理者は、この両方の権限で初期化されます。組織管理者の役割が割り当てられていないユーザーの場合、次のようになります。
resourcemanager.folders.listは、フォルダ閲覧者とフォルダ編集者の役割により付与できます。resourcemanager.projects.listは、閲覧者または参照者の役割により付与できます。
組織リソースのプリンシパルが組織のリソース階層全体を閲覧できるようにするには、組織リソースレベルでリスト権限を付与する必要があります。
フォルダの作成を許可する役割の付与
フォルダの作成を行うユーザーには、フォルダの作成場所より上の階層にあるリソースでフォルダ作成者の役割を付与する必要があります。フォルダ作成権限と一緒に閲覧権限を付与すると、階層内でフォルダを作成する場所に効率的に移動できるようになります。閲覧権限の詳細については、上のセクションをご覧ください。
フォルダ作成者は、ユーザーにフォルダの削除権限を付与しません。ただし、フォルダを作成したユーザーにはフォルダ編集者の役割が自動的に付与されます。フォルダ編集者の役割があればフォルダを削除できます。
フォルダの移動を許可する役割の付与
親のリソースから別のリソースにフォルダを移動するには、移動元と移動先の両方の親リソースまたは共通の祖先に対してフォルダ移動の役割が必要です。
プロジェクトの移動を許可する役割の付与
プロジェクトをフォルダに移動するには、そのプロジェクトに対してプロジェクト編集者またはプロジェクト オーナーの役割が必要です。また、移動元と移動先の親のプロジェクト リソースに対してプロジェクト移動の役割が必要です。
組織が所有していないプロジェクトを組織リソースに移動する場合には、要件が若干異なります。この場合、プロジェクトに対してプロジェクト編集者またはプロジェクト所有者の役割が必要となります。また、組織リソースに対してプロジェクト作成者の役割が必要です。
プロジェクトの作成を許可するフォルダ固有の役割の付与
プロジェクトを作成するには、プロジェクト作成の役割が必要です。ただし、組織全体にプロジェクト作成権限を付与するのではなく、特定のフォルダ内のプロジェクトのみを表示または作成できるように制限するほうが便利です。
フォルダ固有の権限を付与するには:
- 組織ノードレベル（たとえば、domain.com）でユーザーに組織閲覧者役割を付与します。
- 新しいフォルダを作成します。
- フォルダレベルでユーザーを IAM に追加し、フォルダ閲覧者とプロジェクト作成者の役割を付与します。
これにより、大規模な組織リソースのすべてのプロジェクトを閲覧できる権限を付与することなく、特定のフォルダ内でのプロジェクト作成をユーザーに許可できます。