Configurar un perímetro de controles del servicio de VPC para una red de nube privada virtual

Consulta cómo configurar un perímetro de servicio con Controles de Servicio de VPC. En este tutorial se usan ajustes de red, como cortafuegos, Private Service Connect y configuraciones de DNS, que son necesarios para usar un perímetro de Controles de Servicio de VPC de forma eficaz. En este tutorial se muestra cómo se permiten o se deniegan los servicios y cómo se pueden crear excepciones detalladas para una lista de servicios permitidos específicos.

Objetivos

  • Configura un perímetro de Controles de Servicio de VPC con controles de red adicionales para mitigar las vías de filtración externa.
  • Permitir o denegar el acceso a los servicios dentro del perímetro a las solicitudes que procedan de dentro o de fuera del perímetro.
  • Permitir o denegar el acceso a servicios fuera del perímetro desde solicitudes que se originan dentro del perímetro.
  • Usa conjuntamente la política de organización Restrict Resource Service Usage y Controles de Servicio de VPC.

Costes

En este tutorial se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Cuando termines este tutorial, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

  1. Para hacer este tutorial, necesitas un proyecto de tu organización. Si aún no tienes una Google Cloud organización, consulta cómo crear y gestionar una organización.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  6. Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the organization.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      Ir a IAM

    2. Selecciona la organización.
    3. Haz clic en Conceder acceso.

    4. En el campo Nuevos principales, introduce tu identificador de usuario. Normalmente, se trata de la dirección de correo de una cuenta de Google.

    5. En la lista Selecciona un rol, elige un rol.
    6. Para conceder más roles, haz clic en Añadir otro rol y añade cada rol adicional.
    7. Haz clic en Guardar.

    8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor

      Check for the roles

      1. In the Google Cloud console, go to the IAM page.

        Go to IAM
      2. Select the project.

      3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

      4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

      Grant the roles

      1. In the Google Cloud console, go to the IAM page.

        Ir a IAM

      2. Selecciona el proyecto.
      3. Haz clic en Conceder acceso.

      4. En el campo Nuevos principales, introduce tu identificador de usuario. Normalmente, se trata de la dirección de correo de una cuenta de Google.

      5. En la lista Selecciona un rol, elige un rol.
      6. Para conceder más roles, haz clic en Añadir otro rol y añade cada rol adicional.
      7. Haz clic en Guardar.

        8. Configurar el perímetro de Controles de Servicio de VPC

        Para implementar un perímetro de Controles de Servicio de VPC en una red de VPC, debes implementar controles de red que denieguen el tráfico a servicios externos. En las secciones siguientes se detallan las configuraciones de red que debe implementar en las redes VPC de su perímetro, así como un ejemplo de configuración de perímetro.

        Preparar tu red de VPC

        En esta sección, configurarás la conectividad privada con las APIs y los servicios de Google de tu red de VPC para mitigar una serie de rutas de salida de la red a Internet.

        1. En Cloud Shell, define las variables:

          gcloud config set project PROJECT_ID
gcloud config set compute/region REGION
gcloud config set compute/zone ZONE

          Haz los cambios siguientes:

          • PROJECT_ID: el ID del proyecto en el que crearás recursos.
          • REGION: una región cercana a tu ubicación (por ejemplo, us-central1).
          • ZONE: una zona cercana a tu ubicación; por ejemplo, us-central1-a

        2. Crea una red VPC y una subred con la función Acceso privado de Google habilitada:

          gcloud compute networks create restricted-vpc --subnet-mode=custom
gcloud compute networks subnets create restricted-subnet \
--range=10.0.0.0/24 \
--network=restricted-vpc \
--enable-private-ip-google-access

        3. Crea un endpoint de Private Service Connect y una regla de reenvío configurada para usar el paquete vpc-sc:

          gcloud compute addresses create restricted-psc-endpoint \
--global \
--purpose=PRIVATE_SERVICE_CONNECT \
--addresses=10.0.1.1 \
--network=restricted-vpc

gcloud compute forwarding-rules create restrictedpsc \
--global \
--network=restricted-vpc \
--address=restricted-psc-endpoint \
--target-google-apis-bundle=vpc-sc

        4. Configura la política de servidor de Cloud DNS para redirigir las consultas de las APIs de Google Cloud a tu endpoint de Private Service Connect:

          gcloud dns managed-zones create restricted-dns-zone \
  --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \
  --dns-name="googleapis.com." \
  --networks=restricted-vpc \
  --visibility=private

gcloud dns record-sets create googleapis.com  \
--rrdatas=10.0.1.1 \
--type=A \
--ttl=300 \
--zone=restricted-dns-zone

gcloud dns record-sets create *.googleapis.com  \
--rrdatas="googleapis.com." \
--type=CNAME \
--ttl=300 \
--zone=restricted-dns-zone

        5. Configura una regla de cortafuegos con una prioridad baja para denegar todo el tráfico de salida:

          gcloud compute firewall-rules create deny-all-egress \
--priority=65534 \
--direction=egress \
--network=restricted-vpc \
--action=DENY \
--rules=all \
--destination-ranges=0.0.0.0/0

        6. Configura una regla de cortafuegos con una prioridad más alta para permitir que el tráfico llegue a la dirección IP que usa tu punto final de Private Service Connect:

          gcloud compute firewall-rules create allow-psc-for-google-apis \
--priority=1000 \
--direction=egress \
--network=restricted-vpc \
--action=ALLOW \
--rules=tcp:443 \
--destination-ranges=10.0.1.1

          Estas reglas de cortafuegos deniegan la salida de forma generalizada antes de permitirla de forma selectiva al endpoint de Private Service Connect. Esta configuración deniega el tráfico de salida a los dominios predeterminados, a los que normalmente se puede acceder de forma predeterminada con el acceso privado de Google y las reglas de cortafuegos implícitas.

        Crear un perímetro de Controles de Servicio de VPC

        En esta sección, crearás un perímetro de Controles de Servicio de VPC.

        1. En Cloud Shell, crea una política de acceso como requisito previo para crear un perímetro de Controles de Servicio de VPC:

          gcloud access-context-manager policies create \
--organization=ORGANIZATION_ID --title "Access policy at organization node"

          El resultado debería ser similar al siguiente:

          "Create request issued
Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."

          Solo puede haber un contenedor de políticas de acceso en el nodo de la organización. Si ya se ha creado una política en tu organización, el resultado será similar al siguiente:

          "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"

          Si ves este mensaje, ve al paso siguiente.

        2. Crea un perímetro de Controles de Servicio de VPC que restrinja los servicios de Cloud Storage y Compute Engine.

          export POLICY_ID=$(gcloud access-context-manager policies list \
--organization=ORGANIZATION_ID \
--format="value(name)")

gcloud access-context-manager perimeters create demo_perimeter \
--title="demo_perimeter" \
--resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \
--restricted-services="storage.googleapis.com,compute.googleapis.com" \
--enable-vpc-accessible-services \
--policy=$POLICY_ID \
--vpc-allowed-services="RESTRICTED-SERVICES"

        Verificar los servicios permitidos del tráfico que no procede de tu perímetro

        En las siguientes secciones se muestra cómo el perímetro de Controles de Servicio de VPC permite o deniega el acceso a las solicitudes realizadas desde fuera del perímetro y cómo puede permitir selectivamente el acceso a los servicios configurando niveles de acceso y políticas de acceso.

        Para simular el tráfico desde fuera de tu perímetro, puedes ejecutar comandos en Cloud Shell. Cloud Shell es un recurso que está fuera de tu proyecto y perímetro. El perímetro permite o deniega las solicitudes aunque tengan suficientes privilegios de Gestión de Identidades y Accesos para completarse.

        En este tutorial se usan las APIs Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos se aplican a otros servicios.

        Verificar que el perímetro deniega el tráfico externo a los servicios restringidos

        En esta sección, comprobarás que el perímetro deniega el tráfico externo a los servicios restringidos.

        Diagrama de arquitectura que muestra cómo un perímetro de Controles de Servicio de VPC deniega el acceso a servicios restringidos

        El diagrama anterior muestra cómo se deniega el acceso de un cliente autorizado a los servicios que se encuentran dentro del perímetro que has configurado como restringido, pero se le permite acceder a los servicios que no has configurado como restringidos.

        En los pasos siguientes, verificarás este concepto usando Cloud Shell para intentar crear una VM en tu red de VPC, lo que no será posible debido a la configuración del perímetro de Controles de Servicio de VPC.

        1. En Cloud Shell, ejecuta el siguiente comando para crear una VM en tu red de VPC.

          gcloud compute instances create demo-vm \
    --machine-type=e2-micro \
    --subnet=restricted-subnet \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --no-address

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.compute.instances.create) Could not fetch resource:
- Request is prohibited by organization's policy."

          La solicitud falla porque Cloud Shell está fuera de tu perímetro y Compute Engine está configurado con la marca --restricted-services.

        2. En Cloud Shell, ejecuta el siguiente comando para acceder al servicio Resource Manager, que no está configurado en la marca --restricted-services.

          gcloud projects describe PROJECT_ID

          Si la solicitud se hace correctamente, se devuelven los detalles del proyecto. Esta respuesta demuestra que tu perímetro permite el tráfico externo a la API Cloud Resource Manager.

          Has demostrado que el perímetro deniega el tráfico externo a los servicios configurados en --restricted-services y permite el tráfico externo a los servicios que no están configurados explícitamente en --restricted-services.

        En las siguientes secciones se presentan patrones de excepciones para acceder a servicios restringidos dentro del perímetro.

        Verificar que un nivel de acceso permite una excepción al perímetro

        En esta sección, se verifica que un nivel de acceso permite una excepción al perímetro. Los niveles de acceso son útiles cuando quieres crear una excepción para que el tráfico externo pueda acceder a todos los servicios restringidos dentro del perímetro y no necesitas excepciones específicas para cada servicio u otros atributos.

        Diagrama de arquitectura que muestra cómo un nivel de acceso concede una excepción a todos los servicios dentro del perímetro de Controles de Servicio de VPC

        En el diagrama anterior se muestra cómo un nivel de acceso permite que un cliente autorizado acceda a todos los servicios restringidos dentro del perímetro.

        En los pasos siguientes, verificará este concepto creando un nivel de acceso y, a continuación, haciendo una solicitud correcta al servicio Compute Engine. Esta solicitud se permite aunque hayas configurado Compute Engine como restringido.

        1. En Cloud Shell, crea un archivo YAML que describa la configuración de un nivel de acceso y aplícalo a tu perímetro. En este ejemplo se crea un nivel de acceso para la identidad de usuario que estás usando para completar el tutorial.

          export USERNAME=$(gcloud config list account --format "value(core.account)")

cat <<EOF > user_spec.yaml
- members:
  - user:$USERNAME
EOF

          gcloud access-context-manager levels create single_user_level \
--title="single-user access level" \
--basic-level-spec=user_spec.yaml \
--policy=$POLICY_ID

gcloud access-context-manager perimeters update demo_perimeter \
--add-access-levels=single_user_level \
--policy=$POLICY_ID

        2. En Cloud Shell, vuelve a ejecutar el siguiente comando para intentar crear una VM:

          gcloud compute instances create demo-vm \
--machine-type=e2-micro \
--subnet=restricted-subnet \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--no-address

          Esta vez, la solicitud funciona. Tu perímetro impide que el tráfico externo use los servicios restringidos, pero el nivel de acceso que has configurado permite una excepción.

        Verificar que una política de entrada permite una excepción granular al perímetro

        En esta sección, verificará que una política de entrada permite una excepción granular al perímetro. En comparación con el nivel de acceso general, una política de entrada detallada puede configurar atributos adicionales sobre la fuente del tráfico y permitir el acceso a servicios o métodos concretos.

        Diagrama de arquitectura que muestra cómo una política de entrada permite que una excepción granular llegue a servicios específicos dentro del perímetro

        El diagrama anterior muestra cómo una política de entrada permite que un cliente autorizado acceda solo a un servicio específico dentro del perímetro, sin permitir el acceso a otros servicios restringidos.

        En los pasos siguientes, verificará este concepto sustituyendo el nivel de acceso por una política de entrada que permita a un cliente autorizado acceder solo al servicio Compute Engine, pero no a otros servicios restringidos.

        1. En la pestaña Cloud Shell, ejecuta el siguiente comando para eliminar el nivel de acceso.

          gcloud access-context-manager perimeters update demo_perimeter \
--policy=$POLICY_ID \
--clear-access-levels

        2. En la pestaña Cloud Shell, crea una política de entrada que permita a tu identidad de usuario acceder solo al servicio Compute Engine y aplica la política a tu perímetro.

          cat <<EOF > ingress_spec.yaml
- ingressFrom:
    identities:
    - user:$USERNAME
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - methodSelectors:
      - method: '*'
      serviceName: compute.googleapis.com
    resources:
    - '*'
EOF

          gcloud access-context-manager perimeters update demo_perimeter \
--set-ingress-policies=ingress_spec.yaml \
--policy=$POLICY_ID

        3. En la pestaña Cloud Shell, ejecuta el siguiente comando para crear un segmento de Cloud Storage dentro del perímetro.

          gcloud storage buckets create gs://PROJECT_ID-01

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."

          Cloud Shell es un cliente que está fuera del perímetro, por lo que el perímetro de Controles de Servicio de VPC impide que Cloud Shell se comunique con los servicios restringidos que están dentro del perímetro.

        4. En la pestaña Cloud Shell, ejecuta el siguiente comando para enviar una solicitud al servicio Compute Engine dentro del perímetro.

          gcloud compute instances describe demo-vm --zone=ZONE

          Si la solicitud se realiza correctamente, se devuelven los detalles de demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico externo que cumple las condiciones de tu política de entrada al servicio Compute Engine.

        Verificar los servicios permitidos del tráfico dentro de tu perímetro

        En las siguientes secciones se muestra cómo el perímetro de Controles de Servicio de VPC permite o deniega las solicitudes a los servicios desde dentro del perímetro y cómo puede permitir selectivamente el tráfico saliente a servicios externos mediante políticas de salida.

        Para mostrar la diferencia entre el tráfico que se encuentra dentro y fuera del perímetro, en las siguientes secciones se usa Cloud Shell fuera del perímetro y una instancia de Compute Engine que se crea dentro del perímetro. Los comandos que ejecutas desde la sesión SSH en la instancia de Compute Engine dentro del perímetro usan la identidad de la cuenta de servicio adjunta, mientras que los comandos que se ejecutan desde Cloud Shell fuera del perímetro usan tu propia identidad. Si sigues la configuración recomendada del tutorial, el perímetro permite o deniega las solicitudes aunque tengan suficientes privilegios de gestión de identidades y accesos para completarse.

        En este tutorial se usan las APIs Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos se aplican a otros servicios.

        Verificar que el perímetro permite el tráfico interno a los servicios restringidos dentro del perímetro

        En esta sección, se verifica que el perímetro permite el tráfico de los endpoints de red que se encuentran dentro de él si el servicio también está configurado en Servicios accesibles de VPC.

        Diagrama de arquitectura que muestra cómo la configuración de vpc-accessible-services permite acceder a los servicios desde los endpoints de tu red interna

        En el diagrama anterior se muestra cómo un perímetro permite que el tráfico de los endpoints de red que están dentro del perímetro llegue a los servicios restringidos que también has configurado como servicios accesibles a la VPC. No se puede acceder a los servicios que no hayas configurado como servicios accesibles a través de VPC desde los endpoints de red que se encuentren dentro del perímetro.

        En los siguientes pasos, verificará este concepto estableciendo una conexión SSH con la instancia de Compute Engine dentro del perímetro y, a continuación, haciendo solicitudes a los servicios.

        1. En Cloud Shell, crea una regla de cortafuegos que permita el tráfico SSH a tu red de VPC. Para ello, permite la entrada desde el intervalo de direcciones IP 35.235.240.0/20 que usa el servicio IAP para el reenvío de TCP:

          gcloud compute firewall-rules create demo-allow-ssh \
--direction=INGRESS \
--priority=1000 \
--network=restricted-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20

        2. Inicia una sesión SSH en esta instancia:

          gcloud compute ssh demo-vm --zone=ZONE

          Verifica que te has conectado correctamente a la instancia demo-vm comprobando que la petición de línea de comandos ha cambiado para mostrar el nombre de host de tu instancia:

          username@demo-vm:~$

          Si el comando anterior falla, puede que veas un mensaje de error similar al siguiente:

          "[/usr/bin/ssh] exited with return code [255]"

          En este caso, es posible que la instancia de Compute Engine no haya completado el proceso de arranque. Espera un minuto y vuelve a intentarlo.

        3. Desde la sesión SSH dentro de tu perímetro, verifica los servicios que permite tu perímetro internamente mediante un Google Cloud servicio que esté configurado en la lista de permitidos de servicios accesibles de la VPC. Por ejemplo, prueba cualquier comando con el servicio Compute Engine.

          gcloud compute instances describe demo-vm --zone=ZONE

          Si la solicitud se realiza correctamente, se devuelven los detalles de demo-vm. Esta respuesta demuestra que tu perímetro permite que el tráfico interno acceda a la API de Compute Engine.

        4. Desde la sesión SSH dentro de tu perímetro, comprueba que los servicios que no se incluyan en la lista de permitidos de servicios accesibles de la VPC no estén permitidos desde tu VM. Por ejemplo, el siguiente comando usa el servicio Resource Manager, que no está configurado en la lista de permitidos de servicios accesibles de la VPC.

          gcloud projects describe PROJECT_ID

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."

          Tu instancia de Compute Engine y otros endpoints de red solo pueden solicitar servicios que estén configurados en la lista de permitidos de servicios accesibles de la VPC. Sin embargo, los recursos sin servidor o el tráfico de servicios que procedan de fuera de tu perímetro pueden solicitar ese servicio. Si quieres evitar que se use un servicio en tu proyecto, consulta la política Uso de recursos de servicios restringidos.

        Verificar que el perímetro deniega el tráfico interno a los servicios restringidos que están fuera del perímetro

        En esta sección, verificará que el perímetro bloquea la comunicación de los servicios que están dentro del perímetro con los servicios que están fuera del perímetro. Google Cloud

        Diagrama de arquitectura que muestra cómo un perímetro de Controles de Servicio de VPC deniega el acceso desde el tráfico que está dentro del perímetro a los servicios restringidos que están fuera del perímetro

        En el diagrama anterior se muestra cómo el tráfico interno no puede comunicarse con servicios restringidos fuera del perímetro.

        En los pasos siguientes, verificará este concepto intentando enviar tráfico interno a un servicio restringido dentro del perímetro y a un servicio restringido fuera del perímetro.

        1. En la sesión SSH de tu perímetro, ejecuta el siguiente comando para crear un bucket de almacenamiento en tu perímetro. Este comando funciona porque el servicio Cloud Storage está configurado tanto en restricted-services como en accessible-services.

          gcloud storage buckets create gs://PROJECT_ID-02

          Si la respuesta es correcta, se creará el segmento de almacenamiento. Esta respuesta demuestra que tu perímetro permite que el tráfico interno llegue al servicio Cloud Storage.

        2. Desde la sesión SSH dentro de tu perímetro, ejecuta el siguiente comando para leer datos de un bucket que está fuera de tu perímetro. Este segmento público permite el acceso de solo lectura a allUsers, pero el perímetro deniega el tráfico desde dentro del perímetro a un servicio restringido fuera del perímetro.

          gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited
by organization's policy."

          Esta respuesta demuestra que puedes usar servicios restringidos dentro del perímetro, pero un recurso dentro del perímetro no puede comunicarse con servicios restringidos fuera del perímetro.

        Verificar que una política de salida permite una excepción al perímetro

        En esta sección, verificas que una política de salida permite una excepción al perímetro.

        Diagrama de arquitectura que muestra cómo una política de salida permite que excepciones específicas accedan a un servicio restringido fuera del perímetro

        El diagrama anterior muestra cómo puede comunicarse el tráfico interno con un recurso externo específico cuando se concede una excepción limitada con la política de salida.

        En los pasos siguientes, verificará este concepto creando una política de salida y, a continuación, accediendo a un segmento de Cloud Storage público fuera del perímetro permitido por la política de salida.

        1. Abre una nueva sesión de Cloud Shell haciendo clic en abrir una pestaña nueva en Cloud Shell. En los pasos siguientes, cambiarás entre la primera pestaña con la sesión SSH dentro de tu perímetro y la segunda pestaña en Cloud Shell fuera de tu perímetro, donde el prompt de la línea de comandos empieza por username@cloudshell.

        2. En la pestaña Cloud Shell, crea una política de salida que permita la salida de la identidad de la cuenta de servicio adjunta de demo-vm mediante el método google.storage.objects.get a un segmento público de un proyecto externo. Actualiza el perímetro con la política de salida.

          export POLICY_ID=$(gcloud access-context-manager policies list \
--organization=ORGANIZATION_ID \
--format="value(name)")

export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \
--zone=ZONE) \
--format="value(serviceAccounts.email)"
           
          cat <<EOF > egress_spec.yaml
- egressFrom:
    identities:
      - serviceAccount:$SERVICE_ACCOUNT_EMAIL
  egressTo:
    operations:
    - methodSelectors:
      - method: 'google.storage.objects.get'
      serviceName: storage.googleapis.com
    resources:
    - projects/950403849117
EOF

          gcloud access-context-manager perimeters update demo_perimeter \
--set-egress-policies=egress_spec.yaml \
--policy=$POLICY_ID

        3. Vuelve a la pestaña con la sesión SSH de la VM que está dentro de tu perímetro, donde el prompt de la línea de comandos empieza por username@demo-vm.

        4. Desde la sesión SSH dentro de tu perímetro, haz otra solicitud al segmento de Cloud Storage y comprueba que funciona.

          gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

          El resultado debería ser similar al siguiente:

          "Hello world!
This is a sample file in Cloud Storage that is viewable to allUsers."

          Esta respuesta demuestra que tu política de perímetro y de salida permite el tráfico interno de una identidad específica a un segmento de Cloud Storage específico.

        5. Desde la sesión SSH dentro de tu perímetro, también puedes probar otros métodos que no se hayan permitido explícitamente en la excepción de la política de salida. Por ejemplo, el siguiente comando requiere el permiso google.storage.buckets.list que tu perímetro deniega.

          gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."

          Esta respuesta demuestra que tu perímetro deniega el tráfico interno para enumerar objetos en el segmento externo, lo que indica que la política de salida permite solo los métodos especificados explícitamente.

        Para obtener más información sobre los patrones habituales para compartir datos fuera de tu perímetro de servicio, consulta el artículo sobre el intercambio de datos seguro con reglas de entrada y salida.

        (Opcional) Configurar la política de uso de recursos de servicio restringido

        También puede que tengas requisitos internos o de cumplimiento que permitan usar solo las APIs aprobadas individualmente en tu entorno. En este caso, también puedes configurar el servicio de política de la organización Restricted Service Resource Usage (Uso de recursos de servicios restringidos). Al aplicar la política de la organización en un proyecto, puedes restringir los servicios que se pueden crear en ese proyecto. Sin embargo, la política de organización no impide que los servicios de este proyecto se comuniquen con los servicios de otros proyectos. En cambio, Controles de Servicio de VPC te permite definir un perímetro para evitar la comunicación con servicios que estén fuera de él.

        Por ejemplo, si defines una política de organización para permitir Compute Engine y denegar Cloud Storage en tu proyecto, una máquina virtual de este proyecto no podrá crear un segmento de Cloud Storage en tu proyecto. Sin embargo, la VM puede enviar solicitudes a un segmento de Cloud Storage de otro proyecto, por lo que sigue siendo posible la exfiltración con el servicio Cloud Storage. En los siguientes pasos se muestra cómo implementar y probar este caso:

        1. Cambia a la pestaña Cloud Shell, donde el prompt de la línea de comandos empieza por username@cloudshell.

        2. En la pestaña Cloud Shell, crea un archivo YAML que describa el servicio de políticas de la organización que solo permita el uso del servicio Compute Engine y deniegue todos los demás servicios. A continuación, aplícalo a tu proyecto.

          cat <<EOF > allowed_services_policy.yaml
constraint: constraints/gcp.restrictServiceUsage
listPolicy:
  allowedValues:
  - compute.googleapis.com
  inheritFromParent: true
EOF

          gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \
--project=PROJECT_ID

        3. Vuelve a la pestaña con la sesión SSH de la VM que está dentro de tu perímetro, donde el prompt de la línea de comandos empieza por username@demo-vm.

        4. En la sesión SSH de tu perímetro, ejecuta el siguiente comando para ver el mismo contenedor de almacenamiento que creaste anteriormente en este proyecto.

          gcloud storage buckets describe gs://PROJECT_ID

          El resultado debería ser similar al siguiente:

          "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."

          Esta respuesta demuestra que el servicio de políticas de la organización deniega el servicio de Cloud Storage en tu proyecto, independientemente de la configuración de tu perímetro.

        5. En la sesión SSH de tu perímetro, ejecuta el siguiente comando para ver un bucket de almacenamiento fuera del perímetro que permita tu política de salida.

          gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt

          El resultado debería ser similar al siguiente:

          "Hello world!
This is a sample file in Cloud Storage that is viewable to allUsers."

          Si la respuesta es correcta, se devuelve el contenido de helloworld.txt en el segmento de almacenamiento externo. Esta respuesta demuestra que tu política de perímetro y de salida permite que el tráfico interno llegue a un segmento de almacenamiento externo en determinadas condiciones limitadas, pero el servicio de políticas de organización deniega el servicio de Cloud Storage en tu proyecto, independientemente de la configuración de tu perímetro. Es posible que se sigan usando servicios ajenos a tu proyecto para la exfiltración si tu perímetro lo permite, independientemente del servicio de política de organización de uso de recursos de servicios restringidos.

          Para denegar la comunicación con Cloud Storage u otros servicios de Google fuera del perímetro, no basta con el servicio de políticas de organización Restricted Service Resource Usage (Uso de recursos de servicio restringido), sino que debes configurar un perímetro de Controles de Servicio de VPC. Controles de Servicio de VPC mitiga las vías de filtración externa de datos y Uso de recursos de servicio restringido es un control de cumplimiento para evitar que se creen servicios no aprobados en tu entorno. Usa estos controles conjuntamente para bloquear una serie de rutas de exfiltración y permitir de forma selectiva los servicios aprobados para uso interno en tu entorno.

        Limpieza

      8. In the Google Cloud console, go to the Manage resources page.

        Go to Manage resources

      9. In the project list, select the project that you want to delete, and then click Delete.
      10. In the dialog, type the project ID, and then click Shut down to delete the project.

        11. Aunque el perímetro de Controles de Servicio de VPC no genera ningún coste adicional, se debe limpiar para evitar que haya recursos innecesarios en tu organización.

        1. En el selector de proyectos de la parte superior de la Google Cloud consola, selecciona la organización que has usado en este tutorial.

        2. En la Google Cloud consola, ve a la página VPC Service Controls.

          Ir a Controles de Servicio de VPC

        3. En la lista de perímetros, selecciona el que quieras eliminar y haz clic en Eliminar.

        4. En el cuadro de diálogo, vuelve a hacer clic en Eliminar para confirmar la acción.

        Siguientes pasos