Intercambio de datos seguro con reglas de entrada y salida

En este documento se describen casos prácticos habituales para el intercambio seguro de datos y ejemplos de configuraciones para 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 el artículo Reglas de entrada y salida.

Para obtener instrucciones sobre cómo configurar políticas de reglas de entrada y salida, consulta el artículo Configurar políticas de entrada y salida.

Ejemplos de configuración de casos prácticos de intercambio de datos seguro

En esta sección se incluyen ejemplos de casos prácticos sobre el intercambio de datos de forma segura entre perímetros de servicio.

Acceder 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:

Salida de un perímetro

Supongamos que ha definido 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 conceder acceso de lectura a un segmento de Cloud Storage en project 999, que está en otra organización. A continuación, define la siguiente regla de salida en un archivo y guarda el archivo 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

Aplica la regla de salida ejecutando el siguiente comando:

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 gcloud access-context-manager perimeters update.

Compartir datos mediante Pub/Sub entre dos organizaciones que usan Controles de Servicio de VPC

En el siguiente diagrama se muestran dos organizaciones, Org1 y Org2, que usan Controles de Servicio de VPC y comparten datos mediante un tema de Pub/Sub:

Salida de un perímetro y entrada a otro

Supongamos que has definido 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 permita 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

Aplica las reglas de entrada y salida ejecutando los siguientes 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

Compartir datos de IPH anonimizados con una organización colaboradora

En el siguiente diagrama se muestra un perímetro alrededor de un segmento de datos de información médica protegida (PHI), un segundo perímetro alrededor de un segmento de datos anonimizado y una organización asociada independiente. El segmento de información personal sensible puede manipular los datos del segmento de datos anonimizados, y los datos de este segmento se comparten con la organización partner.

Entrada y salida del perímetro

Quieres definir reglas de entrada y salida que permitan compartir datos anonimizados con la organización colaboradora y que tu segmento de IPH pueda manipular los datos del segmento de datos anonimizados.

Supongamos que has definido 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 partner 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

Aplica las reglas de entrada y salida ejecutando los siguientes 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

Conceder 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:

Salida al proyecto de imagen

Supongamos que ha definido 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 conceder acceso de lectura a las imágenes de disco en project 999, que está en otra organización. A continuación, define la siguiente regla de salida en un archivo y guárdalo como compute.yaml:

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

Aplica la regla de salida ejecutando el siguiente comando:

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

Leer un conjunto de datos de BigQuery permitiendo el acceso privado desde una red VPC que esté fuera del perímetro

En el siguiente diagrama se muestran varias redes de VPC de partners fuera del perímetro que necesitan leer datos de un recurso de BigQuery dentro de un perímetro:

Salida al proyecto de imagen

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 VPC que esté fuera del perímetro de varios partners. Define la siguiente regla de entrada en un archivo y guárdalo 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

Aplica la regla de entrada ejecutando el siguiente comando:

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

Para ofrecer más flexibilidad y control, BigQuery usa - permission: methodSelectors en lugar de - method: methodSelectors, que es el que usan la mayoría de los servicios. Un solo método de BigQuery (RunQuery) puede funcionar de diferentes formas en varios recursos distintos. Además, alinear los permisos con el modelo se consigue más flexibilidad y control.

Cargar datos en un segmento de Cloud Storage (escritura) permitiendo el acceso privado desde una red VPC fuera del 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:
  - storage.googleapis.com
  - containerregistry.googleapis.com
title: Example

Tu objetivo es permitir el acceso desde una red de VPC que esté fuera del perímetro para que un partner pueda escribir datos en el bucket que se encuentra dentro del perímetro. Define una regla de entrada y guarda 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

Aplica la regla de entrada ejecutando el siguiente comando:

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

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

En este caso práctico, supongamos que una empresa tiene un proyecto compartido para recoger datos de registro de toda su implementación. Google Cloud La empresa debe poder registrar datos de varios perímetros de Controles de Servicio de VPC diferentes en el proyecto de registros compartidos, que está en su propio perímetro. El proyecto de registros no debe acceder a ningún recurso que no sean los registros.

Supongamos que ha definido los tres perímetros siguientes:

# 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 ejecutando 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 necesite escribir en el perímetro de los registros.

Siguientes pasos