클라우드 환경에서 가장 중요한 보안 과제 중 하나는 누가, 어디서, 어떻게 콘솔과 API에 접근할 수 있느냐입니다.
단순히 사용자에게 권한만 부여하는 것만으로는 부족합니다. 조직 외부 계정이 무단으로 접근할 수도 있고, 내부 사용자라도 허용되지 않은 네트워크에서 접속한다면 보안 위협이 될 수 있습니다.

이 문제를 해결하기 위해 각 클라우드 서비스 제공자(CSP)는 다양한 엑세스 제어(Access Control) 기능을 제공합니다.

• Google Cloud(GCP)는 조직(Organization)과 그룹(Google Groups)을 기반으로 접근 대상을 제한하고, API 호출을 특정 네트워크로 한정할 수 있습니다.

• Microsoft Azure는 Entra ID와 Conditional Access 정책을 통해 정교한 조건부 접근 제어를 제공하지만, Premium 라이선스(P1/P2)가 필요합니다.

• AWS는 IAM 정책의 Condition 구문을 활용해 IP 기반 제어를 지원하지만, 다른 CSP에 비해 세밀함은 다소 떨어집니다.

이번 글에서는 GCP 환경에서 그룹과 IP 제어를 결합해 콘솔 및 API 접근을 조직 내부로만 제한하는 방법을 살펴보고, 실제 테스트를 통해 접근에 대한 허용/차단을 확인하도록 하겠습니다.
 

콘솔 제어를 위한 핵심 준비 사항

GCP에서 콘솔 및 API 접근 제어를 실질적으로 적용하려면 아래 세 가지 준비가 필요합니다.

1. 조직(Organization) 사용 설정

   • "콘솔 및 API 엑세스 정책"을 통해 접근을 제한하려면 기본적으로 "조직"에서만 해당 기능을 적용할 수 있습니다.

   • Cloud Identity 또는 Google Workspace를 기반으로 조직을 생성해야 조직 단위 정책과 Access Context Manager를 활용할 수 있습니다.

   • 이를 통해 "조직 외부 계정은 접근 불가"라는 기본 보안 경계를 만들 수 있습니다.

2. Admin 콘솔에서 그룹 생성

   • admin.google.com에서 그룹(예: gcp-admins@도메인)을 만듭니다.

   • 해당 그룹은 IAM 조건부 정책에서 사용되어, "이 그룹에 속한 사용자만 GCP 콘솔 로그인 및 API 호출 가능"과 같은 제약을 줄 수 있습니다.

   • 그룹 기반 제어는 계정 단위가 아니라 팀/조직 단위로 권한을 관리할 수 있게 해 관리 효율성과 보안성을 동시에 확보합니다.

3. Access Context Manager로 엑세스 수준(Access Levels) 정의

   • Access Context Manager를 이용해 IP 범위, 디바이스 조건, 위치 등 맥락(Context) 기반 접근 조건을 설정합니다.

   • 예: "조직 + 특정 그룹에 속한 사용자"이면서 "허용된 사내망 IP에서 접속한 경우에만" GCP 콘솔/API 접근 허용.

   • 이후 이 조건을 적용해 콘솔 로그인, gcloud CLI, API 호출에 동일하게 반영할 수 있습니다.
     
     추가로 아래의 권한이 필요합니다.

     • 액세스 수준 보기: Access Context Manager 리더(roles/accesscontextmanager.policyReader)
     • 액세스 수준을 보기 및 변경: Access Context Manager 편집자(roles/accesscontextmanager.policyEditor) 또는 Access Context Manager 관리자(roles/accesscontextmanager.policyAdmin)

설정 따라하기

현재 GCP에는 조직/프로젝트는 생성이 되어있는 상태로 아래 가이드를 따라 적용할 수 있습니다.

순서는 아래와 같이 진행합니다.
1. 적용할 그룹 생성 : admin 포털에서 그룹 생성
2. 엑세스 수준 생성 : GCP 콘솔에서 Access Context Manager 설정
3. 콘솔 및 API 엑세스 정책 적용 : GCP 콘솔에서 적용
 

---

1. 적용할 그룹 생성

그룹은 GCP 콘솔과 Admin 포탈 두 곳 중에 하나에서 생성이 가능합니다.
Admin 포털은 조금더 상세한 권한 제어를 포함하여 생성이 가능하며, 본 글에서는 Admin 포털에서 생성하는 방법을 설명합니다.

admin.google.com으로 접속하여 아래와 같은 화면에 진입합니다.

그룹 만들기를 하면 아래와 같으며 각 항목에서 필수 항목을 입력하면 다음 단계로 진행 가능합니다.

• 그룹 이름(필수)
• 그룹 이메일(필수) : 그룹 멤버 전체에게 동시에 메일을 보내는 대표 주소

아래 엑세스 유형은 실제 GCP의 권한에는 크게 영향을 주지는 않는 항목이나 이해를 위해 아래와 같이 간단히 설명하였습니다.
 

• 대화 = 그룹 메일/스레드 기록 (읽기 권한)
• 게시물 = 그룹에 발송되는 메일 (쓰기 권한)

 

• 그룹 소유자에게 연락할 수 있는 사용자
  • 그룹 관리와 관련된 문의를 소유자에게 직접 보낼 수 있는 권한.
  • 기본적으로는 그룹 외부 사람도 그룹 소유자에게 “연락 요청”을 할 수 있도록 열어둘 수 있어요.
• 대화를 볼 수 있는 사용자
  • Google Groups 웹 인터페이스(https://groups.google.com)에서 그룹의 메일/게시물(스레드 형태)을 열람할 수 있는 권한.
  • 여기서 말하는 “대화” = 그룹 메일로 주고받은 메시지들이 스레드 형태로 저장된 것.
  • 즉, 메일링 리스트의 **기록(아카이브)**을 볼 수 있는 권한이라고 보시면 됩니다.
• 게시물을 올릴 수 있는 사용자
  • 그룹 이메일 주소(group-name@도메인)로 메일을 보낼 수 있는 권한.
  • 예를 들어 dev-team@yamistudy.store 그룹에 메일을 보내면 → 그룹 멤버 전체에게 전달됨.
  • 여기서 “게시물” = 그룹에 발송된 메일 한 건을 의미합니다. (메일 = 게시물)
• 회원을 조회할 수 있는 사용자
  • 그룹 구성원 명단을 확인할 수 있는 권한.
  • 예를 들어 “이 그룹에는 누가 속해 있는지”를 볼 수 있는지 여부.
• 회원을 관리할 수 있는 사용자
  • 그룹에 새 멤버를 추가하거나 초대, 승인, 삭제할 수 있는 권한.
  • 보통 그룹 소유자/관리자만 가능하도록 설정합니다.

그러면 아래와 같이 Admin 포털, GCP 콘솔 모두에서 동일하게 표시되는 것을 확인할 수 있습니다.

[Admin 포털]

[GCP 콘솔]


[기타 : GCP 콘솔에서 그룹 만들기]

• 아래와 같은 화면처럼 GCP 콘솔에서도 그룹을 생성 가능하며, Admin 포털과의 차이는 "엑세스 유형"에 대한 선택이 불가능합니다.

 

2. Access Context Manager 생성

정의

• Access Context Manager는 GCP에서 Context-Aware Access(맥락 기반 접근 제어) 를 가능하게 해주는 서비스
• 사용자/그룹, IP, 디바이스 보안 상태 등을 조건으로 삼아 콘솔, API, 애플리케이션 접근을 제한할 수 있음

특징

• 조직 단위 제어: Cloud Identity / Workspace 기반 조직이 있어야 사용 가능
• 조건 기반 정책: Access Levels(엑세스 수준) 정의 → IAM, VPC SC, IAP 등과 결합
• Zero Trust 구현: 단순 권한(Role) + 네트워크 조건을 결합해 세밀한 보안 제공

할 수 있는 것들

1. VPC Service Controls와 연동
   • 민감한 API 호출을 특정 네트워크/그룹/디바이스 조건에서만 허용
2. 콘솔 / API / gcloud CLI 접근 제어
   • 조직 외부 계정 차단, 특정 IP에서만 로그인 허용
3. IAP 보호 애플리케이션 제어
   • Cloud Run, App Engine, GCE, GKE 서비스 접근 시 Access Level 조건 적용
4. BeyondCorp Enterprise와 통합
   • 디바이스 상태(관리 여부, 보안 패치, 암호화 등) 기반 제어
   • Google Workspace 앱(Gmail, Drive 등)에도 조건부 적용 가능

본 글에서는 "콘솔 및 API 엑세스 정책"에 사용하기 위함이므로 "조직"단위에서 생성을 진행합니다.



한국에 대한 지리적 제한과 내 IP(퍼블릭)으로 조건을 제한합니다.

아래와 같이 정상적으로 생성된 화면을 확인 할 수 있습니다.

3. 콘솔 및 API 엑세스 정책 적용

• 아래와 같이 "콘솔 및 API 엑세스 정책" 화면으로 들어가 "추가"를 진행합니다.

• 앞서 만든 그룹과 ACM(Access Context Manager)를 선택하여 생성합니다.

• 아래와 같이 적용이 된 것을 확인 할 수 있습니다.

 

---

테스트

아래와 같이 3개의 시나리오별로 실제 접근에 대한 통제가 이뤄지는지 확인해봅니다.

1. IP와 리전(위치) 기반 통제

• 접속하고자 하는 Public IP와 대한민국에서의 접속만 허용하도록 ACM을 설정

• 결과 : 접속을 시도한 VM(162.120.186.114)에서 콘솔 엑세스 정책에 속한 그룹의 유저로는 콘솔에 접근이 불가능함

2. 리전(위치) 기반 통제

• 리전(위치)가 대한민국 또는 미국만 접속이 가능하도록 ACM을 설정

• 결과 : 접속을 시도한 VM(162.120.186.114)에서 콘솔 엑세스 정책에 속한 그룹의 유저가 미국이므로 접근이 가능함

3. 그룹에 속하지 않은 사용자

• IP와 대한민국으로 ACM을 설정
• 결과 : 해당 User(testuser2)는 콘솔 엑세스 정책을 적용받는 그룹에 없어서 접속 가능

 

---

결론

GCP의 Access Context Manager는 단순한 IAM 권한 관리만으로는 부족한 보안을 한 단계 강화해 줍니다.
조직, 그룹, 네트워크(IP), 디바이스 조건을 조합해 “누가, 어디서, 어떤 환경에서” 접근하는지까지 통제할 수 있기 때문입니다.

결국, 콘솔과 API 접근 제어는 권한 부여(Role) + 맥락(Context) 의 결합으로 완성됩니다.
운영 환경에서는 이 원칙을 잘 적용해야만 안전한 클라우드 거버넌스를 구축할 수 있습니다.