API становятся все более заметными в том, как компании и клиенты получают доступ к службам как внутри организации, так и за пределами. На внутреннем сервере API используются для доступа к бизнес-приложениям, решениям домашней сборки и сторонним интеграциям. Внешне все больше компаний выглядят продуктивными и монетизируют свои API. Учитывая эту тенденцию, Управление API становится центральным компонентом стандартного подхода к управлению, управлению и публикации API как для внутренней, так и для внешней аудитории.
С помощью Шлюз приложений Azure теперь можно защитить и ограничить доступ к API, которые обслуживаются через Azure Управление API. В этой статье описывается решение, в котором можно управлять как внутренними, так и внешними API с помощью одного экземпляра Управление API. Вы можете поддерживать безопасное состояние, не предоставляя его непосредственно через Интернет, но вместо этого доступ к нему осуществляется через Шлюз приложений.
Примечание
Эта архитектура используется в качестве основы акселератора целевой зоны Azure Управление API в Cloud Adoption Framework.
Архитектура
Эта схема архитектуры начинается с комплексного поля, представляющего область подписки, Частная зона DNS зоны, в которой будут разрешаться частные домены, и область имен виртуальной сети APIM-CS VNet. В верхней части подписки находится поле, указывающее, что это локальная рабочая нагрузка. В поле есть значок сервера. Канал указывает подключение типа "сеть — сеть" или Azure ExpressRoute подключается к экземпляру Управление API в подписке Azure. Семь дополнительных небольших полей находятся внутри большого поля, где отображается подписка Azure. Четыре поля находятся в верхней строке, а три — в нижнем. Каждое отдельное поле представляет отдельную подсеть с подключенной группой безопасности сети. Слева в верхней строке находится общедоступный IP-адрес, прикрепленный к Шлюз приложений Azure. Шлюз приложений также находится в одном из семи небольших полей с подсетью App GW. Справа находится еще одно поле, содержащее экземпляр Управление API с подсетью APIM. Рядом с ним находится третье поле в верхней строке, которое содержит частную конечную точку для экземпляра Функции Azure в подсети с именем PE subnet. Самый правый прямоугольник в верхней строке — это серверная подсеть, содержащая приложения-функции Azure, план Служба приложений Azure для функции и учетную запись хранения, связанную с приложением-функцией. В нижней строке, начиная слева, находится поле, содержащее Бастион Azure в подсети Бастиона. Второе поле содержит виртуальную машину jumbox управления в подсети Jump Box. Последним полем в нижней строке является агент DevOps, содержащийся в подсети DevOps. В нижней правой части изображения находятся три общих ресурса с соответствующими значками. Слева направо находятся следующие поля: хранилище ключей, application insights и рабочая область Log Analytics. Существует два набора рабочих процессов. Первый рабочий процесс обозначается черными кругами, а другой — синими кругами, которые будут описаны в последующих разделах. Черный рабочий процесс указывает на доступ к API, которые доступны извне. Поток начинается с пользователя, который обращается к общедоступному IP-адресу. Затем стрелка указывает на направление Шлюз приложений, от Шлюз приложений к частной конечной точке и от частной конечной точки к приложению-функции. Синий рабочий процесс начинается с локального сервера со стрелкой, указывающей на экземпляр Управление API, через значок конвейера, указывающий подключение типа "сеть — сеть" или через ExpressRoute. Остальная часть потока аналогична описанной выше: от Управление API до частной конечной точки и от частной конечной точки до Функции Azure.
В этой архитектуре предполагается, что политики применяются из акселератора целевой зоны Azure и что структура управляется вниз от группы управления.
Скачайте файл Visio этой архитектуры.
Рабочий процесс
Гибридный сценарий (синие круги)
Для этого сценария требуется подключение типа "сеть — сеть" или Azure ExpressRoute к локальной среде.
- Локальному приложению требуется доступ к внутреннему API, который обслуживается через azure Управление API.
- Управление API подключается к интерфейсу API серверной части, размещенным на Функции Azure. Это подключение осуществляется через частную конечную точку, доступную через план Функции Azure Premium и размещенную в собственной подсети.
- Частная конечная точка обеспечивает безопасный доступ к внутреннему API, размещенного на Функции Azure.
Сценарий внешнего доступа (черные круги)
- Внешнее приложение обращается к общедоступному IP-адресу или пользовательскому полному доменному имени, присоединенному к Шлюз приложений Azure.
- Шлюз приложений выступает в качестве брандмауэра веб-приложения, который требует PFX-сертификатов для завершения SSL-подключений.
- Управление API подключается к API серверной части, размещенным в Функции Azure, через частную конечную точку. Эта конечная точка доступна через план Функции Azure Premium и размещается в собственной подсети.
- Частная конечная точка обеспечивает безопасный доступ к внешнему API, размещенного на Функции Azure.
Компоненты
В архитектуре используются следующие компоненты:
Azure Управление API — это управляемая служба, которая позволяет управлять службами в гибридных и многооблачных средах. Управление API выступает в качестве фасада для абстрагирования архитектуры серверной части и обеспечивает контроль и безопасность для наблюдаемости и потребления API как для внутренних, так и для внешних пользователей.
Функции Azure — это бессерверное решение, которое позволяет сосредоточиться на блоках кода, которые можно выполнять с минимальным управлением инфраструктурой. Функции могут размещаться в различных планах размещения, тогда как эта эталонная архитектура использует план "Премиум" из-за использования частных конечных точек.
Шлюз приложений 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.
Azure Key Vault — это облачная служба, которая безопасно хранит и обращается к секретам, которые варьируются от ключей API и паролей до сертификатов и криптографических ключей. Эта эталонная архитектура использует Key Vault Azure для хранения SSL-сертификатов, используемых Шлюз приложений.
Бастион Azure — это платформа как услуга, подготовленная в виртуальной сети разработчика. Она обеспечивает безопасное подключение по протоколу RDP или SSH к виртуальным машинам разработчика по протоколу TLS из портал Azure. В Бастионе Azure виртуальным машинам больше не требуется общедоступный IP-адрес для подключения по протоколу RDP или SSH. Эта эталонная архитектура использует Бастион Azure для доступа к агенту DevOps, серверу средства выполнения 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 размещается в плане "Премиум" из-за необходимости доступа к виртуальной сети.
- Для подтверждения концепции или прототипов рекомендуется использовать другие уровни Управление API (например, Developer или Standard).
эффективность работы;
Эффективность работы охватывает операционные процессы, которые развертывают приложение и сохраняют его работу в рабочей среде. Дополнительные сведения см. в статье Общие сведения о принципе эффективности операций.
- Управление API конфигурации должны быть представлены в виде шаблонов ARM, и вы должны использовать менталитет "инфраструктура как код".
- Используйте процесс CI/CD для управления конфигурациями Управление API, их версий и обновления.
- Создайте пользовательские пробы работоспособности, которые помогут проверить состояние экземпляра управления API. Используйте URL-адрес
/status-0123456789abcdef, чтобы создать общую конечную точку работоспособности для службы APIM в шлюзе приложений. - Сертификаты, обновленные в хранилище ключей, автоматически сменяются в Управление API, которая обновляется в течение 4 часов.
- Разверните по крайней мере две единицы масштабирования Управление API, распределенные по двум зонам доступности для каждого региона. Этот метод обеспечивает максимальную доступность и производительность.
Развертывание этого сценария
Эта архитектура доступна на сайте GitHub. Он содержит все необходимые файлы инфраструктуры как кода и инструкции по развертыванию.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими авторами.
Основные авторы:
- Пит Мессина | Старший архитектор облачных решений
- Энтони Невико | Старший архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Дальнейшие действия
- Эта же архитектура используется в качестве основы акселератора целевой зоны Azure Управление API в Cloud Adoption Framework.
- Непрерывная интеграция и непрерывное развертывание службы управления API Azure посредством шаблонов Azure Resource Manager
- Введение в Управление API
- Управление API с помощью APIM
- Управление API ресурсы для начала работы
Ознакомьтесь со следующими основными ресурсами:
- Ускоритель целевой зоны Azure
- Операции API
- Документация по Azure Управление API
- Основные понятия Azure Управление API
- Документация по Шлюзу приложений
- Ускоритель целевой зоны Azure Управление API
Узнайте больше об этих ключевых службах:
- Обзор Функции Azure
- Частные зоны DNS Azure.
- Обзор приложение Azure Insights
- Обзор Azure Log Analytics
- Обзор Виртуальных машин Azure
- Основные понятия Azure Key Vault
- Обзор Бастиона Azure