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

Шлюз приложений Azure — это балансировщик нагрузки веб-трафика, который позволяет управлять трафиком ваших приложений. Его можно использовать в качестве внутреннего балансировщика нагрузки приложений или в качестве балансировщика нагрузки приложений с выходом в Интернет (Как работает шлюз приложений | Microsoft Обучение).

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

С другой стороны, когда вы создаете частные конечные точки для служб Azure PaaS (например, функций Azure, Azure Key Vault, концентраторов событий и т. д.), связанным полным доменным именем для каждой службы является публичное имя.

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

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

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

Эталонная реализация этой архитектуры доступна на сайте GitHub.

Архитектура

На следующей диаграмме показано, как организация Contoso использует шлюз приложений Azure в качестве основного компонента для своего решения по имени личного домена.

Рабочий процесс

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

1. Прежде чем клиент отправит запрос из сети contoso в службу PaaS с поддержкой частной конечной точки, он разрешает имя личного домена с помощью сервера системы доменных имен (DNS).
2. DNS-сервер возвращает клиенту частный IP-адрес шлюза приложений.
3. Шлюз приложений принимает входящий трафик через определенный прослушиватель, настроенный с использованием IP-адреса, протокола и номера порта.
4. Затем запрос перенаправляется в службу PaaS с поддержкой частной конечной точки, которая настроена как серверная часть с использованием частной ссылки службы. полное доменное имя
   1. Шлюз приложений разрешает частную ссылку полное доменное имя с помощью DNS-сервера, который, в свою очередь, перенаправляет запрос в Azure DNS.
   2. Шлюз приложений отправляет трафик на правильный частный IP-адрес.

Компоненты

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

Шлюз приложений Azure В основе этого решения лежит брандмауэр веб-приложений (WAF) с брандмауэром веб-приложений (WAF) или без него, предоставляющий доступ к конечным точкам HTTP(S) или TCP и маршрутизирующий трафик к службам PaaS с поддержкой частной конечной точки.

Виртуальные сети Azure представляют собой изолированные и высокозащищенные среды для запуска виртуальных машин (ВМ) и приложений. Эта эталонная архитектура использует одноранговую топологию виртуальной сети типа «звезда». Виртуальная сеть концентратора содержит брандмауэр Azure, настраиваемый DNS-сервер и настраиваемые зоны DNS. В распределенной виртуальной сети находится подсеть шлюза приложений и подсети служб PaaS.

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

Брандмауэр Azure — это служба сетевой безопасности, которая защищает все ресурсы виртуальной сети Azure. Брандмауэр пропускает в качестве исходящего трафика только утвержденные службы и полные доменные имена (FQDN).

Хранилище ключей Azure хранит и управляет сертификатами, используемыми шлюзом приложений, а также секретами, используемыми разработчиками Contoso.

Частный DNS Azure используется для разрешения частных доменов конечных точек и домена constoso.corp.

Функции Azure бессерверное приложение.

Центры событий Azure современная платформа потоковой передачи больших данных и служба приема событий

Azure Космос БД полностью управляемая и бессерверная распределенная база данных

Хранилище Azure Решение облачного хранилища Microsoft для современных сценариев хранения данных

Экземпляры контейнеров Azure бессерверные контейнеры

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

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

Детали сценария

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

В этом примере вымышленная компания Contoso, Inc. имеет ряд служб, работающих в локальной сети, которые подключаются к защищенным частным конечным точкам службам Azure PaaS. Когда локальная служба отправляет запрос службе PaaS, она делает это, используя частное полное доменное имя (например, func.contoso.corp), DNS-серверы Contoso разрешают имя личного домена в частный IP-адрес шлюза приложений. Затем шлюз приложений отправляет запрос нужной службе PaaS, и поток трафика завершается.

Возможные варианты использования

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

Соображения

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

Для получения дополнительной информации см. Хорошо спроектированная платформа Microsoft Azure.

Масштабируемость

Учтите, что Шлюз приложений и WAF можно настроить для масштабирования в двух режимах:

• Автомасштабирование — При включенном автоматическом масштабировании шлюз приложений и номера SKU WAF v2 масштабируются или увеличиваются в зависимости от требований к трафику приложения. Этот режим обеспечивает большую гибкость вашего приложения и устраняет необходимость угадывать размер шлюза приложения или количество экземпляров.
• Руководство – Вы также можете выбрать ручной режим, в котором шлюз не будет автоматически масштабироваться. В этом режиме, если трафик превышает возможности шлюза приложений или WAF, это может привести к потере трафика.

Управляемость

При планировании управляемости учитывайте следующие моменты:

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

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

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

• Для получения полностью частного решения разверните шлюз приложений без какого-либо связанного общедоступного IP-адреса.
• Убедитесь, что секреты и учетные данные хранятся в безопасных местах, таких как Azure Key Vault, а не внедряются в код или файлы конфигурации.
• Для получения дополнительной информации: Базовый уровень безопасности Azure для шлюза приложений | Microsoft Обучение

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

Разверните этот сценарий

Чтобы развернуть этот сценарий, вы можете использовать Terraform, выполнив следующую команду:

terraform init
terraform apply

Проверьте развертывание

После развертывания решения вы можете загрузить результаты тестов (TestResults.trx) с помощью следующих команд:

resultsShareKey=$(terraform output -raw results_share_key)
resultsShareName=$(terraform output -raw results_share_name)
resultsAccountName=$(terraform output -raw results_account_name)
resultsFile=$(terraform output -raw results_file)
az storage file download --account-key $resultsShareKey --account-name $resultsAccountName --share-name $resultsShareName --path $resultsFile

Файл результатов должен выглядеть следующим образом:

Проверка журналов контейнера

Чтобы проверить журналы контейнера с помощью Azure CLI выполните следующую команду:

$resourceGroup=$(terraform output -raw resource_group)
$containerGroup=$(terraform output -raw contaner_group_name)
$containerName=$(terraform output -raw container_name)
az container logs --resource-group $resourceGroup --name $containerGroup --container-name $containerName

Пожалуйста, обратитесь к Модули Терраформирования Чтобы получить больше информации.