Diretrizes de limitação do Azure Key Vault

A limitação é um processo iniciado que limita o número de chamadas simultâneas para o serviço do Azure para evitar o uso excessivo de 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 limitação variam consoante o cenário. Por exemplo, se estiver a executar um grande volume de escritas, a possibilidade de limitação é superior 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. O mundo evoluiu e o Key Vault está sendo usado em tempo de execução para armazenar e recuperar segredos e, muitas vezes, os aplicativos e serviços querem usar o Key Vault como um banco de dados. Os limites atuais não suportam altas taxas 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 suas taxas de taxa de transferência do Key Vault, aqui estão algumas diretrizes/práticas recomendadas para maximizar sua taxa de transferência:

1. Certifique-se de ter a limitação em vigor. O cliente deve honrar as políticas de back-off exponenciais para 429s e garantir que você está fazendo novas tentativas de acordo com as orientações abaixo.
2. Divida o tráfego do 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 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 da Chave 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 os 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 primária no Cofre de Chaves do Azure.
5. Criptografar, encapsular e verificar operações de chave pública podem ser executadas sem acesso ao Cofre de Chaves, o que não só reduz o risco de limitação, mas também melhora a confiabilidade (desde que você armazene corretamente em cache o material de chave pública).
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 passaram a usar o Microsoft Entra auth. 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 o seu aplicativo tiver vários nós que precisam ler o(s) mesmo(s) segredo(s), considere usar um padrão de distribuição, em que uma entidade lê o segredo do Cofre da Chave e ventila para todos os nós. Armazene em cache 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 acumuladas em relação aos 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.

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

No código de erro HTTP 429, comece a limitar o cliente com uma abordagem de recuo exponencial:

1. Aguarde 1 segundo e repita o pedido
2. Se ainda estiver limitado, aguarde 2 segundos e repita o pedido
3. Se ainda estiver limitado, aguarde 4 segundos e repita o pedido
4. Se ainda estiver limitado, aguarde 8 segundos e repita 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.

Consulte também

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