Ordine di valutazione delle regole

La valutazione delle regole determina se una richiesta web deve essere consentita o rifiutata dal utilizzando le regole che hai impostato 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: crea corrispondenze in base ai seguenti attributi di richieste HTTP:
    • URL
    • Percorso
    • Intestazioni delle richieste

Per un elenco di tutti gli attributi SessionMatcher e ApplicationMatcher, vedi 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 a SessionMatcher e ApplicationMatcher di quella 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 CONNECT HTTP per stabilire un TCP tunneling alla 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 della regola 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 riesce.

    Se i dati sottostanti sono HTTP, le richieste vengono valutate, includendo nome host, identità di origine, intestazioni HTTP e percorso. In base ai risultato della valutazione, il traffico è consentito o negato.

  • Per il traffico HTTPS, una regola viene valutata solo se include l'ispezione TLS flag abilitato; altrimenti la regola viene ignorata.

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

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

Suggerimenti per la configurazione delle regole di ispezione TLS

  • Se vuoi consentire il traffico TCP, la regola che consente il traffico TCP devono avere una priorità maggiore 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.
  • Regole che consentono il traffico TLS (incluso HTTPS) ma non eseguono TLS l'ispezione può essere interpretata come regole del 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.

  • Affinché la regola 2 abbia effetto, puoi utilizzare una delle seguenti soluzioni:

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

    • Regola di ambito 1 per evitare di sovrapporre il traffico consentito con la relativa 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.

    • Opzione consigliata: restringi l'ambito della regola 1 per consentire l'ispezione TLS in particolare per il dominio github.com. Per restringere l'ambito, aggiungi un attributo sessionMatcher target:

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

Limitazioni

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

  • I server vengono verificati solo mediante 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. corrisponde alla modalità di verifica dei certificati da parte dei browser web.

    Poiché al momento non è possibile eseguire la verifica del backend, il traffico verso server con certificati privati o autofirmati non può essere intercettato.

  • Secure Web Proxy non esegue i controlli degli elenchi di revoche dei certificati (CRL).

  • Affinché l'ispezione TLS funzioni, i client devono attualmente inviare il nome server Indicazione (SNI). SNI è un'estensione della specifica TLS facoltativa, ma la maggior parte dei client lo abilita per impostazione predefinita.

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

    ECH è uno standard bozza di IETF che consente ai client di criptare l'inizio dell'handshake TLS mediante una chiave server prestabilita. 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 tuo certificato radice privato.

  • Se rimuovi le CA dal pool di CA privato, l'accesso verrà gestito nella cache certificati firmati dalla CA per un massimo di 28 ore. Per impedire l'utilizzo per i certificati memorizzati nella cache, puoi aggiornare il criterio di ispezione TLS puntano a un nuovo pool di CA. Di conseguenza, Secure Web Proxy è costretto a generare nuovi certificati.