Ordine di valutazione delle regole

La valutazione delle regole determina se una richiesta web deve essere consentita o rifiutata tramite le regole che hai impostato nel criterio. Per prendere le sue decisioni, prende in considerazione i seguenti attributi:

  • Priorità di una regola: numeri interi più bassi indicano priorità più elevate.
  • SessionMatcher: corrisponde ai seguenti attributi a livello di sessione:
    • Indirizzo IP della macchina di origine
    • Account di servizio della macchina di origine
    • Tag protetto della macchina di origine
    • Nome host della macchina di destinazione
  • ApplicationMatcher: corrisponde ai seguenti attributi di 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 di priorità più elevata che corrisponde agli attributi SessionMatcher e ApplicationMatcher determina l'azione da eseguire 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 finché non vengono 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 quindi valutata utilizzando tutti i dati disponibili, inclusi nome host, identità di origine, intestazioni HTTP e percorso.

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

  • Un client può inviare al proxy una richiesta HTTP CONNECT per stabilire un tunnel TCP verso 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 nel caso di HTTPS.

  • Se una regola ha un attributo SessionMatcher corrispondente e non contiene un attributo ApplicationMatcher e la valutazione della regola determina l'autorizzazione del traffico, viene stabilito un tunnel verso la destinazione e il traffico viene inviato tramite 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 eseguire per 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, vengono valutate le richieste, inclusi nome host, identità di origine, intestazioni HTTP e percorso. In base al risultato della valutazione, il traffico è consentito o negato.

  • Per il traffico HTTPS, una regola viene valutata solo se ha abilitato il flag di ispezione TLS, 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 deve avere una priorità più elevata rispetto alle regole che consentono il traffico HTTP.
  • Le regole con l'attributo ApplicationMatcher devono avere un ambito rigoroso 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 del proxy TCP.
  • Per evitare l'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 eseguire l'errore rapido per il traffico non corrispondente, le regole di ispezione TLS devono essere limitate all'ambito utilizzando l'attributo SessionMatcher.

Esempi di configurazioni delle regole di ispezione TLS

Considera le due regole negli esempi seguenti.

Esempio 1

In questo esempio, si presuppone 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:

  • Se consenti il traffico TCP, ma non un tipo specifico di richiesta HTTP, si escludono a vicenda perché il traffico TCP può contenere una richiesta POST.
  • Il traffico nella regola 2 non è mai consentito. È 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 superiore (priorità: 5).

    • Regola di ambito 1 per evitare di sovrapporre il traffico consentito al relativo attributo SessionMatcher:

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

      Sconsigliamo di utilizzare questa soluzione perché diventa difficile mantenere 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 controllato per TLS in modo che corrisponda a request.url() della regola ad alta priorità 1.

  • 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 di valutare la regola 1 e il traffico proveniente da bankofamerica.com è consentito senza l'ispezione TLS.

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

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

Limitazioni

Devi considerare le seguenti limitazioni prima di configurare l'ispezione TLS:

  • I server vengono verificati solo utilizzando certificati radice pubblici. L'autorità di certificazione (CA) radice impostata si basa sul Mozilla Root Program. Il comportamento della verifica dei certificati è soggetto a modifiche e corrisponde al modo in cui i browser web verificano i certificati.

    Poiché al momento la verifica backend non è possibile, il traffico verso i 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 un'indicazione del nome del server (SNI). SNI è un'estensione della specifica TLS facoltativa, 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 è uno standard IETF in versione bozza che consente ai client di criptare l'inizio dell'handshake TLS utilizzando una chiave server prestabilita. Poiché l'ispezione TLS agisce come proxy di intercettazione, non ha accesso a quella chiave server prestabilita. Di conseguenza, ECH non funziona.

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

  • Se rimuovi le CA dal pool di CA privato, ti verranno forniti 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 rimandi a un nuovo pool di CA. Di conseguenza, Secure Web Proxy è costretto a generare nuovi certificati.