Troca de dados segura com regras de entrada e saída

As configurações de entrada/saída de troca de dados permitem o acesso de/para clientes e recursos separados por perímetros de serviço. O acesso é definido por regras de entrada e saída.

Para uma visão geral das regras de entrada e saída, consulte Regras de entrada e saída.

Para saber como aplicar políticas de regra de entrada e saída, consulte Como configurar políticas de entrada e saída.

Exemplos de configuração de casos de uso de troca de dados segura

Esta seção contém os seguintes exemplos em casos de uso da troca de dados segura:

  1. Permitir acesso a um recurso do Google Cloud fora do perímetro
  2. Compartilhamento por meio do Pub/Sub entre duas organizações em que ambos usam o VPC Service Controls
  3. PHI, segmento de dados anonimizados e organização de parceiros
  4. Imagem de disco do Compute Engine de terceiros
  5. Permitir acesso privado por uma rede VPC fora do perímetro para acessar um conjunto de dados do BigQuery
  6. Permitir que o acesso privado de uma rede VPC fora do perímetro seja carregado em um bucket do Cloud Storage (gravação)
  7. Permitir que projetos de vários perímetros compartilhem registros em um perímetro separado

Permitir acesso a um recurso do Google Cloud fora do perímetro

Saída de um perímetro

Suponha que você tenha definido o seguinte perímetro, encontrado listando o perímetro com a gcloud:

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

Agora você quer conceder acesso de leitura a um bucket do Cloud Storage no projeto 999 (que está em uma organização diferente). Você definiria a seguinte regra de saída e salvaria como gcs.yaml:

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

Aplique a regra de saída executando o seguinte comando:

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

Compartilhamento por meio do Pub/Sub entre duas organizações em que ambos usam o VPC Service Controls

Saída de um perímetro e da entrada para outro perímetro

Neste exemplo, duas organizações, Org1 e Org2, que usam o VPC Service Controls querem compartilhar dados por um tópico do Pub/Sub.

Suponha que você tenha definido os seguintes perímetros, encontrados ao listar os perímetros com a gcloud:

# 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

Para ativar essa troca, a Org1 precisa definir uma regra de saída que permita a assinatura.

# 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 precisa definir uma regra de entrada correspondente que permita a assinatura.

# 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
""" > org2ingress.yaml

Aplique as regras de entrada e saída executando os seguintes comandos:

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, segmento de dados anonimizados e organização de parceiros

Entrada no perímetro e saída do perímetro

Neste exemplo, você quer definir um perímetro em torno de um segmento de dados de Informações protegidas de saúde (PHI, na sigla em inglês) e um segundo perímetro ao redor de um segmento de dados anonimizados. Você quer ativar o compartilhamento de dados anonimizados com uma organização parceira e, ao mesmo tempo, permitir que o segmento de PHI manipule os dados no segmento de dados anonimizados.

Suponha que você tenha definido os dois perímetros a seguir, que podem ser encontrados listando o perímetro com a gcloud:

# 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

Também presumimos que o projeto da organização do parceiro é 999. Você definiria as seguintes regras de política direcional:

# 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
""" > 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

Aplique as regras de saída executando os seguintes comandos:

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

Imagem de disco do Compute Engine de terceiros

Saída para o projeto de imagem

Neste exemplo, você quer autorizar o uso de uma imagem de disco do Compute Engine em um projeto de imagem de terceiros que esteja fora de todos os perímetros.

Suponha que você tenha definido o seguinte perímetro, encontrado listando o perímetro com a gcloud:

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

Agora você quer conceder acesso de leitura a imagens de disco no projeto 999 (que está em uma organização diferente). Você definiria a seguinte regra de saída:

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

Aplique a regra de saída executando o seguinte comando:

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

Permitir acesso privado de uma rede VPC fora do perímetro para acessar um conjunto de dados do BigQuery

Saída para o projeto de imagem

Neste exemplo, supomos o mesmo perímetro do exemplo 1:

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

Agora, seu objetivo é permitir acesso a partir de uma rede VPC fora do perímetro de vários parceiros, o que pode ser feito definindo uma regra de entrada:

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/888
    - resource: projects/999
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - method: \"*\"

""" > partneringress.yaml

Aplique a regra de entrada executando o seguinte comando:

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

Permitir que o acesso privado de uma rede VPC fora do perímetro seja carregado em um bucket do Cloud Storage (gravação)

Neste exemplo, supomos o mesmo perímetro do exemplo 1:

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

Agora, seu objetivo é permitir o acesso de uma rede VPC fora do perímetro para permitir que um parceiro carregue dados no perímetro. Para isso, defina uma regra de entrada:

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

Aplique a regra de entrada executando o seguinte comando:

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

Permitir que projetos de vários perímetros compartilhem registros em um perímetro separado

Nesse caso de uso, uma empresa tem um projeto compartilhado para coleta de dados de geração de registros de toda a implantação do Google Cloud. Eles querem registrar dados de vários perímetros diferentes do VPC Service Controls nesse projeto de registros compartilhados, que está no seu próprio perímetro. Eles não querem que o projeto de registros tenha acesso a outros recursos além dos próprios registros.

Suponha que você tenha definido os três perímetros a seguir, que podem ser encontrados listando os perímetros com a gcloud:

# 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

Para permitir que Sensitive1 e Sensitive2 gravem registros, é preciso usar:

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

Aplique as regras de saída executando os seguintes comandos:

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

Uma configuração semelhante pode ser especificada para qualquer outro perímetro de dados confidenciais que precise gravar no perímetro de registros.