API становятся все более заметными в том, как компании и клиенты получают доступ к службам, как внутренним, так и внешним. Внутри системы API используются для доступа к бизнес-приложениям, домашним решениям и 3-сторонним интеграции. Внешние, больше компаний выглядят продуктивными и монетизировать свои API. Учитывая эту тенденцию, Управление API становится центральным компонентом стандартного подхода к управлению, управлению и публикации API для внутренних и внешних аудиторий.
С помощью Шлюз приложений Azure теперь можно защитить и ограничить доступ API, обслуживаемых через Управление API Azure. В этой статье описывается решение, в котором можно управлять внутренними и внешними API через один экземпляр Управление API. Вы можете поддерживать безопасное состояние от предоставления непосредственно через Интернет, но вместо этого он осуществляется через Шлюз приложений.
Примечание.
Эта архитектура используется в качестве основы руководства по Azure Управление API в целевых зонах Azure в Cloud Adoption Framework.
Архитектура
Эта архитектурная схема начинается со всего охватывающего поля, представляющего область подписки, зону Частная зона DNS, в которой частные домены будут разрешены, и область действия виртуальной сети APIM-CS. Поверх подписки — это поле, указывающее, что это локальная рабочая нагрузка. В поле есть значок сервера. Канал указывает подключение типа "сеть — сеть" или Azure ExpressRoute подключается к экземпляру Управление API в подписке Azure. Семь дополнительных небольших ящиков находятся внутри большого поля, где показана подписка Azure. Четыре поля находятся в верхней строке, а три находятся в нижней строке. Каждое отдельное поле представляет отдельную подсеть с подключенной группой безопасности сети. Слева в верхней строке есть общедоступный IP-адрес, подключенный к Шлюз приложений Azure в левой строке. Шлюз приложений также находится в одном из семи небольших полей с подсетью с именем подсети App GW. Справа — это другое поле, содержащее экземпляр Управление API с подсетью с подсетью APIM. Рядом с ним находится третье поле в верхней строке, которая содержит частную конечную точку для экземпляра Функции Azure в подсети с именем pe subnet. Правое поле в верхней строке — это серверная подсеть, содержащая приложения-функции Azure, план службы приложение Azure для функции и учетную запись хранения, связанную с приложением-функцией. В нижней строке, начиная с слева, — это поле, содержащее Бастион Azure в подсети Бастиона. Второе поле содержит виртуальную машину jumbox управления в подсети Jump Box. Последнее поле нижней строки — агент DevOps, содержащийся в подсети DevOps. В правом нижнем углу изображения находятся три общих ресурса с соответствующими значками. Слева направо представлены следующие поля: хранилище ключей, аналитика приложений и рабочая область log analytics. Существует два набора рабочих процессов. Первый рабочий процесс указывается в черных кругах, а другой рабочий процесс указан в синих кругах, которые будут описаны в последующих разделах. Черный рабочий процесс указывает на доступ к API, которые доступны во внешнем виде. Поток начинается с доступа пользователя к общедоступному IP-адресу. Затем стрелка указывает направление Шлюз приложений, от Шлюз приложений к частной конечной точке и из частной конечной точки в приложение-функцию. Синий рабочий процесс начинается с локального сервера со стрелкой, указывающей на экземпляр Управление API, с помощью значка конвейера, указывающего подключение типа "сеть — сеть" или через ExpressRoute. Остальная часть потока аналогична описанию выше: от Управление API до частной конечной точки и от частной конечной точки до функции Azure.
В этой архитектуре предполагается, что политики выполняются из акселератора целевой зоны Azure и что структура зависит от группы управления.
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
Гибридный сценарий (синие круги)
Для этого сценария требуется подключение типа "сеть — сеть" или подключение Azure ExpressRoute к локальной среде.
- Для локального приложения требуется доступ к внутреннему API, который обслуживается через Управление API Azure.
- Управление API подключается к внутренним API, размещенным в Функции Azure. Это подключение осуществляется через частную конечную точку, которая доступна через план Функции Azure Premium и размещается в собственной подсети.
- Частная конечная точка безопасно обращается к внутреннему API, размещенного в Функции Azure.
Сценарий внешнего доступа (черные круги)
- Внешнее приложение обращается к общедоступному IP-адресу или пользовательскому полному доменному имени, присоединенному к Шлюз приложений Azure.
- Шлюз приложений выступает в качестве брандмауэра веб-приложения, для которого требуются сертификаты PFX для завершения SSL.
- Управление API подключается к внутренним API, размещенным на Функции Azure, через частную конечную точку. Эта конечная точка доступна через план Функции Azure Premium и размещается в собственной подсети.
- Частная конечная точка безопасно обращается к внешнему доступному API, размещенного в Функции Azure.
Компоненты
Архитектура использует следующие компоненты:
Azure Управление API — это управляемая служба, которая позволяет управлять службами в гибридных и многооблачных средах. Управление API выступает в качестве фасада для абстрагирования серверной архитектуры, а также обеспечивает контроль и безопасность для наблюдения и потребления API для внутренних и внешних пользователей.
Функции Azure — это бессерверное решение, которое позволяет сосредоточиться на блоках кода, которые можно выполнять с минимальным управлением инфраструктурой. Функции могут размещаться в различных планах размещения, в то время как эта эталонная архитектура использует план premium из-за использования частных конечных точек.
Шлюз приложений Azure — это управляемая служба, которая выступает в качестве подсистемы балансировки нагрузки уровня 7 и брандмауэра веб-приложения. В этом сценарии шлюз приложений защищает внутренний экземпляр APIM, который позволяет использовать внутренний и внешний режим.
Зоны Azure DNS Частная зона DNS позволяют управлять доменными именами в виртуальной сети и разрешать их без необходимости реализовать пользовательское решение DNS. Зона Частная зона DNS может быть выровнена с одной или несколькими виртуальными сетями через каналы виртуальной сети. Из-за Функции Azure предоставления частной конечной точки, используемой этой эталонной архитектурой, необходимо использовать частную зону DNS.
Azure MonitorApplication Insights помогает разработчикам обнаруживать аномалии, диагностировать проблемы и понимать шаблоны использования. Application Insights предоставляет расширяемое управление производительностью приложений и мониторинг для динамических веб-приложений. Поддерживаются различные платформы, включая .NET, Node.js, Java и Python. Она поддерживает приложения, размещенные в Azure, локальной среде, в гибридной среде или в других общедоступных облаках. Application Insights входит в состав этой эталонной архитектуры, чтобы отслеживать поведение развернутого приложения.
Azure MonitorLog Analytics позволяет изменять и запускать запросы журналов с данными в журналах Azure Monitor, при необходимости из портал Azure. Разработчики могут выполнять простые запросы для набора записей или использовать Log Analytics для выполнения расширенного анализа. Затем они могут визуализировать результаты. Log Analytics настраивается в рамках этой эталонной архитектуры, чтобы агрегировать все журналы мониторинга для получения большего объема анализа и отчетов.
Azure Виртуальные машины — это вычислительный ресурс, который можно использовать для размещения множества различных рабочих нагрузок. В этой эталонной архитектуре виртуальные машины используются для предоставления сервера управления jumpbox, а также узла для агента DevOps или GitHub runner.
Azure Key Vault — это облачная служба, которая безопасно хранит и обращается к секретам, которые варьируются от ключей API и паролей до сертификатов и криптографических ключей. Эта эталонная архитектура использует Azure Key Vault для хранения SSL-сертификатов, используемых Шлюз приложений.
Бастион Azure — это платформа как услуга, подготовленная в виртуальной сети разработчика. Он обеспечивает безопасное подключение RDP/SSH к виртуальным машинам разработчика по протоколу TLS из портал Azure. При использовании Бастиона Azure виртуальные машины больше не требуют общедоступного IP-адреса для подключения через RDP/SSH. Эта эталонная архитектура использует Бастион Azure для доступа к агенту DevOps или серверу runner GitHub или серверу панели управления.
Если вы используете средство DevOps, например Azure DevOps или GitHub, агенты, размещенные в облаке, или средства выполнения работают через общедоступный Интернет. Так как для управления API в этой архитектуре задана внутренняя сеть, необходимо использовать агент DevOps, имеющий доступ к виртуальной сети. Агент DevOps поможет вам развернуть политики и другие изменения API в архитектуре. Их можно использовать для разбиения процесса и разрешения командам разработчиков развертывать изменения на api. Они выполняются бегунами DevOps.
Альтернативные варианты
Для серверных служб, к которым подключается экземпляр Управление API, доступны несколько альтернативных вариантов, помимо Функции Azure, который используется в этой эталонной реализации:
- Служба приложение Azure — это полностью управляемая служба на основе HTTP, которая создает, развертывает и масштабирует веб-приложения. Поддерживаются .NET, .NET Core, Java, Ruby, Node.js, PHP и Python. Приложения могут выполняться и масштабироваться в средах под управлением Windows или Linux.
- Служба Azure Kubernetes предлагает полностью управляемые кластеры Kubernetes для интегрированной непрерывной интеграции и непрерывной доставки (CI/CD), управления и безопасности.
- Azure Logic Apps — это облачная платформа, которая создает и запускает автоматизированные рабочие процессы. Пример эталонной архитектуры можно найти в базовой корпоративной интеграции в Azure.
- Приложения контейнеров Azure позволяют запускать микрослужбы и контейнерные приложения на бессерверной платформе.
Для развертываний в нескольких регионах рекомендуется использовать Azure Front Door , чтобы обеспечить быстрый, надежный и безопасный доступ между пользователями и статическим и динамическим веб-контентом ваших приложений.
Дополнительные примеры защиты API Шлюз приложений см. в статье "Защита API с помощью Шлюз приложений и Управление API".
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".
- Разверните по крайней мере два единици масштабирования Управление API, которые распределяются по двум зонам доступности в каждом регионе. Этот метод обеспечивает максимальную доступность и производительность.
- Пиринг между виртуальными сетями обеспечивает большую производительность в регионе, но он имеет ограничение масштабируемости до 500 сетей. Если требуется подключение к большему объему рабочих нагрузок, используйте периферийный дизайн концентратора или виртуальную глобальную сеть Azure.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
- Управление API политики проверки доступны для проверки запросов и ответов API на схему OpenAPI. Эти функции не являются заменой Брандмауэр веб-приложений, но они могут обеспечить дополнительную защиту от некоторых угроз. Добавление политик проверки может иметь последствия для производительности, поэтому мы рекомендуем использовать нагрузочные тесты производительности для оценки их влияния на пропускную способность API.
- Разверните Брандмауэр веб-приложений Azure (WAF) перед Управление API, чтобы обеспечить защиту от распространенных эксплойтов и уязвимостей веб-приложений.
- Примените именованные значения с секретами Key Vault для защиты конфиденциальной информации в политиках APIM.
- Используйте Шлюз приложений для внешнего доступа к внутреннему экземпляру APIM для защиты экземпляра APIM и включения гибридного подключения.
- Разверните шлюз Управление API в виртуальной сети для поддержки гибридного подключения и повышения безопасности.
- Пиринг между виртуальными сетями обеспечивает большую производительность в регионе, но он имеет ограничение масштабируемости до 500 сетей. Если требуется подключение к большему объему рабочих нагрузок, используйте периферийный дизайн концентратора или виртуальную глобальную сеть Azure.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
- Из-за необходимости поддержки зоны доступности и виртуальной сети мы выбрали уровень "Премиум" Управление API, следуя ценам для каждого региона. Кроме того, в этой рабочей нагрузке Функции Azure размещается в плане Premium из-за необходимости доступа к виртуальной сети.
- Для подтверждения концепции или прототипов рекомендуется использовать другие уровни Управление API (например, разработчик или стандартный).
Эффективность работы
Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".
- Управление API конфигурации должны представляться в виде шаблонов ARM, и следует принять в качестве менталитет инфраструктуры как кода.
- Используйте процесс CI/CD для управления, версией и обновлением конфигураций Управление API.
- Создайте пользовательские пробы работоспособности, чтобы проверить состояние экземпляра управления API. Используйте URL-адрес
/status-0123456789abcdefдля создания общей конечной точки работоспособности для службы APIM в шлюзе приложений. - Сертификаты, обновленные в хранилище ключей, автоматически поворачиваются в Управление API, что обновляется в течение 4 часов.
- Разверните по крайней мере два единици масштабирования Управление API, которые распределяются по двум зонам доступности в каждом регионе. Этот метод обеспечивает максимальную доступность и производительность.
Развертывание этого сценария
Эта архитектура доступна на сайте GitHub. Он содержит все необходимые файлы инфраструктуры как кода и инструкции по развертыванию.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
- Пит Мессина | Старший архитектор облачных решений
- Энтони Невико | Старший архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Руководство по Cloud Adoption Framework для Azure Управление API в целевых зонах Azure
- CI/CD для Управление API с помощью шаблонов Azure Resource Manager
- Введение в Управление API
- Управление API с помощью APIM
- Управление API ресурсы для начала работы
См. следующие ключевые ресурсы:
- Операции API
- Документация по Azure Управление API
- Основные понятия Azure Управление API
- документация по Шлюз приложений
Дополнительные сведения об этих ключевых службах:
- обзор Функции Azure
- Зоны Частная зона DNS Azure
- Обзор приложение Azure Insights
- Обзор Azure Log Analytics
- Обзор Виртуальных машин Azure
- Основные понятия Azure Key Vault
- Обзор Бастиона Azure