Orden de evaluación de reglas

La evaluación de reglas determina si se debe permitir o rechazar una solicitud web mediante las reglas que estableces en tu política. Para tomar sus decisiones, considera los siguientes atributos:

  • 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 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: Coincide con los siguientes atributos de solicitud HTTP:
    • URL
    • Ruta de acceso
    • Encabezados de la solicitud

Si deseas 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 prioridad alta.
  2. La regla de prioridad más alta que coincide con los atributos SessionMatcher y ApplicationMatcher determina la acción que se debe realizar en 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 coincide con la solicitud o hasta que se evalúan todas las reglas. Si no se encuentran coincidencias, se rechaza la solicitud.

Antes de configurar la inspección de TLS

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

  • Un cliente puede enviar una solicitud HTTP al servidor proxy. Luego, la solicitud se evalúa mediante el uso de todos los datos disponibles, incluido 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, no se permite que pase el tráfico HTTP.

  • Un cliente puede enviar 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 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 al destino y el tráfico se envía mediante proxy 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, la evaluación de la regla continúa. Si la evaluación continúa con una regla con un atributo ApplicationMatcher, el tráfico túnel 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, incluido el nombre de host, la identidad de origen, los encabezados HTTP y la ruta de acceso. Según el resultado de la evaluación, el tráfico se permite o rechaza.

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

  • En el caso del tráfico HTTPS, solo se inspecciona una regla 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 las reglas de inspección de TLS

  • Si deseas permitir el tráfico de TCP, la regla que permite el tráfico de TCP debe tener una prioridad más alta que las que permiten el tráfico HTTP.
  • Las reglas con el atributo ApplicationMatcher deben tener un alcance restringido mediante el uso del 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 una inspección de TLS, se pueden interpretar como reglas de proxy TCP.
  • Para evitar la inspección innecesaria de TLS del tráfico, las reglas de inspección de TLS deben tener una prioridad inferior a las reglas de inspección que no sean TLS. Como alternativa, para fallar rápidamente en un tráfico no coincidente, las reglas de inspección de TLS deben tener un alcance estricto mediante el atributo SessionMatcher.

Ejemplos de parámetros de configuración de reglas de inspección de TLS

Considera las dos reglas en los siguientes ejemplos.

Ejemplo 1

En este ejemplo, suponemos la presencia de otras reglas de menor prioridad. Ten en cuenta 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:

  • Permitir el tráfico de TCP, pero inhabilitar un tipo específico de solicitud HTTP es mutuamente excluyente, ya que el tráfico de TCP puede contener una solicitud POST.
  • Nunca se permite el tráfico en la regla 2. 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 entre en vigencia, puedes usar cualquiera de las siguientes soluciones:

    • Recomendado: Aumente la prioridad de la regla 2 a un nivel superior (prioridad 5).

    • Regla de permiso 1 para evitar la superposición del 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 mantener 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 que se dirige a bankofamerica.com, se inspecciona para que TLS coincida con el request.url() de la regla de alta prioridad 1.

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

    • Aumente la prioridad de la regla 2 a un nivel superior (prioridad 5). Como resultado, la regla 2 se aplica antes de evaluar la regla 1 y se permite el tráfico de bankofamerica.com sin que se inspeccione TLS.

    • Recomendado: Limita el alcance de la regla 1 para permitir la inspección de TLS específicamente en 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 mediante certificados raíz públicos. El conjunto de autoridades certificadas (CA) raíz se basa en Mozilla Root Program. 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 de 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 en la lista de revocación de certificados (CRL).

  • Para que la inspección de TLS funcione, los clientes deben enviar actualmente la indicación del nombre del servidor (SNI). La SNI es una extensión de especificación de TLS que es 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 encriptada).

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

  • Debes configurar los clientes para que confíen en tu certificado raíz privado.

  • Si quitas las AC del grupo privado de AC, recibirás certificados almacenados en caché que firma esa CA durante 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 apuntar a un nuevo grupo de AC. Como resultado, el proxy web seguro se ve forzado a generar certificados nuevos.