共用方式為

應用程式閘道整合

  • 發行項

本文將逐步解說如何使用私人端點來保護流量，以使用App Service 設定 應用程式閘道。 本文也會討論使用服務端點與內部和外部 App Service 環境 整合的考慮。 最後，本文說明如何在原始檔控制管理員 (SCM) 網站上設定存取限制。

與 App Service 整合

您可以使用私人端點來保護 應用程式閘道 與 App Service 應用程式之間的流量。 您必須確保應用程式閘道可以使用 DNS 來解析 App Service 應用程式的私人 IP 位址。 或者，您可以使用後端集區中的私人 IP 位址，並在 HTTP 設定中覆寫主機名稱。

此圖顯示透過私人端點流向應用程式閘道的流量，流向App Service中的應用程式實例。

應用程式閘道會快取 DNS 查閱結果。 如果您使用完整網域名稱 (FQDN) 並依賴 DNS 查閱來取得私人 IP 位址，當您在設定後端集區後發生 DNS 更新或 Azure 私人 DNS 區域的連結時，您可能需要重新啟動應用程式閘道。

若要重新啟動應用程式閘道，請使用 Azure CLI 將其停止再啟動：

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

深入瞭解使用 私人端點設定App Service 應用程式。

使用服務端點的考慮

作為私人端點的替代方案，您可以使用服務端點來保護來自 應用程式閘道 的流量。 您可以使用服務端點，僅允許來自 Azure 虛擬網路內特定子網路的流量，並封鎖其他所有流量。 在下列案例中，我們將使用這項功能來確保 App Service 執行個體僅能接收特定應用程式閘道的流量。

此圖顯示因特網流向 Azure 虛擬網路中的應用程式閘道，然後流經防火牆圖示流向 App Service 中的應用程式實例。

除了建立App Service 應用程式實例和應用程式閘道之外，此組態還有兩個部分。 第一部分是在應用程式閘道所部署的虛擬網路子網路中，啟用服務端點。 服務端點可確保從子網路到 App Service 的所有網路流量皆會標記特定的子網路識別碼。

第二部分是設定特定 Web 應用程式的存取限制，以確保僅允許具有此特定子網路識別碼標記的流量。 您可以依您的喜好設定，使用不同工具來設定存取限制。

透過 Azure 入口網站，您可以遵循四個步驟來建立和設定 App Service 和應用程式閘道的設定。 若有現有資源，便可跳過前面的步驟。

  1. 使用 App Service 文件中的快速入門之一建立 App Service 執行個體。 其中一個範例是 .NET Core 快速入門。
  2. 使用入口網站快速入門來建立應用程式閘道，但跳過有關新增後端目標的部分。
  3. 設定 App Service 做為應用程式閘道後端，但跳過有關限制存取的部分。
  4. 使用服務端點建立存取限制。

您現在可以透過應用程式閘道存取 App Service。 如果您嘗試直接存取 App Service，您應該會收到 403 HTTP 錯誤，指出 Web 應用程式正在封鎖您的存取。

此螢幕快照顯示錯誤 403 - 禁止的文字。

內部 App Service 環境 的考慮

內部 App Service 環境 不會向因特網公開。 執行個體與應用程式閘道間的流量已與虛擬網路隔開。 若要設定內部 App Service 環境，並使用 Azure 入口網站 將其與應用程式閘道整合，請參閱操作指南。

若要確保 App Service 環境僅接收應用程式閘道子網路的流量，您可以設定對 App Service 環境中的所有 Web 應用程式都有影響的網路安全性群組 (NSG)。 針對 NSG，您可以指定子網路 IP 範圍，並選擇性地指定連接埠 (80/443)。

若要隔離個別 Web 應用程式的流量，由於服務端點不適用於 App Service 環境，您必須使用以 IP 為基礎的存取限制。 IP 位址應為應用程式閘道的私人 IP。

外部 App Service 環境的考量

外部 App Service 環境 具有公用面向的負載平衡器，例如多租使用者 App Service 應用程式。 服務端點不適用於 App Service 環境。 透過 App Service 環境，您可以使用應用程式閘道的公用IP位址來使用IP型存取限制。 若要使用 Azure 入口網站建立外部 App Service 環境，請遵循本快速入門。

您也可以將私人端點新增至裝載於外部 App Service 環境 上的應用程式。

Kudu/SCM 網站的考量

SCM 網站是存在於每個 Web 應用程式的管理網站，又稱為 Kudu。 對於 SCM 網站無法使用反向 Proxy。 您很可能也想將其限定於個別 IP 位址或特定子網路。

若要使用與主要網站相同的存取限制，可以使用下列命令繼承設定：

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

如果您想要新增 SCM 網站的個別存取限制，您可以使用 --scm-site 旗標：

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

使用預設網域的考量

若要設定整合，最簡單的方式是設定應用程式閘道以覆寫主機名稱，並使用 App Service 的預設網域 (通常是 azurewebsites.net)。 這種方式不需要在 App Service 中設定自訂網域和憑證。

本文討論覆寫原始主機名稱的一般考量。 在 App Service 中，有兩種情況需要注意此設定。

驗證

當您使用 App Service (以前稱為 Easy Auth) 中的驗證功能時，您的應用程式通常會重新導向至登入頁面。 因為 App Service 不知道要求的原始主機名稱，因此會對預設網域名稱執行重新導向，且通常會導致錯誤。

若要解決預設重新導向問題，您可以設定驗證來檢查轉送的標頭，並將重新導向網域調整為原始網域。 應用程式閘道會使用名為 X-Original-Host 的標頭。 藉由使用檔案型設定來設定驗證，您可以設定 App Service 以因應原始主機名稱。 將此設定新增至您的組態檔：

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

工作階段親和性

在多個實例部署中， 會話親和性 可確保用戶端要求在會話存限期間路由傳送至相同的實例。 會話親和性可以設定為將 Cookie 網域從反向 Proxy 調整為傳入標頭。 藉由將會話親和性 Proxy 設定為 true，會話親和性會尋找X-Original-Host或X-Forwarded-Host調整 Cookie 網域到此標頭中找到的網域。 在啟用會話親和性 Proxy 時，建議您在站臺上設定存取限制，以確保流量來自反向 Proxy。

您也可以 clientAffinityProxyEnabled 使用下列命令進行設定：

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

下一步

如需 App Service 環境的詳細資訊，請參閱 App Service 環境文件。

若要進一步保護 Web 應用程式，您可在 Azure Web 應用程式防火牆文件中找到應用程式閘道的 Azure Web 應用程式防火牆相關資訊。

若要使用 Azure Front Door 或應用程式閘道在 App Service 上部署具有自訂網域且安全而可復原的網站，請參閱本教學課程。