Поделиться через

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

  • Статья

Примечание

Azure Spring Apps — это новое название службы Azure Spring Cloud. Старое название будет еще некоторое время встречаться в наших материалах, пока мы не обновим ресурсы, такие как снимки экрана, видео и схемы.

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

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

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

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

План Azure Spring Apps Enterprise состоит из службы сборки VMware Tanzu®, службы конфигурации приложений для VMware Tanzu®, реестра служб VMware Tanzu®, шлюза Spring Cloud для 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 должны обмениваться данными через конечные точки служб или приватный канал.
  • Неактивные данные должны быть зашифрованы.
  • Передаваемые данные тоже должны быть зашифрованы.
  • Могут использоваться конвейеры развертывания DevOps (например, Azure DevOps), для которых требуется сетевое подключение к Azure Spring Apps.
  • Исходящий трафик должен проходить через центральный сетевой виртуальный модуль (NVA) (например, Брандмауэр Azure).
  • Если для загрузки свойств конфигурации из репозитория используется Сервер конфигурации Azure Spring Apps, репозиторий должен быть частным.
  • Для реализации модели безопасности "Никому не доверяй" необходимо хранить секреты, сертификаты и учетные данные в безопасном хранилище. Для этого рекомендуем службу Azure Key Vault.
  • Разрешение имен локальных узлов и в облаке должно быть двунаправленным.
  • Нет прямого исходящего трафика в общедоступный Интернет, кроме трафика с панели управления.
  • Группы ресурсов, управляемые развертыванием Azure Spring Apps, не должны изменяться.
  • Подсети, управляемые развертыванием Azure Spring Apps, не должны изменяться.

В списке ниже представлены компоненты, из которых состоит проект:

  • Локальная сеть
    • Служба доменных имен (DNS)
    • Шлюз
  • Подписка концентратора
    • Подсеть Шлюза приложений
    • Подсеть Брандмауэра 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 должны обмениваться данными через конечные точки служб или приватный канал.
  • Неактивные данные должны быть зашифрованы.
  • Передаваемые данные тоже должны быть зашифрованы.
  • Могут использоваться конвейеры развертывания DevOps (например, Azure DevOps), для которых требуется сетевое подключение к Azure Spring Apps.
  • Исходящий трафик должен проходить через центральный сетевой виртуальный модуль (NVA) (например, Брандмауэр Azure).
  • Входящий трафик должен управляться хотя бы Шлюзом приложений Azure или службой Azure Front Door.
  • Адреса с маршрутизацией через Интернет должны храниться в общедоступной зоне DNS Azure.
  • Для реализации модели безопасности "Никому не доверяй" необходимо хранить секреты, сертификаты и учетные данные в безопасном хранилище. Для этого рекомендуем службу Azure Key Vault.
  • Разрешение имен локальных узлов и в облаке должно быть двунаправленным.
  • Нет прямого исходящего трафика в общедоступный Интернет, кроме трафика с панели управления.
  • Группы ресурсов, управляемые развертыванием Azure Spring Apps, не должны изменяться.
  • Подсети, управляемые развертыванием Azure Spring Apps, не должны изменяться.

В списке ниже представлены компоненты, из которых состоит проект:

  • Локальная сеть
    • Служба доменных имен (DNS)
    • Шлюз
  • Подписка концентратора
    • Подсеть Шлюза приложений
    • Подсеть Брандмауэра 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.

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

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

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

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

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

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

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

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

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

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

Azure Spring Apps обеспечивает разные аспекты эффективности операционных процессов. Вы можете совместить эти аспекты, чтобы служба работала в производственных средах по-настоящему эффективно:

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

Надежность

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

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

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

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

Система управления

Главным аспектом системы управления этой архитектуры является изоляция сетевых ресурсов. В рамках службы CCM, DCS-08 рекомендует контролировать входящий и исходящий трафик центра обработки данных. Для должного контроля архитектура фильтрует трафик "восток — запад" между ресурсами с помощью группы безопасности сети. Кроме того, архитектура фильтрует трафик между центральными службами в концентраторе и ресурсами на периферии. С помощью Брандмауэра Azure архитектура управляет трафиком между Интернетом и ресурсами в составе архитектуры.

В списке ниже приведены элементы управления для обеспечения безопасности центра обработки данных.

Идентификатор управления CCM от CSA Домен управления CCM от CSA
DCS-08 Учет неавторизованных пользователей для безопасности центра обработки данных

Сеть

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

В списке ниже представлены элементы управления CCM, призванные обеспечить безопасность сети.

Идентификатор управления CCM от CSA Домен управления CCM от CSA
IPY-04 Сетевые протоколы
IVS-06 Безопасность сети

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

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

Идентификатор элемента управления CIS Описание элемента управления CIS
6.2 Убедитесь, что доступ по протоколу SSH через Интернет заблокирован.
6.3 Убедитесь, что базы данных SQL разрешают входящий трафик 0.0.0.0/0 (любой IP-адрес).
6,5 Убедитесь, что служба "Наблюдатель за сетями" включена.
6.6 Убедитесь, что входящий трафик по UDP не может попасть в Интернет.

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

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

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

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

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

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

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

Идентификатор элемента управления CIS Описание элемента управления CIS
8.1 Убедитесь, что для всех ключей задана дата окончания срока действия.
8.2 Убедитесь, что для всех секретов задана дата окончания срока действия.
8.4 Убедитесь, что хранилище ключей поддерживает восстановление.

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

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

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

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