Orden de evaluación de reglas

La evaluación de reglas determina si se debe permitir o rechazar una solicitud web con las reglas que configuraste en tu política. Considera los siguientes atributos para tomar sus decisiones:

  • Prioridad de una regla: Los números enteros más bajos indican prioridades más altas.
  • SessionMatcher: Busca coincidencias con los siguientes atributos a nivel de la 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 de la máquina de destino
  • ApplicationMatcher: Busca coincidencias con los siguientes atributos de la solicitud HTTP:
    • URL
    • Ruta de acceso
    • Encabezados de la solicitud

Para obtener una lista de todos los atributos SessionMatcher y ApplicationMatcher, consulta Atributos disponibles en SessionMatcher y ApplicationMatcher.

Cómo funciona la evaluación de reglas

Las reglas se evalúan en el siguiente orden:

  1. Primero se evalúan las reglas de alta prioridad.
  2. La regla de mayor prioridad que coincide con los SessionMatcher y El atributo ApplicationMatcher determina la acción que se debe realizar el tráfico.
  3. 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.
  4. Este proceso continúa hasta que se encuentra una regla que coincida con la solicitud o hasta que se hayan evaluado todas las reglas. Si no se encuentra ninguna coincidencia, se rechaza la solicitud.

Antes de configurar la inspección de TLS

Debes comprender las siguientes situaciones de evaluación de reglas antes configurarás la inspección de TLS:

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

    Si se permite la solicitud, el tráfico HTTP se envía al destino. Sin embargo, si se rechaza la solicitud, el tráfico HTTP no podrá pasar.

  • Un cliente puede enviarle al proxy una solicitud HTTP CONNECT para establecer un túnel TCP al destino. Esto se hace cuando el cliente quiere enviar tráfico de TCP arbitrario o establecer una conexión TLS de extremo a extremo con el destino a través del proxy, como en el caso de 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 hacia el destino y el tráfico se proxy a través de 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 realizar en una solicitud, continúa la evaluación de la regla. Si la evaluación procede a una regla con un atributo ApplicationMatcher; luego, el el tráfico tunelizado se interpreta como HTTP o HTTPS.

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

    Si los datos subyacentes son HTTP, se evalúan las solicitudes, incluidas las siguientes: como el nombre de host, la identidad de la fuente, los encabezados HTTP y la ruta de acceso. En función del resultado de la evaluación, se permite o se rechaza el tráfico.

  • Para el tráfico HTTPS, una regla solo se evalúa si tiene la inspección de TLS marca habilitada; de lo contrario, se omitirá esa regla.

  • En el caso del tráfico HTTPS, se inspecciona una regla solo si se cumplen las siguientes condiciones:

    • La marca de inspección de TLS está habilitada.
    • El tráfico coincide con los atributos SessionMatcher.

Recomendaciones para configurar reglas de inspección de TLS

  • Si quieres permitir el tráfico de TCP, entonces la regla que lo permite deben tener una prioridad más alta que las reglas que permiten el tráfico HTTP.
  • Las reglas con el atributo ApplicationMatcher deben tener un alcance limitado con 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 que no realizan la inspección de TLS, se pueden interpretar como reglas de proxy de TCP.
  • Para evitar la inspección innecesaria del tráfico de TLS, debe tener menor prioridad que las reglas de inspección que no sean TLS. Por otro lado, para que fallen rápido cuando hay tráfico que no coincide, se deben aplicar tiene un alcance limitado mediante el atributo SessionMatcher.

Ejemplos de configuraciones de reglas de inspección de TLS

Considera las dos reglas de los siguientes ejemplos.

Ejemplo 1

En este ejemplo, suponemos la presencia de otras reglas de menor prioridad. Considera las siguientes dos reglas:

  • 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:

  • Permite el tráfico de TCP, pero inhabilita un tipo específico de solicitud HTTP es mutuamente excluyente porque el tráfico de TCP puede contener una solicitud POST.
  • La regla 2 nunca permite el tráfico. 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 se aplique la regla 2, puedes usar cualquiera de las siguientes soluciones:

    • Recomendación: Aumenta la prioridad de la regla 2 a un nivel más alto (prioridad: 5).

    • Establece el alcance de la regla 1 para evitar que se superponga el tráfico permitido con su atributo SessionMatcher:

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      No recomendamos esta solución porque se vuelve difícil mantienen muchas reglas superpuestas.

Ejemplo 2

Ten en cuenta las siguientes dos reglas:

  • Regla 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • Regla 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

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

  • Todo el tráfico, incluido el destinado a bankofamerica.com, se inspecciona para que TLS coincida con el request.url() de la regla de prioridad alta 1.

  • Para evitar la inspección de TLS en la regla 2, puedes usar cualquiera de las siguientes opciones soluciones:

    • Aumenta la prioridad de la regla 2 a un nivel más alto (prioridad: 5). Como resultado, la regla 2 se aplica antes de evaluar la regla 1. se permite el tráfico desde bankofamerica.com sin que se inspeccione TLS.

    • Recomendado: Limita el alcance de la regla 1 para permitir la inspección de TLS específicamente para el dominio github.com. Para reducir el alcance, agrega un atributo sessionMatcher segmentado:

      sessionMatcher: host() == 'github.com'

Limitaciones

Debes tener en cuenta estas limitaciones antes de configurar la inspección de TLS:

  • Los servidores solo se verifican con certificados raíz públicos. La raíz de autoridades certificadoras (AC) se basa en el Programa raíz de Mozilla. El comportamiento de la verificación de certificados está sujeto a cambios y corresponde a la forma en que los navegadores web verifican los certificados.

    Debido a que la verificación del backend no es posible en este momento, no se puede interceptar el tráfico a los servidores con certificados privados o autofirmados.

  • El proxy web seguro no ejecuta verificaciones de la lista de revocación de certificados (CRL).

  • Para que la inspección de TLS funcione, los clientes deben enviar el nombre del servidor Indicación (SNI, por sus siglas en inglés). SNI es una extensión de especificación de TLS opcional, pero la mayoría de los clientes la habilitan de forma predeterminada.

  • La inspección de TLS no funciona si el cliente requiere Encrypted Client Hello (ECH) (antes conocido como SNI encriptado).

    ECH es un borrador de estándar IETF que permite a los clientes encriptar el inicio del protocolo de enlace TLS con una clave de servidor preestablecida. Debido a que TLS la inspección actúa como un proxy interceptor, no tiene acceso a esa clave de servidor preestablecida. Como resultado, ECH no funciona.

  • Los clientes deben configurarse para confiar en tu certificado raíz privado.

  • Si quitas AC de tu grupo de AC privado, se procesarán certificados firmados por esa AC por un máximo de 28 horas. Para evitar el uso de los certificados almacenados en caché, puedes actualizar tu política de inspección de TLS para que apunte a un nuevo grupo de AC. Como resultado, el Proxy web seguro se ve obligado a generar certificados nuevos.