Google Cloud には Identity and Access Management（IAM）機能があり、特定の Google Cloud リソースに対するアクセス権を詳細に設定できるため、他のリソースへの不要なアクセスを防ぐことができます。IAM を使用すると、セキュリティに関する最小権限の原則を導入できるため、リソースに対する必要なアクセス権のみを付与できます。
IAM では、IAM ポリシーを設定して、誰（どのユーザー）に、どのリソースに対するどのアクセス権（役割）を付与するかを制御することができます。IAM ポリシーは、特定の役割をユーザーに付与することで、そのユーザーに特定の権限を付与します。
このページでは、フォルダレベルで使用可能な IAM ロールについて説明し、さらに、Cloud Resource Manager API を使用してフォルダの IAM ポリシーを作成して管理する方法について説明します。IAM の詳細については、IAM のドキュメントをご覧ください。特に、アクセス権の付与、変更、取り消しをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2024-12-21 UTC。"],[],[],null,["# Access control for folders with IAM\n\nGoogle Cloud offers [Identity and Access Management (IAM)](/iam/docs/overview), which\nlets you give more granular access to specific Google Cloud resources and\nprevents unwanted access to other resources. IAM lets you adopt\nthe\n[security principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege),\nso you grant only the necessary access to your resources.\n\nIAM lets you control **who (users)** has **what access (roles)**\nto **which resources** by setting allow policies. Allow policies grant specific\nroles to a user giving the user certain permissions.\n\nThis page explains the IAM roles that are available at the\nFolders level, and how to create and manage allow policies for folders\nusing the Cloud Resource Manager API. For more information, see\n[Manage access to projects, folders, and organizations](/iam/docs/granting-changing-revoking-access).\n\n\n| **Note:** You can also use deny policies to prevent principals from using specific IAM permissions. For more information, see [Deny\n| policies](/iam/docs/deny-overview).\n\n\u003cbr /\u003e\n\n| **Note:** If you're getting started with Google Cloud, you can set up your resource hierarchy and grant initial access as part of the [Google Cloud setup process](/docs/enterprise/setup-checklist).\n\nOverview of IAM roles for Folders\n---------------------------------\n\nTo help you configure your IAM roles, the following table lists:\n\n- The type of actions you want to enable\n- The roles required to perform those actions\n- The resource level on which you need to apply those roles\n\n| **Note:** Allow policies are additive and inherited down the hierarchy. This means that moving a resource into a folder could grant a user additional roles on that resource. Conversely, moving a resource out of a folder might mean losing roles on that resource.\n\nBest practices for using IAM roles and permissions with Folders\n---------------------------------------------------------------\n\nWhen assigning IAM roles and permissions for use with Folders, keep the\nfollowing in mind:\n\n- Use groups whenever possible to manage principals.\n- Minimize usage of basic roles, such as owner, editor, and viewer. Instead, try to use the predefined roles for principle of least privilege.\n- For folder-wide management, assign permissions at folder level and have projects inherit them automatically. For example, you could assign a department administrator group the **Folder Admin** role on the folder. Network administrators that need to have department-wide permissions can have the **Network Admin** role for the folder.\n- Carefully consider what permissions might change before moving a resource out of a folder. Otherwise, you could risk breaking existing apps or workflows that require those permissions on that resource.\n- Plan and test your resource hierarchy carefully before moving production projects under folders. One way to do this is to create a test folder under your organization resource and creating a prototype of your intended hierarchy ahead of time.\n- Granting a role to a user at the folder level will grant the user that role for every resource underneath that folder as well. For example, if you grant a user the Compute Admin role (`roles/compute.admin`) on a folder, that user will have full control of all Compute Engine resources in every project in that folder.\n\nUnderstanding folder roles and permissions\n------------------------------------------\n\n### Default roles\n\nWhen you create a folder, you are granted the **Folder Admin** and\n**Folder Editor** roles for the folder to provide you full control as the\ncreator. See below for the permissions that these roles provide. These default\nroles can be changed as normal in an allow policy.\n\n### Using predefined roles\n\n### Creating custom roles\n\nIn addition to the predefined roles described in this topic, you can also create [custom roles](/iam/docs/understanding-custom-roles) that are collections of permissions that you tailor to your needs. When creating a custom role for use with Resource Manager, be aware of the following points:\n\n- List and get permissions, such as `resourcemanager.projects.get/list`, should always be granted as a pair.\n- When your custom role includes the `folders.list` and `folders.get` permissions, it should also include `projects.list` and `projects.get`.\n- Be aware that the `setIamPolicy` permission for organization, folder, and project resources allows the user to grant all other permissions, and so should be assigned with care.\n\nGranting roles to enable folder browsing\n----------------------------------------\n\nList permissions enable folder browsing. The two types of list permissions that\ntypically need to be granted are `resourcemanager.folders.list`, which allows\nusers to list folders under a resource, and `resourcemanager.projects.list`,\nwhich allows users to browse projects under an organization resource or folder. The\nOrganization Administrator is initialized with both of these permissions. For\nusers that have not been assigned the **Organization Administrator** role:\n\n- `resourcemanager.folders.list` can be granted via the **Folder Viewer** and **Folder Editor** roles.\n- `resourcemanager.projects.list` can be granted via the **Viewer** or **Browser** roles.\n\nFor organization resource principals to browse the entire organization resource hierarchy, list\npermissions should be granted at the organization resource level.\n\nGranting roles to enable folder creation\n----------------------------------------\n\nUsers that need to create folders must be granted **Folder Creator** role on a\nresource in the hierarchy above the level at which the folder will be created.\nIt can be helpful to grant browsing permissions along with folder creation\npermissions so users can effectively navigate to where in the hierarchy the\nfolder will be created. See the [section above](#FolderRolesAndPermissions) for\nmore information on browsing permissions.\n\n**Folder Creator** does not grant a user permission to delete a folder. However,\nwhen a person creates a folder, that person is automatically granted the\n**Folder Editor** role. The **Folder Editor** role enables folder deletion.\n\nGranting roles to enable folder movement\n----------------------------------------\n\nTo move a folder from one parent resource to another, users must have\nthe **Folder Mover** role on both old and new parent resources, or on a common\nancestor.\n\nGranting roles to enable project movement\n-----------------------------------------\n\nTo move a project into a folder, users must have the **Project Editor** or\n**Project Owner** roles on the project and the **Project Mover** on both the\nsource and destination parent resources.\n\nThis is slightly different from the requirements for moving a non-org-owned\nproject into the organization resource, where users must have the **Project Editor**\nor **Project Owner** role on the project and the **Project Creator** role on\nthe organization resource.\n\nGranting folder-specific roles to enable project creation\n---------------------------------------------------------\n\nTo create projects, users must have the **Project Creator** role.\nHowever, rather than granting org-wide project creation permission, it can be\nuseful to instead restrict users to viewing and creating projects only within\na given folder.\n\nTo grant folder-specific permissions:\n\n1. Grant the user the **Organization Viewer** role at the org node level (for example, domain.com).\n2. Create a new folder.\n3. Add the user to IAM at the folder level and grant them the **Folder Viewer** and **Project Creator** roles.\n\nThis allows the user to create projects in their folder without granting them\nvisibility to every project in the greater organization resource."]]
