Questa pagina spiega le regole di sicurezza del gateway e come crearle.
Secure Web Proxy consente di definire vari tipi di regole di sicurezza all'interno delle policy di sicurezza del gateway per proteggere il traffico web in uscita. Puoi utilizzare queste regole per controllare con precisione la sicurezza del traffico utilizzando dettagli specifici delle richieste, come intestazioni e pattern URL, per assicurarti che dalla tua rete esca solo il traffico HTTP/S approvato.
Le regole di sicurezza del gateway hanno le seguenti funzionalità:
Ogni regola è un'istruzione
if-thenche controlla una richiesta web in base ai seguenti parametri:Identità di origine: chi sta effettuando la richiesta, ad esempio una macchina virtuale (VM) specifica o un service account.
Destinazione: dove viene inviata la richiesta, ad esempio un URL di destinazione o un dominio come
trusted-partner.com.Azione: la decisione di consentire o negare il traffico.
Le regole di sicurezza del gateway forniscono un controllo granulare. Queste regole ti consentono di applicare standard di sicurezza diversi nella tua organizzazione utilizzando definizioni chiare e strutturate.
Regole di corrispondenza host
Secure Web Proxy utilizza la corrispondenza del nome host per verificare il dominio di destinazione. La procedura di verifica varia a seconda di come viene implementato il proxy, come mostrato nella tabella seguente.
| Modalità di deployment | Procedura di verifica dell'host |
|---|---|
| Modalità proxy esplicito | Per il traffico non criptato, il proxy controlla il nome host rispetto all'intestazione della connessione HTTP. Se utilizzi [attributi Application Matcher](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) per l'ispezione TLS, il proxy controlla l'hostname prima a livello di connessione e poi a livello di applicazione. |
| Modalità hop successivo | Per il traffico criptato, il proxy controlla il nome host di destinazione rispetto al campo Server Name Indication (SNI) nella richiesta in uscita. Questo campo è visibile anche sulle connessioni sicure. |
Configurare le regole di corrispondenza host per la modalità proxy esplicita
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 sono 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 | Secure Web Proxy 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 (Transport Layer Security)) | 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 delle norme più ampi, come la corrispondenza dell'identità dell'origine, o attivare 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 sia 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 |
Configurare le regole di corrispondenza host per la 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 Server Name Indication (SNI).
La corrispondenza dell'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 | Secure Web Proxy 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 sia 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 |
Regole del proxy TCP
Le regole proxy Transmission Control Protocol (TCP) ti consentono di controllare il traffico
che non è traffico web standard, come HTTP (porta 80) o HTTPS (porta
443). Configurando le regole proxy TCP, puoi
consentire o bloccare il traffico su qualsiasi altra porta TCP. Queste regole ti aiutano a bloccare
il traffico dannoso e a gestire le applicazioni non web che utilizzano TCP.
Se il tuo workload (come applicazioni e servizi) utilizza Secure Web Proxy come hop successivo, l'applicazione delle regole proxy TCP è vantaggiosa. Il reindirizzamento basato su route indirizza il traffico non HTTP(S) e non web all'istanza di Secure Web Proxy. In questo modo, puoi bloccare il traffico in uscita impedendo che raggiunga siti esterni dannosi e gestire i servizi esterni a cui possono connettersi i carichi di lavoro di rete.
Configura le regole del proxy TCP
Puoi configurare regole proxy 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. Facoltativamente, puoi includere uno qualsiasi dei seguenti attributi Session Matcher per perfezionare i criteri della regola di autorizzazione o blocco.
La tabella seguente 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 |
L'argomento è l'ID permanente del tag sicuro, ad esempio
|
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, |
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à del 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 progettoREGION: la regione della policyPOLICY_NAME: il nome della policyRULE_NAME: nome della regola proxy TCP. In questo esempio, possiamo considerare il suo valore comeallow-ssh-tcp-proxy.
Considerazioni importanti
Tutte le regole proxy TCP che configuri devono avere una priorità più elevata (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
hostSession Matcher non è supportato perché le informazioni sull'host non sono disponibili nel livello TCP.Le regole proxy TCP filtrano il traffico web in base solo 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 di sicurezza
Prima di creare una regola di sicurezza del gateway, assicurati di eseguire le seguenti azioni:
Completa tutti i passaggi di configurazione iniziali.
Dopo aver creato una regola e averla associata a una policy, puoi utilizzarla quando esegui il deployment di Secure Web Proxy.
Console
Nella console Google Cloud , vai alla pagina Policy SWP.
Fai clic sul nome della policy, ad esempio
policy1.Fai clic su Aggiungi regola.
Per ogni regola, procedi nel seguente modo:
Per 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.Nel campo Nome, inserisci un nome per la regola.
Nel campo Descrizione, inserisci una descrizione della regola.
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.
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.
Nella sezione Corrispondenza sessione, specifica i criteri per la corrispondenza della sessione, ad esempio
host() == "www.wikipedia.org".Per saperne di più sulla sintassi di
SessionMatcher, consulta il riferimento al linguaggio del matcher CEL.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.
Fai clic su Aggiungi regola.
Cloud Shell
Utilizza l'editor di testo che preferisci per creare un file
rule.yaml. Per saperne di più sulla sintassi disessionMatcher, 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 progettoREGION: la regione della policyRULE_NAME: il nome della regola. In questo esempio, possiamo considerare il suo valore comeallow-wikipedia-org.
(Facoltativo) In alternativa, se vuoi creare una regola con l'ispezione TLS abilitata, crea il file
rule.yamlcome mostrato qui. Per saperne di più, consulta Panoramica dell'ispezione TLS e Attivare 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: truePer saperne di più sulla corrispondenza del traffico TCP, consulta Configura le regole proxy TCP.
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
Limitazioni
Se crei una policy di autorizzazione nella tua istanza di Secure Web Proxy, il proxy ignora tutte le policy di sicurezza del gateway esistenti e le regole di sicurezza del gateway associate.
Secure Web Proxy non supporta la possibilità di configurare regole per le applicazioni User Datagram Protocol (UDP). Secure Web Proxy blocca il traffico delle applicazioni basate su UDP.
Passaggi successivi
- Crea un'istanza di Secure Web Proxy
- Esegui il deployment di Secure Web Proxy come servizio Private Service Connect
- Esegui il deployment di Secure Web Proxy come hop successivo