Proteger recursos con los Controles de Servicio de VPC

Para proteger aún más tus recursos de Compute Engine, puedes usar Controles de Servicio de VPC.

Controles de Servicio de VPC te permite definir un perímetro de servicio para tus recursos de Compute Engine. El perímetro de servicio limita la exportación e importación de recursos y sus datos asociados al perímetro definido.

Cuando creas un perímetro de servicio, seleccionas uno o varios proyectos que quieres proteger con el perímetro. Las solicitudes entre proyectos que se encuentren en el mismo perímetro no se verán afectadas. Todas las APIs seguirán funcionando siempre que los recursos implicados estén dentro del mismo perímetro de servicio. Ten en cuenta que los roles y las políticas de IAM siguen aplicándose dentro de un perímetro de servicio.

Cuando un servicio está protegido por un perímetro, el servicio dentro del perímetro no puede enviar solicitudes a ningún recurso fuera del perímetro. Esto incluye la exportación de recursos desde dentro hacia fuera del perímetro. Las solicitudes de recursos protegidos que proceden de fuera de un perímetro se pueden realizar si cumplen determinados criterios. Para obtener más información, consulta la descripción general de la documentación de Controles de Servicio de VPC.

Cuando se hace una solicitud que infringe el perímetro de servicio, se produce un error con el siguiente mensaje:

"code": 403, "message": "Request is prohibited by organization's policy."

Ventajas para la seguridad

Los Controles de Servicio de VPC ofrecen las siguientes ventajas de seguridad:

  • El acceso a operaciones sensibles de la API de Compute Engine, como cambiar reglas de firewall, se puede restringir al acceso privado desde redes autorizadas o a direcciones IP que formen parte de una lista de permitidas.
  • Las capturas de discos persistentes y las imágenes personalizadas de Compute Engine se pueden restringir a un perímetro.
  • Los metadatos de instancias de Compute Engine actúan como un sistema de almacenamiento limitado. El acceso a los metadatos de las instancias a través de la API de Compute Engine está limitado por la política de perímetro de servicio, lo que reduce los riesgos de filtración externa mediante este canal.

Además, ahora se puede acceder a la API de Compute Engine en la IP virtual (VIP) restringida. De esta forma, se simplifica la configuración de Cloud DNS y de enrutamiento para los clientes que se encuentran dentro del perímetro y que necesitan acceder a esta API.

Limitaciones

  • Los cortafuegos jerárquicos no se ven afectados por los perímetros de servicio.
  • Las operaciones de emparejamiento de VPC no aplican restricciones de perímetros de servicio de VPC.
  • El método de API projects.ListXpnHosts de VPC compartida no aplica restricciones de perímetro de servicio a los proyectos devueltos.

Permisos

Asegúrate de tener los roles adecuados para administrar las configuraciones de perímetro de Controles de Servicio de VPC de tu organización.

Configurar un perímetro de servicio

Sigue las instrucciones de la sección Crear un perímetro de servicio de la documentación de Controles de Servicio de VPC para configurar un perímetro de servicio.

Si configura un perímetro de servicio mediante la CLI de Google Cloud, especifique compute.googleapis.com con la marca --restricted-services para restringir la API Compute Engine.

Añadir Compute Engine como servicio restringido a un perímetro

Si ya tienes un perímetro de servicio y quieres añadir Compute Engine, sigue las instrucciones que se indican en el artículo Actualizar un perímetro de servicio de la documentación de Controles de Servicio de VPC.

Crear una VM con Controles de Servicio de VPC

Una vez que hayas configurado un perímetro de servicio, no tendrás que hacer ningún cambio en las llamadas a la API ni en las herramientas, siempre que los recursos afectados de tus solicitudes estén incluidos en el mismo perímetro de servicio. Por ejemplo, el siguiente comando crea una instancia de VM con una imagen de ejemplo. En este caso, el comando falla si el IMAGE_PROJECT está fuera del perímetro de servicio (y no hay ningún puente de perímetro de servicio entre los proyectos).

gcloud compute instances create new-instance \
    --image-family IMAGE_FAMILY --image-project IMAGE_PROJECT \
    --zone us-central1-a --machine-type n1-standard-72

Si creas una VM a partir de una plantilla de instancia, todos los recursos a los que se haga referencia en la plantilla de instancia deben pertenecer al mismo perímetro de servicio en el que ejecutas el comando o estar conectados mediante un puente de perímetro de servicio. La solicitud falla si la plantilla de instancia hace referencia a un recurso que está fuera del perímetro de servicio, aunque la plantilla de instancia esté dentro del perímetro.

Para ver un ejemplo de un cliente de Compute Engine que está fuera del perímetro y crea un disco de Compute Engine fuera del perímetro mediante una clave de Cloud KMS que está dentro del perímetro, consulta Ejemplos de solicitudes de API permitidas por la combinación de reglas de entrada y salida.

Proyectos de imagen pública

Todos los proyectos de imágenes que se muestran en la página Detalles del SO se incluyen automáticamente en todos los perímetros de servicio. Además, también se incluyen automáticamente los proyectos de imagen de Fedora Cloud, openSUSE y HPC OS.

Si usas proyectos de imágenes que no están incluidos en tu perímetro de servicio y no quieres añadirlos directamente, te recomendamos que copies estos proyectos de imágenes en otro proyecto. Después, puede añadir ese proyecto a su perímetro de servicio.

Copiar imágenes con Controles de Servicio de VPC

Puedes copiar imágenes de un proyecto a otro si ambos proyectos pertenecen al mismo perímetro de servicio. En este ejemplo, tanto DST_PROJECT como SRC_PROJECT deben pertenecer al mismo perímetro de servicio para que la solicitud funcione.

gcloud compute images create --project DST_PROJECT IMAGE_NAME \
   --source-image SOURCE_IMAGE --source-image-project SRC_PROJECT \
    --family IMAGE_FAMILY --storage-location LOCATION

Si decide no incluir el proyecto de imagen directamente en su perímetro de seguridad, le recomendamos que haga una copia de todas las imágenes que vaya a usar en un proyecto independiente y, a continuación, incluya ese proyecto en su perímetro de seguridad.

VPC compartida con Controles de Servicio de VPC

Cuando se usa una VPC compartida, las restricciones del perímetro de servicio se aplican a todos los proyectos implicados en una operación determinada. En otras palabras, te recomendamos que te asegures de que el proyecto del host y los proyectos de servicio estén dentro del mismo perímetro de servicio cuando una operación implique recursos distribuidos entre el proyecto del host y los proyectos de servicio.

Emparejamiento entre redes VPC

El emparejamiento entre redes de VPC permite emparejar redes de VPC entre dos organizaciones independientes. Como un perímetro de servicio se limita a los proyectos de una organización, los perímetros de servicio no afectan a las redes de VPC emparejadas.

Cortafuegos jerárquicos

Los cortafuegos jerárquicos son cortafuegos que se configuran fuera de un proyecto (ya sea a nivel de carpeta o de organización). Las restricciones de perímetro de servicio no se aplican a los cortafuegos jerárquicos.

Grupos de instancias administradas

Los grupos de instancias gestionados te ayudan a gestionar un grupo de instancias de VM como una sola entidad. Los grupos de instancias gestionadas (MIGs) usan plantillas de instancia para crear VMs, por lo que se aplican todas las restricciones relacionadas con las imágenes o las redes y subredes entre proyectos. Es decir, cuando uses imágenes de otros proyectos, asegúrate de que los proyectos pertenezcan al mismo perímetro o copia las imágenes que necesites en otro proyecto e incluye ese proyecto en el perímetro de servicio. Los proyectos de imágenes públicas mantenidos por Google se incluyen automáticamente en todos los perímetros de servicio.

Si quieres usar grupos de instancias con una VPC compartida, asegúrate de que tus proyectos estén en el mismo perímetro de servicio.

Siguientes pasos