Perímetros de servicio y sus equivalentes

Un perímetro de servicio es una frontera alrededor de proyectos (los recursos protegidos) y de una lista de servicios restringidos. Dentro, los recursos se hablan libremente; por defecto, la comunicación con esos servicios a través de la frontera se bloquea. Se abren excepciones con niveles de acceso (por ejemplo, solicitudes que vienen de un rango de direcciones de la oficina) y con reglas de ingreso y de egreso para entradas y salidas concretas. Hay un modo de simulación para ver qué bloquearía antes de aplicarlo.

Es una capa independiente de IAM: no sustituye a los permisos, se suma a ellos. Y solo protege lo que se incluye: un servicio que no está en la lista de restringidos queda fuera de la frontera.

Abre el laboratorio. En perimetros.json el perímetro perimetro-datos-sensibles protege dos proyectos y enumera sus servicios restringidos. En servicios-en-uso.txt está lo que cada proyecto guarda y en qué servicio. Un perímetro con la lista corta es un perímetro con un agujero.

La configuración de un perímetro tiene dos partes: status, la que se aplica de verdad, y spec, la del modo de simulación, que solo registra. Si un perímetro tiene useExplicitDryRunSpec activado y su status está vacío, parece protegido en el inventario y no protege nada. Sus entradas de registro llevan dryRun: true.

En el archivo hay dos perímetros. Uno aplica de verdad lo que dice; el otro solo está en simulación.

Los bloqueos de un perímetro van al registro de políticas (cloudaudit.googleapis.com%2Fpolicy), con la razón de la violación y el nombre del perímetro. NO_MATCHING_ACCESS_LEVEL significa que la dirección, el dispositivo o la identidad no coincide con ningún nivel de acceso ni con una regla de ingreso. RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER significa que una sola solicitud toca recursos que no están en el mismo perímetro, por ejemplo copiar de un proyecto protegido a uno que no lo está. El campo dryRun distingue lo que se habría bloqueado de lo que se bloqueó.

La idea de «los datos no salen de mi frontera, ni con permisos válidos» existe en las otras dos nubes con otras piezas. En AWS se construye un perímetro de datos con tres controles: identidades de confianza, recursos de confianza y red esperada, con claves de condición como la organización a la que pertenece quien pide o el recurso, y con políticas de punto de enlace de VPC. En Azure existe el perímetro de seguridad de red (Network Security Perimeter), que agrupa recursos como cuentas de almacenamiento y bóvedas de claves y, en modo forzado, deniega el tráfico público salvo reglas de acceso explícitas; tiene un modo de transición para observar antes de forzar, que se parece al modo de simulación de Google.