Эталонная архитектура Azure Spring Apps

Эта статья относится к: ✔️ Standard ✔️ Enterprise

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

Существует два варианта azure Spring Apps: план "Стандартный" и "Корпоративный".

План Azure Spring Apps standard состоит из сервера конфигурации Spring Cloud, реестра службы Spring Cloud и службы сборки kpack.

План Azure Spring Apps Enterprise состоит из службы сборки VMware Tanzu®, службы конфигурации приложений для VMware Tanzu®, реестра служб VMware Tanzu®, Spring Cloud Gateway для VMware Tanzu® и портала API для VMware Tanzu®.

Сведения о реализации этой архитектуры см. в справочной архитектуре Azure Spring Apps на GitHub.

Варианты развертывания для этой архитектуры включают Azure Resource Manager (ARM), Terraform, Azure CLI и Bicep. Артефакты в этом репозитории предоставляют основу, которую можно настроить для вашей среды. Вы можете группировать такие ресурсы, как Брандмауэр Azure или Шлюз приложений, в разные группы ресурсов или подписки. Это группирование помогает отделять различные функции, такие как ИТ-инфраструктура, безопасность, команды бизнес-приложений и т. д.

Планирование адресного пространства

Для Azure Spring Apps требуется две выделенные подсети:

• Время выполнения службы
• Приложения Spring Boot

Для каждой из этих подсетей требуется выделенный кластер Azure Spring Apps. Несколько кластеров не могут совместно использовать одни и те же подсети. Минимальный размер каждой подсети — /28. Количество экземпляров приложений, которые azure Spring Apps может поддерживать, зависит от размера подсети. Подробные требования к виртуальной сети можно найти в разделе "Требования к виртуальной сети" в разделе "Развертывание Azure Spring Apps" в виртуальной сети.

Случаи использования

Типичные способы использования этой архитектуры:

• Частные приложения: внутренние приложения, развернутые в гибридных облачных средах
• Приложения для публичного доступа: ориентированные на внешний интерфейс приложения.

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

Частные приложения

В следующем списке описаны требования к инфраструктуре для частных приложений. Эти требования являются типичными в строго регулируемых средах.

• Подсеть должна иметь только один экземпляр Azure Spring Apps.
• Соблюдение по крайней мере одного эталона безопасности должно быть обеспечено.
• Записи службы доменных имен узла приложения (DNS) должны храниться в частной службе DNS Azure.
• Зависимости службы Azure должны взаимодействовать через Service Endpoints или Private Link.
• Неактивные данные должны быть зашифрованы.
• Данные при передаче должны быть зашифрованы.
• Конвейеры развертывания DevOps можно использовать (например, Azure DevOps) и требовать сетевого подключения к Azure Spring Apps.
• Исходящий трафик должен проходить через центральное сетевое виртуальное устройство (NVA) (например, брандмауэр Azure).
• Если сервер конфигурации Azure Spring Apps используется для загрузки свойств конфигурации из репозитория, репозиторий должен быть частным.
• Подход "Zero Trust" от Microsoft требует, чтобы секреты, сертификаты и учетные данные хранились в безопасном хранилище. Рекомендуемая служба — Azure Key Vault.
• Разрешение имен локальных узлов и в облаке должно быть двунаправленным.
• Нет прямого исходящего трафика в общедоступный Интернет, за исключением трафика плоскости управления.
• Группы ресурсов, управляемые развертыванием Azure Spring Apps, не должны быть изменены.
• Подсети, управляемые развертыванием Azure Spring Apps, не должны быть изменены.

В следующем списке показаны компоненты, составляющие структуру:

• Локальная сеть
  • Служба доменных имен (DNS)
  • Шлюз
• Подписка на хаб
  • Подсеть Шлюза приложений (Application Gateway)
  • Подсеть брандмауэра Azure
  • Подсеть общих служб
• Подключенная подписка
  • Подсеть Бастиона Azure
  • Одноранговый узел виртуальной сети

В следующем списке описаны службы Azure в этой эталонной архитектуре:

• Azure Key Vault: аппаратная служба управления учетными данными с жесткой интеграцией со службами удостоверений Майкрософт и вычислительными ресурсами.

• Azure Monitor: комплексный набор служб мониторинга для приложений, развертывающих как в Azure, так и в локальной среде.

• Azure Pipelines: полностью многофункциональная служба непрерывной интеграции и непрерывной разработки (CI/CD), которая может автоматически развертывать обновленные приложения Spring Boot в Azure Spring Apps.

• Microsoft Defender для облака: единая система управления безопасностью и защиты от угроз для рабочих нагрузок в локальной среде, нескольких облаках и Azure.

• Azure Spring Apps: управляемая служба, разработанная и оптимизированная специально для приложений Spring Boot на основе Java и приложений Steeltoe на основе .NET.

На следующих схемах представлен хорошо спроектированный концентратор и периферийный дизайн, который отвечает указанным выше требованиям:

Общедоступные приложения

В следующем списке описаны требования к инфраструктуре для общедоступных приложений. Эти требования являются типичными в строго регулируемых средах.

• Подсеть должна иметь только один экземпляр Azure Spring Apps.
• Соблюдение по крайней мере одного эталона безопасности должно быть обеспечено.
• Записи службы доменных имен узла приложения (DNS) должны храниться в частной службе DNS Azure.
• Защита от атак DDoS Azure должна быть включена.
• Зависимости службы Azure должны взаимодействовать через Service Endpoints или Private Link.
• Неактивные данные должны быть зашифрованы.
• Данные при передаче должны быть зашифрованы.
• Конвейеры развертывания DevOps можно использовать (например, Azure DevOps) и требовать сетевого подключения к Azure Spring Apps.
• Исходящий трафик должен проходить через центральное сетевое виртуальное устройство (NVA) (например, брандмауэр Azure).
• Входящий трафик должен управляться как минимум шлюзом приложений или Azure Front Door.
• Адреса, которые могут маршрутизироваться в Интернете, должны храниться в Azure Public DNS.
• Подход "Zero Trust" от Microsoft требует, чтобы секреты, сертификаты и учетные данные хранились в безопасном хранилище. Рекомендуемая служба — Azure Key Vault.
• Разрешение имен локальных узлов и в облаке должно быть двунаправленным.
• Нет прямого исходящего трафика в общедоступный Интернет, за исключением трафика плоскости управления.
• Группы ресурсов, управляемые развертыванием Azure Spring Apps, не должны быть изменены.
• Подсети, управляемые развертыванием Azure Spring Apps, не должны быть изменены.

В следующем списке показаны компоненты, составляющие структуру:

• Локальная сеть
  • Служба доменных имен (DNS)
  • Шлюз
• Подписка на хаб
  • Подсеть Шлюза приложений (Application Gateway)
  • Подсеть брандмауэра Azure
  • Подсеть общих служб
• Подключенная подписка
  • Подсеть Бастиона Azure
  • Одноранговый узел виртуальной сети

В следующем списке описаны службы Azure в этой эталонной архитектуре:

• Брандмауэр приложений Azure: функция шлюза приложений Azure, которая обеспечивает централизованную защиту приложений от распространенных эксплойтов и уязвимостей.

• Шлюз приложений Azure: подсистема балансировки нагрузки, обрабатывающая трафик приложений и обеспечивающая разгрузку TLS на уровне 7.

• Azure Key Vault: аппаратная служба управления учетными данными с жесткой интеграцией со службами удостоверений Майкрософт и вычислительными ресурсами.

• Azure Monitor: комплексный набор служб мониторинга для приложений, развертывающих как в Azure, так и в локальной среде.

• Azure Pipelines: полностью многофункциональная служба непрерывной интеграции и непрерывной разработки (CI/CD), которая может автоматически развертывать обновленные приложения Spring Boot в Azure Spring Apps.

• Microsoft Defender для облака: единая система управления безопасностью и защиты от угроз для рабочих нагрузок в локальной среде, нескольких облаках и Azure.

• Azure Spring Apps: управляемый сервис, разработанный и оптимизированный специально для приложений Spring Boot на основе Java и приложений Steeltoe на основе .NET.

На следующих схемах отражена хорошо спроектированная звездообразная (hub-and-spoke) архитектура, которая отвечает указанным выше требованиям. Только виртуальная сеть концентратора взаимодействует с Интернетом:

Локальное подключение Azure Spring Apps

Приложения в Azure Spring Apps могут взаимодействовать с различными ресурсами Azure, локальной средой и внешними ресурсами. С помощью центральной и периферийной структуры приложения могут маршрутизировать трафик вне сети или в локальную сеть с помощью Express Route или виртуальной частной сети типа "сеть — сеть" (VPN).

Рекомендации по платформе Azure с продуманной архитектурой

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

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

Из-за природы распределенной системы разрастание инфраструктуры является реальностью. Эта реальность приводит к непредвиденным и неконтролируемым затратам. Azure Spring Apps создается с помощью компонентов, масштабируемых для удовлетворения спроса и оптимизации затрат. Основной частью этой архитектуры является служба Azure Kubernetes (AKS). Сервис предназначен для снижения сложности и эксплуатационных затрат на управление Kubernetes, что включает повышение эффективности операционных затрат кластера.

Вы можете развернуть различные приложения и типы приложений в одном экземпляре Azure Spring Apps. Служба поддерживает автоматическое масштабирование приложений, активируемое метриками или расписаниями, которые могут повысить эффективность использования и затрат.

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

Эффективность работы

Azure Spring Apps решает несколько аспектов эффективности работы. Эти аспекты можно объединить, чтобы служба эффективно работала в рабочих средах, как описано в следующем списке:

• Вы можете использовать Azure Pipelines, чтобы обеспечить надежность и согласованность развертываний, помогая избежать человеческой ошибки.
• Azure Monitor и Application Insights можно использовать для хранения данных журнала и телеметрии. Вы можете оценить собранные данные журнала и метрик, чтобы обеспечить работоспособность и производительность приложений. Мониторинг производительности приложений (APM) полностью интегрирован в службу через агент Java. Этот агент обеспечивает видимость всех развернутых приложений и зависимостей, не требуя дополнительного кода. Дополнительные сведения см. в записи блога, в статье о мониторинге приложений и зависимостей в Azure Spring Apps.
• Вы можете использовать Microsoft Defender для Облака, чтобы обеспечить безопасность приложений, предоставив платформу для анализа и оценки предоставленных данных.
• Служба поддерживает различные шаблоны развертывания. Дополнительные сведения см. в статье "Настройка промежуточной среды в Azure Spring Apps".

Надёжность

Azure Spring Apps основан на AKS. Хотя AKS проявляет уровень устойчивости с помощью кластеризации, данная эталонная архитектура идет еще дальше, включая службы и архитектурные соображения, чтобы повысить доступность приложения, если происходит сбой компонента.

Опираясь на хорошо определенный концентратор и периферийный дизайн, основа этой архитектуры гарантирует, что ее можно развернуть в нескольких регионах. В случае использования частного приложения архитектура использует Частный DNS Azure для обеспечения непрерывной доступности во время географического сбоя. В случае использования общедоступного приложения Azure Front Door и Шлюз приложений Azure обеспечивают доступность.

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

Безопасность этой архитектуры решается его соблюдением отраслевых элементов управления и эталонных показателей. В этом контексте "контроль" означает краткие и четко определенные рекомендации, такие как "Использование принципа наименьших привилегий при реализации доступа к информационной системе. IAM-05" Элементы управления в этой архитектуре относятся к Матрице управления Облаком (CCM) Альянсом Облачной Безопасности (CSA) и Microsoft Azure Foundations Benchmark (MAFB) Центром Интернет-безопасности (CIS). В применяемых элементах управления основное внимание уделяется основным принципам проектирования безопасности системы управления, сети и безопасности приложений. Вы несете ответственность за управление принципами проектирования идентификации, управления доступом и хранилищем в контексте их связи с целевой инфраструктурой.

Управление

Основной аспект управления, на который обращается эта архитектура, заключается в сегрегации путем изоляции сетевых ресурсов. В CCM DCS-08 рекомендует управление входящего трафика и исходящего трафика для центра обработки данных. Для соблюдения требований контроля архитектура использует дизайн "центр и периферия" с использованием групп безопасности сети (NSG) для фильтрации восточно-западного трафика между ресурсами. Архитектура также фильтрует трафик между центральными службами в концентраторе и ресурсами в периферийной части. В архитектуре используется экземпляр брандмауэра Azure для управления трафиком между Интернетом и ресурсами в архитектуре.

В следующем списке показан элемент управления, который обращается к безопасности центра обработки данных в этой ссылке:

Сеть

Схема сети, поддерживающая эту архитектуру, является производной от традиционной модели "концентратор - периферия". Это решение гарантирует, что сетевая изоляция является базовой конструкцией. Элемент управления CCM IVS-06 рекомендует ограничить и отслеживать трафик между сетями и виртуальными машинами между доверенными и ненадежными окружениями. Эта архитектура применяет управление с помощью реализации сетевых групп безопасности для восточно-западного трафика (в пределах центра обработки данных) и брандмауэра Azure для северно-южного трафика (за пределами "центра обработки данных"). Элемент управления CCM IPY-04 рекомендует инфраструктуре использовать безопасные сетевые протоколы для обмена данными между службами. Службы Azure, поддерживающие эту архитектуру, используют стандартные безопасные протоколы, такие как TLS для HTTP и SQL.

В следующем списке показаны элементы управления CCM, которые обращаются к сетевой безопасности в этой ссылке:

Реализация сети еще более защищена путем определения элементов управления из MAFB. Элементы управления гарантируют, что доступ в среду ограничен из общедоступного Интернета.

В следующем списке показаны меры контроля CIS, которые касаются сетевой безопасности в этом контексте.

Azure Spring Apps требует исходящего трафика управления из Azure при развертывании в защищенной среде. Необходимо разрешить правила сети и приложений, перечисленные в обязанностях клиента для запуска Azure Spring Apps в виртуальной сети.

Безопасность приложений

Этот принцип проектирования охватывает основные компоненты удостоверений, защиты данных, управления ключами и конфигурации приложений. По проектированию приложение, развернутое в Azure Spring Apps, выполняется с минимальными привилегиями, необходимыми для работы. Набор элементов управления авторизацией напрямую связан с защитой данных при использовании службы. Управление ключами укрепляет этот многоуровневый подход к безопасности приложений.

В следующем списке показаны элементы управления CCM, которые обращаются к управлению ключами в этой ссылке:

Из CCM, EKM-02 и EKM-03 рекомендуют политики и процедуры для управления ключами и использования протоколов шифрования для защиты конфиденциальных данных. EKM-01 рекомендует, чтобы все криптографические ключи имели идентифицируемых владельцев, чтобы их можно было управлять. EKM-04 рекомендует использовать стандартные алгоритмы.

В следующем списке показаны элементы управления CIS, которые относятся к управлению ключами в этом контексте:

Элементы управления CIS 8.1 и 8.2 рекомендуют устанавливать даты окончания срока действия учетных данных, чтобы гарантировать регулярную смену. Контроль CIS 8.4 гарантирует, что содержимое хранилища ключей можно восстановить для обеспечения непрерывности бизнес-процессов.

Аспекты безопасности приложений позволяют использовать эту эталонную архитектуру для поддержки рабочей нагрузки Spring в Azure.

Дальнейшие действия

Изучите эту эталонную архитектуру с помощью развертываний ARM, Terraform и Azure CLI, доступных в репозитории эталонной архитектуры Azure Spring Apps .