Diretrizes de limitação do Azure Key Vault

  • Artigo

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 grande volume de solicitações. No caso de ocorrer um grande número de solicitações, limitar as solicitações do seu cliente ajuda a manter o desempenho ideal e a confiabilidade 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 trata os próprios limites?

Os limites de serviço no Key Vault impedem o uso incorreto dos recursos e assegurar a qualidade de serviço para todos os clientes do Key Vault. Quando o limite de um serviço é excedido, o Key Vault limita qualquer solicitação adicional desse cliente, retorna o código de status HTTP 429 (Solicitações em excesso) 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 desenvolvido para armazenar e recuperar os segredos no momento da implantação. O mundo evoluiu e o Key Vault está sendo usado em tempo de execução para armazenar e recuperar segredos e, muitas vezes, aplicativos e serviços desejam usar o Key Vault como um banco de dados. Os limites atuais não dão suporte a altas taxas de taxa de transferência.

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

  1. Certifique-se de ter a limitação de mecanismo ativada. O cliente deve honrar as políticas de retirada exponencial para 429s e garantir que esteja fazendo novas tentativas de acordo com as diretrizes abaixo.
  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 que contenham 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, outras transações HSM por assinatura são limitadas a 5.000 transações a cada 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 de Key Vault em uma única região do Azure.
  3. Armazene em cache os segredos que você recupera de Azure Key Vault na memória e reutilize a 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 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 mestra no Azure Key Vault.
  5. As operações criptografar, encapsular e verificar a chave pública podem ser executadas sem acesso ao Key Vault, o que não apenas reduz o risco de limitação, mas também melhora a confiabilidade (desde que você armazene corretamente o material da chave pública em cache).
  6. Se utilizar o Key Vault para armazenar as credenciais de um serviço, verifique se esse serviço dá suporte à autenticação do Microsoft Entra para autenticar diretamente. Isto reduz a carga no Key Vault, melhora a fiabilidade e simplifica o código, já que o Key Vault agora poderá utilizar o token do Microsoft Entra. Muitos serviços passaram a usar 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 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 seu aplicativo for composto por vários nós que precisam ler o(s) mesmo(s) segredo(s), considere usar um padrão de fan-out, em que uma entidade lê o segredo de Key Vault e faz o fan-out 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 for limitado:

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

Quando você implementa o tratamento de erro do aplicativo, use o código de erro HTTP 429 para detectar a necessidade de limitação do lado do cliente. Se a solicitação falha novamente com um código de erro HTTP 429, você ainda está encontrando 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);

O uso desse código em um aplicativo cliente C# é simples.

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.

Confira também

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