Google PCNE: Google 및 관리형 서비스에 대한 비공개 연결 — 학습 가이드

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Network Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Google 및 관리형 서비스에 대한 비공개 연결은 워크로드가 공개 IP를 사용하지 않고 Google API, Google 관리 프로듀서 네트워크 및 서드파티 서비스와 통신할 수 있게 해주는 패턴을 포함합니다. 목표는 트래픽을 비공개 경로에 유지하여 데이터 유출 위험을 줄이고, 규정 준수를 간소화하며, 예측 가능성을 향상시키는 것입니다. 핵심 구성 요소는 Private Google Access(및 제한된 엔드포인트), Private Services Access(Google 관리형 서비스에 대한 비공개 IP용), Private Service Connect(프로듀서-소비자 비공개 서비스 게시 및 사용, Google API 포함), VPC Service Controls(데이터 경계 설정), Cloud NAT(공개 인터넷으로의 비공개 아웃바운드), 그리고 결정적 엔드포인트 선택을 위한 DNS 매핑입니다.

설계 성공은 다음 세 가지 결정에 달려 있습니다.

• 어떤 비공개 액세스 메커니즘이 서비스 및 보안 모델과 일치하는지 (Google API의 경우 PGA vs PSC, 관리형 또는 파트너 서비스의 경우 PSA vs PSC).
• 지원되지 않는 서비스를 중단시키지 않으면서 DNS가 서비스 이름을 비공개 대상으로 어떻게 확인해야 하는지.
• 장애 또는 변경 상황에서 트래픽이 엔드투엔드로 비공개로 유지되도록 라우팅과 경계 정책이 어떻게 상호 작용하는지.

장애 모드는 일반적으로 경로 선택, DNS 순서, 엔드포인트의 리전 범위 또는 호출을 조용히 거부하는 경계 규칙에서 비롯됩니다. 이름 확인, 경로, 방화벽, 엔드포인트 상태, 서비스 정책 등 각 계층을 검증해야 합니다.

Private Google Access, 제한된 엔드포인트 및 엔드포인트 선택

Private Google Access(PGA)는 외부 IP가 없는 VM 및 GKE 노드가 Cloud NAT가 아닌 VPC의 기본 인터넷 게이트웨이를 통해 Google 애니캐스트 VIP를 사용하여 Google API 및 서비스에 연결할 수 있게 해줍니다. 서브넷별로 활성화됩니다.

• 엔드포인트:

  • private.googleapis.com (199.36.153.8/30): 전체 Google API 서비스.
  • restricted.googleapis.com (199.36.153.4/30): VPC Service Controls와 호환되는 API의 하위 집합. 서비스 경계를 적용할 때 사용합니다.

• DNS 매핑 접근 방식:

  • 기본 공개 이름을 유지하고 클라이언트가 공개 DNS에 액세스하도록 허용합니다. Cloud NAT를 통한 이그레스를 허용하는 경우 이 방법이 작동하지만, 데이터 유출 통제를 약화시킵니다.
  • googleapis.com에 대한 Cloud DNS 비공개 영역에서 특정 API 호스트 이름을 restricted.googleapis.com(또는 private.googleapis.com)을 가리키는 CNAME으로 재정의하여 서비스별로 비공개 확인을 강제합니다. 예: googleapis.com 비공개 영역을 만들고 storage.googleapis.com CNAME restricted.googleapis.com을 추가합니다.

• 라우팅 고려 사항:

  • PGA는 기본 인터넷 게이트웨이로의 경로가 필요합니다. 0.0.0.0/0을 서드파티 NGFW로 보내는 경우, Google API VIP가 기본 인터넷 게이트웨이를 사용하도록 명시적인 호스트 경로를 추가해야 합니다.

undefined

• 장애 모드: 이 호스트 경로가 없으면 0.0.0.0/0 넥스트홉이 방화벽 인스턴스일 때 외부 IP가 없는 인스턴스가 API에 연결할 수 없습니다.

• 서브넷 구성:

undefined

장단점:

• restricted.googleapis.com은 데이터 유출 위험을 줄이지만 일부 API는 사용할 수 없습니다.
• PGA 트래픽은 Cloud NAT를 우회하므로 NAT 로깅에 표시되지 않습니다. 서브넷에서 VPC Flow Logs를 사용하세요.

온프레미스 클라이언트의 경우, VPC의 기본 인터넷 게이트웨이를 넥스트홉으로 하여 Cloud VPN/Interconnect를 통해 온프레미스에 199.36.153.4/30 및/또는 199.36.153.8/30을 공지하거나, PSC 엔드포인트(아래 참조)를 노출하고 온프레미스 DNS를 해당 엔드포인트에 매핑하여 Google API에 대한 비공개 액세스를 제공할 수 있습니다.

Private Services Access 및 Private Service Connect

Private Services Access(PSA)는 Cloud SQL(비공개 IP) 및 Memorystore와 같은 서비스를 호스팅하는 Google 관리형 생산자 네트워크에 비공개 IP 연결을 제공합니다. VPC에 Google이 사용할 RFC1918 범위를 할당하고 서비스 생산자 네트워크와 피어링 연결을 설정합니다.

• 설정 패턴:

  • VPC 피어링을 위한 주소 범위 예약: gcloud compute addresses create google-managed-services-range
    –global –purpose=VPC_PEERING –prefix-length=24 –network=VPC
  • 비공개 연결 설정: gcloud services vpc-peerings connect
    –service=servicenetworking.googleapis.com –network=VPC
    –ranges=google-managed-services-range
  • 비공개 IP로 관리형 서비스 프로비저닝.

• 운영 참고사항:

  • 범위는 모든 인스턴스를 수용할 만큼 충분히 커야 하며 기존 범위와 겹치지 않아야 합니다.
  • 피어링은 전이적(transitive)이지 않습니다. 트래픽은 피어링된 VPC에서 시작되어야 합니다(온프레미스는 라우팅이 허용하는 경우 VPC를 통해 연결할 수 있음).
  • 나중에 범위를 변경하거나 축소하면 서비스 중단이 발생할 수 있으므로 용량을 계획해야 합니다.

Private Service Connect(PSC)는 비공개 연결을 다음으로 확장합니다.

• Google API (소비자가 서브넷에 비공개 IP로 엔드포인트를 생성하고, DNS가 API 이름을 해당 IP에 매핑).
• 서비스 연결(service attachment)을 통해 게시된 파트너 및 SaaS 서비스.
• 서비스 연결을 통해 다른 프로젝트나 조직에 비공개로 게시된 자체 서비스.

생산자-소비자 모델:

• 생산자는 리전 내에 내부 부하 분산기(internal load balancer)를 기반으로 하는 서비스 연결을 게시합니다. 생산자는 소비자 프로젝트/조직의 허용 목록을 요구하고 연결 할당량을 지정할 수 있습니다.
• 소비자는 동일한 리전에 생산자의 서비스 연결을 대상으로 하는 PSC 엔드포인트(전달 규칙)를 생성합니다. 엔드포인트는 선택한 서브넷에서 IP를 할당받습니다.

설계 제약 조건 및 장단점:

• PSC는 리전별 서비스입니다. 소비자와 가까운 리전별로 배포하세요. DNS 정책 또는 가중치 레코드를 사용하여 가까운 클라이언트를 유도하고 장애 조치를 제공합니다.
• PSC를 통한 전이성은 없습니다. 소비자는 엔드포인트를 통해 서비스를 체인(chain)으로 연결할 수 없습니다.
• PSC 전반에서 소스 IP가 종단 간(end-to-end) 보존되지 않습니다. 이를 염두에 두고 생산자 측 제어를 설계하세요(예: ID 또는 애플리케이션 수준 인증에 의존).

일반적인 장애 모드:

• 생산자 ILB 상태 확인 실패로 인해 PSC 연결이 거부됩니다.
• 소비자 엔드포인트가 서비스 연결과 다른 리전에 생성되었습니다.
• 생산자의 거부 정책 또는 프로젝트 허용 목록 누락으로 연결이 차단됩니다.
• DNS가 엔드포인트 IP를 가리키지 않거나, 중복된 비공개 영역이 잘못된 대상으로 확인됩니다.

VPC Service Controls, 경계, 인그레스/이그레스 및 DNS 매핑

VPC Service Controls(VPC-SC)는 Google 관리형 리소스 주위에 서비스 경계(service perimeter)를 정의하여 데이터 무단 반출을 완화합니다. 경계 내에서 보호되는 서비스에 대한 요청은 범위 내 프로젝트에서 시작되어야 하며 구성된 모든 액세스 수준을 충족해야 합니다.

• 경계:

  • 표준 경계는 데이터를 호스팅하는 프로젝트(예: BigQuery, Cloud Storage)를 보호합니다.
  • 경계 브리지(Perimeter bridge)는 서로 격리된 경계 간의 제한된 상호 작용을 허용합니다.
  • 인그레스(Ingress) 규칙은 경계 외부로부터의 특정 액세스를 허용합니다(예: CI/CD 또는 모니터링 프로젝트).
  • 이그레스(Egress) 규칙은 호출할 수 있는 Google Cloud 내 외부 서비스 또는 프로젝트를 제한합니다.

• 엔드포인트 선택:

  • restricted.googleapis.com을 사용하여 API 호출을 VPC-SC 호환 서비스로 제한하고, 경계를 인식하지 못하는 공개 엔드포인트로의 우발적인 호출을 방지합니다.
  • Google API용 PSC는 트래픽을 비공개 IP에 유지하고 리전 선호도(regional affinity)를 활성화하여 더 강력한 제어를 제공하지만, 인증을 위해서는 여전히 경계 구성이 필요합니다.

• DNS 및 이름 지정:

  • Cloud DNS 비공개 영역으로 스플릿 호라이즌(split-horizon) DNS를 구현하여 내부 클라이언트가 API 이름을 비공개 대상으로 확인하도록 합니다.
  • 공개 상태를 유지해야 하는 서비스를 중단시킬 수 있는 googleapis.com 전체를 와일드카드로 지정하는 대신, restricted.googleapis.com에 대한 서비스별 레코드나 CNAME을 사용하는 것이 좋습니다.
  • PSC의 경우, 각 엔드포인트의 IP를 가리키는 A 레코드를 게시합니다. 환경 간의 우발적인 교차 사용을 방지하기 위해 환경별로 별도의 영역을 사용합니다.

주의사항:

• 공개 googleapis.com에 연결하기 위해 Cloud NAT를 사용하면 경계 규칙이 이그레스를 명시적으로 제한하지 않는 한 VPC-SC의 의도를 우회할 수 있습니다. NAT를 제한된 DNS 또는 PSC와 함께 사용하세요.
• 일부 API에는 여러 호스트 이름이 있습니다(예: JSON vs XML 엔드포인트). DNS 매핑이 클라이언트가 사용하는 모든 이름을 포함하는지 확인하세요.
• 경계 설정이 잘못되면 ‘fail-closed’(기본적으로 차단) 방식으로 동작합니다. Access Transparency 및 VPC-SC 로그를 모니터링하여 거부를 탐지하세요.

아웃바운드 패턴, 하이브리드 액세스 및 문제 해결

프라이빗 워크로드를 위한 아웃바운드 패턴:

• Google API만 사용하는 경우: PGA를 활성화하고 DNS를 restricted.googleapis.com에 매핑하거나, Google API용 PSC를 배포하고 DNS를 엔드포인트 IP에 매핑합니다.
• 인터넷 및 SaaS: 외부 IP가 없는 인스턴스에 Cloud NAT를 사용합니다. 최대 동시 연결 및 포트에 맞게 NAT 크기를 조정하고, 포트 고갈을 모니터링합니다.
• 서드파티 NGFW와 혼합: NGFW를 기본값으로 유지하되, PGA가 방화벽을 우회하도록 Google API 애니캐스트 VIP에 대한 특정 호스트 경로를 추가합니다. Google 이외의 대상에 대해서는 정책에 따라 NGFW 또는 Cloud NAT로 보냅니다.

하이브리드 클라이언트(온프레미스 또는 다른 클라우드):

• Google API를 비공개로 사용하려면:
  • 옵션 A: Cloud Router에서 온프레미스로 199.36.153.4/30 및/또는 199.36.153.8/30을 공지(advertise)하고, VPC의 기본 인터넷 게이트웨이를 다음 홉(next hop)으로 설정하여 온프레미스용 Private Google Access를 구성합니다. 필요에 따라 온프레미스 DNS를 restricted/private.googleapis.com에 매핑합니다.
  • 옵션 B: VPC에 Google API용 PSC 엔드포인트를 생성합니다. 엔드포인트 IP로 라우팅하고 온프레미스 DNS를 그에 맞게 매핑하여 Cloud VPN/Interconnect를 통해 노출합니다.
• 비공개 IP를 사용하는 Google 관리형 서비스(PSA 경유)에 연결하려면 VPC와의 연결(Cloud VPN/Interconnect)을 설정하고, RFC1918 범위가 겹치지 않도록 하며, 경로를 전파하고, 방화벽 규칙을 허용합니다.

문제 해결 및 확인:

• DNS: 클라이언트에서 API 호스트 이름에 대해 dig 또는 nslookup을 실행하여 의도한 비공개 주소(PSC 엔드포인트 IP) 또는 restricted/private 애니캐스트 VIP로 확인되는지 검증합니다. VPC의 Cloud DNS 정책 순서와 비공개 영역을 확인합니다.
• 라우팅:

undefined

를 실행하고 가장 구체적인 경로가 의도한 다음 홉(PGA VIP의 경우 기본 인터넷 게이트웨이, PSC의 경우 내부)과 일치하는지 확인합니다.

• 방화벽: 이그레스 규칙이 대상 IP에 대한 TCP 443을 허용하는지 확인합니다. PSC 뒤에 있는 부하 분산된 생산자(producer)의 경우, 상태 확인 소스 범위가 허용되는지 확인합니다.
• PGA: 서브넷 설정이 활성화되어 있는지, 그리고 커스텀 기본 경로가 있는 경우 199.36.153.4/30 및/또는 199.36.153.8/30에 대한 호스트 경로가 존재하는지 확인합니다.
• PSA:

undefined

를 실행하여 servicenetworking 피어링이 ACTIVE 상태인지, 할당된 범위가 정확하고 다른 곳에서 사용되지 않는지 확인합니다.

• PSC: 소비자(consumer) 측에서는 엔드포인트를 describe하여 연결 상태를 확인하고, 생산자(producer) 측에서는 보류 중이거나 거부된 연결 및 ILB 상태를 확인합니다. 서비스 연결(service attachment)의 소비자 허용 목록을 확인합니다.
• Cloud NAT: NAT 로깅 및 측정항목을 사용하여 변환을 확인하고, 포트 할당 또는 고갈 여부를 점검합니다. 인스턴스에 외부 IP가 있으면 설계상 NAT를 우회합니다.

실제 문제 시나리오

Contoso Research는 두 리전(us‑east1, europe‑west1)에서 분석을 실행합니다. 보안 요구사항은 다음과 같습니다. VM은 공개 IP를 가질 수 없으며, Google API는 비공개로 그리고 VPC Service Controls 하에서 연결 가능해야 합니다. 온프레미스 사용자는 Cloud SQL 인스턴스(비공개 IP)에 비공개로 액세스해야 하며, 파트너의 SaaS는 비공개로 사용해야 합니다. 서드파티 NGFW가 기본 이그레스 다음 홉입니다.

1. Private Google Access 및 제한된 엔드포인트 활성화

• 조치: 모든 분석 서브넷에서 Private Google Access를 활성화합니다. googleapis.com에 대한 Cloud DNS 비공개 영역을 만들고 필요한 API(BigQuery, Pub/Sub, Cloud Storage)에 대한 CNAME을 restricted.googleapis.com으로 추가합니다. 두 리전 모두에서 199.36.153.4/30에 대한 호스트 경로를 기본 인터넷 게이트웨이로 추가합니다.
• 근거: VM-API 간 트래픽을 비공개로 유지하고, VPC‑SC와 호환되며, 광범위한 인터넷 이그레스를 생성하지 않고 NGFW를 우회하도록 보장합니다.

2. VPC Service Controls 경계 생성

• 조치: 분석 프로젝트와 데이터 프로젝트를 서비스 경계 내에 배치합니다. 필요에 따라 Contoso 회사 네트워크에 대한 액세스 수준을 추가하고 인그레스 규칙을 통해 필요한 프로젝트 간 흐름을 명시적으로 허용합니다. 꼭 필요한 경우가 아니면 경계 브리지는 피합니다.
• 근거: Google 관리형 서비스로부터의 데이터 유출 위험을 줄이고 제한된 엔드포인트 사용과 일치시킵니다.

3. Private Services Access로 Cloud SQL 프로비저닝

• 조치: PSA에 /24를 할당하고, servicenetworking을 연결한 후, us‑east1에 비공개 IP를 가진 Cloud SQL 인스턴스를 생성합니다. Interconnect를 통해 VPC 경로를 온프레미스로 전파하고 방화벽 규칙을 허용합니다.
• 근거: 공개 노출 없이 VPC 워크로드와 온프레미스 클라이언트 모두에서 비공개 RFC1918 연결성을 제공합니다.

4. 온프레미스에서 Google API에 대한 비공개 액세스 제공

• 조치: Cloud Router에서 온프레미스로 199.36.153.4/30을 공지(advertise)하고, VPC의 기본 인터넷 게이트웨이를 다음 홉으로 설정합니다. 온프레미스 DNS에서 동일한 API 호스트 이름을 restricted.googleapis.com에 매핑합니다.
• 근거: 온프레미스 클라이언트가 동일한 제한된 비공개 경로를 사용하도록 하여 일관된 정책을 적용하고 운영상의 편차를 최소화합니다.

5. Private Service Connect를 통해 파트너 SaaS 사용

• 조치: 파트너가 리전별 서비스 연결(service attachment)을 공유합니다. 해당 연결을 대상으로 하는 PSC 엔드포인트를 us‑east1 및 europe‑west1 서브넷에 생성합니다. 각 리전 엔드포인트를 가리키는 비공개 A 레코드(saas.partner.contoso)를 게시하고, 가중치 기반 DNS를 사용하여 리전별 액세스를 우선 적용합니다.
• 근거: 생산자가 적용하는 프로젝트 허용 목록을 통해 SaaS 트래픽을 비공개 IP로 유지하고, 리전 선호도를 통해 지연 시간을 개선하며, 공개 이그레스를 방지합니다.

6. Google 이외의 인터넷 이그레스를 위해 Cloud NAT 유지

• 조치: 최대 흐름에 맞게 크기가 조정된 리전별 Cloud NAT 게이트웨이를 배포합니다. 특정 제한된 VIP 호스트 경로를 제외하고 기본 경로는 여전히 NGFW를 가리키도록 합니다.
• 근거: Google API 트래픽을 비공개로 유지하고 NGFW가 중앙 가시성을 유지하도록 하면서 Google 이외의 대상으로 제어된 아웃바운드를 허용합니다.

7. 검증 및 모니터링

• 조치: 각 클라이언트 유형에 대해 DNS 확인, 경로 선택, TLS 연결을 검증합니다. VPC‑SC 로그에서 거부 여부를, NAT 로그에서 Google 이외의 이그레스를, PSC 연결 상태를 확인합니다. 파트너의 서비스 연결 뒤에 있는 ILB와 Cloud SQL에 대한 상태 및 가용성 알림을 추가합니다.
• 근거: 데이터 경로가 설계 의도와 일치하는지 확인하고, 특히 DNS, 경로 또는 경계가 변경될 때 회귀(regression)를 조기에 발견할 수 있습니다.

← Cloud DNS · 모든 도메인 · 라우팅 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →