Muchas organizaciones tienen un requisito de cumplimiento de restringir el acceso de red a una lista de APIs aprobadas de forma explícita, en función de los requisitos internos o como parte de la adopción de Assured Workloads. En entornos locales, este requisito a menudo se aborda con controles de proxy, pero en la nube privada virtual (VPC) de Google puedes abordar este requisito con la política de la organización Restringir el uso de servicios del recurso en su lugar. Esta política permite que un administrador defina qué recursos de Google Cloud se pueden crear dentro de su jerarquía de recursos, pero para usar esta política de la organización de manera efectiva, debes alinear varios controles de red en tu entorno.
En este documento, se describe cómo restringir el acceso a las API de Google aprobadas de forma individual mediante el Servicio de políticas de la organización y otros controles de red, así como los desafíos de aplicar el enfoque local basado en proxies a los servicios de Google Cloud. Este documento está dirigido a los administradores de red o los equipos de seguridad que deseen restringir las APIs de Google Cloud a las que se puede acceder desde los extremos de su red de VPC.
Desafíos con proxies para el control de acceso a las API de Google
En una red local, es posible que tu empresa tenga un requisito de cumplimiento para permitir el tráfico de salida solo a los servicios y dominios aprobados. Este requisito se puede aplicar mediante el filtrado del tráfico de salida a través de un proxy web o una puerta de enlace de acceso seguro. Este proxy intercepta todo el tráfico saliente y permite la salida solo a las API aprobadas de forma explícita.
En algunas empresas, es posible que tengas un requisito de cumplimiento de restringir el acceso de la red de VPC a las APIs de Google Cloud aprobadas. Este control de cumplimiento se ve a menudo en las siguientes situaciones:
- Una empresa adopta Assured Workloads para controles de cumplimiento y cargas de trabajo sensibles.
- Una empresa tiene requisitos de cumplimiento internos que exigen que el acceso de extremos de red de Google Cloud a las APIs de Google Cloud solo se apruebe mediante un proceso interno.
- Una empresa desea migrar cargas de trabajo de infraestructura como servicio (IaaS) a Google Cloud con una refactorización mínima.
- Una empresa aún no desarrolla controles para la nube y prefiere extender los controles existentes desde el entorno local.
Aunque tu empresa puede usar un proxy web para controlar la salida de su red local a los servicios web, no recomendamos este enfoque para controlar el acceso desde la red de VPC a las APIs de Google Cloud. El uso de este enfoque de proxy genera problemas de escalabilidad, crea un punto único de fallo y no aborda los riesgos de robo de datos con el uso de las APIs de Google Cloud.
Recomendamos usar la política de la organización Restringir el uso de servicios del recurso en lugar de proxies para permitir el acceso de forma selectiva a APIs individuales de Google Cloud. Los desafíos relacionados con la compilación y el mantenimiento de un proxy web para el control de acceso a las APIs de Google individuales se analizan en las siguientes secciones.
Rangos de direcciones IP compartidos usados por varias API de Google
No puedes controlar el acceso a una API de Google individual mediante una regla de firewall o proxy que se filtre a una sola dirección IP. Google usa un rango dinámico de direcciones IP para dominios predeterminados. Dentro de estas direcciones IP, no existe una relación uno a uno entre una dirección IP dedicada y una API específica.
Dominios compartidos usados por las API de Google
Para algunas APIs de Google, no puedes controlar el acceso a la red mediante filtros de tráfico en los dominios. Se puede acceder a la mayoría de las APIs de Google en extremos que diferencian APIs específicas por ruta y comienzan con un URI que empieza con www.googleapis.com. Ciertas APIs de Google usan un extremo con un subdominio dedicado. Por ejemplo, la referencia de la API de Cloud Storage documenta los URI en relación con el extremo storage.googleapis.com/storage/v1, pero también puedes usar un URI que comience con www.googleapis.com/storage/v1 para llamar a los mismos métodos de API.
Cuando usas varias API que solo tienen extremos en el dominio www.googleapis.com, el proxy de salida no puede distinguir entre las API basadas en el dominio. Por ejemplo, algunas API de Google Cloud, como Deployment Manager y otras API de Google, como Tag Manager o Google Play Juegos, solo son accesibles en el dominio www.googleapis.com.
Además, todas las API de Google Cloud usan la encriptación TLS de forma predeterminada. Si deseas permitir una de estas API, pero bloquear las otras, tu proxy tendría que desencriptar la solicitud para filtrar la ruta del URI y aumentar la complejidad.
Cuellos de botella causados por proxies
Si todo el tráfico de la red de VPC a las API de Google debe pasar por un proxy de salida, el proxy podría convertirse en un cuello de botella. Si usas un proxy de salida para el tráfico desde tu red de VPC hacia las API de Google, te recomendamos que compiles el proxy a fin de tener alta disponibilidad para evitar la interrupción del servicio. Mantener y escalar el proxy puede volverse complejo porque, a medida que la organización crece, el proxy puede generar un punto único de fallo, latencia y reducción de la capacidad de procesamiento. Puede haber un impacto particular en las operaciones que transfieren grandes volúmenes de datos.
Riesgo de robo de servicio a servicio
Un proxy web puede restringir si se puede acceder a una API de Google desde tu red de VPC, pero no aborda otras rutas de robo de datos que usan la API de Google. Por ejemplo, un empleado de tu empresa podría tener privilegios de IAM legítimos para leer buckets de Cloud Storage internos. Con este privilegio, podría leer datos internos y, luego, copiarlos en un bucket público. El proxy de salida no puede restringir el tráfico de API a API que no se origina en la VPC ni controlar la forma en que el tráfico de Internet llega a los extremos públicos para las APIs de Google Cloud.
En el caso de los datos sensibles, un perímetro de Controles del servicio de VPC ayuda a mitigar este tipo de robo de datos. La aplicación de un perímetro de Controles del servicio de VPC ayuda a proteger los recursos dentro del perímetro de las políticas de IAM mal configuradas, el robo de datos y las credenciales vulneradas.
Configura controles de red para restringir los servicios no aprobados
Cuando uses la política de la organización Restringir el uso de servicios del recurso, a fin de restringir el acceso a los servicios de manera efectiva, debes considerar cómo tu red de VPC restringe el tráfico de salida y las rutas de robo de datos. En las siguientes secciones, se describen las prácticas recomendadas para el diseño de redes a fin de usar la política de la organización Restringir el uso de servicios del recurso de manera efectiva.
Configurar los Controles del servicio de VPC
Cuando uses la política de la organización Restringir el uso de servicios del recurso, te recomendamos que también configures los Controles del servicio de VPC. Cuando aplicas la política de la organización en un proyecto, restringes los servicios que se pueden usar en ese proyecto, pero la política de la organización no evita 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 de este proyecto no podría crear un bucket de Cloud Storage en tu proyecto ni comunicarse con él. 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. Para bloquear la comunicación con Cloud Storage o con otros servicios de Google fuera del perímetro, debes configurar un perímetro de Controles del servicio de VPC.
Usa estos controles juntos para permitir de forma selectiva servicios aprobados en tu entorno y bloquear una variedad de rutas de robo de datos a servicios no aprobados.
Quita rutas de acceso a Internet
Si los recursos de tu red de VPC pueden comunicarse directamente con Internet, puede haber una ruta alternativa a las APIs de Google no aprobadas y otros servicios que desees bloquear. Por lo tanto, recomendamos que solo uses direcciones IP internas en tus VMs y no permitas rutas de salida a través de una solución de proxy o NAT. La política de la organización Restringir el uso de servicios del recurso no mitiga las rutas de robo de datos a la Internet pública, por lo que aún se puede acceder a los servicios no aprobados de forma indirecta desde un servidor fuera del entorno.
Configura un extremo privado para el acceso a la API
Para controlar los extremos de API en tu red, te recomendamos acceder a las APIs de Google mediante Private Service Connect. Cuando configuras el Acceso privado a Google para permitir que las VMs solo con IP internas accedan a las APIs de Google, esto incluye acceso a todas las APIs de Google, incluidas las que no son compatibles con los Controles del servicio de VPC ni la política de la organización Restringir el uso de servicios del recurso.
Puedes restringir el Acceso privado a Google solo a las APIs compatibles mediante la configuración adicional de Private Service Connect con el paquete vpc-sc.
Por ejemplo, habilitar el Acceso privado a Google permite una ruta de red privada a todas las APIs de Google, como Google Drive o Google Maps Platform. Un empleado puede copiar datos a su Google Drive personal desde una instancia de Compute Engine mediante la API de Google Drive. Puedes evitar esta ruta de robo de datos si configuras Private Service Connect con el paquete vpc-sc para proporcionar acceso al mismo conjunto de servicios compatibles con la IP virtual (VIP) restringida en el extremo de restricted.googleapis.com. En comparación, se puede acceder a un conjunto más amplio de APIs de Google mediante el Acceso privado a Google cuando usas los dominios predeterminados de Google, un extremo de Private Service Connect configurado con el paquete all-apis o la VIP privada (private.googleapis.com).
Como alternativa, puedes configurar rutas a restricted.googleapis.com. Es posible que prefieras usar la VIP restringida si no deseas crear un extremo de Private Service Connect para cada región y cada red de VPC en tu entorno. Sin embargo, recomendamos el enfoque de Private Service Connect porque puedes crear un extremo interno de tu red de VPC, en comparación con el enfoque de la VIP restringida, que requiere una ruta a un extremo anunciado de forma pública.
¿Qué sigue?
- Obtén más información sobre la política de la organización Restringir el uso de servicios del recurso.
- Comprende qué APIs son compatibles con la política de la organización Restringir el uso de servicios del recurso.
- Obtén más información sobre qué API son compatibles con los Controles del servicio de VPC.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.