Базовая архитектура Azure Виртуальные машины в целевой зоне Azure

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

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

Как владелец рабочей нагрузки вы можете выгрузить управление общими ресурсами в центральные команды, чтобы сосредоточиться на усилиях по разработке рабочих нагрузок. В этой статье представлена перспектива группы рабочей нагрузки. Рекомендации, которые предназначены для команды платформы, указаны.

Макет статьи

Архитектура	Решение по проектированию	Подход Azure Well-Architected Framework
▪ Схема архитектуры ▪ Ресурсы рабочей нагрузки ▪ Федеративные ресурсы	▪ Настройка подписки ▪ Требования к сети ▪ Изменения в структуре сети из базового плана ▪ Мониторинга ▪ Соответствие исправлений ▪ Управление организацией ▪ Управление изменениями	▪ Надежность ▪ Безопасности ▪ Оптимизация затрат

Архитектура

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

Компоненты

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

Ресурсы группы рабочей нагрузки

Следующие ресурсы остаются в основном неизменными из базовой архитектуры.

• Azure Виртуальные машины — это платформа приложений. Вычислительные ресурсы распределяются между зонами доступности.

• Azure Load Balancer используется для приватного балансировки трафика между интерфейсными виртуальными машинами и внутренними виртуальными машинами. Подсистема балансировки нагрузки распределяет трафик на виртуальные машины между зонами.

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

• Azure Key Vault используется для хранения секретов и сертификатов приложений.

• Azure Monitor, Log Analytics и Application Аналитика используются для сбора, хранения и визуализации данных наблюдаемости.

• Политика Azure используется для применения политик, относящихся к рабочей нагрузке.

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

• Периферийные подсети виртуальной сети и группы безопасности сети (NSG), размещенные в этих подсетях для поддержания сегментации и управления потоком трафика.

• Частные конечные точки для защиты подключения к решениям paaS и частным зонам DNS, необходимым для этих конечных точек.

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

Ресурсы, принадлежащие команде платформы

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

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

• Бастион Azure в центральной сети обеспечивает безопасный рабочий доступ к виртуальным машинам рабочей нагрузки. В базовой архитектуре команда рабочей нагрузки владеет этим компонентом.

• Периферийная виртуальная сеть находится в месте развертывания рабочей нагрузки.

• Определяемые пользователем маршруты (UDR) используются для принудительного туннелирования в центральной сети.

• ограничения управления на основе Политика Azure и DeployIfNotExists политики DINE являются частью подписки рабочей нагрузки.

Настройка подписки

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

Ваша группа рабочей нагрузки должна содержать подробные сведения о сетевом пространстве, необходимом для рабочей нагрузки, чтобы команда платформы могли выделить необходимые ресурсы. Ваша команда определяет требования, а команда платформы определяет IP-адреса, назначенные в виртуальной сети и группе управления, которой назначена подписка.

Команда платформы назначает соответствующую группу управления на основе критически важных бизнес-требований рабочей нагрузки и технических требований, например, если рабочая нагрузка предоставляется в Интернете. Организация определяет конфигурацию этих групп управления, а команда платформы реализует их.

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

• Частные приложения, такие как внутренние бизнес-приложения или коммерческие решения вне полки (COTS), которые часто находятся в группе управления corp в целевых зонах Azure.

• Общедоступные приложения, как и в интернет-приложениях, которые часто находятся в группе управления Corp или Online.

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

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

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

Требования к рабочей нагрузке и выполнение

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

• Количество периферийных виртуальных сетей: в этой архитектуре требуется только один выделенный периферийный канал. Развернутые ресурсы не должны охватывать несколько сетей и совместно размещаются в одной виртуальной сети.

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

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

• Регион развертывания: важно указать регионы, в которых будет развернута рабочая нагрузка. Команда платформы может использовать эти сведения, чтобы обеспечить подготовку периферийных и центральных виртуальных сетей в одном регионе. Сети в разных регионах могут привести к проблемам с задержкой из-за пересечения региональных границ трафика, а также может привести к дополнительным затратам на пропускную способность.

• Характеристики рабочей нагрузки и варианты проектирования: обмен данными о вариантах проектирования, компонентах и характеристиках в команде платформы. Например, если вы ожидаете, что рабочая нагрузка создаст большое количество одновременных подключений к Интернету (чат), команда платформы должна убедиться, что доступны достаточные порты, чтобы предотвратить исчерпание. Они могут добавлять IP-адреса в централизованный брандмауэр для поддержки трафика или настройки шлюза преобразования сетевых адресов (NAT) для маршрутизации трафика через альтернативный путь.

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

  Команда платформы должна четко понимать все зависимости. Например, рабочей нагрузке может потребоваться доступ к базе данных, принадлежащей другой команде, или у рабочей нагрузки может быть локальный трафик. Есть ли у рабочей нагрузки зависимости за пределами Azure? Такая информация важна для того, чтобы команда платформы знала.

• Конфигурация брандмауэра: команда платформы должна знать о трафике, который покидает периферийную сеть и туннелируется в центральной сети. Брандмауэр в концентраторе не может заблокировать этот трафик.

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

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

  Кроме того, сообщите группе платформы о диапазонах IP-адресов, содержащих виртуальные машины. Эти сведения необходимы для настройки групп безопасности сети вокруг Бастиона Azure в центральной сети.

• Общедоступные IP-адреса: сообщите группе платформы о профиле трафика входящего трафика, включая любые ожидаемые общедоступные IP-адреса. В этой архитектуре только интернет-исходный трафик предназначен для общедоступного IP-адреса в Шлюз приложений. Команда платформы должна сообщить группе рабочей нагрузки, если эти IP-адреса находятся в плане защиты от атак DDoS Azure или если это ответственность группы рабочей нагрузки.

  В этой архитектуре существует еще один общедоступный IP-адрес для оперативного доступа через Бастион Azure. Команда платформы владеет этим общедоступным IP-адресом и регистрируется в службе, например защиты от атак DDoS, которая также управляет командой платформы.

Варианты разработки виртуальных машин

Номера SKU виртуальной машины и диски остаются такими же, как и базовая архитектура.

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

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

Сеть

В базовой архитектуре рабочая нагрузка подготавливается в одной виртуальной сети. Команда рабочей нагрузки управляет виртуальной сетью.

В этой архитектуре команда платформы определяет топологию сети. Топология периферийных узлов предполагается в этой архитектуре.

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

• Виртуальная сеть концентратора: региональный концентратор содержит централизованные службы, взаимодействующие с ресурсами рабочей нагрузки в одном регионе. Дополнительные сведения см. в разделе "Ресурсы, принадлежащие команде платформы". Рекомендуется разместить концентратор в подписке на подключение.

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

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

Подсети виртуальной сети

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

При развертывании рабочей нагрузки в целевой зоне Azure по-прежнему необходимо реализовать сетевые элементы управления. Организации могут ввести ограничения для защиты от кражи данных и обеспечить видимость центра управления безопасностью (SOC) и ИТ-группы.

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

Входящий трафик

Поток трафика входящего трафика остается таким же, как и базовая архитектура.

Владелец рабочей нагрузки отвечает за все ресурсы, связанные с общедоступным интернет-входящего трафика в рабочую нагрузку. Например, в этой архитектуре Шлюз приложений и его общедоступный IP-адрес размещаются в периферийной сети, а не в центральной сети. Некоторые организации могут размещать ресурсы с трафиком входящего трафика в подписке на подключение с помощью централизованной демилитаризованной (DMZ) реализации. Интеграция с этой конкретной топологией не область для этой статьи.

Исходящий трафик

В базовой архитектуре масштабируемые наборы виртуальных машин рабочей нагрузки обращаются к общедоступному Интернету через Azure Load Balancer, но этот трафик не ограничен.

Этот дизайн отличается в этой архитектуре. Весь трафик, покидающий периферийную виртуальную сеть, направляется через одноранговую сеть концентратора через брандмауэр исходящего трафика. Маршрут подключен ко всем возможным подсетям в периферийной сети, которая направляет весь трафик для IP-адресов, не найденных в локальной виртуальной сети (0.0.0.0/0/0) к Брандмауэр Azure концентратора.

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

Обмен данными рабочей нагрузки с частной конечной точкой для доступа Key Vault остается таким же, как и базовая архитектура. Этот путь не указан на предыдущей схеме для краткости.

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

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

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

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

Использование Azure DNS для частных доменов

Архитектуры, использующие частные конечные точки, нуждаются в частных зонах DNS для работы с поставщиком DNS. Команда рабочей нагрузки должна иметь четкое представление о требованиях и управлении частными зонами DNS в подписке, которую предоставляет команда платформы. Частная зона DNS зоны обычно управляются в большом масштабе с помощью политик DINE, что позволяет Брандмауэр Azure функционировать как надежный DNS-прокси и поддерживать полные правила сети доменных имен (FQDN).

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

тестирование Подключение выверения

Для архитектур на основе виртуальных машин существует несколько средств тестирования, которые помогут определить проблемы с сетевой линией зрения, маршрутизацией и DNS. Вы можете использовать традиционные средства устранения неполадок, например netstat, nslookupили tcping. Кроме того, можно проверить параметры протокола конфигурации динамического узла (DHCP) сетевого адаптера и DNS. Если есть сетевые адаптеры, у вас есть дополнительные возможности устранения неполадок, которые позволяют выполнять проверка подключения с помощью Azure Наблюдатель за сетями.

Доступ к оператору

Как и базовая архитектура, рабочий доступ через Бастион Azure поддерживается в этой архитектуре.

Однако базовая архитектура развертывает Бастион Azure в рамках рабочей нагрузки. Для типичной организации, которая принимает целевые зоны Azure, они развертывают Бастион Azure в качестве центральных ресурсов для каждого региона. Команда платформы владеет и поддерживает Бастион Azure, а все рабочие нагрузки в организации совместно используются. Чтобы продемонстрировать, что вариант использования в этой архитектуре, Бастион Azure находится в центральной сети в подписке на подключение.

Удостоверение оператора

Эта архитектура использует то же расширение проверки подлинности, что и базовая архитектура.

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

Обновление исправлений и обновлений ОС

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

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

Наблюдение

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

Команда рабочей нагрузки подготавливает ресурсы мониторинга, в том числе:

• Приложение Аналитика в качестве службы мониторинга производительности приложений (APM) для команды рабочей нагрузки.

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

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

Как и в базовом плане, все ресурсы настроены для отправки Диагностика Azure журналов в рабочую область Log Analytics, которую команда рабочей нагрузки подготавливает в рамках инфраструктуры в качестве кода (IaC) развертывания ресурсов. Также может потребоваться отправить журналы в центральную рабочую область Log Analytics. В целевых зонах Azure эта рабочая область находится в подписке управления.

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

Сопоставление данных из нескольких приемников

Журналы и метрики рабочей нагрузки и ее компоненты инфраструктуры хранятся в рабочей области Log Analytics рабочей нагрузки. Однако журналы и метрики, которые централизованные службы, такие как Брандмауэр Azure, идентификатор Microsoft Entra и Бастион Azure, сохраняются в центральной рабочей области Log Analytics. Сопоставление данных из нескольких приемников может быть сложной задачей.

Коррелированные данные часто используются во время реагирования на инциденты. Если возникла проблема с сопоставлением данных из нескольких приемников, убедитесь, что модуль runbook для этой архитектуры решает эту проблему и включает в себя организационные точки контакта, если проблема выходит за рамки ресурсов рабочей нагрузки. Администраторам рабочей нагрузки может потребоваться помощь администраторам платформы для сопоставления записей журналов из корпоративной сети, безопасности или других служб платформы.

Политика Azure

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

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

Управление изменениями с течением времени

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

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

Изменения платформы, влияющие на рабочую нагрузку

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

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

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

• Общие ресурсы: изменения номера SKU или функций общих ресурсов могут повлиять на рабочую нагрузку.

• Маршрутизация в центральной сети. Изменения транзитивного характера маршрутизации в концентраторе могут повлиять на функциональность рабочей нагрузки, если рабочая нагрузка зависит от маршрутизации в другие виртуальные сети.

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

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

Изменения рабочей нагрузки, влияющие на платформу

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

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

• Общедоступный доступ. Изменения в общедоступном доступе к компонентам рабочей нагрузки могут потребовать дальнейшего тестирования. Команда платформы может переместить рабочую нагрузку в другую группу управления.

• Оценка критическости бизнеса: если существуют изменения соглашений об уровне обслуживания рабочей нагрузки (СОГЛАШЕНИЯ об уровне обслуживания), вам может потребоваться новый подход к совместной работе между группами платформы и рабочей нагрузки.

• Изменения владения: обмен данными об изменениях в собственности и точках связи с командой платформы.

Изменения бизнес-требований рабочей нагрузки

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

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

Надежность

Эта архитектура соответствует гарантии надежности в базовой архитектуре.

Целевые показатели надежности

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

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

Дополнительные сведения см. в Рекомендации определения целевых показателей надежности.

Критические зависимости

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

Для этой архитектуры рассмотрим следующие зависимости:

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

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

• Политики DINE: политики DINE для частных зон DNS Azure DNS (или других зависимостей, предоставляемых платформой), являются лучшими усилиями без обслуживания. Задержка в конфигурации DNS может привести к задержкам в готовности приложения к обработке трафика.

• Групповые политики управления. Согласованные политики между средами являются ключевыми для надежности. Убедитесь, что предварительные среды похожи на рабочие среды для обеспечения точного тестирования и предотвращения отклонений, которые могут блокировать развертывание или масштабирование. Дополнительные сведения см. в статье "Управление средами разработки приложений в целевых зонах Azure".

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

Дополнительные сведения см. в Рекомендации для выполнения анализа режима сбоя.

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

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

Элементы управления сетью

Правильно настройте сетевые элементы управления, чтобы обеспечить безопасность рабочей нагрузки.

Входящий трафик

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

Команда платформы, скорее всего, реализует политики Azure, чтобы убедиться, что Шлюз приложений имеет Брандмауэр веб-приложений запретить режим, чтобы ограничить количество общедоступных IP-адресов, доступных вашей подписке, и другие проверка. Помимо этих политик, команда рабочей нагрузки должна отвечать за развертывание политик, ориентированных на рабочую нагрузку, которые укрепляют состояние безопасности входящего трафика.

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

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

Исходящий трафик

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

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

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

Конечная точка	Характер использования	Элемент управления рабочей нагрузкой (NSG)	Элемент управления platform (hub)
ntp.ubuntu.com	Протокол сетевого времени (NTP) для виртуальных машин Linux	UDP/123 в Интернете в подсети интерфейсной виртуальной машины (брандмауэр исходящего трафика сужает это широкое открытие)	Квота на сетевое правило брандмауэра для управления рабочей нагрузкой
конечные точки Обновл. Windows	Обновл. Windows функциональные возможности с серверов Майкрософт	TCP/443 и TCP/80 в Интернете в подсети серверной виртуальной машины (брандмауэр исходящего трафика сужает это широкое открытие)	Правило квоты брандмауэра с тегом FQDN WindowsUpdate
Мониторинг конечных точек агента	Обязательный трафик для расширения Монитора на виртуальных машинах	TCP/443 в Интернете в обеих подсетях виртуальных машин (брандмауэр исходящего трафика сужает это широкое открытие)	Необходимые квоты правил приложения брандмауэра для всех конкретных полных доменных имен в TCP/443
nginx.org	Установка Nginx (пример компонента приложения) непосредственно от поставщика	TCP/443 в Интернете в подсети интерфейсной виртуальной машины (брандмауэр исходящего трафика сужает это широкое открытие)	Необходимое пособие по правилу приложения брандмауэра для nginx.org в TCP/443
Key Vault	Импорт сертификатов TLS в Шлюз приложений и виртуальных машинах	- TCP/443 в подсеть частной конечной точки из обеих подсетей виртуальной машины в подсеть частной конечной точки - TCP/443 в подсеть частной конечной точки из подсети Шлюз приложений - TCP/443 из виртуальных машин, помеченных обязательным назначением группы безопасности приложений (ASG) и Шлюз приложений подсети	нет

Защита от атак DDos

Определите, кто отвечает за применение плана защиты от атак DDoS, охватывающего все общедоступные IP-адреса вашего решения. Команда платформы может использовать планы защиты IP-адресов или даже использовать Политика Azure для применения планов защиты виртуальной сети. Эта архитектура должна иметь охват, так как она включает общедоступный IP-адрес для входящего трафика из Интернета.

Дополнительные сведения см. в Рекомендации для сетевых подключений и подключения.

Управление секретами

Для управления секретами эта архитектура соответствует базовой архитектуре.

В качестве команды рабочей нагрузки продолжайте хранить секреты в экземпляре Key Vault. Разверните дополнительные экземпляры при необходимости для поддержки операций приложения и инфраструктуры.

Дополнительные сведения см. в Рекомендации защиты секретов приложений.

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

Для ресурсов рабочей нагрузки стратегии оптимизации затрат в базовой архитектуре также применяются к этой архитектуре.

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

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

• Брандмауэр Azure
• SIEM
• Узлы Бастиона Azure
• Кросс-локальное подключение, например ExpressRoute

Воспользуйтесь преимуществами других централизованных предложений от вашей группы платформы, чтобы расширить эти преимущества для рабочей нагрузки без ущерба для своего SLO, цели времени восстановления (RTO) или целевой точки восстановления (RPO).

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

Развертывание этого сценария

Пример развертывания для этой архитектуры можно найти на портале GitHub.

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

Просмотрите общие сведения о совместной работе и технической информации между командой рабочей нагрузки и группами платформ.

Vending подписки