Panoramica delle policy di autorizzazione

I criteri di autorizzazione ti consentono di stabilire controlli dell'controllo dell'accesso e controlli di sanificazione dei contenuti durante l'elaborazione di richieste o risposte tramite diversi serviziGoogle Cloud , come Bilanciatore del carico delle applicazioni, Agent Gateway e Secure Web Proxy.

Per Agent Gateway e Secure Web Proxy, la policy di autorizzazione è collegata direttamente alla risorsa gateway di questi servizi. Per un bilanciatore del carico, la policy di autorizzazione è collegata alla risorsa regola di forwarding del bilanciatore del carico.

Nota: sebbene alcune parti di questo documento si concentrino sulle policy di autorizzazione in relazione a Cloud Load Balancing, i concetti di policy di autorizzazione discussi qui si applicano a tutti i servizi Google Cloud menzionati in precedenza.

Una policy di autorizzazione (AuthzPolicy), collegata alla regola di forwarding di un bilanciatore del carico, ti consente di specificare le condizioni che consentono, limitano o delegano l'autorizzazione delle richieste in base alla loro origine e alle operazioni previste. Le richieste che superano questi controlli vengono indirizzate al servizio di backend del bilanciatore del carico, mentre le richieste che non superano questi controlli vengono rifiutate con una risposta non autorizzata.

Puoi configurare i criteri di autorizzazione nella regola di forwarding di tutti i bilanciatori del carico delle applicazioni con uno schema di bilanciamento del carico EXTERNAL_MANAGED o INTERNAL_MANAGED. I seguenti bilanciatori del carico delle applicazioni supportano le policy di autorizzazione:

• Bilanciatori del carico delle applicazioni esterni regionali
• Bilanciatori del carico delle applicazioni interni regionali

Regole delle policy di autorizzazione

Una policy di autorizzazione è costituita da un elenco di regole HTTP da confrontare con la richiesta in arrivo.

Per una policy di autorizzazione con un'azione ALLOW o DENY, una regola HTTP (AuthzRule) definisce le condizioni che determinano se il traffico può passare attraverso il bilanciatore del carico. È richiesta almeno una regola HTTP.

Per un criterio di autorizzazione con un'azione CUSTOM, una regola HTTP (AuthzRule) definisce le condizioni che determinano se il traffico viene delegato al provider personalizzato per l'autorizzazione. È necessario un provider personalizzato, mentre le regole HTTP sono facoltative.

Una corrispondenza con i criteri si verifica quando almeno una regola HTTP corrisponde alla richiesta o quando non sono definite regole HTTP nei criteri.

Una regola HTTP di una policy di autorizzazione è costituita dai seguenti campi:

• from: specifica l'identità del client consentita dalla regola. L'identità può essere derivata da un certificato client in una connessione mutual TLS oppure può essere l'identità ambientale associata all'istanza di macchina virtuale (VM) client, ad esempio da un account di servizio o un tag sicuro.
• to: specifica le operazioni consentite dalla regola, ad esempio gli URL a cui è possibile accedere o i metodi HTTP consentiti.
• when: specifica vincoli aggiuntivi che devono essere soddisfatti. Puoi utilizzare le espressioni Common Expression Language (CEL) per definire i vincoli.

Azioni delle policy di autorizzazione

Quando valuta una richiesta, una policy di autorizzazione specifica l'azione (AuthzAction) da applicare alla richiesta. Una policy di autorizzazione deve avere almeno un'azione, che può essere una delle seguenti:

• ALLOW: consente alla richiesta di passare al backend se corrisponde a una delle regole specificate in una policy ALLOW. Se esistono policy ALLOW, ma non c'è corrispondenza, la richiesta viene rifiutata. In altre parole, la richiesta viene negata se nessuna delle policy di autorizzazione configurate con un'azione ALLOW corrisponde alla richiesta. In Cloud Logging, questa azione viene registrata come denied_as_no_allow_policies_matched_request.

  Affinché venga applicata un'azione ALLOW, è necessaria almeno una regola HTTP.

• DENY: nega la richiesta se corrisponde a una delle regole specificate in una policy DENY. Se esistono policy DENY, ma non c'è corrispondenza, la richiesta viene consentita. In altre parole, la richiesta è consentita se nessuna delle policy di autorizzazione configurate con un'azione DENY corrisponde alla richiesta. In Cloud Logging, questa azione viene registrata come allowed_as_no_deny_policies_matched_request.

  Per applicare un'azione DENY, è necessaria almeno una regola HTTP.

• CUSTOM: delega la decisione di autorizzazione a un fornitore di autorizzazione personalizzato, ad esempio IAP o estensioni di servizio. Per saperne di più, consulta Delegare le decisioni di autorizzazione.

  Se sono configurate regole HTTP per un criterio CUSTOM, la richiesta deve corrispondere alle regole HTTP per richiamare il provider personalizzato. Tuttavia, se non sono definite regole HTTP, la policy di autorizzazione delega sempre la decisione di autorizzazione a un provider di autorizzazione personalizzato. Per saperne di più, consulta gli esempi in Policy di autorizzazione per delegare le decisioni di autorizzazione.

Ordine di valutazione delle policy di autorizzazione

Una policy di autorizzazione supporta le policy CUSTOM, DENY e ALLOW per controllo dell'accesso#39;accesso. Quando più policy di autorizzazione sono associate a una singola risorsa, viene valutata prima la policy CUSTOM, poi la policy DENY e infine la policy ALLOW. La valutazione è determinata dalle seguenti regole:

1. Se esiste una policy CUSTOM che corrisponde alla richiesta, la policy CUSTOM viene valutata utilizzando un provider di autorizzazione personalizzato. Se il fornitore personalizzato rifiuta la richiesta, questa viene negata. Le norme DENY o ALLOW non vengono valutate, anche se sono configurate.

2. Se esistono policy DENY che corrispondono alla richiesta, quest'ultima viene rifiutata. Le eventuali policy ALLOW non vengono valutate, anche se sono configurate.

3. Se non esistono policy ALLOW, la richiesta viene consentita.

4. Se una delle policy ALLOW corrisponde alla richiesta, consenti la richiesta.

5. Se esistono policy ALLOW, ma non c'è corrispondenza, la richiesta viene rifiutata. In altre parole, la richiesta viene rifiutata per impostazione predefinita se nessuna delle AuthzPolicies configurate con l'azione ALLOW corrisponde alla richiesta.

Per i bilanciatori del carico delle applicazioni esterni regionali, i bilanciatori del carico delle applicazioni interni regionali, Agent Gateway e Secure Web Proxy, ovvero i servizi che supportano i profili dei criteri, l'ordine di valutazione dei criteri di autorizzazione è il seguente:Google Cloud

1. Se esiste una policy di autorizzazione delle richieste personalizzata (REQUEST_AUTHZ) che corrisponde alla richiesta, la policy REQUEST_AUTHZ viene valutata utilizzando un provider di autorizzazione personalizzato. Se il fornitore personalizzato rifiuta la richiesta, questa viene negata. Le norme DENY, ALLOW e CONTENT_AUTHZ non vengono valutate, anche se sono configurate.

2. Se esistono policy DENY che corrispondono alla richiesta, quest'ultima viene rifiutata. I criteri ALLOW e CONTENT_AUTHZ non vengono valutati, anche se sono configurati.

3. Se non esistono policy ALLOW, la richiesta procede alla valutazione dell'autorizzazione dei contenuti (CONTENT_AUTHZ).

4. Se una delle policy ALLOW corrisponde alla richiesta, la richiesta procede alla valutazione CONTENT_AUTHZ.

5. Se esistono policy ALLOW, ma non c'è corrispondenza, la richiesta viene rifiutata. Le policy CONTENT_AUTHZ non vengono valutate.

6. Se esiste una policy CONTENT_AUTHZ che corrisponde alla richiesta, viene valutata per ultima. Se il fornitore personalizzato rifiuta la richiesta, questa viene negata.

Profili delle policy nelle policy di autorizzazione

Anteprima

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

I profili delle policy nelle policy di autorizzazione sono supportati per i seguenti servizi Google Cloud :

• Bilanciatori del carico delle applicazioni esterni regionali
• Bilanciatori del carico delle applicazioni interni regionali
• Agent Gateway
• Secure Web Proxy

Un profilo della policy (PolicyProfile) in una policy di autorizzazione è di uno dei seguenti tipi:

• Profilo di autorizzazione della richiesta (REQUEST_AUTHZ): si basa sulle informazioni contenute nelle intestazioni delle richieste HTTP per consentire o negare il traffico.
• Profilo di autorizzazione dei contenuti (CONTENT_AUTHZ): fornisce sicurezza e filtraggio basati sui contenuti per bloccare gli attacchi di prompt injection, prevenire la fuga di dati sensibili e filtrare i contenuti dannosi.

Puoi configurare una policy di autorizzazione con un profilo REQUEST_AUTHZ o un profilo CONTENT_AUTHZ, ma non entrambi. Se non viene specificato un profilo dei criteri, i criteri di autorizzazione utilizzano per impostazione predefinita il profilo REQUEST_AUTHZ.

Richiedere il profilo di autorizzazione

Le policy di autorizzazione che utilizzano il profilo delle policy REQUEST_AUTHZ possono valutare le decisioni di accesso per il traffico in entrata direttamente o delegarle. Puoi delegare le decisioni di accesso a Identity-Aware Proxy o a un motore di autorizzazione personalizzato utilizzando un'estensione di autorizzazione. Il profilo delle norme REQUEST_AUTHZ agisce in base alle informazioni contenute nelle intestazioni delle richieste HTTP per consentire o negare una richiesta.

Una policy di autorizzazione con il profilo della policy REQUEST_AUTHZ può avere un'azione ALLOW, DENY o CUSTOM applicata alla richiesta. Un'azione di ALLOW o DENY indica che la decisione di accesso viene valutata direttamente, mentre un'azione CUSTOM indica che la decisione di accesso è delegata.

Quando la decisione di accesso viene delegata, un criterio di autorizzazione configurato nella regola di forwarding del bilanciatore del carico punta a un'estensione di autorizzazione delle richieste che viene eseguita su un servizio di backend di callout. Per ogni richiesta di autorizzazione, il bilanciatore del carico inoltra le intestazioni della richiesta all'estensione di autorizzazione utilizzando il protocollo ext_proc o ext_authz di Envoy. A seconda della risposta dell'estensione, il proxy del bilanciatore del carico inoltra la richiesta al servizio di backend o la rifiuta.

Se non viene specificato un profilo di policy, la policy di autorizzazione utilizza per impostazione predefinita il profilo di autorizzazione delle richieste (REQUEST_AUTHZ).

Profilo di autorizzazione dei contenuti

I criteri di autorizzazione che utilizzano il profilo dei criteri CONTENT_AUTHZ possono essere utilizzati per eseguire un'ispezione approfondita dei payload delle applicazioni per consentire o negare le richieste o modificare le richieste o le risposte, se necessario. Puoi delegare le decisioni di accesso a Model Armor o alla tua estensione di sanificazione dei contenuti.

Una policy di autorizzazione con il profilo policy CONTENT_AUTHZ può avere solo un'azione CUSTOM applicata alla richiesta. Ciò significa che la richiesta non può essere valutata direttamente e deve essere delegata.

Una policy di autorizzazione, configurata nella regola di forwarding del bilanciatore del carico, punta a un'estensione di autorizzazione dei contenuti. Per ogni richiesta di autorizzazione, il bilanciatore del carico inoltra l'intero contenuto della richiesta e della risposta, inclusi intestazioni, corpo e trailer, utilizzando il protocollo ext_proc di Envoy in modalità di streaming full duplex (FULL_DUPLEX_STREAMED), all'estensione di autorizzazione dei contenuti. A seconda della risposta dell'estensione, il proxy del bilanciatore del carico inoltra la richiesta alla destinazione o la rifiuta. La destinazione, nel caso di una richiesta, è il servizio di backend del bilanciatore del carico e, nel caso di una risposta, è il client.

Policy di autorizzazione basata sui principal

Per identificare l'origine del traffico con un'elevata granularità, puoi configurare norme di autorizzazione basate su identità derivate dal certificato di un client. Questo metodo richiede l'attivazione di mTLS frontend sul bilanciatore del carico e utilizza i seguenti attributi del certificato come selettore principale per l'identificazione:

• SAN URI del certificato client (CLIENT_CERT_URI_SAN)
• SAN (Subject Alternative Name) del nome DNS del certificato client (CLIENT_CERT_DNS_NAME_SAN)
• Nome comune del certificato client (CLIENT_CERT_COMMON_NAME)

Se non viene specificato alcun selettore principale per l'identificazione, CLIENT_CERT_URI_SAN viene utilizzato come selettore principale predefinito. Ciò significa che i SAN URI del certificato client vengono valutati al momento di prendere decisioni di autorizzazione.

Affinché l'autorizzazione basata sull'entità funzioni, devono essere soddisfatte le seguenti condizioni:

• mTLS frontend deve essere abilitato. Se mTLS frontend non è attivato, il client non presenta un certificato. Di conseguenza, nessuna regola basata sulle entità nella policy di autorizzazione trova informazioni sui certificati da valutare. Ad esempio, una regola che controlla CLIENT_CERT_URI_SAN rileva un valore vuoto.

• Deve essere presente un certificato client valido. Anche con mTLS abilitato, un certificato client non viene utilizzato per l'autorizzazione se la connessione è stata stabilita con un certificato mancante o non valido. Questo scenario si verifica quando la modalità di convalida client mTLS è impostata sulla modalità permissiva ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Anche in questo caso, le regole basate sui principal nella policy di autorizzazione non trovano informazioni sui certificati da valutare. Ad esempio, una regola che controlla CLIENT_CERT_URI_SAN rileva un valore vuoto.

Impatto dei limiti di dimensione degli attributi

Le decisioni di autorizzazione sono sensibili alle dimensioni degli attributi del certificato client. Una richiesta viene rifiutata se un attributo supera il limite di dimensioni e il criterio è configurato per convalidare quell'attributo specifico.

Un rifiuto può verificarsi nelle seguenti condizioni:

• Il criterio viene convalidato in base a CLIENT_CERT_URI_SAN e i SAN URI del certificato superano il limite di dimensioni.
• Il criterio viene convalidato in base a CLIENT_CERT_DNS_NAME_SAN e i SAN del nome DNS del certificato superano il limite di dimensioni.
• La norma viene convalidata rispetto a CLIENT_CERT_COMMON_NAME e il soggetto del certificato (che contiene il nome comune) supera il limite di dimensioni.

Se l'attributo di un certificato supera il limite di dimensioni, ma non è convalidato in modo esplicito dal selettore dei principal delle norme, la richiesta viene comunque valutata in base alle regole dei principal configurate. Ad esempio, se un criterio è configurato per convalidare solo CLIENT_CERT_DNS_NAME_SAN, una richiesta da un client con SAN URI sovradimensionati non viene rifiutata per questo motivo. La policy procede valutando la richiesta in base ai SAN del nome DNS.

Per visualizzare un esempio di policy di autorizzazione basata sulle entità, consulta Policy di autorizzazione per negare le richieste.

Policy di autorizzazione basata su service account o tag sicuri

Una policy di autorizzazione basata su service account o tag sicuri è supportata per i seguenti bilanciatori del carico:

• Bilanciatori del carico delle applicazioni interni regionali
• Bilanciatori del carico delle applicazioni interni tra regioni

Nota: l'applicazione di policy di autorizzazione basate su service account o tag non è supportata per i bilanciatori del carico delle applicazioni esterni.

Le policy di autorizzazione, basate su service account e tag sicuri, consentono di applicare regole di sicurezza in base a chi o cosa invia il traffico, anziché solo all'indirizzo IP. Ciò comporta il passaggio da regole basate su IP a controlli basati sull'identità utilizzando account di servizio e tag sicuri per definire il perimetro di sicurezza. Ad esempio, puoi creare una policy di autorizzazione per:

• nega a una VM Compute Engine con un account di servizio specifico (my-sa-123@PROJECT_ID.) di raggiungere il percorso /api/payments.

• consenti alle VM Compute Engine con un tag sicuro (coppia chiave-valore environment: prod) di raggiungere il percorso /api/payments.

Puoi applicare policy di autorizzazione in base ai service account o ai tag sicuri collegati a vari servizi Google Cloud . Il traffico proveniente da questi servizi Google Cloud , collegati a unaccount di serviziont specifico o a un tag sicuro, può essere consentito, negato o delegato per un'ulteriore valutazione.

La tabella seguente elenca i vari Google Cloud servizi che supportano l'utilizzo di service account e tag sicuri.

ServizioGoogle Cloud	Assistenza per il service account	Supporto dei tag protetti
Macchina virtuale (VM) Compute Engine
Nodo Google Kubernetes Engine (GKE)
Contenitore Google Kubernetes Engine (GKE)	^1	^1
Cloud VPN	^1	^1
Cloud Interconnect on-premise	^1	^1
Bilanciatore del carico delle applicazioni	^3	^3
Bilanciatore del carico di rete	^3	^3

¹ Non supportato da Google Cloud.

³ I service account e i tag non sono supportati quando i bilanciatori del carico delle applicazioni e i bilanciatori del carico di rete fungono da origini di traffico in un'architettura a più livelli.

La tabella seguente elenca le diverse architetture Virtual Private Cloud (VPC) che supportano l'utilizzo di account di servizio e tag.

VPC	Architettura VPC	Assistenza
All'interno di VPC	Tra progetti (VPC condiviso)
All'interno di VPC	Interregionale
Cross VPC	Link di peering incrociato (VPC peer)
Cross VPC	Private Service Connect cross-project
Cross VPC	Spoke di Network Connectivity Center cross-network

Per scoprire di più su come configurare un criterio di autorizzazione basato su service account e tag collegati a una risorsa Google Cloud , consulta Criterio di autorizzazione basato su service account o tag.

Quote

Per informazioni sulle quote per le policy di autorizzazione, consulta Quote e limiti per le policy di autorizzazione.

Passaggi successivi

• Configura le policy di autorizzazione per i bilanciatori del carico delle applicazioni