Защита бесплатной службы приложений API за управлением API потребления

Я создал .NET Core API и развернул его как службу приложений в Azure. Вдобавок ко всему у меня есть экземпляр Azure API Management. Теперь я хочу, чтобы API был доступен только через APIM.

На этапе бесплатного тестирования я ограничил доступ к API IP-адресом APIM. Поскольку я не ожидаю, что мой API будет иметь высокий трафик и сэкономит средства, теперь я переключился на уровень бесплатного использования и потребления.

Поскольку мой APIM использует уровень потребления, нет статического IP-адреса, который я мог бы использовать для ограничения доступа к API. Поскольку моя служба приложений использует бесплатный план, ни интеграция виртуальной сети, ни входящие клиентские сертификаты недоступны.

Есть ли способ защитить бесплатный API службы приложений с помощью APIM на уровне потребления с Azure, кроме как реализовать его самостоятельно?


person DanielGrams    schedule 04.06.2019    source источник


Ответы (1)


У вас есть несколько вариантов с учетом SKU потребления:

  1. Базовая аутентификация - заставьте APIM отправлять хорошо известный секрет и проверьте его в приложении API.
  2. Аутентификация сертификата клиента - заставьте APIM использовать сертификат клиента для подключения к приложению API и проверьте его там.
person Vitaliy Kurokhtin    schedule 04.06.2019
comment
Привет @vitaliy! Большое спасибо, что нашли время ответить. Правильно ли я, что для обоих вариантов мне нужно реализовать это в коде? Потому что я не видел никакой конфигурации для базовой проверки подлинности или проверки подлинности сертификата клиента в Службе приложений Azure (уровень Free). - person DanielGrams; 05.06.2019
comment
Для приложения можно настроить требование сертификата клиента: docs.microsoft.com/en-us/azure/app-service/, но фактический код для проверки сертификата должен быть реализован внутри приложения. Базовая аутентификация должна выполняться полностью в коде. - person Vitaliy Kurokhtin; 05.06.2019
comment
Еще раз спасибо, @vitaly! - person DanielGrams; 06.06.2019