Configura le regole

Secure Web Proxy consente di definire vari tipi di regole all'interno dei criteri per proteggere il traffico web in uscita. Puoi utilizzare queste regole per controllare con precisione la sicurezza del tuo traffico utilizzando dettagli specifici delle richieste, come intestazioni e pattern URL, per garantire che solo il traffico HTTP/S approvato esca dalla tua rete.

Questa pagina descrive i vari tipi di regole e i passaggi per crearle e aggiungerle alla tua policy di sicurezza.

Configurare le regole di corrispondenza host

Le regole di corrispondenza host valutano il nome host di destinazione di una richiesta web in base agli elenchi di URL consentiti o negati. Controllando il dominio di destinazione, ad esempio www.example.com, queste regole assicurano che il traffico raggiunga solo siti web e servizi approvati.

Questa sezione spiega come configurare le regole di corrispondenza host per le seguenti modalità di deployment di Secure Web Proxy:

  • Modalità proxy esplicito
  • Modalità hop successivo

Modalità proxy esplicito

Quando esegui il deployment di Secure Web Proxy come proxy esplicito, configura le regole di corrispondenza host per verificare che le informazioni sull'host inviate dal client vengano estratte e controllate correttamente in base alle regole di sicurezza definite. Nella modalità proxy esplicito, i client vengono configurati attivamente per inviare il traffico direttamente all'istanza Secure Web Proxy.

La corrispondenza host nella modalità proxy esplicito funziona per diversi tipi di traffico web nel seguente modo:

Tipo di traffico Meccanismo di corrispondenza Configurazione della regola
HTTP non criptato Il proxy web sicuro controlla il nome host di destinazione rispetto al campo host nell'intestazione CONNECT standard della richiesta HTTP. Nel campo sessionMatcher, utilizza host() == "example.com".
HTTPS criptato (senza ispezione TLS) La corrispondenza host non è possibile né a livello di applicazione né a livello di sessione. Questo perché i dettagli della richiesta sono criptati e l'attributo destination.ip non è supportato. Devi utilizzare controlli dei criteri più ampi, come la corrispondenza dell'identità di origine o abilitare l'ispezione TLS per il filtro basato sull'host. Per utilizzare Application Matcher, utilizza la corrispondenza dell'identità di origine, ad esempio i service account, o attiva l'ispezione TLS.
HTTPS criptato (con ispezione TLS) Per esaminare la richiesta completa, devi utilizzare sia Session Matcher che Application Matcher. 1. Imposta una regola generale di Session Matcher che restituisca true o che corrisponda all'host di destinazione, ad esempio host() == "example.com".

2. Nel campo applicationMatcher, aggiungi una regola host specifica come request.host() == "example.com".

Modalità hop successivo

Quando esegui il deployment di Secure Web Proxy come hop successivo, devi configurare le regole di corrispondenza host. Il traffico viene reindirizzato al proxy tramite una route Virtual Private Cloud (VPC) in base agli intervalli di indirizzi IP che definisci. Le regole di corrispondenza host assicurano che il proxy identifichi correttamente l'host di destinazione controllando vari campi del traffico, ad esempio l'intestazione SNI (Server Name Indication).

La corrispondenza host nella modalità hop successivo funziona per diversi tipi di traffico web nel seguente modo:

Tipo di traffico Meccanismo di corrispondenza Configurazione della regola
HTTP non criptato Il proxy web sicuro controlla il nome host di destinazione rispetto al campo host nell'intestazione della richiesta HTTP standard. Nel campo sessionMatcher, utilizza host() == "example.com".
HTTPS criptato (senza ispezione TLS) Secure Web Proxy controlla il nome host rispetto all'intestazione SNI nella richiesta in uscita, che è visibile anche se il resto del traffico è criptato. Nel campo sessionMatcher, utilizza host() == "example.com".
HTTPS criptato (con ispezione TLS) Per esaminare la richiesta completa, devi utilizzare sia Session Matcher che Application Matcher. 1. Imposta una regola generale di Session Matcher che restituisca true o che corrisponda all'host di destinazione, ad esempio host() == "example.com".

2. Nel campo applicationMatcher, aggiungi una regola host specifica, ad esempio request.host() == "example.com".

Configura le regole del proxy TCP

Puoi configurare le regole proxy Transmission Control Protocol (TCP) per la tua applicazione per proteggere il traffico non web e applicare criteri di sicurezza per le applicazioni che non utilizzano HTTP/S standard, ad esempio per le porte 80 e 443.

Applicando queste regole, puoi impedire l'utilizzo non autorizzato di altre porte TCP per il trasferimento di dati o attività dannose. Ciò è particolarmente utile quando i tuoi carichi di lavoro utilizzano Secure Web Proxy come hop successivo per protocolli non web.

Per implementare le regole proxy TCP e creare una regola di autorizzazione o blocco del traffico per la tua applicazione, devi specificare la porta di destinazione. Se vuoi, puoi includere uno qualsiasi dei seguenti attributi di Session Matcher per perfezionare i criteri della regola di autorizzazione o blocco.

La seguente tabella fornisce ulteriori informazioni sui vari attributi che puoi utilizzare in una regola proxy TCP:

Attributo Tipo di attributo Descrizione
source.ip string L'indirizzo IP del client che ha inviato la richiesta.
source.port string Porta client che ha inviato la richiesta.
destination.port string Porta upstream a cui l'istanza di Secure Web Proxy invia il traffico.
source.matchTag(SECURE_TAG) boolean

True, se la fonte è associata a SECURE_TAG.

L'argomento è l'ID permanente del tag sicuro, ad esempio source.matchTag('tagValues/123456').
source.matchServiceAccount(SERVICE_ACCOUNT) boolean True, se la fonte è associata a SERVICE_ACCOUNT, ad esempio source.matchServiceAccount('x@my-project.iam.gserviceaccount.com').
inIpRange(IP_ADDRESS,
IP_RANGE)		 boolean True, se IP_ADDRESS è contenuto in IP_RANGE, ad esempio inIpRange(source.ip, '1.2.3.0/24'). Le subnet mask per gli indirizzi IPv6 non possono superare `/64`.

Esempio di regola proxy TCP

Questo esempio mostra come definire un proxy web sicuro gatewaySecurityPolicyRule utilizzando un'espressione CEL per consentire tutto il traffico TCP alla porta 22. Puoi utilizzare questa configurazione quando applichi le funzionalità proxy TCP di Secure Web Proxy.

Il seguente esempio di codice mostra come definire una regola proxy TCP:

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • REGION: la regione della policy
  • POLICY_NAME: il nome della policy
  • RULE_NAME: nome della regola proxy TCP. In questo esempio, possiamo considerare il suo valore come allow-ssh-tcp-proxy.

Considerazioni importanti

  • Tutte le regole proxy TCP che configuri devono avere una priorità più alta (numero inferiore) rispetto alle regole HTTP/S per garantire che vengano valutate e applicate per prime. Per saperne di più, consulta Ordine di valutazione delle regole.

  • Quando configuri le regole proxy TCP, l'attributo host Session Matcher non è supportato perché le informazioni sull'host non sono disponibili nel livello TCP.

  • Le regole proxy TCP filtrano il traffico web solo in base alla porta di destinazione. Per migliorare la sicurezza della tua rete, ti consigliamo di aggiungere altre condizioni utilizzando gli operatori logici AND (&&) e OR (||) e gli attributi supportati come source.ip. Ecco un esempio di come definire una regola proxy TCP più specifica:

      // Allow port 22 from only a specific source IP range
  sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"

  • Secure Web Proxy non supporta la possibilità di configurare regole proxy per le applicazioni User Datagram Protocol (UDP). Di conseguenza, Secure Web Proxy blocca il traffico delle applicazioni basate su UDP.

Crea una regola Secure Web Proxy

Questa sezione spiega come creare una regola Secure Web Proxy.

Prima di creare una regola, assicurati di eseguire le seguenti azioni:

  1. Completa tutti i passaggi di configurazione iniziali.

  2. Crea una policy

Dopo aver creato una regola e averla associata a una policy, puoi utilizzarla quando esegui il deployment di Secure Web Proxy.

Console

  1. Nella console Google Cloud , vai alla pagina Policy SWP.

    Vai alle policy SWP

  2. Fai clic sul nome della policy, ad esempio policy1.

  3. Fai clic su Aggiungi regola.

  4. Per ogni regola, procedi nel seguente modo:

    1. In Priorità, inserisci un ordine di valutazione numerico per la regola. Le regole vengono valutate dalla priorità più alta a quella più bassa, dove 0 è la priorità più alta.

    2. Nel campo Nome, inserisci un nome per la regola.

    3. Nel campo Descrizione, inserisci una descrizione della regola.

    4. Per Azione, seleziona una delle seguenti opzioni:

      • Consenti: per consentire le richieste di connessione che corrispondono alla regola.
      • Nega: per negare le richieste di connessione che corrispondono alla regola.

    5. Per il campo Stato, seleziona una delle seguenti opzioni per l'applicazione della regola:

      • Attivato: per applicare la regola all'istanza di Secure Web Proxy.
      • Disattivato: per non applicare la regola all'istanza di Secure Web Proxy.

    6. Nella sezione Corrispondenza sessione, specifica i criteri per la corrispondenza della sessione, ad esempio host() == "www.wikipedia.org".

      Per maggiori informazioni sulla sintassi di SessionMatcher, consulta il riferimento al linguaggio del matcher CEL.

    7. Nella sezione Corrispondenza applicazione, specifica i criteri per la corrispondenza della richiesta.

      Per saperne di più sulla corrispondenza del traffico TCP, consulta Configura le regole proxy TCP.

    8. Fai clic su Aggiungi regola.

Cloud Shell

  1. Crea il file rule.yaml come mostrato qui. Per saperne di più sulla sintassi di sessionMatcher, consulta il riferimento al linguaggio del matcher CEL.

    name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
description: Allow wikipedia.org
enabled: true
priority: 1
basicProfile: ALLOW
sessionMatcher: host() == 'www.wikipedia.org'

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto
    • REGION: la regione della policy
    • RULE_NAME: il nome della regola. In questo esempio, possiamo considerare il suo valore come allow-wikipedia-org.

  2. (Facoltativo) In alternativa, se vuoi creare una regola con l'ispezione TLS abilitata, crea il file rule.yaml come mostrato qui. Per ulteriori informazioni, consulta Panoramica dell'ispezione TLS e Abilitare l'ispezione TLS.

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
  description: Allow wikipedia.org
  enabled: true
  priority: 1
  basicProfile: ALLOW
  sessionMatcher: host() == 'www.wikipedia.org'
  applicationMatcher: request.path.contains('index.html')
  tlsInspectionEnabled: true

    Per saperne di più sulla corrispondenza del traffico TCP, consulta Configura le regole proxy TCP.

  3. Crea la regola della policy di sicurezza. 

    gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
    --source=rule.yaml \
    --location=REGION \
    --gateway-security-policy=policy1

Passaggi successivi