Google PCA: 보안, 규정 준수 및 데이터 보호 아키텍처 — 학습 가이드

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

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

개요

Google Cloud의 보안, 규정 준수, 데이터 보호는 공동 책임 및 심층 방어 모델을 기반으로 합니다. Google은 기본 인프라를 보호하고, 사용자는 보안 ID, 네트워크, 애플리케이션, 데이터 처리를 설계할 책임이 있습니다. 제로 트러스트를 기본 모델로 채택하십시오. 즉, 네트워크를 암묵적으로 신뢰하지 않고, ID와 컨텍스트를 지속적으로 확인하며, 최소 권한 원칙을 엄격하게 적용해야 합니다. 침해를 가정한 설계: 자격 증명이 유출될 수 있고, 엔드포인트가 탐색될 수 있으며, 내부 서비스가 오용될 수 있다고 가정해야 합니다. 여러 제어(예방, 탐지, 대응), 강력한 암호화 및 키 관리, 견고한 모니터링, 숙련된 사고 대응을 통해 이를 보완해야 합니다.

절충점은 불가피합니다. 더 강력한 제어는 지연 시간, 운영 복잡성, 비용을 증가시킬 수 있습니다. 아키텍처는 입증 가능한 규정 준수 및 포렌식 준비 상태를 유지하면서 위험과 사용성 및 성능 간의 균형을 명시적으로 고려해야 합니다.

ID 및 액세스 아키텍처

• 원칙 및 모델

  • 기본적으로 최소 권한 원칙 적용: 작업을 완료하는 데 필요한 최소한의 권한 집합을 부여하고, 기본 역할(Owner, Editor, Viewer) 대신 사전 정의된 역할이나 커스텀 역할을 사용하는 것을 선호합니다.
  • 직무 분리: 빌더(CI/CD), 배포자, 운영자, 보안 담당자 간에 역할을 분리합니다. 비상시에는 강력한 제어 및 로깅 기능이 있는 브레이크 글래스(break-glass) 계정을 사용합니다.
  • 제로 트러스트 적용: 컨텍스트 인식 액세스를 사용하여 사용자, 기기, 위치, 위험을 확인하고, 강력한 MFA를 요구하며, 세션 컨텍스트를 지속적으로 평가합니다.
  • 조직 정책 및 IAM Deny: 가드레일(예: 서비스 계정 키 생성 금지, 도메인 공유 제한)을 코드로 정의하고, 거부 정책을 사용하여 협상 불가능한 경계를 강제합니다.

• IAM 구현 및 서비스 계정 전략

  • 계층 구조 기반 액세스 모델 구축: 폴더는 사업 부문이나 환경(prod, non-prod)을 반영하고, 프로젝트는 영향 반경과 결제를 격리하며, 서비스 계정(SA)은 워크로드를 나타냅니다.
  • 워크로드당 하나의 서비스 계정: 관련 없는 서비스 간에 SA를 공유하지 마십시오. 배포 범위(프로젝트)와 리소스 범위에 권한을 태그합니다.
  • Service Account Impersonation 및 Workload Identity Federation을 통해 단기 수명 자격 증명을 사용하는 것을 선호합니다. 사용자 관리형 서비스 계정 키를 비활성화하고, 불가피한 경우 사용을 격리하고, 자주 교체하며, 감사 로그로 모니터링합니다.
  • Access Boundaries를 사용하여 가장된 SA가 요청 시 액세스할 수 있는 대상을 제한(예: GCS 객체 경로 제한)하여, 권한이 높은 SA가 오용되더라도 영향 반경을 억제합니다.
  • 조건부 IAM: 리소스 수준의 조건(시간, IP, 주 구성원 속성)을 적용하여 액세스를 제한합니다. 예: 회사 IP 범위 및 변경 기간 외에는 프로덕션 액세스를 금지합니다.

• 장애 모드 및 절충점

  • 과도한 권한을 가진 역할(예: 프로젝트 범위의 Editor)은 위험을 증가시킵니다. 세분화된 역할을 선호하고 정책 분석기를 통해 검증하십시오.
  • CI/CD 및 로컬 스크립트에서의 서비스 계정 키 확산은 일반적인 침해 경로입니다. 가장(impersonation)을 사용하면 일부 레거시 도구는 조정이 필요할 수 있습니다.
  • IAM Deny 정책은 강력하지만 문제 해결이 어려울 수 있습니다. 비프로덕션 환경에서 명시적인 모의 실행을 통해 변경 사항을 스테이징하고 테스트하십시오.

예시 (키를 생성하지 않고 가장하기):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

데이터 보호 및 암호화

• Cloud KMS와 키 관리 모델
  • 기본적으로 저장 데이터에 대한 네이티브 암호화가 제공됩니다. 추가적인 제어가 필요할 경우, BigQuery, Cloud Storage, Compute Engine 디스크, Pub/Sub, GKE 영구 볼륨과 같은 서비스에서 고객 관리 암호화 키(CMEK)를 사용하세요.
  • 환경 및 데이터 도메인별로 키 계층 구조를 설계하세요. 위치별로 별도의 키링을 사용하고, 애플리케이션 또는 데이터세트별로 별도의 키를 사용하여 장애 영향 반경(blast radius)을 제한하세요.
  • 키 순환: 예약된 순환을 활성화하고, 애플리케이션에 봉투 암호화(envelope encryption)를 적용하여 이전 키 버전을 정상적으로 지원 중단(deprecate)하세요. 순환 주기를 늘리기 전에 소비자 호환성을 검증하세요.
  • 외부 키 관리자(EKM) 및 외부 키 액세스(EKA)는 규제 준수를 위해 키를 Google Cloud 외부에 배치합니다. 단점으로는 지연 시간 증가와 외부 HSM 가용성에 대한 종속성이 있으며, 성능 저하 모드(degraded-mode) 운영을 계획해야 합니다.
  • CryptoKey에 IAM 최소 권한 원칙을 적용하세요. 액세스 증거로 키 수준의 감사 로그를 사용하세요.

예시 (CMEK 및 키 순환):

undefined

undefined

• 애플리케이션 수준 암호화

  • 애플리케이션 계층에서 민감한 필드를 암호화하기 위해 봉투 암호화(예: Tink)를 사용하여 선택적 액세스 및 테넌트 데이터 격리를 구현하세요. 테넌트 간 영향을 최소화하기 위해 테넌트별 키를 파생시키세요.
  • 무결성(AEAD)을 검증하여 데이터 변조 및 재전송 공격을 방지하세요.

• Secret Manager와 보안 비밀 수명 주기

  • 자격 증명, 토큰, API 키는 버전이 지정된 보안 비밀(secret)로 저장하고, 이미지, Git 또는 인스턴스 메타데이터에는 절대 저장하지 마세요. 런타임 서비스 계정에 보안 비밀 또는 프로젝트 수준에서 IAM 권한을 부여하세요.
  • 순환: Pub/Sub으로 트리거되는 Cloud Functions/Cloud Run을 사용하여 새 버전을 생성하고, 종속 항목을 업데이트하며, 이전 버전을 폐기하는 과정을 자동화하세요. 수명이 긴 DB 비밀번호는 IAM 기반 데이터베이스 인증이나 수명이 짧은 토큰으로 대체하는 것이 좋습니다.
  • 구성 보안: 보안 비밀이 아닌 구성(ConfigMap, 환경 변수)은 보안 비밀과 분리하세요. 로그 및 오류 메시지에 보안 비밀이 노출되지 않도록 방지하세요.

예시 (새 보안 비밀 버전 추가):

undefined

• 컴퓨팅 강화 및 기밀 컴퓨팅
  • Shielded VM: 보안 부팅, vTPM, 무결성 모니터링을 활성화하여 부트킷과 루트킷으로부터 보호하세요. 조직 정책을 통해 이를 강제하고 CI/CD 파이프라인에서 검증하세요.
  • Confidential VM: 기본적으로 메모리 암호화가 적용되어 최소한의 구성 변경으로 사용 중인 데이터를 보호합니다. 처리량이 많고 암호화 부하가 큰 워크로드의 경우 성능 영향을 평가하세요.
  • 강화된 이미지: Google 최적화 또는 CIS 강화 기준 이미지에서 시작하세요. OS Config로 패치를 관리하고, 불필요한 패키지와 포트를 비활성화하세요.

네트워크 및 경계 보안

• 네트워크 세분화 및 이그레스 제어

  • 계층 및 민감도에 따라 별도의 VPC, 서브넷, 계층적 방화벽 정책을 사용하여 네트워크를 세분화하세요. ID 인식 방화벽 태그를 서비스 간 제약 조건(예: GKE NetworkPolicy)과 결합하여 이스트-웨스트(east-west) 트래픽 제어를 강화하세요.
  • Cloud NAT, DNS 정책, 제한된 비공개 Google 액세스를 통해 이그레스를 제어하여 데이터 유출을 최소화하세요. 명시적인 이그레스 허용 목록을 사용하고, 필요한 경우 프록시 검사를 활용하세요.

• VPC Service Controls (VPC SC)

  • 범위 내 데이터를 호스팅하는 프로젝트 주위에 서비스 경계(service perimeter)를 구축하여 Google 관리 API(GCS, BigQuery, Secret Manager, Pub/Sub 등)로부터의 데이터 유출을 완화하세요.
  • 액세스 수준(Access levels): 경계 내 서비스에 액세스하기 위해 충족해야 하는 컨텍스트 조건(사용자 ID, IP 범위, 기기 상태)을 정의하세요.
  • 제어된 다중 경계 워크플로를 위해 경계 브리지(perimeter bridge)를 사용하고, 대상을 제한하기 위해 이그레스 규칙을 사용하세요. 파이프라인 중단을 방지하기 위해 드라이런(dry-run) 모드로 테스트하세요.
  • 제한 사항: Compute Engine IP로 향하는 트래픽을 직접 보호하지는 않습니다. 방화벽 및 이그레스 제어로 보완해야 합니다. 일부 도구 및 하이브리드 패턴에서는 경계를 인식하는 서비스 계정과 제한된 VIP에 대한 Private Service Connect가 필요할 수 있습니다.

• 경계 및 애플리케이션 보호

  • Cloud Armor: 전역 외부 부하 분산기 뒤의 HTTP(S) 애플리케이션을 L3/L4/L7 DDoS 완화, IP 허용/거부 목록, 지역 기반 제어, 비율 제한(rate limiting) 기능으로 방어하세요.
  • WAF 규칙: 사전 구성된 관리형 규칙과 OWASP Top 10에 대한 커스텀 시그니처를 적용하세요. 오탐(false positive)을 줄이기 위해 규칙을 조정하세요. API 버전이나 앱 구성 요소별로 정책을 맞춤 설정하려면 백엔드 서비스별로 연결하세요.
  • API 보호: API Gateway 또는 Apigee를 API 앞에 배치하여 인증, 할당량, 스키마 유효성 검사, 위협 탐지를 수행하세요. 경계 보안 강화를 위해 Cloud Armor를 통합하고, 필요한 경우 reCAPTCHA Enterprise 및 봇 제어를 고려하세요.
  • 장단점: 심층적인 검사는 지연 시간과 운영상의 노이즈를 추가할 수 있습니다. 규칙을 미리보기(preview) 모드로 스테이징하고, 로그를 모니터링하며, 점진적으로 적용하세요.

보안 운영, 모니터링 및 규정 준수

• Security Command Center (SCC) 및 위협 탐지

  • SCC는 프로젝트와 조직 전반의 자산 인벤토리와 검색 결과를 집계합니다. 이를 사용하여 기준 상태(공개 버킷, 개방된 방화벽 규칙)를 설정하고, 드리프트를 추적하며, 수정 워크플로우를 실행할 수 있습니다.
  • 프리미엄 위협 탐지에는 Event Threat Detection, VM Threat Detection, Container Threat Detection이 포함되어 악성코드, 암호화폐 채굴, 비정상적인 동작을 식별합니다.
  • 검색 결과를 티켓팅 및 SOAR 파이프라인과 통합하고, 만료 기간이 있는 억제/예외 정책을 정의하여 알림 피로도를 방지합니다.

• 취약점 및 아티팩트 보안

  • Artifact Analysis를 사용하여 컨테이너 이미지에서 CVE를 스캔하고, CI의 서명된 증명을 사용하여 Binary Authorization으로 배포 시 정책을 강제합니다.
  • OS Config를 통한 패치 관리, 노출 기간을 모니터링하고 카나리아 배포로 롤아웃을 자동화합니다.

• 감사 로그, 개인정보 보호 및 증거

  • Cloud Audit Logs는 기본적으로 관리자 활동(Admin Activity) 및 시스템 이벤트(System Event) 로그를 제공하며, 데이터 액세스(Data Access) 로그는 서비스별로 활성화할 수 있고 요금이 부과됩니다. 분석을 위해 로그를 BigQuery로, 불변 보관 및 법적 보존 조치를 위해 Cloud Storage로 라우팅합니다.
  • 데이터 분류: Cloud DLP를 사용하여 PII를 발견 및 분류하고, 레이블과 태그를 적용하며, 보호 수준(CMEK, VPC SC, Confidential VMs)에 매핑합니다.
  • 개인정보 보호 및 데이터 상주: 조직 정책을 통해 위치를 제한하고, CMEK 및 스토리지 위치를 규제 요구사항에 맞춥니다.
  • 법적 보존 조치 및 보관: 버킷 보관 정책 및 보존 조치를 활성화하고, 필요한 경우 객체 버전 관리(Object Versioning)를 사용합니다. 방어 가능한 증거를 생성하기 위해 포렌식 이미지 및 로그에 대한 관리 연속성을 문서화합니다.

• 사고 대응 및 포렌식 준비

  • 런북, 액세스 경로, 자동화를 준비합니다. 대응 담당자가 최소 권한 액세스를 갖도록 보장하고 조직, 폴더, 프로젝트 전반에 감사가 활성화되었는지 확인합니다.
  • 격리: 로드 밸런서에서 인스턴스를 제거하거나, 송신 거부 방화벽 규칙을 적용하거나, 프로젝트를 더 엄격한 조직 정책으로 이동하여 인스턴스를 격리합니다. 침해된 서비스 계정을 비활성화하고 보안 비밀과 키를 순환합니다.
  • 포렌식: 오프라인 분석을 위해 디스크를 스냅샷하고 이미지를 내보냅니다. 내보내기를 통해 로그를 보존합니다. 해당하는 경우 패킷 미러링을 사용합니다. 증거 수정을 피하고 사본으로 작업합니다.
  • 복구: 신뢰할 수 있는 이미지에서 재구축하고, 보안 비밀을 다시 채우며, 스모크 테스트와 보안 테스트로 검증합니다. 사고 후 검토를 수행하고 교훈을 가드레일과 탐지 기능에 반영합니다.

실제 문제 시나리오

핀테크 SaaS인 NimbusPay는 Google Cloud의 멀티테넌트 마이크로서비스 전반에서 PCI 태그가 지정된 데이터를 처리하고, EU 내 데이터 상주를 강제하며, API 계층 공격으로부터 보호하고, 통제에 대한 감사 가능한 증거를 생성해야 합니다. 이들은 동일한 호스트 이름으로 v1을 유지하면서 새로운 v2 API를 출시할 예정입니다.

접근 방식:

1. 프로젝트 및 ID 분할

• 환경 및 마이크로서비스 티어(수집, 처리, 보고)별로 별도의 프로젝트를 생성합니다. 각 서비스에 고유한 워크로드 서비스 계정을 할당합니다. 근거: 영향 반경을 격리하고 개별 워크로드에 최소 권한을 매핑합니다.

2. 제로 트러스트 및 최소 권한 원칙 적용

• 서비스 계정과 DevOps 그룹에 사전 정의된/커스텀 역할을 부여합니다. 조건부 IAM을 적용하여 프로덕션 액세스를 회사 IP 및 업무 시간으로 제한합니다. 근거: 내부망 이동(lateral movement)과 우발적인 변경을 줄입니다.

3. 정적 서비스 계정 키 제거

• 조직 정책을 통해 사용자가 관리하는 SA 키를 비활성화합니다. CI/CD 및 운영에는 Service Account Impersonation을 사용합니다. 테넌트별 GCS 경로를 제한하는 Access Boundaries를 적용합니다. 근거: 자주 발생하는 자격 증명 유출 경로를 제거하고 토큰이 도난당하더라도 데이터 액세스를 제한합니다.

4. CMEK 및 리전 제어로 데이터 보호

• europe-west 리전에 Cloud KMS 키링과 키를 생성합니다. BigQuery 데이터 세트, GCS 버킷, Persistent Disk에 CMEK를 활성화합니다. 예약된 순환 및 버전 모니터링을 구성합니다. 근거: EU 상주 및 PCI 요구사항에 부합하는 증명 가능한 암호화 제어.

5. 카드 데이터에 대한 애플리케이션 계층 암호화 채택

• CMEK로 래핑된 테넌트별 데이터 키를 사용하여 봉투 암호화(Tink AEAD)를 사용합니다. 데이터베이스에는 암호문만 저장합니다. 근거: 필드 수준 보호 및 사고 분류 시 범위 최소화.

6. 보안 비밀 중앙 관리 및 자동 순환

• DB 자격 증명과 API 토큰을 Secret Manager에 서비스별 IAM과 함께 저장합니다. 새 버전을 생성하고 배포를 업데이트하는 Pub/Sub 트리거 순환 작업을 구현합니다. 가능한 경우 Cloud SQL에 IAM DB 인증으로 전환합니다. 근거: 최소한의 다운타임으로 감사 가능한 보안 비밀 수명 주기 관리.

7. 네트워크 분할 및 송신(egress) 제어

• 계층적 방화벽 정책을 사용하여 웹→API→DB 흐름을 강제하고, 웹→DB 직접 연결을 거부합니다. Google API에 대해 송신 허용 목록과 Private Google Access(제한됨)가 있는 Cloud NAT를 활성화합니다. 근거: 내부망(east-west) 이동을 제한하고 승인되지 않은 데이터 유출을 차단합니다.

8. VPC Service Controls로 데이터 서비스 래핑

• BigQuery, GCS, Secret Manager 프로젝트를 서비스 경계에 배치합니다. 회사 IP와 관리형 기기를 요구하는 액세스 수준을 정의합니다. 드라이런(dry-run)으로 테스트한 후 적용합니다. 근거: 도난된 토큰이나 잘못 구성된 클라이언트를 통한 데이터 유출을 완화합니다.

9. 에지 및 API 보안 강화

• 글로벌 HTTPS 로드 밸런서 앞에 Cloud Armor 관리형 규칙과 비율 제한을 설정합니다. 경로 기반 라우팅을 사용하여 /v1과 /v2를 별개의 백엔드 서비스로 분리하고 버전별로 맞춤형 WAF 정책을 적용합니다. 인증, 할당량, 스키마 검증을 위해 Apigee를 통합합니다. 근거: 계층화된 API 보호, 원활한 v1→v2 전환, 오탐 최소화.

10. 컴퓨팅 강화 및 아티팩트 증명

• 처리 노드에 Shielded VMs와 Confidential VMs를 활성화하고, CIS 강화 기반 이미지를 채택합니다. Artifact Registry에서 이미지를 스캔하고, GKE에 대해 Binary Authorization으로 서명된 증명을 요구합니다. 근거: 부팅 체인과 사용 중인 데이터를 보호하고 공급망 신뢰를 강제합니다.

11. SCC로 보안 상태 및 위협 모니터링

• SCC Premium을 활성화하여 위험한 구성과 런타임 위협을 탐지하고, SLA를 위해 티켓팅 시스템과 통합합니다. 수용된 위험은 만료 날짜를 설정하여 억제합니다. 근거: 지속적인 보증 및 실행 가능한 신호.

12. 로그 기록, 보관 및 증거 생성

• 관리자 활동, 데이터 액세스, VPC Flow Logs를 보관 정책 및 법적 보존 조치가 설정된 BigQuery와 Cloud Storage로 라우팅합니다. 데이터 세트에 상주 위치 및 민감도 레이블을 태그합니다. 근거: 범위가 지정된 액세스를 통해 조사 및 외부 감사를 지원합니다.

13. 사고 대응 및 포렌식 준비

• 침해된 서비스를 격리하기 위한 런북을 생성합니다. 프로젝트를 더 엄격한 정책이 적용된 격리 폴더로 이동하고, 관련된 SA를 비활성화하며, 오프라인 분석을 위해 디스크를 스냅샷합니다. 근거: 증거를 보존하면서 신속하게 격리합니다.

출시를 지원하는 간단한 명령어:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

이러한 단계를 통해 NimbusPay는 계층화된 보호(ID, 암호화, 네트워크, 에지), 검증 가능한 규정 준수, 단일 호스트 이름 하에서의 제어된 API 진화, 그리고 사고를 탐지, 격리, 복구할 수 있는 준비 상태를 달성합니다.

← 네트워킹 · 모든 도메인 · 안정성 →

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

Google 찾아보기 →