Google ACE: 보안, 규정 준수 및 데이터 보호 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

개요

Google Cloud의 보안, 규정 준수 및 데이터 보호는 공동 책임 모델과 기본적으로 안전한(secure-by-default) 심층 방어(defense-in-depth) 접근 방식을 기반으로 합니다. Google은 물리적 인프라, 기본 서비스, 기본 암호화를 보호하고, 사용자는 ID 및 액세스, 데이터 분류 및 보관, 애플리케이션 구성, 운영 프로세스를 보호합니다. 리소스 계층 구조 전반에 걸쳐 최소 권한 원칙으로 설계하고, 개별 사용자 대신 그룹을 사용하며, 관리형 ID와 단기 수명 사용자 인증 정보를 선호하고, 단일 제어의 실패가 보안 침해로 이어지지 않도록 제어를 계층화하십시오. 처음부터 관측 가능성 및 대응 워크플로를 구축하여 보안 상태를 지속적으로 측정하고 개선할 수 있도록 하십시오.

ID 및 액세스 기본 사항

• 공동 책임 및 최소 권한

  • 신뢰 경계를 반영하는 폴더를 사용하여 단일 조직 아래에 프로젝트를 구성합니다. 조직 정책 제약 조건을 적용하여 안전한 기본값을 강제합니다(예: 공개 IP 비허용, 위치 제한, 서비스 계정 키 생성 방지).
  • 사용자가 아닌 Google Groups에 IAM 역할을 부여하고, 기본 역할보다 사전 정의된 역할을 선호합니다. 정기적으로 역할 바인딩을 검토하고 사용하지 않는 권한을 제거합니다.
  • 감사 가능성 및 귀속성을 활성화합니다. VM에 대한 관리자 OS 액세스의 경우, 사용자별 SSH 키와 함께 OS Login을 사용하고 그룹에 roles/compute.osLogin 또는 roles/compute.osAdminLogin 역할을 부여합니다. 예시:
    • gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
    • gcloud projects add-iam-policy-binding PROJECT_ID –member=‘group:ops@example.com’ –role=‘roles/compute.osAdminLogin’
  • 일반적인 실패 모드: 사용자에게 소유자 또는 편집자 역할을 부여하는 것, 프로젝트 전체 SSH 키를 사용하는 것, 장기 수명 서비스 계정 키를 생성하는 것.

• BeyondCorp 및 Identity-Aware Proxy(IAP)를 사용한 애플리케이션 액세스 보호

  • IAP는 HTTPS 앱과 TCP 전달(SSH/RDP)에 대해 Google 에지에서 ID 인식 액세스를 종료하므로, 앱이나 배스천 호스트를 인터넷에 노출할 필요가 없습니다. 컨텍스트 인식 액세스 정책(Access Context Manager)과 결합하여 기기 상태, IP 범위 또는 사용자 그룹을 요구하도록 설정합니다.
  • 이점: 중앙 집중식 인증(AuthN)/권한 부여(AuthZ), 강력한 귀속성, 공격 표면 감소, 방화벽 정책 단순화(부하 분산기/IAP를 제외한 인바운드 거부).
  • 절충점: 잘못 구성하면 관리자가 잠길 수 있으므로 비상 접근 경로(제한된 프로젝트 소유자, 대역 외 콘솔 액세스)를 유지해야 합니다. 일부 레거시 프로토콜이나 비 HTTP 서비스에는 IAP TCP 전달 또는 대체 제어가 필요할 수 있습니다.

• 서비스 계정 및 워크로드 아이덴티티

  • 서비스 계정을 Compute Engine, Workload Identity를 사용하는 GKE, Cloud Run, Cloud Functions에 연결하여 워크로드가 단기 수명 토큰을 자동으로 얻도록 하는 것을 선호합니다. 키를 포함하지 말고, 조직 정책으로 서비스 계정 키 생성을 비활성화하십시오. 서비스 계정에 대한 IAM 범위를 최소 권한 원칙에 따라 좁게 설정하십시오.
  • 실패 모드: 가장(impersonation)을 허용하는 roles/iam.serviceAccountUser 역할을 광범위하게 부여하는 것, 수평 이동(lateral-movement) 표적이 되는 과도한 권한의 서비스 계정.

데이터 보호 및 키 관리

• 암호화, Cloud KMS, CMEK 및 봉투 암호화

  • Google은 기본적으로 모든 저장 데이터와 전송 중인 데이터를 암호화합니다. 추가적인 제어 및 직무 분리를 위해 Cloud KMS에서 고객 관리 암호화 키(CMEK)를 사용하십시오. 많은 서비스(BigQuery, Cloud Storage, Pub/Sub, Compute Engine 디스크)가 CMEK를 지원합니다. 서비스는 사용자의 CMEK가 객체별 또는 청크별 DEK를 래핑하는 봉투 암호화 방식을 사용합니다.
  • 키 계층 구조 계획: 리전별 키 링, 데이터 도메인별 암호화 키, 위험에 따라 90~365일마다 순환. 순환 예시:
    • gcloud kms keys update KEY_NAME –keyring=KR –location=REGION –rotation-period=90d –next-rotation-time=YYYY-MM-DDT00:00:00Z
  • 액세스 제어: 서비스 계정에는 필요한 키에 대해서만 Cloud KMS CryptoKey Encrypter/Decrypter 역할을 부여합니다. Cloud KMS 사용량 로그로 모니터링합니다.
  • 실패 모드 및 절충점: CMEK를 비활성화하거나 삭제하면 종속된 데이터를 읽을 수 없게 됩니다. 인시던트 대응 계획을 세우고, 순환 전에 IAM을 재확인하며, 배포 전반에 걸쳐 키 가용성을 유지하십시오. Google Cloud 외부에서 키를 보관해야 하는 경우 External Key Manager를 고려하되, 추가적인 지연 시간과 외부 종속성 위험을 감안해야 합니다.

• Secret Manager 및 하드코딩된 사용자 인증 정보 제거

  • API 키, DB 비밀번호, 토큰을 자동 버전 관리 및 IAM 기반 액세스가 가능한 Secret Manager에 저장합니다. Cloud Scheduler → Pub/Sub → Cloud Functions/Run을 통해 순환을 통합하여 업스트림 시스템을 업데이트하고 새 보안 비밀 버전을 작성합니다. 애플리케이션은 시작 시 또는 필요 시 보안 비밀을 가져오고 최소한으로 캐시합니다.
  • 권장사항: 코드나 이미지에 보안 비밀을 커밋하지 말고, 로그에 보안 비밀을 출력하지 않으며, 워크로드 아이덴티티에 roles/secretmanager.secretAccessor 역할을 부여하고, 라벨을 사용하여 민감도를 태그합니다.
  • 실패 모드: 충돌 시 로그에 기록될 수 있는 환경 변수에 보안 비밀을 포함하는 것, 순환 후 다운스트림 앱 업데이트를 잊는 것, 보안 비밀에 대한 광범위한 IAM 설정.

• 데이터 분류, 보관 및 개인정보 보호

  • 데이터를 분류(공개, 내부, 기밀, 규제 대상)하고 라벨로 애셋에 태그를 지정합니다. 세분화된 제어를 위해 BigQuery 열 수준 보안 및 행 액세스 정책을 사용합니다. 검색 및 마스킹을 위해 Sensitive Data Protection(DLP)을 사용합니다.
  • 보관 정책 구현: Cloud Storage 객체 수명 주기(기간 기반 클래스 전환, 삭제), 보류 기능이 있는 버킷 보관 정책, BigQuery 테이블 또는 파티션 TTL. 보관 기간을 법적 요구사항에 맞추십시오. 보관 기간이 길어지면 위험과 비용이 증가합니다.
  • 개인정보 보호 및 상주 위치: 조직 정책으로 리소스 위치를 제한하고, 주권 및 지연 시간 요구사항에 따라 다중 리전과 리전 스토리지 중에서 선택합니다. 감사 로그와 SCC 상태 대시보드를 사용하여 증거를 생성합니다.

네트워크 및 에지 보안

• 네트워크를 위한 심층 방어

  • 기본 거부(deny) 입장의 VPC 방화벽 규칙을 사용하고, 필요한 소스 범위와 포트만 허용합니다. API 트래픽이 공용 인터넷을 통하지 않도록 Private Google Access와 Private Service Connect를 사용하는 것이 좋습니다. VPC Flow Logs와 Firewall Rules Logging을 기록하고, 이그레스(egress) 패턴을 정기적으로 검토합니다.
  • 아웃바운드 제어를 위해 모든 이그레스를 거부한 후, FQDN 이그레스 프록시 또는 NAT와 프록시를 통해 필요한 목적지만 명시적으로 허용합니다. Cloud NAT 로그를 모니터링하고 DNS 로깅을 구성합니다.

• VPC Service Controls (VPC SC), 서비스 경계 및 액세스 수준

  • 지원되는 Google API(예: BigQuery, Storage, Pub/Sub)를 서비스 경계로 감싸서, 자격 증명이 유출되더라도 데이터 유출 위험을 완화합니다. Access Context Manager를 사용하여 사용자 그룹, IP 또는 기기 상태별로 액세스 수준을 정의하여 컨텍스트 인식 정책을 활성화합니다.
  • 필요한 경우 합법적인 경계 간 통합 및 경계 브리지(perimeter bridge)를 위해 이그레스 규칙을 구성합니다. VPC SC의 드라이런(dry-run) 모드로 테스트하여 적용 전에 발생할 수 있는 잠재적인 중단 문제를 파악합니다.
  • 장애 모드: 의도치 않게 CI/CD 또는 교차 프로젝트 작업을 차단하거나, 서드파티 통합이 실패하거나, 개발자가 관리되지 않는 기기로 우회하는 경우입니다. 예외 사항을 문서화하고 정기적으로 검토합니다.

• Cloud Armor, DDoS 보호 및 WAF 규칙

  • Google의 글로벌 에지는 상시 작동하는 L3/L4 DDoS 보호를 제공합니다. Cloud Armor는 외부 HTTP(S) 부하 분산기를 위한 L7 보호를 추가하며, 여기에는 비율 제한, 지역/IP 기반 액세스, 커스텀 표현식, 사전 구성된 WAF 규칙 세트가 포함됩니다.
  • 기본 WAF를 생성하고 연결하는 예시:
    • gcloud compute security-policies create web-waf
    • gcloud compute security-policies rules create 1000 –security-policy=web-waf –expression=“evaluatePreconfiguredWaf(‘sqli-v33-stable’)” –action=deny-403 –preview
    • HTTPS 부하 분산기 백엔드 서비스에 정책을 연결합니다.
  • 권장사항: 오탐(false positive)을 줄이기 위해 미리보기(preview) 모드에서 규칙을 시작하고, 알려진 정상 트래픽에 대한 허용 규칙을 추가하며, 자격이 되는 경우 적응형 보호(adaptive protection)를 활성화합니다. 절충점: Cloud Armor는 HTTP(S) 및 프록시 기반 부하 분산기에 적용됩니다. 네트워크 부하 분산기 및 내부 LB는 다른 제어가 필요합니다.

보안 운영 및 규정 준수

• Security Command Center(SCC) 및 보안 태세 관리

  • SCC를 위험 가시성을 위한 제어 평면으로 사용합니다. Standard 등급은 잘못된 구성 감지 결과와 취약점 데이터를 집계하고, Premium 등급은 위협 탐지(예: Event Threat Detection, VM 및 Container Threat Detection) 및 공격 경로 분석을 추가합니다.
  • 심각도에 따라 감지 결과를 분류하고, 소유자를 할당하며, 해결될 때까지 추적합니다. SIEM 통합 및 증거 수집을 위해 감지 결과를 BigQuery 또는 Pub/Sub으로 내보냅니다. 조직 정책에 따라 지속적으로 보안 태세를 측정하고, 보안 수준이 저하될 경우 알림을 설정합니다.

• Shielded VM, 보안 부팅, vTPM, 무결성 모니터링 및 OS 강화

  • Shielded VM 기능을 활성화하여 루트킷과 부팅 변조를 차단합니다: Secure Boot, vTPM, Integrity Monitoring을 사용하여 부트로더와 커널의 변경 사항을 감지합니다. 일부 커스텀 커널이나 서명되지 않은 모듈은 Secure Boot에 실패할 수 있으므로, 활성화하기 전에 이미지를 검증해야 합니다.
  • OS Config를 사용하여 패치 규정 준수, CIS 정렬 기준, 최소 패키지 설치, 비밀번호 없는 SSH, sudo 및 인증 이벤트 로깅으로 OS를 강화합니다. SSH에는 IAP TCP 전달을 사용하는 것을 선호하며, 0.0.0.0/0으로의 인그레스(ingress)를 제한합니다.

• 포렌식 로깅, 인시던트 분류, 격리 및 해결

  • 포렌식을 위한 로깅: 관리자 활동 및 데이터 액세스 감사 로그, VPC Flow Logs, Firewall Rules Logging, Cloud DNS 로그, 부하 분산기 로그, Cloud KMS 및 Secret Manager 액세스 로그.
  • 중앙화된 로그 프로젝트와 BigQuery로 내보내고, 적절한 보존 기간과 접근 제어를 설정합니다.
  • 분류 및 격리 플레이북:
    • SCC 감지 결과 및 연관된 로그로 지표를 검증합니다.
    • 의심스러운 토큰을 취소하고, 침해된 서비스 계정을 비활성화하며, 거부 방화벽 규칙을 추가하거나 태그를 사용하여 인스턴스를 일시적으로 격리하여 확산을 방지합니다.
    • 증거 보존: 디스크 스냅샷 생성, 로그 내보내기, 승인된 도구를 사용하여 필요한 경우 메모리 캡처, 관리 연속성(chain-of-custody) 기록.
    • 해결: 보안 비밀 및 키 순환, 취약점 패치, 알려진 정상 이미지에서 재구축, 재발 방지를 위한 탐지 기능 추가, 사후 검토를 수행하여 통제 강화.

실제 문제 시나리오

Nimbus Finance는 외부 HTTP(S) 부하 분산기 뒤에서 웹 및 API 워크로드를 실행하고, BigQuery 및 Cloud Storage에서 규제 대상 데이터를 처리하며, 엔지니어에게 원격 관리자 액세스를 허용합니다. 최근 레드팀 훈련에서 침해된 사용자 인증 정보를 통한 데이터 유출 및 측면 이동(lateral movement)의 위험이 드러났습니다. 운영팀은 서비스 제공에 지장을 주지 않으면서 액세스를 강화하고, 데이터를 보호하며, 탐지 능력을 개선해야 합니다.

1. 관리자 책임 추적을 위해 OS Login 강제 적용

• 단계: 프로젝트 전체에 OS Login 활성화; 엔지니어 그룹에 compute.osAdminLogin 추가; 프로젝트 전체 SSH 키 제거.
• 근거: 사용자별 SSH 키와 IAM 기반 역할 부여는 명확한 책임 추적과 간단한 권한 취소를 제공합니다. 공유 키를 제거하여 측면 이동을 줄입니다.

2. IAP 및 컨텍스트 인식 액세스로 원격 액세스 제어

• 단계: 관리자 UI를 IAP로 보호되는 HTTPS 부하 분산기 뒤에 배치; Access Context Manager를 통해 운영 그룹 멤버십 및 회사 IP/기기 보안 상태 요구.
• 근거: 제로 트러스트 액세스는 공개 노출을 제거하고 ID 및 기기 조건을 중앙에서 강제하여 피싱 및 크리덴셜 스터핑(credential-stuffing) 위험을 줄입니다.

3. 단계적 적용을 통한 Cloud Armor WAF 구현

• 단계: Cloud Armor 정책 생성; 미리 구성된 SQLi/XSS용 WAF 규칙을 미리보기 모드로 활성화; /login에 대한 비율 제한 규칙 추가; 로그 모니터링 후 적용.
• 근거: 미리보기 모드는 오탐(false positive)을 줄이고, 특정 경로에 대한 비율 제한은 정상 트래픽에 영향을 주지 않으면서 크리덴셜 스터핑과 봇을 완화합니다.

4. VPC Service Controls로 데이터 서비스 보호

• 단계: BigQuery 및 Cloud Storage 프로젝트를 위한 서비스 경계 생성; 승인된 CI/CD 및 분석 작업을 위한 이그레스(egress) 규칙 정의; 그룹 및 네트워크 기반 액세스 수준 요구.
• 근거: 서비스 경계는 보호된 데이터에 액세스할 수 있는 위치와 방법을 제한하여 유효한 사용자 인증 정보를 이용한 데이터 유출을 완화합니다.

5. Cloud KMS로 CMEK를 적용하고 순환 예약

• 단계: BigQuery 및 Storage를 위한 리전별 키 링 및 암호화 키 생성; 서비스 계정에만 roles/cloudkms.cryptoKeyEncrypterDecrypter 역할 부여; 180일 순환 일정 설정; 키 사용 로그 모니터링.
• 근거: CMEK는 직무 분리를 강제하고 통제된 암호화 경계를 적용합니다. 키 순환은 키가 노출될 경우의 영향 범위를 제한합니다.

6. Secret Manager로 보안 비밀을 중앙화하고 순환 자동화

• 단계: 데이터베이스 및 서드파티 토큰을 Secret Manager로 이동; 워크로드에 최소 권한 액세스 부여; Cloud Scheduler → Pub/Sub → Cloud Run 작업을 구현하여 보안 비밀을 순환하고 새 버전을 생성.
• 근거: 하드코딩된 사용자 인증 정보를 제거합니다. 버전 관리와 자동화는 최소한의 다운타임으로 예측 가능하고 감사 가능한 순환을 보장합니다.

7. Shielded VM 및 OS 강화로 호스트 보안 강화

• 단계: 모든 Compute Engine 인스턴스에서 Secure Boot, vTPM, Integrity Monitoring 활성화; 비밀번호 없는 SSH 강제; OS Config를 사용하여 매주 패치하고 CIS 기준 적용.
• 근거: 부팅 수준의 변조를 방지하고, 구성 변경(drift)을 감지하며, 컴퓨팅 노드의 공격 표면을 줄입니다.

8. SCC로 가시성 및 보안 태세 관리 강화

• 단계: 조직 전체에 SCC Premium 활성화; Pub/Sub으로 실시간 알림 구성; 감지 결과와 로그를 BigQuery로 내보내기; 주요 KPI(미해결된 높은 심각도의 감지 결과 수, 평균 해결 시간) 대시보드 구축.
• 근거: 통합된 가시성은 탐지에서 대응까지의 시간을 단축하고 규정 준수 증거를 제공합니다.

9. 인시던트 플레이북 준비 및 테스트

• 단계: 분류 단계, 비상용 관리자 계정(privileged break-glass accounts), 격리 조치(IAM 비활성화, 방화벽 격리, 토큰 취소) 문서화; 분기별로 연습; 증거 프로젝트에서 로그 보존 및 객체 잠금(object holds) 강제.
• 근거: 연습된 워크플로는 긴급 상황에서의 실수를 줄이고, 근본 원인 분석 및 규제 보고를 위한 포렌식 무결성을 보존합니다.

10. 변경 사항 검증 및 중단 최소화

• 단계: VPC SC 드라이런(dry run) 및 Cloud Armor 미리보기 모드를 사용하여 장애 감지; 카나리(canary) 배포를 통해 환경별로 출시; 롤백 계획 및 변경 기간 유지.
• 근거: 통제된 출시는 데이터 유출 및 액세스 위험을 목표 수준으로 줄이면서, 강화된 보안으로 인한 가용성 위험을 완화합니다.

← 모니터링 · 모든 도메인 · 안정성 →

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

Google 찾아보기 →