주 구성원 액세스 경계 정책

미리보기

이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

주 구성원 액세스 경계(PAB) 정책을 사용하면 주 구성원이 액세스할 수 있는 리소스를 제한할 수 있습니다.

예를 들어 주 구성원 액세스 경계 정책을 사용하여 주 구성원이 다른 조직의 리소스에 액세스하지 못하도록 방지하여 피싱 공격 또는 데이터 무단 반출을 방지하는 데 도움을 줄 수 있습니다.

Identity and Access Management(IAM)에서 제공되는 다른 유형의 액세스 제어 정책에 대해 자세히 알아보려면 정책 유형을 참조하세요.

주 구성원 액세스 경계 정책의 작동 방법

기본적으로 주 구성원은 모든 Google Cloud 리소스에 액세스할 수 있는 자격이 있습니다. 즉, 주 구성원에게 리소스에 대한 권한이 있고 그러한 권한을 거부하지 않았으면 이 권한을 이용해서 리소스에 액세스할 수 있습니다.

주 구성원 액세스 경계 정책을 사용하면 주 구성원에게 액세스 자격이 있는 리소스를 제한할 수 있습니다. 주 구성원 액세스 경계 정책에 따라 주 구성원에 리소스 액세스 자격이 없게 되면 주 구성원에게 부여된 역할에 관계없이 리소스에 대한 주 구성원의 액세스가 제한됩니다.

주 구성원이 액세스 자격이 없는 리소스에 액세스하려고 시도하면 주 구성원 액세스 경계 정책에 따라 전체는 아니지만 일부 Identity and Access Management(IAM) 권한이 차단됩니다. 차단되는 권한에 대해 자세히 알아보려면 주 구성원 액세스 경계로 차단할 수 있는 권한을 참조하세요.

주 구성원 액세스 경계 정책은 주 구성원 액세스 경계 규칙으로 구성됩니다. 각 주 구성원 액세스 경계 규칙은 대상 주 구성원에게 액세스 자격이 있는 리소스 집합을 정의합니다. 조직에서 주 구성원 액세스 경계 정책은 최대 1,000개까지 만들 수 있습니다.

주 구성원 액세스 경계 정책을 만든 후에는 주 구성원 집합에 정책을 적용하도록 정책 바인딩을 만듭니다.

주 구성원에는 하나 이상의 주 구성원 액세스 경계 정책이 적용될 수 있습니다. 각 주 구성원에게는 이러한 정책에 나열된 리소스에만 액세스 자격이 부여됩니다. 다른 모든 리소스에 대해서는 리소스에 대해 주 구성원에게 역할을 부여하더라도 해당 리소스에 대한 주 구성원의 액세스 권한이 제한됩니다.

주 구성원 액세스 경계 정책은 리소스가 아닌 주 구성원과 연결되기 때문에 이를 사용해서 주 구성원이 사용자 소유가 아닌 리소스에 액세스하지 못하도록 방지할 수 있습니다. 예를 들어 다음 시나리오를 고려해 보세요.

• 주 구성원인 탈([e-mail])은 Google Workspace 조직 altostrat.com의 일원입니다.
• 탈에게는 cymbalgroup.com이라는 다른 조직에서도 Cloud Storage 버킷에 대해 스토리지 관리자(roles/storage.admin) 역할이 부여되어 있습니다. 이 역할에는 버킷의 객체를 보는 데 필요한 storage.objects.get 권한이 포함되어 있습니다.
• cymbalgroup.com에는 탈이 storage.objects.get 권한을 사용하지 못하도록 방지하는 거부 정책이 없습니다.

허용 및 거부 정책만으로는 altostrat.com에서 탈이 이 외부 버킷의 객체를 보지 못하도록 방지할 수 없습니다. altostrat.com 주 구성원에는 버킷의 허용 정책을 수정할 수 있는 권한이 없으므로, 탈의 역할을 취소할 수 없습니다. 또한 cymbalgroup.com에서 거부 정책을 만들 수 있는 권한이 없으므로 탈이 버킷에 액세스하지 못하도록 방지하는 거부 정책을 사용할 수 없습니다.

하지만 주 구성원 액세스 경계 정책을 이용할 경우 altostrat.com 관리자는 탈이 cymbalgroup.com 버킷 또는 altostrat.com 외부 버킷의 객체를 보지 못하도록 할 수 있습니다. 이를 위해 관리자는 altostrat.com 주 구성원에게 altostrat.com의 리소스에 대해서만 액세스 자격이 있도록 지정하는 주 구성원 액세스 경계 정책을 만들 수 있습니다. 그런 후 altostrat.com 조직의 모든 주 구성원에 이 정책을 연결하는 정책 바인딩을 만들면 됩니다. 이렇게 정책을 배치하면 cymbalgroup.com 버킷에 대해 스토리지 관리자 역할이 부여되어 있더라도 탈이 해당 버킷의 객체를 볼 수 없습니다.

장애 허용 평가

주 구성원 액세스 경계 정책의 미리보기 출시 기간 중 주 구성원 액세스 경계 정책은 장애 허용 방식을 따릅니다. 즉, IAM이 주 구성원 액세스 경계 정책을 평가하지 못할 때는 주 구성원 액세스 경계 정책을 무시하고 관련 허용 및 거부 정책을 평가합니다.

주 구성원 액세스 경계 정책으로 차단되는 권한

주 구성원이 액세스 자격이 없는 리소스에 액세스하려고 시도할 때 주 구성원 액세스 경계 정책은 전체는 아니지만 일부 Identity and Access Management(IAM) 권한을 사용해서 리소스에 액세스하지 못하도록 방지합니다.

주 구성원 액세스 경계 정책으로 권한이 차단될 때 IAM은 해당 권한에 대해 주 구성원 액세스 경계 정책을 적용합니다. 즉, 리소스에 액세스 자격이 없는 주 구성원이 권한을 이용해서 리소스에 액세스하지 못하도록 방지합니다.

주 구성원 액세스 경계 정책이 권한을 차단하지 않을 경우 주 구성원 액세스 경계 정책은 주 구성원이 그러한 권한을 사용할 수 있는지 여부에 영향을 미치지 않습니다.

예를 들어 주 구성원인 리([e-mail])에게 Dataflow 개발자 역할(roles/dataflow.developer)이 부여되었다고 가정해 보세요. 이 역할에는 리가 Dataflow 작업에 대해 스냅샷을 생성할 수 있는 dataflow.jobs.snapshot 권한이 포함되어 있습니다. 또한 리에게는 example.com 외부의 리소스에 대해 액세스 자격을 없애는 주 구성원 액세스 경계 정책이 적용됩니다. 하지만 주 구성원 액세스 경계 정책에서 dataflow.jobs.snapshot 권한은 차단되지 않으므로, 리는 계속 example.com 외부 조직에서 Dataflow 작업에 대해 스냅샷을 생성할 수 있습니다.

주 구성원 액세스 경계 정책이 차단하는 권하는 주 구성원 액세스 경계 시행 버전에 따라 달라집니다.

주 구성원 액세스 경계 시행 버전

각 주 구성원 액세스 경계 정책에는 주 구성원 액세스 경계 정책이 차단할 수 있는 미리 정의된 IAM 권한 역할을 식별하는 시행 버전이 지정되어 있습니다. 시행 버전은 주 구성원 액세스 경계 정책을 만들거나 업데이트할 때 지정합니다. 시행 버전을 지정하지 않으면 IAM에 최신 시행 버전이 사용되며 업데이트될 때까지 계속 이 버전이 사용됩니다.

IAM은 추가 권한을 차단할 수 있는 새로운 주 구성원 액세스 경계 시행 버전을 주기적으로 추가합니다. 또한 각 새 버전은 이전 버전의 모든 권한을 차단할 수 있습니다.

새 시행 버전에서 권한을 차단하려면 새 버전을 사용하도록 주 구성원 액세스 경계 정책을 업데이트해야 합니다. 새 버전이 출시될 때 시행 버전이 자동으로 업데이트되도록 하려면 정책을 만들 때 latest 값을 사용하면 됩니다. 하지만 이 값을 사용하면 주 구성원이 리소스 액세스 권한을 예기치 않게 잃어버릴 수 있으므로 사용하지 않는 것이 좋습니다.

각 시행 버전이 차단하는 전체 권한 목록은 주 구성원 액세스 경계 정책으로 차단되는 권한을 참조하세요.

주 구성원 집합에 주 구성원 액세스 경계 정책 바인딩

주 구성원 집합에 주 구성원 액세스 경계 정책을 바인딩하려면 시행하려는 주 구성원 액세스 경계 정책과 이를 적용하려는 주 구성원 집합을 모두 지정하는 정책 바인딩을 만듭니다. 정책을 주 구성원 집합에 바인딩한 후 해당 주 구성원 집합의 주 구성원은 주 구성원 액세스 경계 정책의 규칙에 포함된 리소스에만 액세스할 수 있습니다.

주 구성원 액세스 경계 정책은 원하는 개수만큼 주 구성원 집합에 바인딩할 수 있습니다. 각 주 구성원 집합에는 최대 10개까지 주 구성원 액세스 경계 정책을 지정할 수 있습니다.

주 구성원 액세스 경계 정책을 관리하는 방법은 주 구성원 액세스 경계 정책 만들기 및 적용을 참조하세요.

지원되는 주 구성원 집합

다음 표에서는 주 구성원 액세스 경계 정책을 바인딩할 수 있는 주 구성원 집합의 유형을 보여줍니다. 각 행에는 다음이 포함됩니다.

• 주 구성원 집합의 유형
• 해당 유형의 주 구성원 집합에 포함된 주 구성원
• 해당 유형의 주 구성원 집합에 대한 ID 형식
• 해당 유형의 주 구성원 집합에 대한 정책 바인딩을 보유하는 Resource Manager 리소스(프로젝트, 폴더, 조직)

주 구성원 집합	세부정보	정책 바인딩의 상위 리소스
직원 ID 풀	지정된 직원 ID 풀의 모든 ID를 포함합니다. 형식: //iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID	직원 ID 풀이 포함된 조직
워크로드 아이덴티티 풀	지정된 워크로드 아이덴티티 풀의 모든 ID를 포함합니다. 형식: //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID	워크로드 아이덴티티 풀이 포함된 프로젝트
Google Workspace 도메인	지정된 Google Workspace 도메인의 모든 ID를 포함합니다. 형식: //iam.googleapis.com/locations/global/workspace/WORKSPACE_ID 다음 방법을 사용하여 워크스페이스 ID를 찾을 수 있습니다. gcloud organizations describe 명령어를 사용합니다. 작업공간 ID는 응답의 directoryCustomerId 필드에 있습니다. Cloud Resource Manager API에서 organizations.get 메서드를 사용합니다. 작업공간 ID는 응답의 directoryCustomerId 필드에 있습니다. 관리 콘솔에서 워크스페이스 ID를 확인합니다. 이 방법을 사용하려면 Google Workspace 최고 관리자 역할이 필요합니다.	Google Workspace 도메인과 연결된 조직
프로젝트의 주 구성원 집합	지정된 프로젝트에 있는 모든 서비스 계정과 워크로드 아이덴티티 풀을 포함합니다. 형식: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID	프로젝트
폴더의 주 구성원 집합	지정된 폴더에서 모든 프로젝트에 있는 모든 서비스 계정 및 모든 워크로드 아이덴티티 풀을 포함합니다. 형식: //cloudresourcemanager.googleapis.com/folders/FOLDER_ID	폴더
조직의 주 구성원 집합	다음 ID를 포함합니다. Google Workspace 고객 ID와 연결된 모든 도메인의 모든 ID 조직의 모든 직원 ID 풀 조직에서 모든 프로젝트에 잇는 모든 서비스 계정 및 워크로드 아이덴티티 풀 형식: //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID	조직

주 구성원 액세스 경계 정책의 조건부 정책 바인딩

주 구성원 액세스 경계 정책에 따라 정책이 적용되는 주 구성원을 미세 조정하기 위해 정책 바인딩에서 조건 표현식을 사용할 수 있습니다.

정책 바인딩의 조건 표현식은 최대 10개의 논리적 연산자(&&, ||, !)로 결합된 하나 이상의 문으로 구성됩니다. 각 문은 정책 바인딩에 적용되고 마지막으로 정책 적용 여부를 결정하는 속성 기반 제어 규칙을 표시합니다.

정책 바인딩의 조건에는 principal.type 및 principal.subject 속성을 사용할 수 있습니다. 정책 바인딩의 조건에서 다른 속성은 지원되지 않습니다.

• principal.type 속성은 서비스 계정, 워크로드 아이덴티티 풀의 ID와 같이 요청에 있는 주 구성원의 유형을 나타냅니다. 이 속성과 함께 조건을 사용하여 주 구성원 액세스 경계 정책이 적용되는 주 구성원 유형을 제어할 수 있습니다.

  예를 들어 주 구성원 액세스 경계 정책을 위한 바인딩에 다음 조건 표현식을 추가하면 정책이 서비스 계정에만 적용됩니다.

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• principal.subject 속성은 요청에서 주 구성원의 ID를 나타냅니다(예: [e-mail]). 이 속성과 함께 조건을 사용하여 주 구성원 액세스 경계 정책에 적용되는 주 구성원을 정확하게 제어할 수 있습니다.

  예를 들어 주 구성원 액세스 경계 정책을 위한 바인딩에 다음 조건 표현식을 추가하는 경우 [e-mail] 사용자에 대해서는 정책이 적용되지 않습니다.

  principal.subject != '[e-mail]'
  

이러한 조건에 사용할 수 있는 값에 대한 자세한 내용은 조건 속성 참조를 확인하세요.

예시: 주 구성원에게 액세스 자격이 있는 리소스 감소를 위한 조건 사용

주 구성원 액세스 경계 정책 바인딩에서 조건을 사용하는 방법 중 하나는 단일 주 구성원에게 액세스 자격이 있는 리소스를 줄이는 것입니다.

이메일 주소가 [e-mail]인 dev-project-service-account라는 서비스 계정이 있다고 가정해 보세요. 이 서비스 계정에는 주 구성원에게 example.com 조직의 모든 리소스에 대한 액세스 자격을 부여하는 주 구성원 액세스 경계 정책이 적용됩니다. 이 정책은 example.com 조직의 주 구성원 집합에 연결됩니다.

dev-project-service-account에서 example.com의 모든 리소스에 대한 액세스 자격을 없애고 dev-project의 리소스에 대해서만 액세스 자격을 부여하기로 결정했습니다. 하지만 example.com 주 구성원 집합의 다른 주 구성원에게 액세스 권한이 있는 리소스는 변경하지 않아야 합니다.

이렇게 변경하기 위해 주 구성원에게 액세스 자격이 있는 리소스를 줄이는 절차를 수행하지만 이를 삭제하는 대신 정책 바인딩에 조건을 추가합니다.

1. dev-project-service-account에 적용되는 주 구성원 액세스 경계 정책이 주 구성원에 대해 example.com의 모든 리소스에 대한 액세스 자격을 설정하는 정책인지 확인합니다.

2. dev-project에서 주 구성원의 리소스 액세스 자격을 설정하는 새로운 주 구성원 액세스 경계 정책을 만들고 dev-project에 대해 설정된 주 구성원에 연결합니다. 정책 바인딩에서 다음 조건을 사용하여 정책이 dev-project-service-account에 대해서만 시행되었는지 확인합니다.

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == '[e-mail]'"
   }
   

3. 주 구성원에게 example.com의 모든 리소스에 대해 액세스 자격을 부여하는 주 구성원 액세스 경계 정책에서 dev-project-service-account를 제외합니다. 이렇게 하려면 조직의 주 구성원 집합에 주 구성원 액세스 경계 정책을 연결하는 정책 바인딩에 다음 조건을 추가합니다.

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != '[e-mail]' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   기존 주 구성원 액세스 경계 정책을 업데이트하는 방법은 주 구성원 액세스 경계 정책 수정을 참조하세요.

정책 바인딩에 이 조건을 추가한 후에는 dev-project-service-account에 더 이상 example.com의 모든 리소스에 대한 액세스 자격이 없으며, 대신 dev-project의 리소스에 대한 액세스 자격이 부여됩니다.

정책 상호작용

IAM은 허용 및 거부 정책 그리고 다른 주 구성원 액세스 경계 정책과 함께 각 주 구성원 액세스 경계 정책을 평가합니다. 이러한 모든 정책은 주 구성원이 리소스에 액세스할 수 있는지 여부를 결정하기 위해 사용됩니다.

다른 정책 유형과 상호작용

주 구성원이 리소스에 액세스를 시도하면 IAM은 모든 관련된 주 구성원 액세스 경계, 허용, 거부 정책을 평가하여 주 구성원이 리소스에 액세스할 수 있는지 확인합니다. 이러한 정책 중 하나에 주 구성원이 리소스에 액세스할 수 없는 것으로 표시되면 IAM이 액세스를 차단합니다.

따라서 주 구성원 액세스 경계 정책에 따라 주 구성원의 리소스 액세스가 방지되는 경우 IAM은 리소스에 연결된 허용 또는 거부 정책에 관계없이 해당 리소스에 대한 액세스를 차단합니다.

또한 주 구성원 액세스 경계 정책 단독으로는 주 구성원에게 리소스 액세스 권한을 부여하지 않습니다. 주 구성원 액세스 경계 정책은 주 구성원에 리소스 액세스 자격을 부여할 수 있지만 주 구성원에 리소스 액세스 권한을 실제로 부여하는 것은 허용 정책만 가능합니다.

IAM 정책 평가에 대한 자세한 내용은 정책 평가를 참조하세요.

주 구성원 액세스 경계 정책 간 상호작용

주 구성원 액세스 경계 정책으로 주 구성원에게 리소스 액세스 자격이 부여될 경우 주 구성원은 해당 주 구성원에게 적용되는 다른 주 구성원 액세스 경계 정책에 관계없이 해당 리소스에 대한 액세스 자격이 부여됩니다. 따라서 주 구성원에 이미 주 구성원 액세스 경계 정책이 적용되는 경우 주 구성원의 액세스 권한 감소를 위해 주 구성원 액세스 경계 정책을 추가할 수 없습니다.

예를 들어 주 구성원인 다나([e-mail])에게 prod-projects-policy라는 단일 주 구성원 액세스 경계 정책이 적용된다고 가정해 보세요. 이 정책은 주 구성원에게 prod-project의 리소스 액세스 자격을 부여합니다. 다나에게는 조직의 주 구성원 집합 바인딩으로 인해 이 정책이 적용됩니다.

주 구성원에게 dev-project 및 staging-project의 리소스 액세스 자격을 부여하는 dev-staging-projects-policy라는 새로운 주 구성원 액세스 경계 정책을 만든 후 이를 조직의 주 구성원 집합에 바인딩합니다.

이러한 주 구성원 액세스 경계 정책에 따라 다나에게는 dev-project, staging-project, prod-project의 리소스 액세스 자격이 부여됩니다.

다나에게 액세스 자격이 있는 리소스를 줄이기 위해서는 다나에게 적용되는 주 구성원 액세스 경계 정책을 수정하거나 삭제해야 합니다.

예를 들어 주 구성원에게 dev-project의 리소스 액세스 자격을 부여하지 않도록 dev-staging-projects-policy를 수정할 수 있습니다. 그러면 다나에게는 staging-project 및 prod-project의 리소스 액세스 자격만 부여됩니다.

또는 조직의 주 구성원 집합에 바인딩하는 정책 바인딩을 삭제하여 prod-projects-policy를 삭제할 수 있습니다. 그러면 다나에게는 dev-project 및 staging-project의 리소스 액세스 자격만 부여됩니다.

중요: 주 구성원의 액세스 권한을 줄이기 위해 주 구성원 액세스 경계 정책을 삭제할 경우 주 구성원에게 항상 하나 이상의 주 구성원 액세스 경계 정책이 적용되도록 해야 합니다. 주 구성원에게 주 구성원 액세스 경계 정책이 적용되지 않으면 주 구성원에게 모든 Google Cloud 리소스에 대한 액세스 자격이 부여됩니다. 주 구성원의 액세스 권한을 안전하게 줄이는 방법은 주 구성원에게 액세스 자격이 있는 리소스 감소를 참조하세요.

하지만 이러한 변경사항은 다나에게만 영향을 미치지 않으며, 수정된 주 구성원 액세스 경계 정책 및 바인딩에 적용되는 다른 주 구성원에도 영향을 미칩니다. 단일 주 구성원에 리소스 액세스 자격이 있는 리소스를 줄이려면 조건부 정책 바인딩을 사용합니다.

정책 상속

주 구성원 액세스 경계 정책은 Resource Manager 리소스가 아닌 주 구성원 집합에 연결됩니다. 따라서 허용 및 거부 정책과 동일한 방법으로 리소스 계층 구조를 통해 상속되지 않습니다.

하지만 폴더 및 조직에 해당하는 Resource Manager 상위 리소스에 대한 주 구성원 집합에는 항상 해당 종속 항목의 주 구성원 집합에 있는 모든 주 구성원이 포함됩니다. 예를 들어 주 구성원이 프로젝트의 주 구성원 집합에 포함된 경우에는 상위 폴더 또는 조직의 주 구성원 집합에도 포함됩니다.

예를 들어 example.com이라는 조직이 있다고 가정해 보세요. 이 조직은 example.com 도메인과 연결되어 있으며 다음과 같은 Resource Manager 리소스를 포함합니다.

• example.com 조직
• 조직의 하위 요소인 project-1 프로젝트
• 조직의 하위 요소인 folder-a 폴더
• folder-a의 하위 요소인 2개의 project-2 및 project-3 프로젝트

이러한 리소스의 주 구성원 집합에는 다음 ID가 포함됩니다.

주 구성원 집합	example.com 도메인의 Google Workspace ID	example.com의 직원 ID 제휴 풀	project-1의 서비스 계정 및 워크로드 아이덴티티 풀	project-2의 서비스 계정 및 워크로드 아이덴티티 풀	project-3의 서비스 계정 및 워크로드 아이덴티티 풀
example.com의 주 구성원 집합
folder-a의 주 구성원 집합
project-1의 주 구성원 집합
project-2의 주 구성원 집합
project-3의 주 구성원 집합

따라서 다음 주 구성원은 다음 주 구성원 액세스 경계 정책의 영향을 받습니다.

• example.com 도메인에서 Google Workspace ID는 example.com에 대한 주 구성원 집합에 포함되며 해당 주 구성원 집합에 바인딩된 주 구성원 액세스 경계 정책의 영향을 받습니다.

• project-1의 서비스 계정은 project-1 및 example.com에 대한 주 구성원 집합에 포함되며 이러한 주 구성원 집합 중 하나에 바인딩된 주 구성원 액세스 경계 정책의 영향을 받습니다.

• project-3의 서비스 계정은 project-3, folder-a, example.com에 대한 주 구성원 집합에 포함되며 이러한 주 구성원 집합에 바인딩된 주 구성원 액세스 경계 정책의 영향을 받습니다.

주 구성원 액세스 경계 정책 및 캐시된 리소스

특정 Google Cloud 서비스는 표시되는 리소스를 공개적으로 캐시합니다. 예를 들어 Cloud Storage는 공개적으로 읽기 가능한 객체를 캐시합니다.

주 구성원 액세스 경계를 이용해서 공개적으로 표시되는 리소스가 자격 없는 주 구성원에게 표시되지 않도록 방지할 수 있는지 여부는 리소스가 캐시되었는지 여부에 따라 달라집니다.

• 리소스가 캐시되었으면 주 구성원 액세스 경계를 통해 주 구성원이 리소스를 보지 못하도록 방지할 수 없습니다.
• 리소스가 캐시되지 않았으면 주 구성원 액세스를 통해 자격 없는 주 구성원이 리소스를 보지 못하도록 방지할 수 있습니다.

모든 경우에 주 구성원 액세스 경계 정책은 자격 없는 주 구성원이 공개적으로 표시되는 리소스를 수정하거나 삭제하지 못하도록 방지합니다.

주 구성원 액세스 경계 정책의 구조

주 구성원 액세스 경계 정책은 메타데이터 및 주 구성원 액세스 경계 정책 세부정보를 컬렉션으로 합한 것입니다. 메타데이터는 정책 이름, 정책 생성 시간과 같은 정보를 제공합니다. 정책 세부정보는 영향을 받는 주 구성원에게 액세스 자격이 있는 리소스를 식별하는 등 정책의 기능을 정의합니다.

예를 들어 다음 주 구성원 액세스 경계 정책은 정책이 적용되는 주 구성원에게 ID가 0123456789012인 조직의 리소스 액세스 자격을 부여합니다.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

다음 섹션에서는 주 구성원 액세스 경계 정책의 메타데이터의 필드와 세부정보에 대해 설명합니다.

메타데이터

주 구성원 액세스 경계 정책에는 다음과 같은 메타데이터가 포함됩니다.

• name: 주 구성원 액세스 경계 정책의 이름입니다. 이 이름의 형식은 organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID입니다. 여기서 ORGANIZATION_ID는 주 구성원 액세스 경계 정책이 생성된 조직의 숫자 ID이고 PAB_POLICY_ID는 주 구성원 액세스 경계 정책의 영숫자 ID입니다.
• uid: 주 구성원 액세스 경계 정책에 할당된 고유 ID입니다.
• etag: 정책의 현재 상태를 나타내는 식별자입니다. 이 값은 정책을 업데이트할 때 변경됩니다. 업데이트 충돌을 방지하려면 etag 값이 IAM에 저장된 값과 일치해야 합니다. etag 값이 일치하지 않으면 요청이 실패합니다.
• displayName: 주 구성원 액세스 경계 정책에 대한 인간이 읽을 수 있는 이름입니다.
• annotations: 선택사항. 사용자 정의 키-값 쌍 목록입니다. 정책을 만든 사람 또는 정책이 자동 파이프라인으로 배포되었는지 여부와 같이 이러한 주석을 사용해서 정책에 메타데이터를 추가할 수 있습니다. 주석에 대한 자세한 내용은 주석을 참조하세요.
• createTime: 주 구성원 액세스 경계 정책이 생성된 시간입니다.
• updateTime: 주 구성원 액세스 경계 정책이 마지막으로 업데이트된 시간입니다.

세부정보

각각의 주 구성원 액세스 경계 정책에는 details 필드가 포함됩니다. 이 필드에는 주 구성원 액세스 경계 규칙 및 시행 버전이 포함됩니다.

• rules: 영향을 받는 주 구성원에게 액세스 자격이 있는 리소스를 정의하는 주 구성원 액세스 경계 규칙의 목록입니다. 각 규칙에는 다음 필드가 포함됩니다.

  • description: 규칙에 대한 인간이 읽을 수 있는 설명입니다.

  • resources: 주 구성원에게 액세스 자격을 부여하려는 Resource Manager 리소스(프로젝트, 폴더, 조직) 목록입니다. 이 정책이 적용되는 주 구성원에게 이러한 리소스에 대한 액세스 자격이 부여됩니다.

    각 주 구성원 액세스 경계 정책은 정책의 모든 규칙에서 최대 500개 리소스를 참조할 수 있습니다.

  • effect: 주 구성원이 resources 필드에 나열된 리소스에 대해 갖는 관계입니다. 주 구성원 액세스 경계 정책 규칙에서 지정할 수 있는 유일한 효과는 "ALLOW"입니다. 이 관계는 주 구성원에게 규칙에 나열된 리소스에 대한 액세스 자격을 부여합니다.

• enforcementVersion: 정책을 적용할 때 IAM에 사용되는 시행 버전입니다. 주 구성원 액세스 경계 정책 버전은 주 구성원 액세스 경계 정책이 차단할 수 있는 권한을 결정합니다.

  주 구성원 액세스 경계 정책 버전에 대한 자세한 내용은 이 페이지에서 주 구성원 액세스 경계 시행 버전을 참조하세요.

정책 바인딩의 구조

주 구성원 액세스 경계 정책의 정책 바인딩에는 정책 이름, 정책을 바인딩할 주 구성원 집합 이름, 정책 바인딩을 설명하는 메타데이터가 포함됩니다. 정책이 적용되는 정확한 주 구성원을 수정하는 조건도 포함될 수 있습니다.

예를 들어 다음 정책 바인딩은 example-policy 정책을 ID가 0123456789012인 example.com 조직의 모든 주 구성원에 바인딩합니다. 정책 바인딩에는 또한 [e-mail] 주 구성원에 대해 정책이 시행되지 않도록 방지하는 조건이 포함됩니다.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

각 정책 바인딩에는 다음 필드가 포함됩니다.

• name: 정책 바인딩의 이름입니다. 이 이름의 형식은 RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID입니다. 여기서 RESOURCE_TYPE/RESOURCE_ID는 정책 바인딩의 상위 리소스의 ID이고 BINDING_ID는 정책 바인딩의 영숫자 ID입니다.
• uid: 정책 바인딩에 할당된 고유 ID입니다.
• etag: 정책의 현재 상태를 나타내는 식별자입니다. 이 값은 정책을 업데이트할 때 변경됩니다. 업데이트 충돌을 방지하려면 etag 값이 IAM에 저장된 값과 일치해야 합니다. etag 값이 일치하지 않으면 요청이 실패합니다.
• displayName: 정책 바인딩에 대한 인간이 읽을 수 있는 이름입니다.
• annotations: 선택사항. 사용자 정의 키-값 쌍 목록입니다. 정책 바인딩을 만든 사람 또는 정책 바인딩이 자동 파이프라인으로 배포되었는지 여부와 같이 이러한 주석을 사용해서 정책 바인딩에 메타데이터를 추가할 수 있습니다. 주석에 대한 자세한 내용은 주석을 참조하세요.

• target: 정책을 바인딩할 주 구성원 집합입니다. 값의 형식은 {"principalSet": PRINCIPAL_SET}입니다. 여기서 PRINCIPAL_SET는 정책을 바인딩하려는 주 구성원 집합의 ID입니다.

  각 대상에는 최대 10개의 정책이 바인딩될 수 있습니다.

• policyKind: 정책 바인딩이 참조하는 정책 유형입니다. 주 구성원 액세스 경계 정책의 정책 바인딩에서 이 값은 항상 PRINCIPAL_ACCESS_BOUNDARY입니다.

• policy: 대상 주 구성원 집합에 바인딩할 주 구성원 액세스 경계 정책입니다.

• policyUid: policy 필드에서 참조되는 주 구성원 액세스 경계 정책에 할당된 고유 ID입니다.

• condition: 선택사항. IAM이 정책을 시행하는 주 구성원에 영향을 주는 논리 표현식입니다. 조건이 true로 평가되거나 조건을 평가할 수 없으면 Identity and Access Management가 요청을 수행하는 주 구성원에 대해 정책을 시행합니다. 조건이 false로 평가되면 Identity and Access Management가 주 구성원에 대해 정책을 시행하지 않습니다. 자세한 내용은 이 페이지에서 주 구성원 액세스 경계 및 조건을 참조하세요.

• createTime: 정책 바인딩이 생성된 시간입니다.

• updateTime: 정책 바인딩이 마지막으로 업데이트된 시간입니다.

사용 사례

다음은 주 구성원 액세스 경계 정책을 사용하려는 일반적인 상황과 각 상황에서 만들 수 있는 주 구성원 액세스 경계 정책 및 정책 바인딩 예시를 보여줍니다. 주 구성원 액세스 경계 정책을 만들고 이를 주 구성원 집합에 바인딩하는 방법은 주 구성원 액세스 경계 정책 만들기 및 적용을 참조하세요.

주 구성원을 조직의 리소스로 제한

주 구성원 액세스 경계 정책을 사용해서 조직의 주 구성원에게 조직 내 리소스에 대한 액세스 자격만 부여되도록 제한할 수 있습니다.

예를 들어 example.com 조직의 모든 주 구성원에게 example.com 내 리소스에 대한 액세스 자격만 부여되도록 제한한다고 가정해 보세요. example.com에 있는 주 구성원에는 example.com 도메인의 모든 ID, example.com의 모든 인력 ID 풀, example.com에 있는 프로젝트의 모든 서비스 계정 및 워크로드 아이덴티티 풀이 포함됩니다.

조직의 주 구성원에 적용되는 주 구성원 액세스 경계 정책은 없습니다. 따라서 모든 주 구성원에게 모든 리소스에 대한 액세스 자격이 부여됩니다.

주 구성원이 example.com 외부 리소스에 대해 액세스 자격을 얻지 못하도록 하려면 주 구성원에게 example.com의 리소스에 대해 액세스 자격을 부여하는 주 구성원 액세스 경계 정책을 만듭니다.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

그런 후 이 정책을 주 구성원 집합에 바인딩하는 정책 바인딩을 만듭니다.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

그러면 이제 example.com의 모든 주 구성원에게는 example.com 내에서만 리소스에 대해 액세스 자격이 부여됩니다. 리소스에 대한 액세스 권한이 있더라도 주 구성원 액세스 경계 정책에 의해 차단된 권한을 사용하여 example.com 외부의 리소스에 액세스하는 것이 제한됩니다.

서비스 계정을 단일 프로젝트의 리소스로 제한

주 구성원 액세스 경계 정책을 사용하면 특정 프로젝트의 서비스 계정에게 해당 프로젝트 내에서만 리소스 액세스 자격이 부여되도록 할 수 있습니다.

예를 들어 example-dev 프로젝트가 있다고 가정해 보세요. example-dev의 서비스 계정에 대해 example-dev의 리소스에 대해서만 액세스 자격을 부여해야 합니다.

example-dev의 서비스 계정을 포함하여 조직의 모든 주 구성원에게 example.com의 리소스 액세스 자격을 부여하는 주 구성원 액세스 경계 정책이 있습니다. 이 정책 유형의 구성을 보려면 조직의 리소스로 주 구성원 제한을 참조하세요.

example-dev의 서비스 계정에 example-dev 외부 리소스에 대한 리소스 액세스 자격을 부여하지 않으려면 먼저 주 구성원에게 example-dev의 리소스 액세스 자격을 부여하는 주 구성원 액세스 경계 정책을 만들어야 합니다

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

그런 후 example-dev에서 모든 주 구성원에 이 정책을 바인딩하는 정책 바인딩을 만들어서 정책 바인딩이 서비스 계정에만 적용되도록 합니다.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

하지만 이 정책은 자체적으로 서비스 계정의 자격을 제한하지 않습니다. 이는 example.com의 모든 주 구성원에 example.com의 모든 리소스에 대한 액세스 자격을 부여하는 기존 주 구성원 액세스 경계 정책이 있기 때문입니다. 주 구성원 액세스 경계 정책은 추가적으로 적용됩니다. 즉, example-dev의 서비스 계정에 여전히 example.com의 모든 리소스에 대한 액세스 자격이 부여됩니다.

example-dev의 서비스 계정에 대해 example-dev의 리소스에 대해서만 액세스 자격을 부여하려면 기존 주 구성원 액세스 경계 정책의 정책 바인딩에 example-dev의 서비스 계정에 대해 적용하지 않도록 방지하는 조건을 추가해야 합니다.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

이제 example-dev의 서비스 계정에는 example-dev의 리소스에 대해서만 액세스 자격이 부여됩니다. 리소스에 대한 액세스 권한이 있더라도 주 구성원 액세스 경계 정책에 의해 차단된 권한을 사용하여 example-dev 외부의 리소스에 액세스하는 것이 제한됩니다.

다음 단계

• 주 구성원 액세스 경계 정책 만들기 및 적용 방법 알아보기
• 각 주 구성원 액세스 경계 정책 시행 버전이 차단하는 권한 검토