Panoramica delle policy di autorizzazione

Le policy di autorizzazione ti consentono di stabilire controlli dell'accesso e controlli di sanificazione dei contenuti durante l'elaborazione di richieste o risposte tramite diversi serviziGoogle Cloud , come bilanciatori del carico delle applicazioni, gateway dell'agente (anteprima privata) 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 della regola di forwarding del bilanciatore del carico.

Una policy di autorizzazione (AuthzPolicy), associata 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 globali
  • Bilanciatori del carico delle applicazioni esterni regionali
  • Bilanciatori del carico delle applicazioni interni regionali
  • Bilanciatori del carico delle applicazioni interni tra regioni

Regole delle policy di autorizzazione

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

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 un criterio si verifica quando almeno una regola HTTP corrisponde alla richiesta o quando non sono definite regole HTTP nel criterio.

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: rifiuta la richiesta se corrisponde a una delle regole specificate all'interno di una policy DENY. Se esistono policy DENY, ma non c'è corrispondenza, la richiesta è 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 le 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

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
  • Gateway dell'agente
  • Secure Web Proxy

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

  • Profilo di autorizzazione 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 di 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 dell'applicazione 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 sua 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.

Delegare le decisioni di autorizzazione

I criteri di autorizzazione possono essere valutati direttamente o delegati. Per decisioni di autorizzazione complesse che non possono essere espresse utilizzando un criterio di autorizzazione, puoi creare un criterio di autorizzazione con un'azione CUSTOM e delegare la decisione di autorizzazione a un servizio gestito da Google o a un servizio gestito dall'utente tramite le estensioni di servizio.

  • Servizio gestito da Google
    • Model Armor
    • Identity-Aware Proxy
  • Servizio gestito dall'utente
    • un servizio di backend Google Cloud
    • un servizio accessibile tramite un nome di dominio completo (FQDN) che supporta il protocollo ext_proc o ext_authz di Envoy

La tabella seguente riassume i diversi servizi a cui può essere delegata una decisione di autorizzazione tramite le Service Extensions.

Policy di autorizzazione Valutazione diretta Delegato a Service Extensions (estensione di autorizzazione)
Servizi gestiti da Google Servizi gestiti dall'utente
Model Armor Identity-Aware Proxy Google Cloud servizio di backend Servizio basato su FQDN
Profilo REQUEST_AUTHZ
Profilo CONTENT_AUTHZ

Service Extensions

Puoi utilizzare le policy di autorizzazione per delegare le decisioni di autorizzazione alle Service Extensions, in particolare di tipo estensione di autorizzazione. Le estensioni di autorizzazione supportano i callout per inserire logica personalizzata nei Google Cloud bilanciatori del carico delle applicazioni. Questa funzionalità ti consente di scrivere il tuo codice per eseguire varie attività sul traffico elaborato da un bilanciatore del carico, ad esempio riscrittura degli header, sicurezza incrementale, logging personalizzato e autenticazione utente personalizzata.

Con i callout Service Extensions, indichi al bilanciatore del carico di inoltrare il traffico dal percorso di elaborazione dei dati di bilanciamento del carico utilizzando le chiamate gRPC a un servizio di callout, che può essere gestito dall'utente o da Google. I diversi servizi di callout sono definiti nella tabella precedente. Questi servizi di callout eseguono l'estensione di autorizzazione e possono applicare varie norme o funzioni prima di restituire il traffico al bilanciatore del carico per l'ulteriore elaborazione. Il seguente diagramma mostra questo processo.

Una policy di autorizzazione può delegare le decisioni di autorizzazione a Service Extensions, in particolare di tipo estensione di autorizzazione.
Policy di autorizzazione che delega la decisione di autorizzazione tramite un'estensione di autorizzazione (fai clic per ingrandire).

Per delegare le decisioni di autorizzazione a un'estensione di autorizzazione, crea un'estensione di autorizzazione (AuthzExtension) che venga eseguita su un servizio di callout. Quindi, puoi creare una policy di autorizzazione con un'azione CUSTOM e indirizzarla all'estensione di autorizzazione che hai creato. L'estensione di autorizzazione può essere utilizzata per eseguire sia l'autorizzazione a livello di richiesta (REQUEST_AUTHZ) sia la sanificazione dei contenuti (CONTENT_AUTHZ).

Per scoprire di più su come delegare la decisione di autorizzazione a un servizio di backendGoogle Cloud gestito dall'utente o a un servizio basato su FQDN, consulta Delegare la decisione di autorizzazione a un servizio gestito dall'utente.

Estensioni dell'autorizzazione nel percorso di trattamento dei dati

Quando deleghi una decisione di autorizzazione alle Service Extensions, in particolare di tipo estensione di autorizzazione, tieni presente la seguente terminologia:

  • Quando una policy di autorizzazione personalizzata con un profilo della policy REQUEST_AUTHZ rimanda a un'estensione di autorizzazione (AuthzExtension), l'estensione di autorizzazione viene definita estensione di autorizzazione delle richieste.

  • Quando una policy di autorizzazione con un profilo della policy CONTENT_AUTHZ punta a un'estensione di autorizzazione (AuthzExtension), l'estensione di autorizzazione viene definita estensione di autorizzazione dei contenuti.

Nel percorso di elaborazione delle richieste, viene richiamata prima un'estensione di autorizzazione delle richieste, seguita dalla valutazione delle policy di negazione e autorizzazione, quindi dall'estensione di autorizzazione dei contenuti e infine dall'estensione del traffico. Un'estensione di autorizzazione dei contenuti può essere richiamata anche nel percorso di elaborazione della risposta. Il seguente diagramma mostra la sequenza in cui vengono richiamate le diverse estensioni.

Un'estensione di autorizzazione delle richieste viene richiamata prima di un'estensione di autorizzazione dei contenuti
Estensione dell'autorizzazione richiesta prima di un'estensione dell'autorizzazione dei contenuti (fai clic per ingrandire).

Puoi considerare le diverse estensioni come hook che vengono attivati in determinati punti del percorso di elaborazione dei dati. Per scoprire di più sulle diverse estensioni, consulta la sezione Punti di estensibilità nel percorso dei dati di bilanciamento del carico nella documentazione di Service Extensions.

Model Armor

Puoi utilizzare i criteri di autorizzazione per consentire a Model Armor di applicare misure di salvaguardia dell'AI che impediscono la generazione di contenuti dannosi, il prompt injection e la perdita di dati.

Per farlo, puoi creare un'estensione di autorizzazione (AuthzExtension) che viene eseguita su un servizio Model Armor. Poi, puoi creare una policy di autorizzazione con un'azione CUSTOM e un profilo CONTENT_AUTHZ che punta all'estensione di autorizzazione che hai creato.

Per scoprire di più su come delegare l'autorizzazione a Model Armor, consulta Delegare la decisione di autorizzazione a Model Armor.

Identity-Aware Proxy

Puoi delegare le decisioni di autorizzazione a Identity-Aware Proxy. IAP verifica l'identità dell'utente e il contesto della richiesta per determinare se un utente può essere autorizzato ad accedere a un'applicazione o a una risorsa.

Per i bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni interni tra regioni, non puoi delegare la decisione di autorizzazione a IAP tramite un'estensione di autorizzazione.

Per i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali, puoi configurare una policy di autorizzazione per delegare la decisione di autorizzazione a IAP tramite un'estensione di autorizzazione.

Per saperne di più sull'utilizzo di IAP come servizio di autorizzazione, consulta Delega la decisione di autorizzazione a Identity-Aware Proxy.

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 sul principal nella policy di autorizzazione trova informazioni sul certificato 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 sulle entità 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 l'attributo specifico.

Un rifiuto può verificarsi nelle seguenti condizioni:

  • La policy viene convalidata 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 in base 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 del criterio, 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 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

Le policy di autorizzazione, basate su service account e tag sicuri, ti 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 eseguire le seguenti operazioni:

  • nega a una VM Compute Engine con unaccount di serviziot specifico (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) 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 i service account Supporto dei tag protetti
Macchina virtuale (VM) Compute Engine
Nodo Google Kubernetes Engine (GKE)
Contenitore Google Kubernetes Engine (GKE) 1 1
VPC diretta per Cloud Run 1
Connettore di accesso VPC serverless 2 2
Cloud VPN 1 1
Cloud Interconnect on-premise 1 1
Bilanciatore del carico delle applicazioni 3 3
Bilanciatore del carico di rete 3 3

1 Non supportato da Google Cloud.

2 L'indirizzo IP di origine è univoco e può essere utilizzato al suo posto.

3 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 una policy di autorizzazione basata su service account e tag collegati a una risorsa Google Cloud , consulta Policy di autorizzazione basata su service account o tag.

Quote

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

Prezzi

Per le informazioni sui prezzi, consulta Prezzi di rete: Cloud Load Balancing.

Passaggi successivi