[GCP Associate Cloud Engineer] IAM 및 역할 관리

IAM의 개요

IAM은 관리자가 누가 무엇을 어떤 리소스에서 할 수 있는지를 정의하는 정책을 설정할 수 있도록 돕는 도구이다.

여기서 누가는 Google 계정, Google 그룹, 서비스 계정, Cloud Identity 도메인 등이 포함되며, 일반적으로 이메일 주소로 식별한다.

그리고 IAM의 역할은 권한의 집합으로, 역할을 할당하면 해당 권한이 부여 된다.

 

Deny 정책

특정 주체가 특정 권한을 사용하지 못하도록 차단 가능으로 Deny 정책은 Allow 정책보다 우선적으로 적용되기 때문에 어떤 역할을 맡게 되든 상관없이 적용이되며, 리소스 계층 구조를 따라 상속된다.

 

IAM 역할의 유형

 

기본 역할(Basic)

광범위한 권한을 부여하며, 프로젝트 내 모든 리소스에 영향을 미친다.

Viewer: 리소스 읽기 가능, 수정 불가

Editor: 리소스 수정 및 읽기 가능

Owner: 리소스 수정, 읽기, 권한 관리, 청구 설정 가능

Billing Administrator: 프로젝트 리소스를 수정하지 않고 청구만 관리 가능

 

사전 정의된 역할(Predefined)

특정 Google Cloud 서비스에 대한 정확히 정의된 역할 제공한다.

대표적인 예시로 Compute Engine이 있는데, 이를 사용하면 instanceAdmin과 같은 미리 정의된 역할을 적용하여 Compute Engine VM 인스턴스 관리 권한 부여등 특정 프로젝트, 폴더, 조직 수준에서 적용이 가능하다.

 

맞춤형 역할(Custom)

맞춤형 역할을 사용하면 정확한 권한을 정의할 수 있지만 권한 관리는 직접 해야 하므로 사전 정의된 역할을 선호하는 경우도 있다.

그리고 맞춤형 역할은 프로젝트 수준 또는 조직 수준에만 적용 가능하며, 폴더 수준에서는 불가능하다.

 

최소 권한 원칙(Principle of Least Privilege)

IAM에서 가장 중요한 원칙 중 하나는 최소 권한 원칙이다.
즉, 특정 역할 수행에 필요한 최소한의 권한만 부여해야 한다는 의미이다.

예를 들어, 개발자에게 필요한 권한만 부여해야 하며, 불필요한 추가 권한을 허용해서는 안 된다.
이 원칙을 적용하기 위해 기본 역할을 사용하는 것은 추천되지 않는다.
기본 역할인 Viewer, Editor, Owner는 광범위한 권한을 포함하고 있어 최소 권한 원칙을 위반할 가능성이 크다.

대신, 사전 정의된 역할을 사용하여 필요한 권한만 부여하는 것이 좋다.
또한, 서비스 계정을 생성할 때도 최소한의 권한만 부여해야 한다.
예를 들어, 특정 VM이 클라우드 스토리지와 통신할 필요가 있다면, 스토리지에 접근할 수 있는 최소 권한만 부여해야 한다.
불필요한 추가 권한을 부여하면 보안 리스크가 커지므로 주의해야 한다.

 

서비스 계정 분리

여러 개의 애플리케이션이 실행되는 환경에서는 각 애플리케이션마다 별도의 서비스 계정을 사용하는 것이 바람직하다.

일반적으로 Google Cloud 환경에서는 모든 애플리케이션이 공통된 서비스 계정을 공유하는 경우가 많다.
그러나 이는 보안상 좋지 않다.

각 애플리케이션이 필요로 하는 권한이 다를 수 있기 때문에, 애플리케이션별로 서비스 계정을 만들고, 해당 애플리케이션에 맞는 권한만 부여해야 한다.
이렇게 하면 불필요한 권한 노출을 방지할 수 있으며, 관리도 더 용이해진다.

 

직무 분리(Separation of Duties, SoD)

민감한 작업을 수행할 때 한 사람에게 모든 권한을 부여하는 것은 위험하다.
따라서 최소 두 명 이상이 관여하도록 역할을 분리하는 것이 보안상 권장된다.

예를 들어, App Engine에서 새로운 버전을 배포하고 트래픽을 이동하는 작업을 할 때,

App Engine Deployer 역할은 새로운 버전을 배포할 수 있지만, 트래픽을 이동할 수 없다.

App Engine Service Admin 역할은 트래픽을 새로운 버전으로 이동할 수 있지만, 새로운 버전을 배포할 수 없다.

이처럼 민감한 작업을 수행할 때는 최소 두 명 이상이 필요하도록 역할을 분리하는 것이 중요하다.
이러한 방식은 권한 오남용을 방지하고, 보안을 강화하는 효과가 있다.

 

지속적인 모니터링

IAM 정책이 적용된 후에도 계속해서 변경 사항을 모니터링하는 것이 중요하다.
이를 위해 클라우드 감사 로그를 활용해야 한다.

IAM 정책 변경 사항을 감사 로그에서 확인할 수 있다.

서비스 계정 키에 대한 접근 기록도 확인할 수 있다.

장기 보관을 위해 감사 로그를 Cloud Storage 버킷에 저장할 수도 있다.

이를 통해 비정상적인 활동을 감지하고, 보안 위협을 신속하게 대응할 수 있다.

 

그룹을 활용한 권한 관리

IAM에서 개별 사용자에게 직접 권한을 부여하는 것은 관리 부담이 크고, 실수할 가능성이 높다.
따라서 가능한 경우 그룹을 활용하는 것이 권장된다.

예를 들어, 개발자가 여러 명 있는 경우 개별 사용자에게 권한을 부여하는 대신, 개발자 그룹을 생성하고 해당 그룹에 필요한 역할을 할당하는 것이 좋다.

이후 새로운 개발자가 팀에 합류하면 그룹에 추가하기만 하면 자동으로 적절한 권한을 부여할 수 있다.

개발자가 팀을 떠나면 그룹에서 제거하면 권한이 자동으로 회수된다.

이를 통해 사용자 관리가 훨씬 쉬워지고, 권한 설정의 일관성을 유지할 수 있다.

 

추가적인 보안 강화 방안

위에서 언급한 사안 외에도 다음과 같은 보안 강화 방법을 적용할 수 있다.

 

 - 다단계 인증 적용

관리자 계정 및 중요한 IAM 계정에는 MFA를 활성화하여 보안을 강화해야 한다.

 

 - 서비스 계정 키 사용 최소화

서비스 계정 키를 직접 사용하기보다는 워크로드 아이덴티티 연동이나 OAuth 2.0을 활용하는 것이 더 안전하다.

 

 - 정기적인 IAM 정책 검토 및 감사

IAM 정책을 주기적으로 검토하여 불필요한 권한이 부여되지 않았는지 확인해야 한다.

 

ID 유형

Google 계정(Google Account)

가장 기본적인 IAM 멤버 유형은 Google 계정이다.
이는 사용자를 식별하는 이메일 주소 기반의 계정으로, 개인 사용자가 Google Cloud를 사용할 때 필수적이다.
예를 들어, Google 계정을 사용해 무료 체험 계정을 생성할 수 있다.

 

서비스 계정

서비스 계정은 사람이 아닌 애플리케이션 또는 리소스를 위한 계정이다.
즉, 애플리케이션이 Google Cloud 서비스에 접근할 때 사용된다.

예를 들어, Compute Engine VM, Cloud Functions, Kubernetes Pod 등이 특정 Google Cloud 리소스에 접근해야 할 때, 서비스 계정을 사용하여 인증 및 권한을 부여할 수 있다.

서비스 계정은 보안과 관리 효율성을 위해 최소 권한 원칙을 준수하여 생성해야 한다.

 

Google 그룹

Google 그룹은 여러 사용자 또는 서비스 계정을 하나의 단위로 묶은 그룹이다.

그룹을 생성하면 그룹 자체가 하나의 IAM 멤버처럼 동작하며, 그룹에 역할(Role)을 할당할 수 있다.

Google Cloud에서는 그룹이 하나의 이메일 주소를 가지며, 이를 통해 IAM 정책을 관리할 수 있다.

Google 그룹을 사용하는 이유는 IAM 권한을 그룹 단위로 관리할 수 있어 편리하기 때문이다.

예를 들어, 개발자 팀을 위한 그룹을 만들고, 그룹에 필요한 역할을 부여하면, 새로운 개발자가 합류할 때 단순히 그룹에 추가하는 것만으로 권한을 부여할 수 있다.

그리고 팀원 관리가 용이하고 실수로 인한 권한 남용을 방지할 수 있다.

 

Google Workspace 도메인

Google Workspace는 기업용 Google 서비스 패키지이다.

Gmail, Calendar, Google Meet, Chat, Drive, Docs 등의 협업 도구를 포함하고 있으며, 기업이 자체적으로 도메인 기반 계정을 관리할 수 있도록 해준다.

기업이 Google Workspace를 사용하면 IAM 권한을 Google Workspace 도메인 단위에서 설정할 수 있다.

예를 들어, 회사의 모든 직원이 @company.com 도메인을 사용한다면, Google Workspace를 통해 IAM 권한을 조직 단위에서 관리할 수 있으며, 특정 부서별로 권한을 차별화할 수도 있다.

 

페더레이션 및 Cloud Identity

기업에서 자체적인 사용자 디렉터리를 운영하는 경우, Google Cloud와 연동하여 기존 사용자 계정을 그대로 활용할 수 있다.
이를 페더레이션이라고 하며, Google Cloud에서는 Cloud Identity를 사용하여 이를 설정할 수 있다.

페더레이션을 사용하면 Google Cloud와 외부 ID 공급자를 연결하여 기존 엔터프라이즈 계정을 그대로 사용할 수 있다.

IAM을 통해 적절한 역할을 매핑하고 클라우드 리소스 접근을 제어할 수 있다.