Google PCA: 조직 설계, IAM 및 클라우드 거버넌스 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Architect — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

조직 설계, IAM, 거버넌스는 모든 Google Cloud 아키텍처가 실행되는 기반을 구축합니다. 좋은 설계는 명확한 관리 경계를 만들고, 영향 범위(blast radius)를 최소화하며, 최소 권한 원칙을 가능하게 하고, 비용을 제어하며, 여러 팀과 환경에 걸쳐 운영을 확장할 수 있도록 합니다. 거버넌스는 게이트(차단) 방식보다는 가드레일(안전장치) 방식을 강조해야 합니다. 즉, 안전하고 측정 가능하며 되돌릴 수 있는 기본값을 자동화하는 동시에, 일상적인 제어는 워크로드에 가장 가까운 팀에 위임해야 합니다.

리소스 계층 구조 및 ID 기반

Google Cloud 리소스는 조직(Organization) → 폴더(Folders) → 프로젝트(Projects) → 리소스(예: Compute Engine 인스턴스, 버킷)의 엄격한 트리 구조를 형성합니다. IAM 정책과 조직 정책(Organization Policy) 제약 조건은 이 트리를 따라 하위로 상속됩니다.

주요 설계 원칙:

• 단일 조직(Organization)을 사용하여 거버넌스를 중앙 집중화합니다. 최상위 폴더(Folder)를 주요 관리 경계(예: 사업부, 리전, 또는 규제 대상 vs. 비규제 대상)에 따라 생성합니다.
• 각 경계 내에 환경 폴더(prod, nonprod)를 생성하여 차별화된 정책을 적용합니다. 프로젝트는 가능한 한 워크로드 범위로 유지하고 임시적으로(ephemeral) 사용하여 영향 범위를 줄이고 비용 정산(chargeback)을 용이하게 합니다.
• 상속: 허용(allow) 권한은 누적됩니다(상위 계층과 해당 노드의 허용 바인딩의 합집합). IAM 거부(Deny) 정책을 사용하는 경우, 이 정책이 우선 적용되어 허용 권한이 존재하더라도 액세스를 차단할 수 있습니다. 트리 상위 계층에 광범위한 역할을 배치하는 것을 피하십시오. 영향 범위가 크고 되돌리기 어렵습니다.

ID 소스:

• Cloud Identity는 직원 ID 관리 플레인입니다. 엔터프라이즈 IdP(SAML/OIDC)와 통합하여 인증 및 수명 주기(입사자, 이동자, 퇴사자) 관리를 중앙 집중화합니다. 필요한 경우 Google Cloud Directory Sync를 사용하여 속성 및 그룹 동기화를 수행합니다.
• 그룹은 주요 IAM 주체(subject)입니다. 그룹 기반 액세스는 확장 가능한 변경과 감사 가능한 소유권 관리를 가능하게 합니다. 그룹-속-그룹 패턴(예: net-admins, sec-admins, app-team-A)을 사용하고 그룹 구성원 관리 권한을 제한합니다.
• 서비스 계정은 워크로드를 나타냅니다. 저장된 키 대신 단기 수명 사용자 인증 정보를 사용하는 서비스 계정 가장(impersonation)을 선호합니다. 사용자 관리 서비스 계정 키 사용을 피하고, 이를 예외적인 경우로 취급하여 엄격한 승인 및 교체 주기를 적용합니다.
• 워크로드 아이덴티티 패턴:
  • GKE Workload Identity는 Kubernetes 서비스 계정을 Google 서비스 계정에 바인딩하여 노드 전체에 적용되는 사용자 인증 정보를 제거합니다.
  • Workload Identity Federation은 외부 ID(온프레미스, 다른 클라우드, GitHub Actions)가 키 없이 단기 수명 Google 액세스 권한을 얻을 수 있도록 합니다. 풀/공급업체 범위 지정 및 속성 조건을 사용하여 액세스를 제한합니다.

일반적인 실패 모드 및 완화 조치:

• 폴더 또는 조직 수준에서 기본 역할(소유자/편집자/뷰어)을 부여하면 광범위한 과잉 권한으로 이어집니다. 엄격하게 범위가 지정된 비상 접근(break-glass) 프로젝트에서만 사용하십시오.
• 소유권이 불분명한 그룹 난립은 최소 권한 원칙을 훼손합니다. 그룹에 이름 지정 규칙, 용도 태그, 소유자 메타데이터를 강제합니다.
• 고아 서비스 계정(Orphaned service accounts)과 오래된 바인딩은 위험을 누적시킵니다. 정기적인 액세스 검토를 예약하고 IAM Recommender를 사용하여 사용하지 않는 권한을 줄입니다.

IAM 모델, 역할 및 액세스 작업

역할 및 바인딩:

• 사전 정의된 역할은 특정 서비스에 맞게 선별되었으므로 기본 선택 사항이 되어야 합니다.
• 커스텀 역할은 사전 정의된 역할이 너무 광범위할 때 그 간극을 메웁니다. 필요하다고 관찰된 최소한의 권한 집합으로 구성하고, 버전 관리 및 테스트를 수행합니다.
• 기본 역할(뷰어/편집자/소유자)은 레거시이며 지나치게 광범위합니다. 조직 및 폴더 범위에서는 사용을 피하십시오. 일상적인 작업에 소유자 역할을 사용하지 말고, 강력한 보상 통제(compensating controls)와 함께 플랫폼 비상 접근(break-glass)용으로 남겨두십시오.
• 조건부 역할 바인딩(IAM Conditions)은 resource.name, resource.matchTag, request.time 또는 request.auth.audiences와 같은 속성을 사용하여 바인딩이 적용되는 시점과 위치를 제한합니다. 시간 제한 액세스, prod 환경에 대한 태그 범위 액세스 또는 위치 제한 작업에 조건을 사용합니다.

최소 권한 및 권한 상승:

• “읽기”, “운영”, “관리” 직무를 분리합니다. 예를 들어, 네트워크, 보안, 앱 팀은 각각 다른 범위에서 다른 역할을 부여받습니다.
• Access Approval 워크플로나 티켓 기반 자동화를 통해 Just-in-Time(JIT) 권한 상승을 사용하여 조건을 통해 시간 제한 역할을 바인딩합니다.

거부(Deny) 정책 및 위험 요소:

• IAM Deny는 중앙에서 위험한 권한(예: resourcemanager.projects.delete)을 차단할 수 있습니다. 거부(Deny)는 허용(allow)을 재정의하며 전체 하위 트리에 적용됩니다. 철저히 검증하십시오. 잘못 구성된 거부 정책은 자동화를 차단하거나 배포를 중단시킬 수 있습니다.

감사 가능성 및 검토:

• 조직 수준에서 관리자 활동(Admin Activity) 로그를 활성화하십시오. 이 로그는 기본적으로 400일 동안 보관됩니다. 민감한 서비스의 경우, 데이터 액세스(Data Access) 로그를 활성화하고 장기 보관 및 감사를 위해 BigQuery로 라우팅하십시오.
• 주기적인 액세스 검토를 구현하십시오: Cloud Asset Inventory로 바인딩을 열거하고, 소유권 레지스트리와 비교하며, IAM Recommender가 제안하는 미사용 역할을 제거하고, 예외 만료를 확인합니다.

유용한 예시 (시간 및 태그 범위가 지정된 바인딩):

undefined

재무 거버넌스 및 조직 정책 가드레일

결제 아키텍처:

• 하나 이상의 결제 계정을 재무팀 소유로 중앙 집중화합니다. 법적으로나 운영상으로 필요한 경우(예: 별도 법인 또는 리셀러 모델)에만 여러 결제 계정을 사용합니다.
• 자동화를 통해 프로젝트를 결제 계정에 연결합니다. 승인된 워크플로 외부에서의 수동 연결은 허용하지 않습니다.

비용 청구 및 가시성:

• 라벨과 비용 할당 태그를 일관되게 사용합니다. 라벨은 필터링 및 보고를 위한 자유 형식 메타데이터이며, 태그는 계층적이며 IAM Conditions 및 정책에서 사용할 수 있습니다. 선택한 태그에 대해 비용 할당을 활성화하여 결제 내보내기(billing export)에 표시되도록 합니다.
• 분석을 위해 결제 데이터를 BigQuery로 내보냅니다. 소유자, 비용 센터, 환경별로 대시보드를 구축합니다. 각 프로젝트에 책임 있는 소유자와 예산이 있도록 요구합니다.

예산 및 이상 감지:

• 폴더 및 프로젝트 수준에서 알림이 포함된 예산을 생성합니다. 과도한 지출을 억제하기 위해 프로그래밍 방식의 대응(예: 담당자 알림, 티켓 생성 또는 신규 할당량 증가 비활성화)을 추가합니다.
• 예상 사용량에 맞춰 할당량(Quotas) 및 약정 사용 할인(CUD)을 사용하고 사용률을 모니터링합니다.

조직 정책 제약 조건 (기본적으로 보안):

• 조직 또는 폴더 수준에서 가드레일을 적용하고, 정당한 경우에만 완화합니다. 일반적인 제약 조건:
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects로 VM 이미지 제한
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• 민감한 경계 전반에 걸쳐 지원되는 서비스의 데이터 유출 위험을 줄이기 위해 VPC Service Controls를 사용합니다.

정책 예외 처리:

• 예외는 요청 가능하고, 승인되고, 시간제한이 있으며, 감사 가능해야 합니다. 태그/시간별로 예외 범위를 지정하기 위해 IAM Conditions를 사용하는 것을 선호합니다. 주기적으로 예외를 조정하고 Policy-as-Code 파이프라인을 통해 자동으로 만료시킵니다.

서비스 계정 키 생성을 비활성화하는 조직 정책 예시 (YAML):

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true 그다음 적용: gcloud org-policies set-policy policy.yaml

랜딩 존, 공유 서비스, 자동화 및 운영 모델

랜딩 존:

• 사전 강화된 기준선 제공: Organization Policies, 로깅 싱크, CMEK 전략, Shared VPC, 비공개 DNS, Cloud NAT, Private Service Connect, 감사 및 보안 프로젝트, 제한된 이미지 카탈로그.
• Shared VPC를 위해 환경별로 호스트 프로젝트 분리. 네트워크 관리자는 호스트 프로젝트를 제어하고, 애플리케이션 팀은 올바른 호스트에 연결된 서비스 프로젝트에 배포합니다.

프로젝트 팩토리:

• IaC(Infrastructure-as-Code)를 사용하여 프로젝트 생성 자동화. 다음을 포함하여 프로젝트를 찍어내듯이 생성합니다:
  • 올바른 Folder 배치 및 결제 계정 연결
  • 사전 바인딩된 그룹 및 역할
  • 기본 서비스 계정 비활성화 또는 제한
  • 중앙 프로젝트 및 보관 버킷으로 로깅 싱크 설정
  • 사전 정의된 예산, 라벨, 태그
• Terraform 모듈 또는 Cloud Config Controller를 사용하여 팩토리 코드를 작성합니다. CI에서 변경 사항을 적용하기 전에 정책 유효성 검사를 강제합니다.

공유 서비스 및 격리:

• ID, 네트워킹, CI/CD, 아티팩트 레지스트리, 보안 도구를 전용 프로젝트에 중앙화합니다. Folder 및 VPC별로 환경을 격리하고, 방화벽 정책, 별도의 서비스 경계, 환경별 개별 Cloud KMS 키링으로 수평적 이동을 차단합니다.
• Private Service Connect와 생산자 프로젝트를 사용하여 공개 엔드포인트를 노출하지 않고 소비자에게 공유 서비스를 게시합니다.

감사 로깅 및 거버넌스 자동화:

• 관리자 활동 및 데이터 액세스 로그를 감사 프로젝트로 라우팅합니다. 규정 준수에 맞춰 CMEK 및 보관 정책으로 로그 버킷을 구성합니다.
• Cloud Asset Inventory 피드를 Pub/Sub으로 보내고 Cloud Functions/Cloud Run을 사용하여 구성 편차(예: 공개 버킷)를 감지하고 자동으로 수정하거나 티켓을 엽니다.
• Policy-as-Code 스택:
  • 리포지토리에 저장된 코드 형식의 Org Policies 및 IAM
  • KRM 리소스를 위한 Config Validator/Policy Controller
  • CI/CD의 배포 전 정책 확인
  • 원하는 상태를 다시 적용하기 위한 예약된 조정 작업(reconciler job)

리소스 이름 지정 및 태그:

• 환경, 앱, 리전, 시퀀스를 인코딩하는 짧고 읽기 쉬운 이름 지정 패턴을 적용합니다(예: appA-prd-usw2-web-01). 태그는 거버넌스를 위해 사용합니다(env=prod, pii=true, owner=team-x). 프로젝트 생성 시 필수 라벨/태그의 존재 여부를 확인합니다.

다중 팀 운영 및 위임된 관리:

• 명확하게 정의된 범위와 역할을 가진 플랫폼, 보안, 네트워크 팀을 구성합니다. 프로젝트 수준 관리는 Folder 경계 내에서 애플리케이션 팀에 위임합니다. 카탈로그와 템플릿을 통해 가드레일 내에서 셀프서비스를 제공합니다.
• 영향 범위(blast radius)가 작은 결정은 팀에 위임하고, 많은 프로젝트나 공유 인프라에 영향을 미치는 결정은 중앙에서 처리하여 자율성과 위험 사이의 균형을 맞춥니다.

실용적인 문제 시나리오

Contoso Retail은 3개월 이내에 8개의 제품 팀을 Google Cloud에 온보딩할 계획입니다. 각 팀은 프로덕션 및 비프로덕션 환경, 격리된 네트워킹, 중앙 집중식 보안 로깅, 비용 책임이 필요합니다. 플랫폼 팀은 서비스 계정 키 확산을 방지하고, VM 이미지를 제한하며, 인시던트 대응을 위해 시간 제한이 있는 승격된 액세스를 활성화해야 합니다.

접근 방식:

1. 계층 구조 및 폴더 설정

• 부서별 최상위 Folder와 프로덕션 및 비프로덕션용 중첩 Folder를 생성합니다. 근거: 명확한 관리 경계는 조직 전체의 권한을 부여하지 않고도 제품 팀에 위임된 관리를 가능하게 하면서 대상이 명확한 가드레일과 예산을 설정할 수 있게 합니다.

2. Shared VPC를 사용하여 랜딩 존 배포

• 네트워크 팀이 관리하는 프로덕션 및 비프로덕션 네트워크용 호스트 프로젝트를 생성합니다. Shared VPC를 통해 팀 서비스 프로젝트를 연결합니다. 근거: 워크로드를 프로젝트별로 격리하면서 라우팅, NAT, 방화벽 정책을 중앙에서 관리합니다. 이를 통해 확산과 일관성 없는 보안으로 이어지는 임시 네트워킹을 방지합니다.

3. 조직 정책 가드레일 구현

• 제약 조건 적용: 서비스 계정 키 생성 비활성화, OS Login 요구, Cloud SQL에 대한 공개 IP 제한, VM 이미지를 신뢰할 수 있는 프로젝트로 제한, 균일한 버킷 수준 액세스 활성화. 근거: 기본적으로 보안을 적용함으로써 빈번하게 발생하는 잘못된 구성을 줄입니다. 필요한 경우 예외는 시간 제한을 둘 수 있습니다.

4. ID 및 그룹 설정

• Cloud Identity를 기업 IdP와 통합합니다. 각 팀의 개발, 운영, 관리자 역할에 대한 그룹과 네트워크 관리자 및 보안 관리자를 위한 플랫폼 수준 그룹을 생성합니다. 근거: 그룹 기반 IAM은 확장이 용이하고 직무 분리에 부합하며, 라이프사이클은 HR 이벤트를 따릅니다.

5. 최소 권한 및 조건부 승격으로 IAM 정의

• 사전 정의된 역할을 Folder 또는 프로젝트 범위의 그룹에 바인딩합니다. 프로덕션 태그가 지정된 리소스로 제한되고 24시간 후에 만료되는 조건부 바인딩을 통해 인시던트 대응을 위한 권한 승격을 활성화합니다. 근거: 일상적인 작업에는 최소 권한을 부여하고, 필요할 때 안전하고 감사 가능한 권한 상승 경로를 제공합니다.

6. 프로젝트 팩토리 파이프라인 구축

• Terraform 모듈을 사용하여 필수 라벨/태그(env, owner, cost-center)가 있는 프로젝트를 생성하고, 결제 계정을 연결하고, 올바른 Shared VPC에 연결하고, 중앙 감사 프로젝트로 로깅 싱크를 생성하고, 예산을 설정합니다. 근거: 일관되고 규정을 준수하는 프로비저닝을 대규모로 수행하여 수동으로 인한 구성 편차를 없애고 온보딩 속도를 높입니다.

7. 감사 로깅 및 액세스 검토 중앙화

• 관리자 활동 및 데이터 액세스 로그를 CMEK가 적용된 BigQuery로 라우팅합니다. 매월 쿼리를 예약하여 IAM 바인딩을 열거하고 IAM Recommender의 그룹 소유권 및 마지막 액세스 데이터와 비교합니다. 근거: 영구적인 감사 추적과 지속적인 액세스 권한 최적화를 통해 위험과 비용을 줄입니다.

8. 비용 거버넌스 및 알림

• 비용 할당 태그 및 라벨을 활성화하고, 결제 데이터를 BigQuery로 내보내고, 재무팀 및 팀 리더에게 알림을 보내는 폴더별 및 프로젝트별 예산을 설정합니다. 근거: 투명한 비용 청구는 책임감을 높이고, 조기 경보는 예상치 못한 비용 급증을 억제합니다.

9. 워크로드 아이덴티티 및 키 없는 자동화

• GKE의 경우 Workload Identity를 활성화합니다. 외부 CI(GitHub)의 경우 특정 리포지토리로 범위가 지정된 조건부 Workload Identity Federation을 설정합니다. 근거: 수명이 긴 키를 제거하고 사용을 의도된 워크로드로 제한합니다.

10. 예외 처리 프로세스 및 자동화

• CI를 통해 자동 만료 기능이 있는 조건부 IAM 바인딩 또는 임시 정책 완화를 생성하는 요청 워크플로를 구현합니다. 근거: 제어력을 희생하지 않으면서 팀에 권한을 부여합니다. 모든 예외는 시간 제한이 있으며 감사가 가능합니다.

기술적 결과:

• 팀은 15분 이내에 규정을 준수하는 기본값으로 새 프로젝트를 셀프서비스로 프로비저닝할 수 있습니다.
• 사용자 관리 서비스 계정 키는 허용되지 않으며, 인시던트 대응을 위한 권한 승격은 시간 및 태그로 범위가 제한됩니다.
• 비용은 팀 및 환경별로 집계되며, 자동화된 예산 및 이상 징후 알림이 제공됩니다.
• 감사 로그 및 액세스 검토를 통해 권한과 정책이 의도와 일치하는지 지속적으로 확인합니다.

모든 도메인 · 컴퓨팅 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →