인그레스 및 이그레스 규칙을 사용한 안전한 데이터 교환

이 문서에서는 안전한 데이터 교환에 대한 일반적인 사용 사례와 서비스 경계로 구분된 클라이언트와 리소스 간의 액세스를 허용하는 구성 예시를 설명합니다.

인그레스 규칙과 이그레스 규칙에 대한 개요는 인그레스 및 이그레스 규칙을 참조하세요.

인그레스 및 이그레스 규칙 정책을 구성하는 방법은 인그레스 및 이그레스 정책 구성을 참조하세요.

안전한 데이터 교환 사용 사례의 구성 예시

이 섹션에서는 서비스 경계에서 안전하게 데이터를 교환하는 사용 사례의 예시를 포함합니다.

경계 외부의 Google Cloud 리소스에 액세스

다음 다이어그램은 경계 외부에 있는 Cloud Storage 리소스에 액세스해야 하는 서비스 경계 내의 Compute Engine 리소스를 보여줍니다.

한 경계에서 이그레스

다음 경계를 정의했다고 가정해 보겠습니다.

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - storage.googleapis.com
title: Example

다른 조직에 있는 project 999의 Cloud Storage 버킷에 대한 읽기 액세스 권한을 부여해야 합니다. 그런 다음 파일에 다음 이그레스 규칙을 정의하고 파일을 gcs.yaml로 저장합니다.

echo """
- egressTo:
    operations:
      - serviceName: storage.googleapis.com
        methodSelectors:
        - method: google.storage.objects.get
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > gcs.yaml

다음 명령어를 실행하여 이그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Example --set-egress-policies=gcs.yaml

gcloud access-context-manager perimeters update 명령어에 대한 자세한 내용은 gcloud access-context-manager perimeters update를 참조하세요.

VPC 서비스 제어를 사용하는 두 조직 간에 Pub/Sub를 사용하여 데이터 공유

다음 다이어그램은 VPC 서비스 제어를 사용하고 Pub/Sub 주제를 사용하여 데이터를 공유하는 두 조직 Org1Org2를 보여줍니다.

한 경계에서 이그레스하고 다른 경계로 인그레스

다음 경계를 정의했다고 가정해 보겠습니다.

# Org 1 Perimeter Definition
name: accessPolicies/222/servicePerimeters/Example1
status:
  resources:
  - projects/111
  restrictedServices:
  - pubsub.googleapis.com
title: Example1

# Org 2 Perimeter Definition
name: accessPolicies/333/servicePerimeters/Example2
status:
  resources:
  - projects/222
  restrictedServices:
  - pubsub.googleapis.com
title: Example2

데이터 교환을 사용 설정하려면 Org1에서 구독을 허용하는 다음 이그레스 규칙을 저장하고 해당 파일을 org1egress.yaml로 저장해야 합니다.

# Org1: Org1's perimeter must allow a Pub/Sub subscription to project 222.

echo """
- egressTo:
    operations:
    - serviceName: pubsub.googleapis.com
      methodSelectors:
      - method: Subscriber.CreateSubscription
    resources:
    - projects/222
  egressFrom:
    identityType: ANY_IDENTITY
""" > org1egress.yaml

Org2는 구독을 허용하는 이에 상응한 인그레스 규칙을 정의하고 파일을 org2ingress.yaml로 저장해야 합니다.

# Org 2: Org2's perimeter must allow a Pub/Sub subscription from network
project 111 in Org1.

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/111
  ingressTo:
    operations:
    - serviceName: pubsub.googleapis.com
      methodSelectors:
      - method: Subscriber.CreateSubscription
    resources:
    - \"*\"
""" > org2ingress.yaml

다음 명령어를 실행하여 인그레스 규칙과 이그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Example2 1--set-egress-policies=org1egress.yaml
gcloud beta access-context-manager perimeters update Example1 1--set-ingress-policies=org2ingress.yaml

파트너 조직과 익명처리된 PHI 데이터 공유

다음 다이어그램은 PHI(보호 건강 정보) 데이터 세그먼트 주위의 경계, 익명처리된 데이터 세그먼트 주변의 두 번째 경계, 별도의 파트너 조직을 보여줍니다. PHI 세그먼트는 익명처리된 데이터 세그먼트의 데이터를 조작할 수 있으며, 익명처리된 데이터 세그먼트의 데이터는 파트너 조직과 공유됩니다.

경계로 인그레스하고 경계 외부로 이그레스

파트너 조직과 익명처리된 데이터를 공유하고 PHI 세그먼트가 익명처리된 데이터 세그먼트의 데이터를 조작할 수 있도록 허용하는 인그레스 및 이그레스 규칙을 정의하려고 합니다.

다음 경계를 정의했다고 가정해 보겠습니다.

# PhiPerimeter
name: accessPolicies/222/servicePerimeters/PhiPerimeter
status:
  resources:
  - projects/111
  restrictedServices:
  - storage.googleapis.com
  - bigquery.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: PhiPerimeter
# AnonPerimeter
name: accessPolicies/222/servicePerimeters/AnonPerimeter
status:
  resources:
  - projects/222
  restrictedServices:
  - storage.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: AnonPerimeter

파트너 조직 프로젝트가 999라고 가정할 수도 있습니다. 다음과 같은 인그레스 및 이그레스 규칙을 정의할 수 있습니다.

# Anon Perimeter

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/111
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.Write
      - method: google.storage.objects.create
    resources:
    - \"*\"
""" > anoningress.yaml

echo """
- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.Write
      - method: google.storage.objects.create
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > anonegress.yaml
# PHI Perimeter

echo """
- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/222
  egressFrom:
    identityType: ANY_IDENTITY
""" > phiegress.yaml

다음 명령어를 실행하여 인그레스 규칙과 이그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update AnonPerimeter --set-ingress-policies=anoningress.yaml --set-egress-policies=anonegress.yaml
gcloud beta access-context-manager perimeters update PhiPerimeter --set-egress-policies=phiegress.yaml

타사 Compute Engine 디스크 이미지에 대한 액세스 권한 부여

다음 다이어그램은 경계 외부에 있는 타사 이미지 프로젝트에서 Compute Engine 디스크 이미지에 액세스해야 하는 서비스 경계의 Compute Engine 리소스를 보여줍니다.

이미지 프로젝트로 이그레스

다음 경계를 정의했다고 가정해 보겠습니다.

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  - projects/222
  restrictedServices:
  - compute.googleapis.com
  - containerregistry.googleapis.com
title: Example

이제 다른 조직에 있는 project 999의 디스크 이미지에 대한 읽기 액세스 권한을 부여해야 합니다. 그런 다음 파일에 다음 이그레스 규칙을 정의하고 파일을 compute.yaml로 저장합니다.

echo """
- egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: InstancesService.Insert
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > compute.yaml

다음 명령어를 실행하여 이그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Example --set-egress-policies=compute.yaml

경계 외부의 VPC 네트워크에서 비공개 액세스를 허용하여 BigQuery 데이터 세트 읽기

다음 다이어그램은 경계 내부의 BigQuery 리소스에서 읽어야 하는 경계 외부의 여러 파트너 VPC 네트워크를 보여줍니다.

이미지 프로젝트로 이그레스

예시 1과 동일한 경계를 사용한다고 가정할 수 있습니다.

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
title: Example

목표는 다양한 파트너의 경계 외부에 있는 VPC 네트워크에서 읽기 액세스를 허용하는 것입니다. 파일에 다음 인그레스 규칙을 정의하고 파일을 partneringress.yaml로 저장합니다.

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/888
    - resource: projects/999
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: bigquery.datasets.get
      - permission: bigquery.tables.list
      - permission: bigquery.tables.get
      - permission: bigquery.tables.getData
      - permission: bigquery.jobs.create
    resources:
    - \"*\"

""" > partneringress.yaml

다음 명령어를 실행하여 인그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml

유연성 및 제어 증가를 위해 BigQuery는 대부분의 서비스에서 사용되는 - method: methodSelectors 대신 - permission: methodSelectors를 사용합니다. 단일 BigQuery 메서드(RunQuery)는 여러 다른 리소스에서 서로 다른 방식으로 작동할 수 있으며, 권한 모델에 맞게 유연성과 제어 기능이 향상됩니다.

경계 외부의 VPC 네트워크에서 비공개 액세스를 허용하여 Cloud Storage 버킷에 로드(쓰기)

예시 1과 동일한 경계를 사용한다고 가정할 수 있습니다.

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - storage.googleapis.com
  - containerregistry.googleapis.com
title: Example

목표는 경계 외부의 VPC 네트워크에서 액세스를 허용하여 파트너가 경계 내부의 버킷에 데이터를 쓸 수 있도록 하는 것입니다. 인그레스 규칙을 정의하고 파일을 partneringress.yaml로 저장합니다.

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/222
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.objects.create
    resources:
    - \"*\"
""" > partneringress.yaml

다음 명령어를 실행하여 인그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml

여러 경계의 프로젝트가 로그를 공유하도록 허용하여 개별 경계에서 로그 공유

이 사용 사례에서는 기업에 Google Cloud 배포 전반에서 로그 데이터 수집을 위한 공유 프로젝트가 있다고 가정해 보겠습니다. 기업은 여러 VPC 서비스 제어 경계의 데이터를 자체 경계 내에 있는 공유 로그 프로젝트에 로깅할 수 있어야 합니다. 로그 프로젝트는 로그 이외의 리소스에 액세스할 수 없어야 합니다.

다음 세 경계를 정의했다고 가정해 보겠습니다.

# Sensitive 1
name: accessPolicies/222/servicePerimeters/Sensitive1
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Sensitive Data 1
# Sensitive 2
name: accessPolicies/222/servicePerimeters/Sensitive2
status:
  resources:
  - projects/222
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Sensitive Data 2
#Logs
name: accessPolicies/222/servicePerimeters/Logs
status:
  resources:
  - projects/777
  restrictedServices:
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Logs Perimeter

Sensitive1Sensitive2에서 Logs 경계에 로그를 작성할 수 있도록 파일에 다음 이그레스 규칙을 정의하고 해당 파일을 logsegress.yaml로 저장합니다.

echo """
- egressTo:
    operations:
    - serviceName: logging.googleapis.com
      methodSelectors:
      - method: LoggingServiceV2.WriteLogEntries
      - method: LoggingService.WriteLogEntries
    resources:
    - projects/777
  egressFrom:
    identityType: ANY_IDENTITY
""" > logsegress.yaml

다음 명령어를 실행하여 이그레스 규칙을 적용합니다.

gcloud beta access-context-manager perimeters update Sensitive1 --set-egress-policies=logsegress.yaml
gcloud beta access-context-manager perimeters update Sensitive2 --set-egress-policies=logsegress.yaml

로그 경계에 작성해야 하는 다른 민감한 정보 경계에도 유사한 구성을 지정할 수 있습니다.

다음 단계