클라우드 보안의 95%는 IAM에서 결정된다
클라우드 보안 사고의 90% 이상은 잘못된 IAM 설정에서 시작됩니다. 과도한 권한을 가진 서비스 계정 키가 GitHub에 노출되거나, 퇴사한 직원의 계정이 여전히 프로덕션 리소스에 접근하거나, 누군가 관리자 권한을 조용히 추가해도 아무도 모르는 상황 — 이 모든 문제의 뿌리는 IAM입니다. Associate Cloud Engineer 시험에서도 IAM 도메인은 전체 문항의 약 17%를 차지하며, 단순 암기가 아닌 실제 보안 판단 능력을 검증합니다. 이 글은 Cloud IAM 모델의 기초부터 서비스 계정의 올바른 사용법, Cloud Audit Logs를 활용한 운영 추적까지 GCP 보안 운영의 전체 그림을 다룹니다.
---
Cloud IAM 모델: 멤버, 역할, 바인딩
Cloud IAM의 핵심은 세 가지 개념의 조합입니다. 멤버(member)는 누구인가를 나타내고, 역할(role)은 무엇을 할 수 있는가를 정의하며, 이 둘을 연결하는 것이 정책 바인딩(policy binding)입니다.
멤버 유형은 다섯 가지입니다.
| 멤버 유형 | 설명 | 예시 | |---------|------|------| | Google Account | 개인 Google 계정 | user@gmail.com | | Service Account | 애플리케이션·VM용 계정 | my-app@project-id.iam.gserviceaccount.com | | Google Group | 계정 묶음 단위 | dev-team@company.com | | Google Workspace Domain | 도메인 전체 | @company.com | | allAuthenticatedUsers | 모든 인증 Google 계정 | (공개 리소스에 주의) |
Google Group을 활용한 바인딩이 대규모 조직에서 권장되는 이유는 간단합니다. 그룹에 역할을 한 번 바인딩하면 이후에는 그룹 멤버십만 관리하면 됩니다. IAM 정책 자체는 변하지 않아 감사 부담도 줄어듭니다. 한 정책에는 최대 1,500개의 바인딩을 설정할 수 있습니다.
시험 함정: allUsers는 인터넷의 모든 사람(인증 없이), allAuthenticatedUsers는 Google 계정으로 인증된 모든 사람입니다. 공개 Cloud Storage 버킷에만 allUsers를 사용하고, 민감 데이터에는 절대 적용하지 않습니다.
---
역할 3종과 최소 권한 원칙
Cloud IAM 역할은 세 가지 유형으로 구분됩니다. 각 유형의 특성과 적합한 사용 상황을 이해하면 시험 정답이 보입니다.
| 역할 유형 | 예시 | 권한 범위 | 시험 출제 방향 | |---------|------|---------|-------------| | 기본 역할 (Basic) | roles/owner, roles/editor, roles/viewer | 프로젝트 전체, 매우 광범위 | 거의 항상 오답 (최소 권한 위반) | | 사전 정의 역할 (Predefined) | roles/compute.admin, roles/bigquery.dataViewer | 서비스·작업 단위 | 대부분의 상황에서 정답 | | 사용자 정의 역할 (Custom) | 직접 권한을 선택해 조합 | 매우 세밀한 제어 | 사전 정의 역할이 없을 때 사용 |
기본 역할이 권장되지 않는 이유는 명확합니다. roles/editor는 프로젝트 내 대부분의 리소스를 수정할 수 있고, roles/owner는 IAM까지 포함한 전권을 갖습니다. 특정 서비스만 관리해야 하는 사람에게 부여하면 최소 권한 원칙에 위배됩니다. 시험에서 "보안을 강화하면서", "필요한 권한만" 같은 표현이 나오면 가장 좁은 사전 정의 역할을 선택합니다.
사용자 정의 역할은 사전 정의 역할로 요구사항을 충족할 수 없을 때 사용합니다. 주의할 점은 조직 수준 또는 프로젝트 수준에서만 생성 가능하며 폴더 수준은 지원하지 않는다는 것입니다. IAM Recommender는 90일 사용 이력을 머신러닝으로 분석하여 사용되지 않는 권한 제거를 추천합니다. 보안 감사 후 조직 전체 최소 권한 표준 수립 시나리오에서는 IAM Recommender가 정답입니다.
!IAM 역할 3가지 유형
정책 상속과 IAM Conditions
GCP의 리소스는 계층 구조로 조직됩니다. 이 계층에서 IAM 정책은 위에서 아래로 상속됩니다.
| 계층 | 설명 | 상속 방향 | |------|------|----------| | Organization | 최상위 단위 (회사/도메인) | 하위 모두에 상속 | | Folder | 부서·환경 단위 그룹 | 하위 프로젝트에 상속 | | Project | 리소스 격리 기본 단위 | 하위 리소스에 상속 | | Resource | 개별 Compute Engine, Cloud Storage 등 | 상속받는 최하위 |
상속의 핵심 규칙은 "상위에서 부여된 권한은 하위에서 제거할 수 없다"입니다. 폴더 수준에서 roles/editor를 부여받으면 그 아래 모든 프로젝트에 editor 권한이 적용되며, 특정 프로젝트에서만 제거하는 것은 불가능합니다. 권한은 가능한 가장 좁은 범위에서 부여해야 합니다.
IAM Conditions는 역할 바인딩에 시간, 리소스 이름, 리소스 유형 등의 조건을 추가해 세밀하게 제어하는 기능입니다. 야간 배포 작업자에게 특정 시간대에만 유효한 일시적 권한을 부여하고 시간이 지나면 자동 소멸하도록 구성하는 것이 대표적인 활용 패턴입니다.
| 조건 유형 | 사용 예시 | 활용 시나리오 | |---------|---------|-------------| | 시간 기반 | 업무 시간(09:00~18:00)에만 접근 허용 | 개발 환경 접근 시간 제한 | | 리소스 이름 | 특정 버킷 이름 패턴에만 적용 | 환경별(dev/prod) 버킷 분리 | | 리소스 유형 | compute.googleapis.com/Instance에만 적용 | VM만 관리 가능한 역할 |
---
서비스 계정의 본질과 키 관리 위험
서비스 계정은 GCP에서 동시에 두 가지 역할을 합니다. 멤버(ID)로서 IAM 역할을 부여받아 GCP 리소스에 접근하는 주체이고, 동시에 리소스로서 "누가 이 서비스 계정을 가장할 수 있는가"를 IAM으로 제어합니다. Compute Engine VM, Cloud Run, Cloud Functions 등 모든 GCP 컴퓨팅 리소스는 서비스 계정을 연결해 다른 GCP 서비스에 접근합니다.
서비스 계정 키(JSON 파일)는 GCP에서 가장 위험한 아티팩트 중 하나입니다.
| 접근 방식 | 보안 수준 | 권장 여부 | 비고 | |---------|---------|---------|------| | 서비스 계정 키 (JSON) | 낮음 | 권장하지 않음 | 노출 시 즉각적 위험, 만료 없음 | | 서비스 계정 가장 (Impersonation) | 높음 | 권장 | 단기 토큰, 감사 로그 추적 가능 | | Workload Identity (GKE) | 매우 높음 | 강력 권장 | 키 없음, 자동 갱신 | | Workload Identity Federation (외부) | 매우 높음 | 강력 권장 | 외부 IdP 신원으로 직접 인증 |
키 파일은 만료 기간이 없어 한 번 발급되면 명시적으로 삭제하지 않는 한 영구적으로 유효합니다. GitHub 저장소, Docker 이미지, 로그 파일에 실수로 포함되는 사고가 반복적으로 발생합니다. Google의 공식 권장 사항은 Workload Identity 계열로 대체하는 것입니다.
서비스 계정 가장(Impersonation)은 roles/iam.serviceAccountTokenCreator 역할로 단기 토큰을 발급해 해당 서비스 계정 권한으로 API를 호출하는 방식입니다. 토큰은 최대 1시간 후 자동 만료되며 가장 행위가 Cloud Audit Logs에 기록되어 추적이 가능합니다. 키 사용이 불가피한 레거시 환경에서는 정기 교체와 즉시 삭제, Cloud KMS 관리를 병행합니다.
---
Workload Identity와 Workload Identity Federation
서비스 계정 키 없이 GCP에 접근하는 두 메커니즘을 구분하는 것이 시험의 핵심입니다.
| 항목 | Workload Identity (GKE) | Workload Identity Federation (외부) | |------|------------------------|-------------------------------------| | 대상 | GKE 파드 전용 | AWS, Azure, GitHub Actions, 온프레미스 등 | | 원리 | KSA → GSA 바인딩 | 외부 IdP 토큰 → GCP 단기 토큰 교환 | | 키 필요 | 없음 | 없음 | | 시나리오 | GKE 워크로드 → GCP API | 외부 CI/CD, 멀티클라우드 → GCP API |
Workload Identity는 GKE 파드의 Kubernetes Service Account(KSA)를 GCP Service Account(GSA)에 연결합니다. 파드가 별도의 키 없이 GCP API를 호출하며, 인증 정보는 메타데이터 서버를 통해 자동 갱신됩니다.
Workload Identity Federation은 AWS IAM Role, Azure Managed Identity, GitHub Actions OIDC 토큰 등 외부 IdP 신원을 GCP가 신뢰하도록 구성합니다. 외부 시스템이 신원 토큰을 GCP Security Token Service(STS)에 제출하면 GCP는 단기 액세스 토큰을 발급합니다.
시험 구분법: "키 없이 외부 CI/CD에서 GCP 접근" → Workload Identity Federation, "GKE 파드에서 키 없이 Cloud Storage 접근" → Workload Identity(GKE 전용). 두 개념의 대상 환경이 다르다는 점을 기억하세요.
---
Cloud Audit Logs로 운영 흔적 추적하기
Cloud Audit Logs는 GCP에서 무슨 일이 일어났는지, 누가 했는지, 언제 했는지를 기록하는 감사 추적 시스템입니다. 시험에서 "누가 이 설정을 변경했는가", "언제 이 리소스가 삭제됐는가"를 묻는 문제의 정답은 Cloud Audit Logs입니다.
| 로그 유형 | 기록 내용 | 기본 활성화 | 요금 | |---------|---------|-----------|------| | 관리자 활동 (Admin Activity) | IAM 정책 변경, 리소스 생성·삭제 | 항상 (비활성화 불가) | 무료 | | 데이터 액세스 (Data Access) | BigQuery 쿼리, Cloud Storage 객체 조회 등 | 비활성화 (수동 필요) | 유료 | | 시스템 이벤트 (System Event) | GCP 내부 자동화 (라이브 마이그레이션 등) | 항상 | 무료 | | 정책 거부 (Policy Denied) | IAM에 의해 거부된 요청 | 항상 | 유료 |
데이터 액세스 로그는 기본 비활성화 상태입니다. BigQuery 쿼리 이력을 감사해야 한다면 반드시 수동으로 활성화해야 합니다. Cloud Logging의 Log Explorer에서 필터로 특정 이벤트를 검색할 수 있습니다.
Audit Logs 장기 보관은 Cloud Logging 싱크(Sink)로 Cloud Storage 버킷에 내보냅니다. 기본 보관 기간은 관리자 활동·시스템 이벤트 로그 400일, 데이터 액세스·정책 거부 로그 30일입니다. 규정 준수 요건이 있으면 싱크 구성이 필수입니다. 로그 기반 메트릭(Log-based Metrics)으로 IAM 정책 변경 감지 시 Cloud Monitoring 알림을 트리거하는 것도 운영 필수 패턴입니다.
---
정리: 시험 빈출 시나리오와 안전한 IAM 체크리스트
GCP-ACE IAM 도메인에서 반복적으로 출제되는 시나리오와 정답 패턴을 정리합니다.
| 시나리오 | 정답 패턴 | 오답 함정 | |---------|---------|----------| | 팀 단위 권한 관리, 팀원 변경 잦음 | Google Group + 사전 정의 역할 | 개인별 IAM 바인딩 | | 특정 버킷만 읽기 | 버킷 수준 roles/storage.objectViewer | 프로젝트 수준 roles/storage.admin | | 조직 전체 과도한 권한 식별 | IAM Recommender | 수동 검토 | | GKE 파드 → GCP API, 키 없이 | Workload Identity | 서비스 계정 키 | | 외부 CI/CD → GCP API, 키 없이 | Workload Identity Federation | 서비스 계정 키 | | 누가 리소스를 삭제했는가 | Cloud Audit Logs (Admin Activity) | Cloud Monitoring | | BigQuery 쿼리 기록 확인 | Cloud Audit Logs (Data Access, 수동 활성화) | Cloud Logging 기본 로그 | | 임시 권한 위임, 1시간 제한 | IAM Conditions (시간 기반) 또는 서비스 계정 가장 | 서비스 계정 키 발급 |
안전한 IAM 운영 체크리스트입니다.
서비스 계정 키 발급 전 Workload Identity 또는 Workload Identity Federation으로 대체 가능한지 검토합니다. 기본 역할(roles/owner, roles/editor)은 테스트 환경에서도 사용하지 않는 것을 원칙으로 합니다. IAM Recommender를 정기적으로 검토하여 사용되지 않는 권한을 제거합니다. 데이터 액세스 감사가 필요하면 Cloud Audit Logs Data Access 로그를 명시적으로 활성화합니다. Cloud Storage 싱크로 Audit Logs를 장기 보관하여 규정 준수 요건을 충족합니다.
GCP 보안의 출발점은 "최소한의 권한을, 가장 좁은 범위에, 필요한 기간 동안만"이라는 원칙입니다. Cloud IAM은 이 원칙을 구현하는 도구이고, Cloud Audit Logs는 이 원칙이 실제로 지켜졌는지 검증하는 수단입니다.