범위가 지정된 정책은 전체 조직에 적용할 수 있는 액세스 정책과 함께 특정 폴더나 프로젝트로 범위가 지정된 액세스 정책입니다. 범위가 지정된 정책을 사용하여 VPC 서비스 제어 경계 및 액세스 수준의 관리를 폴더 수준 관리자와 프로젝트 수준 관리자에게 위임할 수 있습니다.
조직은 조직 수준의 액세스 정책을 하나만 가질 수 있으며 조직 수준 액세스 정책을 조직의 모든 폴더나 프로젝트에 적용할 수 있습니다.
폴더와 같은 조직 리소스의 하위 집합에 대한 정책 관리를 위임된 관리자에게 위임하려는 경우가 있을 수 있습니다.
전체 조직에 적용할 수 있는 액세스 정책과 함께 특정 폴더나 프로젝트로 범위가 지정된 액세스 정책을 만들 수 있습니다. VPC 서비스 제어 경계와 액세스 수준의 관리를 폴더 수준 관리자와 프로젝트 수준 관리자에게 위임하려면 범위가 지정된 정책을 사용하면 됩니다.
범위가 지정된 정책 관리를 위임하면 위임된 관리자가 조직의 Access Context Manager 정책이 아닌 특정 정책을 수정하거나 읽을 수 있습니다.
범위가 지정된 정책은 VPC 서비스 제어 경계에서 제한할 수 있는 리소스와 액세스 수준 공개 상태를 제한합니다.
범위가 지정된 정책 관리
조직 수준 Access Context Manager 관리자는 범위가 지정된 정책을 생성, 수정, 삭제할 수 있습니다. Access Context Manager 정책에서 Identity and Access Management(IAM) binding을 직접 지정하고 Access Context Manager 정책 관리를 조직 내 다른 사용자에게 위임할 수 있습니다. 범위가 지정된 정책 관리자는 정책에서 서비스 경계와 액세스 수준을 구성할 수 있습니다. 하지만 범위가 지정된 정책 관리자는 새 정책을 만들거나 다른 폴더나 프로젝트에 적용할 정책 범위를 변경할 수 없습니다.
다음은 관리자가 범위가 지정된 정책을 관리하는 방법의 순서입니다.
조직 수준 관리자는 특정 폴더나 프로젝트를 참조하는 범위 필드가 있는 새 액세스 정책을 만듭니다.
조직 수준 관리자는 액세스 정책 리소스에서 위임된 관리자에게 IAM 권한을 직접 할당합니다. 이제 위임된 관리자에게는 범위가 지정된 정책에 대한 권한이 있지만 조직 수준 관리자가 위임된 관리자에게 권한을 명시적으로 할당하지 않으면 다른 정책에 대한 권한은 없습니다.
이제 위임된 관리자는 정책을 수정하여 액세스 수준과 서비스 경계를 구성할 수 있습니다. 위임된 관리자는 해당 정책에 대한 IAM 권한을 다른 사용자에게 부여할 수도 있습니다.
폴더나 프로젝트를 삭제하면 삭제된 폴더나 프로젝트가 있는 정책과 해당 범위도 삭제됩니다. 또한 프로젝트를 조직 계층 구조의 다른 노드로 이동해도 프로젝트로 범위가 지정된 정책은 자동으로 수정되지 않습니다.
프로젝트와 연결된 정책을 삭제한 후 정책을 다시 만들고 범위를 지정해야 합니다.
범위가 지정된 정책 계층 구조
조직 리소스는 Google Cloud 리소스 계층 구조의 루트 노드이며 조직에 속하는 모든 리소스는 조직 노드의 하위 요소로 존재합니다.
폴더는 프로젝트 기반의 그룹화 메커니즘입니다. 폴더와 프로젝트는 조직 리소스의 하위 노드로 존재합니다.
다음 다이어그램에서는 각 부서의 폴더가 포함된 조직 예시를 보여줍니다. 폴더에는 개발, 테스트, 프로덕션 프로젝트가 포함되어 있습니다.
예시 조직에서 다음 제약조건은 범위가 지정된 정책의 서비스 경계나 액세스 수준에 적용됩니다.
범위가 지정된 정책의 서비스 경계는 해당 정책 범위에 있는 리소스만 제한할 수 있습니다. 예를 들어 engineering 폴더로 범위가 지정된 정책의 서비스 경계는 프로젝트가 engineering 폴더에 있으므로 example-dev, example-prod, example-test 프로젝트를 보호할 수 있습니다.
범위가 지정된 정책이 sales 폴더에 적용되면 해당 정책의 서비스 경계는 example-dev, example-prod, example-test 프로젝트를 보호할 수 없습니다. 그러나 인그레스 및 이그레스 규칙을 사용하면 범위가 지정된 정책의 서비스 경계에서 다른 폴더의 프로젝트에 액세스할 수 있습니다.
정책 범위 내에서만 범위가 지정된 정책의 액세스 수준을 볼 수 있습니다. engineering 폴더로 범위가 지정된 정책에 액세스 수준을 만드는 경우 engineering 폴더의 서비스 경계와 액세스 수준에서만 사용할 수 있습니다. 다른 폴더의 서비스 경계와 액세스 수준은 engineering 폴더에 정의된 액세스 수준을 사용할 수 없습니다.
example.com 조직 리소스 계층 구조의 폴더와 같은 위치에는 액세스 수준이나 서비스 경계가 포함된 정책이 여러 개 있을 수 있습니다. 정책이 여러 개 있으면 example.com 조직의 리소스 요청은 다음 규칙에 따라 평가됩니다.
정책 하나에는 폴더와 같은 범위 하나만 포함될 수 있지만 조직의 각 수준에 대한 정책을 만들 수 있습니다. 예를 들어 정책 1의 범위가 engineering 폴더인 경우 engineering 폴더를 다른 정책의 범위로 설정할 수 없습니다. example-prod와 같이 engineering 폴더의 하위 요소로 설정된 범위를 사용하여 다른 정책을 설정할 수 있습니다.
정책 범위가 프로젝트나 프로젝트 상위 요소에 적용되면 프로젝트를 정책에 추가할 수 있습니다. 그러나 프로젝트는 모든 정책에서 서비스 경계 하나에만 속할 수 있습니다. 예를 들어 범위가 example.com 조직으로 설정된 정책은 example-dev를 사용하여 서비스 경계를 정의할 수 있습니다. 범위가 engineering 폴더나 example-dev 프로젝트로 설정된 정책은 example-dev 프로젝트를 두 프로젝트 중 하나에서 정의된 경계에 추가할 수 있습니다. 그러나 이 세 가지 정책 중 하나만 이 프로젝트를 포함할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eScoped policies allow delegation of VPC Service Controls perimeter and access level administration to folder-level and project-level administrators, alongside an organization-level access policy.\u003c/p\u003e\n"],["\u003cp\u003eOrganization-level administrators can create, modify, and delete scoped policies, but delegated administrators can only manage the specific policy assigned to them, not the organization's policy.\u003c/p\u003e\n"],["\u003cp\u003eScoped policies restrict resources within the specified scope, such as a folder or project, meaning service perimeters can only secure resources within that scope, and access levels are only visible within the scope.\u003c/p\u003e\n"],["\u003cp\u003eEach folder or project can only have one scoped policy, and when a folder or project is deleted, the associated scoped policy is also deleted, with projects that are moved to different locations needing to be recreated and re-scoped.\u003c/p\u003e\n"],["\u003cp\u003eIf an organization-level access policy does not exist, scoped policies created at the folder or project level will not function, highlighting the dependency on an organizational access policy.\u003c/p\u003e\n"]]],[],null,["# Scoped policies are access policies that are scoped to specific folders or projects\nalongside an access policy that you can apply to the entire organization. You can\nuse scoped policies to delegate administration of VPC Service Controls perimeters\nand access levels to folder-level and project-level administrators.\n\nOrganizations can only have one access policy at the organizational level, and you\ncan apply the organizational-level access policy to any folder or project in your\norganization.\n\nThere might be instances when you want to delegate the management of a policy for a\nsubset of an organization's resources, such as a folder, to a delegated administrator.\nYou can create access policies that are scoped to specific folders or projects\nalongside an access policy that can apply to the entire organization. To delegate\nadministration of VPC Service Controls perimeters and access levels to folder-level and\nproject-level administrators, you can use scoped policies.\n\nWhen you delegate administration of a scoped policy, the delegated administrators can\nmodify or read that specific policy and not the organization's Access Context Manager policy.\nThe scoped policies limit the resources that can be restricted in a VPC Service Controls perimeter, and the visibility of any access levels.\n\nScoped policies management\n--------------------------\n\nAs an organization-level Access Context Manager administrator, you can create, modify,\nand delete scoped policies. You can specify Identity and Access Management (IAM) bindings on\nAccess Context Manager policy directly, and allow further delegation of\nAccess Context Manager policy administration to other users in the organization. A\nscoped policy administrator can configure service perimeters and access levels in\npolicies. However, a scoped policy administrator cannot create a new policy or change\nthe scope of the policy to apply to another folder or project.\n| **Warning:** If an organization-level access policy doesn't exist for your organization, scoped policies that you create at the folder or project-level will not operate.\n\nHere is a sequence of how administrators manage the scoped policies:\n\n1. The organization-level administrator creates a new access policy with a scope\n field referencing a specific folder or project.\n\n2. The organization-level administrator assigns IAM permissions to the delegated\n administrator directly on the access policy resource. The delegated administrator\n now has permissions on the scoped policy but does not have permissions on any\n other policy unless the organization-level administrator explicitly assigns them\n to the delegated administrator.\n\n3. The delegated administrator can now edit the policy to configure access levels\n and service perimeters. The delegated administrator can also grant\n IAM permissions on that policy to any other user.\n\nWhen you delete a folder or a project, the policy that has the deleted folder or project\nas its scope is also deleted. Also, if you move a project to another node in the\norganization hierarchy, the policy scoped to the project is not automatically modified.\nYou must delete the policy associated with the project, and then recreate the policy\nand specify the scope.\n\nScoped policies hierarchy\n-------------------------\n\nThe organization resource is the root node of the Google Cloud resource hierarchy and\nall resources that belong to an organization exist as children of the organization node.\nFolders are a grouping mechanism on top of projects. Folders and projects\nexist as child nodes of the organization resource.\n\nThe following diagram shows an example organization that contains folders for each\ndepartment, and the folders contain dev, test, and production projects.\n\nIn the example organization, the following constraints apply to a service perimeter\nor an access level in a scoped policy:\n\n- Service perimeters in a scoped policy can only restrict resources that exist\n in the scope of that policy. For example, a service perimeter in a policy scoped\n to the engineering folder can secure the example-dev, example-prod, and example-test\n projects because the projects are in the engineering folder.\n\n If the scoped policy applies to the sales folder, then service perimeters in\n that policy cannot secure any of example-dev, example-prod, and example-test\n projects. However, the service perimeter in the scoped policy can allow access\n to projects in other folders by using ingress and egress rules.\n- Access levels in a scoped policy are only visible within the scope of the policy. If\n you create an access level in the policy scoped to the engineering folder, then only\n service perimeters and access levels in the engineering folder can use it. Service\n perimeters and access levels in other folders cannot use the access level defined in\n the engineering folder.\n\nA location, such as a folder, in the example.com organization resource hierarchy\ncan have multiple policies that contain an access level or service perimeter. When\nmultiple policies exist, a request for resources in the example.com organization\nis evaluated based on the following rules:\n\n- A policy can contain only one scope, such as a folder, but you can create a\n policy for each level of an organization. For example, if the scope of\n policy 1 is the engineering folder, you cannot set the engineering folder as the\n scope of any other policy. You can set another policy with the scope set to the\n child of the engineering folder, such as example-prod.\n\n- If the scope of a policy applies to a project or a parent of the project,\n you can add the project to the policy. However, a project can be a member\n of only one service perimeter across all policies. For example, A policy with\n scope set to the organization example.com can define a service perimeter with\n example-dev. A policy with scope set to the engineering folder or scope set to\n the example-dev project can also add the example-dev project to a perimeter\n defined within either of them. However, only one of those three policies can\n contain this project.\n\nWhat's next\n-----------\n\n- [Create an access policy](/access-context-manager/docs/create-access-policy)"]]
