Esta página se ha traducido con Cloud Translation API.

Orden de evaluación de reglas

La evaluación de reglas determina si se debe permitir o denegar una solicitud web mediante las reglas que hayas definido en tu política. Tiene en cuenta los siguientes atributos para tomar sus decisiones:

Prioridad de una regla: los números enteros más bajos indican prioridades más altas.
SessionMatcher: coincide con los siguientes atributos a nivel de sesión:
- Dirección IP de la máquina de origen
- Cuenta de servicio de la máquina de origen
- Etiqueta segura de la máquina de origen
- Nombre de host del equipo de destino
ApplicationMatcher: se compara con los siguientes atributos de solicitud HTTP:
- URL
- Ruta
- Encabezados de solicitud

Para ver una lista de todos los atributos SessionMatcher y ApplicationMatcher, consulte Atributos disponibles en SessionMatcher y ApplicationMatcher.

Cómo funciona la evaluación de reglas

Las reglas se evalúan en el siguiente orden:

Las reglas de alta prioridad se evalúan primero.
La regla de mayor prioridad que coincida con los atributos SessionMatcher y ApplicationMatcher determina la acción que se debe llevar a cabo con el tráfico.
Si la solicitud no coincide con los atributos SessionMatcher y ApplicationMatcher de esa regla, se evalúa la siguiente regla con la prioridad más alta.
Este proceso continúa hasta que se encuentra una regla que coincide con la solicitud o hasta que se han evaluado todas las reglas. Si no se encuentra ninguna coincidencia, se rechaza la solicitud.

Antes de configurar la inspección TLS

Debes conocer los siguientes casos de evaluación de reglas antes de configurar la inspección TLS:

Un cliente puede enviar una solicitud HTTP al servidor proxy. La solicitud se evalúa con todos los datos disponibles, incluidos el nombre de host, la identidad de origen, los encabezados HTTP y la ruta.

Si se permite la solicitud, el tráfico HTTP se envía al destino. Sin embargo, si se rechaza la solicitud, no se permitirá que pase el tráfico HTTP.
Un cliente puede enviar al proxy una solicitud HTTP CONNECT para establecer un túnel TCP a la destinación. Esto se hace cuando el cliente quiere enviar tráfico TCP arbitrario o establecer una conexión TLS de extremo a extremo con el destino a través del proxy, como ocurre con HTTPS.
Si una regla tiene un atributo SessionMatcher coincidente y no contiene un atributo ApplicationMatcher, y la evaluación de la regla permite el tráfico, se establece un túnel a la destinación y el tráfico se proxyiza por TCP. Esto se aplica al tráfico HTTPS y TCP.
Si las reglas de mayor prioridad no pueden determinar la acción que se debe llevar a cabo en una solicitud, se sigue evaluando la regla. Si la evaluación continúa con una regla que tiene un atributo ApplicationMatcher, el tráfico tunelizado se interpreta como HTTP o HTTPS.

Si los datos subyacentes no son HTTP o HTTPS, la conexión fallará.

Si los datos subyacentes son HTTP, se evalúan las solicitudes, incluidos el nombre de host, la identidad de origen, los encabezados HTTP y la ruta. En función del resultado de la evaluación, el tráfico se permite o se deniega.
En el caso del tráfico HTTPS, una regla solo se evalúa si tiene habilitada la marca de inspección TLS. De lo contrario, se omite.
En el caso del tráfico HTTPS, una regla solo se inspecciona si se cumplen las siguientes condiciones:
- La marca de inspección TLS está habilitada.
- El tráfico coincide con los atributos de SessionMatcher.

Recomendaciones para configurar reglas de inspección TLS

Si quieres permitir el tráfico TCP, la regla que lo permita debe tener una prioridad más alta que las reglas que permitan el tráfico HTTP.
Las reglas con el atributo ApplicationMatcher deben tener un ámbito limitado. Para ello, use el atributo SessionMatcher para minimizar la interpretación de flujos no relacionados como HTTP.
Las reglas que permiten el tráfico TLS (incluido HTTPS), pero no realizan la inspección TLS, se pueden interpretar como reglas de proxy TCP.
Para evitar la inspección TLS innecesaria del tráfico, las reglas de inspección TLS deben tener una prioridad inferior a las reglas de inspección no TLS. También puede fallar rápidamente en el caso del tráfico que no coincida. Para ello, las reglas de inspección TLS deben tener un ámbito reducido mediante el atributo SessionMatcher.

Ejemplos de configuraciones de reglas de inspección TLS

Veamos las dos reglas de los siguientes ejemplos.

Ejemplo 1

En este ejemplo, suponemos que hay otras reglas de menor prioridad. Ten en cuenta las dos reglas siguientes:

Regla 1

description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

Regla 2

description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

En este ejemplo, el proxy web seguro interpreta las dos reglas de la siguiente manera:

Permitir el tráfico TCP y denegar un tipo específico de solicitud HTTP son acciones mutuamente excluyentes, ya que el tráfico TCP puede contener una solicitud POST.
El tráfico de la regla 2 nunca se permite. Se rechaza porque el tráfico de la etiqueta 12345 a example.com se intercepta y se interpreta como HTTP para evaluar el método HTTP.
Para que la regla 2 surta efecto, puedes usar cualquiera de las siguientes soluciones:
- Recomendación: Aumenta la prioridad de la regla 2 a un nivel superior (prioridad: 5).
- Aplica la regla 1 para evitar que el tráfico permitido se solape con su atributo SessionMatcher:
  
  sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')
  
  No recomendamos esta solución porque resulta difícil mantener muchas reglas superpuestas.

Ejemplo 2

Ten en cuenta las dos reglas siguientes: