Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Utilizzare mTLS frontend con Secure Web Proxy

Puoi configurare il mutual TLS (mTLS) del frontend su Secure Web Proxy per migliorare la sicurezza dei carichi di lavoro, ad esempio gli agenti AI. Secure Web Proxy utilizza l'mTLS del frontend per verificare le identità dei client tramite i certificati.

Questa integrazione ti consente di utilizzare le identità client convalidate nelle policy di autorizzazione di Secure Web Proxy per applicare un controllo dell'accesso granulare al traffico in uscita.

Come funziona

I seguenti passaggi spiegano come Secure Web Proxy utilizza l'mTLS del frontend per proteggere il traffico in uscita:

Connessione proxy esplicita: puoi configurare il client in modo che utilizzi Secure Web Proxy come proxy esplicito. Il client avvia una richiesta HTTPS CONNECT al frontend di Secure Web Proxy anziché connettersi direttamente a internet.
Handshake mutual TLS: durante la configurazione della connessione, Secure Web Proxy e il client eseguono un handshake mTLS nel frontend del proxy. Il proxy utilizza una risorsa TrustConfig configurata per convalidare il certificato del client, mentre il client convalida il certificato del server del proxy.
Estrazione dell'identità: dopo un handshake riuscito, Secure Web Proxy estrae gli attributi di identità univoci, ad esempio URI_SAN, direttamente dal certificato client convalidato.
Autorizzazione basata sull'identità: Secure Web Proxy valuta la richiesta in uscita in base alle policy di autorizzazione configurate. Per determinare se la richiesta è autorizzata, il proxy utilizza l'identità del client, che è stata verificata crittograficamente durante l'handshake mTLS.
Traffico in uscita sicuro: una volta autorizzata e se esiste una regola corrispondente per una destinazione esterna, Secure Web Proxy soddisfa la richiesta alla destinazione.

Vantaggi principali

La configurazione dell'mTLS del frontend su Secure Web Proxy offre i seguenti vantaggi operativi e di sicurezza:

Maggiore sicurezza: ottieni l'accesso Zero Trust richiedendo l'autenticazione mTLS del frontend per tutto il traffico in uscita. In questo modo, solo i carichi di lavoro con un'identità verificata possono stabilire una connessione con il proxy per accedere ai servizi esterni.
Configurazione semplificata del carico di lavoro: utilizza la modalità di routing proxy esplicito per Secure Web Proxy per sfruttare la capacità del proxy di intercettare e autenticare le richieste.
Controllo granulare: applica policy dettagliate e basate sull'identità per determinare a quali servizi esterni può accedere ogni carico di lavoro specifico.

Esempio di caso d'uso: convalida l'identità dei carichi di lavoro

Nei settori altamente conformi e regolamentati, come il settore bancario, la verifica della posizione di rete di una richiesta non è sufficiente per impedire l'accesso non autorizzato ai dati. Configurando l'mTLS del frontend su Secure Web Proxy, le organizzazioni possono passare a un modello di identità verificato crittograficamente. In questo modo, ogni carico di lavoro, che si tratti di un'istanza di macchina virtuale (VM) o di un agente AI, deve dimostrare la propria identità specifica utilizzando un certificato attendibile.

Questo approccio consente agli amministratori di applicare misure di sicurezza basate sull'identità che proteggono i percorsi in uscita sensibili. Ad esempio, una banca può assicurarsi che solo un carico di lavoro di elaborazione dei pagamenti autenticato specifico possa raggiungere un gateway finanziario esterno.

Configura l'autenticazione mTLS del frontend per Secure Web Proxy

Questa sezione descrive i passaggi per configurare l'autenticazione mTLS del frontend per l'istanza di Secure Web Proxy.

Prima di iniziare

Esamina la pagina Gestire le configurazioni di attendibilità.
Installa la Google Cloud CLI
Abilita le API richieste
Chiedi all'amministratore di Identity and Access Management di concederti i seguenti ruoli:
- Ruolo Proprietario di Certificate Manager (roles/certificatemanager.owner)
- Ruolo Compute Network Admin (roles/compute.networkAdmin)
- Ruolo Compute Security Admin (roles/compute.securityAdmin)
- Ruolo Networksecurity Admin (roles/networksecurity.admin)
Devi avere un'istanza di Secure Web Proxy di cui hai eseguito il deployment in modalità di routing proxy esplicito.

Crea i certificati radice e intermedi

Questa sezione mostra come utilizzare OpenSSL per generare un certificato dell'autorità di certificazione radice (CA) (il trust anchor) e un certificato CA intermedio facoltativo. Secure Web Proxy utilizza questi certificati per verificare i certificati client presentati dai carichi di lavoro durante la procedura di handshake mTLS del frontend. Questa procedura manuale è destinata agli ambienti di test e sviluppo per fornire il trust anchor di cui Secure Web Proxy ha bisogno per verificare i certificati client.

Un certificato radice si trova nella parte superiore della catena di certificati, mentre un certificato intermedio funge da bridge nella catena di attendibilità fino alla radice. Il certificato intermedio è firmato crittograficamente dal certificato radice. Quando Secure Web Proxy riceve un certificato client, ne convalida l'identità stabilendo una catena di attendibilità dal certificato client al trust anchor configurato.

Utilizza i seguenti comandi per creare i certificati radice e intermedi. Sebbene il certificato intermedio sia facoltativo, questa configurazione lo utilizza per firmare il certificato client per mostrare una gerarchia di certificati a più livelli.

Crea un file di configurazione OpenSSL.

cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

Crea un certificato radice X.509 autofirmato (root.cert) e una chiave privata (root.key).

openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

Crea la richiesta di firma del certificato (int.req) per il certificato intermedio.

openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

Firma la richiesta di firma del certificato (CSR) per creare il certificato intermedio X.509 (int.cert).

openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

Crea un certificato client per i test

Crea un certificato foglia e una chiave privata per il carico di lavoro del client di test. Durante la procedura di handshake mTLS con l'istanza di Secure Web Proxy, il client fornisce questo certificato foglia per dimostrare la propria identità.

L'esempio seguente utilizza OpenSSL per generare una chiave client e una CSR, quindi firma la CSR con la chiave CA intermedia che hai creato nella sezione Crea i certificati radice e intermedi certificati.

Esegui il seguente OpenSSL per generare una chiave privata RSA denominata client.key:
```
openssl genpkey -algorithm RSA -out client.key
```

Crea un file di configurazione denominato client.cnf che specifichi un nome DNS per il nome alternativo del soggetto (SAN). In questo modo, il certificato è compatibile con i moderni requisiti di sicurezza.

cat > client.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = my-client.example.com

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = my-client.example.com

EOF

Puoi modificare i valori CN e DNS.1 in base alle esigenze di test.

Esegui il comando di richiesta OpenSSL utilizzando la chiave privata e il file di configurazione creati per generare un file client.req.
```
openssl req -new -key client.key -out client.req -config client.cnf
```
Utilizza il comando OpenSSL x509 per firmare la richiesta utilizzando il certificato intermedio (int.cert) e la chiave (int.key). Imposta un periodo di validità, ad esempio 365 giorni, e assicurati che le estensioni del file di configurazione vengano applicate al file client.cert generato.
```
openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
  -set_serial 02 -days 365 -out client.cert \
  -extfile client.cnf -extensions v3_req
```
Questa procedura crea il file client.cert. Registra il valore utilizzato nel SAN DNS (ad esempio, my-client.example.com) come identità del client. Puoi utilizzare questo valore per identificare il carico di lavoro quando crei le policy di autorizzazione di Secure Web Proxy.

Formatta i certificati

Formatta i certificati radice e intermedi in variabili di ambiente da utilizzare nel file trust_config.yaml.

  export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
  export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Crea una risorsa di configurazione di attendibilità

Una configurazione di attendibilità rappresenta la tua infrastruttura a chiave pubblica (PKI) in Certificate Manager. La configurazione di attendibilità indica all'istanza di Secure Web Proxy quali certificati dell'autorità di certificazione (CA) considerare attendibili durante la verifica dei certificati client presentati durante un handshake mTLS del frontend.

Questa risorsa di configurazione di attendibilità di esempio contiene un archivio di attendibilità con un singolo archivio di attendibilità con un trust anchor (CA radice) e una CA intermedia. Utilizza i contenuti dei certificati delle variabili di ambiente create in the previous Format the certificates section.

Crea un file trust_config.yaml.

cat << EOF > trust_config.yaml
trustStores:
  TRUST_CONFIG_NAME:
    trustAnchors:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----
    intermediateCAs:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

EOF

Sostituisci TRUST_CONFIG_NAME con il nome della risorsa di configurazione di attendibilità.

Importa il file trust config.yaml utilizzando il gcloud certificate-manager trust-configs import comando.
```
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
  --source=trust_config.yaml \
  --location=LOCATION
```
Sostituisci quanto segue:
- TRUST_CONFIG_NAME: nome della risorsa di configurazione di attendibilità
- LOCATION: regione in cui è archiviata la risorsa di configurazione di attendibilità

Crea una risorsa `ServerTlsPolicy`

Una risorsa ServerTlsPolicy, nota anche come risorsa di autenticazione client, definisce il modo in cui Secure Web Proxy convalida i certificati client. Consente di specificare la modalità TLS lato server e la risorsa di configurazione di attendibilità per la verifica dei certificati.

L'attributo clientValidationMode determina la modalità di gestione della connessione quando un client fornisce un certificato non valido o nessun certificato. Per saperne di più, consulta le modalità di convalida del client mTLS del frontend .

I valori dell'attributo clientValidationMode sono i seguenti:

REJECT_INVALID: Secure Web Proxy consente solo le connessioni da client che presentano un certificato valido firmato da una CA nella configurazione di attendibilità. Le connessioni con certificati non validi o mancanti vengono rifiutate.
ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Secure Web Proxy consente la richiesta di connessione anche se il certificato client non è valido, non può essere convalidato in base alla configurazione di attendibilità o è completamente mancante.

Nota :se selezioni questa modalità, l'istanza di Secure Web Proxy estrae SPIFFE_ID e altri attributi del certificato se viene fornito un certificato valido. Tuttavia, se il certificato non è valido o è mancante, questi attributi di identità specifici non sono disponibili. Puoi comunque creare policy di autorizzazione in base alla presenza di un certificato o alla sua impronta digitale.

Per creare una risorsa ServerTlsPolicy:

Crea un file server_tls_policy.yaml. Scegli una delle seguenti opzioni per clientValidationMode:
- Opzione 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
- Opzione 2: REJECT_INVALID
```
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
```
Sostituisci quanto segue:
- SERVER_TLS_POLICY_NAME: nome della risorsa ServerTlsPolicy
- PROJECT_ID: ID deltuo Google Cloud progetto
- TRUST_CONFIG_NAME: nome della risorsa di configurazione di attendibilità
- LOCATION: regione in cui è configurata l'istanza di Secure Web Proxy
Importa la risorsa ServerTlsPolicy utilizzando il gcloud network-security server-tls-policies import comando.
```
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
  --source=server_tls_policy.yaml \
  --location=LOCATION
```
Sostituisci quanto segue:
- SERVER_TLS_POLICY_NAME: nome della risorsa ServerTlsPolicy
- LOCATION: regione in cui è configurata l'istanza di Secure Web Proxy
(Facoltativo) Per elencare tutte le risorse ServerTlsPolicies, utilizza il gcloud network-security server-tls-policies list comando.
```
gcloud network-security server-tls-policies list \
  --location=LOCATION
```
Sostituisci LOCATION con la regione in cui è configurata l'istanza di Secure Web Proxy.

Associa la risorsa `ServerTlsPolicy` all'istanza di Secure Web Proxy

Aggiungi la risorsa ServerTlsPolicy al file gateway.yaml dell'istanza di Secure Web Proxy.
```
echo "serverTlsPolicy:
//networksecurity.googleapis.com/projects/PROJECT_ID/locations/
LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
>> gateway.yaml
```
Sostituisci quanto segue:
- PROJECT_ID: ID deltuo Google Cloud progetto
- LOCATION: regione in cui è configurata l'istanza di Secure Web Proxy
Importa la configurazione dell'istanza di Secure Web Proxy dal gateway.yaml file utilizzando il gcloud network-services gateways import comando.
```
gcloud network-services gateways import GATEWAY_NAME\
    --source=gateway.yaml \
    --location=LOCATION
```
Sostituisci quanto segue:
- GATEWAY_NAME: nome dell'istanza di Secure Web Proxy
- LOCATION: regione in cui è configurata l'istanza di Secure Web Proxy

Configura le policy di autorizzazione

Per saperne di più, consulta Configurare le policy di autorizzazione per Secure Web Proxy.

Logging

Per saperne di più, consulta Gestione degli errori e logging mTLS del frontend.

Limitazioni

Secure Web Proxy supporta la configurazione dell'mTLS del frontend solo in modalità di routing proxy esplicito.
Per creare una regola di sicurezza basata sull'mTLS del frontend, utilizza authorization policies per Secure Web Proxy. Le regole delle policy di sicurezza del gateway non sono supportate.

Per saperne di più, consulta le limitazioni dell'mTLS del frontend.

Passaggi successivi

Esegui il deployment di Secure Web Proxy come servizio Private Service Connect