Руководство. Создание безопасного n-уровня приложения в службе приложение Azure

  • Статья

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

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

Архитектура сценария

На следующей схеме показана архитектура, которую вы создадите в рамках этого руководства.

Architecture diagram of an n-tier App Service.

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

Примечание.

Интеграция виртуальной сети и частные конечные точки доступны вплоть до уровня "Базовый" в Служба приложений. Уровень "Бесплатный " не поддерживает эти функции. С этой архитектурой:

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

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

Из этого руководства вы узнаете, как выполнять такие задачи:

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

Необходимые компоненты

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

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

Для работы с этим руководством:

  • Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см . в кратком руководстве по Bash в Azure Cloud Shell.

  • Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

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

    • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.

    • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

1. Создание двух экземпляров веб-приложения

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

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

    # Save resource group name and region as variables for convenience
groupName=myresourcegroup
region=eastus
az group create --name $groupName --location $region

  2. Создание плана службы приложений. Замените <app-service-plan-name> уникальным именем. Измените параметр, --sku если необходимо использовать другой номер SKU. Убедитесь, что вы не используете бесплатный уровень, так как этот номер SKU не поддерживает необходимые сетевые функции.

    # Save App Service plan name as a variable for convenience
aspName=<app-service-plan-name>
az appservice plan create --name $aspName --resource-group $groupName --is-linux --location $region --sku P1V3

  3. Создайте веб-приложения. Замените <frontend-app-name> и <backend-app-name> двумя глобально уникальными именами (допустимыми символами являются a-z, 0-9и -). В этом руководстве приведены примеры приложений Node.js. Если вы хотите использовать собственные приложения, измените --runtime параметр соответствующим образом. Запустите az webapp list-runtimes список доступных сред выполнения.

    az webapp create --name <frontend-app-name> --resource-group $groupName --plan $aspName --runtime "NODE:18-lts"
az webapp create --name <backend-app-name> --resource-group $groupName --plan $aspName --runtime "NODE:18-lts"

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

Вы создадите следующие сетевые ресурсы:

  • Виртуальная сеть.
  • Подсеть для интеграции Служба приложений виртуальной сети.
  • Подсеть для частной конечной точки.
  • Частная зона DNS.
  • Частная конечная точка.

  1. Создайте виртуальную сеть. Замените <virtual-network-name> уникальным именем.

    # Save vnet name as variable for convenience
vnetName=<virtual-network-name>
az network vnet create --resource-group $groupName --location $region --name $vnetName --address-prefixes 10.0.0.0/16

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

    az network vnet subnet create --resource-group $groupName --vnet-name $vnetName --name vnet-integration-subnet --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms --disable-private-endpoint-network-policies false

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

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

    az network vnet subnet create --resource-group $groupName --vnet-name $vnetName --name private-endpoint-subnet --address-prefixes 10.0.1.0/24 --disable-private-endpoint-network-policies true

    Для подсетей частной конечной точки необходимо отключить политики сети частной конечной точки, установив для него --disable-private-endpoint-network-policies значение true.

  4. Создайте частную зону DNS.

    az network private-dns zone create --resource-group $groupName --name privatelink.azurewebsites.net

    Дополнительные сведения об этих параметрах см. в разделе "Конфигурация DNS частной конечной точки Azure".

    Примечание.

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

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

    az network private-dns link vnet create --resource-group $groupName --name myDnsLink --zone-name privatelink.azurewebsites.net --virtual-network $vnetName --registration-enabled False

  6. В подсети частной конечной точки виртуальной сети создайте частную конечную точку для внутреннего веб-приложения. Замените <backend-app-name> на имя внутреннего веб-приложения.

    # Get backend web app resource ID
resourceId=$(az webapp show --resource-group $groupName --name <backend-app-name> --query id --output tsv)
az network private-endpoint create --resource-group $groupName --name myPrivateEndpoint --location $region --connection-name myConnection --private-connection-resource-id $resourceId --group-id sites --vnet-name $vnetName --subnet private-endpoint-subnet

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

    az network private-endpoint dns-zone-group create --resource-group $groupName --endpoint-name myPrivateEndpoint --name myZoneGroup --private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net

  8. При создании частной конечной точки для Служба приложений общедоступный доступ неявно отключается. Если вы пытаетесь получить доступ к внутреннему веб-приложению с помощью своего URL-адреса по умолчанию, ваш доступ запрещен. В браузере перейдите к <backend-app-name>.azurewebsites.net подтверждению этого поведения.

    Screenshot of 403 error when trying to access backend web app directly.

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

3. Настройка интеграции виртуальной сети в интерфейсном веб-приложении

Включение интеграции с виртуальной сетью в приложении. Замените <frontend-app-name> имя внешнего веб-приложения.

az webapp vnet-integration add --resource-group $groupName --name <frontend-app-name> --vnet $vnetName --subnet vnet-integration-subnet

Интеграция с виртуальной сетью позволяет исходящему трафику поступать непосредственно в виртуальную сеть. По умолчанию в виртуальную сеть направляется только локальный IP-трафик, определенный в RFC-1918 — это то, что необходимо для частных конечных точек. Сведения о маршрутизации всего трафика в виртуальную сеть см. в разделе Управление маршрутизацией при интеграции с виртуальной сетью. Маршрутизацию всего трафика можно также использовать в ситуации, если через виртуальную сеть, например через NAT виртуальных сетей Azure или Брандмауэр Azure, требуется маршрутизировать интернет-трафик.

4. Включение развертывания в серверное веб-приложение из Интернета

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

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

    az webapp update --resource-group $groupName --name <backend-app-name> --set publicNetworkAccess=Enabled

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

    az resource update --resource-group $groupName --name <backend-app-name> --namespace Microsoft.Web --resource-type sites --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny

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

    az resource update --resource-group $groupName --name <backend-app-name> --namespace Microsoft.Web --resource-type sites --set properties.siteConfig.scmIpSecurityRestrictionsDefaultAction=Allow

5. Блокировка доступа FTP и SCM

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

  1. Отключите ftp-доступ для внешних и внутренних веб-приложений. Замените <frontend-app-name> имена приложений и <backend-app-name> их именами.

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

  2. Отключите базовый доступ к портам WebDeploy и сайтам средств SCM/advanced tool для обоих веб-приложений. Замените <frontend-app-name> имена приложений и <backend-app-name> их именами.

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

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

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

  1. Перейдите к примеру приложения Node.js серверной части. Это простое приложение Hello World.

  2. Нажмите кнопку Вилка в правом верхнем углу на странице GitHub.

  3. Выберите владельца и оставьте имя репозитория по умолчанию.

  4. Щелкните Создать вилку.

  5. Повторите тот же процесс для Node.js интерфейсного приложения. Это базовое веб-приложение, которое обращается к удаленный URL-адрес.

  6. Создайте субъект-службу. Замените <subscription-id>, <frontend-app-name>а также <backend-app-name> значениями.

    az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/$groupName/providers/Microsoft.Web/sites/<frontend-app-name> /subscriptions/<subscription-id>/resourceGroups/$groupName/providers/Microsoft.Web/sites/<backend-app-name> --sdk-auth

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

  7. Чтобы сохранить учетные данные субъекта-службы в качестве секретов GitHub, перейдите к одному из вилочных репозиториев в GitHub и перейдите к Параметры> Security>Secret и переменным>Actions.

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

    Имя. Значение
    AZURE_APP_ID <application/client-id>
    AZURE_PASSWORD <client-secret>
    AZURE_TENANT_ID <tenant-id>
    AZURE_SUBSCRIPTION_ID <subscription-id>

  9. Повторите этот процесс для другого вилированного репозитория примера.

  10. Чтобы настроить непрерывное развертывание с помощью GitHub Actions, войдите в портал Azure.

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

  12. В области слева выберите Центр развертывания. Затем выберите Параметры.

  13. В поле "Источник" выберите "GitHub" в параметрах CI/CD.

    Screenshot that shows how to choose the deployment source.

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

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

    Параметр Значение
    Организация <your-GitHub-organization>
    Репозиторий nodejs-frontend
    Филиал main

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

  17. Повторите те же действия для внутреннего веб-приложения. Параметры Центра развертывания приведены в следующей таблице.

    Параметр Значение
    Организация <your-GitHub-organization>
    Репозиторий nodejs-backend
    Филиал main

7. Использование субъекта-службы для развертывания GitHub Actions

Конфигурация Центра развертывания создала файл рабочего процесса по умолчанию в каждом из примеров репозиториев, но по умолчанию использует профиль публикации, который использует базовую проверку подлинности. Так как вы отключили базовую проверку подлинности, если вы проверка вкладку "Журналы" в Центре развертывания, вы увидите, что автоматически активируемое развертывание приводит к ошибке. Необходимо изменить файл рабочего процесса, чтобы использовать субъект-службу для проверки подлинности с помощью Служба приложений. Примеры рабочих процессов см. в разделе "Добавление файла рабочего процесса в репозиторий GitHub".

  1. Откройте один из вложенных репозиториев GitHub и перейдите в <repo-name>/.github/workflows/ каталог.

  2. Выберите автоматически созданный файл рабочего процесса и нажмите кнопку "карандаш" в правом верхнем углу, чтобы изменить файл. Замените содержимое следующим текстом, который предполагает, что вы создали секреты GitHub ранее для учетных данных. Обновите заполнитель в <web-app-name> разделе "env", а затем зафиксируйте его непосредственно в главной ветви. Эта фиксация активирует действие GitHub для повторного выполнения и развертывания кода, на этот раз с помощью субъекта-службы для проверки подлинности.

    name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
  NODE_VERSION: '18.x'                # set this to the node version to use
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: npm install, build
        run: |
          npm install
          npm run build --if-present

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: node-app
          path: .

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v2
        with:
          name: node-app
      - uses: azure/login@v1
        with:
          creds: |
            {
              "clientId": "${{ secrets.AZURE_APP_ID }}",
              "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
              "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
              "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
            }

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

      - name: logout
        run: |
          az logout

  3. Повторите этот процесс для файла рабочего процесса в другом вилке репозитория GitHub.

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

Подробные инструкции по настройке непрерывного развертывания с поставщиками, такими как GitHub Actions, см. в статье "Непрерывное развертывание в службе приложение Azure".

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

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

  2. В текстовом поле введите URL-адрес для внутреннего веб-приложения: https://<backend-app-name>.azurewebsites.net Если вы правильно настроили подключения, необходимо получить сообщение "Hello из внутреннего веб-приложения!", которое является всем содержимым внутреннего веб-приложения. Весь исходящий трафик из интерфейсного веб-приложения направляется через виртуальную сеть. Интерфейсный веб-приложение безопасно подключается к внутреннему веб-приложению через частную конечную точку. Если что-то не так с подключениями, интерфейсное веб-приложение завершает работу.

  3. Попробуйте перейти непосредственно к внутреннему веб-приложению с его URL-адресом: https://<backend-app-name>.azurewebsites.net Отобразится сообщение Web App - Unavailable. Если вы можете получить доступ к приложению, убедитесь, что вы настроили частную конечную точку и что ограничения доступа для приложения будут запрещены для всего трафика для основного веб-приложения.

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

    az webapp ssh --resource-group $groupName --name <frontend-app-name>

  5. Когда оболочка откроется в браузере, запустите nslookup , чтобы убедиться, что серверное веб-приложение достигается с помощью частного IP-адреса внутреннего веб-приложения. Вы также можете выполнить curl проверку содержимого сайта еще раз. Замените <backend-app-name> на имя внутреннего веб-приложения.

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

    Screenshot of SSH session showing how to validate app connections.

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

    Screenshot of App Service Networking page showing the inbound IP of the app.

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

    Screenshot of an external terminal doing a nslookup and curl of the back-end web app.

    Возвращает nslookup общедоступный IP-адрес для внутреннего веб-приложения. Так как общедоступный доступ к внутреннему веб-приложению отключен, если вы пытаетесь получить общедоступный IP-адрес, вы получите ошибку отказа в доступе. Эта ошибка означает, что этот сайт недоступен из общедоступного Интернета, что является предполагаемым поведением. Не nslookup разрешается частный IP-адрес, так как его можно разрешить только из виртуальной сети через частную зону DNS. Только интерфейсное веб-приложение находится в виртуальной сети. Если вы попытаетесь запустить curl серверное веб-приложение из внешнего терминала, html-код, который возвращается Web App - Unavailable. Эта ошибка отображает HTML-код страницы ошибок, который вы видели ранее при попытке перейти к внутреннему веб-приложению в браузере.

9. Очистка ресурсов

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

az group delete --name myresourcegroup

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

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

Существует ли альтернатива развертыванию с помощью субъекта-службы?

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

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

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

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

Безопасно ли оставить внутренний SCM общедоступным?

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

Существует ли способ развертывания без открытия внутреннего сайта SCM вообще?

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

Как развернуть эту архитектуру с помощью ARM/Bicep?

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

Сведения о развертывании шаблонов ARM/Bicep см. в статье "Развертывание ресурсов с помощью Bicep и Azure CLI".

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

Интеграция приложения с виртуальной сетью Azure

Сетевые функции Службы приложений

Планирование шаблонов надежных веб-приложений (.NET)