Руководство по регулированию Azure Key Vault

Регулирование — это процесс, позволяющий ограничить число одновременных вызовов к службе Azure для предотвращения чрезмерного использования ресурсов. Хранилище ключей Azure (AKV) может обрабатывать большое число запросов. Если это число превышает приемлемое, для обеспечения оптимальной производительности и надежности службы AKV используется регулирование клиентских запросов.

Ограничения регулирования зависят от сценария. Например, при выполнении большого объема операций записи возможность регулирования будет более высокой по сравнению с ситуацией, когда выполняются только операции чтения.

Как хранилище ключей обрабатывает свои ограничения?

Для предотвращения некорректного использования ресурсов и обеспечения качества обслуживания для всех клиентов Key Vault действуют ограничения службы. При превышении порогового значения службы Key Vault ограничивает все дальнейшие запросы от этого клиента, возвращает код состояния HTTP 429 (слишком много запросов), а запрос завершается ошибкой. Невыполненные запросы, для которых возвращается код состояния 429, не учитываются при подсчете общего числа запросов для сравнения с пороговым значением.

Key Vault изначально предназначен для хранения и извлечения секретов во время развертывания. Мир вокруг нас изменился, и Key Vault теперь используется для хранения и извлечения секретов во время выполнения, а приложения и службы часто используют его как базу данных. Текущие ограничения не поддерживают высокие показатели пропускной способности.

Изначально хранилище Key Vault было создано с ограничениями, указанными в статье Ограничения службы Azure Key Vault. Ниже приведены рекомендации и лучшие методики по повышению пропускной способности Key Vault.

1. Обязательно реализуйте регулирование. Клиент должен учитывать экспоненциальные политики обратного отключения для 429-х и убедиться, что вы выполняете повторные попытки, как показано ниже.
2. Разделите трафик Key Vault между несколькими хранилищами и различными регионами. Используйте отдельное хранилище для каждого домена безопасности и доступности. Если у вас пять приложений, каждое из которых работает в двух регионах, мы рекомендуем использовать 10 хранилищ, каждое из которых содержит секреты, уникальные для приложения и региона. Ограничение для всех типов транзакций на уровне подписки в пять раз превышает ограничение на уровне одного хранилища. Например, для других транзакций HSM на каждую подписку предусмотрено максимум 5000 транзакций в течение 10 секунд. Рассмотрите возможность кэширования секрета в своей службе или приложении, чтобы также сократить число RPS непосредственно в хранилище и (или) обрабатывать пиковый трафик. Вы также можете разделить трафик между разными регионами, чтобы минимизировать задержку и использовать другую подписку или хранилище. Не отправляйте в службу Key Vault в одном регионе Azure больше запросов, чем позволяет ограничение для подписки.
3. Кэшируйте секреты, получаемые из Azure Key Vault, в памяти и по возможности используйте эти кэшированные данные, не обращаясь к хранилищу. Выполняйте повторное чтение из Azure Key Vault, только если кэшированная копия перестанет работать (например, если в источнике выполнен циклический сдвиг).
4. Хранилище Key Vault предназначено для ваших собственных секретов служб. Если вы храните секреты клиентов (особенно для сценариев хранилища ключей с высокой пропускной способностью), рекомендуется поместить ключи в базу данных или учетную запись хранения с шифрованием и сохранить только первичный ключ в Azure Key Vault.
5. Шифрование, помещение в оболочку и проверку операций с открытым ключом можно выполнять без доступа к Key Vault, что не только снижает риск регулирования, но также повышает надежность (при условии, что вы правильно кэшируете данные открытого ключа).
6. Если вы используете Key Vault для хранения учетных данных для службы, проверьте, поддерживает ли эта служба проверку подлинности Microsoft Entra напрямую. Это снижает нагрузку на Key Vault, повышает надежность и упрощает код, так как Key Vault теперь может использовать токен Microsoft Entra. Многие службы перешли на использование проверки подлинности Microsoft Entra. См. текущий список служб, поддерживающих управляемые удостоверения для ресурсов Azure.
7. Рассмотрите возможность разнесения нагрузки или развертывания на более длительный период, чтобы избежать превышения текущих ограничений RPS.
8. Если приложение состоит из нескольких узлов, которые должны считывать одни и те же секреты, рассмотрите возможность использования шаблона вентилятора, где одна сущность считывает секрет из Key Vault и вентиляторов для всех узлов. Кэшируйте извлеченные секреты только в памяти.

Регулирование приложения в ответ на ограничения служб

Ниже приведены рекомендации, которых следует придерживаться, если применяется регулирование для службы.

• Сократите число операций на один запрос.
• Уменьшите частоту запросов.
• Избегайте немедленных повторных попыток.
  • Все запросы учитываются, и их количество сравнивается с ограничениями использования.

При реализации обработки ошибок для приложения используйте код ошибки HTTP 429, чтобы определить необходимость регулирования на стороне клиента. Если запрос снова завершается сбоем с кодом ошибки HTTP 429, это означает, что вы по-прежнему не соблюдаете ограничения службы Azure. Продолжайте использовать рекомендуемый метод регулирования на стороне клиента и повторяйте выполнять запрос, пока он не будет успешно выполнен.

Ниже приведен код, реализующий экспоненциальную обратную передачу:

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

Использовать этот код в клиентском приложении на C# очень просто.

Рекомендуемый метод регулирования на стороне клиента

При возврате кода ошибки HTTP 429 начните регулирование клиента с помощью метода экспоненциального откладывания:

1. Подождите 1 с и повторите запрос
2. Если запрос по-прежнему не выполнен, подождите 2 с и повторите запрос
3. Если запрос по-прежнему не выполнен, подождите 4 с и повторите запрос
4. Если запрос по-прежнему не выполнен, подождите 8 с и повторите запрос
5. Если запрос по-прежнему не выполнен, подождите 16 с и повторите запрос

На этом этапе вы не должны получать коды ответа HTTP 429.

См. также

Более подробные сведения о регулировании для Microsoft Cloud см. в разделе Шаблон регулирования.