Guida alla limitazione delle richieste per Azure Key Vault

La limitazione delle richieste è un processo che consente di limitare il numero di chiamate simultanee al servizio di Azure per prevenire l'uso eccessivo delle risorse. Azure Key Vault è progettato per gestire un volume di richieste elevato. In caso di un numero eccessivamente elevato di richieste, la limitazione delle richieste del client aiuta a mantenere le prestazioni ottimali e l'affidabilità del servizio di Azure Key Vault.

I limiti delle richieste variano in base allo scenario. Ad esempio, se si esegue un volume elevato di operazioni di scrittura, la possibilità di limitare le richieste è maggiore rispetto a quando si eseguono solo operazioni di lettura.

Gestione dei limiti da parte di Key Vault

I limiti del servizio in Key Vault hanno lo scopo di evitare un uso improprio delle risorse e garantire la qualità del servizio per tutti i client di Key Vault. Quando viene superata una soglia del servizio, Key Vault limita eventuali ulteriori richieste da tale client, restituisce il codice di stato HTTP 429 (troppe richieste) e la richiesta ha esito negativo. Le richieste non riuscite che restituiscono un codice 429 non valgono per le limitazioni della velocità effettiva di cui tiene traccia Key Vault.

Key Vault è stato originariamente progettato per archiviare e recuperare i segreti in fase di distribuzione. Il mondo si è evoluto e Key Vault viene usato in fase di esecuzione per archiviare e recuperare segreti e spesso app e servizi vogliono usare Key Vault come un database. I limiti correnti non supportano velocità effettiva elevate.

Key Vault è stato originariamente creato con i limiti specificati in Limiti dei servizi Azure Key Vault . Per ottimizzare la velocità effettiva di Key Vault, ecco alcune linee guida consigliate/procedure consigliate per ottimizzare la velocità effettiva:

1. Assicurarsi che sia attiva la limitazione. Il client deve rispettare i criteri di backoff esponenziali per gli errori 429 e assicurarsi di eseguire nuovi tentativi in base alle indicazioni seguenti.
2. Dividere il traffico di Key Vault tra più insiemi di credenziali e aree diverse. Usare un insieme di credenziali separato per ogni dominio di sicurezza/disponibilità. Se si hanno cinque app, ognuna in due aree, è consigliabile usare 10 insiemi di credenziali ognuno contenente i segreti univoci per l'app e l'area. Il limite a livello di sottoscrizione per tutti i tipi di transazione è pari a cinque volte il limite di un singolo insieme di credenziali delle chiavi. Ad esempio, le transazioni diverse da HSM hanno un limite di 5.000 transazioni ogni 10 secondi per sottoscrizione. Prendere in considerazione la memorizzazione nella cache del segreto all'interno del servizio o dell'app per ridurre anche l'RPS direttamente all'insieme di credenziali delle chiavi e/o gestire il traffico basato su burst. È anche possibile dividere il traffico tra aree diverse per ridurre al minimo la latenza e usare una sottoscrizione o un insieme di credenziali diversi. Non inviare più del limite di sottoscrizione al servizio Key Vault in una singola area di Azure.
3. Memorizzare nella cache i segreti recuperati da Azure Key Vault in memoria e riutilizzare dalla memoria quando possibile. Ripetere la lettura da Azure Key Vault solo quando la copia memorizzata nella cache smette di funzionare, ad esempio in seguito alla rotazione nell'origine.
4. Key Vault è progettato per i segreti dei servizi propri. Se si archiviano i segreti dei clienti (in particolare per scenari di archiviazione chiavi a velocità effettiva elevata), è consigliabile inserire le chiavi in un database o un account di archiviazione con crittografia e archiviare solo la chiave primaria in Azure Key Vault.
5. Crittografare, eseguire il wrapping e verificare che le operazioni con chiave pubblica possano essere eseguite senza accesso a Key Vault, riducendo non solo il rischio di limitazione, ma anche migliorando l'affidabilità (purché si memorizzi correttamente nella cache il materiale della chiave pubblica).
6. Se si usa Key Vault per archiviare le credenziali per un servizio, verificare se tale servizio supporta l'autenticazione di Microsoft Entra per l'autenticazione diretta. In questo modo si riduce il carico in Key Vault, si migliora l'affidabilità e si semplifica il codice perché Key Vault può ora usare il token di Microsoft Entra. Molti servizi sono stati spostati per l'uso dell'autenticazione di Microsoft Entra. Vedere l'elenco aggiornato in Servizi che supportano le identità gestite per le risorse di Azure.
7. Valutare la possibilità di scaglionare il carico o la distribuzione in un periodo di tempo più lungo per rimanere al di sotto dei limiti RPS correnti.
8. Se l'app comprende più nodi che devono leggere gli stessi segreti, prendere in considerazione l'uso di un modello fan-out, in cui un'entità legge il segreto da Key Vault e lo distribuisce a tutti i nodi. Memorizzare nella cache i segreti recuperati solo in memoria.

Come limitare le richieste per l'app in risposta ai limiti del servizio

Di seguito sono riportate le procedure consigliate da implementare quando il servizio è limitato:

• Ridurre il numero di operazioni per ogni richiesta.
• Ridurre la frequenza delle richieste.
• Evitare tentativi immediati.
  • Tutte le richieste si accumulano per i limiti di consumo.

Quando si implementa la gestione degli errori dell'app, usare il codice di errore HTTP 429 per rilevare la necessità di limitazione delle richieste lato client. Se la richiesta ha di nuovo esito negativo con un codice di errore HTTP 429, vuol dire che ci sono ancora limiti nel servizio di Azure. Continuare a usare il metodo di limitazione delle richieste lato client consigliato, provando a inviare nuovamente la richiesta fino a quando non ha esito positivo.

Di seguito è riportato il codice che implementa il backoff esponenziale:

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

L'uso di questo codice in un'applicazione C# client è semplice.

Metodo consigliato per la limitazione delle richieste lato client

Quando si genera il codice di errore HTTP 429, iniziare a limitare le richieste del client con un approccio di backoff esponenziale:

1. Attendere 1 secondo e ripetere la richiesta
2. Se viene ancora limitata, attendere 2 secondi e ripetere la richiesta
3. Se viene ancora limitata, attendere 4 secondi e ripetere la richiesta
4. Se viene ancora limitata, attendere 8 secondi e ripetere la richiesta
5. Se viene ancora limitata, attendere 16 secondi e ripetere la richiesta

A questo punto, il codice di risposta HTTP 429 dovrebbe non essere più visualizzato.

Vedi anche

Per un approfondimento sulla limitazione delle richieste nel cloud di Microsoft, vedere Throttling Pattern (Modello di limitazione delle richieste).