이 주제에서는 몇 가지 샘플 결제 시나리오에서 Identity and Access Management(IAM) 권한을 구성하는 방법을 보여줍니다. 또한 각 시나리오에서 회사의 결제 관련 직책에 어떠한 IAM 역할을 부여해야 하는지도 설명합니다. 이 문서의 예시는 주로 결제 관리자 및 조직의 결제 작업을 관리하는 직원을 대상으로 합니다.
결제 역할 및 권한에 대해서는 이 문서에서 자세히 설명하지 않습니다. Billing API의 역할 및 권한에 대한 자세한 내용은 결제 액세스 제어 페이지를 참조하세요.
결제 권한을 구성하는 소규모 회사
이 시나리오에서는 Google 결제 계정을 구성하려 하는 소기업을 다룹니다. 이 회사에는 애플리케이션을 개발하고 유지보수하는 엔지니어 소수가 근무하지만 결제 관리 담당자가 없습니다. 대신 지급 내역과 인보이스를 대조하는 사무장이 있습니다. 하지만 규정 준수를 위해 사무장은 프로젝트의 Google Cloud 리소스에 액세스할 수 없습니다. 또한 CEO가 신용카드 세부정보를 직접 관리합니다.
아래 표에서는 조직 관리자(이 시나리오에서는 CEO)가 회사 내 다른 사람에게 부여할 수 있는 결제 IAM 역할과 이러한 역할을 부여하는 리소스 수준을 설명합니다.
역할: | 조직 관리자 | CEO는 조직 관리자 역할을 가지므로 오피스 매니저에게 권한을 할당할 수 있습니다. |
---|---|---|
리소스: | 조직 | |
주 구성원: | CEO |
역할: | 결제 계정 관리자 | 오피스 매니저와 CEO는 결제 계정 관리자 역할을 통해 프로젝트 콘텐츠를 볼 수 있는 권한을 부여받지 않고도 결제와 송장을 관리할 수 있습니다. |
---|---|---|
리소스: | 조직 | |
주 구성원: | 오피스 매니저, CEO |
이 시나리오에서 조직 리소스에 연결되는 허용 정책은 다음과 유사합니다.
{
"bindings": [
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"user:ceo@example.com"
]
},
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
}
]
}
그룹을 사용하여 주 구성원을 관리하는 것이 좋습니다. 위의 예시에 있는 두 번째 결합에서는 finance-admins-group
에 CEO와 오피스 매니저를 추가하면 됩니다. 특정 직무를 수행할 수 있는 직원을 수정해야 하는 경우 허용 정책을 업데이트할 필요 없이 그룹 소속 관계만 조정하면 됩니다. 따라서 개별 사용자 계정은 역할 결합에 나타나지 않습니다.
예산을 관리하는 재무팀
이 시나리오에서는 각 부서의 재무팀이 Google Cloud 리소스에는 액세스하지 않으면서 예산을 설정하고 부서의 팀 지출을 확인할 수 있게 하려는 대규모 조직을 다룹니다. 개발자가 자신의 프로젝트 지출을 확인할 수 있어도 전체 비용 규모를 확인할 수 없도록 해야 합니다.
각 부서의 재무 담당자와 개발자에게 아래 표와 같이 역할을 부여합니다.
역할: | 결제 계정 관리자 | 이 역할은 각 부서의 재무 담당자에게 예산을 설정하고 결제 계정의 지출을 확인할 수 있는 권한을 부여하지만 프로젝트 콘텐츠를 볼 수 있는 권한을 부여하지 않습니다. |
---|---|---|
리소스: | 결제 계정 | |
주 구성원: | 각 부서의 재무 담당자 |
역할: | 결제 계정 뷰어 | 결제 계정 뷰어 역할을 통해 개발자가 결제 계정의 비용을 볼 수 있습니다. |
---|---|---|
리소스: | 결제 계정 | |
주 구성원: | 프로젝트 개발자 |
이 시나리오에서는 결제 콘솔을 사용하여 재무 관리자에게 결제 계정에 대한 결제 계정 관리자 역할을 부여합니다. 또한 개발자에게 결제 계정에 대한 결제 계정 뷰어 역할을 부여합니다.
완료되면 결제 계정의 허용 정책이 다음과 비슷하게 표시됩니다.
{
"bindings": [
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
},
{
"role": "roles/billing.viewer",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
고객 셀프서비스 포털, 개발자가 결제 조정 불가능
이 시나리오에서는 고객의 중앙 IT 팀이 셀프 서비스 포털의 일부로 개발자에게 Google Cloud 리소스를 제공합니다. 개발자는 포털을 통해 Google Cloud 프로젝트 및 기타 승인된 클라우드 서비스에 대한 액세스를 요청합니다. 개발자 비용 센터에서 소비한 클라우드 리소스에 대한 비용을 중앙 IT팀에 지불합니다.
중앙 IT팀에는 다음과 같은 권한이 있어야 합니다.
- 프로젝트를 결제 계정에 연결
- 프로젝트 결제 중지
- 신용카드 정보 확인
프로젝트 콘텐츠를 볼 수 있는 권한은 없어야 합니다.
개발자는 소비되는 Google Cloud 리소스의 실제 비용을 볼 수 있어야 하지만 결제를 사용 중지하고, 결재를 프로젝트와 연결하고, 신용 카드 정보를 볼 수 없어야 합니다.
역할: | 결제 계정 관리자 | 결제 관리자 역할은 IT 부서에 프로젝트를 결제 계정에 연결하고, 프로젝트 결제를 중지하고, 고객에게 재판매하는 계정의 신용카드 정보를 볼 수 있는 권한을 부여합니다. 프로젝트 콘텐츠를 볼 수 있는 권한을 부여하지 않습니다. |
---|---|---|
리소스: | 결제 계정 | |
주 구성원: | IT 부서 |
역할: | 결제 계정 사용자 | 결제 계정 사용자 역할은 서비스 계정에 결제(프로젝트를 조직의 모든 프로젝트의 조직의 결제 계정과 연결)를 사용 설정하여 서비스 계정에서 결제가 필요한 API를 사용 설정할 수 있는 권한을 부여합니다. |
---|---|---|
리소스: | 조직 | |
주 구성원: | 프로젝트 생성을 자동화하는 데 사용되는 서비스 계정 |
역할: | 결제 계정 뷰어 | 결제 계정 뷰어 역할을 통해 개발자가 결제 계정의 비용을 볼 수 있습니다. |
---|---|---|
리소스: | 결제 계정 | |
주 구성원: | 프로젝트 개발자 |
이 시나리오에서는 허용 정책이 계층 구조의 서로 다른 수준에 연결되어 있으므로 적절한 할당 작업을 두 번 수행해야 합니다.
결제 콘솔을 사용하여 IT 부서에 결제 계정에 대한 결제 계정 관리자 역할을 부여합니다. 또한 개발자에게 결제 계정에 대한 결제 계정 뷰어 역할을 부여합니다.
그런 후 조직 수준에서 허용 정책을 연결해야 합니다. 이 허용 정책은 서비스 계정에 대한 결제 계정 사용자 역할을 부여합니다. 다음과 비슷합니다.
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
}
],
"etag": "BwWKmjvelug=",
"version": 1
}
결제 대상 프로젝트를 만드는 개발자
대형 디지털 네이티브에서 모든 개발자가 조직의 인보이스 계정에 결제 대상 프로젝트를 만들 수 있도록 허용하지만 결제 관리자 권한을 개발자에게 부여하지 않으려고 합니다.
프로젝트에서 결제를 사용 설정해야 기본값 이외의 API를 사용 설정할 수 있습니다. 따라서 개발자가 프로젝트를 만든 경우 API를 사용 설정하려면 프로젝트를 결제 계정에 연결해야 합니다.
역할: | 결제 계정 사용자 | 결제 계정 사용자 역할을 통해 개발자는 결제 계정을 조직 내의 새 프로젝트에 연결할 수 있습니다. |
---|---|---|
리소스: | 조직 | |
주 구성원: | 개발자 |
이 시나리오의 허용 정책은 조직 수준에서 연결되어야 하며 다음과 유사합니다.
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
비용 집계
이 시나리오에서는 팀별, 부서별, 서비스별 또는 프로젝트별 발생 비용을 계산하고 추적하려는 기업을 설명합니다. 예를 들어 테스트 배포 비용을 월 단위로 추적할 수 있습니다.
이러한 비용을 추적하는 방법은 다음과 같습니다.
- 프로젝트를 사용하여 리소스를 체계적으로 정리합니다. 프로젝트별 비용이 표시되며 결제 내보내기에는 프로젝트 ID가 포함됩니다.
- 프로젝트에 추가 그룹화 정보를 나타내는 라벨을 붙입니다. 예를 들어
environment=test
와 같은 라벨을 붙이면 결제 내보내기에 이 라벨이 포함되어 상세한 분석이 가능해집니다. 그러나 프로젝트의 라벨에는 프로젝트의 나머지 메타데이터와 동일한 권한이 적용되므로 프로젝트 소유자라면 누구나 라벨을 변경할 수 있습니다. 변경하지 말아야 하는 항목을 직원에게 교육하고 감사 로그를 통해 모니터링할 수도 있고, 프로젝트 메타데이터를 변경할 수 없도록 세분화된 권한만 부여할 수도 있습니다.
JSON 및 CSV로 내보낼 수 있지만, 권장되는 솔루션은 BigQuery로 직접 내보내는 것입니다. 이 기능은 결제 콘솔의 결제 내보내기 섹션에서 손쉽게 구성할 수 있습니다.
각 비용 센터에서 특정 작업 부하에 대해 별도의 인보이스를 결제하거나 다른 통화로 결제해야 하는 경우 비용 센터마다 다른 결제 계정이 필요합니다. 그러나 이 방식을 사용하려면 각 결제 계정에서 연결 동의서를 서명해야 합니다.