주 구성원 액세스 경계 정책의 사용 사례 예

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

조직 외부 사용자가 리소스에 액세스하지 못하도록 방지

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

리소스에 대한 액세스를 방지하는 주 구성원 액세스 경계 정책

리소스에 대한 액세스를 방지하는 주 구성원 액세스 경계 정책

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

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

하지만 주 구성원 액세스 경계 정책을 사용하면 example.com 관리자는 탈이 cymbalgroup.com 버킷이나 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": "4"
  }
}

그런 다음 조직 example.com의 모든 주 구성원에 이 정책을 연결하는 정책 바인딩을 만들면 됩니다.

{
  "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 도메인의 모든 ID, example.com의 모든 직원 ID 풀, example.com에 있는 프로젝트의 모든 서비스 계정 및 워크로드 아이덴티티 풀이 포함됩니다.

이 정책이 적용되면 example.com의 주 구성원은 주 구성원 액세스 경계 정책으로 차단되는 권한을 사용해서는 example.com 외부 리소스에 액세스할 수 없습니다. 해당 리소스에 대한 권한이 있더라도 마찬가지입니다.

이 경우 주 구성원 액세스 경계 정책은 적용 버전 4을 사용하므로 storage.objects.get 권한을 차단할 수 있습니다. 따라서 탈에게 버킷에 대한 스토리지 관리자 역할이 부여되더라도 cymbalgroup.com 버킷의 객체를 볼 수 없습니다.

서비스 계정에 단일 프로젝트의 리소스에 대한 자격 부여

주 구성원 액세스 경계 정책을 사용하여 주 구성원의 하위 집합에 조직의 리소스 하위 집합에 대한 액세스 자격을 부여할 수도 있습니다.

예를 들어 프로젝트 번호가 901234567890인 example-dev 프로젝트가 있다고 가정해 보겠습니다. example-dev의 서비스 계정은 example-dev의 리소스에만 액세스할 수 있게 하려고 합니다.

이렇게 하려면 먼저 새로운 주 구성원 액세스 경계 정책을 만들어 주 구성원이 dev-project의 리소스에 액세스할 수 있게 합니다.

{
  "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": "4"
  }
}

이 주 구성원 액세스 경계 정책은 적용 버전 4을 사용하므로 적용 버전 4에서 지원되는 모든 권한을 차단할 수 있습니다.

주 구성원 액세스 경계 정책을 만든 후에는 정책 바인딩을 만들어 새 정책을 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-dev 외부의 리소스에 액세스할 수 없습니다.

여러 주 구성원 그룹의 자격 관리

동일한 조직에서 여러 주 구성원 액세스 경계 정책을 사용하여 여러 주 구성원이 여러 리소스에 액세스할 수 있도록 할 수 있습니다. 여러 주 구성원 액세스 경계 정책을 사용하는 경우 정책 바인딩의 조건을 사용하여 각 정책이 적용되도록 하려는 주 구성원에만 적용되도록 합니다.

예를 들어 조직 외부 사용자가 리소스에 액세스하지 못하도록 방지에서와 같이 대부분의 주 구성원이 조직의 모든 리소스에 액세스할 수 있도록 하려고 한다고 가정해 보겠습니다. 하지만 단일 프로젝트의 리소스에 서비스 계정에 대한 자격 부여에서와 같이 example-dev의 서비스 계정은 example-dev의 리소스에만 액세스할 수 있도록 하려고 합니다.

이 목표를 달성하려면 다음 단계를 따르세요.

  1. 조직 외부 사용자가 리소스에 액세스하지 못하도록 방지 의 예시에 따라 주 구성원이 example.com 의 리소스에 액세스할 수 있게 하는 주 구성원 액세스 경계 정책을 만들고 조직 주 구성원 집합에 바인딩합니다.

  2. 단일 프로젝트의 리소스에 서비스 계정에 대한 자격 부여의 예시에 따라 서비스 계정에 대한 자격 부여 를 만들고 example-dev의 서비스 계정이 example-dev의 리소스에 액세스할 수 있게 하는 주 구성원 액세스 경계 정책을 만들고 example-dev의 서비스 계정에 바인딩합니다.

  3. 주 구성원이 example.com의 모든 리소스에 액세스할 수 있게 해주는 주 구성원 액세스 경계 정책에서 example-dev의 서비스 계정을 제외합니다. 이렇게 하려면 주 구성원 액세스 경계 정책을 조직의 주 구성원 집합에 연결하는 정책 바인딩에 다음 조건을 추가합니다.

    "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') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

이 마지막 단계는 매우 중요합니다. 초기 주 구성원 액세스 경계 정책에서 example-dev 서비스 계정을 제외하지 않으면 해당 정책은 적용되는 다른 주 구성원 액세스 경계 정책과 관계없이 example.com의 모든 리소스에 액세스할 수 있도록 합니다. 자세한 내용은 액세스할 수 있는 리소스 정의를 참조하세요.

또한 초기 주 구성원 액세스 경계 정책에서 example-dev 서비스 계정을 제외하기 전에 새 주 구성원 액세스 경계 정책을 만들고 연결하는 것이 중요합니다. 이 절차를 따르면 서비스 계정에 항상 하나 이상의 주 구성원 액세스 경계 정책이 적용되어 모든 리소스 Google Cloud에 액세스할 수 없게 됩니다. 주 구성원이 액세스할 수 있는 리소스를 안전하게 줄이는 방법에 대한 자세한 내용은 주 구성원이 액세스할 수 있는 리소스 감소를 참조하세요.

다음 단계