ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни управления API
При создании экземпляра службы Azure API Management в облаке Azure назначается поддомен azure-api.net (например, apim-service-name.azure-api.net). Вы также можете предоставить доступ к своим конечным точкам управления API, используя собственное доменное имя, например contoso.com. В этой статье показано, как сопоставить существующее пользовательское имя DNS с конечными точками, которые открывает экземпляр службы управления API.
Important
Управление API принимает только запросы со значениями заголовка узла , соответствующими:
- доменное имя шлюза по умолчанию;
- любой из настроенных пользовательских доменных имен шлюза.
Note
В настоящее время имена пользовательских доменов не поддерживаются в шлюзе рабочей области .
Important
Изменения инфраструктуры службы управления API (например, настройка пользовательских доменов, добавление сертификатов ЦС, масштабирование, конфигурация виртуальной сети, изменения зоны доступности и дополнения регионов) могут занять 15 минут или больше времени, в зависимости от уровня служб и размера развертывания. Ожидается больше времени для экземпляра с большим количеством единиц масштабирования или конфигурацией с несколькими регионами (шлюзами в нескольких расположениях). Изменения в управлении API внедряются постепенно и тщательно для сохранения производительности и доступности.
В то время как служба обновляется, другие изменения инфраструктуры служб не могут быть сделаны. Однако вы можете настроить API, продукты, политики и параметры пользователя. Служба не столкнется с простоем шлюза, а управление API будет продолжать обрабатывать запросы API без прерываний (за исключением уровня разработчика).
Prerequisites
Экземпляр управления API. Дополнительные сведения см. в разделе Создание экземпляра Azure API Management.
Пользовательское доменное имя, принадлежащее вам или вашей организации. В этой статье не приводятся инструкции по приобретению пользовательского доменного имени.
Действительный сертификат с открытым и закрытым ключом (PFX) (необязательно). Субъект или альтернативное имя субъекта (SAN) должны совпадать с доменным именем (это позволяет экземпляру Управления API безопасно предоставлять URL-адреса через TLS).
См. параметры сертификата домена.
DNS-записи, размещенные на DNS-сервере, которые сопоставляют пользовательское доменное имя с доменным именем по умолчанию для вашего экземпляра Управления API. В этом разделе не приводятся инструкции по размещению DNS-записей.
Дополнительные сведения о необходимых записях см. в разделе "Конфигурация DNS" далее в этой статье.
Конечные точки для личных доменов
Есть ряд конечных точек Управления API, которым вы можете назначить пользовательское доменное имя. Сейчас доступны следующие конечные точки:
| Endpoint |
Default |
|
Gateway |
По умолчанию: <apim-service-name>.azure-api.net. Шлюз — единственная конечная точка, доступная для настройки на уровне потребления.
Конфигурация конечной точки шлюза по умолчанию остается доступной после добавления домена пользовательского шлюза. |
|
Портал разработчика (все уровни, кроме потребления) |
По умолчанию: <apim-service-name>.developer.azure-api.net |
|
Управление (только классические уровни) |
По умолчанию: <apim-service-name>.management.azure-api.net |
|
API конфигурации локального шлюза (версия 2) |
По умолчанию: <apim-service-name>.configuration.azure-api.net |
|
SCM (только классические уровни) |
По умолчанию: <apim-service-name>.scm.azure-api.net |
Considerations
- Вы можете обновить любую конечную точку, поддерживаемую на уровне служб. Как правило, клиенты обновляют шлюз (этот URL-адрес используется для вызова API, предоставляемых через управление API) и портала разработчика (URL-адрес портала разработчика ).
- Конечная точка шлюза по умолчанию остается доступной после настройки пользовательского доменного имени шлюза и не может быть удалена. Для других конечных точек управления API (например , портала разработчика), настроенных с помощью имени личного домена, конечная точка по умолчанию больше недоступна.
- Только владельцы экземпляров API Management в классических уровнях могут использовать конечные точки Management и SCM для внутреннего доступа. Этим конечным точкам реже назначается пользовательское доменное имя.
- Уровни "Developer", "Premium" и "Premium v2" поддерживают настройку нескольких пользовательских имен узлов для конечной точки Gateway.
- Доменные имена с подстановочными знаками, например
*.contoso.com, поддерживаются на следующих уровнях: Developer, Basic, Standard, Standard v2, Premium, Premium v2. Сертификат для определенного поддомена (например, api.contoso.com) будет иметь приоритет над маскирующим сертификатом (*.contoso.com) для запросов к api.contoso.com.
- При настройке личного домена на портале разработчика можно включить CORS для нового доменного имени. Это необходимо для посетителей портала разработчика использовать интерактивную консоль на справочных страницах API.
Варианты сертификатов домена
Управление API поддерживает пользовательские сертификаты TLS или сертификаты, импортированные из Azure Key Vault. Вы также можете активировать бесплатный управляемый сертификат.
Warning
Если требуется закрепление сертификатов, используйте имя личного домена и пользовательский или Key Vault сертификат, а не сертификат по умолчанию или бесплатный управляемый сертификат. Мы не рекомендуем настраивать жесткую зависимость от сертификата, которым вы не управляете.
Если у вас уже есть частный сертификат от стороннего поставщика, вы можете загрузить его в экземпляр Управления API. Он должен соответствовать следующим требованиям Если вы включите бесплатный сертификат, управляемый службой «Управление API», он уже соответствует этим требованиям.
- экспортирован как PFX-файл, зашифрованный с помощью TRIPLE DES и при необходимости защищенный паролем;
- Содержит закрытый ключ длиной не менее 2048 битов
- должен содержать все промежуточные сертификаты и корневой сертификат в цепочке сертификатов.
Мы рекомендуем использовать Azure Key Vault для управления сертификатами и настройки их autorenew.
Если вы используете Azure Key Vault для управления сертификатом TLS личного домена, убедитесь, что сертификат вставляется в Key Vault как сертификат, а не как секрет.
Caution
При использовании в Управлении API сертификата, размещенного в хранилище ключей, важно соблюдать осторожность, чтобы случайно не удалить сертификат, хранилище ключей или управляемое удостоверение для доступа к хранилищу ключей.
Чтобы получить СЕРТИФИКАТ TLS/SSL, управление API должно иметь список и получать разрешения секретов на Azure Key Vault, содержащей сертификат.
При использовании портала Azure для импорта сертификата в управление API все необходимые действия по настройке выполняются автоматически.
При использовании инструментов командной строки или API управления эти разрешения необходимо предоставить вручную в два этапа:
- На странице управляемых удостоверений экземпляра службы управления API включите назначаемое системой или назначаемое пользователем управляемое удостоверение. Обратите внимание на идентификатор субъекта на этой странице.
- Назначьте разрешения управляемому удостоверению для доступа к хранилищу ключей. Выполните действия, описанные в следующем разделе.
- На портале Azure перейдите в хранилище ключей.
- В меню слева выберите Параметры>Конфигурация доступа. Запишите настроенную модель разрешений.
- В зависимости от модели разрешений настройте политику доступа хранилища ключей key vault или доступ Azure RBAC Azure RBAC для управляемого удостоверения в службе управления API.
Чтобы добавить политику доступа к хранилищу ключей, выполните следующие действия.
- В меню слева выберите политики доступа.
- На странице политик доступа нажмите кнопку +Создать.
- На вкладке "Разрешения" в разделе "Разрешения секрета" выберите "Получить" и "Список" и нажмите кнопку "Далее".
- На вкладке "Основной" найдите управляемое имя ресурса удостоверения, затем выберите "Далее".
Если вы используете назначаемое системой удостоверение, субъектом является имя экземпляра Управления API.
- Снова нажмите кнопку "Далее ". На вкладке "Просмотр и создание " нажмите кнопку "Создать".
Для настройки доступа Azure RBAC:
- В меню слева выберите элемент управления доступом (IAM).
- На странице управления доступом (IAM) выберите "Добавить назначение роли".
- На вкладке "Роль" выберите "Пользователь Key Vault Secrets".
- На вкладке "Члены" выберите "Управляемое удостоверение"> и "Выберите участников".
- В окне "Выбор управляемых удостоверений " выберите управляемое удостоверение, назначаемое системой, или назначаемое пользователем управляемое удостоверение, связанное с экземпляром управления API, и нажмите кнопку "Выбрать".
- Выберите Рецензирование + назначение.
Если для сертификата установлено значение autorenew, а для вашего уровня Управления API предусмотрено Соглашение об уровне обслуживания (доступное на всех уровнях кроме "Разработчик"), Управление API автоматически загрузит последнюю версию без простоя службы. Это обновление может занять до 1–2 дней. Синхронизацию сертификатов можно активировать вручную, если вы не хотите ждать автоматического обновления сертификата для управления API.
Дополнительные сведения о синхронизации и об устранении неполадок, связанных с доступом к сертификатам в Azure Key Vault, см. далее в этой статье в разделе Синхронизация сертификатов и устранение неполадок для сертификатов, хранящихся в Azure Key Vault.
Управление API предлагает бесплатный управляемый сертификат TLS для вашего домена, если вы не хотите приобретать собственный сертификат и управлять им. Сертификат автоматически продлевается.
Important
Создание управляемых сертификатов для пользовательских доменов в службе управления API временно недоступно с 15 августа 2025 г. по 30 июня 2026 г. Наш удостоверяющий центр (ЦС) DigiCert перейдет на новую платформу валидации, чтобы соответствовать требованиям многостороннего подтверждения выпуска (MPIC) для выдачи сертификатов. Эта миграция требует от нас временно приостановить создание управляемых сертификатов для пользовательских доменов.
Подробнее
Существующие управляемые сертификаты будут автоматически продлеваться и оставаться не затронутыми.
При приостановке создания управляемых сертификатов используйте другие параметры сертификата для настройки пользовательских доменов.
Note
Бесплатный управляемый сертификат TLS находится в предварительной версии.
Limitations
- Сейчас это можно использовать только с конечной точкой шлюза службы "Управление API".
- Не поддерживается на уровнях версии 2
- Не поддерживается в самостоятельно размещённом шлюзе
- Не поддерживается в следующих Azure регионах: Южная Франция и Южная Африка Западная Африка
- Сейчас доступно только в облаке Azure
- Не поддерживает корневые доменные имена (например,
contoso.com). Требуется полное имя, например api.contoso.com.
- Поддерживает только общедоступные доменные имена
- Можно настроить только при обновлении существующего экземпляра Управления API, а не при добавлении нового.
Разрешить доступ к IP-адресам DigiCert
Начиная с января 2026 года Управлению API Azure потребуется входящий доступ на порт 80 к определенным IP-адресам DigiCert для обновления (ротации) управляемого сертификата.
Если экземпляр управления API ограничивает входящие IP-адреса, рекомендуется удалить или изменить существующие ограничения IP-адресов с помощью одного из следующих методов на основе архитектуры развертывания.
Note
При внесении изменений в конфигурации политик, групп безопасности сети или правил брандмауэра рекомендуется проверить доступ к API, чтобы убедиться, что ограничения были удалены как и предполагалось.
Удаление или изменение политик IP-фильтров в службе управления API
Если вы реализовали ограничения IP-адресов с помощью встроенных политик, таких как ip-filter:
- Войдите на портал Azure и перейдите к экземпляру службы управления API.
- В разделе API выберите API, в котором применяется политика (или все API для глобального изменения).
- На вкладке "Дизайн", в обработке входящего трафика, выберите значок редактора кода (
</>).
- Найдите инструкцию политики ограничения IP-адресов.
- Выполните одно из следующих действий:
- Удалите весь фрагмент XML, чтобы полностью удалить ограничение.
- Измените элементы, чтобы включить или удалить определенные IP-адреса или диапазоны по мере необходимости. Рекомендуется добавить IP-адреса DigiCert в список разрешений.
- Нажмите кнопку "Сохранить", чтобы немедленно применить изменения к шлюзу.
Изменение правил группы безопасности сети (развертывание внешней виртуальной сети)
При развертывании экземпляра службы управления API в виртуальной сети во внешнем режиме ограничения входящего IP-адреса обычно управляются с помощью правил группы безопасности сети в подсети.
Чтобы изменить группу безопасности сети, настроенную в подсети, выполните следующие действия.
- На портале Azure перейдите к группам безопасности Network.
- Выберите группу безопасности сети, связанную с подсетью управления API.
- В разделе "Параметры>правила безопасности для входящего трафика" найдите правила, которые применяют ограничение IP-адресов (например, правила с определенным диапазоном исходных IP-адресов или тегом службы, который требуется удалить или расширить).
- Выполните одно из следующих действий:
-
Удалите ограничивающее правило: выберите правило и выберите параметр "Удалить ".
-
Измените правило: Источник замените на IP-адреса и добавьте IP-адреса DigiCert в список разрешенных адресов на порту 80.
- Нажмите кнопку "Сохранить".
Развертывание внутренней виртуальной сети
Если экземпляр управления API развертывается в виртуальной сети в внутреннем режиме и подключен к Шлюз приложений Azure, Azure Front Door или Диспетчер трафика Azure, необходимо реализовать следующую архитектуру:
Azure Front Door / Диспетчер трафика → Шлюз приложений → управление API (внутренняя виртуальная сеть)
Экземпляры шлюза приложений и управления API должны быть внедрены в одну виртуальную сеть.
Узнайте больше об интеграции Шлюза приложений с управлением API.
Шаг 1. Настройка шлюза приложений перед управлением API и разрешение IP-адресов DigiCert в группе безопасности сети
- На портале Azure перейдите к группам безопасности Network и выберите группу безопасности сети для подсети управления API.
- В разделе "Параметры>правила безопасности для входящего трафика" найдите правила, которые применяют ограничение IP-адресов (например, правила с определенным диапазоном исходных IP-адресов или тегом службы, который требуется удалить или расширить).
- Выполните одно из следующих действий:
-
Удалите ограничивающее правило: выберите правило и выберите параметр "Удалить ".
-
Измените правило: Источник замените на IP-адреса и добавьте IP-адреса DigiCert в список разрешенных адресов на порту 80.
- Нажмите кнопку "Сохранить".
Шаг 2. Сохранение целевого личного домена или имени узла от диспетчера трафика до экземпляра службы "Управление API"
Выполните одно или несколько из следующих действий в зависимости от вашего развертывания:
Настройте Azure Front Door для сохранения заголовка узла (пересылка исходного заголовка узла).
-
Azure Front Door (классическая): Set Backend host header в имя узла управления API (а не полное доменное имя шлюза приложений) или выберите заголовок узла Preserve входящего заголовка узла при использовании пользовательских доменов.
-
Azure Front Door Standard/Premium: В настройках маршрутизации > источника > включите передачу заголовка узла и выберите оригинальный заголовок узла.
Настройте шлюз приложений для сохранения заголовка Host.
В параметрах HTTP выполните одно из следующих действий, чтобы убедиться, что шлюз приложений выступает в качестве обратного прокси-сервера без перезаписи заголовка узла:
- Установите переопределение имени узла на Нет.
- Если вы используете переопределение имени узла, установите параметр Выбрать имя узла из входящего запроса (рекомендуется).
Убедитесь, что управление API имеет соответствующий личный домен.
Управление API в режиме внутренней виртуальной сети по-прежнему требует, чтобы входящее имя хоста совпадало с настроенным пользовательским доменом управления API.
Рассмотрим пример.
| Уровень |
Заголовок хоста |
| → Azure Front Door клиента |
api.contoso.com |
| шлюз приложений Azure Front Door → |
api.contoso.com |
| Управление API шлюза приложений → |
api.contoso.com |
Управление API отклоняет запросы, если имя входящего узла не соответствует настроенного личного домена.
Important
Если вы настроили бесплатный управляемый сертификат на Azure Front Door в том же домене api.contoso.com, вы не можете использовать бесплатный управляемый сертификат управления API. Вместо этого рекомендуется принести собственный сертификат и отправить его в службу управления API для личного домена.
Изменение правил Брандмауэр Azure при использовании
Если Брандмауэр Azure защищает экземпляр службы управления API, измените правила сети брандмауэра, чтобы разрешить входящий доступ с IP-адресов DigiCert через порт 80:
- Перейдите к экземпляру Брандмауэр Azure.
- Под Параметры>Правила (или Сетевые правила) найдите коллекцию правил и конкретное правило, ограничивающее входящий доступ к экземпляру API Management.
- Измените или удалите правило, чтобы добавить IP-адреса DigiCert в список разрешений через порт 80.
- Выберите "Сохранить и проверить доступ к API".
Настройка пользовательского доменного имени на портале
Выберите шаги в соответствии с сертификатом домена , который вы хотите использовать.
- Перейдите к экземпляру службы управления API на портале Azure.
- В области навигации слева выберите "Личные домены".
- Нажмите кнопку +Добавить или выберите существующую конечную точку , которую требуется обновить.
- В окне справа выберите тип конечной точки для личного домена.
- В поле "Имя узла " укажите имя, которое вы хотите использовать. Например,
api.contoso.com.
- В разделе "Сертификат" выберите "Настраиваемый"
- Выберите файл сертификата , чтобы выбрать и отправить сертификат.
- Загрузите допустимый файл .PFX и укажите его пароль, если сертификат защищен паролем.
- При настройке конечной точки шлюза выберите или отключите другие параметры при необходимости, включая согласование сертификата клиента или привязку SSL по умолчанию.
- Выберите "Добавить" или выберите "Обновить " для существующей конечной точки.
- Нажмите кнопку "Сохранить".
- Перейдите к экземпляру службы управления API на портале Azure.
- В области навигации слева выберите "Личные домены".
- Нажмите кнопку +Добавить или выберите существующую конечную точку , которую требуется обновить.
- В окне справа выберите тип конечной точки для личного домена.
- В поле "Имя узла " укажите имя, которое вы хотите использовать. Например,
api.contoso.com.
- В разделе Certificate выберите Key Vault и Select.
- Выберите подписку из раскрывающегося списка.
- Выберите хранилище ключей из раскрывающегося списка.
- После загрузки сертификатов выберите сертификат из раскрывающегося списка. Щелкните Выбрать.
- В удостоверении клиента выберите удостоверение, назначенное системой, или управляемое удостоверение, назначенное пользователем и включенное в экземпляре, чтобы получить доступ к хранилищу ключей.
- При настройке конечной точки шлюза выберите или отключите другие параметры при необходимости, включая согласование сертификата клиента или привязку SSL по умолчанию.
- Выберите "Добавить" или выберите "Обновить " для существующей конечной точки.
- Нажмите кнопку "Сохранить".
- Перейдите к экземпляру службы управления API на портале Azure.
- В области навигации слева выберите "Личные домены".
- Нажмите кнопку +Добавить или выберите существующую конечную точку , которую требуется обновить.
- В окне справа выберите тип конечной точки для личного домена.
- В поле "Имя узла " укажите имя, которое вы хотите использовать. Например,
api.contoso.com.
- В разделе "Сертификат" выберите "Управляемый ", чтобы включить бесплатный сертификат, управляемый управлением API. Управляемый сертификат доступен в режиме предварительной версии только для конечной точки шлюза.
- Скопируйте следующие значения и используйте их для настройки DNS:
- При настройке конечной точки шлюза выберите или отключите другие параметры при необходимости, включая согласование сертификата клиента или привязку SSL по умолчанию.
- Выберите "Добавить" или выберите "Обновить " для существующей конечной точки.
- Нажмите кнопку "Сохранить".
DNS configuration (Настройка DNS)
Настройте поставщика DNS для сопоставления имени личного домена с именем домена по умолчанию экземпляра службы управления API.
CNAME record
Настройте запись CNAME, которая связывает имя личного домена (например, api.contoso.com) с именем узла службы "Управление API" (например, yourapim-service-name.azure-api.net). Запись CNAME является более стабильной, чем запись A в случае изменения IP-адреса. Дополнительные сведения см. в разделе IP-адреса Azure API Management и часто задаваемые вопросы об управлении API Management.
Note
Некоторые регистраторы доменов позволяют отображать поддомены только при использовании записи CNAME, например www.contoso.com, а не корневых имен, таких как contoso.com. Дополнительные сведения о записях CNAME см. в документации, предоставленной вашим регистратором, или в документе IETF — доменные имена: реализация и спецификация.
CNAME record
Настройте запись CNAME, которая связывает имя личного домена (например, api.contoso.com) с именем узла службы "Управление API" (например, yourapim-service-name.azure-api.net). Запись CNAME является более стабильной, чем запись A в случае изменения IP-адреса. Дополнительные сведения см. в разделе IP-адреса Azure API Management и часто задаваемые вопросы об управлении API Management.
Note
Некоторые регистраторы доменов позволяют отображать поддомены только при использовании записи CNAME, например www.contoso.com, а не корневых имен, таких как contoso.com. Дополнительные сведения о записях CNAME см. в документации, предоставленной вашим регистратором, или в документе IETF — доменные имена: реализация и спецификация.
CNAME record
Настройте запись CNAME, которая связывает имя личного домена (например, api.contoso.com) с именем узла службы "Управление API" (например, yourapim-service-name.azure-api.net). Запись CNAME является более стабильной, чем запись A в случае изменения IP-адреса. Дополнительные сведения см. в разделе IP-адреса Azure API Management и часто задаваемые вопросы об управлении API Management.
Note
Некоторые регистраторы доменов позволяют отображать поддомены только при использовании записи CNAME, например www.contoso.com, а не корневых имен, таких как contoso.com. Дополнительные сведения о записях CNAME см. в документации, предоставленной вашим регистратором, или в документе IETF — доменные имена: реализация и спецификация.
Caution
При использовании бесплатного управляемого сертификата и настройки записи CNAME у вашего DNS-провайдера убедитесь, что он разрешается на имя узла службы API Management по умолчанию (<apim-service-name>.azure-api.net). В настоящее время служба Управления API не обновляет сертификат автоматически, если запись CNAME не соответствует имени узла по умолчанию для Управления API. Например, если вы используете бесплатный управляемый сертификат и используете Cloudflare в качестве поставщика DNS, убедитесь, что DNS-прокси не включен в записи CNAME.
TXT record
При включении бесплатного управляемого сертификата для Управления API также настройте запись типа TXT в свой зоне DNS, чтобы установить владение доменным именем.
- Имя записи — это имя личного домена с префиксом
apimuid. Пример: apimuid.api.contoso.com.
- Значение — это идентификатор владельца домена, предоставленный вашей системой управления API.
Если для настройки бесплатного управляемого сертификата для личного домена вы использовали портал, имя и значение необходимой записи типа TXT отображаются автоматически.
Вы также можете получить идентификатор владения доменом, вызвав REST API Get Domain Ownership Identifier.
Синхронизация сертификатов и устранение неполадок для сертификатов, поддерживаемых Azure Key Vault
Управление API предоставляет элементы управления и диагностику, помогающие синхронизировать сертификаты и быстро устранять проблемы с доступом.
Например, из-за изменения конфигурации или проблемы с подключением экземпляр управления API может не получить сертификат имени узла из Azure Key Vault после обновления или смены сертификата. В этом случае экземпляр службы управления API продолжает использовать кэшированный сертификат, пока он не получит обновленный сертификат. Если срок действия кэшированного сертификата истекает, рабочий трафик в шлюз будет заблокирован. Любая вышестоящая служба, например Шлюз приложений, использующая конфигурацию сертификата имени узла, также может блокировать трафик среды выполнения к шлюзу при использовании кэшированного сертификата с истекшим сроком действия.
Используйте следующие элементы управления и диагностику, чтобы сохранить сертификаты в синхронизации и предотвратить или свести к минимуму время простоя.
Синхронизация сертификатов
Выберите "Синхронизировать сертификаты " на панели команд, чтобы вручную запустить синхронизацию сертификатов при изменении отпечатков сертификатов. Этот параметр позволяет избежать ожидания задания автоматической синхронизации, которое может занять несколько часов или больше времени.
Просмотр журналов синхронизации
Выберите "Просмотреть журналы синхронизации " на панели команд, чтобы открыть панель с подробными сведениями о первопричине при сбое синхронизации сертификатов. Эти журналы помогают быстрее диагностировать и устранять проблемы синхронизации.
Восстановление доступа к хранилищу ключей
Управление API отображает упреждающие предупреждения при обнаружении проблем с доступом между экземпляром службы управления API и хранилищем ключей, используемым в пользовательском домене. Эти проблемы с доступом часто вызывают сбои синхронизации сертификатов.
Если появится предупреждение, выберите "Восстановить ", чтобы автоматически исправить доступ на основе модели авторизации хранилища ключей. В зависимости от модели управление API выполняет одно из следующих действий для восстановления доступа:
- Назначает роль пользователя секретов хранилища ключей для хранилища ключей Azure, основанного на RBAC.
- Предоставляет разрешение GET для хранилища ключей, управляемого на основе политики доступа.
Дополнительные советы по устранению неполадок при сбое процесса ротации сертификатов в Azure Key Vault
Убедитесь, что управляемое удостоверение, используемое для доступа к хранилищу ключей, существует.
Если экземпляр службы управления API развернут в виртуальной сети, подтвердите исходящее подключение к тегу службы AzureKeyVault.
Как прокси-сервер менеджмента API отвечает SSL-сертификатами в ходе TLS-рукопожатия
При настройке личного домена для конечной точки шлюза можно задать дополнительные свойства, определяющие способ ответа службы "Управление API" сертификатом сервера в зависимости от запроса клиента.
При наличии одного или нескольких личных доменов, настроенных для конечной точки шлюза, служба "Управления API" может отвечать на запросы HTTPS из следующих источников.
- Личный домен (например,
contoso.com)
- Домен по умолчанию (например,
apim-service-name.azure-api.net).
В зависимости от информации в заголовке SNI, служба управления API отвечает соответствующим сертификатом сервера.
Если вы используете клиент, который не отправляет заголовок SNI , управление API создает ответы на основе следующей логики:
Если служба имеет только один личный домен, настроенный для шлюза, сертификат по умолчанию является сертификатом, выданным пользовательскому домену шлюза.
Если служба настроила несколько пользовательских доменов для шлюза (поддерживается на уровне "Разработчик " и "Премиум "), можно назначить сертификат по умолчанию, установив для свойства defaultSslBinding значение true ("defaultSslBinding":"true"). На портале установите флажок привязки SSL по умолчанию .
Если вы не задали свойство, сертификатом по умолчанию является сертификат, выданный домену шлюза по умолчанию по адресу *.azure-api.net.
Поддержка запросов PUT/POST с большим объемом полезных данных
Прокси-сервер управления API поддерживает запросы с большим объемом (>40 КБ) полезных данных при использовании клиентских сертификатов в HTTPS. Чтобы предотвратить замораживание запроса сервера, можно задать для свойства negotiateClientCertificate значение true ("negotiateClientCertificate": "true") в имени узла шлюза. На портале установите флажок "Согласование сертификата клиента ".
Если свойство имеет значение true, сертификат клиента запрашивается во время подключения SSL/TLS перед обменом HTTP-запросами. Так как параметр применяется на уровне имени узла шлюза , все запросы на подключение запрашивают сертификат клиента. Это ограничение можно обойти и настроить до 20 пользовательских доменов для шлюза (только для уровня "Премиум ").
Ограничение для имени личного домена на уровнях версии 2
В настоящее время на уровнях "Стандартная v2" и "Премиум v2", для управления API необходимо DNS-имя, доступное для разрешения в публичной сети, чтобы обеспечить возможность трафика к конечной точке шлюза. Если вы настраиваете имя личного домена для конечной точки шлюза, это имя должно быть общедоступным, не ограничено частной зоной DNS.
В качестве обходного решения в сценариях, когда вы ограничиваете общедоступный доступ к шлюзу и настраиваете частное доменное имя, вы можете настроить шлюз приложений для получения трафика по имени частного домена и перенаправить его в конечную точку шлюза службы управления API. Пример архитектуры см. в этом GitHub репозитории.
Связанный контент
