本文提供使用 App Service 環境部署安全應用程式的概觀。 若要限制來自網際網路的應用程式存取，請使用 Azure 應用程式閘道服務和 Azure Web 應用程式防火牆。 本文也提供使用 Azure DevOps 進行 App Service 環境的持續整合和持續部署 (CI/CD) 指引。
此案例通常會部署在銀行業和保險業，除了應用程式層級安全性之外，客戶也會意識到平台層級的安全性。 為了示範這些概念，我們將使用可讓使用者提交費用報表的應用程式。
潛在使用案例
請針對以下使用案例考慮此案例：
- 建置需要額外安全性的 Azure Web Apps。
- 提供專用租用，而不是共用租用戶 App Service 方案。
- 使用 Azure DevOps 搭配 內部負載平衡 (ILB) 應用程式服務環境。
架構
下載此架構的 Visio 檔案。
資料流程
- HTTP/HTTPS 要求會先到達應用程式閘道。
- 或者 (未顯示在圖表中)，您可以為 Web Apps 啟用 Microsoft Entra 驗證。 流量先到達應用程式閘道之後，系統會提示使用者提供認證以驗證該應用程式。
- 使用者要求會流經該環境的內部負載平衡器 (ILB)，進而將流量路由至 Expenses Web Apps。
- 然後，使用者會繼續建立費用報表。
- 在建立費用報表時，會叫用已部署的 API Apps 來擷取使用者的管理員名稱和電子郵件。
- 建立的費用報表會儲存在 Azure SQL Database。
- 為了便於持續部署，程式碼會簽入 Azure DevOps 執行個體。
- 建置 VM 已安裝 Azure DevOps 代理程式，使其能夠提取 Web Apps 的程式碼並部署到 App Service 環境 (因為 Build VM 部署在相同虛擬網路內的子網路中)。
元件
- App Service 環境提供了一個完全隔離的專用環境，用於安全地大規模執行應用程式。 此外，由於 App Service 環境和其上執行的工作負載位於虛擬網路後方，因此也會提供額外的安全性和隔離層。 高規模和隔離的需求促使選取 ILB App Service 環境。
- 此工作負載會使用隔離的 App Service 定價層，因此應用程式會使用較快的處理器、固態硬碟 (SSD) 儲存體，在 Azure 資料中心的私人專用環境中執行，而且相較於標準，記憶體對核心比率增加了一倍。
- Azure App Service Web Apps 和 API Apps 託管 Web 應用程式和 RESTful API。 這些應用程式和 API 託管於隔離式服務方案上，該方案也提供自動縮放、自訂網域等功能，但屬於專用層。
- Azure 應用程式閘道是在層級 7 運作的網路流量負載平衡器，用於管理 Web 應用程式的流量。 它提供 SSL 卸載功能，可移除託管 Web 應用程式的 Web 伺服器再次解密流量的額外負荷。
- Web 應用程式防火牆是應用程式閘道的一種功能。 在應用程式閘道中啟用 Web 應用程式防火牆可進一步增強安全性。 Web 應用程式防火牆會使用 OWASP (Open Worldwide Application Security Project) 規則來保護 Web 應用程式免受跨網站指令碼、工作階段劫持和 SQL 插入式等攻擊。
- 已選取 Azure SQL 資料庫，因為此應用程式中大部分的資料都是關聯式資料，有些資料是文件和 Blob。
- Azure 網路在 Azure 中提供各種網路功能，而且網路可與 Azure 中的其他虛擬網路對等互連。 也可以透過 ExpressRoute 或站對站與內部部署資料中心建立連接。 在此情況下，虛擬網路上會啟用服務端點，以確保資料只會在 Azure 虛擬網路與 SQL 資料庫執行個體之間流動。
- Azure DevOps 可用來協助團隊在短期衝刺期間共同作業、使用支援敏捷式開發的功能，以及建立建置和發行管線。
- 已建立 Azure 建置 VM，讓已安裝的代理程式可以提取個別的建置，並將 Web 應用程式部署至環境。
替代項目
App Service 環境可以在 Windows 上執行一般 Web 應用程式，或在此範例中，部署在每個以 Linux 容器執行的環境中的 Web 應用程式。 已選取 App Service 環境來託管這些單一執行個體容器化應用程式。 有可用的替代方案 — 在設計解決方案時，請檢閱下列考量因素。
- Azure Service Fabric：如果您的環境大多是以 Windows 為基礎，而且工作負載主要是以 .NET Framework 為基礎，但您不考慮重新架構至 .NET Core，則請使用 Service Fabric 來支援及部署 Windows Server 容器。 此外，Service Fabric 支援 C# 或 Java 程式設計 API，以及開發原生微服務，可以在 Windows 或 Linux 上佈建叢集。
- Azure Kubernetes Service (AKS) 是開放原始碼專案，也是更適合託管通常使用微服務架構之複雜多容器應用程式的協調流程平台。 AKS 是受控 Azure 服務，能夠簡化佈建和設定 Kubernetes 叢集的複雜性。 然而，支援和維護 Kubernetes 平台需要大量知識，因此託管少量單一執行個體容器化 Web 應用程式可能不是最佳選擇。
資料層的其他選項包括：
- Azure Cosmos DB：如果您的大部分資料都是非關聯式格式，Azure Cosmos DB 是很好的替代方案。 此服務提供平台來執行其他資料模型，例如 MongoDB、Cassandra、Graph 資料或簡單的資料表儲存體。
考量
處理 ILB App Service 環境上的憑證時，需要注意一些事項。 您需要產生一個鏈結至受信任根的憑證，而不需要最終儲存憑證的伺服器產生的憑證簽署要求。 例如，使用網際網路資訊服務 (IIS)，第一個步驟是從 IIS 伺服器產生憑證簽署要求 (CSR)，然後將它傳送至 SSL 憑證發行授權單位。
您無法從 App Service 環境的內部負載平衡器 (ILB) 發出 CSR。 處理此限制的方式是使用萬用字元程序。
萬用字元程序可讓您使用 DNS 名稱所有權證明而不是 CSR。 如果您擁有 DNS 命名空間，可以放入特殊的 DNS TXT 記錄中，(萬用字元程序會檢查記錄是否存在，如果找到，就會知道您擁有 DNS 伺服器，因為您有正確的記錄。 根據該資訊，它會發出已註冊至受信任根的憑證，然後您可以將其上傳至 ILB。 您不需要對 Web Apps 上的個別憑證儲存執行任何動作，因為您在 ILB 上有受信任根的 SSL 憑證。
如果您想要在 ILB App Service 環境中執行的服務之間進行安全呼叫，請讓自我簽署或內部核發的 SSL 憑證能夠運作。 另一個要考慮的解決方案是如何讓 ILB App Service 環境使用內部核發 SSL 憑證，以及如何將內部 CA 載入受信任的根存放區。
佈建 App Service 環境時，請在為該環境選擇網域名稱時考慮以下限制。 網域名稱不能是：
netazurewebsites.netp.azurewebsites.netnameofthease.p.azurewebsites.net
此外，用於應用程式的自訂網域名稱和 ILB App Service 環境所使用的網域名稱無法重疊。 對於具有網域名稱 contoso.com 的 ILB App Service 環境，您無法對應用程式使用自訂網域名稱，例如：
www.contoso.comabcd.def.contoso.comabcd.contoso.com
針對不會與這些自訂網域名稱衝突的 ILB App Service 環境選擇網域。 在此範例中，您可以使用 contoso-internal.com 等內容作為您的環境網域，因為這不會與以 .contoso.com 結尾的自訂網域發生衝突。
另一個要考慮的點是 DNS。 為了允許 App Service 環境中的應用程式相互通訊 (例如 Web 應用程式與 API 通訊)，您需要為保存該環境的虛擬網路設定 DNS。 您可以攜帶自己的 DNS，或使用 Azure DNS 私人區域。
可用性
- 請考慮在建置雲端應用程式時套用可用性的一般設計模式。
- 檢閱適當的 App Service Web 應用程式參考架構中的可用性考慮。
- 如需可用性的其他考慮，請參閱 Azure 架構中心的可用性檢查清單 。
延展性
- 了解 App Service 環境中縮放的運作方式。
- 檢閱雲端應用程式自動縮放的最佳做法。
- 建置雲端應用程式時，請注意可擴縮性的典型設計模式。
- 檢閱適當的 App Service Web 應用程式參考架構中的可擴縮性考慮。
- 如需其他可擴縮性文章，請參閱 Azure 架構中心提供的效能效率檢查清單。
安全性
- 檢閱安全性支柱概觀。
- 檢閱適當的 App Service Web 應用程式參考架構中的安全性考慮。
- 請考慮遵循安全的開發生命週期程序，協助開發人員建置更安全的軟體，並解決安全性合規性需求，同時降低開發成本。
- 檢閱 Azure PCI DSS 合規性的藍圖架構。
- Azure DDoS 保護 (結合應用程式設計最佳做法) 可提供增強的 DDoS 風險降低功能，以針對 DDoS 攻擊提供更多的防禦。 您應在任何周邊虛擬網路上啟用 Azure DDoS 保護。
復原
- 請考慮使用 App Service 環境的異地複寫分散規模調整，以提高復原和可擴縮性。
- 檢閱復原的典型設計模式，並考慮在適當情況下實作這些模式。
- 您可以在 Azure 架構中心找到數個 App Service 的建議做法。
- 請考慮針對映像和佇列使用資料層的作用中異地複寫和異地備援儲存體。
- 如需深入討論復原，請參閱 Azure 架構中心的相關文章。
部署此案例
若要部署此案例，請遵循此示範如何手動部署每個元件的逐步教學課程。 遵循本教學課程時，請選取 App Service 環境 v3 而非 v2。 本教學課程也提供執行簡單 Contoso 費用報告應用程式的 .NET 範例應用程式。
定價
探索執行此案例的成本。 所有服務都會在成本計算機中預先設定。 若要查看定價如何針對您的特定使用案例變更，請變更適當的變數以符合您預期的流量。
我們已根據您預期取得的流量，提供三個範例成本設定檔：
- 小型：此定價範例代表每月為數千位使用者提供服務的最低生產層級執行個體所需的元件。 該應用程式使用標準 Web 應用程式的單一執行個體，足以啟用自動縮放。 其他每個元件都會縮放至基本層，以將成本降到最低，但仍確保有服務等級協定 (SLA) 支援和足夠的容量來處理生產層級工作負載。
- 中型：此定價範例代表中等大小部署所需的元件。 在此，我們估計一個月內約有100,000 位使用者。 預期的流量會在具有中等標準層的單一 App Service 執行個體中處理。 此外，計算器中還新增了中等層級的認知和搜尋服務。
- 大型：此定價範例代表了一個用於大規模 (每月數百萬用戶) 行動 TB 資料的應用程式。 在此使用量層級上，需要在流量管理員前端的多個區域中部署高效能、進階層 Web 應用程式。 資料是由下列元件所組成：儲存體、資料庫和 CDN，全都針數 TB 的資料進行設定。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Faisal Mustafa | 資深客戶工程師