編輯

共用方式為


基準高可用性區域備援 Web 應用程式

Azure App Service
Azure 應用程式閘道
Azure 儲存體
Azure SQL Database
Azure Private Link
Azure 虛擬網路
Azure 監視器

此基準架構是以基本 Web 應用程式架構為基礎,並加以擴充,以提供在 Azure 上設計安全、區域備援和高可用性 Web 應用程式的詳細指引。 架構會透過具有 Web 應用程式防火牆 的 Azure 應用程式閘道 公開公用端點。 它會透過 Private Link 將要求路由傳送至 Azure App 服務。 App Service 應用程式會使用虛擬網路整合和 Private Link,安全地與 Azure PaaS 服務通訊,例如 Azure 金鑰保存庫 和 Azure SQL 資料庫。

重要

GitHub 標誌 此指引是由 示範 Azure 上基準 App Service 實作的範例實 作所支援。 此實作可作為進一步開發生產環境之進一步解決方案的基礎。

架構

此圖顯示具有區域備援和高可用性的基準 App Service 架構。

圖 1:基準 Azure App 服務 架構

下載此架構的 Visio 檔案

元件

此架構的許多元件與基本 Web 應用程式架構相同。 下列清單只會醒目提示基本架構的變更。

  • 應用程式閘道 是第 7 層 (HTTP/S) 負載平衡器和 Web 流量管理員。 它會使用 URL 路徑型路由,將連入流量分散到可用性區域,並卸除加密以改善應用程式效能。
  • Web 應用程式防火牆 (WAF) 是雲端原生服務,可保護 Web 應用程式免於常見的惡意探索,例如 SQL 插入式和跨網站腳本。 WAF 可讓您檢視 Web 應用程式的來回流量,讓您能夠監視及保護應用程式。
  • Azure 金鑰保存庫 是一項服務,可安全地儲存和管理秘密、加密密鑰和憑證。 它會集中管理敏感性資訊。
  • Azure 虛擬網路 是一項服務,可讓您在 Azure 中建立隔離且安全的專用虛擬網路。 針對 App Service 上的 Web 應用程式,您需要虛擬網路子網,才能使用私人端點進行資源之間的網路安全通訊。
  • Private Link 可讓用戶端直接從私人虛擬網路存取 Azure 平臺即服務 (PaaS) 服務,而不需使用公用 IP 位址。
  • Azure DNS 是 DNS 網域的裝載服務,可使用 Microsoft Azure 基礎結構來提供名稱解析。 私用 DNS 區域提供將服務的完整功能變數名稱 (FQDN) 對應至私人端點IP位址的方式。

網路

網路安全性是 App Services 基準架構的核心(請參閱圖 2)。 從高階而言,網路架構可確保下列各項:

  1. 用戶端流量的單一安全進入點
  2. 已篩選網路流量
  3. 傳輸中的數據會以 TLS 加密端對端
  4. 透過使用 Private Link 將流量保留在 Azure 中,以最小化數據外洩
  5. 網路資源會透過網路分割以邏輯方式分組並彼此隔離

網路流程

顯示基準 App Service 網路架構的圖表。

圖 2:基準 Azure App 服務 應用程式的網路架構

以下是因特網流量到 App Service 實例的輸入流程,以及從 App Service 到 Azure 服務的流量。

輸入流程

  1. 使用者向 應用程式閘道 公用IP發出要求。
  2. 評估 WAF 規則。 WAF 規則可藉由防範各種攻擊,例如跨網站腳本 (XSS) 和 SQL 插入,對系統的可靠性產生正面影響。 如果違反 WAF 規則並停止處理,Azure 應用程式閘道 會傳回要求者的錯誤。 如果未違反 WAF 規則,應用程式閘道 將要求路由傳送至後端集區,在此案例中為 App Service 預設網域。
  3. 私人 DNS 區域 privatelink.azurewebsites.net 會連結至虛擬網路。 DNS 區域有 A 記錄,會將 App Service 預設網域對應至 App Service 私人端點的私人 IP 位址。 此連結的私人 DNS 區域可讓 Azure DNS 將預設網域解析為私人端點 IP 位址。
  4. 要求會透過私人端點路由傳送至 App Service 實例。

App Service 至 Azure PaaS 服務流程

  1. App Service 對所需 Azure 服務的 DNS 名稱提出要求。 要求可能是 Azure 金鑰保存庫 取得秘密、Azure 儲存體 取得發佈 zip 檔案、Azure SQL 資料庫,或任何其他支援 Private Link 的 Azure 服務。 App Service 虛擬網路整合 功能會透過虛擬網路路由傳送要求。
  2. 如同輸入流程中的步驟 3,連結的私人 DNS 區域具有 A 記錄,會將 Azure 服務的網域對應至私人端點的私人 IP 位址。 同樣地,此連結的私人 DNS 區域可讓 Azure DNS 將網域解析為服務的私人端點 IP 位址。
  3. 要求會透過私人端點路由傳送至服務。

輸入至 App Services

應用程式閘道 是符合此基準架構需求的區域資源。 應用程式閘道 是可調整的區域第 7 層負載平衡器,可支援 Web 應用程式防火牆和 TLS 卸除等功能。 實作 應用程式閘道 輸入至 Azure App 服務 時,請考慮下列幾點。

  • 部署 應用程式閘道,並使用Microsoft管理的規則集來設定WAF原則。 使用預防模式來減輕 Web 攻擊,這可能會導致原始服務(架構中的 App Service) 變得無法使用。
  • 實作 端對端 TLS 加密
  • 使用 私人端點來實作 App Service 的輸入私人存取。
  • 請考慮為 應用程式閘道 實作自動調整,以便輕鬆地調整為動態流量。
  • 請考慮使用最小規模實例計數不超過 3,且一律使用您區域支援的所有可用性區域。 雖然 應用程式閘道 是以高可用性的方式部署,即使針對單一縮放實例,在失敗時建立新的實例最多可能需要七分鐘的時間。 跨 可用性區域 部署多個實例,有助於確保實例在建立新實例時正在執行。
  • 停用 App Service 上的公用網路存取,以確保網路隔離。 在 Bicep 中,這是藉由在 properties/siteConfig 下設定 publicNetworkAccess: 'Disabled' 來完成。

從 App Services 流向 Azure 服務

此架構會使用 App Service的虛擬網路整合 ,特別是透過虛擬網路將流量路由傳送至私人端點。 基準架構不會啟用 所有流量路由 ,以強制所有輸出流量通過虛擬網路,而只是內部流量,例如系結至私人端點的流量。

不需要從公用因特網存取的 Azure 服務應該已啟用私人端點,並停用公用端點。 私人端點會在整個架構中使用,藉由允許App Service直接從私人虛擬網路連線到 Private Link 服務,而不需使用公用IP位址,來改善安全性。

在此架構中,Azure SQL 資料庫、Azure 儲存體 和 金鑰保存庫 都停用公用端點。 Azure 服務防火牆僅用於允許來自其他授權 Azure 服務的流量。 您應該使用私人端點設定其他 Azure 服務,例如 Azure Cosmos DB 和 Azure Redis 快取。 在此架構中,Azure 監視器不會使用私人端點,但可以。

基準架構會為每個服務實作私人 DNS 區域。 私人 DNS 區域包含 A 記錄,可對應服務的完整功能變數名稱與私人端點私人 IP 位址。 區域會連結至虛擬網路。 私用 DNS 區域群組可確保會自動建立和更新私人連結 DNS 記錄。

實作虛擬網路整合和私人端點時,請考慮下列幾點。

虛擬網路分割和安全性

此架構中的網路有個別的子網,適用於 應用程式閘道、App Service 整合元件和私人端點。 每個子網都有一個網路安全組,其會將這些子網的輸入和輸出流量限製為所需的流量。 下表顯示基準新增至每個子網之 NSG 規則的簡化檢視。 數據表會提供規則名稱和函式。

子網路 傳入 輸出
snet-AppGateway AppGw.In.Allow.ControlPlane:允許輸入控制平面存取

AppGw.In.Allow443.Internet:允許輸入因特網 HTTPS 存取
AppGw.Out.Allow.AppServices:允許對 AppServicesSubnet 進行輸出存取

AppGw.Out.Allow.PrivateEndpoints:允許對 PrivateEndpointsSubnet 進行輸出存取

AppPlan.Out.Allow.AzureMonitor:允許對 Azure 監視器進行輸出存取
snet-PrivateEndpoints 默認規則:允許從虛擬網路輸入 默認規則:允許輸出至虛擬網路
snet-AppService 默認規則:允許從 vnet 輸入 AppPlan.Out.Allow.PrivateEndpoints:允許對 PrivateEndpointsSubnet 進行輸出存取

AppPlan.Out.Allow.AzureMonitor:允許對 Azure 監視器進行輸出存取

實作虛擬網路分割和安全性時,請考慮下列幾點。

  • 使用屬於具有公用IP的應用程式閘道一部分的子網,為虛擬網路啟用 DDoS 保護
  • 盡可能將 NSG 新增至每個子網。 您應該使用最嚴格的規則來啟用完整的解決方案功能。
  • 使用 應用程式安全組。 應用程式安全組可讓您將 NSG 分組,讓複雜環境更容易建立規則。

虛擬子網架構的範例可能是:

類型 名稱 位址範圍
虛擬網路 地址前綴 10.0.0.0/16
子網路 GatewaySubnet 10.0.1.0/24
子網路 AppServicesSubnet 10.0.0.0/24
子網路 PrivateEndpointsSubnet 10.0.2.0/27
子網路 AgentsSubject 10.0.2.32/27

參考 Azure-Samples\app-service-baseline-implementation

考量

這些考量能實作 Azure Well-Architected Framework 的要素,其為一組指導原則,可以用來改善工作負載的品質。 如需詳細資訊,請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊,請參閱可靠性要素的概觀 (部分機器翻譯)。

基準 App Services 架構著重於主要區域服務的區域性備援。 可用性區域是區域內實際不同的位置。 當兩個或多個實例部署在支援區域中時,它們會為支援服務提供區域性備援。 當某個區域發生停機時,其他區域可能仍然不受影響。

此架構也可確保足夠的 Azure 服務實例來滿足需求。 下列各節提供架構中重要服務的可靠性指引。 如此一來,可用性區域可藉由提供高可用性和容錯,協助您達到可靠性。

應用程式閘道

在區域備援設定中部署 Azure 應用程式閘道 v2。 請考慮使用不小於 3 的最小調整實例計數,以避免發生失敗時,應用程式閘道 實例的六到七分鐘的啟動時間。

應用程式服務

  • 部署至少三個具有可用性區域支援的App Services 實例。
  • 在您的應用程式中實作健康情況檢查端點,並設定應用程式 服務健康情況 檢查功能,以從狀況不良的實例重新路由傳送要求。 如需 App Service 健康狀態檢查的詳細資訊,請參閱 使用健康情況檢查監視 App Service 實例。 如需在 ASP.NET 應用程式中實作健康情況檢查端點的詳細資訊,請參閱 ASP.NET Core 中的健康情況檢查。
  • 過度布建容量以處理區域失敗。

SQL 資料庫

  • 部署已啟用區域備援的 Azure SQL DB 一般用途、進階或 業務關鍵。 一般用途、進階和 業務關鍵 層支援 Azure SQL DB 中的區域備援。
  • 設定 SQL DB 備份 以使用區域備援記憶體 (ZRS) 或異地區域備援記憶體 (GZRS)。

Blob 儲存體

  • Azure 區域備援記憶體 (ZRS) 會將您的資料同步復寫到區域中的三個可用性區域。 建立標準 ZRS 或標準 GZRS 記憶體帳戶,以確保數據會跨可用性區域複寫。
  • 為部署、Web 資產和其他數據建立個別的記憶體帳戶,以便您可以個別管理和設定帳戶。

效能效益

效能效率可讓您的工作負載進行調整,以有效率的方式符合使用者對其放置的需求。 如需詳細資訊,請參閱效能效率要件概觀

下列各節將討論此架構中重要元件的延展性。

應用程式閘道

  • 實作自動調整,讓 應用程式閘道相應縮小或相應放大以符合需求。
  • 將實例計數上限設定為高於您預期需求的數位。 您只需要支付您使用的容量單位的費用。
  • 設定可處理流量小尖峰的最小實例計數。 您可以使用 平均計算單位使用量 來計算最小實例計數。
  • 請遵循調整 應用程式閘道 子網大小的指導。

應用程式服務

SQL Server

調整資料庫資源是此架構範圍以外的複雜主題。 調整資料庫時,請考慮下列資源:

其他延展性指引

  • 檢閱 訂用帳戶限制和配額 ,以確保服務可依需求進行調整。
  • 請考慮快取下列類型的數據,以提高效能和延展性:
    • 半靜態事務數據。
    • 工作階段狀態。
    • HTML 輸出。 這對於轉譯複雜 HTML 輸出的應用程式很有用。

安全性

基準 App Service 架構著重於 Web 應用程式的基本安全性建議。 瞭解加密和身分識別在每一層的運作方式,對於保護您的工作負載至關重要。

應用程式服務

  • 停用 FTP 和 SCM 月臺部署的本機驗證方法
  • 關閉遠端偵錯。
  • 使用最新的 TLS 版本。
  • 啟用適用於 App Service 的 Microsoft Defender。
  • 使用最新版的支援平台、程式設計語言、通訊協定和架構。
  • 如果您需要更高的隔離或安全的網路存取,請考慮 App Service 環境

加密

生產 Web 應用程式必須使用 HTTPS 加密傳輸中的數據。 HTTPS 通訊協定依賴傳輸層安全性 (TLS),並使用公用和私鑰進行加密。 您必須將憑證 (X.509) 儲存在 金鑰保存庫 中,並允許 應用程式閘道 擷取私鑰。 針對待用數據,某些服務會自動加密數據,而其他服務則可讓您自定義。

傳輸中資料

在基準架構中,傳輸中的數據會從使用者加密到 App Service 中的 Web 應用程式。 下列工作流程說明加密在高階的運作方式。

顯示基準 App Service 加密流程的圖表。

  1. 用戶會將 HTTPS 要求傳送至 Web 應用程式。
  2. HTTPS 要求會到達應用程式閘道。
  3. 應用程式閘道會使用 金鑰保存庫 中的憑證 (X.509) 來建立與使用者網頁瀏覽器的安全 TLS 連線。 應用程式閘道會解密 HTTPS 要求,讓 Web 應用程式防火牆可以檢查它。
  4. 應用程式閘道會建立與 App Service 的 TLS 連線,以重新加密使用者要求。 App Service 提供 HTTPS 的原生支援,因此您不需要將憑證新增至 App Service。 應用程式閘道會將加密的流量傳送至 App Service。 App Service 會解密流量,而 Web 應用程式會處理要求。

設定傳輸中的數據加密時,請考慮下列建議。

  • 建立或上傳憑證至 金鑰保存庫。 HTTPS 加密需要憑證 (X.509)。 您需要來自自定義網域受信任證書頒發機構單位的憑證。
  • 將私鑰儲存至 金鑰保存庫 中的憑證。
  • 請遵循將許可權授與應用程式以使用 Azure RBACAzure 資源的受控識別存取 Azure 金鑰保存庫中的指引,為憑證私鑰提供 應用程式閘道 存取權。 請勿使用 金鑰保存庫 存取原則來提供存取權。 存取原則只可讓您授與廣泛許可權,而不只是授與特定值的許可權。
  • 啟用端對端加密。 App Service 是應用程式閘道的後端集區。 當您設定後端集區的後端設定時,請使用透過後埠 443 的 HTTPS 通訊協定。
待用資料
  • 使用透明數據加密,加密 Azure SQL 資料庫 中的敏感數據。 透明數據會加密整個資料庫、備份和事務歷史記錄檔,而且不需要變更 Web 應用程式。
  • 將資料庫加密延遲降至最低。 若要將加密延遲降到最低,請將您需要保護的數據放在自己的資料庫中,並只啟用該資料庫的加密。
  • 了解內建加密支援。 Azure 儲存體 使用伺服器端加密 (256 位 AES) 自動加密待用數據。 Azure 監視器會使用Microsoft管理的金鑰 (MMK) 自動加密待用數據。

身分識別與存取管理

App Service 基準會設定使用者身分識別(使用者)和工作負載身分識別的驗證和授權(Azure 資源),並實作最低許可權原則。

使用者身分識別
  • 使用 App Service 的整合式驗證機制 (“EasyAuth”) 。 EasyAuth 可簡化將識別提供者整合到 Web 應用程式的程式。 它會處理 Web 應用程式外部的驗證,因此您不需要進行重要的程式碼變更。
  • 設定自訂網域的回復 URL。 您必須將 Web 應用程式重新導向至 https://<application-gateway-endpoint>/.auth/login/<provider>/callback。 將取代 <application-gateway-endpoint> 為公用IP位址或與應用程式閘道相關聯的自定義功能變數名稱。 將 取代 <provider> 為您所使用的驗證提供者,例如Microsoft Entra標識碼的 “aad”。 您可以使用 Azure Front 檔來設定此流程與 應用程式閘道 或設定 應用程式閘道
工作負載身分識別
  • 針對工作負載身分識別使用受控識別。 受控識別不需要開發人員管理驗證認證。
  • 使用使用者指派的受控識別。 系統指派的身分識別可能會根據競爭條件和作業順序,造成基礎結構即程式代碼部署失敗。 您可以使用使用者指派的受控識別來避免其中一些部署錯誤案例。 如需詳細資訊,請參閱受控識別

卓越營運

卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊,請參閱卓越營運要素的概觀 (部分機器翻譯)。

基準 App Service 應用程式的部署遵循使用 Azure Pipelines 的 Azure Web Apps CI/CD 中的指引。 除了該指引之外,App Services 基準架構也會考慮應用程式和部署記憶體帳戶受到網路保護。 架構會拒絕對 App Service 的公用存取。 這表示您無法從虛擬網路外部部署。 基準會示範如何使用自我裝載的部署代理程式,在虛擬網路內部署應用程式程序代碼。 下列部署指引著重於部署應用程式程序代碼,而不是部署基礎結構或資料庫變更。

顯示基準 App Service 部署架構的圖表。

圖 3:部署 Azure App 服務 應用程式

部署流程

  1. 在發行管線中,管線會在作業佇列中張貼自我裝載代理程序的作業要求。 作業要求是讓代理程式將發佈 zip 檔案組建成品上傳至 Azure 儲存體 帳戶。

  2. 自我裝載部署代理程式會透過輪詢來挑選新的作業要求。 它會下載作業和組建成品。

  3. 自我裝載部署代理程式會透過記憶體帳戶的私人端點,將 zip 檔案上傳至記憶體帳戶。

  4. 管線會繼續,而受控代理程式會挑選後續作業。 受控代理程式 會進行 CLI 呼叫,將 appSetting WEBSITE_RUN_FROM_PACKAGE更新為預備位置的新發行 zip 檔案名稱。

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
    
  5. Azure App 服務 透過記憶體帳戶私人端點從記憶體提取新的發佈 zip 檔案。 暫存實例會以新的套件重新啟動,因為WEBSITE_RUN_FROM_PACKAGE已設定為不同的檔名。

  6. 管線會繼續並執行任何煙霧測試,或等候核准。 如果已提供測試通過或核准,管線會交換預備和生產位置。

部署指引

下列重點說明基準架構的重要部署指引。

  • 使用 從套件 執行以避免部署衝突。 當您直接從 Azure App 服務 中的套件執行應用程式時,套件中的檔案不會複製到 wwwroot 目錄。 相反地,ZIP 套件本身會直接掛接為唯讀的 wwwroot 目錄。 這可消除部署與運行時間之間的檔案鎖定衝突,並確保隨時只會執行完全部署的應用程式
  • 在已部署的套件 zip 檔案中包含版本號碼。 將 WEBSITE_RUN_FROM_PACKAGE appSetting 更新為具有不同檔名的部署套件,會導致 App Services 自動挑選新版本並重新啟動服務。
  • 使用部署位置進行復原程式代碼部署。
  • 請考慮使用受控和自我裝載代理程式的混合。
    • 使用 自我裝載代理 程式,透過私人端點將套件 zip 檔案上傳至記憶體帳戶。 代理 程式會透過輪詢 起始與管線的通訊,因此不需要開啟網路以進行輸入呼叫。
    • 針對管線中的其他作業使用受控代理程式。
  • 使用基礎結構即程式代碼將基礎結構部署自動化(IaC)。
  • 使用 Azure Load Testing 和 Azure Chaos Studio服務,持續驗證工作負載以測試整個解決方案的效能和復原能力。

組態

應用程式需要組態值和秘密。 使用下列指導方針進行設定和秘密管理。

  • 請勿將密碼或存取金鑰等秘密檢查到原始檔控制。
  • 使用 Azure 金鑰保存庫 來儲存秘密。
  • 針對您的應用程式組態使用App Service組態。 如果您需要從應用程式組態外部化組態,或需要功能旗標支援,請考慮使用 Azure 應用程式組態
  • 使用 App Service 組態中的 金鑰保存庫 參考,安全地公開應用程式中的秘密。
  • 如果您需要不同的生產和預備設定,請建立堅持位置的應用程式設定,且不需要交換。 當您交換部署位置時,應用程式設定預設會交換。
  • 設定本機開發的本機環境變數,或利用應用程式平臺功能。 App Services 組態會將應用程式設定公開為環境變數。 例如,Visual Studio 可讓您在啟動配置檔中設定環境變數。 它也可讓您使用應用程式設定和用戶密碼來儲存本機應用程式設定和秘密。

監視

監視是從IT系統收集和分析數據。 監視的目標是要追蹤 Web 應用程式健康情況和安全性的多層可觀察性。 可檢視性是基準 App Service 架構的重要 Facet。

若要監視 Web 應用程式,您需要從應用程式程式代碼、基礎結構(運行時間)和平臺 (Azure 資源) 收集及分析計量和記錄。 如需詳細資訊,請參閱 Azure 活動記錄Azure 資源記錄和應用程式記錄。

監視平臺

平台監視是從您架構中的 Azure 服務收集數據。 請考慮下列有關平台監視的指引。

應用程式閘道

應用程式閘道 監視其後端集區中資源的健康情況。 使用 應用程式閘道 Access 記錄來收集時間戳、HTTP 回應碼和 URL 路徑等資訊。 如需詳細資訊,請參閱 應用程式閘道 預設健康情況探查後端健康情況和診斷記錄

應用程式服務

App Service 具有內建和整合的監視工具,您應該啟用以提升可檢視性。 如果您的 Web 應用程式已經有遙測和監視功能(「行程內檢測」),它應該會繼續在 App Service 上運作。

  • 啟用自動檢測。 App Service 具有檢測延伸模組,您可以在不變更程式代碼時啟用。 您可以取得應用程式效能監視 (APM) 可見度。 如需詳細資訊,請參閱監視 Azure App 服務 效能
  • 啟用分散式追蹤。 自動檢測提供一種方式,可透過分散式追蹤和效能分析工具監視分散式雲端系統。
  • 針對自訂遙測使用程式碼型檢測。 Azure 應用程式 Insights 也支援自定義應用程式遙測的程式代碼型檢測。 將 Application Insights SDK 新增至您的程式代碼,並使用 Application Insights API。
  • 啟用 App Service 記錄。 App Service 平台支援四個額外的記錄,您應該啟用以支援疑難解答。 這些記錄是應用程式記錄、Web 伺服器記錄、詳細的錯誤訊息,以及失敗的要求追蹤。
  • 使用結構化記錄。 將結構化記錄連結庫新增至您的應用程式程式碼。 更新您的程式代碼以使用機碼/值組,並在 App Service 中啟用應用程式記錄,將這些記錄儲存在 Log Analytics 工作區中。
  • 開啟 App Service 健康情況檢查。 健康情況檢查會從狀況不良的實例重新路由傳送要求,並取代狀況不良的實例。 您的 App Service 方案需要使用兩個以上的實例來進行健康情況檢查才能運作。
Database
  • 用戶資料庫深入解析。 針對 Azure SQL 資料庫,您應該在 Azure 監視器中設定 SQL Insights。 Database Insights 會使用動態管理檢視來公開您需要監視健康情況、診斷問題及微調效能的數據。 如需詳細資訊,請參閱使用 Azure 監視器監視 Azure SQL 資料庫。
  • 如果您的架構包含 Cosmos DB,則不需要啟用或設定任何專案以使用 Cosmos DB 深入解析

治理

Web 應用程式可藉由強制執行架構和安全性決策,從 Azure 原則 獲益。 Azure 原則 可以讓它(1)不可能部署(拒絕)或(2)容易偵測(稽核)組態漂移從您慣用的預期狀態。 這可協助您攔截基礎結構即程序代碼 (IaC) 部署,或 Azure 入口網站 偏離已同意架構的變更。 您應該將架構中的所有資源放在 Azure 原則 控管之下。 盡可能使用內建原則或原則計劃來強制執行基本網路拓撲、服務功能、安全性和監視決策,例如:

  • App Service 應停用公用網路存取
  • App Service 應該使用虛擬網路整合
  • App Service 應使用 Azure Private Link 連線至 PaaS 服務
  • App Service 應停用 FTP 和 SCM 網站部署的本機驗證方法
  • App Service 應該已關閉遠端偵錯
  • App Service 應用程式應使用最新的 TLS 版本
  • 應啟用適用於 App Service 的 Microsoft Defender
  • 應為應用程式閘道啟用 Web 應用程式防火牆 (WAF)

如需重要服務,請參閱更多內建原則,例如 應用程式閘道 和網路元件App Service金鑰保存庫監視。 如果內建原則未完全涵蓋您的需求,可以建立自定義原則或使用社群原則(例如從 Azure 登陸區域)。 當內建原則可供使用時,偏好使用。

下一步