Aprende a configurar un perímetro de servicio con los Controles del servicio de VPC. En este instructivo, se usa la configuración de red, como firewalls, Private Service Connect y las configuraciones de DNS necesarias para usar un perímetro de los Controles del servicio de VPC de manera efectiva. Luego, se muestra cómo se permiten o rechazan los servicios, y cómo realizar excepciones detalladas en una lista de entidades permitidas de servicios específicos.
Objetivos
- Configura un perímetro de Controles del servicio de VPC con controles de red adicionales para mitigar las rutas de robo de datos.
- Permite o deniega el acceso a los servicios dentro del perímetro desde las solicitudes que se originan dentro o fuera del perímetro.
- Permite o rechaza el acceso a los servicios fuera del perímetro de las solicitudes que se originan en el perímetro.
- Usa la política de la organización Restrict Resource Service Usage y los Controles del servicio de VPC juntos.
Costos
En este instructivo, se usan los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Cuando finalices este instructivo, puedes borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta Cómo realizar una limpieza.
Antes de comenzar
Este instructivo requiere un proyecto en tu organización. Si aún no tienes una organización de Google Cloud, consulta Crea y administra una organización.
-
En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
Habilita las API de Compute Engine, Access Context Manager y Cloud DNS .
-
En la consola de Google Cloud, activa Cloud Shell.
Asegúrate de tener los siguientes roles en la organización: Access Context Manager Admin, Organization Policy Administrator
Verifica los roles
-
En la consola de Google Cloud, ve a la página IAM.
Ir a IAM - Selecciona la organización.
-
En la columna Principal, busca la fila que tiene tu dirección de correo electrónico.
Si tu dirección de correo electrónico no está en esa columna, no tienes ningún rol.
- En la columna Función de la fila con la dirección de correo electrónico, verifica si la lista de roles incluye los roles necesarios.
Otorga los roles
-
En la consola de Google Cloud, ve a la página IAM.
Ir a IAM - Selecciona la organización.
- Haz clic en Grant access.
- En el campo Principales nuevas, ingresa tu dirección de correo electrónico.
- En la lista Seleccionar un rol, elige un rol.
- Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
- Haz clic en Guardar.
-
Asegúrate de tener los siguientes roles en el proyecto: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor
Verifica los roles
-
En la consola de Google Cloud, ve a la página IAM.
Ir a IAM - Selecciona el proyecto.
-
En la columna Principal, busca la fila que tiene tu dirección de correo electrónico.
Si tu dirección de correo electrónico no está en esa columna, no tienes ningún rol.
- En la columna Función de la fila con la dirección de correo electrónico, verifica si la lista de roles incluye los roles necesarios.
Otorga los roles
-
En la consola de Google Cloud, ve a la página IAM.
Ir a IAM - Selecciona el proyecto.
- Haz clic en Grant access.
- En el campo Principales nuevas, ingresa tu dirección de correo electrónico.
- En la lista Seleccionar un rol, elige un rol.
- Para otorgar funciones adicionales, haz clic en Agregar otro rol y agrega cada rol adicional.
- Haz clic en Guardar.
-
Configura el perímetro de los Controles del servicio de VPC
A fin de implementar un perímetro de los Controles del servicio de VPC para una red de VPC, debes implementar controles de red que rechacen el tráfico a servicios externos. En las siguientes secciones, se detalla la configuración de red que debes implementar en las redes de VPC dentro de tu perímetro y una configuración de perímetro de ejemplo.
Prepara la red de VPC
En esta sección, configurarás la conectividad privada a los servicios y las API de Google para tu red de VPC a fin de mitigar un rango de rutas de salida de red a Internet.
En Cloud Shell, establezca las variables:
gcloud config set project PROJECT_ID gcloud config set compute/region REGION gcloud config set compute/zone ZONE
Reemplaza lo siguiente:
- PROJECT_ID: Es el ID del proyecto en el que crearás los recursos.
- REGION: Es una región cercana a tu ubicación, por ejemplo,
us-central1. - ZONE: Una zona que está cerca de tu ubicación, por ejemplo,
us-central1-a
Crea una red de VPC y una subred con el Acceso privado a Google habilitado:
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
Crea un extremo 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
Configura la política del servidor de Cloud DNS para redireccionar las consultas de las API de Google Cloud a tu extremo 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
Configura una regla de firewall con una prioridad baja para rechazar 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
Configura una regla de firewall con una prioridad más alta para permitir que el tráfico alcance la dirección IP que usa el extremo 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 firewall rechazan la salida de manera amplia antes de permitir la salida al extremo de Private Service Connect de manera selectiva. 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 a Google y las reglas de firewall implícitas.
Crea un perímetro de Controles del servicio de VPC
En esta sección, creará un perímetro de Controles del servicio de VPC.
En Cloud Shell, crea una política de acceso como requisito previo para crear un perímetro de Controles del servicio de VPC:
gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title "Access policy at organization node"
El resultado es similar a este:
"Create request issued Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."Solo puede haber un contenedor de la política de acceso en el nodo de la organización. Si ya se creó una política en tu organización, el resultado es similar al siguiente:
"ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"Si ves este mensaje, continúa con el siguiente paso.
Crear un perímetro de Controles del 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"
Verifica los servicios permitidos del tráfico fuera del perímetro
En las siguientes secciones, se muestra cómo el perímetro de los Controles del servicio de VPC permite o niega el acceso a las solicitudes realizadas fuera del perímetro y cómo puedes permitir la entrada de forma selectiva de servicios mediante la configuración de niveles de acceso y políticas de entrada.
Para simular tráfico desde fuera de tu perímetro, puedes ejecutar comandos en Cloud Shell. Cloud Shell es un recurso fuera de tu propio proyecto y perímetro. El perímetro permite o rechaza las solicitudes, a pesar de que tengan suficientes privilegios de Identity and Access Management para ejecutarse correctamente.
En este instructivo, se usa la API de Compute Engine, la API de Cloud Storage y la API de Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
Verifica que el perímetro rechace el tráfico externo para los servicios restringidos
En esta sección, verificarás que el perímetro rechace el tráfico externo a los servicios restringidos.
En el diagrama anterior, se ilustra cómo se niega a un cliente autorizado el acceso a los servicios dentro del perímetro que configuraste como restringido, pero el cliente tiene permiso para acceder a los servicios que no configuraste como restringidos.
En los siguientes pasos, verificarás este concepto con Cloud Shell para intentar crear una VM dentro de tu red de VPC, que falla debido a la configuración del perímetro de los Controles del servicio de VPC.
En Cloud Shell, ejecuta el siguiente comando para crear una VM dentro de la 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-addressEl resultado es similar a este:
"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 se configura con la marca
--restricted-services.En Cloud Shell, ejecuta el siguiente comando para acceder al servicio de Resource Manager, que no está configurado en la marca
--restricted-services.gcloud projects describe PROJECT_ID
Una respuesta correcta muestra los detalles de tu proyecto. En esta respuesta, se muestra que tu perímetro permite el tráfico externo a la API de Resource Manager.
Demostraste que el perímetro rechaza el tráfico externo a los servicios configurados en
--restricted-servicesy permite el tráfico externo a los servicios no configurados de forma explícita en--restricted-services.
En las siguientes secciones, se presentan patrones de excepciones para llegar a servicios restringidos dentro del perímetro.
Verifica que un nivel de acceso permita una excepción al perímetro
En esta sección, verificarás que un nivel de acceso permita una excepción al perímetro. Un nivel de acceso es útil cuando quieres crear una excepción para que el tráfico externo acceda a todos los servicios restringidos dentro del perímetro y no necesites excepciones detalladas para cada servicio ni para otros atributos.
En el diagrama anterior, se ilustra cómo un nivel de acceso permite que un cliente autorizado acceda a todos los servicios restringidos dentro del perímetro.
En los siguientes pasos, para verificar este concepto, debes crear un nivel de acceso y, luego, realizar una solicitud correcta al servicio de Compute Engine. Esta solicitud está permitida incluso si configuraste Compute Engine como restringido.
Desde Cloud Shell, crea un archivo YAML que describa la configuración de un nivel de acceso y aplícalo a tu perímetro. En esta muestra, se crea un nivel de acceso para la identidad del usuario que usas actualmente a fin de ejecutar el instructivo.
export USERNAME=$(gcloud config list account --format "value(core.account)") cat <<EOF > user_spec.yaml - members: - user:$USERNAME EOFgcloud 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
Desde 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. El perímetro evita que el tráfico externo use los servicios restringidos, pero el nivel de acceso que configuraste permite una excepción.
Verifica que una política de entrada permita una excepción detallada al perímetro
En esta sección, verificarás que una política de entrada permita una excepción detallada 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 de tráfico y permitir el acceso a servicios o métodos individuales.
En el diagrama anterior, se ilustra cómo una política de entrada permite que un cliente autorizado acceda solo a un servicio especificado dentro del perímetro, sin permitir el acceso a otros servicios restringidos.
En los siguientes pasos, debes verificar este concepto. Para ello, reemplaza el nivel de acceso por una política de entrada que permita que un cliente autorizado solo acceda al servicio de Compute Engine, pero que no permita el acceso a otros servicios restringidos.
En la pestaña de Cloud Shell, ejecuta el siguiente comando para quitar el nivel de acceso.
gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
En la pestaña de Cloud Shell, crea una política de entrada que permita que tu identidad de usuario ingrese solo al servicio de 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: - '*' EOFgcloud access-context-manager perimeters update demo_perimeter \ --set-ingress-policies=ingress_spec.yaml \ --policy=$POLICY_ID
En la pestaña de Cloud Shell, ejecute el siguiente comando para crear un bucket de Cloud Storage dentro del perímetro.
gcloud storage buckets create gs://PROJECT_ID-01
El resultado es similar a este:
"ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."Cloud Shell es un cliente fuera del perímetro, por lo que el perímetro de los Controles del servicio de VPC impide que Cloud Shell se comunique con los servicios restringidos dentro del perímetro.
En la pestaña de Cloud Shell, ejecuta el siguiente comando para realizar una solicitud al servicio de Compute Engine dentro del perímetro.
gcloud compute instances describe demo-vm --zone=ZONE
Una respuesta correcta muestra los detalles de
demo-vm. En esta respuesta, se muestra que el perímetro permite el tráfico externo que cumple con las condiciones de la política de entrada al servicio de Compute Engine.
Verifica los servicios permitidos del tráfico dentro de tu perímetro
En las siguientes secciones, se muestra cómo el perímetro de los Controles del servicio de VPC permite o rechaza las solicitudes a servicios desde el perímetro, y cómo puedes permitir la salida a servicios externos de forma selectiva mediante políticas de salida.
Para demostrar la diferencia entre el tráfico dentro y fuera del perímetro, en las siguientes secciones, se usan Cloud Shell fuera del perímetro y una instancia de Compute Engine que creas 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 conectada, mientras que los comandos que se ejecutan desde Cloud Shell fuera del perímetro usan tu propia identidad. Cuando se sigue la configuración recomendada para el instructivo, el perímetro permite o rechaza las solicitudes, aunque las solicitudes tengan suficientes privilegios de IAM para tener éxito.
En este instructivo, se usa la API de Compute Engine, la API de Cloud Storage y la API de Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
Verifica que el perímetro permita el tráfico interno a servicios restringidos dentro del perímetro
En esta sección, verificarás que el perímetro permita el tráfico desde los extremos de red dentro de tu perímetro si el servicio también está configurado en servicios accesibles de VPC.
En el diagrama anterior, se ilustra cómo un perímetro permite que el tráfico de los extremos de red dentro del perímetro llegue a los servicios restringidos que también configuraste como servicios accesibles de VPC. No se puede acceder a los servicios que no configuraste como servicios accesibles de VPC desde los extremos de red dentro del perímetro.
En los siguientes pasos, verificarás este concepto estableciendo una conexión SSH a la instancia de Compute Engine dentro del perímetro y, luego, realizando solicitudes a servicios.
En Cloud Shell, crea una regla de firewall que permita el tráfico SSH a tu red de VPC, ya que permite la entrada desde el rango de direcciones IP 35.235.240.0/20 que usa el servicio de IAP para redirección 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
Inicia una sesión SSH para esta instancia:
gcloud compute ssh demo-vm --zone=ZONE
Confirma que te hayas conectado a la instancia
demo-vmcorrectamente. Para ello, confirma que la ventana de la línea de comandos haya cambiado a fin de mostrar el nombre de host de tu instancia:username@demo-vm:~$Si el comando anterior falla, es posible 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 inicio. Espera un minuto y vuelve a intentarlo.
Desde la sesión SSH dentro de tu perímetro, verifica los servicios que tu perímetro permite de forma interna mediante un servicio de Google Cloud configurado en la lista de servicios permitidos de VPC. Por ejemplo, prueba cualquier comando que use el servicio de Compute Engine.
gcloud compute instances describe demo-vm --zone=ZONE
Una respuesta correcta muestra los detalles de
demo-vm. En esta respuesta, se muestra que tu perímetro permite el tráfico interno a la API de Compute Engine.Desde la sesión SSH dentro de tu perímetro, verifica que la VM no permita los servicios que no están incluidos en la lista de servicios accesibles de VPC. Por ejemplo, el siguiente comando usa el servicio de Resource Manager, que no está configurado en la lista de entidades permitidas de los servicios accesibles de VPC.
gcloud projects describe PROJECT_ID
El resultado es similar a este:
"ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."Tu instancia de Compute Engine y otros extremos de red solo pueden solicitar servicios configurados en la lista de entidades permitidas de servicios accesibles de VPC. Sin embargo, los recursos sin servidores o el tráfico de servicios que se originan fuera del perímetro pueden solicitar ese servicio. Si deseas evitar que se use un servicio en tu proyecto, consulta la política de uso de recursos del servicio restringido.
Verifica que el perímetro rechace el tráfico interno para los servicios restringidos fuera del perímetro
En esta sección, verificarás que el perímetro bloquee la comunicación de los servicios dentro del perímetro con los servicios de Google Cloud fuera del perímetro.
En el diagrama anterior, se ilustra cómo el tráfico interno no puede comunicarse con servicios restringidos fuera del perímetro.
En los siguientes pasos, verificarás este concepto si intentas enviar tráfico interno a un servicio restringido dentro del perímetro y a un servicio restringido fuera del perímetro.
Desde la sesión SSH dentro de tu perímetro, ejecuta el siguiente comando para crear un bucket de almacenamiento dentro de tu perímetro. Este comando funciona porque el servicio de Cloud Storage se configura en
restricted-servicesyaccessible-services.gcloud storage buckets create gs://PROJECT_ID-02
Una respuesta correcta crea el bucket de almacenamiento. En esta respuesta, se muestra que tu perímetro permite el tráfico interno al servicio de Cloud Storage.
Desde la sesión SSH dentro de tu perímetro, ejecuta el siguiente comando para leer desde un bucket que esté fuera de tu perímetro. Este bucket público permite el permiso de solo lectura a
allUsers, pero el perímetro rechaza el tráfico desde el perímetro hasta un servicio restringido fuera del perímetro.gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
El resultado es similar a este:
"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.
Verifica que una política de salida permita una excepción al perímetro
En esta sección, verificarás que una política de salida permita una excepción al perímetro.
En el diagrama anterior, se ilustra cómo el tráfico interno puede comunicarse con un recurso externo específico cuando se otorga una excepción limitada con la política de salida.
En los siguientes pasos, para verificar este concepto, debes crear una política de salida y, luego, acceder a un bucket público de Cloud Storage fuera del perímetro que permite la política de salida.
Para abrir una sesión nueva de Cloud Shell, haz clic en Abrir una pestaña nueva en Cloud Shell. En los pasos posteriores, alternas 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, en la que la línea de comandos comienza con
username@cloudshell.En la pestaña de Cloud Shell, crea una política de salida que permita la salida de la identidad de la cuenta de servicio conectada de
demo-vmcon el métodogoogle.storage.objects.geta un bucket público en 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 EOFgcloud access-context-manager perimeters update demo_perimeter \ --set-egress-policies=egress_spec.yaml \ --policy=$POLICY_ID
Regresa a la pestaña que tiene la sesión SSH en la VM dentro del perímetro, en la que la ventana de la línea de comandos comienza con
username@demo-vm.Desde la sesión SSH dentro de tu perímetro, realiza otra solicitud al bucket de Cloud Storage y verifica que funcione.
gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
El resultado es similar a este:
"Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."Esta respuesta demuestra que el perímetro y la política de salida permiten el tráfico interno de una identidad específica a un bucket de Cloud Storage específico.
Desde la sesión SSH dentro de tu perímetro, también puedes probar otros métodos que la excepción a la política de salida no permitió de forma explícita. Por ejemplo, el siguiente comando requiere el permiso
google.storage.buckets.listque el perímetro rechaza.gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
El resultado es similar a este:
"ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."En esta respuesta, se demuestra que el perímetro niega el tráfico interno de la enumeración de objetos en el bucket externo, lo que indica que la política de salida permite métodos específicos especificados de forma específica.
Si deseas obtener más referencias sobre patrones comunes para compartir datos fuera del perímetro de servicio, consulta Intercambio de datos seguro con reglas de entrada y salida.
(Opcional) Configura la política de Uso restringido del recurso de servicio
Es posible que también tengas requisitos internos o requisitos de cumplimiento para permitir que solo se usen API aprobadas de forma individual en tu entorno. En este caso, también puedes configurar el servicio de la política de la organización Uso restringido de recursos del servicio. Cuando aplicas la política de la organización en un proyecto, restringes los servicios que se pueden crear en ese proyecto. Sin embargo, la política de la organización no impide que los servicios de este proyecto se comuniquen con los servicios de otros proyectos. En comparación, los Controles del servicio de VPC te permiten definir un perímetro para evitar la comunicación con servicios fuera del perímetro.
Por ejemplo, si defines una política de la organización para permitir Compute Engine y rechazar Cloud Storage en tu proyecto, una VM en este proyecto no podría crear un bucket de Cloud Storage en tu proyecto. Sin embargo, la VM puede realizar solicitudes a un bucket de Cloud Storage en otro proyecto, por lo que el robo con el servicio de Cloud Storage aún es posible. En los siguientes pasos, se muestra cómo implementar y probar esta situación:
- Cambia a la pestaña de Cloud Shell, en la que la línea de comandos comienza con
username@cloudshell. En la pestaña de Cloud Shell, crea un archivo YAML que describa el servicio de política de la organización que solo permitirá el uso del servicio de Compute Engine y rechazará todos los demás, y luego aplícalo a tu proyecto.
cat <<EOF > allowed_services_policy.yaml constraint: constraints/gcp.restrictServiceUsage listPolicy: allowedValues: - compute.googleapis.com inheritFromParent: true EOFgcloud resource-manager org-policies set-policy allowed_services_policy.yaml \ --project=PROJECT_ID
Regresa a la pestaña que tiene la sesión SSH en la VM dentro del perímetro, en la que la ventana de la línea de comandos comienza con
username@demo-vm.Desde la sesión SSH dentro de tu perímetro, ejecuta el siguiente comando para ver el mismo bucket de almacenamiento que creaste antes en este proyecto.
gcloud storage buckets describe gs://PROJECT_ID
El resultado es similar a este:
"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'."En esta respuesta, se demuestra que el servicio de políticas de la organización niega el servicio de Cloud Storage dentro de tu proyecto, sin importar la configuración del perímetro.
Desde la sesión SSH dentro de tu perímetro, ejecuta el siguiente comando para ver un bucket de almacenamiento fuera del perímetro que permite tu política de salida.
gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
El resultado es similar a este:
"Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."Una respuesta correcta muestra el contenido de
helloworld.txten el bucket de almacenamiento externo. Esta respuesta demuestra que el perímetro y la política de salida permiten que el tráfico interno llegue a un bucket de almacenamiento externo en ciertas condiciones limitadas, pero el servicio de políticas de la organización niega el servicio de Cloud Storage en tu proyecto sin importar la configuración del perímetro. Es posible que los servicios fuera de tu proyecto aún se usen para el robo de datos si el perímetro los permite, sin importar el Servicio de políticas de la organización sobre el uso de recursos restringidos del servicio.Para denegar la comunicación con Cloud Storage o cualquier otro servicio de Google fuera del perímetro, el servicio de política de la organización Uso restringido de recursos de servicios no es suficiente, debes configurar un perímetro de los Controles del servicio de VPC. Los Controles del servicio de VPC mitigan las rutas de robo de datos y el Uso restringido de recursos del servicio es un control de cumplimiento para evitar que se creen servicios no aprobados dentro del entorno. Usa estos controles juntos a fin de bloquear un rango de rutas de robo de datos y permitir servicios aprobados de forma selectiva para uso interno en tu entorno.
Limpia
Borra un proyecto de Google Cloud:
gcloud projects delete PROJECT_ID
Aunque el perímetro de los Controles del servicio de VPC no genera ningún costo adicional, debes realizar una limpieza para evitar un desorden y los recursos no utilizados en tu organización.
- En el selector de proyectos en la parte superior de la consola de Google Cloud, selecciona la organización que usaste durante este instructivo.
En la consola de Google Cloud, ve a la página Controles del servicio de VPC.
En la lista de perímetros, selecciona el perímetro que deseas borrar y haz clic en Borrar.
En el cuadro de diálogo, haz clic en Borrar nuevamente para confirmar la eliminación.
¿Qué sigue?
- Obtén más información sobre las prácticas recomendadas para habilitar los Controles del servicio de VPC.
- Obtén más información sobre qué servicios son compatibles con los Controles del servicio de VPC.
- Obtén más información para habilitar los servicios accesibles de VPC.
- Lee sobre la configuración de Private Service Connect para acceder a las API de Google.
Si deseas conocer más arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas, explora el Centro de arquitectura de Cloud.