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 configuraciones de DNS, que son necesarias para usar un perímetro de Controles del servicio de VPC de manera eficaz. Luego, en este instructivo, se muestra cómo se permiten o rechazan los servicios y cómo hacer excepciones detalladas para una lista de entidades permitidas de servicios específicos.
Objetivos
- Configurar 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 a partir de solicitudes que se originan dentro o fuera de este.
- Permite o deniega el acceso a servicios fuera del perímetro de las solicitudes que se originan dentro de este.
- Usa la política de la organización Restringir el uso de servicios de recursos y los Controles del servicio de VPC en conjunto.
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 de 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 Controles del servicio de VPC para una red de VPC, debes implementar controles de red que denieguen 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, configuras la conectividad privada a los servicios y las APIs de Google para tu red de VPC con el fin de mitigar un rango de rutas de acceso de salida de red a Internet.
En Cloud Shell, configura 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: Es una zona cercana a 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 APIs 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 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
Configura una regla de firewall con una prioridad más alta para permitir que el tráfico llegue a la dirección IP que usa tu 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 de manera selectiva al extremo de Private Service Connect. Esta configuración rechaza el tráfico de salida a los dominios predeterminados a los que se suele 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ás un perímetro de Controles del servicio de VPC.
En Cloud Shell, crea una política de acceso como requisito 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 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 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 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 el acceso a las solicitudes realizadas desde fuera del perímetro y cómo puedes permitir de forma selectiva la entrada a los servicios mediante la configuración de niveles de acceso y políticas de entrada.
Para simular el tráfico desde fuera del 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 solicitudes, aunque estas tengan privilegios de Identity and Access Management suficientes para tener éxito.
En este instructivo, se usan la API de Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
Verifica que el perímetro deniegue el tráfico externo a los servicios restringidos
En esta sección, verificarás que el perímetro deniegue el tráfico externo a los servicios restringidos.
En el diagrama anterior, se ilustra cómo a un cliente autorizado se le niega el acceso a los servicios dentro del perímetro que configuraste como restringidos, pero el cliente puede acceder a los servicios que no configuraste como restringidos.
En los siguientes pasos, verificarás este concepto mediante Cloud Shell para intentar crear una VM dentro de la 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 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-addressEl resultado es 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.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 devuelve los detalles de tu proyecto. Esta respuesta demuestra que tu perímetro permite el tráfico externo a la API de Cloud 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 que no están configurados de forma explícita en--restricted-services.
En las siguientes secciones, se presentan patrones de excepción para alcanzar los 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 deseas crear una excepción de tráfico externo para acceder a todos los servicios restringidos dentro del perímetro y no necesitas excepciones detalladas para cada servicio o cualquier otro atributo.
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 restringida.
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 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
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 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, debes verificar que una política de entrada permita una excepción detallada al perímetro. En comparación con el nivel de acceso poco detallado, 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, para verificar este concepto, debes reemplazar el nivel de acceso por una política de entrada que permita a un cliente autorizado acceder solo al servicio de Compute Engine, pero no 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, ejecuta 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 al siguiente:
"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 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
Si la respuesta es correcta, se mostrarán los detalles de
demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico externo que cumple con las condiciones de tu 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 que están dentro del perímetro, y cómo puedes permitir de forma selectiva la salida a servicios externos mediante las políticas de salida.
Para demostrar la diferencia entre el tráfico 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 creas dentro de él. 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 sigues 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 usan la API de Compute Engine, Cloud Storage y Cloud Resource Manager, pero los mismos conceptos también se aplican a otros servicios.
Verifica que el perímetro permita el tráfico interno a los servicios restringidos dentro del perímetro
En esta sección, verificarás que el perímetro permita el tráfico desde extremos de red dentro del 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, para verificar este concepto, debes establecer una conexión SSH a la instancia de Compute Engine dentro del perímetro y, luego, realizar solicitudes a los servicios.
En Cloud Shell, crea una regla de firewall que permita el tráfico SSH a tu red de VPC permitiendo la entrada desde el rango 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
Inicia una sesión SSH para esta instancia:
gcloud compute ssh demo-vm --zone=ZONE
Para verificar que te conectaste de forma correcta a la instancia
demo-vm, confirma que la ventana de la línea de comandos haya cambiado y muestre el nombre de host de la 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 terminado de iniciarse. Espera un minuto y vuelve a intentarlo.
Desde la sesión SSH dentro del perímetro, verifica los servicios que este permite de forma interna con un servicio de Google Cloud configurado en la lista de servicios permitidos de VPC. Por ejemplo, prueba cualquier comando con el servicio de Compute Engine.
gcloud compute instances describe demo-vm --zone=ZONE
Si la respuesta es correcta, se mostrarán los detalles de
demo-vm. Esta respuesta demuestra que tu perímetro permite el tráfico interno a la API de Compute Engine.En la sesión SSH dentro de tu perímetro, verifica que no se permitan desde tu VM los servicios que no están incluidos en la lista de servicios permitidos de VPC accesibles. Por ejemplo, el siguiente comando usa el servicio de Resource Manager, que no está configurado en la lista de entidades permitidas de servicios accesibles de VPC.
gcloud projects describe PROJECT_ID
El resultado es similar al siguiente:
"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 servicios permitidos de VPC accesibles. Sin embargo, es posible que los recursos sin servidores o el tráfico del servicio que se origine fuera de tu perímetro soliciten ese servicio. Si quieres evitar que se use un servicio en tu proyecto, consulta la política de Uso restringido de recursos de servicios.
Verifica que el perímetro deniegue el tráfico interno a 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 a 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, para verificar este concepto, intentarás 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 del perímetro, ejecuta el siguiente comando para crear un bucket de almacenamiento dentro del perímetro. Este comando funciona porque el servicio de Cloud Storage está configurado tanto en
restricted-servicescomo enaccessible-services.gcloud storage buckets create gs://PROJECT_ID-02
Una respuesta correcta crea el bucket de almacenamiento. Esta respuesta demuestra que tu perímetro permite el tráfico interno al servicio de Cloud Storage.
Desde la sesión SSH dentro del perímetro, ejecuta el siguiente comando para leer desde un bucket que esté fuera del perímetro. Este bucket público otorga permiso de solo lectura a
allUsers, pero el perímetro rechaza 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 es 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 de él.
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 otorgas una excepción estrecha con la política de salida.
En los siguientes pasos, para verificar este concepto, crearás una política de salida y, luego, accederás 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, cambiarás entre la primera pestaña con la sesión SSH dentro del perímetro y la segunda pestaña en Cloud Shell fuera del perímetro, en la que comienza la ventana de la línea de comandos 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-vmmediante el métodogoogle.storage.objects.geta un bucket público en un proyecto externo. Actualizar el perímetro con la política de salidaexport 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 con la sesión SSH a la VM dentro de tu perímetro, donde 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 al siguiente:
"Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."Esta respuesta demuestra que tu perímetro y 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 del perímetro, también puedes probar otros métodos que la excepción de la política de salida no permitió de forma explícita. Por ejemplo, el siguiente comando requiere el permiso
google.storage.buckets.list, que tu perímetro rechaza.gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
El resultado es similar al siguiente:
"ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."Esta respuesta demuestra que tu perímetro rechaza el tráfico interno de enumerar objetos en el bucket externo, lo que indica que la política de salida permite de forma limitada los métodos especificados de manera explícita.
Si quieres obtener más referencias sobre los patrones comunes para compartir datos fuera del perímetro de servicio, consulta intercambio seguro de datos con reglas de entrada y salida.
(Opcional) Configura la política de uso restringido de recursos de servicios
También es posible que tengas requisitos internos o de cumplimiento para permitir que solo las APIs aprobadas de forma individual se usen en tu entorno. En este caso, también puedes configurar el servicio de políticas de la organización Uso restringido de recursos de recursos. Cuando aplicas la política de la organización en un proyecto, restringes qué servicios 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 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 de este.
Por ejemplo, si defines una política de la organización para permitir Compute Engine y rechazar Cloud Storage en tu proyecto, una VM de 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 aún es posible el robo de datos con el servicio de Cloud Storage. 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 ventana de 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íticas de la organización que solo permitirá el uso del servicio de Compute Engine y rechazará todos los demás servicios. 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 con la sesión SSH a la VM dentro de tu perímetro, donde 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 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'."En esta respuesta, se muestra que el Servicio de políticas de la organización rechaza el servicio de Cloud Storage dentro de tu proyecto, sin importar la configuración de tu perímetro.
Desde la sesión SSH dentro del 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 al siguiente:
"Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."Si la respuesta es correcta, se muestra el contenido de
helloworld.txten el bucket de almacenamiento externo. Esta respuesta demuestra que tu perímetro y 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 rechaza el servicio de Cloud Storage en tu proyecto, sin importar la configuración de tu perímetro. Es posible que los servicios fuera de tu proyecto se sigan usando para el robo de datos si tu perímetro los permite, sin importar el Servicio de políticas de la organización de uso de recursos de servicio restringido.Para denegar la comunicación con Cloud Storage o con otros servicios de Google fuera del perímetro, el Uso restringido de recursos de recursos por sí solo no es suficiente, debes configurar un perímetro de Controles del servicio de VPC. Los Controles del servicio de VPC mitigan las rutas de robo de datos, y el Uso restringido de recursos de servicio es un control de cumplimiento para evitar la creación de servicios no aprobados dentro de tu entorno. Utiliza estos controles juntos para bloquear un rango de rutas de robo de datos y permitir selectivamente los servicios aprobados para el 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, se debe limpiar para evitar el desorden y los recursos sin usar en la 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 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 información sobre las prácticas recomendadas para habilitar los Controles del servicio de VPC.
- Obtén 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.
Para obtener más arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas, explora el Centro de arquitectura de Cloud.