
클라우드 환경에서는 수많은 사용자와 서비스가 다양한 자원에 접근합니다. 이때 "누구에게, 어떤 권한을, 어디까지 허용할 것인가?"를 체계적으로 관리하는 것은 보안의 가장 핵심적인 첫걸음입니다. Google Cloud에서는 이 모든 접근 제어를 **Cloud IAM(Identity and Access Management)**을 통해 해결하며, 그 핵심 원칙은 이미지에 나타난 것처럼 매우 간단하고 명확합니다.
이 글에서는 Cloud IAM의 핵심 3요소인 **'누가(Who)', '무엇을(What)', '어느 리소스에(On Which Resource)'**를 중심으로, 복잡하게 느껴질 수 있는 클라우드 접근 제어의 개념을 누구나 쉽게 이해할 수 있도록 풀어 설명합니다.
### '누가' (Who): 주 구성원(Principal) 정의하기
가장 먼저 정의해야 할 것은 접근을 요청하는 주체, 즉 '누가'입니다. IAM에서는 이 대상을 **주 구성원(Principal)**이라고 부릅니다. 주 구성원은 특정 개인만을 의미하지 않으며, 다음과 같은 다양한 유형이 있습니다.
- 사람 사용자:
- Google 계정: @gmail.com으로 끝나는 일반 사용자 계정입니다.
- Google Workspace / Cloud ID 계정: 기업이나 조직에서 관리하는 사용자 계정입니다.
- 애플리케이션 / 워크로드:
- 서비스 계정(Service Account): 사람이 아닌 애플리케이션이나 가상 머신(VM) 등 코드에 부여하는 고유한 로봇 계정입니다.
쉽게 비유하기 🏢 주 구성원은 **'건물 출입증을 발급받을 대상'**이라고 생각할 수 있습니다. 이 출입증은 정직원(Google Workspace 계정), 방문객(Google 계정), 또는 보안 로봇(서비스 계정)에게 발급될 수 있습니다.
### '무엇을' (What): 역할(Role)과 권한(Permission) 부여하기
'누가'를 정의했다면, 그 주체가 '무엇을' 할 수 있는지 결정해야 합니다. 이는 **역할(Role)**을 통해 이루어집니다.
중요한 점은 IAM에서는 개별적인 행동 하나하나(예: 'VM 생성하기', '파일 삭제하기')를 직접 부여하지 않는다는 것입니다. 이러한 개별 행동을 **권한(Permission)**이라고 하며, 관련된 권한들의 묶음을 **역할(Role)**이라는 하나의 직책으로 만들어 부여합니다.
- 권한(Permission): compute.instances.create와 같이 매우 구체적인 단일 행동을 의미합니다.
- 역할(Role): 'Compute 엔진 관리자', '스토리지 뷰어'처럼 여러 권한을 묶어놓은 직책입니다. 예를 들어, 'Compute 엔진 관리자' 역할에는 VM을 생성, 수정, 삭제하는 모든 권한이 포함되어 있습니다.
쉽게 비유하기 💳 권한이 'A 사무실 문 열기', 'B 창고 문 열기' 같은 개별적인 행동이라면, 역할은 이런 권한들이 포함된 **'인사팀 직원 출입증'**이나 **'보안팀 마스터키'**와 같습니다. 우리는 사람에게 행동 하나하나를 허용하는 대신, 직책에 맞는 출입증을 발급해 줍니다.
### '어느 리소스에' (On Which Resource): 접근 대상 지정하기
마지막으로, 부여된 역할이 '어느 리소스에' 적용될지 범위를 지정해야 합니다. Google Cloud의 모든 자원(VM 인스턴스, 스토리지 버킷, 데이터베이스 등)은 리소스가 될 수 있습니다.
특히 Google Cloud의 리소스는 **조직(Organization) > 폴더(Folder) > 프로젝트(Project)**라는 계층 구조를 가집니다. IAM의 중요한 특징 중 하나는 **정책 상속(Policy Inheritance)**으로, 상위 계층에 부여된 역할은 하위의 모든 리소스에 자동으로 상속됩니다.
예를 들어, 특정 '프로젝트'에 '뷰어' 역할을 부여하면, 그 사용자는 해당 프로젝트 내의 모든 VM, 스토리지, 데이터베이스를 조회할 수 있는 권한을 자동으로 갖게 됩니다. 개별 리소스마다 권한을 설정할 필요가 없어 관리가 매우 효율적입니다.
쉽게 비유하기 🏛️ '인사팀 직원 출입증'을 '본사 건물 10층'(프로젝트)에 대해서만 유효하게 만들 수 있습니다. 그러면 그 직원은 10층의 모든 사무실(리소스)에 들어갈 수 있지만, 11층(다른 프로젝트)의 문은 열 수 없습니다. 만약 '본사 건물 전체'(폴더 또는 조직)에 대한 마스터키를 준다면 모든 층의 모든 사무실에 접근할 수 있게 됩니다.
### 모든 것을 연결하는 열쇠: 허용 정책(Allow Policy)
이 세 가지 요소('누가', '무엇을', '어느 리소스에')를 하나로 묶어 최종적으로 적용하는 규칙을 **허용 정책(Allow Policy)**이라고 합니다. 즉, 허용 정책은 **"A라는 주 구성원(Principal)에게 B라는 역할(Role)을 C라는 리소스(Resource)에 부여한다"**는 하나의 완성된 선언문입니다. 이 정책이 리소스에 연결됨으로써 비로소 접근 제어가 효력을 발휘합니다.
결론적으로, Cloud IAM은 이 명확한 프레임워크를 통해 **최소 권한의 원칙(Principle of Least Privilege)**을 쉽게 구현하고, 복잡한 클라우드 환경의 보안을 강력하고 유연하게 관리할 수 있도록 돕는 핵심 도구입니다.
### 관련 웹사이트 (URL)
- Cloud IAM 개요: https://cloud.google.com/iam/docs/overview?hl=ko
- 이 글의 바탕이 된 공식 기술 문서로, IAM의 모든 구성 요소에 대해 상세히 설명합니다.
- IAM 역할 이해: https://cloud.google.com/iam/docs/understanding-roles?hl=ko
- Google Cloud에서 제공하는 기본, 사전 정의, 맞춤 역할의 차이점과 사용법을 알아볼 수 있습니다.
### 주요 용어 정리
- IAM (Identity and Access Management): 누가(ID) 어떤 리소스에 대해 무엇을(접근) 할 수 있는지 관리하는 중앙 집중식 서비스입니다.
- 주 구성원 (Principal): 접근 권한을 부여받는 대상. 사용자 계정, 서비스 계정, Google 그룹 등이 될 수 있습니다.
- 역할 (Role): 권한의 집합. '뷰어', '편집자', '소유자'와 같이 특정 직책에 해당하는 권한들을 묶어놓은 것입니다.
- 리소스 (Resource): 접근 제어의 대상이 되는 Google Cloud의 자원. (예: VM 인스턴스, Cloud Storage 버킷, 프로젝트)
- 허용 정책 (Allow Policy): '누가, 어떤 역할로, 어느 리소스에' 접근할 수 있는지를 정의하는 규칙들의 모음입니다. 이 정책이 리소스에 첨부되어 실제 효력이 발생합니다.
- 정책 상속 (Policy Inheritance): 상위 리소스 계층(예: 프로젝트)에 적용된 허용 정책이 그 아래의 모든 하위 리소스에 자동으로 적용되는 특징입니다.
'IT 지식 및 정보 (구글 클라우드 등)' 카테고리의 다른 글
| [GCP 배우기 2] GCP 핵심 인프라 완전 정복: 컴퓨팅, 스토리지, 네트워킹 가이드 (0) | 2025.10.20 |
|---|---|
| [GCP 배우기 1] 구글 클라우드(GCP) 핵심 개념 (0) | 2025.10.20 |
| [Google Cloud 소개 8] 책임을 넘어 운명까지 함께: 구글 클라우드의 '공유 책임'과 '공유 운명' 모델 (0) | 2025.10.20 |
| [Google Cloud 소개 7] 데이터를 보물로 바꾸는 Google Cloud의 청사진: BigQuery부터 Gemini까지 (0) | 2025.10.17 |
| [Google Cloud 소개 6] Google Cloud 스토리지 완벽 가이드: 내 데이터에 맞는 최적의 집은 어디일까? (0) | 2025.10.17 |