GCP VPC-SC(VPC Service Controls) 정리

 

정의:
IAM(ID 기반 보안)과는 독립적으로, 컨텍스트 기반의 경계 보안을 제공하는 추가 보안 계층

목적:
데이터 무단 반출 방지: 권한이 있는 내부자가 데이터를 외부 버킷으로 복사하거나 유출하는 것을 차단
도용된 인증 정보 보호: 외부에서 훔친 계정으로 접근하더라도, 승인되지 않은 네트워크라면 API 호출을 차단
공용 노출 방지: IAM 설정 실수로 데이터가 외부에 공개되더라도, VPC SC 경계가 2차 방어선 역할을 하여 접근을 차단

 

구성도

 

• GCP 내부 동작

• VPN 연결을 통한 동작아래 그림은 PGA를 사용해서 제어하는 구성

 

• 단순 인터넷 제어

• 각 서비스별 설정방안

 

1. PGA로 오는 서비스를 제어
   
   
   
   모든 서비스 : 모두 통과
   서비스 없음 : 모두 차단
   제한된 모든 서비스 : 제한된 서비스로 선택한 리소스만 사용가능
   서비스 선택 : PGA를 사용할 서비스를 직접 선택
2. 보호할 리소스
   
   

프로젝트 : 프로젝트 내부에 존재하는 리소스들을 지킨다. (VPC도 포함)
VPC : VPC내부에 있는 VM들이 외부로 나가는 것을 차단 
공유VPC → VPC를 공유해서 쓰는 여러 서비스 프로젝트들 중 해당 VPC를 타고 들어오는 트래픽만 제어

1. 제한된 서비스
   
   
   
   보호할 서비스들 설정 (API단위)
2. 액세스 수준
   
   
   
   내부 : VPC, Subnet 설정
   외부 : Public IP 설정
3. 인그레스정책
   경계 외부의 API 클라이언트가 경계 내에 있는 리소스에 액세스할 수 있도록 허용하는 규칙

시작(from) → 종료(To) 

구분	상세 설정 항목 (무엇을 넣는가?)	비고
출발지	1. ID 및 그룹: 사용자 이메일, 서비스 계정(SA)	AND 조건으로 결합됨
	2. 소스 (액세스 수준): 허용된 IP 대역, 국가, 기기 상태	(ID + 소스 모두 맞아야 통과)
	3. 소스 (리소스): 허용된 다른 프로젝트 또는 VPC 네트워크
목적지	1. 프로젝트: 경계 내 보호받고 있는 특정 프로젝트	AND 조건으로 결합됨
	2. 서비스: 허용할 구글 서비스 (예: Storage, BigQuery)	(해당 프로젝트의 특정 기능을 허용)
	3. 작업: 허용할 구글 API의 구체적 동작 (예: Get, List, Write)

이그레스 정책
경계 내부에 있는 API 클라이언트 또는 리소스가 경계 외부의 Google Cloud 리소스에 액세스할 수 있도록 허용하는 규칙
경계가 서드 파티 API 또는 인터넷의 서비스에 대한 액세스를 차단하지 않습니다.
← 중요!! API 방화벽으로 네트워크는 차단하지 않는다는점
네트워크 차단은 방화벽 차단필요

구분	상세 설정 항목 (무엇을 넣는가?)	비고
출발지	1. ID 및 그룹: 내부의 누가 요청하는가? (보통 서비스 계정 등)	AND 조건 결합
	2. 소스 (액세스 수준): 어떤 환경에서 요청하는가? (IP, 기기 조건 등)	(요청자가 누구인지 확인)
목적지	1. 프로젝트: 성벽 밖의 어떤 프로젝트에 접근할 것인가?	AND 조건 결합
	2. 서비스: 외부의 어떤 서비스를 쓸 것인가? (예: 외부 GCS)	(어디로 나가는지 확인)
	3. 작업: 외부 리소스에서 어떤 동작을 할 것인가? (예: Write 등)

단 BigQuery Omni와 같이 타사 스토리지(AWS S3, Azure Blob)를 직접 조회하는 구글의 특정 서비스 기능을 쓸 때만 해당 외부 리소스를 제어 가능함
→ 세부 설정방안은 테스트 필요

 

- 네트워크 보안 관점으로 재설명

Access Manager Context 서비스와 같이 VPC SC를 사용하면 위치정보, IP, 기기정보(유료) 외부에서 오는 네트워크와 내부 VPC 트래픽으로 오는 것을 네트워크적으로 (외부IP → Vertex AI (Gemini Model API) 로 허용, 차단 하는 것은 가능합니다.

 

 

 

다만 VPC SC는 VPN으로 들어오는 On-presmise/VPN IP의 네트워크단 제어를 지원하지를 않음

On-premise → GCP (Host VPC)로 들어오기에 해당 VPC를 허용하면, 해당 VPC의 트래픽은 허용처리가 가능함

즉 VPN을 통해 들어오는 패킷들이 HostNetwork VPC로 왔기에 허용할 수 있는 있으며

이는 해당 VPC 에서 VM을 만든다면, 해당 VM에서 호출이 가능할 수 있습니다.
(물론 SA에 Vertex API 권한이 있어야하지만, 호출될 가능성이 있다는 점입니다.)

네트워크 IP와 Port로 제어를 원한다면, On-premise 측에서 → GCP (PSC IP)에 대해 Egress 를 차단하는 정책을 두는 것이 방법이라 판단됨

네트워크 외 다른 방안은 인그레스 정책 방안이 있습니다.

• 인그레스정책

경계 외부의 API 클라이언트가 경계 내에 있는 리소스에 액세스할 수 있도록 허용하는 규칙

네트워크(VPC)방안도 일부 포함하나, 사용자, 서비스 계정(SA)으로도 사용이 가능합니다.

GCP Docs는 아래와 같습니다.

https://docs.cloud.google.com/vpc-service-controls/docs/ingress-egress-rules?hl=ko​​

 

위의 조건을 풀어서 보면 아래와 같습니다.

구분	상세 설정 항목 (무엇을 넣는가?)	비고
출발지	1. ID 및 그룹: 사용자 이메일, 서비스 계정(SA)	AND 조건으로 결합
	2. 소스 (액세스 수준): 허용된 IP 대역, 국가, 기기 상태 (모든소스 선택가능)	(ID + 소스 모두 맞아야 통과)
	3. 소스 (리소스): 허용된 다른 프로젝트 또는 VPC 네트워크
목적지	1. 프로젝트: 경계 내 보호받고 있는 특정 프로젝트 (모든 프로젝트 가능)	AND 조건으로 결합
	2. 서비스: 허용할 GCP 서비스 (예: Storage, BigQuery)	(해당 프로젝트의 특정 기능을 허용)
	3. 작업: 허용할 GCP API의 구체적 동작 (예: Get, List, Write)

목적지의 경우 Gemini API를 사용할 프로젝트를 선택하면 됩니다.

• 서비스 차단시 
  VPC차단이나 위의 ID(그룹)으로 차단하면 아래의 결과와 같이 차단되며 상세 설명은 다음과 같습니다.
  PERMISSION_DENIED으로 실행할 수 없으며, 사유(Type)는 VPC_SERVICE_CONTROLS 인 것을 알 수 있습니다.

VPC-SC는 다양한 조건 조합이 가능하고 고객사마다 지향하는 보안 요건이 상이하므로, 특정 방식만이 '유일한 정답'이라고  정의하기는 어려움

다만, 고객사의 On-premise 자원과 결합하여 상호 보완적인 구성이 가장 효과적일 것으로 판단

On-premise/타Cloud  측 (네트워크 제어): PSC Endpoint IP로만 통신이 가능하도록 방화벽(Egress) 규칙을 적용하여 네트워크 레벨의 접근을 1차로 통제

GCP 측 (신원 제어): VPC-SC 인그레스 정책을 통해, 승인된 특정 서비스 계정(SA)만 Vertex AI API를 호출할 수 있도록 Identity 기반의 보안을 적용