チュートリアル: セキュリティで保護された n 層アプリを Azure App Service で作成する

[アーティクル]
03/17/2023

多くのアプリケーションには、1 つ以上のコンポーネントがあります。たとえば、バックエンド API または Web アプリにパブリックにアクセス可能なフロントエンドがこれらに接続し、次に、これらがデータベース、ストレージアカウント、キーコンテナー、別の VM、またはこれらのリソースの組み合わせに接続する場合などです。このアーキテクチャが n 層アプリケーションを構成します。このようなアプリケーションは、バックエンドリソースを最大限に保護するように設計することが重要です。

このチュートリアルでは、別のネットワーク分離 Web アプリに接続するフロントエンド Web アプリと共に、セキュリティで保護された n 層アプリケーションをデプロイする方法について説明します。 Azure Virtual Network 内では、仮想ネットワーク統合とプライベートエンドポイントを使用して、すべてのトラフィックが分離されます。他のシナリオを含むより包括的なガイダンスについては、次を参照してください。

シナリオのアーキテクチャ

次の図は、このチュートリアルで作成するアーキテクチャを示しています。

Architecture diagram of an n-tier App Service.

仮想ネットワーク: 2 つのサブネットを含んでいます。1 つはフロントエンド Web アプリと統合され、もう 1 つはバックエンド Web アプリ用のプライベートエンドポイントを備えています。仮想ネットワークでは、それに統合されているフロントエンドアプリを除く、すべての受信ネットワークトラフィックをブロックします。
フロントエンド Web アプリ: 仮想ネットワークに統合され、パブリックインターネットからアクセスできます。
バックエンド Web アプリ: 仮想ネットワーク内のプライベートエンドポイント経由でのみアクセスできます。
プライベートエンドポイント: バックエンド Web アプリに統合され、Web アプリにプライベート IP アドレスを使用してアクセスできるようにします。
プライベート DNS ゾーン: DNS 名をプライベートエンドポイントの IP アドレスに解決できるようにします。

Note

仮想ネットワーク統合とプライベートエンドポイントを利用できるのは、App Service の Basic レベルまでです。 Free レベルでは、これらの機能をサポートしていません。このアーキテクチャでは、次のことが行われます。

バックエンドアプリへのパブリックトラフィックはブロックされます。
App Service からの送信トラフィックが仮想ネットワークにルーティングされてバックエンドアプリに到達できます。
App Service では、バックエンドアプリへの DNS 解決を実行できます。

このシナリオは、App Service で可能な n 層シナリオの 1 つを示しています。このチュートリアルで説明する概念を利用して、より複雑な n 層アプリを構築できます。

ここでは、次の内容について学習します。

App Service 仮想ネットワーク統合用の仮想ネットワークとサブネットを作成します。
プライベート DNS ゾーンを作成します。
プライベートエンドポイントを作成します。
App Service で仮想ネットワーク統合を構成します。
App Service で基本認証を無効にします。
ロックダウンされたバックエンド Web アプリに継続的にデプロイします。

前提条件

このチュートリアルでは、GitHub でホストされている 2 つのサンプル Node.js アプリを使用します。 GitHub アカウントをまだお持ちでない場合は、無料でアカウントを作成できます。

Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。

このチュートリアルを完了するには、以下が必要です。

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンスコマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
- ローカルインストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、Azure CLI でのサインインに関するページを参照してください。
- 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

1. Web アプリの 2 つのインスタンスを作成する

Web アプリのインスタンスは、フロントエンド用に 1 つ、バックエンド用に 1 つの 2 つが必要です。仮想ネットワーク統合とプライベートエンドポイントを使用するには、少なくとも Basic レベルを使用する必要があります。仮想ネットワーク統合とその他の構成は、後で構成します。

このチュートリアルで作成するすべてのリソースを管理する、リソースグループを作成します。

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

Create an App Service plan. <app-service-plan-name> を一意の名前に置き換えます。別の SKU を使用する必要がある場合は、--sku パラメーターを変更します。 Free レベルの 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
```
Web アプリを作成します。 <frontend-app-name> および <backend-app-name> を、グローバルに一意な 2 つの名前に置き換えます (有効な文字は、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. ネットワークインフラストラクチャを作成する

次のネットワークリソースを作成します。

仮想ネットワーク。
App Service 仮想ネットワーク統合用のサブネット。
プライベートエンドポイントのサブネット。
プライベート DNS ゾーン。
プライベートエンドポイント。

仮想ネットワークを作成します。 <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

"App Service 仮想ネットワーク統合用のサブネット" を作成します。
```
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
```
App Service の仮想ネットワーク統合サブネットには、少なくとも /26 の CIDR ブロックを割り当てることをお勧めします。 /24 では、必要以上のサイズになってしまいます。 --delegations Microsoft.Web/serverfarms では、サブネットを App Service の仮想ネットワーク統合に委任することを指定します。
"プライベートエンドポイント用に別のサブネット" を作成します。
```
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 に設定してプライベートエンドポイントのネットワークポリシーを無効にする必要があります。
"プライベート DNS ゾーン" を作成します。
```
az network private-dns zone create --resource-group $groupName --name privatelink.azurewebsites.net
```
これらの設定の詳細については、「Azure プライベートエンドポイントの DNS 構成」を参照してください。

Note

ポータルを使用してプライベートエンドポイントを作成すると、プライベート DNS ゾーンが自動的に作成されるため、個別に作成する必要はありません。このチュートリアルとの整合性を保つために、Azure CLI を使用してプライベート DNS ゾーンとプライベートエンドポイントを別々に作成します。

仮想ネットワークにプライベート DNS ゾーンをリンクします。

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

仮想ネットワークのプライベートエンドポイントサブネットに、バックエンド Web アプリ用の "プライベートエンドポイント" を作成します。 <backend-app-name> は、バックエンド Web アプリの名前に置き換えます。

# 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

バックエンド Web アプリのプライベートエンドポイントで、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
```
App Service のプライベートエンドポイントを作成すると、パブリックアクセスは暗黙的に無効になります。既定の URL を使用してバックエンド Web アプリにアクセスしようとすると、アクセスは拒否されます。ブラウザーから、<backend-app-name>.azurewebsites.net に移動して、この動作を確認します。

プライベートエンドポイントでの App Service のアクセス制限の詳細については、「Azure App Service のアクセス制限」を参照してください。

3. フロントエンド Web アプリで仮想ネットワーク統合を構成する

アプリで仮想ネットワーク統合を有効にします。 <frontend-app-name> は、フロントエンド Web アプリの名前に置き換えます。

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

仮想ネットワーク統合により、アウトバウンドトラフィックを仮想ネットワークに直接流すことができます。既定では、RFC-1918 で定義されているローカル IP トラフィックのみが仮想ネットワークにルーティングされます。これはプライベートエンドポイントに必要な動作です。すべてのトラフィックを仮想ネットワークにルーティングする場合は、仮想ネットワーク統合のルーティングの管理に関するページを参照してください。すべてのトラフィックのルーティングは、Azure Virtual Network NAT や Azure Firewall など、仮想ネットワーク経由でインターネットトラフィックをルーティングする場合にも使用できます。

4. インターネットからのバックエンド Web アプリへのデプロイを有効にする

バックエンド Web アプリにはパブリックにアクセスできないため、SCM サイトをパブリックにアクセスできるようにして、継続的デプロイツールからアプリにアクセスできるようにする必要があります。メイン Web アプリ自体は、引き続きすべてのトラフィックを拒否できます。

バックエンド Web アプリのパブリックアクセスを有効にします。

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

メイン Web アプリがすべてのトラフィックを拒否するように、不一致のルールのアクションを設定します。この設定を使用すると、一般的なアプリアクセス設定がパブリックアクセスを許可するように設定されている場合でも、メイン Web アプリへのパブリックアクセスが拒否されます。
```
az resource update --resource-group $groupName --name <backend-app-name> --namespace Microsoft.Web --resource-type sites --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny
```

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 サイトがパブリックにアクセス可能になったら、セキュリティを強化してそれをロックダウンする必要があります。

フロントエンドとバックエンドの両方の Web アプリの 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

両方の Web アプリで WebDeploy ポートと SCM/高度なツールサイトへの基本認証アクセスを無効にします。 <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

App Service の基本認証を無効にすると、FTP と SCM エンドポイントへのアクセスが、Microsoft Entra ID によってサポートされているユーザーに制限され、それによってアプリの保護がさらに強化されます。ログインのテストと監視の方法など、基本認証の無効化について詳しくは、「App Service での基本認証の無効化」をご覧ください。

6. GitHub Actions を使用して継続的デプロイを構成する

Node.js バックエンドサンプルアプリに移動します。このアプリは単純な Hello World アプリです。
GitHub のページの右上にある [フォーク] ボタンを選択します。
[所有者] を選択し、リポジトリ名は既定のままにします。
[Create fork] (フォークの作成) を選択します。
Node.js フロントエンドサンプルアプリで同じプロセスを繰り返します。このアプリは、リモート URL にアクセスする基本の Web アプリです。
サービスプリンシパルを作成します。 <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
```
出力は、その App Service アプリへのアクセスを提供するロール割り当て資格情報を含む JSON オブジェクトです。次のステップのため、この JSON オブジェクトをコピーしておきます。それに含まれるクライアントシークレットは、このときだけ表示されます。常に最小限のアクセス権を付与することをお勧めします。この例のスコープは、リソースグループ全体ではなく、アプリだけに限定されます。
サービスプリンシパルの資格情報を GitHub シークレットとして保存するには、GitHub のフォークされたサンプルリポジトリのいずれかに移動し、[設定]>[セキュリティ]>[Secrets and variables] (シークレットと変数)>[アクション] に移動します。
[New repository secret] (新しいリポジトリシークレット) を選んで、次の値ごとにシークレットを作成します。値は、前にコピーした JSON 出力で確認できます。

Name 値

AZURE_APP_ID <application/client-id>

AZURE_PASSWORD <client-secret>

AZURE_TENANT_ID <tenant-id>

AZURE_SUBSCRIPTION_ID <subscription-id>
他のフォークされたサンプルリポジトリで、このプロセスを繰り返します。
GitHub Actions を使用して継続的デプロイを設定するには、Azure portal にサインインします。
フロントエンド Web アプリの [概要] ページに移動します。
左側のウィンドウで、 [デプロイセンター] を選択します。次に、 [設定] を選択します。
[ソース] ボックスで、CI/CD オプションから [GitHub] を選びます。
初めて GitHub からデプロイする場合は、 [承認] を選択し、承認のプロンプトに従います。別のユーザーのリポジトリからデプロイする場合は、 [アカウントの変更] を選択します。
前提条件の一環としてフォークされた Node.js サンプルアプリを使用している場合は、Organization、Repository、Branch に次の設定を使用します。

設定値

Organization <your-GitHub-organization>

リポジトリ nodejs-frontend

[Branch]\(ブランチ) メイン
[保存] を選択します。
バックエンド Web アプリで同じ手順を繰り返します。次の表にデプロイセンターの設定を示します。

設定値

Organization <your-GitHub-organization>

リポジトリ nodejs-backend

[Branch]\(ブランチ) メイン

Name	値
AZURE_APP_ID	`<application/client-id>`
AZURE_PASSWORD	`<client-secret>`
AZURE_TENANT_ID	`<tenant-id>`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`

設定	値
Organization	`<your-GitHub-organization>`
リポジトリ	nodejs-frontend
[Branch]\(ブランチ)	メイン

設定	値
Organization	`<your-GitHub-organization>`
リポジトリ	nodejs-backend
[Branch]\(ブランチ)	メイン

7. GitHub Actions のデプロイにサービスプリンシパルを使用する

デプロイセンターの構成では、各サンプルリポジトリに既定のワークフローファイルが作成されていますが、既定では発行プロファイルが使用され、これには基本認証が使用されます。基本認証は無効にしているため、デプロイセンターで [Logs] (ログ) タブを確認すると、自動的にトリガーされたデプロイによってエラーが発生していることがわかります。サービスプリンシパルを使用して App Service で認証するように、ワークフローファイルを変更する必要があります。サンプルワークフローについては、「GitHub リポジトリにワークフローファイルを追加する」を参照してください。

フォークされた GitHub リポジトリのいずれかを開き、<repo-name>/.github/workflows/ ディレクトリに移動します。

自動生成されたワークフローファイルを選択し、右上にある "鉛筆" ボタンを選んでファイルを編集します。内容を次のテキストに置き換えます。ここでは、資格情報用の GitHub シークレットを前に作成してあることが想定されています。 "env" セクションにあるプレースホルダー <web-app-name> を更新し、main ブランチに直接コミットします。このコミットにより、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

他のフォークされた GitHub リポジトリ内のワークフローファイルで、このプロセスを繰り返します。

新しい GitHub コミットによって、アプリごとに別のデプロイがトリガーされます。ワークフローではサービスプリンシパルを使用してアプリの SCM サイトで認証しているので、今回は、デプロイが成功するはずです。

GitHub Actions などのプロバイダーで継続的デプロイを構成する方法の詳しいガイダンスについては、「Azure App Service への継続的デプロイ」をご覧ください。

8. 接続とアプリのアクセスを検証する

URL https://<frontend-app-name>.azurewebsites.net を使用してフロントエンド Web アプリを参照します。
テキストボックスに、バックエンド Web アプリの URL https://<backend-app-name>.azurewebsites.net を入力します。接続を正しく設定すると、"Hello from the backend web app!" というメッセージが表示されます。これが、バックエンド Web アプリのコンテンツ全体です。フロントエンド Web アプリからのすべての "送信" トラフィックが仮想ネットワーク経由でルーティングされます。フロントエンド Web アプリは、プライベートエンドポイントを介してバックエンド Web アプリに安全に接続しています。接続に問題があると、フロントエンド Web アプリはクラッシュします。
URL https://<backend-app-name>.azurewebsites.net を使用してバックエンド Web アプリに直接移動してみてください。 Web App - Unavailable というメッセージが表示されます。アプリに到達できる場合は、プライベートエンドポイントを構成していること、およびメイン Web アプリではアプリのアクセス制限がすべてのトラフィックを拒否するように設定されていることを確認します。
フロントエンド Web アプリがプライベートリンクを介してバックエンド Web アプリに到達していることをさらに検証するには、フロントエンドのインスタンスのいずれかに SSH 接続します。 SSH 接続するには、次のコマンドを実行します。これにより、アプリの Web コンテナーへの SSH セッションが確立され、ブラウザーでリモートシェルが開きます。
```
az webapp ssh --resource-group $groupName --name <frontend-app-name>
```
ブラウザーでシェルが開いたら、nslookup を実行して、バックエンド Web アプリのプライベート IP を使用してバックエンド Web アプリに到達していることを確認します。 curl を実行して、サイトコンテンツをもう一度検証することもできます。 <backend-app-name> は、バックエンド Web アプリの名前に置き換えます。
```
nslookup <backend-app-name>.azurewebsites.net
curl https://<backend-app-name>.azurewebsites.net
```
nslookup は、バックエンド Web アプリのプライベート IP アドレスに解決されます。このプライベート IP アドレスは、仮想ネットワークからのアドレスであることが必要です。プライベート IP を確認するには、バックエンド Web アプリの [ネットワークの種類] ページに移動します。
別のターミナル (フロントエンドのインスタンス上の SSH セッションではないもの) から同じ nslookup および curl コマンドを繰り返します。

nslookup では、バックエンド Web アプリのパブリック IP を返します。バックエンド Web アプリへのパブリックアクセスは無効になっているため、パブリック IP にアクセスしようとすると、アクセス拒否エラーが発生します。このエラーは、このサイトにはパブリックインターネットからアクセスできないことを意味します。これは意図した動作です。 nslookup はプライベート IP に解決されません。これは、プライベート DNS ゾーンを介して仮想ネットワーク内からのみ解決できるからです。フロントエンド Web アプリのみが仮想ネットワーク内にあります。外部ターミナルからバックエンド Web アプリで curl を実行しようとすると、返される HTML に Web App - Unavailable が含まれます。このエラーで表示されるのは、前にブラウザーでバックエンド Web アプリに移動しようとしたときに表示されたエラーページの HTML です。

9.リソースをクリーンアップする

前の手順では、リソースグループ内に Azure リソースを作成しました。これらのリソースが将来必要になると想定していない場合、Cloud Shell で次のコマンドを実行して、リソースグループを削除します。

az group delete --name myresourcegroup

このコマンドの実行には、数分かかる場合があります。

よく寄せられる質問

サービスプリンシパルを使用するデプロイに代わる方法はありますか?
App Service で GitHub Actions のデプロイを構成するとどうなりますか?
バックエンド SCM をパブリックにアクセス可能なままにしても安全ですか?
バックエンド SCM サイトをまったく開かずにデプロイする方法はありますか?
ARM/Bicep を使用してこのアーキテクチャをデプロイするにはどうすればよいですか?

サービスプリンシパルを使用するデプロイに代わる方法はありますか?

このチュートリアルでは基本認証を無効にしているため、ユーザー名とパスワードを使用してバックエンド SCM サイトで認証できません。また、発行プロファイルを使用してもできません。サービスプリンシパルの代わりに、OpenID Connect を使用することもできます。

App Service で GitHub Actions のデプロイを構成するとどうなりますか?

Azure によって、リポジトリにワークフローファイルが自動生成されます。選択したリポジトリおよびブランチでの新しいコミットが App Service アプリに継続的にデプロイされるようになりました。コミットとデプロイは、 [ログ] タブで追跡できます。

発行プロファイルを使って App Service への認証を行う既定のワークフローファイルが、GitHub リポジトリに追加されます。このファイルは、<repo-name>/.github/workflows/ ディレクトリに移動して見ることができます。

バックエンド SCM をパブリックにアクセス可能なままにしても安全ですか?

FTP および SCM アクセスをロックダウンすると、SCM エンドポイントにアクセスできるのは (それがパブリックにアクセス可能な場合でも)、Microsoft Entra バックエンドプリンシパルのみです。この設定を使用すると、バックエンド Web アプリが引き続きセキュリティで保護されます。

バックエンド SCM サイトをまったく開かずにデプロイする方法はありますか?

SCM サイトへのパブリックアクセスを有効にすることを懸念している場合、またはポリシーによって制限されている場合は、ZIP パッケージからの実行など、他の App Service のデプロイオプションを検討してください。

ARM/Bicep を使用してこのアーキテクチャをデプロイするにはどうすればよいですか?

このチュートリアルで作成したリソースは、ARM/Bicep テンプレートを使ってデプロイできます。バックエンド Web アプリに接続されたアプリの Bicep テンプレートを使用すると、セキュリティで保護された n 層アプリソリューションを作成できます。

ARM/Bicep テンプレートをデプロイする方法については、「Bicep と Azure CLI を使用してリソースをデプロイする方法」をご覧ください。

次のステップ

アプリを Azure 仮想ネットワークに統合する

App Service のネットワーク機能

信頼性の高い Web アプリパターン計画 (.NET)

次の方法で共有

チュートリアル: セキュリティで保護された n 層アプリを Azure App Service で作成する

シナリオのアーキテクチャ

前提条件

1. Web アプリの 2 つのインスタンスを作成する

2. ネットワークインフラストラクチャを作成する

3. フロントエンド Web アプリで仮想ネットワーク統合を構成する

4. インターネットからのバックエンド Web アプリへのデプロイを有効にする

5. FTP および SCM のアクセスをロックダウンする

6. GitHub Actions を使用して継続的デプロイを構成する

7. GitHub Actions のデプロイにサービスプリンシパルを使用する

8. 接続とアプリのアクセスを検証する

9.リソースをクリーンアップする

よく寄せられる質問

サービスプリンシパルを使用するデプロイに代わる方法はありますか?

App Service で GitHub Actions のデプロイを構成するとどうなりますか?

バックエンド SCM をパブリックにアクセス可能なままにしても安全ですか?

バックエンド SCM サイトをまったく開かずにデプロイする方法はありますか?

ARM/Bicep を使用してこのアーキテクチャをデプロイするにはどうすればよいですか?

次のステップ

フィードバック

その他のリソース

次の方法で共有

チュートリアル: セキュリティで保護された n 層アプリを Azure App Service で作成する

シナリオのアーキテクチャ

前提条件

1. Web アプリの 2 つのインスタンスを作成する

2. ネットワーク インフラストラクチャを作成する

3. フロントエンド Web アプリで仮想ネットワーク統合を構成する

4. インターネットからのバックエンド Web アプリへのデプロイを有効にする

5. FTP および SCM のアクセスをロックダウンする

6. GitHub Actions を使用して継続的デプロイを構成する

7. GitHub Actions のデプロイにサービス プリンシパルを使用する

8. 接続とアプリのアクセスを検証する

9.リソースをクリーンアップする

よく寄せられる質問

サービス プリンシパルを使用するデプロイに代わる方法はありますか?

App Service で GitHub Actions のデプロイを構成するとどうなりますか?

バックエンド SCM をパブリックにアクセス可能なままにしても安全ですか?

バックエンド SCM サイトをまったく開かずにデプロイする方法はありますか?

ARM/Bicep を使用してこのアーキテクチャをデプロイするにはどうすればよいですか?

次のステップ

フィードバック

その他のリソース

2. ネットワークインフラストラクチャを作成する

7. GitHub Actions のデプロイにサービスプリンシパルを使用する

サービスプリンシパルを使用するデプロイに代わる方法はありますか?