архитектура посадочной зоны Azure API Management

Управление API Azure

Шлюз приложений Azure

Функции Azure

.NET

API становятся все более неотъемлемой частью того, как организации и их клиенты получают доступ к службам, как внутри внутренних систем, так и через внешние каналы. Внутренние интерфейсы API упрощают доступ к бизнес-приложениям, собственным решениям и интеграции с партнерами. Во внешних условиях растущее число организаций сосредоточено на повышении производительности и создании доходов за счет монетизации API. Учитывая эту тенденцию, Azure API Management выступает в качестве основного элемента в стандартизованном управлении, публикации и надзоре за API как для внутренних, так и для внешних заинтересованных лиц.

Azure Application Gateway служит контрольной точкой безопасности для API. Вместо того, чтобы разрешить пользователям подключаться непосредственно через Интернет, вы направляете весь трафик через шлюз приложений. Эта настройка добавляет дополнительные элементы управления доступом для защиты API. С помощью этого подхода можно использовать один экземпляр службы управления API для поддержки как внутренних API в организации, так и внешних API за пределами вашей организации, сохраняя все общедоступные API-интерфейсы, защищенные за шлюзом.

Архитектура

Значок ключа в левом верхнем углу представляет подписку Azure. Значок сетевого интерфейса, помеченный общедоступными IP-адресами, подключается со стрелкой вправо к значку с двумя противоположными стрелками, помеченными шлюзом приложений. Этот шлюз находится в прямоугольной области подсети шлюза приложений. Кирпичная стена со значком глобуса, помеченным Web Application Firewall политиками, подключается к шлюзу приложений, что указывает на встроенную проверку трафика. В подсети шлюза приложений есть три значка: рабочие области Log Analytics, Application Insights и azure-api.net. Стрелка вправо из Шлюза приложений ведет к значку облака API Management Premium, который находится внутри отдельной прямоугольной зоны, обозначенной как подсеть управления API. Частная конечная точка находится в третьей прямоугольной области, обозначенной как подсеть частной конечной точки. Стрелка вниз от частной конечной точки указывает на значок с изображением ключа в круге, помеченный как Хранилища ключей. Стрелки направления на схеме указывают поток трафика и безопасное подключение между компонентами.

Скачайте файл Visio этой архитектуры.

В этой архитектуре предполагается, что политики установлены в соответствии с эталонной реализацией целевой зоны Azure, и что структура организована сверху вниз от группы управления.

Рабочий процесс

• Общедоступные IP-адреса назначаются шлюзу приложений, который служит точкой входа для внешнего трафика. Эта конечная точка предоставляет API через личный домен.

• Шлюз приложений развертывается в собственной подсети и защищен политиками Web Application Firewall (WAF) для проверки и фильтрации входящих запросов.

• Трафик направляется из шлюза приложений в службу управления API (Premium), которая находится в отдельной подсети управления API. Экземпляр управления API настраивается во внутреннем режиме, что предотвращает прямой открытый доступ.

• Частные конечные точки используются для безопасного подключения управления API-сервисами к серверам приложений back-end, доступным только в виртуальной сети. Управление API периодически подключает такие компоненты, как хранилища ключей Azure. Как правило, все эти частные подключения осуществляются с конечными узлами в выделенной подсети частной конечной точки.

• Рабочие области Log Analytics и Application Insights интегрированы для ведения журнала, мониторинга и телеметрии.

Компоненты

• Управление API — это управляемая служба, которая позволяет управлять службами в гибридных и многооблачных средах. Она обеспечивает контроль и безопасность для наблюдения и потребления API внутренними и внешними пользователями. В этой архитектуре управление API служит фасадом для абстрагирования серверной архитектуры.

• Шлюз приложений — это управляемая служба, которая служит подсистемой балансировки нагрузки уровня 7 и WAF. Шлюз приложений защищает внутренний экземпляр управления API, который позволяет использовать как внутренние, так и внешние режимы. В этой архитектуре управление API защищает API, а шлюз приложений добавляет дополнительные возможности, такие как WAF.

• Приватные зоны системы доменных имен (DNS — это функция Azure DNS, которая позволяет управлять и разрешать доменные имена в виртуальной сети без необходимости реализовать кастомное решение DNS. Частная зона DNS может связываться с одной или несколькими виртуальными сетями через связи виртуальной сети. В этой архитектуре для обеспечения правильного разрешения имен в виртуальной сети требуется частная зона DNS.

• Application Insights — это расширяемая служба управления производительностью приложений, которая помогает разработчикам обнаруживать аномалии, диагностировать проблемы и понимать шаблоны использования. Application Insights предоставляет расширяемое управление производительностью приложений и мониторинг для динамических веб-приложений. Поддерживаются различные платформы, включая .NET, Node.js, Java и Python. Она поддерживает приложения, размещенные в Azure, локальной среде или в других общедоступных облаках. В этой архитектуре Application Insights отслеживает поведение развернутого приложения.

• Log Analytics — это облачное средство анализа данных, позволяющее изменять и запускать запросы журналов к данным в журналах Azure Monitor, возможно на портале Azure. Разработчики могут выполнять простые запросы для получения записей или использования Log Analytics для расширенного анализа, а затем визуализировать результаты. В этой архитектуре Log Analytics агрегирует все журналы ресурсов платформы для анализа и создания отчетов.

• Azure Key Vault — это облачная служба, которая безопасно хранит и обращается к секретам. Эти секреты варьируются от ключей API и паролей до сертификатов и криптографических ключей. В этой архитектуре Key Vault хранятся сертификаты SSL, которые использует шлюз приложений.

Альтернативные варианты

Для внутренних служб, к которым подключается экземпляр службы управления API, доступны несколько альтернативных вариантов:

• Azure App Service — это полностью управляемая служба на основе HTTP, которая создает, развертывает и масштабирует веб-приложения. Он поддерживает .NET, .NET Core, Java, Ruby, Node.js, PHP и Python. Приложения могут выполняться и масштабироваться в Windows или в средах под управлением Linux.

• Azure Kubernetes Service (AKS) — это управляемое предложение Kubernetes, которое предоставляет полностью управляемые кластеры. Она обеспечивает встроенную непрерывную интеграцию и непрерывную доставку (CI/CD), а также встроенную систему управления и безопасность.

• Azure Logic Apps — это облачная платформа, которая создает и запускает автоматизированные рабочие процессы. Дополнительные сведения см. в примере эталонной архитектуры.

• Azure Container Apps — это полностью управляемая бессерверная служба контейнеров, которая позволяет запускать микрослужбы и контейнерные приложения на бессерверной платформе.

Для многорегионных развертываний рекомендуется использовать Azure Front Door для обеспечения быстрого, надежного и безопасного доступа между пользователями и статическим и динамическим веб-контентом приложений.

Дополнительные примеры защиты API шлюза приложений см. в статье "Защита API с помощью шлюза приложений и управления API".

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Для получения дополнительной информации см. в руководстве Well-Architected Framework.

Надежность

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

• Разверните не менее двух единиц масштаба управления API, распределённых по двум или более зонам доступности в каждом регионе. Отслеживайте метрики емкости и подготавливайте достаточные единицы емкости, чтобы можно было продолжать работать, даже если единицы в одной зоне доступности потеряны.

• Рекомендуется использовать уровень "Премиум", так как он поддерживает зоны доступности и многорегиональные развертывания. Эта возможность означает, что службы могут продолжать работать даже в том случае, если один регион или зона отключены. Эти функции помогают защитить приложение во время сбоя или аварий.

• Для аварийного восстановления настройте управление API с управляемым удостоверением, назначаемое пользователем, вместо удостоверения, назначаемого системой. При повторном развертывании или удалении ресурса удостоверение и его разрешения остаются на месте, чтобы можно было легко восстановить доступ. Используйте Azure Pipelines для автоматизации резервных копий. Определите, нужно ли развертывать службы в нескольких регионах для повышения надежности.

• Пиринг между виртуальными сетями обеспечивает высокую производительность в пределах региона, но имеет ограничение масштабируемости 500 сетей. Если необходимо подключить больше рабочих нагрузок, используйте дизайн hub-spoke или Azure Virtual WAN.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

• Политики проверки управления API проверяют запросы и ответы API на схему OpenAPI. Эти функции не являются заменой WAF, но они могут обеспечить дополнительную защиту от некоторых угроз. Добавление политик проверки может иметь последствия для производительности, поэтому мы рекомендуем использовать нагрузочные тесты производительности для оценки их влияния на пропускную способность API.

• Microsoft Defender для API обеспечивает полную защиту жизненного цикла, обнаружение и реагирование на API, опубликованные в службе управления API. Одна из ключевых возможностей заключается в обнаружении эксплойтов API Open Web Application Security Project (OWASP) Top 10 уязвимостей с помощью наблюдений за аномалиями во время выполнения с помощью обнаружения на основе машинного обучения и обнаружения на основе правил.

• Рабочие области управления API помогают упорядочивать и изолировать API. Такой подход облегчает контроль над тем, кто может получить доступ и управлять ими. Каждая рабочая область может иметь собственный набор разрешений, поэтому вы можете ограничить доступ только к пользователям или командам, которым он нужен. Это разделение снижает риск случайных изменений или несанкционированного доступа и поддерживает более безопасную среду API.

• Использовать секреты Key Vault в качестве именованных значений в политиках управления API для защиты конфиденциальной информации в политиках управления API.

• Используйте Шлюз приложений для внешнего доступа к внутреннему экземпляру службы управления API для защиты экземпляра управления API , защиты от распространенных эксплойтов веб-приложений и уязвимостей с помощью WAF и включения гибридного подключения.

• Разверните шлюз управления API в виртуальной сети для поддержки гибридного подключения и повышения безопасности.

• Пиринг между виртуальными сетями повышает производительность в регионе и обеспечивает частный обмен данными между виртуальными сетями.

• При использовании WAF вы создаете слой, проверяющий входящий трафик на вредоносную активность. Эта защита помогает блокировать распространенные угрозы, такие как внедрение SQL и междоменный скрипт. Шлюз приложений и распределенная защита от атак типа "отказ в обслуживании" (DDoS) помогают предотвратить перегрузку экземпляра службы управления API избыточным трафиком или наводнением подключений. Дополнительные сведения см. в статье "Защита API с помощью шлюза приложений и управления API".

• Частные конечные точки для Azure Functions позволяют безопасно подключаться к приложениям-функциям через частный IP-адрес в виртуальной сети. Эта настройка предотвращает подключение ваших функций к открытому интернету, что уменьшает риск несанкционированного доступа. В этой архитектуре частные конечные точки обеспечивают доступ к Azure Functions только доверенным ресурсам в вашей сети.

Обработка политик управления API за обратным прокси-сервером

Шлюз приложений с Web Application Firewall (WAF) размещается перед API Managment и обрабатывает весь трафик API, прежде чем он достигнет внутреннего экземпляра управления API. Цель заключается в добавлении пограничного уровня безопасности, который проверяет, фильтрует и направляет клиентские запросы, а управление API ориентировано на управление API, преобразование и интеграцию серверной части.

Однако эта многоуровневая топология имеет поведенческие последствия для определенных политик управления API: когда завершение TLS, принятие решений по маршрутизации или преобразования заголовков или соединений происходят на границе шлюза приложений, подсистема политик управления API может не видеть исходные сведения о клиентском запросе, который она ожидает. Это может привести к тому, что поведение политик будет отличаться от ситуации, когда управление API непосредственно доступно. Рассмотрим пример.

• Фильтрация на основе IP-адресов клиента: политики, например ip-filter , где можно разрешить или запретить трафик на основе исходных IP-адресов, теперь частный IP-адрес шлюза приложений будет отображаться как источник, а не фактический адрес клиента. В результате ip-filter политика должна быть тщательно запланирована и управляема, чтобы обеспечить фильтрацию правильного трафика.

• Предположения о упорядочении политик и контексте: политики управления API ожидают выполнения запросов с определенными заголовками, именами узлов или характеристиками запросов. Если шлюз приложений перезаписывает заголовки (для маршрутизации, пользовательских доменов или разгрузки SSL), контекст, на который применяются политики управления API ниже, могут не совпадать с тем, что было определено в этих политиках. Это может привести к несоответствию намерений клиента политикам маршрутизации, проверке или преобразованию внутри службы управления API.

Шлюз приложений и Менеджмент API становятся двумя уровнями принудительного применения, а представление Менеджмента API по входящим запросам отстоит на один шаг от исходного контекста клиента. Необходимо избегать использования политик в управлении API, которые зависят от необработанных клиентских атрибутов, если эти атрибуты не сохраняются на протяжении всего процесса, и может потребоваться разработать пользовательские политики на основе данных, доступных в HTTP-запросе.

Дополнительные рекомендации по сохранению данных, таких как заголовки узлов, см. в разделе "Сохранение исходного имени узла HTTP" между обратным прокси-сервером и серверным веб-приложением.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

• Это развертывание использует план Premium для поддержки возможностей зоны доступности и виртуальной сети. Если вам не нужны выделенные экземпляры, можно также использовать Flex Consumption, которая поддерживает как сетевой доступ, так и зоны доступности. Просмотрите калькулятор цен для этого развертывания.

• Для подтверждения концепций или прототипов рекомендуется использовать другие уровни управления API, такие как разработчик или стандартный.

Операционное превосходство

Операционная эффективность охватывает процессы эксплуатации, которые развертывают приложение и поддерживают его в рабочей среде. Для получения дополнительной информации см. Контрольный список для оценки проектирования с точки зрения операционной эффективности.

• Представьте конфигурации управления API в виде шаблонов для Azure Resource Manager и примите подход инфраструктуры как код (IaC).

• Используйте процесс CI/CD для управления, версионирования и обновления конфигураций управления API.

• Создайте пользовательские пробы работоспособности, чтобы проверить состояние экземпляра службы управления API. Используйте URL-адрес /status-0123456789abcdef для создания общей конечной точки работоспособности для службы управления API в шлюзе приложений.

• Сертификаты, обновленные в хранилище ключей, автоматически поворачиваются в службе управления API, что отражает изменения в течение четырех часов.

• Если вы используете средство DevOps, например Azure DevOps или GitHub, агенты, размещенные в облаке, или средства запуска работают через общедоступный Интернет. Так как для управления API в этой архитектуре задана внутренняя сеть, необходимо использовать агент DevOps, имеющий доступ к виртуальной сети. Агент DevOps помогает развертывать политики и другие изменения в интерфейсах API вашей архитектуры. Эти шаблоны CI/CD можно использовать для разделения процесса на части, чтобы команды разработчиков могли развертывать изменения для каждого API. Агенты DevOps инициируют шаблоны для обработки этих отдельных развертываний.

Развертывание этого сценария

Эта архитектура доступна в GitHub. Он содержит все необходимые файлы IaC и инструкции deployment.

Соавторы

Microsoft поддерживает эту статью. Следующие участники написали эту статью.

Основные авторы:

• Пит Мессина | Старший архитектор облачных решений
• Энтони Невико | Старший архитектор облачных решений

Чтобы просмотреть закрытые профили в LinkedIn, войдите в свою учетную запись LinkedIn.

Следующие шаги

• Терминология управления API
• Документация по шлюзу приложений

Связанные ресурсы

• Использование шлюзов API в микрослужбах
• топология сети Hub-периферийной сети в Azure
• Basic enterprise integration on Azure
• Защита API с помощью шлюза приложений и управления API

API становятся все более неотъемлемой частью того, как организации и их клиенты получают доступ к службам, как внутри внутренних систем, так и через внешние каналы. Внутренние интерфейсы API упрощают доступ к бизнес-приложениям, собственным решениям и интеграции с партнерами. Во внешних условиях растущее число организаций сосредоточено на повышении производительности и создании доходов за счет монетизации API. Учитывая эту тенденцию, Azure API Management выступает в качестве основного элемента в стандартизованном управлении, публикации и надзоре за API как для внутренних, так и для внешних заинтересованных лиц.

Azure Application Gateway служит контрольной точкой безопасности для API. Вместо того, чтобы разрешить пользователям подключаться непосредственно через Интернет, вы направляете весь трафик через шлюз приложений. Эта настройка добавляет дополнительные элементы управления доступом для защиты API. С помощью этого подхода можно использовать один экземпляр службы управления API для поддержки как внутренних API в организации, так и внешних API за пределами вашей организации, сохраняя все общедоступные API-интерфейсы, защищенные за шлюзом.

Архитектура

Значок ключа в левом верхнем углу представляет подписку Azure. Значок сетевого интерфейса, помеченный общедоступными IP-адресами, подключается со стрелкой вправо к значку с двумя противоположными стрелками, помеченными шлюзом приложений. Этот шлюз находится в прямоугольной области подсети шлюза приложений. Кирпичная стена со значком глобуса, помеченным Web Application Firewall политиками, подключается к шлюзу приложений, что указывает на встроенную проверку трафика. В подсети шлюза приложений есть три значка: рабочие области Log Analytics, Application Insights и azure-api.net. Стрелка вправо из Шлюза приложений ведет к значку облака API Management Premium, который находится внутри отдельной прямоугольной зоны, обозначенной как подсеть управления API. Частная конечная точка находится в третьей прямоугольной области, обозначенной как подсеть частной конечной точки. Стрелка вниз от частной конечной точки указывает на значок с изображением ключа в круге, помеченный как Хранилища ключей. Стрелки направления на схеме указывают поток трафика и безопасное подключение между компонентами.

Скачайте файл Visio этой архитектуры.

В этой архитектуре предполагается, что политики установлены в соответствии с эталонной реализацией целевой зоны Azure, и что структура организована сверху вниз от группы управления.

Рабочий процесс

• Общедоступные IP-адреса назначаются шлюзу приложений, который служит точкой входа для внешнего трафика. Эта конечная точка предоставляет API через личный домен.

• Шлюз приложений развертывается в собственной подсети и защищен политиками Web Application Firewall (WAF) для проверки и фильтрации входящих запросов.

• Трафик направляется из шлюза приложений в службу управления API (Premium), которая находится в отдельной подсети управления API. Экземпляр управления API настраивается во внутреннем режиме, что предотвращает прямой открытый доступ.

• Частные конечные точки используются для безопасного подключения управления API-сервисами к серверам приложений back-end, доступным только в виртуальной сети. Управление API периодически подключает такие компоненты, как хранилища ключей Azure. Как правило, все эти частные подключения осуществляются с конечными узлами в выделенной подсети частной конечной точки.

• Рабочие области Log Analytics и Application Insights интегрированы для ведения журнала, мониторинга и телеметрии.

Компоненты

• Управление API — это управляемая служба, которая позволяет управлять службами в гибридных и многооблачных средах. Она обеспечивает контроль и безопасность для наблюдения и потребления API внутренними и внешними пользователями. В этой архитектуре управление API служит фасадом для абстрагирования серверной архитектуры.

• Шлюз приложений — это управляемая служба, которая служит подсистемой балансировки нагрузки уровня 7 и WAF. Шлюз приложений защищает внутренний экземпляр управления API, который позволяет использовать как внутренние, так и внешние режимы. В этой архитектуре управление API защищает API, а шлюз приложений добавляет дополнительные возможности, такие как WAF.

• Приватные зоны системы доменных имен (DNS — это функция Azure DNS, которая позволяет управлять и разрешать доменные имена в виртуальной сети без необходимости реализовать кастомное решение DNS. Частная зона DNS может связываться с одной или несколькими виртуальными сетями через связи виртуальной сети. В этой архитектуре для обеспечения правильного разрешения имен в виртуальной сети требуется частная зона DNS.

• Application Insights — это расширяемая служба управления производительностью приложений, которая помогает разработчикам обнаруживать аномалии, диагностировать проблемы и понимать шаблоны использования. Application Insights предоставляет расширяемое управление производительностью приложений и мониторинг для динамических веб-приложений. Поддерживаются различные платформы, включая .NET, Node.js, Java и Python. Она поддерживает приложения, размещенные в Azure, локальной среде или в других общедоступных облаках. В этой архитектуре Application Insights отслеживает поведение развернутого приложения.

• Log Analytics — это облачное средство анализа данных, позволяющее изменять и запускать запросы журналов к данным в журналах Azure Monitor, возможно на портале Azure. Разработчики могут выполнять простые запросы для получения записей или использования Log Analytics для расширенного анализа, а затем визуализировать результаты. В этой архитектуре Log Analytics агрегирует все журналы ресурсов платформы для анализа и создания отчетов.

• Azure Key Vault — это облачная служба, которая безопасно хранит и обращается к секретам. Эти секреты варьируются от ключей API и паролей до сертификатов и криптографических ключей. В этой архитектуре Key Vault хранятся сертификаты SSL, которые использует шлюз приложений.

Альтернативные варианты

Для внутренних служб, к которым подключается экземпляр службы управления API, доступны несколько альтернативных вариантов:

• Azure App Service — это полностью управляемая служба на основе HTTP, которая создает, развертывает и масштабирует веб-приложения. Он поддерживает .NET, .NET Core, Java, Ruby, Node.js, PHP и Python. Приложения могут выполняться и масштабироваться в Windows или в средах под управлением Linux.

• Azure Kubernetes Service (AKS) — это управляемое предложение Kubernetes, которое предоставляет полностью управляемые кластеры. Она обеспечивает встроенную непрерывную интеграцию и непрерывную доставку (CI/CD), а также встроенную систему управления и безопасность.

• Azure Logic Apps — это облачная платформа, которая создает и запускает автоматизированные рабочие процессы. Дополнительные сведения см. в примере эталонной архитектуры.

• Azure Container Apps — это полностью управляемая бессерверная служба контейнеров, которая позволяет запускать микрослужбы и контейнерные приложения на бессерверной платформе.

Для многорегионных развертываний рекомендуется использовать Azure Front Door для обеспечения быстрого, надежного и безопасного доступа между пользователями и статическим и динамическим веб-контентом приложений.

Дополнительные примеры защиты API шлюза приложений см. в статье "Защита API с помощью шлюза приложений и управления API".

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Для получения дополнительной информации см. в руководстве Well-Architected Framework.

Надежность

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

• Разверните не менее двух единиц масштаба управления API, распределённых по двум или более зонам доступности в каждом регионе. Отслеживайте метрики емкости и подготавливайте достаточные единицы емкости, чтобы можно было продолжать работать, даже если единицы в одной зоне доступности потеряны.

• Рекомендуется использовать уровень "Премиум", так как он поддерживает зоны доступности и многорегиональные развертывания. Эта возможность означает, что службы могут продолжать работать даже в том случае, если один регион или зона отключены. Эти функции помогают защитить приложение во время сбоя или аварий.

• Для аварийного восстановления настройте управление API с управляемым удостоверением, назначаемое пользователем, вместо удостоверения, назначаемого системой. При повторном развертывании или удалении ресурса удостоверение и его разрешения остаются на месте, чтобы можно было легко восстановить доступ. Используйте Azure Pipelines для автоматизации резервных копий. Определите, нужно ли развертывать службы в нескольких регионах для повышения надежности.

• Пиринг между виртуальными сетями обеспечивает высокую производительность в пределах региона, но имеет ограничение масштабируемости 500 сетей. Если необходимо подключить больше рабочих нагрузок, используйте дизайн hub-spoke или Azure Virtual WAN.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

• Политики проверки управления API проверяют запросы и ответы API на схему OpenAPI. Эти функции не являются заменой WAF, но они могут обеспечить дополнительную защиту от некоторых угроз. Добавление политик проверки может иметь последствия для производительности, поэтому мы рекомендуем использовать нагрузочные тесты производительности для оценки их влияния на пропускную способность API.

• Microsoft Defender для API обеспечивает полную защиту жизненного цикла, обнаружение и реагирование на API, опубликованные в службе управления API. Одна из ключевых возможностей заключается в обнаружении эксплойтов API Open Web Application Security Project (OWASP) Top 10 уязвимостей с помощью наблюдений за аномалиями во время выполнения с помощью обнаружения на основе машинного обучения и обнаружения на основе правил.

• Рабочие области управления API помогают упорядочивать и изолировать API. Такой подход облегчает контроль над тем, кто может получить доступ и управлять ими. Каждая рабочая область может иметь собственный набор разрешений, поэтому вы можете ограничить доступ только к пользователям или командам, которым он нужен. Это разделение снижает риск случайных изменений или несанкционированного доступа и поддерживает более безопасную среду API.

• Использовать секреты Key Vault в качестве именованных значений в политиках управления API для защиты конфиденциальной информации в политиках управления API.

• Используйте Шлюз приложений для внешнего доступа к внутреннему экземпляру службы управления API для защиты экземпляра управления API , защиты от распространенных эксплойтов веб-приложений и уязвимостей с помощью WAF и включения гибридного подключения.

• Разверните шлюз управления API в виртуальной сети для поддержки гибридного подключения и повышения безопасности.

• Пиринг между виртуальными сетями повышает производительность в регионе и обеспечивает частный обмен данными между виртуальными сетями.

• При использовании WAF вы создаете слой, проверяющий входящий трафик на вредоносную активность. Эта защита помогает блокировать распространенные угрозы, такие как внедрение SQL и междоменный скрипт. Шлюз приложений и распределенная защита от атак типа "отказ в обслуживании" (DDoS) помогают предотвратить перегрузку экземпляра службы управления API избыточным трафиком или наводнением подключений. Дополнительные сведения см. в статье "Защита API с помощью шлюза приложений и управления API".

• Частные конечные точки для Azure Functions позволяют безопасно подключаться к приложениям-функциям через частный IP-адрес в виртуальной сети. Эта настройка предотвращает подключение ваших функций к открытому интернету, что уменьшает риск несанкционированного доступа. В этой архитектуре частные конечные точки обеспечивают доступ к Azure Functions только доверенным ресурсам в вашей сети.

Обработка политик управления API за обратным прокси-сервером

Шлюз приложений с Web Application Firewall (WAF) размещается перед API Managment и обрабатывает весь трафик API, прежде чем он достигнет внутреннего экземпляра управления API. Цель заключается в добавлении пограничного уровня безопасности, который проверяет, фильтрует и направляет клиентские запросы, а управление API ориентировано на управление API, преобразование и интеграцию серверной части.

Однако эта многоуровневая топология имеет поведенческие последствия для определенных политик управления API: когда завершение TLS, принятие решений по маршрутизации или преобразования заголовков или соединений происходят на границе шлюза приложений, подсистема политик управления API может не видеть исходные сведения о клиентском запросе, который она ожидает. Это может привести к тому, что поведение политик будет отличаться от ситуации, когда управление API непосредственно доступно. Рассмотрим пример.

• Фильтрация на основе IP-адресов клиента: политики, например ip-filter , где можно разрешить или запретить трафик на основе исходных IP-адресов, теперь частный IP-адрес шлюза приложений будет отображаться как источник, а не фактический адрес клиента. В результате ip-filter политика должна быть тщательно запланирована и управляема, чтобы обеспечить фильтрацию правильного трафика.

• Предположения о упорядочении политик и контексте: политики управления API ожидают выполнения запросов с определенными заголовками, именами узлов или характеристиками запросов. Если шлюз приложений перезаписывает заголовки (для маршрутизации, пользовательских доменов или разгрузки SSL), контекст, на который применяются политики управления API ниже, могут не совпадать с тем, что было определено в этих политиках. Это может привести к несоответствию намерений клиента политикам маршрутизации, проверке или преобразованию внутри службы управления API.

Шлюз приложений и Менеджмент API становятся двумя уровнями принудительного применения, а представление Менеджмента API по входящим запросам отстоит на один шаг от исходного контекста клиента. Необходимо избегать использования политик в управлении API, которые зависят от необработанных клиентских атрибутов, если эти атрибуты не сохраняются на протяжении всего процесса, и может потребоваться разработать пользовательские политики на основе данных, доступных в HTTP-запросе.

Дополнительные рекомендации по сохранению данных, таких как заголовки узлов, см. в разделе "Сохранение исходного имени узла HTTP" между обратным прокси-сервером и серверным веб-приложением.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

• Это развертывание использует план Premium для поддержки возможностей зоны доступности и виртуальной сети. Если вам не нужны выделенные экземпляры, можно также использовать Flex Consumption, которая поддерживает как сетевой доступ, так и зоны доступности. Просмотрите калькулятор цен для этого развертывания.

• Для подтверждения концепций или прототипов рекомендуется использовать другие уровни управления API, такие как разработчик или стандартный.

Операционное превосходство

Операционная эффективность охватывает процессы эксплуатации, которые развертывают приложение и поддерживают его в рабочей среде. Для получения дополнительной информации см. Контрольный список для оценки проектирования с точки зрения операционной эффективности.

• Представьте конфигурации управления API в виде шаблонов для Azure Resource Manager и примите подход инфраструктуры как код (IaC).

• Используйте процесс CI/CD для управления, версионирования и обновления конфигураций управления API.

• Создайте пользовательские пробы работоспособности, чтобы проверить состояние экземпляра службы управления API. Используйте URL-адрес /status-0123456789abcdef для создания общей конечной точки работоспособности для службы управления API в шлюзе приложений.

• Сертификаты, обновленные в хранилище ключей, автоматически поворачиваются в службе управления API, что отражает изменения в течение четырех часов.

• Если вы используете средство DevOps, например Azure DevOps или GitHub, агенты, размещенные в облаке, или средства запуска работают через общедоступный Интернет. Так как для управления API в этой архитектуре задана внутренняя сеть, необходимо использовать агент DevOps, имеющий доступ к виртуальной сети. Агент DevOps помогает развертывать политики и другие изменения в интерфейсах API вашей архитектуры. Эти шаблоны CI/CD можно использовать для разделения процесса на части, чтобы команды разработчиков могли развертывать изменения для каждого API. Агенты DevOps инициируют шаблоны для обработки этих отдельных развертываний.

Развертывание этого сценария

Эта архитектура доступна в GitHub. Он содержит все необходимые файлы IaC и инструкции deployment.

Соавторы

Microsoft поддерживает эту статью. Следующие участники написали эту статью.

Основные авторы:

• Пит Мессина | Старший архитектор облачных решений
• Энтони Невико | Старший архитектор облачных решений

Чтобы просмотреть закрытые профили в LinkedIn, войдите в свою учетную запись LinkedIn.

Следующие шаги

• Терминология управления API
• Документация по шлюзу приложений

Связанные ресурсы

• Использование шлюзов API в микрослужбах
• топология сети Hub-периферийной сети в Azure
• Basic enterprise integration on Azure
• Защита API с помощью шлюза приложений и управления API