本文提供使用 Azure App 服務 環境部署安全應用程式的概觀。 若要限制來自因特網的應用程式存取，會使用 Azure 應用程式閘道 服務和 Azure Web 應用程式防火牆。 本文也會針對使用 Azure DevOps 的 App Service 環境 提供持續整合和持續部署 （CI/CD） 的相關指引。
此案例通常會部署在銀行和保險等產業中，除了應用層級安全性之外，客戶也會意識到平臺層級的安全性。 為了示範這些概念，我們將使用可讓使用者提交費用報表的應用程式。
潛在的使用案例
針對下列使用案例，請考慮此案例：
- 建置需要額外安全性的 Azure Web 應用程式。
- 提供專用租用，而不是共用租使用者 App Service 方案。
- 使用 Azure DevOps 搭配 內部負載平衡（ILB） 應用程式服務環境。
架構
資料流程
- HTTP/HTTPS 要求會先叫用 應用程式閘道。
- 您可以選擇性地（未顯示在圖表中），您可以為 Web 應用程式啟用 Microsoft Entra 驗證。 流量第一次叫用 應用程式閘道 之後，系統會提示使用者提供認證以向應用程式進行驗證。
- 使用者要求會流經環境的內部負載平衡器 （ILB），進而將流量路由傳送至 Expenses Web 應用程式。
- 然後，用戶會繼續建立費用報表。
- 在建立費用報表時，會叫用已部署的 API 應用程式來擷取使用者的經理名稱和電子郵件。
- 建立的費用報告會儲存在 Azure SQL 資料庫 中。
- 為了加速持續部署，程式代碼會簽入 Azure DevOps 實例。
- 建置 VM 已安裝 Azure DevOps 代理程式，可讓建置 VM 提取 Web 應用程式部署至 App Service 環境 的位（因為建置 VM 部署在相同虛擬網路內的子網中）。
元件
- App Service 環境 提供完全隔離的專用環境，可安全地大規模執行應用程式。 此外，由於 App Service 環境和其上執行的工作負載位於虛擬網路後方，因此也會提供額外的安全性和隔離層。 高規模和隔離的需求促使選取 ILB App Service 環境。
- 此工作負載會使用 隔離的 App Service 定價層，因此應用程式會使用較快的處理器、SSD 記憶體，在 Azure 資料中心的私人專用環境中執行，相較於標準，記憶體與核心比率會加倍。
- Azure App 服務Web 應用程式和API 應用程式裝載 Web 應用程式和 RESTful API。 這些應用程式和 API 裝載於隔離服務方案上，其也提供自動調整、自定義網域等等，但在專用層中。
- Azure 應用程式閘道 是在第 7 層運作的 Web 流量負載平衡器，可管理 Web 應用程式的流量。 它提供 SSL 卸除功能，可移除裝載 Web 應用程式的 Web 伺服器的額外額外負荷，以再次解密流量。
- Web 應用程式防火牆 （WAF） 是 應用程式閘道 的功能。 在 應用程式閘道 中啟用 WAF 會進一步增強安全性。 WAF 會使用 OWASP 規則來保護 Web 應用程式免受跨網站腳本、會話劫持和 SQL 插入等攻擊。
- 已選取 Azure SQL 資料庫，因為此應用程式中的大部分數據都是關係型數據，其中有些數據是檔和 Blob。
- Azure 網路 在 Azure 中提供各種網路功能，而且網路可與 Azure 中的其他虛擬網路對等互連。 您也可以透過 ExpressRoute 或站對站透過內部部署資料中心建立 連線 ion。 在此情況下，虛擬網路上會啟用服務端點，以確保數據只會在 Azure 虛擬網路與 SQL 資料庫 實例之間流動。
- Azure DevOps 可用來協助小組在短期衝刺期間共同作業、使用支援敏捷式開發的功能，以及建立建置和發行管線。
- 已建立 Azure 組建 VM ，讓已安裝的代理程式可以提取個別的組建，並將 Web 應用程式部署至環境。
替代項目
App Service 環境 可以在 Windows 上執行一般 Web 應用程式，或如此範例所示，部署在環境內的 Web 應用程式，且每個應用程式都是以 Linux 容器的形式執行。 已選取 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 環境 時，請在為環境選擇功能變數名稱時考慮下列限制。 功能變數名稱不能是：
- net
- azurewebsites.net
- p.azurewebsites.net
- nameofthease.p.azurewebsites.net
此外，用於應用程式的自定義功能變數名稱和 ILB App Service 環境 所使用的功能變數名稱無法重疊。 對於具有功能變數名稱 contoso.com 的 ILB App Service 環境，您無法針對您的應用程式使用自定義功能變數名稱，例如：
- www.contoso.com
- abcd.def.contoso.com
- abcd.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 |資深客戶工程師