Azure Container Apps (ACA) 存取 VNet 內的資源

既然你已經從 Web App 遷移到 Azure Container Apps (ACA)，網路架構的邏輯會稍微有些不同。ACA 本身就是建立在一個名為 Container Apps Environment 的容器環境中，因此 VNet 的整合是在「環境 (Environment)」層級設定的，而不是單獨在特定的 App 上。

存取 VNet 資源的流程主要分為：環境網路配置、基礎架構委派、以及 ACA 部署。

1. 核心觀念：VNet 整合模式

ACA 支援兩種網路模式：

  • External (外部)：環境有公網 IP，但後端可以存取 VNet 資源。
  • Internal (內部)：環境沒有公網 IP，所有存取都必須透過 VNet（適合純內網系統）。

2. 實作流程與 CLI 指令

第一步：建立（或準備）Subnet 並設定委派

與 Web App 相似，ACA 的 Subnet 也需要特定的委派，但它是委派給 Microsoft.App/environments。

PowerShell

# 定義變數 (假設 VNet 在不同的 RG)
$VNET_RG = "rg-network-shared"
$VNET_NAME = "vnet-pr-stg-twn-01"
$ACA_SUBNET_NAME = "snet-aca-integration" # 建議建立一個新的 Subnet

# 更新 Subnet 委派
az network vnet subnet update `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $ACA_SUBNET_NAME `
  --delegations Microsoft.App/environments

第二步：取得 Subnet ID

跨 RG 操作時，直接拿 ID 最安全：

PowerShell

$SUBNET_ID = $(az network vnet subnet show `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $ACA_SUBNET_NAME `
  --query id -o tsv)

第三步：建立 Container Apps Environment 並綁定 VNet

這是關鍵步驟。一旦 Environment 建立並綁定 VNet，該環境下所有的 Container Apps 都能直接存取該 VNet 內的資源。

PowerShell

$ENVIRONMENT_NAME = "cae-pr-stg-twn-001"

az containerapp env create `
  --name $ENVIRONMENT_NAME `
  --resource-group $RESOURCE_GROUP `
  --location "taiwannorth" `
  --infrastructure-subnet-id $SUBNET_ID `
  --internal-client-ip-dns-mode "None"  # 如果需要外部存取設為 None，純內網設為 Internal

第四步：部署 Container App 到該環境

PowerShell

az containerapp create `
  --name "my-fast-app" `
  --resource-group $RESOURCE_GROUP `
  --environment $ENVIRONMENT_NAME `
  --image "${ACR_NAME}.azurecr.io/policy-app:v1" `
  --registry-server "${ACR_NAME}.azurecr.io" `
  --target-port 80 `
  --ingress 'external' # 允許外部流量進來

3. 如何存取 VNet 內的資源？

部署完成後，你的 Container App 就像是在 VNet 內的一台機器：

  • 透過 IP 存取：你可以直接 ping 或連線 VNet 內 VM 的私有 IP。
  • 透過 DNS 存取：如果你 VNet 內有設定 Azure Private DNS Zones，你需要確保 ACA 環境關聯了該 Private DNS，這樣才能解析例如 mydb.privatelink.database.azure.com 這樣的域名。

4. 權限鬼打牆預警 (RBAC)

因為你跨了 Resource Group，且不是 Owner：

  1. Network Contributor：你的帳號必須在 VNet RG 擁有這個角色，否則無法將 ACA 環境掛載到該 Subnet。
  2. Managed Identity：如果你的 ACA 需要存取 Key Vault 或 SQL (存取權限控管)，建議幫 ACA 開啟 System Assigned Identity。

💡 總結

ACA 的優勢在於一次設定，全家享用。只要把 Environment 塞進 VNet，之後在裡面建立的幾十個微服務就通通都能連內網了。

寫一段建立新 Subnet 的指令

既然要為 Azure Container Apps (ACA) 建立新的 Subnet，我們必須確保該 Subnet 的位址空間不與現有的資源衝突，並且正確設定 委派 (Delegation)。

在跨 Resource Group 的情境下，請執行以下 PowerShell 指令：

1. 定義變數

請根據你的實際環境修改位址範圍（例如 10.0.2.0/24）：

PowerShell

$VNET_RG = "rg-network-shared"         # VNet 所在的 RG
$VNET_NAME = "vnet-pr-stg-twn-01"       # 現有的 VNet 名稱
$NEW_SUBNET_NAME = "snet-aca-infra-01"  # 新 Subnet 的名字
$ADDRESS_PREFIX = "10.0.2.0/24"         # 確保此範圍在 VNet 內且未被使用

2. 建立 Subnet 並設定委派

我們使用 az network vnet subnet create 指令。關鍵在於 --delegations，這會告訴 Azure：「這個網段是給 ACA 環境專用的」。

PowerShell

az network vnet subnet create `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $NEW_SUBNET_NAME `
  --address-prefixes $ADDRESS_PREFIX `
  --delegations "Microsoft.App/environments"

3. 取得新 Subnet 的 ID (供後續建立 ACA 環境使用)

建立完成後，建議直接把 ID 存起來，這樣在建立 ACA Environment 時才不會因為名稱解析問題而「鬼打牆」：

PowerShell

$ACA_SUBNET_ID = $(az network vnet subnet show `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $NEW_SUBNET_NAME `
  --query id -o tsv)

# 驗證一下有沒有抓到
echo $ACA_SUBNET_ID

⚠️ 執行前的注意事項 (避免再次鬼打牆)

  • 位址衝突：請先確認 $ADDRESS_PREFIX 沒有被 VNet 內其他的 Subnet 佔用。你可以執行 az network vnet show -g $VNET_RG -n $VNET_NAME --query "subnets[].addressPrefix" 來查看已使用的網段。
  • Subnet 大小：ACA 規定最小必須是 /23 (512 個 IP) 或 /27 (32 個 IP)，具體取決於你的工作負載。對於測試環境，建議至少使用 /24 或 /23，因為 ACA 在升級（Rolling update）或擴展時會消耗大量 IP。
  • 權限：雖然你不是 Owner，但只要你在 $VNET_RG 擁有 Network Contributor 角色，就可以成功執行這段指令。

下一步你就可以拿著 $ACA_SUBNET_ID 去執行 az containerapp env create 了。

準備建立環境的完整指令

沒問題！我們直接把 建立 Subnet 到 建立 ACA 環境 的完整流程串起來。這組指令會確保你的 Container Apps 基礎設施能夠正確與 VNet 銜接。

第一階段：建立 Subnet (跨 RG)

請確保你已經定義了之前討論的變數（$VNET_RG, $VNET_NAME 等）。

PowerShell

# 1. 在指定的 VNet RG 下建立專屬 Subnet
az network vnet subnet create `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $NEW_SUBNET_NAME `
  --address-prefixes $ADDRESS_PREFIX `
  --delegations "Microsoft.App/environments"

# 2. 獲取該 Subnet 的 Resource ID (這是建立環境的必要參數)
$ACA_SUBNET_ID = $(az network vnet subnet show `
  --resource-group $VNET_RG `
  --vnet-name $VNET_NAME `
  --name $NEW_SUBNET_NAME `
  --query id -o tsv)

第二階段：建立 ACA 環境 (Managed Environment)

這是 ACA 的核心，「環境」決定了容器的網路邊界。

PowerShell

# 定義環境名稱
$ENVIRONMENT_NAME = "cae-pr-stg-twn-001"

# 建立環境並掛載到 VNet ID
az containerapp env create `
  --name $ENVIRONMENT_NAME `
  --resource-group $RESOURCE_GROUP `
  --location "taiwannorth" `
  --infrastructure-subnet-id $ACA_SUBNET_ID `
  --internal-client-ip-dns-mode "None"

💡 專業提示：

  • --internal-client-ip-dns-mode "None"：這代表你的 ACA 會有一個公用 IP (External)。如果你希望這是一個純內網（外面完全連不到）的環境，請將此參數改為 Internal。

第三階段：部署第一個 Container App

現在環境已經在 VNet 裡了，我們把你的 App 丟進去測試連通性。

PowerShell

az containerapp create `
  --name "app-pr-stg-twn" `
  --resource-group $RESOURCE_GROUP `
  --environment $ENVIRONMENT_NAME `
  --image "${ACR_NAME}.azurecr.io/policy-app:v1" `
  --registry-server "${ACR_NAME}.azurecr.io" `
  --registry-username $ACR_USERNAME `
  --registry-password $ACR_PASSWORD `
  --target-port 80 `
  --ingress 'external' `
  --query "properties.configuration.ingress.fqdn"

網路架構圖解

這套設定完成後，你的網路架構會長這樣：

驗證 VNet 連通性

部署成功後，你可以進入 ACA 的「主控台 (Console)」或是透過 az containerapp exec 嘗試 ping VNet 內的資源（例如資料庫的 Private IP）：

PowerShell

# 進入容器內部測試
az containerapp exec --name "app-pr-stg-twn" --resource-group $RESOURCE_GROUP --command "ping 10.0.1.5"

🛑 避坑指南：關於「位置 (Location)」

ACA 與 VNet 整合時，Region 必須完全一致。

  • 如果 VNet 在 Japan East，指令中的 --location 必須填 japaneast。
  • 如果 VNet 在 Taiwan North，則填 taiwannorth。

如果跨區建立，az containerapp env create 會報錯並告訴你 Subnet 不在該區域。

在使用 Azure Container Apps (ACA) 時，理解「環境 (Environment)」與「網路 (VNet)」的關係至關重要。你的觀察很準確：ACA 的網路配置確實是綁定在 Environment 層級，這決定了該環境下所有 Microservices 的通訊邊界。

以下是針對你問題的詳細解析：

1. 容器應用程式環境 (Environment) 如何設定？

在建立 ACA 環境時，網路設定主要分為兩大模式。一旦環境建立後，虛擬網路配置是無法更改的（例如：不能從內網模式改為外網模式）。

核心設定步驟：

  1. 選擇 VNet 整合模式：
    • External (外部)：環境會有一個公用 IP。雖然它整合在你的 VNet 中，但入口 (Ingress) 是對外開放的。
    • Internal (內部)：環境使用 VNet 私有 IP。入口僅限於 VNet 內部或透過 VPN/ExpressRoute 連線的對象。
  2. 準備子網 (Subnet)：
    • ACA 環境需要一個專用子網（建議 CIDR 至少為 /23 或 /27，取決於規模）。
    • 該子網必須委派 (Delegate) 給 Microsoft.App/testClients（在使用門戶時會自動處理）。
  3. 基礎結構資源群組：
    • ACA 會自動建立一個額外的資源群組（名稱通常以 MC_ 開頭），用來放置負載平衡器、Managed Identity 等底層元件。

2. ACA 可以連到多個 VNet 嗎？

答案是：一個環境（Environment）只能「直接」加入一個 VNet。

但是，如果你需要 ACA 存取其他 VNet 中的資源，可以透過 Azure 的標準網路技術來達成：

  • VNet Peering (虛擬網路對等)：這是最常見的做法。將 ACA 所在的 VNet 與目標 VNet 串連，ACA 就能像存取本地資源一樣存取對端資源。
  • Private Endpoints (私有端點)：如果目標是 PaaS 服務（如 SQL, Key Vault），建議在 ACA 所在的 VNet 中建立 Private Endpoint。
  • Virtual WAN：對於跨區域或大規模的多 VNet 架構，透過 Hub-and-Spoke 模型達成互連。

3. 如何設定「對外的網路」？

如果你希望 ACA 具備對外服務的能力，同時又想保有 VNet 的控制權，有以下兩種策略：

策略 A：使用 External 模式 (最簡單)

在建立環境時，將 Virtual IP 設定為 External。

  • 優點：Azure 會自動為你的 Environment Ingress 分配一個公用 IP。
  • 缺點：控制力較弱，所有 Container App 的外網入口都共用同一個 IP。

策略 B：使用 Internal 模式 + Application Gateway (最推薦/安全)

這是企業級架構的首選。將 ACA 設定為 Internal（不對外），然後在 VNet 前端放一個 Azure Application Gateway。

  • 架構邏輯：
    1. ACA 環境：隱藏在 VNet 私有子網中。
    2. App Gateway：擁有公用 IP，負責接收外部流量。
    3. 轉發：App Gateway 透過私有網路將流量導向 ACA 的內部負載平衡器位址。
  • 優點：可以加上 WAF (網頁應用程式防火牆) 防護，且能更精確地管理 SSL 憑證。

快速比較表

功能External 模式Internal 模式 (+ Gateway)
公用存取直接由 ACA 環境提供由 Gateway 提供，ACA 隱身
安全性基本保護高 (可加裝 WAF)
VNet 整合是是
適用場景快速開發、簡單網站企業正式環境、API 閘道需求

溫馨提醒：在規劃子網空間時，請務必留足 IP 數量。ACA 在擴展 (Scale out) 時會消耗子網內的 IP，如果 IP 用盡，容器將無法啟動。

你目前的架構是打算直接讓每個 App 都有獨立的公用 IP，還是希望能有一個統一的入口來管理這些流量？

App Gateway 費用

在使用 Azure Application Gateway 作為 Azure Container Apps (ACA) 的入口時，費用是許多開發者最關心的部分。App Gateway 的計費模式相較於其他服務稍微複雜一些，主要由 「固定費用」 與 「容量單位費用」 兩部分組成。

目前建議使用 Standard_v2 或 WAF_v2 版本，因為它們支援自動調整大小 (Autoscaling) 且效能更佳。

1. 費用結構分解 (以 v2 版本為例)

A. 固定時薪 (Fixed Cost)

只要你部署了 Application Gateway，不論流量多少，每小時都會產生固定費用。

  • Standard_v2: 約 $0.20 USD / 小時 (一個月約 $144 USD)。
  • WAF_v2 (含防火牆): 約 $0.40 USD / 小時 (一個月約 $288 USD)。

注意：如果啟用了「自動調整大小」，且執行個體數目為 0，仍會收取此固定費用。

B. 容量單位費用 (Capacity Unit, CU)

這是根據實際使用量計費的部分。1 個 CU 每小時約 $0.008 USD。

Azure 會從以下三個維度計算，並取其 「最大值」 來決定該小時消耗了多少個 CU：

  1. 計算量 (Compute)：處理連線的 CPU 消耗。
  2. 持續連線數 (Persistent Connections)：每 2,500 個連線算 1 個 CU。
  3. 吞吐量 (Throughput)：每 2.22 Mbps 的資料傳輸量算 1 個 CU。

2. 預估案例 (以台幣/美金概算)

假設你是一個中小型專案，流量穩定且不大的情況：

項目Standard_v2 (無 WAF)WAF_v2 (含防火牆)
月固定費用約 $144 USD (約 NT$ 4,600)約 $288 USD (約 NT$ 9,200)
低流量 CU 費用約 $10 ~ $20 USD約 $10 ~ $20 USD
每月總估計約 NT$ 5,000 ~ 6,000約 NT$ 9,500 ~ 11,000

3. 節省費用的替代方案

如果你的預算有限，或是專案還在初期開發階段，直接使用 App Gateway 可能會覺得負擔太重。以下是針對 ACA 的其他選擇：

  • ACA 內建 External 模式：
    • 費用：$0 (這功能是免費提供的)。
    • 優點：設定極快，自動獲得公用 IP 和 FQDN。
    • 缺點：無法進行細部的進階路由控制或加裝 WAF。
  • Azure Front Door (AFD)：
    • 費用：按流量計費，基本方案 (Standard) 每月固定費約 $35 USD 起。
    • 適合：全球分散的應用程式。雖然連線到內部 VNet 的 ACA 需要搭配 Private Link Service，但整體起步成本可能比 App Gateway 低。
  • Cloudflare + ACA External Ingress：
    • 費用：Cloudflare 有免費版。
    • 做法：讓 ACA 維持 External，但限制只有 Cloudflare 的 IP 可以進入。這能以最低成本獲得 WAF 和 DDoS 防護。

總結建議

  • 如果你需要嚴格的內網安全控管：必須選 App Gateway (Internal 模式)，請預留每月至少台幣 5,000 元以上的預算。
  • 如果你只是想要有個對外網路，且沒有法規合規壓力：建議先從 ACA 的 External Ingress 開始使用，這部分是免費的，等流量變大或有安全需求後再掛載 App Gateway。

你目前預計的流量規模大概是多少？如果只是個人測試或輕量級 API，或許 External 模式配上 API Management (Consumption Tier) 會是更省錢的選擇。

對比ACA 使用 External 模式的費用

簡單來說，ACA External 模式是「內建免費」的，而掛載 App Gateway 則是一筆顯著的「額外固定支出」。

以下是兩者的詳細費用對比：

1. 費用對比表 (2026 預估價格)

項目ACA External 模式Internal 模式 + App Gateway (v2)
入口服務費$0 (內建功能)$144+ USD/月 (固定時薪)
防火牆 (WAF)無 (僅基本 DDoS 防護)$288+ USD/月 (固定時薪)
流量處理費每百萬次請求 $0.40 USD每容量單位 (CU) $0.008 USD/時
固定低消$0 (用多少付多少)約 NT$ 4,600 ~ 9,000 / 月
設定難度極低 (一鍵開啟)中高 (需設定子網與後端池)

2. 深入分析：為什麼費用差這麼多？

ACA External 模式：省錢之選

在 External 模式下，Azure 會為你的環境建立一個共用的負載平衡器（Load Balancer）。

  • 省錢點：你不需要支付這個負載平衡器的「租金」，只需要支付 ACA 本身的算力費（CPU/Memory）和請求數費。
  • 免費額度：ACA 每個月有 200 萬次免費請求。如果你的流量很小，入口端幾乎是 完全免費。
  • 適合對象：個人專案、開發測試環境、預算有限的小型 API。

App Gateway (v2)：安全與控制之選

當你為了安全性選擇 Internal 模式並掛上 App Gateway 時，你買的是一個專用的虛擬設備。

  • 費用組成：
    • 固定費用：只要服務開著，每小時都在燒錢（約 $0.20 USD/hr）。
    • WAF 加值：如果你要防範 SQL Injection 或惡意攻擊，開啟 WAF 功能會讓固定費用直接翻倍。
  • 適合對象：企業級應用、需要自訂複雜路由規則、或是法規要求必須有 Web 應用程式防火牆 (WAF) 的場景。

3. 我該選哪一個？

場景一：我想要最省錢，且不需要複雜的網路控管。

  • 建議：直接使用 ACA External 模式。
  • 省錢秘訣：如果你擔心安全，可以在前端掛一個 Cloudflare（免費版），並在 ACA 設定 IP Restrictions，只允許 Cloudflare 的 IP 進入。這樣你一毛錢 App Gateway 的費用都不用出。

場景二：我需要符合資安合規，且容器必須隱藏在內網。

  • 建議：使用 App Gateway v2 或最新的 Application Gateway for Containers (更適合容器化架構，費用略低但功能更現代)。
  • 預算準備：每個月請至少準備 NT$ 5,000 作為基礎網路開銷。

4. 補充：另一種平衡選擇 (Azure Front Door)

如果你有多個區域部署，或是覺得 App Gateway 太貴，可以考慮 Azure Front Door (Standard)。

  • 優點：它是按流量計費，每個月固定費大約 $35 USD (約 NT$ 1,100)，比 App Gateway 便宜許多，且同樣具備基本的 WAF 功能和全球加速。
  • 搭配方式：ACA 設定為 External，前端掛 Front Door 並限制只有 Front Door 的流量能進入。

總結建議： 如果只是想讓網路通，External 模式 是最划算的，它讓你省去每個月數千元的網路固定支出。

ACA使用 External 模式  也有 load balance ?

有的，ACA 在 External 模式下「內建」了強大的負載平衡功能，只是它被封裝在服務內部，你不需要手動建立 Load Balancer 資源。

當你開啟 External Ingress 時，Azure 會在背景為你處理好一切：

1. 內建負載平衡的運作邏輯

ACA 的負載平衡是在兩個層級進行的：

  • 流量入口 (Ingress 層)：Azure 會在該環境（Environment）前端自動配置一個 L7 負載平衡器（基於 Envoy Proxy）。它會接收來自公網的請求，並處理 TLS 終端（HTTPS 憑證加密）、路徑路由等工作。
  • 複本分配 (Replica 層)：如果你的容器應用程式設定了多個複本（Replicas），內建的負載平衡器會自動將請求分發到這些健康的複本上。

2. External 模式提供的功能

雖然是內建免費，但它提供的功能相當完整：

  • 自動 HTTPS：系統會自動為你的 *.azurecontainerapps.io 域名提供託管憑證。
  • 流量分割 (Traffic Splitting)：這是一大強項。你可以同時運行兩個版本（Revision），並設定 80% 流量去舊版、20% 去新版，實現 藍綠部署 (Blue-green) 或 金絲雀發佈 (Canary)。
  • 工作階段親和性 (Session Affinity)：支援 HTTP 工作階段綁定（Sticky Sessions），確保同一使用者的請求導向同一個複本。
  • 自訂網域名稱：你可以掛載自己的網域，ACA 也會幫你管理 SSL 憑證。

3. 與 App Gateway 的本質區別

你可能會問：「既然 ACA 已經有 Load Balance 了，為什麼還有人要花錢買 App Gateway？」

功能ACA 內建 Load BalancerApp Gateway (額外付費)
位置緊貼容器環境內部位於 VNet 的最前端
WAF 安全防護無 (僅基本 DDoS)有 (防 SQL 注入、XSS 攻擊)
URL 重寫功能較基本強大且靈活的重寫規則
多站點託管主要是單一 App 的 Ingress可同時管理多個不同服務的後端
管理成本$0 (全自動)需支付固定月租費

結論

如果你只是需要流量分發、自動擴展、HTTPS 以及 版本切換，ACA 的 External 模式 已經完全足夠，而且完全免費。

你只需要在 App 的「輸入 (Ingress)」設定中，將 Ingress 設為 Enabled，並將 Traffic 設為 Accepting traffic from anywhere，你的 Load Balance 就已經啟動了！

你目前的應用程式是否需要 WAF 防火牆（例如為了過資安審核）？如果不需要，用 External 模式可以幫你省下每個月幾千塊的支出。

既然你的需求是為了**「通過資安審核」**，那麼 WAF (Web Application Firewall) 就是必選題了。資安審核（如 ISO 27001, PCI-DSS 或金管會規範）通常要求具備偵測並攔截 SQL Injection、XSS 等攻擊的能力，而 ACA 內建的 Load Balancer 僅提供基本傳輸功能，並不具備這類深層封包檢查（Deep Packet Inspection）的能力。

要達成此目標，你有以下三種主要方案，費用與架構邏輯各不相同：

方案一：最正規的企業架構 (Application Gateway + WAF v2)

這是最常見的審核過關配置。你會將 ACA 環境設為 Internal（隱藏在私有網段），前端放一個 App Gateway 帶 WAF。

  • 架構：外部流量 → App Gateway (WAF) → VNet 內部 → ACA Internal Ingress。
  • 優點：符合所有資安規範；流量完全不暴露於公網。
  • 缺點：費用最高（每月至少 NT$ 9,000+ 起）。
  • 審核關鍵：可以提供詳細的 WAF 攻擊日誌（Logs）給稽核員。

方案二：性價比高的邊緣防護 (Azure Front Door + WAF)

如果你的服務不需要完全封鎖在 VNet 內，但需要 WAF 標章，Front Door 是個好選擇。

  • 架構：外部流量 → Front Door (WAF) → ACA External Ingress (需設定 IP 限制)。
  • 優點：全域加速、按流量計費，起步成本比 App Gateway 低。
  • 費用：固定費約 $35 USD/月 + WAF 策略費，總額通常比 App Gateway 便宜。
  • 審核關鍵：雖然 ACA 是 External 模式，但透過 IP Restrictions 限制只接受 Front Door 的 IP，在邏輯上同樣可以滿足「防護邊界」的要求。

方案三：最新容器原生方案 (Application Gateway for Containers)

這是 Azure 2024-2025 年推廣的新產品，專為容器化架構設計。

  • 特點：它是傳統 App Gateway 的進階版，與 ACA/AKS 整合更深。
  • 費用架構：將「控制層」與「轉發層」分離，對於中高流量的環境，費用可能比傳統 v2 更具預測性。
  • 審核關鍵：同樣支援 WAF 策略。

資安審核的「加分項」建議

為了順利通過審核，建議你在設定時同步啟用以下功能：

  1. Log Analytics 診斷日誌：
    • WAF 只是防護，資安審核一定要看到日誌。請確保將 WAF 的 Access Log 和 Firewall Log 傳送到 Log Analytics 工作區。
  2. 封鎖模式 (Prevention Mode)：
    • WAF 預設可能是 Detection (僅偵測)，審核時必須切換到 Prevention (攔截模式) 才算有效。
  3. 限制 TLS 版本：
    • 在 WAF 設定中強制要求使用 TLS 1.2 或 1.3，停用過時的 TLS 1.0/1.1。

決策建議

  • 如果預算充足且法規極其嚴格（如銀行）：請選 方案一 (App Gateway WAF v2)。
  • 如果想兼顧效能、全球部署且預算中等：請選 方案二 (Azure Front Door)。

小撇步：如果還在開發階段，可以先用 ACA External 模式省錢，等到審核前一個月再掛上 App Gateway 並開啟 WAF，這樣可以節省前期的建置成本。

針對你的資安審核，是否有特定要求「後端服務必須完全不可從公網訪問（Private IP Only）」？這將決定你必須選方案一，還是方案二也可以接受。

App Gateway, 是可以與多個系統共用?

答案是 肯定的。Azure Application Gateway (App Gateway) 的設計初衷就是為了作為一個「中央閘道器」，能夠同時管理並保護多個不同的後端系統。

這也是為什麼對於有資安審核需求的企業來說，App Gateway 雖然單價高，但透過 「資源共用」 可以大幅攤平單一系統的建置成本。

1. 如何達成「多系統共用」？

App Gateway 透過以下兩種核心機制來區分不同的系統流量：

A. 多站點代管 (Multi-site Hosting)

你可以在同一個 App Gateway 上綁定多個網域（Domain）。

  • 例子：
    • app1.yourcompany.com 導向 ACA 系統 A
    • app2.yourcompany.com 導向 ACA 系統 B
    • api.yourcompany.com 導向 虛擬機 (VM) 或 Azure SQL
  • App Gateway 會根據 HTTP Header 中的 Host 欄位，決定將流量丟給哪一個後端池。

B. 路徑型路由 (Path-based Routing)

如果你只有一個網域，也可以根據 URL 的路徑來拆分流量。

  • 例子：
    • website.com/shop/* 導向 商務系統 (ACA)
    • website.com/blog/* 導向 部落格系統 (VM/App Service)

2. 共用時的優點與風險

優點：節省費用與統一管理

  • 攤平固定成本：原本三個系統要花 3 份 WAF 錢 (約 $288 \times 3 \approx 864$ USD)，現在只需付一份 App Gateway 的錢 ($288$ USD)。
  • 統一 WAF 策略：你可以在閘道層級統一設定資安規則，確保所有系統都符合同樣的資安審核標準。
  • 憑證管理：所有系統的 SSL 憑證可以集中在 App Gateway 管理，不需要分開維護。

風險：單一故障點 (SPOF)

  • 影響範圍廣：如果 App Gateway 設定錯誤或是發生故障，所有掛載在其後的系統都會同時斷線。
  • 效能競爭：如果系統 A 流量暴增，雖然 App Gateway 會自動擴展 (Autoscale)，但若沒設定好，可能會影響到系統 B 的反應速度。

3. 如何將 ACA 接入共用的 App Gateway？

當你要將多個系統接入時，架構會變成這樣：

  1. VNet 規劃：
    • 建立一個 VNet，劃分 Subnet-AppGW (給 Gateway) 和 Subnet-ACA (給 ACA 環境)。
  2. ACA 設定：
    • 將 ACA Environment 設為 Internal。
    • ACA 會獲得一個內部的 Load Balancer IP (或是預設的內部 FQDN)。
  3. App Gateway 設定：
    • Backend Pool：填入 ACA 的內部存取點位址。
    • HTTP Settings：這點很重要，因為 ACA 通常需要 Host Name Override (後端主機名稱覆寫)，否則請求會被 ACA 拒絕。

4. 費用節省試算

如果你有 3 個 需要過資安審核的獨立應用程式：

  • 各自獨立使用 WAF (External 模式 + WAF)：
    • 這在 ACA 上不可行，因為 ACA 本身沒 WAF。
  • 各自掛載 App Gateway (3 個)：
    • 費用：約 $864 USD/月。
  • 共用 1 個 App Gateway (1 個)：
    • 費用：約 $300 – $320 USD/月 (含少量流量費用)。
    • 結論：省下約 65% 的網路支出。

專業建議

既然你有資安審核需求，「共用 App Gateway」 是最聰明的作法。你可以先建立一個足夠規格的 App Gateway (WAF_v2)，然後將目前的所有服務（不論是 ACA、VM 還是 App Service）通通導向它後端。

你目前規劃的系統中，除了 ACA，還有其他類型的服務（例如 SQL 資料庫、Legacy VM）需要一起納入 WAF 的保護範圍嗎？

App Gateway, 一定要有 domain name ?

簡單來說：技術上不一定，但實務上「強烈建議」要有。

如果你只是為了測試，可以直接用 IP 位址 存取；但因為你有 「資安審核」 與 「連接 ACA」 的需求，使用 Domain Name 幾乎是強制性的。

以下是詳細的原因分析：

1. 技術層面：可以用 IP 存取嗎？

可以。App Gateway 建立後會獲得一個前端公用 IP（Frontend Public IP）。

  • 你可以直接在瀏覽器輸入 http://20.xx.xx.xx。
  • 但這僅限於最簡單的測試，且不支援 HTTPS（因為 SSL 憑證必須綁定網域）。

2. 為何連線 ACA「一定」要有 Domain Name？

當 App Gateway 後端接的是 Azure Container Apps (ACA) 時，Domain 變得非常重要：

  • ACA 的識別機制：ACA 環境內部是透過 Host Header 來決定要把流量導向哪一個 Container App。如果 App Gateway 只是丟一個 IP 給 ACA，ACA 會不知道你要找哪一個 App，進而回報 404 錯誤。
  • SNI 與 TLS 握手：現代的加密連線 (HTTPS) 需要 SNI (Server Name Indication)。如果沒有 Domain，App Gateway 無法與後端的 ACA 建立安全的加密隧道。

3. 資安審核的考量 (WAF)

你的目標是通過資安審核，這通常涉及以下要求：

  • 強制 HTTPS/TLS 加密：要啟用 HTTPS，你必須有 SSL 憑證，而憑證是頒發給 Domain (例如 api.yourcompany.com) 的，不是頒發給 IP 的。
  • WAF 規則優化：許多 WAF 規則是基於主機名稱 (Host) 進行過濾的。

4. 如果多個系統共用，該怎麼辦？

當你共用同一個 App Gateway 時，Domain 是區分系統的唯一標準：

  • 系統 A：app1.test.com → 導向 ACA-1
  • 系統 B：app2.test.com → 導向 ACA-2
  • 如果只有一個 IP，App Gateway 將無法區分外部請求到底是想找系統 A 還是系統 B。

5. 沒有預算買網域？解決方案：

如果你目前還不想購買正式網域，有兩個替代方案：

  1. 使用 Azure 預設網域：App Gateway 的公用 IP 可以設定一個 「DNS 名稱標籤」（例如 my-gateway.eastasia.cloudapp.azure.com）。這是一個免費且合法的 FQDN，可以用來申請測試用的憑證或進行連線。
  2. 修改本地 Hosts 檔案 (僅限開發調試)：在你的電腦 C:\Windows\System32\drivers\etc\hosts 中，手動將你的測試網域指向 App Gateway 的 IP。這可以騙過瀏覽器進行測試，但無法用於正式環境或資安審核。

總結

為了滿足你的 資安審核 需求並確保能 連通 ACA：

  • 前端 (Client -> App Gateway)：必須有 Domain，才能掛載 SSL 憑證。
  • 後端 (App Gateway -> ACA)：App Gateway 必須設定「主機名稱覆寫 (Host Override)」，指向 ACA 內部的 FQDN。

你目前已經有準備好要使用的網域了嗎？還是需要指導如何使用 Azure 提供的免費 cloudapp.azure.com 名稱？

Web App, 也會有 vnet 存取內網與 public IP 的問題?

是的，Azure App Service (Web App) 面對網路架構時，邏輯與 ACA 非常相似，但其「虛擬網路整合」的方式稍有不同。

Web App 本質上也是一個多租戶（Multi-tenant）服務，預設是走公網。若要存取內網或限制外部存取，同樣需要處理「流入」與「流出」兩個方向。

1. Web App 的雙向網路邏輯

在 Web App 中，存取內網與對外公開 IP 的問題通常拆解為兩部分：

A. 流出 (Outbound)：Web App 存取內網資源

當你的 Web App 需要連線到同一個 VNet 內的 SQL Server 或 VM 時：

  • 解決方案：VNet Integration (虛擬網路整合)。
  • 邏輯：這會配置一個子網給 Web App 使用，讓 Web App 的「出口」流量進入你的 VNet。
  • 注意：這並不代表你的 Web App 就此變成私有的，它預設仍然有一個公用 IP 可以從外面連進來。

B. 流入 (Inbound)：限制誰能連到 Web App

如果你不希望 Web App 被公網直接存取（為了過資安審核）：

  • 解決方案：Private Endpoint (私有端點)。
  • 邏輯：這會給你的 Web App 一個 VNet 內部的私有 IP。一旦啟用，原本的公用 IP 就會失效（或被拒絕存取）。
  • 搭配 WAF：此時你同樣需要 App Gateway 放在最前端，透過私有 IP 轉發流量給 Web App。

2. Web App 與 ACA 的對比

特性Azure Container Apps (ACA)Azure App Service (Web App)
環境邊界建立在 Environment (環境) 層級建立在 App Service Plan 層級
IP 資源消耗較大 (需要一整個子網段)較小 (每個 App 整合僅佔用少數 IP)
VNet 整合難度建立環境時就要決定，事後難改隨時可以開啟或關閉 VNet 整合
預設網路依環境設定 (Internal/External)預設為 Public (需手動加 Private Endpoint)

3. Web App 同樣會遇到 Public IP 的問題嗎？

是的，而且更具迷惑性。

  1. 公用輸出 IP (Outbound IP)：即便你沒設定 VNet 整合，Web App 也有幾組固定的公用出口 IP。如果你的後端資料庫（例如在地端或其他雲端）有白名單限制，你需要把這幾組 IP 加進去。
  2. 資安審核的挑戰：Web App 的預設網址是 *.azurewebsites.net，這是對全網路公開的。資安審核通常不允許這個網址直接暴露。
    • 解法：開啟「存取限制 (Access Restrictions)」，只允許 App Gateway 的 IP 存取；或者直接關閉公網存取，改用 Private Endpoint。

4. 總結：Web App 還是 ACA？

如果你已經決定要用 App Gateway + WAF 來過審核：

  • 選 Web App 的理由：你只需要運行單一 Web 程式，不想要管理複雜的容器環境，且希望網路設定更彈性（可以隨時插拔 VNet）。
  • 選 ACA 的理由：你有複數個小服務（Microservices）要互相溝通，或者你的程式本來就是高度容器化的，ACA 的自動擴展（KEDA）比 Web App 更強大且便宜（支援縮減至 0 份複本）。

您目前的選擇考量

您提到 Web App 是因為覺得 ACA 的網路設定太複雜嗎？

Web App 在設定 Private Endpoint + App Gateway 時，雖然步驟多，但每一層的邏輯比 ACA 的 Environment 稍微透明一點。

您是否需要將 多個 Web App 同時掛在同一個 App Gateway 下來省錢？（這在 Web App 也是完全可行的）

以不需要分析log 與防火牆的小系統來看, web app 直接存取 vnet 裡的資源, 是否有資安上的風險?

在「不需要通過嚴格資安審核」且「不需分析 Log」的前提下，讓 Web App 直接存取 VNet 資源是常見的做法。但從純粹的資安角度來看，「風險」依然存在，只是嚴重程度取決於你的配置方式。

以下從三個關鍵面向分析可能的風險：

1. 「流出 (Outbound)」的風險：VNet 整合

當你開啟 VNet Integration 讓 Web App 存取內網（如 SQL 或 VM）時：

  • 單向透明度：預設情況下，這是單向的。Web App 可以看到 VNet 內部，但 VNet 內部的機器無法主動連回 Web App。這部分風險較低。
  • 橫向移動 (Lateral Movement)：這是最大的潛在風險。如果你的 Web App 程式碼有漏洞（例如被植入 WebShell），攻擊者可以利用這個 Web App 作為「跳板」，攻擊你 VNet 內部的其他資源。
    • 解決方案：在 VNet 的子網上設定 網路安全性組群 (NSG)，嚴格限制 Web App 只能存取特定的 IP 和 Port（例如只允許連線到資料庫的 1433 Port）。

2. 「流入 (Inbound)」的風險：公網入口

即便 Web App 正在存取內網，它預設的 *.azurewebsites.net 依然是在公網上公開的。

  • 暴露於自動掃描：全球的黑客機器人每天都在掃描 Azure 的公用網域名稱。如果你的 Web App 沒有做任何存取限制，你的程式碼漏洞（如未經授權的 API）就直接暴露在危險中。
  • 繞過內網防護：如果你認為「反正我的資料庫在內網很安全」，但 Web App 卻是公開的且有 SQL Injection 漏洞，攻擊者依然可以透過 Web App 偷走內網資料庫的資料。

3. Web App vs. ACA 在此情境下的安全差異

如果你使用 ACA (External) 或 Web App (預設)：

比較項目Web App (直接存取 VNet)ACA (External 模式)
預設防護只有基礎 DDoS 防護只有基礎 DDoS 防護
隔離性較弱，多租戶環境共享較強，環境有獨立邊界
存取控制需要手動設定 Access Restrictions需要手動設定 IP Restrictions

4. 關鍵安全風險檢查清單 (即使是小系統)

如果你不打算用 App Gateway/WAF，建議至少做到以下幾點，以規避基本風險：

  1. IP 存取限制 (Access Restrictions)：
    • 如果這個系統只是內部同仁使用，請在 Web App 的「網路」設定中，加入公司外部 IP 的白名單，封鎖其他所有國家的連線。
  2. 停用 SCM (Kudu) 介面公網存取：
    • Web App 有個管理後台（*.scm.azurewebsites.net），這通常是攻擊目標。建議將其設定為僅限特定 IP 存取。
  3. 使用 Managed Identity (受管理識別碼)：
    • 絕對不要把資料庫帳號密碼寫在 Web App 的設定檔中。使用 Managed Identity 讓 Web App 存取 SQL 或 Key Vault，這樣就算 Web App 被攻破，攻擊者也拿不到明文密碼。
  4. NSG 限制：
    • 在 Web App 整合的那個子網（Subnet）掛上 NSG，限制它「只能」往哪裡跑。

總結建議

對於「小系統」來說，最大的風險通常不是來自網路架構，而是來自「公開的 Ingress (入口)」。

  • 最低限度做法：使用 Web App + VNet Integration，但務必在 Web App 設定中開啟 Access Restrictions (存取限制)，只允許特定 IP 進入。
  • 如果不做 IP 限制：那就像是把內網資料庫的鑰匙插在門口，只鎖了一層薄薄的紗窗。

你目前的這個小系統，使用者是「一般大眾」還是「公司內部員工」？如果是內部員工，透過 IP 限制就能解決 90% 的安全顧慮。

使用者是「一般大眾」

既然使用者是 「一般大眾」，這意味著你無法透過 IP 白名單（Access Restrictions）來限制連線，你的 Web App 必須完全暴露在網際網路上。

在這種情況下，即便不使用 WAF，你依然面臨以下兩個主要的資安風險，以及相對應的低成本防護建議：

1. 核心風險：內網變「肉墊」

當 Web App 同時擁有 「公網入口」 且 「整合內網 (VNet)」 時，它就成了內網最脆弱的邊界。

  • 風險情境：如果你的程式碼存在上傳漏洞或遠端執行漏洞（RCE），駭客攻入 Web App 後，因為該 Web App 已整合進 VNet，駭客可以像進到你家客廳一樣，直接掃描並攻擊你家臥室（內網裡的資料庫、其他 VM、或是內部 API）。
  • 如何防範（不花大錢）：
    • 實施 NSG 隔離（關鍵！）：在 Web App 整合的 Subnet 上設定 網路安全性組群 (NSG)。
    • 規則設定：禁止該 Subnet 存取 VNet 內的所有 IP，僅排除必要的資料庫 IP 與 Port。
    • 這能確保萬一 Web App 被駭，駭客也無法在你的內網橫向移動。

2. 公共存取風險：資源耗盡與攻擊

因為對象是「一般大眾」，你無法預測流量來源。

  • 風險情境：
    1. DDoS/暴力破解：雖然 Azure 有基本 DDoS 防護，但它不防範應用層（L7）的攻擊，例如頻繁刷 API 導致你的 Web App 算力耗盡，產生高額費用。
    2. SQL 注入 (SQLi)：沒有 WAF 幫你過濾 SQL 指令，你必須 100% 依賴工程師的程式碼寫得夠安全（例如使用參數化查詢）。
  • 如何防範（不花大錢）：
    • API Throttling (速率限制)：在程式碼層級或使用 Azure API Management (Consumption Tier) 來限制單一 IP 的請求頻率。
    • Managed Identity：確保 Web App 存取資料庫時不使用帳密，而是使用 Identity 認證，防止連線字串外洩。

3. 建議的「最小可行性」安全架構

如果你決定暫時不買 App Gateway (WAF)，建議採取以下架構來平衡成本與安全：

  1. Web App + VNet Integration：用於存取內網。
  2. 強制 HTTPS 轉向：在 Azure 入口設定中開啟「僅限 HTTPS」。
  3. 啟用最低 TLS 版本：限制為 TLS 1.2 以上。
  4. 子網 NSG：嚴格限制 Web App 只能往哪跑。
  5. Azure Front Door (Standard) (可選)：
    • 雖然它要錢（約 $35 USD/月），但它比 App Gateway 便宜很多。
    • 它能提供基礎的邊界防護與全球加速，適合面對「一般大眾」的場景。

4. 總結：資安與風險的權衡

「如果不分析 Log 也沒有 WAF，安全嗎？」

老實說：這是不透明的安全。 當攻擊發生時，你既不會收到警報，事後也無從查起。對於面對一般大眾的系統，這存在一定的「運氣成分」。

我的具體建議：

既然對象是大眾，且要存取內網資源，請務必至少設定好 NSG (網路安全性組群)。這不需要額外付費，卻是防止小災難變成大浩劫（資料庫被搬空）的最重要防線。

既然這個系統要面對大眾，你是否有預期大約會有多少同時在線人數？這會影響到你是否需要考慮基本的負載平衡或防護層級。

對於 400 人 規模的系統（假設是同時在線或每日活躍用戶），這屬於一個「中小型但已有基本規模」的應用。在 Azure 上，這是一個非常尷尬的平衡點：流量大到需要考慮穩定性，但可能還沒大到想支付每個月台幣 5,000 元以上的 App Gateway 費用。

針對這個規模，且使用者是「一般大眾」，我為你整理了三種不使用 App Gateway 的安全加固策略：

1. 網路層級的「斷開」 (Zero Cost)

既然 Web App 必須開給大眾，而你又需要連回 VNet 存取資料庫，最危險的就是 Web App 被當成進入內網的跳板。

  • 實作 NSG (網路安全性組群)：在 Web App 整合的子網上，設定一條「拒絕所有」的規則，然後只針對資料庫的 IP 開放特定的 Port。
  • 優點：即使程式碼被駭，駭客也無法掃描你 VNet 裡的其他 VM 或資源。

2. 入口層級的「隱身」 (Low Cost)

如果你不想花大錢買 App Gateway，但又擔心 *.azurewebsites.net 被人掃描，可以考慮 Azure Front Door (Standard)。

  • 費用：大約 $35 USD/月 (約 NT$ 1,100)。
  • 做法：
    1. 流量先經過 Front Door。
    2. 在 Web App 的 Access Restrictions 中，設定只允許來自 Front Door 的標籤（Service Tag: AzureFrontDoor.Backend）進入。
  • 好處：這能隱藏你的 Web App 原始位址，並提供基礎的 L3/L4 DDoS 防護。對於 400 人的規模，這比 App Gateway 划算得多。

3. 程式碼與驗證層級的「鎖頭」 (Zero Cost)

面對大眾時，最容易被攻擊的是 API 接口。

  • 驗證機制 (Easy Auth)：如果這 400 人需要登入，直接利用 Azure App Service 內建的 Authentication (Entra ID / Google / Facebook)。這能確保未經授權的人連你的程式碼邏輯都碰不到。
  • HTTPS 封閉循環：確保 HTTPS Only 是開啟的，且停用所有不安全的連線。

4. 給你的最終建議架構

對於 400 人規模且要過資安基本門檻的系統，建議採用：

層級推薦配置成本
入口Web App (Public) + Access Restrictions$0
防護Azure Front Door (Standard) (視預算而定)~$35 USD/月
內網存取VNet Integration + NSG (限制輸出流量)$0
認證Managed Identity (存取 SQL 不用密碼)$0

為什麼這能過「小規模」的審核？

雖然你沒有專業的 WAF 分析 Log，但你做到了 「最小權限原則 (Least Privilege)」：

  1. 外網進不去內網 (由 NSG 擋掉)。
  2. Web App 拿不到資料庫帳密 (由 Managed Identity 處理)。
  3. 入口流量有基本過濾 (由 Front Door 或 Access Restrictions 處理)。

總結： 400 人規模建議先用 Web App + VNet Integration + NSG 撐住，並將省下來的錢花在 Azure SQL 的備份與加密上。

你目前資料庫是使用 Azure SQL Database 嗎？如果是的話，別忘了開啟 Microsoft Defender for SQL，它能幫你偵測 SQL Injection，某種程度上能彌補沒有 WAF 的缺憾。

針對這 400 人的存取，你有打算讓他們使用特定的登入方式嗎？

與 vnet 內網裡的 portal 系統 進行 oauth, 驗證使用者身份

對於這 400 人要與 VNet 內網裡的 Portal 系統進行 OAuth 驗證，這是非常關鍵的步驟。因為你的對象是「一般大眾」，但驗證對象（Portal 系統）卻在「內網」，這會涉及一個核心矛盾：外網的使用者如何與內網的認證服務溝通？

在不使用 App Gateway 的前提下，以下是針對此場景的專業建議架構：

1. 核心邏輯：區分「認證流量」與「資料流量」

你必須確保 OAuth 的流量能安全地穿透外網到達內網。這裡有兩種實踐方式：

方案 A：Web App 擔任「代理人」 (最推薦)

這是最安全的做法，不直接暴露內網 Portal。

  1. 流程：一般大眾訪問公網 Web App -> Web App 發現未登入 -> Web App 透過 VNet Integration 在後端與內網 Portal 通訊。
  2. 關鍵點：Web App 設定為 Confidential Client。所有的 OAuth 交換（Client Secret, Code Exchange）都在後端（內網）完成，不經過使用者的瀏覽器直接接觸內網。
  3. 安全性：使用者的瀏覽器只會看到公網 Web App，永遠看不到內網 Portal 的 IP 或網址。

方案 B：使用 Private Endpoint + 轉發 (需考量連通性)

如果你的 OAuth 流程（例如 Authorization Code Flow）需要使用者的瀏覽器直接「重新導向 (Redirect)」到 Portal 的網址：

  1. 挑戰：使用者的瀏覽器在公網，無法解析或連線到 10.x.x.x 這種內網位址。
  2. 解法：你必須在 Web App 上設定 Reverse Proxy (反向代理)，或者在前端掛一個可以處理轉發的服務（如 Azure Front Door），將特定路徑（如 /login）轉導進 VNet。

2. 資安防護建議：如何保護內網 Portal？

既然要進行身份驗證，Portal 系統就是最高機密。即使是小系統，也建議做到以下防範：

  • 實施 NSG 嚴格限縮：
    • 內網 Portal 系統所在的子網，其 NSG 必須設定：僅允許來自 Web App 子網的流量。
    • 禁止所有其他內網機器或外網 IP 直接存取 Portal。
  • 使用受管理識別碼 (Managed Identity)：
    • 讓 Web App 存取 Portal 時，不需要在 App 設定中儲存 API Key 或密碼。

3. 針對 400 人規模的建議實作：Easy Auth

如果你的內網 Portal 支援 OpenID Connect (OIDC)，強烈建議使用 Azure App Service 內建的 Authentication (Easy Auth)：

  1. 設定：在 Web App 的「驗證」頁面中，新增一個「自訂 OpenID Connect 供應商」。
  2. 中繼設定：由於供應商（Portal）在內網，請在 Web App 設定中開啟 vnetRouteAll: true。
  3. 優點：你不需要寫任何驗證程式碼，Azure 平台會自動幫你處理與內網 Portal 的握手（Handshake），並確保未登入的人連 Web App 的頁面都進不去。

4. 潛在風險提示

  • DNS 解析問題：Web App 能否找到內網 Portal？你可能需要設定 Azure Private DNS Zone，並將其連結到 VNet，這樣 Web App 才能解析出 Portal 的私有網址（如 portal.internal）。
  • 回傳網址 (Redirect URI)：在 OAuth 註冊中，Redirect URI 必須是公網 Web App 的位址（如 https://your-app.azurewebsites.net/.auth/login/custom/callback），否則使用者的瀏覽器跳轉時會找不到路。

總結架構建議

針對 400 人的一般大眾系統：

  1. Web App：作為唯一公網入口。
  2. VNet Integration：導引流量進入內網。
  3. NSG：封閉 Portal，僅限 Web App 存取。
  4. Easy Auth (OIDC)：簡化程式碼並強化安全性。

這套架構在不增加 App Gateway 成本的情況下，提供了極高的安全性，且足以應付 400 人的流量。

你目前內網的 Portal 系統是用什麼技術開發的（例如：IdentityServer, Keycloak, 或是自研 API）？這會決定我們如何配置 OIDC 的中繼資料。

Related Posts

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *