Modo de ejecución de prueba para perímetros de servicio

Cuando se usan Controles de Servicio de VPC, puede ser difícil determinar el impacto en tu entorno cuando se crea o se modifica un perímetro de servicio. Con el modo de prueba, puedes comprender mejor el efecto de habilitar Controles de Servicio de VPC y los cambios en los perímetros de los entornos actuales.

En el modo de ejecución de prueba, las solicitudes que infringen la política del perímetro no se deniegan, sino que solo se registran. Puedes usar el modo de prueba para comprobar la configuración del perímetro y monitorizar el uso de los servicios sin impedir el acceso a los recursos. Estos son algunos de los usos más habituales:

  • Determinar el impacto que tendrán los cambios en los perímetros de servicio.

  • Vista previa del impacto que tendrán los nuevos perímetros de servicio.

  • Monitorizar las solicitudes a servicios protegidos que proceden de fuera de un perímetro de servicio. Por ejemplo, para ver de dónde proceden las solicitudes a un servicio determinado o para identificar un uso inesperado de los servicios en tu organización.

  • En tus entornos de desarrollo, crea una arquitectura de perímetro análoga a la de tu entorno de producción. De esta forma, puedes identificar y mitigar los problemas que causarán tus perímetros de servicio antes de implementar los cambios en tu entorno de producción.

Los perímetros de servicio pueden existir exclusivamente en el modo de prueba. También puedes tener perímetros de servicio que usen una combinación de modos de prueba y obligatorios.

Ventajas del modo de ejecución de prueba

Con el modo de prueba, puedes crear perímetros de servicio o cambiar varios perímetros ya existentes sin que esto afecte al entorno. Las solicitudes que infrinjan la nueva configuración de perímetro no se bloquearán. También puedes conocer el impacto del perímetro en un entorno en el que no todos los servicios que se utilizan están integrados con Controles de Servicio de VPC.

Puede analizar los registros de Controles de Servicio de VPC para ver las denegaciones, cambiar la configuración para solucionar posibles problemas y, a continuación, aplicar la nueva postura de seguridad.

Si no se pueden resolver los problemas con la configuración del perímetro, puede mantener la configuración de prueba del perímetro y monitorizar los registros para detectar denegaciones inesperadas que puedan indicar un intento de exfiltración. Sin embargo, no se deniegan las solicitudes al perímetro.

Conceptos del modo de ejecución de prueba

El modo de prueba de funcionamiento se comporta como una segunda pasada de evaluación de la configuración del perímetro. De forma predeterminada, la configuración del modo obligatorio de todos los perímetros de servicio se hereda en la configuración del modo de prueba, donde se puede modificar o eliminar sin que afecte al funcionamiento del perímetro de servicio.

Como el modo de prueba hereda la configuración del modo obligatorio, en cada paso ambas configuraciones deben ser válidas. En concreto, un proyecto solo puede estar en un perímetro en la configuración obligatoria y en un perímetro en la configuración de simulacro. Por lo tanto, los cambios que abarcan varios perímetros, como mover un proyecto de un perímetro a otro, deben realizarse en el orden adecuado.

En el modo de prueba de funcionamiento, solo se registra una solicitud si cumple los dos criterios siguientes:

  • La solicitud no se ha rechazado en la configuración de prueba o en la obligatoria del perímetro.

  • La solicitud infringe la configuración de ejecución de prueba del perímetro.

Por ejemplo, si las configuraciones idénticas de modo de prueba y modo obligatorio restringen un segmento de Cloud Storage, el modo obligatorio bloquea y registra cualquier solicitud al segmento de Cloud Storage. En el modo de prueba, solo se registran las diferencias en las infracciones en comparación con el modo activo.

En los registros de auditoría de una comprobación de políticas en modo de prueba, el valor del campo metadata.dryRun del registro de auditoría se define como True. Para obtener más información, consulta el artículo Contenido de los registros de auditoría.

También puedes crear perímetros que solo tengan una configuración de simulacro. Esto te permite simular el impacto de un nuevo perímetro obligatorio en tu entorno.

Para evaluar la configuración de prueba de un perímetro de servicio, asigna el valor True al campo useExplicitDryRunSpec en la configuración del perímetro de servicio. Para obtener más información, consulta accessPolicies.servicePerimeters.

Semántica de las políticas

En la siguiente sección se describe la relación entre las políticas de los modos de cumplimiento obligatorio y de prueba, así como el orden en el que se resuelven.

Restricción de pertenencia única

Un Google Cloud proyecto solo se puede incluir en una configuración obligatoria y en una configuración de prueba. Sin embargo, las configuraciones obligatorias y de prueba no tienen por qué ser del mismo perímetro. De esta forma, puedes probar el impacto de mover un proyecto de un perímetro a otro sin poner en riesgo la seguridad que se aplica actualmente al proyecto.

Ejemplo

El proyecto corp-storage está protegido por la configuración obligatoria del perímetro PA. Quieres probar el impacto de mover corp-storage al perímetro PB.

La configuración de ejecución de prueba de PA aún no se ha modificado. Como la configuración de ejecución de prueba no se ha modificado, hereda corp-storage de la configuración obligatoria.

Para probar el impacto, primero quita corp-storage de la configuración de ejecución de prueba de PA y añade el proyecto a la configuración de ejecución de prueba de PB. Primero debes quitar corp-storage de la configuración de ejecución de prueba de PA, ya que los proyectos solo pueden estar en una configuración de ejecución de prueba a la vez.

Cuando estés seguro de que migrar corp-storage de PA a PB no tendrá efectos adversos en tu postura de seguridad, decide aplicar los cambios.

Hay dos formas de aplicar los cambios a los perímetros PA y PB:

  • Puedes quitar manualmente corp-storage de la configuración obligatoria de PA y añadir el proyecto a la configuración obligatoria de PB. Como corp-storage solo puede estar en una configuración obligatoria a la vez, debes seguir los pasos en este orden.

    -o-

  • Puedes usar la herramienta de línea de comandos gcloud o la API Access Context Manager para aplicar todas las configuraciones de prueba. Esta operación se aplica a todas las configuraciones de prueba modificadas de tus perímetros, por lo que deberás coordinarla con cualquier otro miembro de tu organización que haya modificado las configuraciones de prueba de tus perímetros. Como la configuración de la prueba de la actualización automática ya excluye corp-storage, no es necesario realizar ningún paso adicional.

La configuración obligatoria de un perímetro se ejecuta primero

Solo se registran como infracciones de la política de ejecución de prueba las solicitudes que se permiten en la configuración obligatoria de un perímetro, pero que se deniegan en la configuración de ejecución de prueba. Las solicitudes que se deniegan por la configuración obligatoria, pero que se permitirían con la configuración de ejecución de prueba, no se registran.

Los niveles de acceso no tienen un equivalente al modo de prueba

Aunque puedes crear una configuración de prueba para un perímetro, los niveles de acceso no tienen ninguna. En la práctica, esto significa que, si quieres probar cómo afectaría un cambio en un nivel de acceso a tu configuración de prueba, debes hacer lo siguiente:

  1. Crea un nivel de acceso que refleje los cambios que quieras hacer en un nivel de acceso.

  2. Aplica el nuevo nivel de acceso a la configuración de prueba del perímetro.

El modo de prueba no tiene un impacto negativo en la seguridad

Los cambios en la configuración de una prueba de un perímetro, como añadir proyectos o niveles de acceso a un perímetro, o cambiar los servicios protegidos o accesibles para las redes que se encuentran dentro del perímetro, no afectan a la aplicación real de un perímetro.

Por ejemplo, supongamos que tienes un proyecto que pertenece al perímetro de servicio PA. Si el proyecto se añade a la configuración de prueba de otro perímetro, la seguridad real aplicada al proyecto no cambia. El proyecto sigue protegido por la configuración obligatoria de PA de perímetro, como se esperaba.

Acciones de ejecución de prueba y estados de configuración

Con la función de prueba, puedes hacer lo siguiente:

  • Crear un perímetro con solo una configuración de prueba

  • Actualizar la configuración de ejecución de prueba de un perímetro

  • Mover un proyecto nuevo a un perímetro ya creado

  • Mover un proyecto de un perímetro a otro

  • Eliminar la configuración de ejecución de prueba de un perímetro

En función de la acción realizada en el modo de prueba, un perímetro puede tener uno de los siguientes estados de configuración:

Heredado de obligatorio: estado predeterminado de los perímetros obligatorios. En este estado, los cambios que se hagan en la configuración obligatoria del perímetro también se aplicarán a la configuración de la prueba.

Modificado: se ha visto o cambiado la configuración de ejecución de prueba de un perímetro y, a continuación, se ha guardado. En este estado, los cambios que se hagan en la configuración obligatoria de un perímetro no se aplicarán a la configuración de ejecución de prueba.

Nuevo: el perímetro solo tiene una configuración de prueba. Aunque se hagan cambios en la configuración de la prueba, hasta que este perímetro tenga una configuración obligatoria, el estado seguirá siendo Nuevo.

Eliminada: se ha eliminado la configuración de prueba de funcionamiento del perímetro. Este estado se mantendrá hasta que crees una nueva configuración de prueba para el perímetro o deshagas la acción. En este estado, los cambios que se hagan en la configuración obligatoria de un perímetro no se aplicarán a la configuración de ejecución de prueba.

Limitaciones del modo de prueba

El modo de prueba solo se aplica a los perímetros. No ayuda a comprender el impacto de restringir el acceso a la API a la VIP restringida o privada. Google Cloud Te recomendamos que te asegures de que todos los servicios que quieras usar estén disponibles en la IP virtual restringida antes de configurar el dominio restricted.googleapis.com.

Si no sabes con certeza si las APIs que usas en un entorno determinado son compatibles con la IP virtual restringida, te recomendamos que utilices la IP virtual privada. Puedes seguir aplicando la seguridad perimetral en los servicios compatibles. Sin embargo, si usas el VIP privado, las entidades de tu red tendrán acceso a servicios no seguros (servicios que no son compatibles con los Controles de Servicio de VPC), como las versiones para consumidores de Gmail y Drive. Como el VIP privado permite usar servicios que no son compatibles con Controles de Servicio de VPC, es posible que un código vulnerado, un malware o un usuario malintencionado de tu red exfiltre datos mediante esos servicios no seguros.

Siguientes pasos