Panoramica della limitazione di frequenza del servizio

Le policy di limitazione di frequenza dei servizi ti consentono di mantenere la disponibilità dei servizi tra i client attendibili che potrebbero consumare una quantità eccessiva di risorse. Le policy raggiungono questo obiettivo dando la priorità al traffico client essenziale durante i sovraccarichi dei servizi e limitando i client che superano le soglie predefinite.

Puoi combinare le policy di limitazione di frequenza dei servizi con altri tipi di limitazione di frequenza, come le policy di sicurezza di Cloud Armor che vietano esplicitamente i client non attendibili per prevenire abusi. Per saperne di più sulle policy di sicurezza, consulta la Panoramica delle policy di sicurezza e la Panoramica della limitazione di frequenza di Cloud Armor.

Puoi collegare le policy di limitazione di frequenza dei servizi alle regole di forwarding dei bilanciatori del carico supportati o alle risorse del gateway Secure Web Proxy. Per saperne di più sull'utilizzo delle policy di limitazione di frequenza dei servizi con le istanze di Secure Web Proxy, consulta Configurare le policy di limitazione di frequenza dei servizi.

Target supportati

Le policy di limitazione di frequenza dei servizi sono disponibili per i seguenti target:

• Bilanciatori del carico delle applicazioni interni regionali
• Secure Web Proxy

Ordine di filtraggio delle richieste

Le policy di limitazione di frequenza dei servizi sono solo un tipo di filtro applicato alle richieste. Il seguente diagramma mostra l'ordine in cui vengono applicati i filtri:

Regole

Ogni policy di limitazione di frequenza dei servizi contiene un elenco di regole HTTP. Ogni regola specifica una condizione di corrispondenza e un insieme di azioni di limitazione di frequenza. Quando una richiesta soddisfa le condizioni di corrispondenza della regola, viene valutata in base a uno o più bucket di limitazione di frequenza configurati.

Condizioni di corrispondenza

Le condizioni di corrispondenza e le relative proprietà sono le seguenti. Ogni proprietà può corrispondere a una stringa esatta, un prefisso, un suffisso o una sottostringa:

• Source: l'origine della richiesta.
  • principal: un elenco di identità derivate dal certificato del client. Si verifica una corrispondenza quando un'entità corrisponde alla regola. Per saperne di più sull'utilizzo delle entità per la limitazione di frequenza dei servizi, consulta Utilizzare le entità per la limitazione di frequenza dei servizi.
• Destination: la destinazione della richiesta. Se specifichi più proprietà, queste vengono combinate con un operatore logico AND.
  • header_set: un elenco di intestazioni HTTP. Si verifica una corrispondenza quando tutte le intestazioni in header_set corrispondono alla regola.
  • hosts: un elenco di host HTTP. Si verifica una corrispondenza quando la richiesta viene inviata a uno qualsiasi degli host specificati nell'elenco.
  • paths: un elenco di percorsi dell'URL. Si verifica una corrispondenza quando la richiesta utilizza uno qualsiasi dei percorsi specificati nell'elenco.
  • methods: un elenco di metodi HTTP validi (ad esempio GET o POST). Si verifica una corrispondenza quando la richiesta utilizza uno qualsiasi dei metodi specificati nell'elenco.

Tieni presente che le proprietà di origine e destinazione vengono combinate con un operatore logico AND per determinare se una regola corrisponde a una richiesta. Ciò significa che, se specifichi un'origine e una destinazione, una richiesta deve corrispondere a entrambe per soddisfare le condizioni di corrispondenza. Inoltre, le regole vuote corrispondono a tutte le richieste.

Ordine di valutazione delle regole

Le regole vengono valutate in ordine, dalla prima all'ultima definita nella policy. La prima regola che corrisponde a una richiesta applica le azioni di limitazione di frequenza alla richiesta e non vengono valutate altre regole. Se una regola ha più azioni di limitazione di frequenza e una di queste supera la soglia configurata, la richiesta viene limitata.

Bucket di limitazione di frequenza

Puoi configurare uno o più bucket di limitazione di frequenza, ognuno dei quali ha una o più chiavi di limitazione di frequenza. Quando una richiesta corrisponde alle condizioni di corrispondenza di una regola, viene valutata in base a uno o più bucket di limitazione di frequenza configurati. Il bucket applica quindi la chiave di limitazione di frequenza configurata per identificare i singoli client e applica il limite.

Oltre ai tipi di chiave, puoi configurare le seguenti proprietà del bucket:

• Dry run: in modalità dry run, la regola viene valutata e le corrispondenze vengono monitorate, ma l'azione della regola non viene applicata. In questo modo, puoi testare le regole di limitazione di frequenza senza limitare i client o influire sul traffico di produzione.
• Override utente: puoi sostituire i limiti di richiesta predefiniti per valori di chiave specifici. Ad esempio, se avevi un bucket con un limite predefinito di 100 richieste al minuto per client e questo bucket utilizzava il tipo di chiave SOURCE_IP, potevi sostituire il limite per un indirizzo IP specifico e imporre invece un limite di 200 richieste al minuto.

Tipi di chiave

Puoi identificare i singoli client per la limitazione di frequenza utilizzando i seguenti tipi di chiave per aggregare le richieste e applicare i limiti di frequenza:

• ALL: una singola chiave per tutte le richieste che soddisfano la condizione di corrispondenza della regola.
• SOURCE_IP: una chiave univoca per ogni indirizzo IP client le cui richieste soddisfano la condizione di corrispondenza della regola.
• HTTP_HEADER: una chiave univoca per ogni valore univoco dell'intestazione HTTP il cui nome è configurato. Il valore della chiave viene troncato ai primi 128 byte del valore dell'intestazione. Il tipo di chiave è impostato sul valore predefinito "ALL" se non è presente un'intestazione di questo tipo.
• HTTP_PATH: il percorso dell'URL della richiesta HTTP. Il valore della chiave viene troncato ai primi 128 byte.
• PRINCIPAL: una stringa che rappresenta un'identità, derivata da certificato del client. L'unico tipo di entità supportato è CLIENT_CERT_COMMON_NAME.

Puoi specificare uno o più tipi di chiave in ogni regola. Se specifichi più tipi di chiave, la combinazione totale di chiavi per ogni client viene utilizzata come chiave univoca. Ad esempio, puoi utilizzare una combinazione di SOURCE_IP e HTTP_PATH per applicare limiti di frequenza alla frequenza con cui un indirizzo IP specifico può accedere a un endpoint specifico.

Utilizzare le entità per la limitazione di frequenza dei servizi

Per identificare l'origine del traffico con una granularità elevata, puoi configurare le policy di limitazione di frequenza dei servizi in base alle identità derivate dal certificato di un client. Questo metodo richiede l'abilitazione di mTLS frontend sul bilanciatore del carico e utilizza l'attributo Nome comune del certificato client (CLIENT_CERT_COMMON_NAME) come selettore di entità per l'identificazione.

Se non viene specificato alcun selettore di entità per l'identificazione, viene utilizzato CLIENT_CERT_URI_SAN come selettore di entità predefinito. Ciò significa che gli URI SAN del certificato client vengono valutati quando si prendono decisioni di limitazione di frequenza.

Affinché la limitazione di frequenza basata su entità funzioni, devono essere soddisfatte le seguenti condizioni:

• mTLS frontend deve essere abilitato. Se mTLS frontend non è abilitato, il client non presenta un certificato. Di conseguenza, le regole basate su entità nella policy di limitazione di frequenza dei servizi non trovano informazioni sul certificato da valutare. Ad esempio, una regola che controlla CLIENT_CERT_URI_SAN vede un valore vuoto.

• Deve essere presente un certificato client valido. Anche con mTLS abilitato, un certificato client non viene utilizzato per la limitazione di frequenza se la connessione è stata stabilita con un certificato mancante o non valido. Questo scenario si verifica quando la modalità di convalida del client mTLS è impostata sulla modalità permissiva ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Anche in questo caso, le regole basate su entità nella policy di limitazione di frequenza dei servizi non trovano informazioni sul certificato da valutare. Ad esempio, una regola che controlla CLIENT_CERT_URI_SAN vede un valore vuoto.

Impatto dei limiti di dimensione degli attributi

Le decisioni di limitazione di frequenza sono sensibili alla dimensione degli attributi del certificato client. Una richiesta viene rifiutata se un attributo supera il limite di dimensione e la policy è configurata per convalidare l'attributo specifico.

Un rifiuto può verificarsi quando la policy esegue la convalida rispetto a CLIENT_CERT_COMMON_NAME e l'oggetto del certificato (che contiene il nome comune) supera il limite di dimensione.

Passaggi successivi

• Configurare le policy di limitazione di frequenza dei servizi