Google PCD: 아이덴티티, 인증 및 애플리케이션 보안 — 학습 가이드

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

개요

Google Cloud에서 ID는 새로운 경계입니다. 애플리케이션은 보안 주체(사용자, 서비스)를 인증하고 데이터 및 API에 대한 최소 권한 액세스를 인가하는 동시에, 시크릿, 키, 소프트웨어 공급망을 보호해야 합니다. 이 섹션에서는 Google Cloud IAM, 최신 인증 프로토콜, 네트워크 및 API 방어, 암호화, 로깅, 대응 프로세스를 결합한 엔드투엔드 설계 및 운영 방식을 설명합니다. 수명이 짧은 크리덴셜, 중앙 집중식 정책, 안전하게 실패하도록(fail-safe) 설계된 계층적 제어에 중점을 둡니다.

ID, 인증, 액세스 제어

• IAM 역할 및 서비스 계정
  • 리소스 계층 구조(조직 > 폴더 > 프로젝트)를 사용하고, 기본(primitive) 역할 대신 사전 정의된 역할을 사용하세요. 사전 정의된 역할의 권한이 너무 광범위할 경우에만 커스텀 역할을 사용하는 것이 좋습니다.
  • 워크로드에 서비스 계정(SA)을 할당하세요. 기본 Compute Engine 또는 App Engine SA를 재사용하지 마세요. 워크로드 경계당 하나의 SA를 사용하면 최소 권한 원칙 적용과 신뢰 관계 순환이 단순해집니다.
  • 가장 좁은 리소스 범위에서 최소한의 권한 집합을 부여하여 최소 권한 원칙을 적용하세요.
  • 가장(Impersonation): 사람이 직접, CI/CD 파이프라인 또는 다른 서비스가 키를 저장하지 않고 임시 액세스 권한을 얻도록 하려면, Service Account Token Creator 역할을 통해 수명이 짧은 크리덴셜을 사용하는 것이 좋습니다.
    • 호출하는 ID에 대상 SA에 대한 roles/iam.serviceAccountTokenCreator 역할을 부여하세요.
    • 예시:

undefined

• Workload Identity

  • GKE: Workload Identity를 사용하여 Kubernetes 서비스 계정을 Google 서비스 계정에 바인딩하세요. 토큰이 자동으로 주입되고 교환되므로 JSON 키가 필요 없습니다.
  • 외부 워크로드: Workload Identity Federation을 사용하여 OIDC/SAML 크리덴셜(예: GitHub Actions 또는 온프레미스 환경)을 수명이 긴 키를 저장하지 않고 Google 액세스 토큰으로 교환하세요.

• 장애 시나리오 및 장단점

  • 권한이 과도하게 부여된 역할이나 넓은 범위의 권한 할당은 수평 이동(lateral movement)으로 이어질 수 있습니다. Token Creator 권한이 없으면 가장(impersonation) 흐름이 차단됩니다. JSON 키 파일은 침해 사고 발생 시 피해 범위(blast radius)를 넓힙니다.

• OAuth 2.0, OpenID Connect, Google Identity를 사용한 사용자 인증

  • 최종 사용자 인증에는 Google을 IdP로 사용하거나 기업용 IdP를 사용하는 OIDC를 활용하고, 서버 측에서 ID 토큰을 검증하세요. API 액세스에는 적절한 범위(scope)를 가진 OAuth 2.0 액세스 토큰을 사용하세요.
  • 토큰 검증: IdP의 JWKS를 사용하여 iss, aud, exp, iat 및 서명을 확인하세요. JWKS를 캐시하고 키 순환을 강제하세요.
  • 모바일/SPA 백엔드의 경우, PKCE를 사용한 Authorization Code flow를 선호하세요. Implicit flow는 피하세요.
  • 서비스 간 통신에는 OAuth 2.0 Service Account JWT flow 또는 mTLS를 사용하고, 정적 API 키는 피하세요.
  • 예시 (gcloud를 사용한 토큰 가장):

undefined

• 장애 시나리오

  • aud/iss를 검증하지 않으면 토큰 혼동(token confusion) 공격에 취약해집니다. 만료된 토큰을 수락하거나 JWKS를 순환하지 않으면 위험이 증가합니다. 모바일 앱에서 리프레시 토큰을 사용하면 수명이 긴 크리덴셜이 노출될 수 있습니다.

• 브라우저 액세스를 위한 Identity-Aware Proxy (IAP)

  • Cloud Run, GKE 또는 Compute Engine에서 실행되는 HTTP 앱 앞에 IAP를 배치하여 인증 로직을 앱에 내장하지 않고도 보호할 수 있습니다. 액세스 제어를 위해 ‘IAP로 보호된 웹 앱 사용자’ 역할을 적용하세요.
  • 앱은 서명된 헤더(x-goog-iap-jwt-assertion)를 수신합니다. 이 JWT를 검증하여 사용자 ID와 이메일을 신뢰해야 하며, 인증을 위해 X-Forwarded-* 헤더에 의존해서는 안 됩니다.
  • 일반적인 함정: IAP를 통하지 않는 우회 경로, 잘못 구성된 백엔드 방화벽, 또는 Cloud Load Balancing의 무결성 검증 없이 클라이언트 IP 헤더를 신뢰하는 경우입니다.

시크릿, 키, 암호화

• Secret Manager
  • API 키, DB 비밀번호, 웹훅 시크릿 등은 Secret Manager에 저장하세요. 버전 관리, IAM 제어, 감사 로그 기능을 활용하세요.
  • 액세스 패턴
    • 시작 시점에 가져와서 메모리에 캐시하고, 시크릿 변경 신호(Pub/Sub 알림)를 받으면 새로고침하세요.
    • 이미지나 환경 변수에 시크릿을 포함(baking)하는 것을 피하세요. 환경 변수를 사용해야 한다면, 해당 변수가 로그나 충돌 보고서에 절대 기록되지 않도록 하세요.
  • 순환
    • Cloud Scheduler와 Cloud Functions/Run을 함께 사용하여 새 버전을 생성하고, 종속 항목을 업데이트하며, 이전 버전을 비활성화하는 과정을 자동화하세요.
    • 예시:

undefined

• 장애 시나리오

  • 요청당 Secret Manager 호출이 너무 많으면 지연 시간이 증가하고 할당량 소진 위험이 있습니다. roles/secretAccessor 역할이 없으면 런타임에 403 오류가 발생합니다.

• Cloud KMS 및 애플리케이션 암호화

  • 봉투 암호화(envelope encryption)를 사용하세요. 로컬에서 생성된 데이터 암호화 키(DEK)로 데이터를 암호화하고, Cloud KMS의 고객 관리 암호화 키(CMEK)를 키 암호화 키(KEK)로 사용하여 DEK를 암호화합니다.
  • 키를 정기적으로 순환하고, 재암호화 계획을 세우세요. 쓰기 작업 시 ‘이전 키로 복호화, 새 키로 암호화’ 방식을 선호하세요. 저장 데이터(at-rest data)에 대한 대량 재암호화 작업은 비용이 더 많이 듭니다.
  • 규정 준수를 위해 필요한 경우 BigQuery, GCS, Pub/Sub, Cloud SQL 등의 서비스에 CMEK를 활성화하세요. KMS 키는 데이터와 동일한 리전에 보관하세요.
  • CLI 예시:
    • 암호화:

undefined

- 복호화:

undefined

• 구현 오류를 피하기 위해 잘 검증된 암호화 라이브러리(예: Tink)를 사용하세요.
• 장애 시나리오: 리전이 일치하지 않으면 CMEK를 사용할 수 없습니다. 요청마다 KMS 복호화를 수행하면 지연 시간이 늘어납니다. 키 순환을 인지하는 방식으로 DEK를 메모리에 캐시하세요. roles/cloudkms.cryptoKeyEncrypterDecrypter 역할이 없으면 403 오류가 발생합니다.

인가, API, 경계 보안

• 애플리케이션 인가

  • 역할 기반 확인: 간단하고 빠르지만 세분화되지 않음. 속성 기반 액세스 제어(ABAC)는 사용자 속성, 리소스 속성, 컨텍스트(시간, 기기 상태)를 사용하여 세분화된 결정을 내립니다.
  • 정책 평가를 중앙 집중화하거나 사이드카/OPA를 사용합니다. 마이크로서비스 전반에 걸쳐 ID 및 테넌트 클레임을 일관되게 전파합니다.
  • 멀티테넌시 패턴
    • 인증 토큰에 tenant_id를 포함하고 모든 데이터 액세스 경로에서 이를 강제합니다. 엄격한 격리를 위해 행 수준 필터링 또는 테넌트별 별도 데이터 세트를 사용합니다.
    • 규제 준수를 위한 격리가 필요한 경우 테넌트별 서비스 계정 또는 KMS 키를 고려합니다.
  • 장애 모드
    • 테넌트 확인 누락으로 인한 안전하지 않은 직접 객체 참조(IDOR). 서비스 간 인가 로직이 달라 일관되지 않은 정책이 적용됨.

• 안전한 API 설계

  • 모든 입력의 유효성을 검사하고 정규화합니다. 과도하게 큰 페이로드는 거부합니다. 강력한 콘텐츠 타입을 강제합니다. 파일 업로드에 대한 위협 모델링을 수행하고, 대용량 객체에는 서명된 URL을 사용합니다.
  • 속도 제한 및 할당량: Cloud Armor 속도 제한 또는 Apigee를 사용하여 악용 및 429 오류를 완화합니다. 클라이언트에서 지터가 포함된 지수 백오프를 구현합니다.
  • CORS
    • 최소한의 Access-Control-Allow-*를 반환합니다. 자격 증명이 포함된 요청에는 와일드카드 오리진 사용을 피합니다. 프리플라이트 캐싱은 지연 시간을 줄여줍니다.
  • CSRF 방어
    • Authorization 헤더에 bearer 토큰을 사용하는 무상태(stateless) API를 선호합니다. 쿠키 기반 세션의 경우, SameSite=strict 또는 lax, 보안 쿠키, CSRF 토큰(이중 제출 또는 동기화 장치)을 사용합니다.

  • 예시 (Cloud Armor 규칙):

undefined

• 장애 모드

  • 단순한 IP 기반 제한은 IPv6나 프록시로 우회될 수 있습니다. 지나치게 허용적인 CORS 설정은 토큰 유출을 야기합니다. 쿠키 사용 시 CSRF 토큰이 없으면 세션 하이재킹(session riding)이 가능해집니다.

• 네트워크 제어 및 데이터 경계

  • 계층적 방화벽 정책과 VPC 방화벽 규칙을 사용합니다. HTTP(S) Load Balancing 뒤에 있을 경우 Google Front End 상태 확인을 허용해야 합니다.

  • 예시:

undefined

• Cloud Armor는 WAF, 봇 방어, 지역/IP 제한 기능을 제공합니다. 규칙을 조정하고 오탐(false positive)을 검토합니다.
• 비공개 서비스 액세스는 Google 관리형 서비스(예: Cloud SQL, Memorystore)에 대한 비공개 IP 연결을 제공합니다. 퍼블릭 이그레스(egress) 및 IP 허용 목록 사용을 피합니다.
• VPC 서비스 제어는 지원되는 서비스 주위에 경계를 만들어 데이터 무단 반출 위험을 줄입니다. 기기/위치 컨텍스트를 위해 Access Context Manager와 함께 사용합니다.
• 장애 모드
  • 잘못 구성된 경계는 CI/CD를 차단하거나 서비스 간 호출을 중단시킬 수 있습니다. PSA 할당이 누락되면 비공개 IP 연결이 불가능합니다. 지나치게 엄격한 WAF 규칙은 가용성 사고를 유발할 수 있습니다.

공급망 보안, 로깅 및 대응

• 소프트웨어 공급망 보안

  • Artifact Registry에 아티팩트를 저장하고 취약점 스캔을 강제합니다. 정책 예외를 추적하면서 높음/심각 수준의 CVE 발생 시 빌드를 실패 처리합니다.
  • 의존성과 베이스 이미지를 고정하고 “latest” 태그 사용을 피합니다. SBOM을 생성하고 검증합니다. Binary Authorization을 사용하여 배포 전 서명된 이미지를 요구합니다.
  • Cosign으로 이미지에 서명하고 출처(provenance)를 기록합니다. SLSA에 부합하는 빌드 관행을 채택합니다. CI에 Workload Identity Federation을 사용하여 JSON 키를 제거합니다.
  • 실패 모드
    • 고정되지 않은 의존성은 취약한 릴리스를 가져올 수 있습니다. 출처 기록을 생략하면 이미지 변조가 가능해집니다. CI 로그에 레지스트리 자격 증명이나 서비스 계정 키를 저장하면 보안 비밀이 유출됩니다.

• 보안 로깅 및 모니터링

  • 중요 프로젝트 및 서비스에 대해 Admin Activity 및 Data Access Audit Logs를 활성화합니다. 로그를 접근이 제한된 전용 프로젝트로 라우팅합니다.
  • 인증 실패, 권한 거부, 정책 평가 오류에 대한 Cloud Logging 측정항목을 생성하고 Cloud Monitoring을 통해 알림을 보냅니다.
  • 예시 (커스텀 카운터 측정항목 아이디어): /api/* 경로의 401/403 비율을 계산하고 기준선 편차 발생 시 알림을 보냅니다.
  • 위협 분류 및 해결
    • Security Command Center를 사용하여 발견된 사항을 집계합니다. 주요 시나리오(키 유출, 무차별 대입 공격, 비정상적인 IAM 변경)에 대한 플레이북을 만듭니다.
    • 일반적인 해결 조치(토큰 폐기, 키 비활성화, 보안 비밀 순환, 서비스 계정 격리)를 자동화합니다.
  • 개인정보 보호를 고려한 설계
    • PII를 최소화하고 가능한 경우 토큰화합니다. 로그에서 민감한 값을 삭제 처리하고, 분류를 위해 Cloud DLP를 사용합니다. 최소 보존 및 리전별 스토리지 정책을 적용합니다.
  • 실패 모드
    • Data Access 로그를 비활성화하면 데이터 유출 탐지가 불가능해집니다. 카디널리티가 높은 라벨은 비용을 폭증시킵니다. 보안 비밀을 로깅하면 영구적인 노출이 발생합니다.

실제 문제 시나리오

Acme Retail은 React 프런트엔드, Python API, 테넌트별 BigQuery 데이터세트를 사용하여 Cloud Run에 멀티 테넌트 분석 포털을 구축합니다. 요구사항에는 직원 및 고객을 위한 SSO, 테넌트 격리, 보안 비밀 및 키 관리, 비공개 데이터베이스 액세스, WAF 및 비율 제한, 그리고 장기 수명 키가 없는 강력한 CI/CD 환경이 포함됩니다.

접근 방식:

1. ID 설정 및 최소 권한 원칙 적용

• 마이크로서비스별(api-sa, ingest-sa)로 전용 Google 서비스 계정을 생성합니다. 프로젝트 또는 데이터세트 범위에서 최소 권한 역할(예: 테넌트 데이터세트에 대한 roles/bigquery.dataEditor)을 부여합니다.
• 근거: 서비스별 SA는 잠재적 피해 범위(blast radius)를 제한하고 순환을 단순화합니다. 좁은 범위의 역할은 측면 이동(lateral movement)을 줄입니다.

2. CI/CD에 Workload Identity Federation 사용

• GitHub Actions OIDC를 구성하여 roles/iam.workloadIdentityUser 및 roles/iam.serviceAccountTokenCreator를 통해 deployer-sa를 가장(impersonate)하도록 합니다. 가장된 토큰을 사용하여 Cloud Run에 배포합니다.
• 근거: CI에서 JSON 키를 제거합니다. 수명이 짧은 자격 증명은 도난 위험을 줄입니다.

3. 프런트엔드 및 사용자 인증

• Cloud Run 서비스 앞단의 HTTPS Load Balancer에 IAP를 구성합니다. 직원을 위해 Google을 IdP로 통합하고, 연동을 통해 고객 IdP를 통합합니다. “IAP-secured Web App User” 역할을 사용하여 승인된 그룹으로 접근을 제한합니다.
• 근거: 브라우저 앱을 위한 중앙 집중식 인증, 서비스 내 인증 로직 불필요, SSO 지원.

4. API에서 IAP ID 검증

• API에서 x-goog-iap-jwt-assertion 헤더를 확인합니다. tenant_id 클레임(그룹 또는 커스텀 클레임에서 매핑됨)이 있는지 강제합니다.
• 근거: IAP가 제공하는 강력한 ID 보증, 각 요청에 테넌트 컨텍스트를 포함시켜 일관된 다운스트림 인가를 보장합니다.

5. 테넌트 인식 인가 구현

• 테넌트별 정책을 저장하고 사용자를 역할(viewer, analyst, admin)에 매핑합니다. 각 요청 시 역할 및 ABAC 조건(tenant_id 일치, 기능 플래그)을 확인합니다.
• 근거: RBAC의 단순성과 ABAC의 유연성을 결합합니다. 테넌트 범위 지정을 강제하여 IDOR를 제거합니다.

6. 보안 비밀 및 데이터베이스 액세스

• DB 비밀번호와 서드파티 API 토큰을 Secret Manager에 저장합니다. API SA에만 roles/secretmanager.secretAccessor 역할을 부여합니다. 시작 시 보안 비밀에 액세스하고 Pub/Sub 순환 알림 시 새로 고칩니다.
• 근거: 하드코딩된 자격 증명 없음, 감사 가능한 액세스, 재시작 없는 시기적절한 순환.

7. 데이터 암호화 및 CMEK

• 환경별로 Cloud KMS 키링과 키를 생성합니다. BigQuery 데이터세트와 Cloud Storage 버킷에 CMEK를 활성화합니다. 애플리케이션에 저장되는 모든 민감한 blob에 대해 봉투 암호화(envelope encryption)를 사용합니다.
• 근거: 고객 관리형 키(Customer-managed keys)는 규정 준수 요구사항을 충족하고 직무 분리를 제공합니다.

8. 비공개 연결 및 서비스 경계

• Cloud SQL 비공개 IP에 대해 비공개 서비스 액세스(private service access)를 사용합니다. BigQuery와 GCS를 호스팅하는 프로젝트에 VPC Service Controls 경계를 생성합니다. 회사 관리자 액세스를 위해 Access Context 정책을 추가합니다.
• 근거: 공용 이그레스(egress) 경로를 제거하고 데이터 유출 위험을 줄입니다.

9. API 보안, 비율 제한, CORS 및 CSRF

• 외부 HTTP(S) LB에 WAF 관리형 규칙과 비율 제한이 포함된 Cloud Armor 보안 정책을 적용합니다. 파트너 IP에 대한 허용 목록을 조정합니다. API에 대해 엄격한 CORS(명시적 출처)를 구성하고 Authorization bearer 토큰을 사용합니다. 쿠키는 사용하지 않습니다.
• 근거: OWASP Top 10 및 어뷰징을 완화합니다. 교차 출처 자격 증명 유출을 방지합니다. 쿠키를 사용하지 않아 CSRF를 방지합니다.

10. 공급망 강화

• Artifact Registry에 이미지를 저장합니다. 취약점 스캔을 활성화하고 심각한 CVE 발생 시 빌드를 실패 처리합니다. Cosign으로 이미지에 서명하고, 프로덕션 환경에서 Acme 서명을 요구하도록 Binary Authorization을 강제합니다.
• 근거: 검증되지 않은 아티팩트가 실행되는 것을 방지하고 출처를 유지합니다.

11. 로깅, 모니터링 및 알림

• Audit Logs를 활성화하고 중앙 집중식 프로젝트로 라우팅합니다. 401/403 급증, BigQuery의 permissionDenied, Secret Manager 액세스에 대한 로그 기반 측정항목을 생성합니다. 이상 징후 발생 시 알림을 보내고, 공용 엔드포인트에 대한 Cloud Monitoring 가동 시간 확인을 설정합니다.
• 근거: 인증 실패 및 오용의 조기 탐지, 가용성 모니터링.

12. 인시던트 플레이북 및 순환 훈련

• 손상된 SA 폐기(비활성화, 키 순환, 토큰 무효화), 보안 비밀 순환, 새 KMS 버전으로 재암호화하는 단계를 문서화합니다. 분기별로 테스트합니다.
• 근거: 준비되고 반복 가능한 대응은 다운타임과 데이터 노출을 최소화합니다.

이 설계는 모든 단계에서 수명이 짧고 검증 가능한 ID, 일관된 테넌트 인식 인가, 보호된 보안 비밀 및 키, 비공개 데이터 경로, 강화된 공급망을 보장합니다. 또한 공격 시나리오와 일상적인 운영 중에 시스템의 복원력을 유지하는 관측 가능성 및 대응 워크플로를 갖추고 있습니다.

← 애플리케이션 데이터 · 모든 도메인 · 지속적인 배포 →

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

Google 찾아보기 →