Intercambio seguro de datos con reglas de entrada y salida

En este documento, se describen casos de uso comunes para el intercambio de datos seguro y parámetros de configuración de ejemplo a fin de permitir el acceso entre clientes y recursos separados por perímetros de servicio.

Para obtener una descripción general de las reglas de entrada y salida, consulta Reglas de entrada y salida.

A fin de obtener instrucciones para configurar las políticas de reglas de entrada y salida, consulta Configura las políticas de entrada y salida.

Ejemplos de configuración de casos de uso de intercambio seguro de datos

En esta sección, se incluyen ejemplos de casos de uso de intercambio seguro de datos entre perímetros de servicio.

• Acceder a un recurso de Google Cloud fuera del perímetro
• Compartir datos a través de Pub/Sub entre dos organizaciones que usan los Controles del servicio de VPC
• Compartir datos anonimizados de PHI con una organización del socio
• Otorgar acceso a una imagen de disco de Compute Engine de terceros
• Permitir un acceso privado desde una red de VPC fuera del perímetro para leer un conjunto de datos de BigQuery
• Permitir acceso privado desde una red de VPC fuera del perímetro para cargar en un bucket de Cloud Storage (escritura)
• Permitir que los proyectos de varios perímetros compartan registros en un perímetro independiente

Accede a un recurso de Google Cloud fuera del perímetro

En el siguiente diagrama, se muestra un recurso de Compute Engine dentro de un perímetro de servicio que requiere acceso a un recurso de Cloud Storage, que está fuera del perímetro:

Supongamos que definiste el siguiente perímetro:

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

Debes otorgar acceso de lectura a un bucket de Cloud Storage en project 999, que se encuentra en una organización diferente. Luego, debes definir la siguiente regla de salida en un archivo y guardarla 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

Ejecuta el siguiente comando para aplicar la regla de salida:

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

Para obtener más información sobre el comando gcloud access-context-manager perimeters update, consulta la actualización sobre perímetros de access-context-manager de gcloud .

Comparte datos a través de Pub/Sub entre dos organizaciones que usan los Controles del servicio de VPC

En el siguiente diagrama, se muestran dos organizaciones, Org1 y Org2, que usan los Controles del servicio de VPC y comparten datos a través de un tema de Pub/Sub:

Supongamos que definiste los siguientes perímetros:

# 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 habilitar el intercambio de datos, Org1 debe definir la siguiente regla de salida que permite la suscripción y guardar el archivo como 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 debe definir una regla de entrada correspondiente que permita la suscripción y guardar el archivo como 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

Ejecuta los siguientes comandos para aplicar las reglas de entrada y salida:

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

Comparte datos anonimizados de PHI con una organización del socio

En el siguiente diagrama, se muestra un perímetro alrededor de un segmento de datos de Información de salud protegida (PHI), un segundo perímetro alrededor de un segmento de datos anonimizados y una organización del socio independiente. El segmento de PHI puede manipular los datos en el segmento de datos anonimizados, y los datos del segmento de datos anonimizado se comparten con la organización del socio.

Debes definir reglas de entrada y salida que permitan compartir datos anonimizados con la organización del socio y permitir que tu segmento de la PHI manipule los datos en el segmento de datos anonimizado.

Supongamos que definiste los siguientes perímetros:

# 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

También puedes suponer que el proyecto de la organización del socio es 999. Puedes definir las siguientes reglas de entrada y salida:

# 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

Ejecuta los siguientes comandos para aplicar las reglas de entrada y salida:

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

Otorga acceso a una imagen de disco de Compute Engine de terceros

En el siguiente diagrama, se muestra un recurso de Compute Engine en un perímetro de servicio que requiere acceso a una imagen de disco de Compute Engine en un proyecto de imagen de terceros que está fuera del perímetro:

Supongamos que definiste el siguiente perímetro:

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

Ahora debes otorgar acceso de lectura a las imágenes de disco en project 999, que se encuentra en una organización diferente. Luego, debes definir la siguiente regla de salida en un archivo y guardarla como compute.yaml:

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

Ejecuta el siguiente comando para aplicar la regla de salida:

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

Permite un acceso privado desde una red de VPC fuera del perímetro para leer un conjunto de datos de BigQuery

En el siguiente diagrama, se muestran varias redes de VPC de socios fuera del perímetro que deben leer a partir de un recurso de BigQuery dentro de un perímetro:

Puedes suponer que usas el mismo perímetro que en el ejemplo 1:

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

Tu objetivo es permitir el acceso de lectura desde una red de VPC fuera del perímetro de varios socios. Define la siguiente regla de entrada en un archivo y guárdala como 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

Ejecuta el siguiente comando para aplicar la regla de entrada:

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

Para obtener más flexibilidad y control, BigQuery usa - permission: methodSelectors en lugar de - method: methodSelectors, que la mayoría de los servicios usan. Un solo método de BigQuery (RunQuery) puede operar de distintas maneras en varios recursos diferentes, y alinearse con el modelo de permisos proporciona más flexibilidad y control.

Permite el acceso privado desde una red de VPC fuera del perímetro para cargar en un bucket de Cloud Storage (escritura)

Puedes suponer que usas el mismo perímetro que en el ejemplo 1:

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

Tu objetivo es permitir el acceso desde una red de VPC fuera del perímetro para que un socio escriba datos en el bucket dentro del perímetro. Debes definir una regla de entrada y guardar el archivo como 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

Ejecuta el siguiente comando para aplicar la regla de entrada:

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

Permite que los proyectos de varios perímetros compartan registros en un perímetro independiente

En este caso de uso, supongamos que una empresa tiene un proyecto compartido para la recolección de datos de registro de toda su implementación de Google Cloud . La empresa debe poder registrar datos de diferentes perímetros de los Controles del servicio de VPC en el proyecto de registros compartidos, que se encuentra en su propio perímetro. El proyecto de registros no debería acceder a ningún otro recurso que no sean los registros.

Supongamos que definiste estos tres perímetros:

# 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 y Sensitive2 escriban registros en el perímetro de registros, define la siguiente regla de salida en un archivo y guárdalo como 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

Aplica las reglas de salida a través de la ejecución de los siguientes 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

Se puede especificar una configuración similar para cualquier otro perímetro de datos sensibles que deba escribir en el perímetro de registros.

¿Qué sigue?

• Configura las políticas de entrada y salida
• Acceso adaptado al contexto con reglas de entrada
• Reglas de entrada y salida