Базовое зонально избыточное веб-приложение с высокой доступностью

Служба приложений Azure

Шлюз приложений Azure

Хранилище Azure

База данных SQL Azure

Приватный канал Azure

Виртуальная сеть Azure

Azure Monitor

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

Внимание

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

Архитектура

На схеме показана виртуальная сеть с тремя подсетями. Одна подсеть содержит шлюз приложений с брандмауэром веб-приложения Azure. Пользователь указывает на эту подсеть. Вторая подсеть содержит частные конечные точки для служб Azure PaaS. Третья подсеть содержит виртуальный интерфейс для интеграции сети службы приложений. Шлюз приложений взаимодействует со службой приложений через частную конечную точку. Сервис приложений показывает зональную конфигурацию. Служба приложений использует интеграцию виртуальных сетей и частные конечные точки для взаимодействия с базой данных SQL, Key Vault и хранилищем Azure. Частные зоны DNS связаны с виртуальной сетью. Распределенная защита от отказов в обслуживании (DDoS) защищает виртуальную сеть. Microsoft Entra ID предоставляет управление идентификацией и доступом. Application Insights и Azure Monitor служат целям мониторинга.

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

Компоненты

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

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

• Брандмауэр веб-приложений Azure — это облачная служба, которая защищает веб-приложения от распространенных эксплойтов, таких как внедрение SQL и межсайтовые скрипты (XSS). В этой архитектуре брандмауэр веб-приложений Azure запускается в шлюзе приложений и блокирует вредоносные запросы, прежде чем они достигают службы приложений. Эта настройка улучшает безопасность и помогает поддерживать доступность.

• Key Vault — это служба, которая безопасно хранит секреты, ключи шифрования и сертификаты и управляет ими. В этой архитектуре он хранит сертификат TLS (X.509), который использует шлюз приложений, и содержит секреты приложений, к которым служба приложений обращается в частном порядке.

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

• Приватный канал — это сетевая служба, которая предоставляет частный доступ к службам Azure через магистральную сеть Майкрософт для устранения воздействия на общедоступный Интернет. В этой архитектуре Приватный канал обеспечивает частные входящие подключения к Службе приложений и частным исходящим подключениям из службы приложений к службам, таким как Key Vault, База данных SQL и служба хранилища Azure.

• Azure DNS — это служба размещения доменных доменов (DNS). Он обеспечивает разрешение имен с использованием инфраструктуры Microsoft Azure. Частные зоны DNS сопоставляют полное доменное имя службы (FQDN) с IP-адресом частной конечной точки. В этой архитектуре частные зоны DNS сопоставляют домен службы приложений по умолчанию и другие домены службы PaaS с адресами частной конечной точки, чтобы весь трафик оставался в частной сети.

Сеть

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

• Единая безопасная точка входа для трафика клиента

• Фильтрация трафика через брандмауэр веб-приложения Azure

• Сквозное шифрование TLS для передаваемых данных

• Минимизированные утечки данных через Private Link, который сохраняет трафик в Azure

• Логическое группирование и изоляция сетевых ресурсов с помощью сегментации сети

Сетевые потоки

Схема напоминает базовую архитектуру службы приложений с двумя нумерованными сетевыми потоками. На шаге 1 входящего потока пользователь выдает запрос шлюзу приложений с брандмауэром веб-приложения Azure. На шаге 2 брандмауэр веб-приложения Azure оценивает правила. На шаге 3 частные зоны DNS связываются с виртуальной сетью. На шаге 4 шлюз приложений использует частные конечные точки для взаимодействия со службой приложений. На шаге 1 исходящего потока служба приложений указывает на виртуальный интерфейс в подсети интеграции службы приложений. На шаге 2 частные зоны DNS связываются с виртуальной сетью. На шаге 3 виртуальный интерфейс взаимодействует через частные конечные точки со службами Azure PaaS.

Входящий поток

Ниже описан поток входящего трафика из Интернета в экземпляр App Service:

1. Пользователь выдает запрос на общедоступный IP-адрес шлюза приложений.

2. Шлюз приложений оценивает правила брандмауэра веб-приложения, которые защищают от атак, таких как XSS и внедрение SQL. Если правило обнаруживает нарушение, шлюз приложений возвращает ошибку запрашивателю и останавливает обработку. В противном случае шлюз приложений направляет запрос в внутренний пул, который в данном случае является доменом службы приложений по умолчанию.

3. Частная зона privatelink.azurewebsites.net DNS связывается с виртуальной сетью. Зона DNS содержит запись A , которая сопоставляет домен службы приложений по умолчанию с частным IP-адресом частной конечной точки службы приложений. Azure DNS использует эту запись для сопоставления домена по умолчанию с IP-адресом частной конечной точки.

4. Шлюз приложения направляет запрос к экземпляру службы приложений через частную конечную точку.

Исходящий поток

Ниже описан исходящий поток из службы приложений в службы PaaS Azure:

1. Служба приложений отправляет запрос на DNS-имя требуемой службы Azure, например Key Vault, хранилища, базы данных SQL или любой другой службы Azure, поддерживающей приватный канал. Функция интеграции виртуальной сети Служба приложений направляет запрос через виртуальную сеть.

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

3. Виртуальная сеть направляет запрос в службу через частную конечную точку.

Исходящий трафик, который не направляется в службы PaaS Azure, выходит через общедоступный IP-адрес, который используется несколькими клиентами. Например, веб-приложение может вызывать общедоступный API во время HTTP-запроса. Чтобы контролировать этот тип исходящего трафика, перенаправите его через сетевое устройство, например брандмауэр Azure. Дополнительные сведения см. в статье "Управление исходящим трафиком с помощью брандмауэра Azure".

Реализация шлюза приложений

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

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

• Реализуйте сквозное шифрование TLS.

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

• Реализуйте автомасштабирование , чтобы шлюз приложений настраивал емкость в зависимости от спроса на трафик.

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

• Блокировать доступ к общедоступной сети в службе приложений, чтобы обеспечить сетевую изоляцию. В Bicep установите publicNetworkAccess в Disabled под properties.

Поток из службы приложений в службы Azure

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

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

В этой архитектуре для базы данных SQL, хранилища и Key Vault заблокированы общедоступные конечные точки. Брандмауэры служб разрешают трафик только из других авторизованных служб Azure. Настройте другие службы Azure, такие как Azure Cosmos DB и Azure Managed Redis, с частными конечными точками. В этой архитектуре Azure Monitor не использует частную конечную точку, но ее можно реализовать с помощью области приватного канала Azure Monitor (AMPLS).

Базовая архитектура реализует частную зону DNS для каждой службы. Каждая частная зона DNS содержит запись A , которая сопоставляет полное доменное имя службы с IP-адресом частной конечной точки. Зоны связаны с виртуальной сетью. Группы частной зоны DNS автоматически создают и обновляют записи DNS для частных конечных точек.

При реализации интеграции виртуальной сети и частных конечных точек следует учитывать следующие моменты:

• Назовите частные зоны DNS на основе руководства по настройке зоны DNS служб Azure.

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

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

  • Включите Key Vault для Приватной ссылки.

  • Запретить доступ к базе данных SQL общедоступной сети.

Сегментация виртуальной сети и безопасность

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

Подсеть	Входящий трафик	Исходящие
GatewaySubnet	AppGw.In.Allow.ControlPlane: разрешить доступ к плоскости управления входящего трафика. AppGw.In.Allow443.Internet: разрешить входящий доступ через Интернет HTTPS.	AppGw.Out.Allow.PrivateEndpoints: разрешить исходящий доступ к PrivateEndpointsSubnet. AppPlan.Out.Allow.AzureMonitor: разрешить исходящий доступ к Azure Monitor.
PrivateEndpointsSubnet	Правила по умолчанию: разрешить входящий доступ из виртуальной сети.	Правила по умолчанию: разрешить исходящий доступ к виртуальной сети.
AppServiceSubnet	Правила по умолчанию: разрешить входящий доступ из виртуальной сети.	AppPlan.Out.Allow.PrivateEndpoints: разрешить исходящий доступ к PrivateEndpointsSubnet. AppPlan.Out.Allow.AzureMonitor: разрешить исходящий доступ к Azure Monitor.

При реализации сегментации и безопасности виртуальной сети следует учитывать следующие моменты:

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

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

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

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

Тип	Имя.	Диапазон адресов
Виртуальная сеть	Префикс адреса	10.0.0.0/16
Подсеть	Подсеть шлюза	10.0.1.0/24
Подсеть	AppServiceSubnet	10.0.0.0/24
Подсеть	PrivateEndpointsSubnet	10.0.2.0/27
Подсеть	AgentSubnet	10.0.2.32/27

Рекомендации

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

Reliability

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

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

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

Шлюз приложений

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

Служба приложений

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

• Реализуйте конечные точки проверки работоспособности в ваших приложениях и настройте функцию проверки работоспособности в App Service для перенаправления запросов из неработоспособных экземпляров. Для получения дополнительной информации см. Мониторинг экземпляров службы приложений с помощью проверки работоспособности и Проверки работоспособности в ASP.NET Core.

• Избыточное резервирование ресурсов для управления сбоями в зоне.

Хранилище BLOB-объектов

• Используйте хранилище с избыточностью между зонами (ZRS), которое реплицирует данные синхронно в трех зонах доступности в регионе. Создайте учетные записи хранения уровня "Стандартный ZRS" или "Стандартный GZRS", чтобы обеспечить репликацию данных по зонам доступности.

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

База данных SQL

• Разверните базу данных SQL на уровне "Общее назначение", "Премиум" или "Критически важный для бизнеса" с зональной избыточностью. Эти уровни поддерживают зональную избыточность.

• Настройте резервные копии базы данных SQL для использования ZRS или GZRS.

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

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

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

Служба приложений

• Отключите локальные методы проверки подлинности для развертываний сайтов с использованием протокола FTP и системы управления исходным кодом (SCM).

• Отключите удаленную отладку.

• Используйте последнюю версию TLS, поддерживаемую всеми клиентами.

• Включите Microsoft Defender для плана Службы приложений.

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

• Рассмотрите App Service Environment, если вам требуется более высокая изоляция или безопасный сетевой доступ.

Шифрование

Рабочие веб-приложения должны шифровать передаваемые данные с помощью HTTPS. ПРОТОКОЛ HTTPS использует протокол TLS и использует открытые и закрытые ключи для шифрования. Сохраните сертификат TLS (X.509) в Key Vault и предоставьте шлюзу приложений разрешение на получение закрытого ключа. Для неактивных данных некоторые службы автоматически шифруют данные, а другие позволяют настраивать параметры.

Передаваемые данные

Базовая архитектура шифрует данные при передаче от пользователя к веб-приложению в службе приложений.

На схеме показаны шаги потока шифрования в базовой архитектуре. На шаге 1 пользователь указывает на шлюз приложений с брандмауэром веб-приложения Azure, который помечен на шаге 2. Шаг 3 указывает на Key Vault, в котором хранится сертификат X.509. Шаг 4 представляет зашифрованный трафик из шлюза приложений в службу приложений.

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

1. Пользователь отправляет HTTPS-запрос в веб-приложение.

2. HttpS-запрос достигает шлюза приложений.

3. Шлюз приложений использует сертификат (X.509) в Key Vault для создания безопасного tls-подключения с веб-браузером пользователя. Шлюз приложений расшифровывает HTTPS-запрос, чтобы брандмауэр веб-приложения смог проверить его.

4. Шлюз приложений создает подключение TLS к службе приложений для повторного шифрования запроса пользователя. Служба приложений обеспечивает встроенную поддержку HTTPS, поэтому вам не нужно добавлять сертификат в службу приложений. Шлюз приложений отправляет зашифрованный трафик в Служба приложений. Служба приложений расшифровывает трафик, а веб-приложение обрабатывает запрос.

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

• Создайте или отправьте сертификат в Key Vault. Для шифрования HTTPS требуется сертификат (X.509). Вам нужен сертификат из доверенного центра сертификации для личного домена.

• Сохраните закрытый ключ в сертификате в Key Vault.

• Предоставьте шлюзу приложений доступ к закрытому ключу сертификата. Дополнительные сведения см. в статьях "Предоставление разрешений с помощью управления доступом на основе ролей Azure" (Azure RBAC) и "Управляемые удостоверения для ресурсов Azure". Не используйте политики доступа Key Vault для предоставления доступа. Политики доступа позволяют предоставлять только широкие разрешения, а не определенные значения.

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

Неактивные данные

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

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

• Поймите встроенную поддержку шифрования. Служба хранилища Azure автоматически шифрует неактивных данных с помощью шифрования на стороне сервера (256-разрядная расширенная версия шифрования (AES)). Azure Monitor автоматически шифрует неактивных данных с помощью ключей, управляемых Корпорацией Майкрософт.

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

Политика Azure помогает применять решения по архитектуре и безопасности для веб-приложений. Он может предотвратить развертывание несоответствуемых ресурсов (режим запрета) или пометить их для проверки (режим аудита). Этот подход помогает обнаружить отклонения конфигурации от предполагаемой архитектуры, независимо от того, происходит ли это отклонение через развертывания «инфраструктура как код» (IaC) или в результате ручных изменений на портале Azure.

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

• Служба приложений должна отключить доступ к общедоступной сети.
• Служба приложений должна использовать интеграцию виртуальной сети.
• Служба приложений должна использовать приватный канал для подключения к службам PaaS.
• Служба приложений должна иметь локальные методы проверки подлинности, отключенные для развертываний сайтов FTP и SCM.
• Служба приложений должна отключить удаленную отладку.
• Приложения службы приложений должны использовать последнюю версию TLS.
• Необходимо включить Defender для службы приложений.
• Брандмауэр веб-приложения Azure должен быть включен для шлюза приложений.

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

Управление удостоверениями и доступом

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

Идентичности пользователей

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

• Настройте URL-адрес ответа для личного домена. Установите URL-адрес перенаправления на https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

  Замените <application-gateway-endpoint> на общедоступный IP-адрес или пользовательское доменное имя вашего шлюза приложений. Замените <provider> своим поставщиком проверки подлинности, например aad для Microsoft Entra ID.

  Инструкции по настройке см. в рекомендациях по настройке Azure Front Door или настройке шлюза приложений.

Идентификации рабочих нагрузок

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

• Используйте назначаемые пользователем управляемые удостоверения. Назначаемые системой удостоверения могут привести к сбою развертываний IaC в зависимости от условий гонки и порядка операций. Назначаемые пользователем управляемые удостоверения избегают некоторых сценариев ошибок развертывания. Дополнительные сведения см. в разделе Управляемые удостоверения.

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

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

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

Операционное превосходство

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

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

На схеме показана базовая архитектура с подсетью, содержащей агенты локального развертывания. Он добавляет также Azure Pipelines с управляемыми агентами. Управляемые агенты указывают на Azure DevOps и конвейер выпуска (шаги 1, 4 и 6). Агенты локального развертывания указывают на Azure DevOps и конвейер выпуска (шаг 2) и частную конечную точку хранилища (шаг 3). Частная конечная точка хранилища указывает на хранилище (шаг 3).

Процесс развертывания

1. Конвейер выпуска отправляет запрос задания в очередь заданий для локальных агентов. Задание указывает агенту отправить опубликованный ZIP-файл как артефакт сборки в аккаунт хранилища.

2. Агент локального развертывания опрашивает очередь, выбирает запрос задания и загружает задание и создает артефакт.

3. Агент локального развертывания отправляет ZIP-файл в учетную запись хранения через частную конечную точку учетной записи хранения.

4. Потоковая линия продолжается, и управляемый агент берет следующее задание. Управляемый агент вызывает интерфейс командной строки (CLI) для обновления параметра приложения WEBSITE_RUN_FROM_PACKAGE с новой ссылкой на zip-файл публикации для промежуточного слота.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

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

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

Руководства по развертыванию

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

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

• Включите номера версий в имена zip-файлов развернутого пакета. При обновлении WEBSITE_RUN_FROM_PACKAGE параметра приложения для ссылки на пакет развертывания с другим именем файла служба приложений автоматически извлекает новый пакет и перезапускается.

• Используйте слоты развертывания для надежных развертываний кода.

• Рассмотрите возможность использовать как управляемые, так и локальные агенты.

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

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

• Используйте IaC для автоматизации развертываний инфраструктуры.

• Непрерывно проверяйте производительность рабочей нагрузки и устойчивость с помощью таких служб, как Azure Load Testing и Azure Chaos Studio.

Настройка

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

• Никогда не храните пароли или ключи доступа в системе контроля версий. Храните секреты в Key Vault.

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

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

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

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

Наблюдение

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

Мониторинг трех ключевых уровней:

• Код приложения: Отслеживайте данные телеметрии для конкретного приложения и пользовательские метрики.

• Инфраструктура (среда выполнения): Мониторинг среды выполнения службы приложений.

• Платформа (ресурсы Azure): Сбор метрик и журналов из служб Azure, таких как Шлюз приложений, База данных SQL и Key Vault.

Дополнительные сведения см. в журнале действий Azure, журналах ресурсов Azure и ведении журнала приложений службы приложений.

Мониторинг платформы

Мониторинг платформы собирает данные из служб Microsoft Azure в вашей архитектуре.

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

  Ресурс Azure	Описания метрик и журналов
  Шлюз приложений	Описание метрик и журналов для шлюза приложений
  Брандмауэр веб-приложений Azure	Метрики и описания журналов брандмауэра веб-приложений Azure
  Служба приложений	Описание метрик и журналов службы приложений
  SQL Database	Описание метрик и журналов базы данных SQL
  Azure Cosmos DB (облачная база данных)	Описания метрик и журналов Azure Cosmos DB
  Key Vault (Хранилище ключей)	Описания метрик и журналов Key Vault
  Хранилище BLOB-объектов	Описания метрик и логов BLOB-хранилища
  Application Insights	Описания метрик и журналов Application Insights
  Общедоступный IP-адрес	Метрики и описания общедоступных IP-адресов

• Сбалансируйте потребности в наблюдаемости с затратами. Чем больше собранных данных, тем выше стоимость. Подробнее см. в разделе «Вычисления затрат и параметры Log Analytics» и «Цены на рабочую область Log Analytics».

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

  • Обзор оповещений Azure Monitor
  • Оповещения шлюза приложений
  • Оповещения Службы приложений
  • Оповещения базы данных SQL
  • Оповещения Blob-хранилища
  • Оповещения Key Vault

Шлюз приложений

Шлюз приложений отслеживает работоспособности внутреннего пула с помощью проб работоспособности по умолчанию. Используйте журналы доступа шлюза приложений для сбора таких сведений, как метки времени, коды ответов HTTP и пути URL-адреса. Дополнительные сведения см. в журналах работоспособности и диагностики внутреннего сервера.

Служба приложений

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

• Включите автоматическое инструментирование для расширения инструментирования без изменений кода. Эта функция обеспечивает видимость мониторинга производительности приложений (APM). Дополнительные сведения см. в разделе "Мониторинг производительности службы приложений".

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

• Используйте инструментирование на основе кода для пользовательской телеметрии. Application Insights также поддерживает инструментирование на основе кода для телеметрии пользовательских приложений. Добавьте дистрибутив Azure Monitor OpenTelemetry в код.

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

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

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

База данных

• Включите мониторинг базы данных для базы данных SQL. Используйте средство наблюдения за базами данных, которое является управляемым решением мониторинга для служб баз данных в семействе SQL Azure. Дополнительные сведения см. в статье "Мониторинг базы данных SQL" с помощью Azure Monitor.

• Не включайте и не настраивайте аналитику Azure Cosmos DB, если архитектура содержит Azure Cosmos DB.

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки проектного решения на эффективность производительности .

Шлюз приложений

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

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

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

• Следуйте указаниям по размеру подсети шлюза приложений.

Служба приложений

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

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

• Попробуйте открыть запрос в службу поддержки, чтобы увеличить максимальное число работников до величины, равной удвоенному количеству экземпляров, если Служба приложений последовательно использует половину максимального числа экземпляров. Максимальное количество экземпляров по умолчанию составляет до 30 для плана Службы приложений "Премиум" и 10 для стандартного плана.

• Рассмотрите возможность развертывания нескольких экземпляров приложения, когда App Service начнет достигать пределов масштабирования.

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

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

• Рекомендуется использовать среду службы приложений , чтобы предотвратить шумные проблемы соседей.

SQL Database

Масштабирование базы данных включает в себя множество соображений, выходящих за рамки этой архитектуры. Дополнительные сведения о масштабировании базы данных SQL см. в следующих ресурсах:

• Динамическое масштабирование ресурсов базы данных с минимальным временем простоя
• Горизонтальное масштабирование с помощью базы данных SQL
• Используйте реплики только для чтения для разгрузки рабочих нагрузок, связанных с выполнением запросов только для чтения

Другие рекомендации по масштабируемости

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

• Рекомендуется кэширование для следующих типов данных для повышения производительности и масштабируемости:

  • Данные о полустатических транзакциях
  • Состояние сеанса
  • Сложные выходные данные HTML

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

• Масштабирование приложения в службе приложений
• Масштабирование шлюза приложений и брандмауэра веб-приложений Azure

Связанные ресурсы

• Шаблоны корпоративных веб-приложений
• Руководство по приватному соединению в виртуальной сети Azure

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

Внимание

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

Архитектура

На схеме показана виртуальная сеть с тремя подсетями. Одна подсеть содержит шлюз приложений с брандмауэром веб-приложения Azure. Пользователь указывает на эту подсеть. Вторая подсеть содержит частные конечные точки для служб Azure PaaS. Третья подсеть содержит виртуальный интерфейс для интеграции сети службы приложений. Шлюз приложений взаимодействует со службой приложений через частную конечную точку. Сервис приложений показывает зональную конфигурацию. Служба приложений использует интеграцию виртуальных сетей и частные конечные точки для взаимодействия с базой данных SQL, Key Vault и хранилищем Azure. Частные зоны DNS связаны с виртуальной сетью. Распределенная защита от отказов в обслуживании (DDoS) защищает виртуальную сеть. Microsoft Entra ID предоставляет управление идентификацией и доступом. Application Insights и Azure Monitor служат целям мониторинга.

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

Компоненты

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

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

• Брандмауэр веб-приложений Azure — это облачная служба, которая защищает веб-приложения от распространенных эксплойтов, таких как внедрение SQL и межсайтовые скрипты (XSS). В этой архитектуре брандмауэр веб-приложений Azure запускается в шлюзе приложений и блокирует вредоносные запросы, прежде чем они достигают службы приложений. Эта настройка улучшает безопасность и помогает поддерживать доступность.

• Key Vault — это служба, которая безопасно хранит секреты, ключи шифрования и сертификаты и управляет ими. В этой архитектуре он хранит сертификат TLS (X.509), который использует шлюз приложений, и содержит секреты приложений, к которым служба приложений обращается в частном порядке.

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

• Приватный канал — это сетевая служба, которая предоставляет частный доступ к службам Azure через магистральную сеть Майкрософт для устранения воздействия на общедоступный Интернет. В этой архитектуре Приватный канал обеспечивает частные входящие подключения к Службе приложений и частным исходящим подключениям из службы приложений к службам, таким как Key Vault, База данных SQL и служба хранилища Azure.

• Azure DNS — это служба размещения доменных доменов (DNS). Он обеспечивает разрешение имен с использованием инфраструктуры Microsoft Azure. Частные зоны DNS сопоставляют полное доменное имя службы (FQDN) с IP-адресом частной конечной точки. В этой архитектуре частные зоны DNS сопоставляют домен службы приложений по умолчанию и другие домены службы PaaS с адресами частной конечной точки, чтобы весь трафик оставался в частной сети.

Сеть

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

• Единая безопасная точка входа для трафика клиента

• Фильтрация трафика через брандмауэр веб-приложения Azure

• Сквозное шифрование TLS для передаваемых данных

• Минимизированные утечки данных через Private Link, который сохраняет трафик в Azure

• Логическое группирование и изоляция сетевых ресурсов с помощью сегментации сети

Сетевые потоки

Схема напоминает базовую архитектуру службы приложений с двумя нумерованными сетевыми потоками. На шаге 1 входящего потока пользователь выдает запрос шлюзу приложений с брандмауэром веб-приложения Azure. На шаге 2 брандмауэр веб-приложения Azure оценивает правила. На шаге 3 частные зоны DNS связываются с виртуальной сетью. На шаге 4 шлюз приложений использует частные конечные точки для взаимодействия со службой приложений. На шаге 1 исходящего потока служба приложений указывает на виртуальный интерфейс в подсети интеграции службы приложений. На шаге 2 частные зоны DNS связываются с виртуальной сетью. На шаге 3 виртуальный интерфейс взаимодействует через частные конечные точки со службами Azure PaaS.

Входящий поток

Ниже описан поток входящего трафика из Интернета в экземпляр App Service:

1. Пользователь выдает запрос на общедоступный IP-адрес шлюза приложений.

2. Шлюз приложений оценивает правила брандмауэра веб-приложения, которые защищают от атак, таких как XSS и внедрение SQL. Если правило обнаруживает нарушение, шлюз приложений возвращает ошибку запрашивателю и останавливает обработку. В противном случае шлюз приложений направляет запрос в внутренний пул, который в данном случае является доменом службы приложений по умолчанию.

3. Частная зона privatelink.azurewebsites.net DNS связывается с виртуальной сетью. Зона DNS содержит запись A , которая сопоставляет домен службы приложений по умолчанию с частным IP-адресом частной конечной точки службы приложений. Azure DNS использует эту запись для сопоставления домена по умолчанию с IP-адресом частной конечной точки.

4. Шлюз приложения направляет запрос к экземпляру службы приложений через частную конечную точку.

Исходящий поток

Ниже описан исходящий поток из службы приложений в службы PaaS Azure:

1. Служба приложений отправляет запрос на DNS-имя требуемой службы Azure, например Key Vault, хранилища, базы данных SQL или любой другой службы Azure, поддерживающей приватный канал. Функция интеграции виртуальной сети Служба приложений направляет запрос через виртуальную сеть.

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

3. Виртуальная сеть направляет запрос в службу через частную конечную точку.

Исходящий трафик, который не направляется в службы PaaS Azure, выходит через общедоступный IP-адрес, который используется несколькими клиентами. Например, веб-приложение может вызывать общедоступный API во время HTTP-запроса. Чтобы контролировать этот тип исходящего трафика, перенаправите его через сетевое устройство, например брандмауэр Azure. Дополнительные сведения см. в статье "Управление исходящим трафиком с помощью брандмауэра Azure".

Реализация шлюза приложений

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

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

• Реализуйте сквозное шифрование TLS.

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

• Реализуйте автомасштабирование , чтобы шлюз приложений настраивал емкость в зависимости от спроса на трафик.

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

• Блокировать доступ к общедоступной сети в службе приложений, чтобы обеспечить сетевую изоляцию. В Bicep установите publicNetworkAccess в Disabled под properties.

Поток из службы приложений в службы Azure

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

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

В этой архитектуре для базы данных SQL, хранилища и Key Vault заблокированы общедоступные конечные точки. Брандмауэры служб разрешают трафик только из других авторизованных служб Azure. Настройте другие службы Azure, такие как Azure Cosmos DB и Azure Managed Redis, с частными конечными точками. В этой архитектуре Azure Monitor не использует частную конечную точку, но ее можно реализовать с помощью области приватного канала Azure Monitor (AMPLS).

Базовая архитектура реализует частную зону DNS для каждой службы. Каждая частная зона DNS содержит запись A , которая сопоставляет полное доменное имя службы с IP-адресом частной конечной точки. Зоны связаны с виртуальной сетью. Группы частной зоны DNS автоматически создают и обновляют записи DNS для частных конечных точек.

При реализации интеграции виртуальной сети и частных конечных точек следует учитывать следующие моменты:

• Назовите частные зоны DNS на основе руководства по настройке зоны DNS служб Azure.

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

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

  • Включите Key Vault для Приватной ссылки.

  • Запретить доступ к базе данных SQL общедоступной сети.

Сегментация виртуальной сети и безопасность

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

Подсеть	Входящий трафик	Исходящие
GatewaySubnet	AppGw.In.Allow.ControlPlane: разрешить доступ к плоскости управления входящего трафика. AppGw.In.Allow443.Internet: разрешить входящий доступ через Интернет HTTPS.	AppGw.Out.Allow.PrivateEndpoints: разрешить исходящий доступ к PrivateEndpointsSubnet. AppPlan.Out.Allow.AzureMonitor: разрешить исходящий доступ к Azure Monitor.
PrivateEndpointsSubnet	Правила по умолчанию: разрешить входящий доступ из виртуальной сети.	Правила по умолчанию: разрешить исходящий доступ к виртуальной сети.
AppServiceSubnet	Правила по умолчанию: разрешить входящий доступ из виртуальной сети.	AppPlan.Out.Allow.PrivateEndpoints: разрешить исходящий доступ к PrivateEndpointsSubnet. AppPlan.Out.Allow.AzureMonitor: разрешить исходящий доступ к Azure Monitor.

При реализации сегментации и безопасности виртуальной сети следует учитывать следующие моменты:

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

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

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

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

Тип	Имя.	Диапазон адресов
Виртуальная сеть	Префикс адреса	10.0.0.0/16
Подсеть	Подсеть шлюза	10.0.1.0/24
Подсеть	AppServiceSubnet	10.0.0.0/24
Подсеть	PrivateEndpointsSubnet	10.0.2.0/27
Подсеть	AgentSubnet	10.0.2.32/27

Рекомендации

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

Reliability

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

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

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

Шлюз приложений

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

Служба приложений

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

• Реализуйте конечные точки проверки работоспособности в ваших приложениях и настройте функцию проверки работоспособности в App Service для перенаправления запросов из неработоспособных экземпляров. Для получения дополнительной информации см. Мониторинг экземпляров службы приложений с помощью проверки работоспособности и Проверки работоспособности в ASP.NET Core.

• Избыточное резервирование ресурсов для управления сбоями в зоне.

Хранилище BLOB-объектов

• Используйте хранилище с избыточностью между зонами (ZRS), которое реплицирует данные синхронно в трех зонах доступности в регионе. Создайте учетные записи хранения уровня "Стандартный ZRS" или "Стандартный GZRS", чтобы обеспечить репликацию данных по зонам доступности.

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

База данных SQL

• Разверните базу данных SQL на уровне "Общее назначение", "Премиум" или "Критически важный для бизнеса" с зональной избыточностью. Эти уровни поддерживают зональную избыточность.

• Настройте резервные копии базы данных SQL для использования ZRS или GZRS.

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

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

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

Служба приложений

• Отключите локальные методы проверки подлинности для развертываний сайтов с использованием протокола FTP и системы управления исходным кодом (SCM).

• Отключите удаленную отладку.

• Используйте последнюю версию TLS, поддерживаемую всеми клиентами.

• Включите Microsoft Defender для плана Службы приложений.

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

• Рассмотрите App Service Environment, если вам требуется более высокая изоляция или безопасный сетевой доступ.

Шифрование

Рабочие веб-приложения должны шифровать передаваемые данные с помощью HTTPS. ПРОТОКОЛ HTTPS использует протокол TLS и использует открытые и закрытые ключи для шифрования. Сохраните сертификат TLS (X.509) в Key Vault и предоставьте шлюзу приложений разрешение на получение закрытого ключа. Для неактивных данных некоторые службы автоматически шифруют данные, а другие позволяют настраивать параметры.

Передаваемые данные

Базовая архитектура шифрует данные при передаче от пользователя к веб-приложению в службе приложений.

На схеме показаны шаги потока шифрования в базовой архитектуре. На шаге 1 пользователь указывает на шлюз приложений с брандмауэром веб-приложения Azure, который помечен на шаге 2. Шаг 3 указывает на Key Vault, в котором хранится сертификат X.509. Шаг 4 представляет зашифрованный трафик из шлюза приложений в службу приложений.

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

1. Пользователь отправляет HTTPS-запрос в веб-приложение.

2. HttpS-запрос достигает шлюза приложений.

3. Шлюз приложений использует сертификат (X.509) в Key Vault для создания безопасного tls-подключения с веб-браузером пользователя. Шлюз приложений расшифровывает HTTPS-запрос, чтобы брандмауэр веб-приложения смог проверить его.

4. Шлюз приложений создает подключение TLS к службе приложений для повторного шифрования запроса пользователя. Служба приложений обеспечивает встроенную поддержку HTTPS, поэтому вам не нужно добавлять сертификат в службу приложений. Шлюз приложений отправляет зашифрованный трафик в Служба приложений. Служба приложений расшифровывает трафик, а веб-приложение обрабатывает запрос.

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

• Создайте или отправьте сертификат в Key Vault. Для шифрования HTTPS требуется сертификат (X.509). Вам нужен сертификат из доверенного центра сертификации для личного домена.

• Сохраните закрытый ключ в сертификате в Key Vault.

• Предоставьте шлюзу приложений доступ к закрытому ключу сертификата. Дополнительные сведения см. в статьях "Предоставление разрешений с помощью управления доступом на основе ролей Azure" (Azure RBAC) и "Управляемые удостоверения для ресурсов Azure". Не используйте политики доступа Key Vault для предоставления доступа. Политики доступа позволяют предоставлять только широкие разрешения, а не определенные значения.

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

Неактивные данные

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

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

• Поймите встроенную поддержку шифрования. Служба хранилища Azure автоматически шифрует неактивных данных с помощью шифрования на стороне сервера (256-разрядная расширенная версия шифрования (AES)). Azure Monitor автоматически шифрует неактивных данных с помощью ключей, управляемых Корпорацией Майкрософт.

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

Политика Azure помогает применять решения по архитектуре и безопасности для веб-приложений. Он может предотвратить развертывание несоответствуемых ресурсов (режим запрета) или пометить их для проверки (режим аудита). Этот подход помогает обнаружить отклонения конфигурации от предполагаемой архитектуры, независимо от того, происходит ли это отклонение через развертывания «инфраструктура как код» (IaC) или в результате ручных изменений на портале Azure.

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

• Служба приложений должна отключить доступ к общедоступной сети.
• Служба приложений должна использовать интеграцию виртуальной сети.
• Служба приложений должна использовать приватный канал для подключения к службам PaaS.
• Служба приложений должна иметь локальные методы проверки подлинности, отключенные для развертываний сайтов FTP и SCM.
• Служба приложений должна отключить удаленную отладку.
• Приложения службы приложений должны использовать последнюю версию TLS.
• Необходимо включить Defender для службы приложений.
• Брандмауэр веб-приложения Azure должен быть включен для шлюза приложений.

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

Управление удостоверениями и доступом

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

Идентичности пользователей

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

• Настройте URL-адрес ответа для личного домена. Установите URL-адрес перенаправления на https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

  Замените <application-gateway-endpoint> на общедоступный IP-адрес или пользовательское доменное имя вашего шлюза приложений. Замените <provider> своим поставщиком проверки подлинности, например aad для Microsoft Entra ID.

  Инструкции по настройке см. в рекомендациях по настройке Azure Front Door или настройке шлюза приложений.

Идентификации рабочих нагрузок

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

• Используйте назначаемые пользователем управляемые удостоверения. Назначаемые системой удостоверения могут привести к сбою развертываний IaC в зависимости от условий гонки и порядка операций. Назначаемые пользователем управляемые удостоверения избегают некоторых сценариев ошибок развертывания. Дополнительные сведения см. в разделе Управляемые удостоверения.

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

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

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

Операционное превосходство

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

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

На схеме показана базовая архитектура с подсетью, содержащей агенты локального развертывания. Он добавляет также Azure Pipelines с управляемыми агентами. Управляемые агенты указывают на Azure DevOps и конвейер выпуска (шаги 1, 4 и 6). Агенты локального развертывания указывают на Azure DevOps и конвейер выпуска (шаг 2) и частную конечную точку хранилища (шаг 3). Частная конечная точка хранилища указывает на хранилище (шаг 3).

Процесс развертывания

1. Конвейер выпуска отправляет запрос задания в очередь заданий для локальных агентов. Задание указывает агенту отправить опубликованный ZIP-файл как артефакт сборки в аккаунт хранилища.

2. Агент локального развертывания опрашивает очередь, выбирает запрос задания и загружает задание и создает артефакт.

3. Агент локального развертывания отправляет ZIP-файл в учетную запись хранения через частную конечную точку учетной записи хранения.

4. Потоковая линия продолжается, и управляемый агент берет следующее задание. Управляемый агент вызывает интерфейс командной строки (CLI) для обновления параметра приложения WEBSITE_RUN_FROM_PACKAGE с новой ссылкой на zip-файл публикации для промежуточного слота.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

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

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

Руководства по развертыванию

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

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

• Включите номера версий в имена zip-файлов развернутого пакета. При обновлении WEBSITE_RUN_FROM_PACKAGE параметра приложения для ссылки на пакет развертывания с другим именем файла служба приложений автоматически извлекает новый пакет и перезапускается.

• Используйте слоты развертывания для надежных развертываний кода.

• Рассмотрите возможность использовать как управляемые, так и локальные агенты.

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

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

• Используйте IaC для автоматизации развертываний инфраструктуры.

• Непрерывно проверяйте производительность рабочей нагрузки и устойчивость с помощью таких служб, как Azure Load Testing и Azure Chaos Studio.

Настройка

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

• Никогда не храните пароли или ключи доступа в системе контроля версий. Храните секреты в Key Vault.

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

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

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

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

Наблюдение

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

Мониторинг трех ключевых уровней:

• Код приложения: Отслеживайте данные телеметрии для конкретного приложения и пользовательские метрики.

• Инфраструктура (среда выполнения): Мониторинг среды выполнения службы приложений.

• Платформа (ресурсы Azure): Сбор метрик и журналов из служб Azure, таких как Шлюз приложений, База данных SQL и Key Vault.

Дополнительные сведения см. в журнале действий Azure, журналах ресурсов Azure и ведении журнала приложений службы приложений.

Мониторинг платформы

Мониторинг платформы собирает данные из служб Microsoft Azure в вашей архитектуре.

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

  Ресурс Azure	Описания метрик и журналов
  Шлюз приложений	Описание метрик и журналов для шлюза приложений
  Брандмауэр веб-приложений Azure	Метрики и описания журналов брандмауэра веб-приложений Azure
  Служба приложений	Описание метрик и журналов службы приложений
  SQL Database	Описание метрик и журналов базы данных SQL
  Azure Cosmos DB (облачная база данных)	Описания метрик и журналов Azure Cosmos DB
  Key Vault (Хранилище ключей)	Описания метрик и журналов Key Vault
  Хранилище BLOB-объектов	Описания метрик и логов BLOB-хранилища
  Application Insights	Описания метрик и журналов Application Insights
  Общедоступный IP-адрес	Метрики и описания общедоступных IP-адресов

• Сбалансируйте потребности в наблюдаемости с затратами. Чем больше собранных данных, тем выше стоимость. Подробнее см. в разделе «Вычисления затрат и параметры Log Analytics» и «Цены на рабочую область Log Analytics».

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

  • Обзор оповещений Azure Monitor
  • Оповещения шлюза приложений
  • Оповещения Службы приложений
  • Оповещения базы данных SQL
  • Оповещения Blob-хранилища
  • Оповещения Key Vault

Шлюз приложений

Шлюз приложений отслеживает работоспособности внутреннего пула с помощью проб работоспособности по умолчанию. Используйте журналы доступа шлюза приложений для сбора таких сведений, как метки времени, коды ответов HTTP и пути URL-адреса. Дополнительные сведения см. в журналах работоспособности и диагностики внутреннего сервера.

Служба приложений

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

• Включите автоматическое инструментирование для расширения инструментирования без изменений кода. Эта функция обеспечивает видимость мониторинга производительности приложений (APM). Дополнительные сведения см. в разделе "Мониторинг производительности службы приложений".

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

• Используйте инструментирование на основе кода для пользовательской телеметрии. Application Insights также поддерживает инструментирование на основе кода для телеметрии пользовательских приложений. Добавьте дистрибутив Azure Monitor OpenTelemetry в код.

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

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

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

База данных

• Включите мониторинг базы данных для базы данных SQL. Используйте средство наблюдения за базами данных, которое является управляемым решением мониторинга для служб баз данных в семействе SQL Azure. Дополнительные сведения см. в статье "Мониторинг базы данных SQL" с помощью Azure Monitor.

• Не включайте и не настраивайте аналитику Azure Cosmos DB, если архитектура содержит Azure Cosmos DB.

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки проектного решения на эффективность производительности .

Шлюз приложений

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

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

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

• Следуйте указаниям по размеру подсети шлюза приложений.

Служба приложений

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

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

• Попробуйте открыть запрос в службу поддержки, чтобы увеличить максимальное число работников до величины, равной удвоенному количеству экземпляров, если Служба приложений последовательно использует половину максимального числа экземпляров. Максимальное количество экземпляров по умолчанию составляет до 30 для плана Службы приложений "Премиум" и 10 для стандартного плана.

• Рассмотрите возможность развертывания нескольких экземпляров приложения, когда App Service начнет достигать пределов масштабирования.

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

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

• Рекомендуется использовать среду службы приложений , чтобы предотвратить шумные проблемы соседей.

SQL Database

Масштабирование базы данных включает в себя множество соображений, выходящих за рамки этой архитектуры. Дополнительные сведения о масштабировании базы данных SQL см. в следующих ресурсах:

• Динамическое масштабирование ресурсов базы данных с минимальным временем простоя
• Горизонтальное масштабирование с помощью базы данных SQL
• Используйте реплики только для чтения для разгрузки рабочих нагрузок, связанных с выполнением запросов только для чтения

Другие рекомендации по масштабируемости

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

• Рекомендуется кэширование для следующих типов данных для повышения производительности и масштабируемости:

  • Данные о полустатических транзакциях
  • Состояние сеанса
  • Сложные выходные данные HTML

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

• Масштабирование приложения в службе приложений
• Масштабирование шлюза приложений и брандмауэра веб-приложений Azure

Связанные ресурсы

• Шаблоны корпоративных веб-приложений
• Руководство по приватному соединению в виртуальной сети Azure