使用 Azure App 服務環境進行企業部署

Microsoft Entra ID

Azure 應用程式閘道

Azure App Service

Azure 防火牆

Azure 虛擬網路

Azure Private Link

此參考架構示範使用 App Service 環境第 3 版的常見企業工作負載。它也會說明加強工作負載安全性的最佳做法。

注意

App Service 環境第3版是此架構的主要元件。版本 1 和 2 於 2024 年 8 月 31 日淘汰。

GitHub 標誌 GitHub 上提供了此架構的參考實作。

架構

顯示 App Service 環境部署架構的圖表。

下載此架構的 Visio 檔案。

工作流程

您可以透過兩種方式部署 App Service 環境：

作為具有公用IP位址的外部 App Service 環境
作為內部 App Service 環境，其內部IP位址屬於內部負載平衡器（ILB）

此參考架構會在內部 App Service 環境中部署企業 Web 應用程式，也稱為 ILB App Service 環境。當您的案例要求您執行下列作業時，請使用 ILB App Service 環境：

裝載雲端安全性增強的內部網路應用程式，並透過站對站 VPN 或 Azure ExpressRoute 加以存取。
使用 Web 應用程式防火牆（WAF）為應用程式提供一層保護。
在雲端裝載未在公用 DNS 伺服器中列出的應用程式。
建立因特網隔離的後端應用程式，您的前端應用程式可以透過高度安全的方式與它整合。

App Service 環境必須一律部署在企業虛擬網路中自己的子網，以嚴格控制傳入和傳出流量。在此子網中，App Service 應用程式會部署在一或多個 App Service 方案中，這是執行應用程式所需的實體資源集合。視複雜度和資源需求而定，App Service 方案可以在多個應用程式之間共用。此參考實作會部署名為 Voting App 的 Web 應用程式，其會與私人 Web API 和函式互動。它也會部署名為 Test App 的虛擬 Web 應用程式 ，以示範多應用程式部署。每個 App Service 應用程式都會裝載在其自己的 App Service 方案中，並視需要個別調整每個應用程式。這些裝載應用程式所需的所有資源，例如記憶體和計算，以及調整需求，都完全由 App Service 環境基礎結構管理。

此實作中的簡單投票應用程式可讓用戶檢視現有的專案、建立新專案，以及投票處理現有的專案。 Web API 用於建立和擷取專案和投票。數據本身會儲存在 SQL Server 資料庫中。為了示範異步數據更新，Web 應用程式會在服務匯流排實例中排入新加入的投票佇列。函式會挑選佇列投票並更新 SQL 資料庫。 Azure Cosmos DB 用來儲存模擬廣告，Web 應用程式會擷取以在瀏覽器上顯示。應用程式會使用 Azure Cache for Redis 進行快取管理。系統會使用進階層 Azure Cache for Redis，其允許在自己的子網中，將組態設定為與 App Service 環境相同的虛擬網路。這會為快取提供增強的安全性和隔離。

Web 應用程式是因特網唯一可透過應用程式閘道存取的元件。 API 和函式無法從因特網用戶端存取。輸入流量會受到在應用程式閘道上設定的 WAF 保護。

元件

下列服務是鎖定此架構中 App Service 環境的關鍵：

Azure 虛擬網絡是企業所擁有的私人 Azure 雲端網路。它提供增強的網路型安全性和隔離。 App Service 環境是 App Service 部署至企業擁有虛擬網路的子網。它可讓企業使用網路安全組和私人端點，嚴格控制該網路空間及其存取的資源。
應用程式閘道是具有 TLS/SSL 卸除和 WAF 的應用程式層級 Web 流量負載平衡器。它會接聽公用IP位址，並將流量路由傳送至ILB App Service 環境中的應用程式端點。由於這是應用層級路由，因此可以將流量路由傳送至相同 ILB App Service 環境內的多個應用程式。如需詳細資訊，請參閱應用程式閘道的多網站裝載。
Azure 防火牆可用來限制來自 Web 應用程式的輸出流量。不會通過私人端點通道的連出流量，且 App Service 環境所需的路由表會導向至防火牆子網。為了簡單起見，此架構會設定服務子網上的所有私人端點。
Microsoft Entra ID 或 Microsoft Entra ID 提供 Azure 資源和服務的訪問許可權和許可權管理。 受控識別 會將身分識別指派給服務與應用程式，由 Microsoft Entra 識別元自動管理。這些身分識別可用來向任何支援 Microsoft Entra 驗證的服務進行驗證。這樣就不需要明確設定這些應用程式的認證。此架構會將受控識別指派給 Web 應用程式。
Azure 金鑰保存庫會儲存應用程式所需的任何秘密和認證。在應用程式中直接儲存秘密時，請使用此選項。
GitHub Actions 在此架構中提供持續整合和持續部署功能。由於 App Service 環境位於虛擬網路中，因此虛擬機會作為虛擬網路內的 jumpbox，以在 App Service 方案中部署應用程式。動作會建置虛擬網路外部的應用程式。如需增強的安全性和順暢的 RDP/SSH 連線能力，請考慮使用 Azure Bastion 作為 jumpbox。

多月台設定

顯示多月臺部署的圖表。

下載此架構的 Visio 檔案。

內部 App Service 環境可以裝載數個具有 HTTP 端點的 Web 應用程式和 API。這些應用程式會從公用因特網鎖定，因為 ILB IP 只能從虛擬網絡記憶體取。應用程式閘道可用來選擇性地將這些應用程式公開至因特網。 App Service 環境將預設 URL 指派給每個 App Service 應用程式作為 <default-appName>.<app-service-environment-domain>.appserviceenvironment.net。系統會建立私人 DNS 區域，將 App Service 環境功能變數名稱對應至 App Service 環境 ILB IP 位址。這可避免使用自定義 DNS 來存取虛擬網路內的應用程式。

應用程式閘道已設定為接聽程式接聽 HTTPS 連接埠，以取得閘道IP位址的要求。為了簡單起見，此實作不會使用公用 DNS 名稱註冊。您必須修改電腦上的 localhost 檔案，以將任意選擇的 URL 指向應用程式閘道 IP。為了簡單起見，接聽程式會使用自我簽署憑證來處理這些要求。應用程式閘道每個 App Service 應用程式的預設 URL 都有後端集區。路由規則已設定為將接聽程式連線到後端集區。系統會建立 HTTP 設定，以判斷閘道與 App Service 環境之間的連線是否會加密。這些設定也可用來覆寫從後端集區挑選的主機名來覆寫傳入的 HTTP 主機標頭。此實作會使用針對閘道信任的預設 App Service 環境應用程式URL所建立的預設憑證。要求會重新導向至對應應用程式的預設URL。連結至虛擬網路的私人 DNS 會將此要求轉送至 ILB IP。 App Service 環境接著將此轉送至要求的應用程式服務。 App Service 環境應用程式內的任何 HTTP 通訊都會通過私人 DNS。請注意，每個 App Service 環境應用程式的應用程式閘道上都必須設定接聽程式、後端集區、路由規則和 HTTP 設定。

檢閱 appgw.bicep 和 dns.bicep ，以瞭解如何進行這些設定以允許多個網站。名為 testapp 的 Web 應用程式是建立來示範此設定的空白應用程式。您可以從部署文稿 commands_std.azcli 存取這些 JSON 檔案。 commands_ha.azcli 也會存取這些專案，用於高可用性多月臺 App Service 環境部署。

案例詳細資料

Azure App 服務是 PaaS 服務，可用來在 Azure 上裝載各種應用程式：Web 應用程式、API 應用程式、函式和行動應用程式。 App Service 環境可讓企業將其App Service 應用程式部署在自己的 Azure 虛擬網絡子網中，為雲端工作負載提供隔離、高度可調整且專用的環境。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。如需詳細資訊，請參閱安全性支柱的概觀。

App Service 環境

內部 App Service 環境會部署在企業虛擬網路中，從公用因特網隱藏。它可讓企業鎖定其後端服務，例如網路層級的 Web API 和函式。任何具有 HTTP 端點的 App Service 環境應用程式，都可以透過 ILB 從虛擬網路記憶體取。應用程式閘道設定為透過 ILB 將要求轉送至 Web 應用程式。 Web 應用程式本身會透過 ILB 來存取 API。重要的後端元件，也就是 API 和函式，實際上無法從公用因特網存取。

系統會為每個應用程式服務建立預設憑證，以針對 App Service 環境指派的預設功能變數名稱。此憑證可以加強閘道與應用程式之間流量的安全性，而且在某些情況下可能需要此憑證。這些憑證無法透過用戶端瀏覽器顯示。它只能回應應用程式閘道上設定的憑證。

應用程式閘道

如使用應用程式閘道的 TLS 終止和端對端 TLS 概觀中所述，應用程式閘道可以使用傳輸層安全性（TLS）/安全套接字層（SSL）來加密和保護來自網頁瀏覽器的所有流量。加密可以透過下列方式進行設定：

加密在閘道終止。在此情況下，後端集區已針對 HTTP 進行設定。加密會在閘道停止，且閘道與 App Service 之間的流量未加密。由於加密需要大量 CPU，因此後端的未加密流量可改善效能，並允許更簡單的憑證管理。這可提供合理的安全性層級，因為後端會受到網路設定保護。
端對端加密。在某些情況下，例如特定的安全性或合規性需求，可能需要在閘道與應用程式之間加密流量。這可透過使用 HTTPS 連線，並在後端集區設定憑證來達成。

此參考實作會使用自我簽署憑證進行應用程式閘道。針對生產程式代碼，應該使用證書頒發機構單位所簽發的憑證。如需支持的憑證類型清單，請參閱 TLS 終止支援的憑證。請參閱使用 Azure 入口網站設定具有 TLS 終止的應用程式閘道，以瞭解如何建立閘道終止加密。 appgw.bicep 中的下列幾行程式代碼會以程式設計方式設定：

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

參考實作示範應用程式閘道與 App Service 環境上 Web 應用程式之間的流量端對端加密。會使用預設 SSL 憑證。此實作中的後端集區會設定為重新導向 HTTPS 流量，且主機名已由與 Web 應用程式相關聯的預設功能變數名稱覆寫。應用程式閘道信任預設 SSL 憑證，因為它們是由 Microsoft 所發行。如需如何進行這些設定的詳細資訊，請參閱使用應用程式閘道設定 App Service。來自 appgw.bicep 的下列程式代碼示範如何在參考實作中設定：

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Web 應用程式防火牆

應用程式閘道上的 Web 應用程式防火牆（WAF）可保護 Web 應用程式免於遭受惡意攻擊，例如 SQL 插入式攻擊。它也會與 Azure 監視器整合，以使用即時記錄來監視攻擊。必須在閘道上啟用 WAF，如使用 Azure 入口網站建立具有 Web 應用程式防火牆的應用程式閘道中所述。參考實作會在 appgw.bicep 檔案中使用下列代碼段，以程式設計方式啟用 WAF：

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

虛擬網路

網路安全組可以與虛擬網路中的一或多個子網相關聯。這些是允許或拒絕流量在各種 Azure 資源之間流動的安全性規則。此架構會將每個子網的個別網路安全組建立關聯。這允許根據子網中包含的服務，微調每個子網的這些規則。例如，如需 App Service 環境子網的網路安全組，請參閱"type": "Microsoft.Network/networkSecurityGroups"檔案 ase.bicep 中的組態，以及應用程式閘道子網網路安全組的 appgw.bicep 檔案。

私人端點可透過專用網啟用用戶端與 Azure 服務之間的增強安全性私人連線。他們會為 Azure 服務提供可私用存取的 IP 位址，讓 Azure Private Link 資源能夠增強安全性流量。平臺會驗證網路連線，只允許那些連線到指定的 Private Link 資源。私人端點支援網路原則，例如網路安全組、用戶定義路由和應用程式安全組。若要改善安全性，您應該為支持這些服務的任何 Azure 服務啟用私人端點。然後，您可以停用公用存取，有效地封鎖來自公用因特網的任何存取，藉此改善虛擬網路中服務的安全性。此架構會為支持的服務設定私人端點：Azure 服務匯流排、SQL Server、金鑰保存庫和 Azure Cosmos DB。您可以在 privatendpoints.bicep 中看到組態。

若要啟用私人端點，您也需要設定私人 DNS 區域。如需詳細資訊，請參閱 Azure 私人端點 DNS 設定。

防火牆

Azure 防火牆和私人端點彼此互補。私人端點只允許來自您虛擬網路的流量，協助保護資源。 Azure 防火牆可讓您限制來自應用程式的輸出流量。我們建議您允許所有輸出流量通過防火牆子網，包括私人端點流量。這可讓您更妥善地監視輸出流量。為了簡單起見，此參考架構會設定服務子網上的所有私人端點，而不是在防火牆子網上設定。

若要瞭解 Azure 防火牆如何與 App Service 環境整合，請參閱使用您的 App Service 環境設定 Azure 防火牆。不會周遊私人端點和虛擬網路路由表的任何流量，會受到防火牆的監視和閘道。

Microsoft Entra ID

Microsoft Entra ID 提供安全性功能來驗證應用程式，並授權存取資源。此參考架構使用Microsoft Entra ID 的兩個主要功能：受控識別和 Azure 角色型訪問控制。

在雲端應用程式上，必須保護向雲端服務驗證所需的認證。在理想情況下，認證不應該出現在開發人員工作站上，或簽入原始檔控制。 Azure 金鑰保存庫提供安全地儲存認證和秘密的方法，但應用程式仍必須進行驗證，才能金鑰保存庫擷取認證。 適用於 Azure 資源的 受控識別可為 Azure 服務提供 Microsoft Entra 識別碼中的自動受控識別。此身分識別可用來向任何支援Microsoft Entra 驗證的服務進行驗證，包括金鑰保存庫，而不需要應用程式中的任何認證。

Azure 角色型訪問控制（Azure RBAC）可管理對 Azure 資源的存取。這包括：

哪個實體具有存取權：使用者、受控識別、安全性主體。
其存取類型：擁有者、參與者、讀者、系統管理員。
存取範圍：資源、資源群組、訂用帳戶或管理群組。

您可以嚴格控制每個應用程式所需的角色和存取類型，以鎖定 App Service 環境應用程式的存取權。如此一來，就可以將多個應用程式部署在不同的開發小組的相同 App Service 環境上。例如，前端可能由一個小組處理，而後端則由另一個小組處理。 Azure RBAC 可用來限制每個小組正在處理的應用程式存取權。探索 Azure 自定義角色，以建立適合您組織的角色。

金鑰保存庫

某些服務支援受控識別，並使用 Azure RBAC 來設定應用程式的許可權。例如，請參閱 Azure Cosmos DB 中的內建服務匯流排角色和 Azure RBAC。 即使具有參與者存取權的人員可以部署這些服務，也需要使用者存取權系統管理員存取這些訂用帳戶的存取權才能授與這些許可權。若要讓更廣泛的開發人員小組能夠執行部署腳本，替代方法是使用服務所提供的原生訪問控制：

針對服務匯流排，它是共用存取簽章。
針對 Azure Cosmos DB，這是金鑰。

如果工作負載需要服務型存取，則這些預先共用的秘密應該儲存在金鑰保存庫中。保存庫本身應該透過 Web 應用程式的受控識別來存取。

儲存在金鑰保存庫中的秘密是由參考金鑰保存庫機碼/值組的應用程式存取。這會在 sites.bicep 檔案中完成，如投票應用程式的下列程式代碼所示：

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

延展性

設計可調整的應用程式

此參考架構中的應用程式會結構化，以便根據使用量調整個別元件。每個 Web 應用程式、API 和函式都會部署在其自己的 App Service 方案中。您可以監視每個應用程式是否有任何效能瓶頸，然後視需要相應增加。

自動調整應用程式閘道

您可以在 Azure 應用程式閘道 V2 上啟用自動調整。這可讓應用程式閘道根據流量負載模式相應增加或減少。此參考架構會在 autoscaleConfiguration appgw.bicep 檔案中設定，以在零到 10 個額外的實例之間進行調整。如需詳細資訊，請參閱調整應用程式閘道和 WAF v2。

部署

此參考架構中的部署腳本可用來部署 App Service 環境、其他服務和 App Service 環境內的應用程式。部署這些應用程式之後，企業可能會想要規劃持續整合和部署應用程式維護和升級。本節說明開發人員使用 #DBE48426B1AB14464A9260F87CAB8FAC7 應用程式 CI/CD 的一些常見方式。

應用程式只能從虛擬網路內部部署至內部 App Service 環境。下列三種方法廣泛使用來部署 App Service 環境應用程式：

手動在虛擬網絡內：使用部署所需的工具，在 App Service 環境虛擬網路內建立虛擬機。使用 NSG 組態開啟 VM 的 RDP 連線。將您的程式代碼成品複製到 VM、建置和部署至 App Service 環境子網。這是設定初始組建和測試開發環境的簡單方式。不過，不建議用於生產環境，因為它無法調整所需的部署輸送量。
從本機工作網站對站連線：這可讓您將 App Service 環境虛擬網路延伸至開發計算機，並從該處部署。這是設定初始開發環境的另一種方式，不建議用於生產環境。
透過 Azure Pipelines： 這會實作完整的 CI/CD 管線，以位於虛擬網路內的代理程序結尾。這適用於需要高部署輸送量的生產環境。組建管線會完全保留在虛擬網路外部。部署管線會將建置的物件複製到虛擬網路內的組建代理程式，然後部署到 App Service 環境子網。如需詳細資訊，請閱讀有關 Pipelines 與 App Service 環境虛擬網路之間自我裝載組建代理程式的討論。

建議針對生產環境使用 Azure Pipelines。使用 Azure Pipelines YAML 架構的協助編寫 CI/CD 腳本，有助於將建置和部署程式自動化。 azure-pipelines.yml在此參考實作中為 Web 應用程式實作這類 CI/CD 管線。 Web API 和函式也有類似的 CI/CD 腳本。請參閱使用 Azure Pipelines 來瞭解如何使用這些管線將每個應用程式的 CI/CD 自動化。

某些企業可能不想在虛擬網路內維護永久建置代理程式。在此情況下，您可以選擇在 DevOps 管線內建立組建代理程式，並在部署完成後將其卸除。這會在 DevOps 中新增另一個步驟，但會降低維護 VM 的複雜度。您甚至可以考慮使用容器作為組建代理程式，而不是 VM。建置代理程式也可以完全避免，方法是從 位於虛擬網路外部的壓縮檔部署，通常是在記憶體帳戶中。記憶體帳戶必須可從 App Service 環境存取。管線應該能夠存取記憶體。在發行管線結束時，壓縮的檔案可以放入 Blob 記憶體中。然後，App Service 環境可以挑選並部署。請注意此方法的下列限制：

DevOps 與實際部署程式之間有中斷連線，導致監視和追蹤任何部署問題時發生困難。
在具有安全流量的鎖定環境中，您可能需要變更規則，以存取記憶體上的壓縮檔案。
您必須在 App Service 環境上安裝特定的擴充功能和工具，才能從 zip 部署。

若要深入瞭解應用程式可以部署到 App Service 方案的方式，請閱讀以部署策略為重點的 App Service 文章。

成本最佳化

使用 Azure 定價計算機來預估成本。 Microsoft Azure Well-Architected Framework 中的「成本」一節會說明其他考量。 Azure 保留可協助您藉由承諾多項 Azure 資源一年或三年期的方案來節省成本。如需詳細資訊，請參閱購買保留一文。

以下是此架構中所使用的一些重要服務需要考慮的一些要點。

App Service 環境 v3

App Service 提供各種定價選項。使用隔離 v2 服務方案部署 App Service 環境。在此方案中，CPU 大小有多個選項，從 I1v2 到 I6v2。此參考實作會針對每個實例使用三個 I1v2。

應用程式閘道

應用程式閘道定價提供各種定價選項。此實作會使用應用程式閘道 Standard v2 和 WAF v2 SKU，其支援自動調整和區域備援。如需此 SKU 所用定價模式的詳細資訊，請參閱調整應用程式閘道 v2 和 WAF v2。

Azure Cache for Redis

Azure Cache for Redis 定價提供此服務的各種定價選項。此架構會 使用進階 SKU 進行虛擬網路支援。

以下是用來鎖定 App Service 環境之其他服務的定價頁面：

部署此案例

若要部署此架構的參考實作，請參閱 GitHub 自述檔，並遵循標準部署的腳本。

參與者

本文由 Microsoft 維護。原始投稿人如下。

主要作者：

達納什里·克斯希爾薩加 |資深內容 PM

其他投稿人：

Deep Bhattacharya |雲端解決方案架構師
Suhas Rao |雲端解決方案架構師

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

若要瞭解如何擴充此架構以支援高可用性，請參閱使用App Services環境部署高可用性應用程式。

共用方式為

使用 Azure App 服務環境進行企業部署

架構

工作流程

元件

多月台設定

案例詳細資料

考量

安全性

App Service 環境

應用程式閘道

Web 應用程式防火牆

虛擬網路

防火牆

Microsoft Entra ID

金鑰保存庫

延展性

設計可調整的應用程式

自動調整應用程式閘道

部署

成本最佳化

App Service 環境 v3

應用程式閘道

Azure Cache for Redis

部署此案例

參與者

下一步

意見反應

其他資源

共用方式為

使用 Azure App 服務 環境進行企業部署

架構

工作流程

元件

多月台設定

案例詳細資料

考量

安全性

App Service 環境

應用程式閘道

Web 應用程式防火牆

虛擬網路

防火牆

Microsoft Entra ID

金鑰保存庫

延展性

設計可調整的應用程式

自動調整 應用程式閘道

部署

成本最佳化

App Service 環境 v3

應用程式閘道

Azure Cache for Redis

部署此案例

參與者

下一步

相關資源

意見反應

其他資源

使用 Azure App 服務環境進行企業部署

自動調整應用程式閘道