Partilhar via

Diretrizes de limitação do Azure Key Vault

A limitação é um processo que você inicia para restringir o número de chamadas simultâneas para o serviço do Azure, prevenindo a sobrecarga dos recursos. O Azure Key Vault (AKV) foi projetado para lidar com um grande volume de solicitações. Se ocorrer um número esmagador de pedidos, limitar os pedidos do seu cliente ajuda a manter o desempenho ideal e a fiabilidade do serviço AKV.

Os limites de controlo variam consoante o cenário. Por exemplo, se estiver a realizar um grande volume de operações de escrita, a possibilidade de limitação é maior do que se estiver a realizar apenas leituras.

Como o Key Vault lida com seus limites?

Os limites de serviço no Key Vault evitam 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 Cofre da Chave limita quaisquer outras solicitações 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 não contam para os limites de aceleração rastreados pelo Cofre de Chaves.

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 utilizado em tempo de execução 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 foram projetados para oferecer suporte a cenários de alta taxa de transferência.

O Cofre da Chave foi originalmente criado com os limites especificados nos limites de serviço do Cofre da Chave do Azure. Para maximizar o desempenho do Key Vault, aqui estão algumas diretrizes/práticas recomendadas para melhorar o seu desempenho:

  1. Certifique-se de que a limitação está em funcionamento. O cliente deve respeitar as políticas de back-off exponenciais para os códigos de erro 429 e deve assegurar que novas tentativas sejam realizadas conforme as orientações fornecidas.
  2. Divida o tráfego do Cofre da Chave 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 toda a assinatura para todos os tipos de transação é 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 ao cofre de chaves e/ou lidar com tráfego baseado em intermitência. Você também pode dividir seu tráfego entre diferentes regiões 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 Cofre da Chave em uma única região do Azure.
  3. Armazene em cache os segredos recuperados do Cofre de Chaves do Azure na memória e reutilize da memória sempre que possível. Releia do Cofre de Chaves do Azure somente quando a cópia em cache parar de funcionar (por exemplo, porque foi girada na origem).
  4. O Key Vault foi concebido para armazenar segredos dos seus próprios serviços. Se você estiver armazenando os segredos de seus 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 Cofre de Chaves do Azure.
  5. Para operações de chave pública, como criptografia, encapsulamento e verificação, execute essas operações localmente sem acessar o Cofre de Chaves armazenando em cache o material de chave pública. Essa abordagem não só reduz o risco de limitação, mas também melhora a confiabilidade do seu aplicativo.
  6. Se você usar o Cofre da Chave para armazenar credenciais de um serviço, verifique se esse serviço oferece suporte à autenticação do Microsoft Entra para autenticação direta. Isso reduz a carga no Cofre de Chaves, melhora a confiabilidade e simplifica seu código, já que o Cofre de Chaves agora pode usar o token Microsoft Entra. Muitos serviços agora usam a autenticação do Microsoft Entra. Consulte a lista atual em Serviços que dão suporte a identidades gerenciadas para recursos do Azure.
  7. Considere escalonar sua carga/implantação por um longo período de tempo para permanecer abaixo dos limites atuais do RPS.
  8. Se a sua aplicação tiver vários nós que precisam ler um ou mais dos mesmos segredos, considere usar um padrão de distribuição, onde uma entidade lê o segredo do Key Vault e o distribui para todos os nós. Cacheie os segredos recuperados apenas na memória.

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

A seguir estão as práticas recomendadas que você deve implementar quando o serviço estiver limitado:

  • Reduza o número de operações por solicitação.
  • Reduza a frequência dos pedidos.
  • Evite repetições imediatas.
    • Todas as solicitações são contabilizadas para os seus limites de uso.

Ao implementar o tratamento de erros do aplicativo, use o código de erro HTTP 429 para detetar a necessidade de limitaçã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 recomendado do lado do cliente, tentando novamente a solicitação até que ela seja bem-sucedida.

Aqui está o código que implementa backoff 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 cliente C# é simples.

No código de erro HTTP 429, comece a reduzir a velocidade do cliente usando uma abordagem de retrocesso exponencial.

  1. Aguarde 1 segundo e repita o pedido
  2. Se ainda estiver limitado, aguarde 2 segundos e tente novamente a requisição.
  3. Se ainda estiver restrito, aguarde 4 segundos e tente novamente o pedido.
  4. Se ainda estiver restrito, aguarde 8 segundos e tente novamente fazer o pedido.
  5. Se ainda estiver limitado, aguarde 16 segundos e repita o pedido

Neste momento, não deverá receber códigos de resposta HTTP 429.

Ver também

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