Ordine di valutazione delle regole

La valutazione delle regole determina se una richiesta web deve essere consentita o negata utilizzando le regole impostate nel criterio. Per prendere le sue decisioni, prende in considerazione i seguenti attributi:

  • Priorità di una regola:i numeri interi più bassi indicano priorità più elevate.
  • SessionMatcher: corrisponde ai seguenti attributi a livello di sessione:
    • Indirizzo IP della macchina di origine
    • Service account della macchina di origine
    • Tag sicuro della macchina di origine
    • Nome host della macchina di destinazione
  • ApplicationMatcher: corrisponde ai seguenti attributi della richiesta HTTP:
    • URL
    • Percorso
    • Intestazioni delle richieste

Per un elenco di tutti gli attributi SessionMatcher e ApplicationMatcher, consulta Attributi disponibili in SessionMatcher e ApplicationMatcher.

Come funziona la valutazione delle regole

Le regole vengono valutate nel seguente ordine:

  1. Le regole con priorità elevata vengono valutate per prime.
  2. La regola con la priorità più alta che corrisponde agli attributi SessionMatcher e ApplicationMatcher determina l'azione da intraprendere sul traffico.
  3. Se la richiesta non corrisponde agli attributi SessionMatcher e ApplicationMatcher della regola, viene valutata la regola successiva con la priorità più alta.
  4. Questo processo continua fino a quando non viene trovata una regola che corrisponde alla richiesta o fino a quando non sono state valutate tutte le regole. Se non viene trovata alcuna corrispondenza, la richiesta viene rifiutata.

Prima di configurare l'ispezione TLS

Devi comprendere i seguenti scenari di valutazione delle regole prima di configurare l'ispezione TLS:

  • Un client può inviare una richiesta HTTP al server proxy. La richiesta viene poi valutata utilizzando tutti i dati disponibili, tra cui il nome host, l'identità di origine, le intestazioni HTTP e il percorso.

    Se la richiesta è consentita, il traffico HTTP viene inviato alla destinazione. Tuttavia, se la richiesta viene rifiutata, il traffico HTTP non può passare.

  • Un client può inviare al proxy una richiesta HTTP CONNECT per stabilire un tunnel TCP con la destinazione. Questo viene fatto quando il client vuole inviare traffico TCP arbitrario o stabilire una connessione TLS end-to-end con la destinazione tramite il proxy, come con HTTPS.

  • Se una regola ha un attributo SessionMatcher corrispondente e non contiene un attributo ApplicationMatcher e la valutazione della regola comporta l'autorizzazione del traffico, viene stabilito un tunnel per la destinazione e il traffico viene sottoposto a proxy TCP. Questo vale per il traffico HTTPS e TCP.

  • Se le regole con priorità più elevata non sono in grado di determinare l'azione da intraprendere su una richiesta, la valutazione delle regole continua. Se la valutazione procede a una regola con un attributo ApplicationMatcher, il traffico in tunnel viene interpretato come HTTP o HTTPS.

    Se i dati sottostanti non sono HTTP o HTTPS, la connessione non va a buon fine.

    Se i dati sottostanti sono HTTP, vengono valutate le richieste, inclusi il nome host, l'identità di origine, le intestazioni HTTP e il percorso. In base al risultato della valutazione, il traffico viene consentito o negato.

  • Per il traffico HTTPS, una regola viene valutata solo se è attivato il flag di ispezione TLS. In caso contrario, la regola viene ignorata.

  • Per il traffico HTTPS, una regola viene ispezionata solo se le seguenti condizioni sono vere:

    • Il flag di ispezione TLS è attivato.
    • Il traffico corrisponde agli attributi SessionMatcher.

Consigli per la configurazione delle regole di ispezione TLS

  • Se vuoi consentire il traffico TCP, la regola che lo consente deve avere una priorità superiore rispetto alle regole che consentono il traffico HTTP.
  • Le regole con l'attributo ApplicationMatcher devono avere un ambito limitato utilizzando l'attributo SessionMatcher per ridurre al minimo l'interpretazione di flussi non correlati come HTTP.
  • Le regole che consentono il traffico TLS (incluso HTTPS), ma non eseguono l'ispezione TLS, possono essere interpretate come regole proxy TCP.
  • Per evitare un'ispezione TLS non necessaria del traffico, le regole di ispezione TLS devono avere una priorità inferiore rispetto alle regole di ispezione non TLS. In alternativa, per fallire rapidamente per il traffico non corrispondente, le regole di ispezione TLS devono avere un ambito limitato utilizzando l'attributo SessionMatcher.

Esempi di configurazioni delle regole di ispezione TLS

Considera le due regole negli esempi seguenti.

Esempio 1

In questo esempio, assumiamo la presenza di altre regole con priorità inferiore. Considera le due regole seguenti:

  • Regola 1

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

  • Regola 2

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

In questo esempio, Secure Web Proxy interpreta le due regole come segue:

  • Consentire il traffico TCP, ma non un tipo specifico di richiesta HTTP, è mutuamente esclusivo perché il traffico TCP può contenere una richiesta POST.
  • Il traffico nella regola 2 non è mai consentito. Viene negato perché il traffico dal tag 12345 a example.com viene intercettato e interpretato come HTTP per valutare il metodo HTTP.

  • Per applicare la regola 2, puoi utilizzare una delle seguenti soluzioni:

    • Consigliato: aumenta la priorità della regola 2 a un livello superiore (priorità: 5).

    • Regola di ambito 1 per evitare l'accavallamento del traffico consentito con il relativo attributo SessionMatcher:

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

      Questa soluzione non è consigliata perché diventa difficile gestire molte regole sovrapposte.

Esempio 2

Considera le due regole seguenti:

  • Regola 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')

  • Regola 2

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

In questo esempio, Secure Web Proxy interpreta le due regole come segue:

  • Tutto il traffico, incluso quello destinato a bankofamerica.com, viene sottoposto a ispezione per verificare che TLS corrisponda a request.url() della regola 1 con priorità elevata.

  • Per evitare l'ispezione TLS nella regola 2, puoi utilizzare una delle seguenti soluzioni:

    • Aumenta la priorità della regola 2 a un livello superiore (priorità: 5). Di conseguenza, la regola 2 viene applicata prima della valutazione della regola 1 e il traffico da bankofamerica.com è consentito senza essere sottoposto a ispezione TLS.

    • Consigliato: restringi l'ambito della regola 1 per consentire l'ispezione TLS specificamente per il dominio github.com. Per restringere l'ambito, aggiungi un attributo sessionMatcher scelto come target:

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

Limitazioni

Devi prendere in considerazione queste limitazioni prima di configurare l'ispezione TLS:

  • I server vengono verificati solo utilizzando certificati radice pubblici. L'insieme di autorità di certificazione (CA) radice si basa sul Mozilla Root Program. Il comportamento della verifica del certificato è soggetto a modifiche e corrisponde alla modalità di verifica dei certificati da parte dei browser web.

    Poiché al momento non è possibile la verifica del backend, non è possibile intercettare il traffico verso i server con certificati privati o autofirmati.

  • Secure Web Proxy non esegue controlli dell'elenco revoche certificati (CRL).

  • Affinché l'ispezione TLS funzioni, al momento i client devono inviare Server Name Indication (SNI). SNI è un'estensione facoltativa della specifica TLS, ma la maggior parte dei client la abilita per impostazione predefinita.

  • L'ispezione TLS non funziona se il client richiede Encrypted Client Hello (ECH) (in precedenza noto come SNI criptato).

    ECH è una bozza di standard IETF che consente ai client di criptare l'inizio dell'handshake TLS utilizzando una chiave del server predefinita. Poiché l'ispezione TLS agisce come proxy di intercettazione, non ha accesso alla chiave del server predefinita. Di conseguenza, ECH non funziona.

  • I client devono essere configurati in modo da considerare attendibile il certificato radice privato.

  • Se rimuovi le CA dal tuo pool di CA private, vengono pubblicati i certificati memorizzati nella cache firmati dalla CA per un massimo di 28 ore. Per impedire l'utilizzo dei certificati memorizzati nella cache, puoi aggiornare il criterio di ispezione TLS in modo che punti a un nuovo pool di CA. Di conseguenza, Secure Web Proxy è costretto a generare nuovi certificati.