VPC Service Controls: la única defensa real contra la exfiltración en GCP, y por qué es difícil

Piensa en el escenario que IAM no puede abordar. Un ingeniero con roles/bigquery.dataViewer legítimo sobre tu dataset de clientes ejecuta una consulta y escribe el resultado en un bucket de Cloud Storage de su propio proyecto personal de GCP. Todas las llamadas a la API están autorizadas. Todas las líneas de log parecen normales. Los datos ya no están.

VPC Service Controls es el control que aborda esto, y es el motivo por el que una carga regulada en Google Cloud puede hacer una afirmación de residencia de datos más fuerte que su equivalente en otros sitios. También es el control que más caídas autoinfligidas provoca, así que el orden del despliegue importa más que el diseño.

Qué hace un perímetro de verdad

Un perímetro de servicio es una frontera alrededor de un conjunto de proyectos y un conjunto de APIs de Google. Dentro, las llamadas funcionan con normalidad. Cruzarlo —en cualquier dirección— se deniega salvo que una regla explícita lo permita.

Importan tres propiedades:

• Se aplica en la capa de API, no en la de red. Detiene las llamadas a bigquery.googleapis.com desde fuera del perímetro con independencia de que quien llama tenga permiso IAM.
• Es independiente de la identidad. Una clave de cuenta de servicio robada y usada desde fuera del perímetro no sirve de nada, lo que es una mitigación significativa para la credencial que más se filtra.
• Controla la salida además de la entrada. Copiar datos de un proyecto protegido a uno no protegido es cruzar el perímetro, que es el caso de exfiltración de arriba.

El despliegue que no provoca una caída

1. Dibuja el perímetro alrededor de los datos, no de todo. Los proyectos con datos de clientes, los datasets de BigQuery, los buckets. No tu proyecto de CI, no el de monitorización. Un perímetro que contiene todo tu entorno no protege nada de nada y lo rompe todo.

2. Ejecútalo en modo simulación al menos un mes. Los perímetros en dry-run registran lo que se habría denegado sin denegarlo. Esto no es opcional. Todo entorno tiene una integración que nadie documentó, y la simulación es cómo la encuentras antes de que te encuentre ella un viernes a las cuatro.

3. Lee las violaciones de simulación cada semana y clasifica cada una. Tres cubos: legítima y necesita una regla de entrada o salida, legítima pero debería moverse dentro del perímetro, o exactamente lo que construiste el perímetro para detener. La tercera categoría es rara y es la justificación de todo el proyecto.

4. Escribe las reglas tan estrechas como exijan las violaciones. Las reglas de entrada y salida se pueden acotar por identidad, por proyecto de origen, por servicio y por método. Una regla que permite a una cuenta de servicio llamar a un método desde un proyecto es una regla que puedes defender en una auditoría. Una regla que permite * desde * es un perímetro con un agujero.

5. Añade niveles de acceso para los humanos. Access Context Manager te permite exigir un rango de IP corporativo, un dispositivo gestionado o un grupo de identidad concreto para el acceso desde fuera. Así tus analistas siguen trabajando desde la VPN de la oficina mientras una credencial filtrada desde cualquier otro sitio no.

6. Impón, y mantén el perímetro en simulación en paralelo para el siguiente cambio.

Las cosas que se van a romper

Apréndelas antes, no durante:

• Cloud Build y la CI tirando de Artifact Registry dentro del perímetro. Necesita una regla de entrada o salida, o el proyecto de build dentro.
• Terraform desde un portátil o un runner de CI fuera. Vas a necesitar un nivel de acceso, y suele ser lo primero que se rompe.
• Sumideros de logs escribiendo en un bucket de otro proyecto.
• El acceso desde la consola a BigQuery desde un navegador fuera del nivel de acceso, que produce un error de permisos confuso en lugar de uno claro.
• Cualquier integración SaaS leyendo de tus buckets. Cada una necesita una regla de entrada documentada, lo que de por sí es un ejercicio de inventario útil.

Los mensajes de error de las denegaciones de perímetro son célebremente poco útiles. Prepara una consulta de logs guardada para las violaciones de VPC_SERVICE_CONTROLS el primer día y compártela con todo el equipo, o te pasarás el despliegue depurando problemas de IAM que no son problemas de IAM.

¿Compensa?

Para un entorno con datos personales regulados, datos de salud o datos de pago: sí, y a menudo es el control que acorta la conversación de cumplimiento. Para una startup con datos públicos de producto: no, y el coste operativo no se justifica.

El caso intermedio —un entorno con un dataset sensible entre muchos— es donde mejor funcionan los perímetros, precisamente porque puedes dibujar una frontera pequeña alrededor de lo que importa. Esa decisión de alcance es en lo que gastamos la primera semana de un proyecto de seguridad.

Qué hacer esta semana

Crea un perímetro en simulación alrededor de tu proyecto más sensible. No deniega nada, no cuesta nada, y en un mes te habrá enseñado todos los sistemas que tocan esos datos — una lista que casi nadie tiene.