Архитектура целевой зоны управления API Azure

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

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

Функции Azure

.NET

API становятся все более неотъемлемой частью того, как организации и их клиенты получают доступ к службам, как внутри внутренних систем, так и через внешние каналы. Внутренние ИНТЕРФЕЙСы API упрощают доступ к бизнес-приложениям, частным решениям и интеграции партнеров. Во внешних условиях растущее число организаций сосредоточено на повышении производительности и создании доходов за счет монетизации API. Учитывая эту тенденцию, управление API Azure выступает в качестве основного элемента в стандартизованном управлении, публикации и надзоре API как для внутренних, так и для внешних заинтересованных лиц.

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

Примечание.

Эта архитектура служит основой руководства по управлению API в целевой зоне Azure в Cloud Adoption Framework для Azure.

Архитектура

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

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

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

Общедоступные IP-адреса назначаются шлюзу приложений, который служит точкой входа для внешнего трафика. Эта конечная точка предоставляет API через личный домен.
Шлюз приложений развертывается в собственной подсети и защищен политиками брандмауэра веб-приложений (WAF) для проверки и фильтрации входящих запросов.
Трафик направляется из шлюза приложений в службу управления API (Premium), которая находится в отдельной подсети управления API. Экземпляр управления API настраивается во внутреннем режиме, что предотвращает прямой открытый доступ.
Частные конечные точки используются для безопасного подключения управления API к серверным серверам приложений, предоставляемым только виртуальной сети. Управление 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 — это полностью управляемая служба на основе HTTP, которая создает, развертывает и масштабирует веб-приложения. Он поддерживает .NET, .NET Core, Java, Ruby, Node.js, PHP и Python. Приложения могут выполняться и масштабироваться в средах под управлением Windows или Linux.
Служба Azure Kubernetes (AKS) — это управляемое предложение Kubernetes, которое предоставляет полностью управляемые кластеры. Она обеспечивает встроенную непрерывную интеграцию и непрерывную доставку (CI/CD), а также встроенную систему управления и безопасность.
Azure Logic Apps — это облачная платформа, которая создает и запускает автоматизированные рабочие процессы. Дополнительные сведения см. в примере эталонной архитектуры.
Приложения контейнеров Azure — это полностью управляемая бессерверная служба контейнеров, которая позволяет запускать микрослужбы и контейнерные приложения на бессерверной платформе.

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

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

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

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

Надежность

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

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

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

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

Политики проверки управления 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 позволяют безопасно подключаться к приложениям-функциям через частный IP-адрес в виртуальной сети. Эта настройка предотвращает воздействие ваших функций в общедоступный Интернет, что снижает риск несанкционированного доступа. В этой архитектуре частные конечные точки гарантируют, что доступ к Функциям Azure может получить только доверенные ресурсы в вашей сети.

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

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

Это развертывание использует план 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 и инструкции по развертыванию.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие участники написали эту статью.

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

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

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

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

Обратная связь

Была ли эта страница полезна?