Configura las reglas

El proxy web seguro te permite definir varios tipos de reglas dentro de tus políticas para proteger el tráfico web saliente. Puedes usar estas reglas para controlar con precisión la seguridad de tu tráfico a través de detalles específicos de las solicitudes, como encabezados y patrones de URL, y garantizar que solo el tráfico HTTP/S aprobado salga de tu red.

En esta página, se describen los distintos tipos de reglas y los pasos para crearlas y agregarlas a tu política de seguridad.

Configura reglas de coincidencia de host

Las reglas de coincidencia de host evalúan el nombre de host de destino de una solicitud web en función de tus listas de URLs permitidas o rechazadas. Al verificar el dominio de destino, como www.example.com, estas reglas garantizan que tu tráfico llegue solo a los sitios web y servicios aprobados.

En esta sección, se explica cómo configurar reglas de coincidencia de host para los siguientes modos de implementación de Secure Web Proxy:

Modo de proxy explícito
Modo de próximo salto

Modo de proxy explícito

Cuando implementes el Proxy web seguro como un proxy explícito, configura reglas de coincidencia de host para verificar que la información del host que envía el cliente se extraiga correctamente y se verifique con las reglas de seguridad que definiste. En el modo de proxy explícito, los clientes se configuran de forma activa para enviar su tráfico directamente a la instancia de Secure Web Proxy.

La coincidencia de host en el modo de proxy explícito funciona para diferentes tipos de tráfico web de la siguiente manera:

Tipo de tráfico	Mecanismo de correlación	Configuración de la regla
HTTP sin encriptar	El proxy web seguro verifica el nombre de host de destino con el campo `host` en el encabezado `CONNECT` estándar de la solicitud HTTP.	En el campo `sessionMatcher`, usa `host() == "example.com"`.
HTTPS encriptado (sin inspección de seguridad de la capa de transporte [TLS])	La coincidencia de host tampoco es posible a nivel de la aplicación ni de la sesión. Esto se debe a que los detalles de la solicitud están encriptados y el atributo `destination.ip` no es compatible. Debes usar controles de políticas más amplios, como la coincidencia de identidad de origen, o habilitar la inspección de TLS para el filtrado basado en el host.	Para usar Application Matcher, usa la coincidencia de identidad de origen, como las cuentas de servicio, o habilita la inspección de TLS.
HTTPS encriptado (con inspección de TLS)	Para inspeccionar la solicitud completa, debes usar el Session Matcher y el Application Matcher.	1. Establece una regla general de Session Matcher que devuelva `true` o que coincida con el host de destino, como `host() == "example.com"`. 2. En el campo `applicationMatcher`, agrega una regla de host específica, como `request.host() == "example.com"`.

Modo de próximo salto

Cuando implementes Secure Web Proxy como próximo salto, debes configurar reglas de coincidencia de host. El tráfico se redirecciona al proxy a través de una ruta de nube privada virtual (VPC) basada en los rangos de direcciones IP que definas. Las reglas de coincidencia de host garantizan que el proxy identifique correctamente el host de destino verificando varios campos del tráfico, como el encabezado de indicación del nombre del servidor (SNI).

La coincidencia de host en el modo de próximo salto funciona para diferentes tipos de tráfico web de la siguiente manera:

Tipo de tráfico	Mecanismo de correlación	Configuración de la regla
HTTP sin encriptar	El proxy web seguro verifica el nombre de host de destino en el campo `host` del encabezado de solicitud HTTP estándar.	En el campo `sessionMatcher`, usa `host() == "example.com"`.
HTTPS encriptado (sin inspección de TLS)	El proxy web seguro verifica el nombre de host con el encabezado SNI en la solicitud saliente, que es visible incluso si el resto del tráfico está encriptado.	En el campo `sessionMatcher`, usa `host() == "example.com"`.
HTTPS encriptado (con inspección de TLS)	Para inspeccionar la solicitud completa, debes usar el Session Matcher y el Application Matcher.	1. Establece una regla general de Session Matcher que devuelva `true` o que coincida con el host de destino, como `host() == "example.com"`. 2. En el campo `applicationMatcher`, agrega una regla de host específica, como `request.host() == "example.com"`.

Configura reglas de proxy TCP

Puedes configurar reglas de proxy del Protocolo de control de transmisión (TCP) para tu aplicación y, así, proteger el tráfico que no es web y aplicar políticas de seguridad para las aplicaciones que no usan HTTP/S estándar, como los puertos 80 y 443.

Si aplicas estas reglas, puedes evitar el uso no autorizado de otros puertos TCP para la transferencia de datos o la actividad maliciosa. Esto es particularmente útil cuando tus cargas de trabajo usan Secure Web Proxy como próximo salto para protocolos que no son web.

Para implementar reglas de proxy TCP y crear una regla de permiso o bloqueo de tráfico para tu aplicación, debes especificar el puerto de destino. De manera opcional, puedes incluir cualquiera de los siguientes atributos del Session Matcher para definir mejor los criterios de la regla de bloqueo o permiso.

En la siguiente tabla, se proporciona más información sobre los distintos atributos que puedes usar en una regla de proxy TCP:

Atributo	Tipo de atributo	Descripción
`source.ip`	cadena	Dirección IP del cliente que envió la solicitud.
`source.port`	cadena	Es el puerto del cliente que envió la solicitud.
`destination.port`	cadena	Es el puerto upstream al que tu instancia de Proxy web seguro envía el tráfico.
`source.matchTag(SECURE_TAG)`	booleano	`True`, si la fuente está asociada con `SECURE_TAG`. El argumento es el ID permanente de la etiqueta segura, como `source.matchTag('tagValues/123456')`.
`source.matchServiceAccount(SERVICE_ACCOUNT)`	booleano	`True`, si la fuente está asociada con `SERVICE_ACCOUNT`, como `source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	booleano	`True`, si `IP_ADDRESS` se incluye en `IP_RANGE`, como `inIpRange(source.ip, '1.2.3.0/24')` Las máscaras de subred para direcciones IPv6 no pueden ser mayores que "/64".

Ejemplo de regla de proxy TCP

En este ejemplo, se muestra cómo definir un proxy web seguro gatewaySecurityPolicyRule con una expresión CEL para permitir todo el tráfico TCP al puerto 22. Puedes usar esta configuración cuando apliques las capacidades del proxy TCP del Proxy web seguro.

En el siguiente muestra de código, se muestra cómo definir una regla de proxy TCP:

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

Reemplaza lo siguiente:

PROJECT_ID: ID de tu proyecto
REGION: Región de tu política
POLICY_NAME: Nombre de la política
RULE_NAME: Es el nombre de la regla del proxy TCP. En este ejemplo, podemos considerar su valor como allow-ssh-tcp-proxy.

Consideraciones importantes

Todas las reglas de proxy TCP que configures deben tener una prioridad más alta (número más bajo) que las reglas HTTP/S para garantizar que se evalúen y se apliquen primero. Para obtener más información, consulta Orden de evaluación de reglas.
Cuando se configuran reglas de proxy TCP, no se admite el atributo host Session Matcher porque la información del host no está disponible en la capa TCP.
Las reglas de proxy TCP filtran el tráfico web solo según el puerto de destino. Para mejorar la seguridad de tu red, te recomendamos que agregues otras condiciones con los operadores lógicos AND (&&) y OR (||), y atributos admitidos, como source.ip. A continuación, se muestra un ejemplo de cómo definir una regla de proxy TCP más específica:
```
  // Allow port 22 from only a specific source IP range
  sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
```
Secure Web Proxy no admite la capacidad de configurar reglas de proxy para aplicaciones del protocolo de datagramas de usuario (UDP). Como resultado, el proxy web seguro bloquea el tráfico de las aplicaciones basadas en UDP.

Crea una regla del Proxy web seguro

En esta sección, se explica cómo crear una regla del Proxy web seguro.

Antes de crear una regla, asegúrate de realizar las siguientes acciones:

Completa todos los pasos de configuración inicial.
Crea una política

Después de crear una regla y asociarla con una política, puedes usar la regla cuando implementes el proxy web seguro.

Console

En la consola de Google Cloud , ve a la página Políticas de SWP.

Ir a Políticas de SWP
Haz clic en el nombre de tu política, como policy1.
Haz clic en Agregar regla.
Para cada regla, haz lo siguiente:
1. En Prioridad, ingresa un orden de evaluación numérico para la regla. Las reglas se evalúan de mayor a menor prioridad, en la que 0 es la prioridad más alta.
2. En el campo Nombre, ingresa un nombre para la regla.
3. En el campo Descripción, ingresa una descripción para la regla.
4. En Acción, selecciona una de las siguientes opciones:
  - Permitir: Para permitir las solicitudes de conexión que coinciden con la regla
  - Rechazar: Para rechazar las solicitudes de conexión que coinciden con la regla.
5. En el campo Estado, selecciona una de las siguientes opciones para la aplicación de la regla:
  - Habilitada: Para aplicar la regla en tu instancia de Proxy web seguro
  - Inhabilitado: Para no aplicar la regla en tu instancia de Proxy web seguro
6. En la sección Session Match, especifica los criterios para hacer coincidir la sesión, como host() == "www.wikipedia.org".
  
  Para obtener más información sobre la sintaxis de SessionMatcher, consulta la referencia del lenguaje del comparador de CEL.
7. En la sección Application Match, especifica los criterios para hacer coincidir la solicitud.
  
  Para obtener más información sobre la correlación del tráfico de TCP, consulta Configura reglas de proxy TCP.
8. Haz clic en Agregar regla.

Cloud Shell

Crea el archivo rule.yaml como se muestra aquí. Para obtener más información sobre la sintaxis de sessionMatcher, consulta la referencia del lenguaje del comparador de CEL.
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
description: Allow wikipedia.org
enabled: true
priority: 1
basicProfile: ALLOW
sessionMatcher: host() == 'www.wikipedia.org'
```
Reemplaza lo siguiente:
- PROJECT_ID: ID de tu proyecto
- REGION: Región de tu política
- RULE_NAME: Es el nombre de la regla. En este ejemplo, podemos considerar su valor como allow-wikipedia-org.
Opcional: Como alternativa, si quieres crear una regla con la inspección de TLS habilitada, crea el archivo rule.yaml como se muestra aquí. Para obtener más información, consulta Descripción general de la inspección de TLS y Habilita la inspección de TLS.
```
  name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
  description: Allow wikipedia.org
  enabled: true
  priority: 1
  basicProfile: ALLOW
  sessionMatcher: host() == 'www.wikipedia.org'
  applicationMatcher: request.path.contains('index.html')
  tlsInspectionEnabled: true
```
Para obtener más información sobre la correlación del tráfico de TCP, consulta Configura reglas de proxy TCP.

Importante: Para habilitar la inspección de TLS en cada regla que crees, establece el atributo tlsInspectionEnabled como true para cada regla que use applicationMatcher para hacer coincidir el tráfico HTTPS. La inspección de TLS para la regla se limita al tráfico que coincide con el atributo sessionMatcher de la regla. Para obtener más información, consulta Evaluación de reglas de inspección de TLS.

Crea la regla de la política de seguridad.

gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
    --source=rule.yaml \
    --location=REGION \
    --gateway-security-policy=policy1