Diretrizes de limitação do Azure Key Vault

A limitação é o processo que você iniciar para limitar o número de chamadas simultâneas para o serviço do Azure a fim de evitar o uso excessivo de recursos. O AKV (Azure Key Vault) foi projetado para lidar com um alto volume de solicitações. Se ocorrer um número avassalador de solicitações, a limitação das solicitações do cliente ajudará a manter o desempenho e a confiabilidade ideais do serviço AKV.

Limites de limitação variam de acordo com o cenário. Por exemplo, se você estiver executando um grande volume de gravação, a possibilidade de limitação será maior do que se você estiver apenas executando leituras.

Como o Key Vault lida com seus limites?

Os limites de serviço no Key Vault impedem o uso indevido de recursos e garantem a qualidade do serviço para todos os clientes do Key Vault. Quando um limite de serviço é excedido, o Key Vault limita as solicitações adicionais desse cliente, retorna o código de status HTTP 429 (muitas solicitações) e a solicitação falha. As solicitações com falha que retornam um 429 contam para as restrições acompanhadas pelo Key Vault.

O Key Vault foi originalmente projetado para armazenar e recuperar seus segredos no momento da implantação. À medida que a tecnologia evoluiu, o Key Vault agora é cada vez mais usado em runtime para armazenar e recuperar segredos. Muitos aplicativos e serviços usam o Key Vault semelhante a um banco de dados. No entanto, os limites de serviço atuais não são projetados para dar suporte a cenários de alta taxa de transferência.

O Key Vault foi criado originalmente com os limites especificados nos limites de serviço do Azure Key Vault. Para otimizar suas taxas de transferência do Key Vault, aqui estão algumas diretrizes/práticas recomendadas para maximizar seu desempenho:

1. Verifique se a limitação está em vigor. O cliente deve honrar as políticas de retirada exponencial para 429s e garantir que esteja fazendo novas tentativas de acordo com as diretrizes.
2. Divida o seu tráfego de Key Vault entre vários cofres e regiões diferentes. Use um cofre separado para cada domínio de segurança/disponibilidade. Se você tiver cinco aplicativos, cada um em duas regiões, recomendamos 10 cofres cada um contendo os segredos exclusivos do aplicativo e da região. Um limite de assinaturas para todos os tipos de transações será cinco vezes o limite individual do cofre de chaves. Por exemplo, as transações HSM-other por assinatura são limitadas a 5.000 transações em 10 segundos por assinatura. Considere armazenar em cache o segredo em seu serviço ou aplicativo para também reduzir o RPS diretamente para o cofre de chaves e/ou lidar com o tráfego baseado em intermitência. Você também pode dividir o tráfego entre regiões diferentes para minimizar a latência e usar uma assinatura/cofre diferente. Não envie mais do que o limite de assinatura para o serviço do Key Vault em uma única região do Azure.
3. Armazene em cache os segredos que você recupera do Azure Key Vault na memória e reutilize da memória sempre que possível. Leia novamente do Azure Key Vault somente quando a cópia armazenada em cache parar de funcionar (por exemplo, porque ela foi girada na origem).
4. O Key Vault é projetado para seus próprios segredos de serviços. Se você estiver armazenando os segredos dos clientes (especialmente para cenários de armazenamento de chaves de alta taxa de transferência), considere colocar as chaves em um banco de dados ou conta de armazenamento com criptografia e armazenar apenas a chave primária no Azure Key Vault.
5. Para operações de chave pública, como criptografia, encapsulamento e verificação, execute essas operações localmente sem acessar o Key Vault armazenando em cache o material da chave pública. Essa abordagem não apenas reduz o risco de limitação, mas também melhora a confiabilidade do aplicativo.
6. Se você usar o Key Vault para armazenar credenciais para um serviço, verifique se esse serviço dá suporte à autenticação do Microsoft Entra para autenticação diretamente. Isso reduz a carga no Key Vault, melhora a confiabilidade e simplifica seu código, já que o Key Vault agora pode usar o token do Microsoft Entra. Muitos serviços agora usam a autenticação do Microsoft Entra. Consulte a lista atual nos Serviços que dão suporte a identidades gerenciadas para recursos do Azure.
7. Considere a possibilidade de escalonar sua carga/implantação em um período de tempo maior para permanecer sob os limites atuais do RPS.
8. Se o aplicativo for composto por vários nós que precisam ler um ou mais dos mesmos segredos, considere usar um padrão de disseminação, em que uma entidade lê o segredo do Key Vault e o distribui para todos os nós. Armazene em cache os segredos recuperados apenas na memória.

Como restringir o seu aplicativo em resposta aos limites de serviço

Veja a seguir as práticas recomendadas que você deve implementar quando o serviço é limitado:

• Reduza o número de operações por solicitação.
• Reduza a frequência de solicitações.
• Evite novas tentativas imediatas.
  • Todas as solicitações se acumulam em relação a seus limites de uso.

Ao implementar o tratamento de erros do aplicativo, use o código de erro HTTP 429 para detectar a necessidade de restrição do lado do cliente. Se a solicitação falhar novamente com um código de erro HTTP 429, você ainda encontrará um limite de serviço do Azure. Continue a usar o método de limitação do lado do cliente recomendado, tentando realizar a solicitação novamente até que ela tenha êxito.

Aqui está o código que implementa a retirada exponencial:

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);

Usar esse código em um aplicativo C# do cliente é simples.

Método recomendado de limitação do lado do cliente

No código de erro HTTP 429, inicie a limitação do cliente usando uma abordagem de retirada exponencial:

1. Aguarde 1 segundo, tente solicitar novamente
2. Se ainda estiver limitado, aguarde 2 segundos e tente a solicitação novamente
3. Se ainda estiver limitado, aguarde 4 segundos e tente a solicitação novamente
4. Se ainda estiver limitado, aguarde 8 segundos e tente a solicitação novamente
5. Se ainda estiver limitado, aguarde 16 segundos e tente a solicitação novamente

Neste ponto, você não deve estar obtendo códigos de resposta HTTP 429.

Consulte também

Para obter uma orientação mais profunda de limitação no Microsoft Cloud, consulte Padrão de Limitação.