Panoramica dei criteri di autorizzazione

Un criterio di autorizzazione (AuthzPolicy) applicato alla regola di forwarding dei bilanciatori del carico delle applicazioni definisce regole che specificano l'origine del traffico in entrata e le operazioni consentite o limitate per questa origine. Inoltre, la policy di autorizzazione delinea le condizioni in base alle quali si applica una regola e specifica un'azione per consentire, negare o valutare ulteriormente il traffico.

I criteri di autorizzazione ti consentono di stabilire controlli di controllo dell'accesso dell'accesso per il traffico in entrata ai bilanciatori del carico delle applicazioni. Le richieste che superano questi controlli vengono indirizzate ai servizi di backend. Le richieste che non superano questi controlli vengono terminate con una risposta non autorizzata.

Le norme di autorizzazione possono essere configurate nella regola di forwarding di tutti i bilanciatori del carico delle applicazioni con uno schema di bilanciamento del carico di 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

Nei bilanciatori del carico delle applicazioni, le policy di autorizzazione vengono richiamate dopo la valutazione delle estensioni di route, delle policy di sicurezza di rete (valutate da Google Cloud Armor), delle policy di condivisione delle risorse tra origini diverse (CORS) e delle policy di Identity-Aware Proxy (IAP), ma prima dell'esecuzione delle azioni di gestione del traffico.

Per scoprire di più su quando vengono richiamate le policy di autorizzazione nel percorso di elaborazione delle richieste, consulta Punti di estensione nel percorso dei dati di bilanciamento del carico.

Se vuoi utilizzare le policy di autorizzazione per i servizi di cui è stato eseguito il deployment con Cloud Service Mesh, consulta Configurare la sicurezza dei servizi con Envoy.

Regole dei criteri di autorizzazione

Un criterio di autorizzazione è costituito da un elenco di regole HTTP da confrontare con la richiesta in entrata.

Per un criterio 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 un criterio 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 norma 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 un criterio ALLOW. Se esistono criteri 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.

    Per applicare un'azione ALLOW, devi avere almeno una regola HTTP.

  • DENY: nega la richiesta se corrisponde a una delle regole specificate all'interno di una norma DENY. Se esistono criteri 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, devi avere 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 Utilizzare i criteri di autorizzazione per 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ù, vedi il seguente esempio in cui non sono definite regole HTTP e la policy di autorizzazione delega la decisione di autorizzazione a un IAP:

    Crea la policy di autorizzazione e abilita IAP

Ordine di valutazione dei criteri di autorizzazione

Un criterio di autorizzazione supporta i criteri CUSTOM, DENY e ALLOW per controllo dell'accesso'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 un criterio CUSTOM che corrisponde alla richiesta, il criterio CUSTOM viene valutato utilizzando i provider di autorizzazione personalizzati e la richiesta viene rifiutata se il provider la rifiuta. Le norme DENY o ALLOW non vengono valutate, anche se sono configurate.

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

  3. Se non esistono criteri ALLOW, la richiesta è consentita.

  4. Se uno dei criteri ALLOW corrisponde alla richiesta, consenti la richiesta.

  5. Se esistono criteri 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.

Utilizza i criteri di autorizzazione per delegare le decisioni di autorizzazione

Per decisioni di autorizzazione complesse che non possono essere espresse utilizzando le norme di autorizzazione, delega la decisione di autorizzazione a fornitori di autorizzazione personalizzati, come Identity-Aware Proxy (IAP), o crea la tua estensione di autorizzazione utilizzando le estensioni di servizio. Ciò è utile quando vuoi utilizzare il tuo motore di autorizzazione on-premise o provider di identità di terze parti tramite IAP.

  • IAP: configura IAP per controllare l'accesso alle applicazioni dietro le regole di forwarding del bilanciatore del carico delle applicazioni. IAP verifica l'identità e il contesto dell'utente per determinare l'accesso. Può anche autenticare i token del account di servizio IAM (Identity and Access Management) e valutare i criteri IAM, proteggendo l'accesso ai bucket di backend esposti da Application Load Balancer. Per saperne di più, consulta Delegare l'autorizzazione a IAP e IAM.

    Potresti scegliere di delegare l'autenticazione a IAP e IAM nei seguenti scenari:

    • Utilizza IAM per la gestione delle autorizzazioni.
    • Implementa l'accesso sensibile al contesto.
    • Utilizza l'autenticazione basata sul browser per le applicazioni web che richiedono l'autenticazione interattiva.

  • Estensioni di servizio: delega le decisioni di autorizzazione al tuo motore di autorizzazione personalizzato in esecuzione su istanze VM o on-premise. Google Cloud Ciò offre flessibilità per criteri di autorizzazione complessi che non sono coperti dai criteri integrati. Per saperne di più, consulta Configurare un'estensione di autorizzazione.

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 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 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 principale del criterio, la richiesta viene comunque valutata in base alle regole principali configurate. Ad esempio, se una policy è configurata 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.

Norme di autorizzazione basate su service account o tag

Puoi utilizzare attributi come service account o tag per identificare l'origine del traffico per i bilanciatori del carico delle applicazioni interni.

Per i bilanciatori del carico delle applicazioni interni, puoi applicare criteri di autorizzazione basati su account di servizio o tag collegati alle risorse. Google Cloud Il traffico proveniente da queste risorse Google Cloud collegate a un tag o a un account di servizio specifico può essere consentito, negato o delegato a un servizio esterno.

La tabella seguente elenca le risorse di origine che supportano l'utilizzo di service account e tag.

Origine Assistenza per il service account Assistenza per i tag
VM
Nodo GKE
Container 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 VM Google Cloud , consulta Policy di autorizzazione basata su service account o tag.

Quote

Per informazioni sulle quote per i criteri di autorizzazione, consulta quote e limiti per i criteri di autorizzazione.

Prezzi

Per informazioni sui prezzi, consulta la pagina Prezzi.

Passaggi successivi