Руководство: создание защищённого многоуровневого приложения в Служба приложений Azure

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

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

Изучив это руководство, вы:

  • Создание виртуальной сети и подсетей для интеграции виртуальной сети службы приложений
  • Создание частных зон DNS и частных конечных точек
  • Настройка интеграции виртуальной сети в Службе приложений
  • Отключение базовой проверки подлинности в службе приложений
  • Выполняйте непрерывное развертывание в защищенное серверное веб-приложение

Предварительные требования

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

Если у вас нет аккаунта Azure, создайте бесплатную учетную запись перед началом.

Чтобы пройти это руководство:

Просмотр архитектуры сценария

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

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

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

  • Интерфейсное веб-приложение интегрировано в виртуальную сеть и доступно из общедоступного Интернета.

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

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

  • Частная зона DNS обеспечивает разрешение DNS-имени в IP-адрес частной конечной точки.

Примечание.

Чтобы настроить интеграцию виртуальных сетей и частные конечные точки, потребуется уровень Basic уровня Служба приложений Azure или более высокого уровня. Уровень "Бесплатный " не поддерживает эти функции.

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

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

Создание двух веб-приложений

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

  1. Создайте группу ресурсов для управления всеми ресурсами в рамках этого руководства.

    Задайте для заполнителя <resource-group> имя новой группы ресурсов, например zava-resources. Установите для заполнителя <region-location> регион вашей новой группы ресурсов, например eastus.

    # Define variables for the resource group name and region location
resourceGroupName=<resource-group>
regionLocation=<region-location>

# Create the resource group
az group create --name $resourceGroupName --location $regionLocation

    Дополнительные сведения см. в справочнике команд az group create.

  2. Создайте план службы приложений для ваших ресурсов.

    Укажите в <app-service-plan> имя нового плана службы приложений, например zava-app-service-plan.

    В примере учебника для параметра задано --skuP1V3 значение (Premium V3). Это значение можно использовать или указать другой номер SKU. SKU должен поддерживать необходимые сетевые функции для этого руководства. Выберите уровень "Базовый" или "Выше".

    # Define a variable for the App Service plan name
appServicePlanName=<app-service-plan>

# Create the App Service plan
az appservice plan create --name $appServicePlanName --resource-group $resourceGroupName --is-linux --location $regionLocation --sku P1V3

    Дополнительные сведения см. в справочнике az appservice plan create.

  3. Создайте внешние и внутренние веб-приложения.

    В этом руководстве создаются два примера приложений Node.js, в которых версия языка среды выполнения — NODE:24-lts. Если вы предпочитаете использовать собственные приложения, задайте --runtime значение параметра <language-version> соответствующим образом. Вы можете выполнить команду az webapp list-runtimes, чтобы получить список доступных сред выполнения:

    az webapp list-runtimes

    <frontend-app-name> Задайте заполнитель имени нового внешнего веб-приложения, напримерzava-frontend-app. Имя должно быть глобально уникальным и состоять из допустимых символов (a-z, 0-9, -). Аналогичным образом задайте для заполнителя <backend-app-name> имя нового серверного веб-приложения, например zava-backend-app.

    # Define variables for the App Service web app names
frontendAppName=<frontend-app-name>
backendAppName=<backend-app-name>

# Create the web apps
az webapp create --name $frontendAppName --resource-group $resourceGroupName --plan $appServicePlanName --runtime "NODE:24-lts"
az webapp create --name $backendAppName  --resource-group $resourceGroupName --plan $appServicePlanName --runtime "NODE:24-lts"

    Дополнительные сведения см. в справочнике по команде az webapp create.

Создание сетевой инфраструктуры

Инфраструктура виртуальной сети состоит из следующих ресурсов:

  • Экземпляр Azure Virtual Network
  • Подсеть для интеграции виртуальной сети службы приложений
  • Другая подсеть для частной конечной точки
  • Зона Azure Частная зона DNS
  • Частная конечная точка

  1. создайте виртуальную сеть Azure;

    Укажите в поле <virtual-network-name> имя новой виртуальной сети, например zava-virtual-network. Это имя должно быть глобально уникальным.

    # Define a variable for the virtual network name
virtualNetworkName=<virtual-network-name>

# Create the virtual network
az network vnet create --resource-group $resourceGroupName --location $regionLocation --name $virtualNetworkName --address-prefixes 10.0.0.0/16

    Дополнительные сведения см. в справочнике по команде az network vnet create.

  2. Создайте подсеть для интеграции виртуальной сети службы приложений.

    Задайте для заполнителя <network-integration-subnet> имя новой подсети, поддерживающей интеграцию с виртуальной сетью, например, zava-integration-subnet.

    Для службы приложений рекомендуется, чтобы подсеть интеграции с виртуальной сетью имела блок CIDR не менее /26. Варианта /24 более чем достаточно. --delegations Microsoft.Web/serverfarms указывает, что подсеть делегирована для интеграции с виртуальной сетью Службы приложений.

    # Define a variable for the integration subnet name
networkIntegrationSubnet=<network-integration-subnet>

# Create the subnet for virtual network integration
az network vnet subnet create --resource-group $resourceGroupName --vnet-name $virtualNetworkName --name $networkIntegrationSubnet \
   --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms \
   --disable-private-endpoint-network-policies false

    Дополнительные сведения см. в справочнике по команде az network vnet subnet create.

  3. Создайте другую подсеть для частных конечных точек.

    Укажите в заполнителе <private-endpoint-subnet> имя новой подсети, которая поддерживает частную конечную точку, например zava-endpoint-subnet.

    # Define a variable for the private endpoint subnet name
privateEndpointSubnet=<private-endpoint-subnet>

# Create the subnet for the private endpoint
az network vnet subnet create --resource-group $resourceGroupName --vnet-name $virtualNetworkName --name $privateEndpointSubnet \
   --address-prefixes 10.0.1.0/24 \
   --disable-private-endpoint-network-policies true

    Для подсетей приватной конечной точки необходимо отключить сетевые политики приватной конечной точки, установив для флага --disable-private-endpoint-network-policies значение true. Дополнительные сведения см. в разделе "Необязательные параметры " для команды az network vnet subnet create .

    Примечание.

    Флаг --private-endpoint-network-policies может скоро заменить --disable-private-endpoint-network-policies флаг.

  4. Создайте зону Azure Частная зона DNS.

    Задайте для заполнителя <private-zone-name> имя новой зоны частного DNS, например zava-private.azurewebsites.net.

    # Define a variable for the Private DNS zone
privateDNSZone=<private-zone-name>

# Create the Private DNS zone
az network private-dns zone create --resource-group $resourceGroupName --name $privateDNSZone

    Дополнительные сведения см. в справочнике по команде az network vnet subnet create. Дополнительные сведения о настройке зоны Частная зона DNS см. в разделе Azure конфигурация зоны DNS службы.

    Примечание.

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

  5. Свяжите зону Частная зона DNS с виртуальной сетью.

    Укажите в заполнителе <dns-link-name> имя для вашей новой ссылки DNS, например zava-private-link.

    # Define a variable for the DNS link name
dnsLinkName=<dns-link-name>

# Create the link between the Private DNS zone and the virtual network
az network private-dns link vnet create --resource-group $resourceGroupName --name $dnsLinkName --zone-name $privateDNSZone \
   --virtual-network $virtualNetworkName --registration-enabled False

    Дополнительные сведения см. в справочнике по команде az network private-dns link vnet create.

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

    <private-endpoint-name> Задайте заполнитель имени новой частной конечной точки для внутреннего веб-приложения, напримерzava-backend-endpoint. Укажите в заполнителе <service-connection-name> имя нового подключения к службе, например zava-backend-connection.

    # Define variables for the private endpoint and service connection
privateEndpointName=<private-endpoint-name>
serviceConnectionName=<service-connection-name>

# Get the resource ID of the backend web app
resourceId=$(az webapp show --resource-group $resourceGroupName --name $backendAppName --query id --output tsv)

# Create the private endpoint for the backend web app by using the resource ID
az network private-endpoint create --resource-group $resourceGroupName --name $privateEndpointName --location $regionLocation \
   --connection-name $serviceConnectionName --private-connection-resource-id $resourceId \
   --group-id sites --vnet-name $virtualNetworkName --subnet $privateEndpointSubnet

    Дополнительные сведения см. в справочной статье по команде az network private-endpoint create.

  7. Свяжите частную конечную точку серверного веб-приложения с частной зоной DNS с помощью группы зон DNS.

    Установите для заполнителя <dns-zone-group-name> имя новой группы зон DNS, например zava-dns-zone-group. Группа зон DNS помогает автоматически обновлять зону Частная зона DNS при обновлении частной конечной точки.

    # Define a variable for the DNS Zone group
dnsZoneGroupName=<dns-zone-group-name>

# Link the private endpoint to the Private DNS      
az network private-endpoint dns-zone-group create --resource-group $resourceGroupName --endpoint-name $privateEndpointName \
   --name $dnsZoneGroupName --private-dns-zone $privateDNSZone --zone-name $privateDNSZone

    Дополнительные сведения см. в справочной информации о команде az network private-endpoint dns-zone-group create.

  8. Убедитесь, что прямой доступ к частной конечной точке запрещен.

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

    В браузере введите URL-адрес по умолчанию для внутреннего веб-приложения, например <backend-app-name>.azurewebsites.net.

    Сообщение браузера указывает, что прямой доступ запрещен:

    Снимок экрана: сообщение браузера, когда запрещен прямой доступ к внутреннему приложению.

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

Настройка интеграции виртуальной сети

После создания инфраструктуры виртуальной сети можно настроить интеграцию виртуальной сети в интерфейсном веб-приложении. Интеграция с виртуальной сетью позволяет исходящему трафику поступать непосредственно в виртуальную сеть. По умолчанию в виртуальную сеть направляется только локальный IP-трафик, определённый в RFC-1918 > Private Address Space. Этот уровень маршрутизации необходим для включения частных конечных точек.

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

az webapp vnet-integration add --resource-group $resourceGroupName --name $frontendAppName --vnet $virtualNetworkName --subnet $networkIntegrationSubnet

Дополнительные сведения см. в справочнике по команде az webapp vnet-integration add.

Сведения о маршрутизации всего трафика в виртуальную сеть см. в статье "Управление маршрутизацией интеграции виртуальной сети". Маршрутизация всего трафика также может использоваться, если вы хотите маршрутизировать интернет-трафик через виртуальную сеть, например через Azure Virtual Network NAT или Брандмауэр Azure.

Включить развертывание для серверного веб-приложения

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

  1. Включите общедоступный доступ для внутреннего веб-приложения.

    az webapp update --resource-group $resourceGroupName --name $backendAppName --set publicNetworkAccess=Enabled

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

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

    az resource update --resource-group $resourceGroupName --name $backendAppName --namespace Microsoft.Web \
   --resource-type sites --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny

  3. Задайте для сайта SCM несоответсвованное действие правила, чтобы разрешить весь трафик.

    az resource update --resource-group $resourceGroupName --name $backendAppName --namespace Microsoft.Web \
   --resource-type sites --set properties.siteConfig.scmIpSecurityRestrictionsDefaultAction=Allow

Ограничение доступа FTP и SCM

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

  1. Отключите ftp-доступ для внешнего и внутреннего веб-приложения:

    az resource update --resource-group $resourceGroupName --name ftp --namespace Microsoft.Web \
   --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false

az resource update --resource-group $resourceGroupName --name ftp --namespace Microsoft.Web \
   --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false

  2. Отключите доступ с использованием базовой аутентификации к портам WebDeploy и сайтам SCM и расширенных средств для обоих веб-приложений:

    az resource update --resource-group $resourceGroupName --name scm --namespace Microsoft.Web \
   --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false

az resource update --resource-group $resourceGroupName --name scm --namespace Microsoft.Web \
   --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false

Когда вы отключаете базовую аутентификацию в App Service, вы ограничиваете доступ к конечным точкам FTP и SCM только для пользователей, зарегистрированных в Microsoft Entra ID. Это действие дополнительно защищает ваши приложения. Дополнительные сведения об отключении базовой проверки подлинности, включая тестирование и мониторинг имен входа, см. в разделе "Отключение базовой проверки подлинности в службе приложений".

Настройка непрерывного развертывания с помощью GitHub Actions

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

Получите веб-приложения для тестирования развертывания

Репозитории Azure samples в GitHub предоставляют примеры приложений Node.js для развертывания.

  1. В браузере перейдите на страницу примера приложения серверной части Node.js.

    Форкните репозиторий на GitHub, чтобы у вас была своя копия для внесения изменений. В этом примере создается приложение Hello World. Вы развертываете это приложение в серверном веб-приложении.

  2. Повторите тот же процесс для примера приложения Node.js frontend.

    Форкните репозиторий на GitHub, чтобы у вас была своя копия для внесения изменений. В этом примере создается веб-приложение, которое извлекает и отображает содержимое URL-адреса. Вы развертываете это приложение в интерфейсном веб-приложении.

Настройка основной службы

Вам нужен субъект-службы для клиентского веб-приложения и серверного веб-приложения.

  1. Создайте служебный принципал.

    Задайте для заполнителя <service-principal-name> имя нового субъекта-службы, например zava-service-principal.

    Замените другие <placeholder> значения параметров сведениями для собственных ресурсов.

    # Define a variable for the service principal name
servicePrincipalName=<service-principal-name>

# Link the private endpoint to the Private DNS 

 az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<frontend-app-name> \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<backend-app-name>

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

    {
  "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "displayName": "<service-principal-name>",
  "password": "0Aa!1Bb!2Cc!3Dd!4Ee!5Ff!6Gg!7Hh!8Ii!9Jj!",
  "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee"
}

    JSON включает пароль субъекта-службы, который отображается только в настоящее время.

    Tip

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

  2. Скопируйте объект JSON, чтобы у вас была запись имени субъекта-службы.

  3. Укажите учетные данные принципала службы для выполнения операции входа в Azure в рамках рабочего процесса GitHub Action.

    Сохраните учетные данные как секреты GitHub, на которые ссылается workflow.

    1. В браузере перейдите в форк репозитория вашего серверного приложения Node.js на GitHub.

    2. Перейдите в Параметры>Безопасность>Секреты и переменные>Действия.

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

      Используйте значения из выходных данных JSON.

      Настройка Значение Пример
      AZURE_CLIENT_ID <application/client-id> 00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_TENANT_ID <tenant-id> aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID <subscription-id> cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

    4. Повторите этот процесс для форкнутого репозитория вашего фронтенд-приложения Node.js на GitHub.

Настройка непрерывного развертывания с помощью GitHub Actions

Вы можете настроить непрерывное развертывание с помощью GitHub Actions.

  1. На странице портала Azure перейдите на страницу Обзор для веб-приложения внешнего интерфейса.

  2. В меню слева выберите Развертывание>Центр развертывания.

  3. На вкладке Settings установите параметр Source значение GitHub:

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

  4. При первом развертывании из GitHub выберите Авторизовать и следуйте запросам авторизации. Если требуется выполнить развертывание из другого пользовательского репозитория, выберите Изменить учетную запись.

  5. После авторизации учетной записи Azure с помощью GitHub выберите Organization, Repository и Branch для настройки CI/CD. Если вы не можете найти организацию или репозиторий, может потребоваться включить дополнительные разрешения на GitHub. Дополнительные сведения см. в статье "Управление доступом пользователей к репозиториям организации".

    Настройка Значение
    Предприятие <your-GitHub-organization>
    Репозиторий <forked-repository-name>
    Филиал главный

  6. Выберите Сохранить.

  7. Повторите этот процесс для вашего серверного веб-приложения и соответствующего разветвлённого репозитория.

Проверка подключений и доступа к приложению

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

  1. Попробуйте перейти непосредственно к внутреннему веб-приложению с его URL-адресом https://<backend-app-name>.azurewebsites.net.

    Должно появиться следующее сообщение браузера:

    Снимок экрана: сообщение браузера, когда запрещен прямой доступ к внутреннему приложению.

    Если вы можете получить доступ к приложению, проверьте конфигурацию:

    • Убедитесь, что частная конечная точка настроена правильно.

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

  2. Теперь попробуйте перейти напрямую к вашему фронтенд веб-приложению по его URL-адресу https://<frontend-app-name>.azurewebsites.net.

    После успешного подключения отображается следующая страница:

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

  3. В поле URL-адреса введите URL-адрес серверного веб-приложения, https://<backend-app-name>.azurewebsites.net, и выберите Получить.

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

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

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

    Если что-то не так с подключениями, в выходных данных отображается сообщение об ошибке 403 . Запрещено .

Установка сеанса SSH и открытие удаленной оболочки

Убедитесь, что внешнее веб-приложение обращается к серверному веб-приложению через private link, подключившись по SSH к экземпляру внешнего приложения.

  1. Установите SSH-сеанс с веб-контейнером вашего приложения и откройте удаленную оболочку в окне браузера:

    az webapp ssh --resource-group $resourceGroupName --name $frontendAppName

    Дополнительные сведения см. в справочнике по команде az webapp ssh.

  2. После того как оболочка откроется в браузере, убедитесь, что ваше серверное веб-приложение доступно по частному IP-адресу вашего серверного веб-приложения.

    В следующих командах замените <placeholder> значения параметров сведениями для собственного ресурса.

    1. Выполните команду nslookup.

      nslookup <backend-app-name>.azurewebsites.net

    2. Выполните команду, чтобы проверить содержимое curl сайта еще раз:

      curl https://<backend-app-name>.azurewebsites.net

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

    Команда nslookup должна разрешить частный IP-адрес внутреннего веб-приложения. Частный IP-адрес должен быть адресом из виртуальной сети.

    Вы можете подтвердить частный IP-адрес на портале Azure. Перейдите на страницу "Параметры>сети " для внутреннего веб-приложения.

    Снимок экрана, на котором показана страница «Сеть» для веб-приложения на портале Azure с выделенным входящим IP-адресом.

  3. Повторите те же команды nslookup и curl из другого терминала (не из SSH-сеанса к экземплярам фронтенда).

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

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

    Команда nslookup не разрешается в частный IP-адрес, поскольку этот адрес может быть разрешён только внутри виртуальной сети с помощью частной зоны DNS. Только веб-приложение внешнего интерфейса находится в виртуальной сети. Если вы пытаетесь выполнить curl команду на серверном веб-приложении из внешнего терминала, возвращенный HTML-код содержит сообщение Error 403, запрещено — веб-приложение, которое вы пытались связаться, заблокировало доступ. Некоторые терминалы также отображают тот же HTML-код, что и страница ошибки, возвращаемая при попытке напрямую получить доступ к внутреннему веб-приложению.

Очистите ресурсы

На предыдущем шаге вы создали ресурсы Azure в группе ресурсов. Если эти ресурсы вам не понадобятся в будущем, вы можете удалить группу ресурсов, выполнив приведенную ниже команду в Cloud Shell.

Замените <placeholder> значение параметра сведениями для собственного ресурса:

az group delete --name <resource-group>

Выполнение этой команды может занять несколько минут.

Часто задаваемые вопросы

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

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

Развертывание с помощью других методов, отличных от субъекта-службы

В этом руководстве вы отключили обычную проверку подлинности. Вы не можете пройти проверку подлинности с помощью внутреннего сайта SCM с помощью имени пользователя и пароля или с помощью профиля публикации. Однако вместо проверки подлинности с помощью субъекта-службы можно использовать учетные данные OpenID Connect .

Настройка развертывания GitHub Actions в Службе приложений

Azure автоматически создает файл рабочего процесса в репозитории. Новые коммиты в выбранном репозитории и ветке непрерывно развертываются в ваше приложение App Service. Вы можете отслеживать фиксации и развертывания на вкладке Logs в GitHub.

В ваш репозиторий GitHub добавляется файл рабочего процесса по умолчанию, использующий профиль публикации для проверки подлинности в App Service. Этот файл можно просмотреть, перейдя в <repo-name>/.github/workflows/ каталог.

Подтверждение безопасного общедоступного доступа к внутреннему сайту SCM

Если вы ограничите доступ к FTP и SCM, то сможете гарантировать, что доступ к конечной точке SCM будут иметь только учетные записи, управляемые Microsoft Entra, даже если эта конечная точка общедоступна. Этот параметр помогает убедиться, что серверные веб-приложения по-прежнему защищены.

Развертывание без открытого внутреннего сайта SCM

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

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

Ресурсы, созданные в этом руководстве, можно развернуть с помощью шаблона Azure Resource Manager (шаблона ARM) или шаблона Bicep. Приложение, подключенное к Bicep-файлу серверного веб-приложения, позволяет создавать безопасное многоуровневое решение.

Инструкции по развертыванию шаблонов ARM и Bicep см. в статье Развертывание файлов Bicep с помощью Azure CLI.

Связанный контент

  • Last updated on