在現代的網路架構中，主要透過以下兩種技術來達成：

1. 使用主機名稱識別（Host Header）

這是最常見的做法。當多個網站共享同一個 IP 時，伺服器會根據瀏覽器傳送的 HTTP Request 中的 Host 欄位來判斷要由哪一個 App 處理。

• 用戶輸入 A.com，請求送到 IP 1.2.3.4。
• 伺服器看見要求的主機名稱是 A.com，於是把流量導向 Web App A。
• 另一個用戶輸入 B.com，同樣送到 IP 1.2.3.4。
• 伺服器看見要求的主機名稱是 B.com，則導向 Web App B。

這也是為什麼在 Azure App Service 或應用程式閘道上，你需要註冊自訂網域的原因，這樣伺服器才知道這個網域是歸屬於哪一個服務。

2. 使用反向代理（Reverse Proxy）

像你提到的 Azure 應用程式閘道（Application Gateway）就是一個強大的反向代理伺服器。

一個應用程式閘道通常只有一個公用 IP，但它可以根據不同的規則來分流：

• 根據網域分流：例如 shop.example.com 導向後端的「購物車服務」，而 blog.example.com 導向「部落格服務」。
• 根據路徑分流：同一個網域下，[example.com/api](https://example.com/api) 導向「後端 API 服務」，而 [example.com/static](https://example.com/static) 導向「靜態網頁服務」。

總結

一個 IP 確實可以對應多個 Web App。這不僅節省了公用 IP 的資源（IP 資源很貴且有限），也讓系統架構更具靈活性。

你目前正在設定的應用程式閘道，正是利用這種機制來管理多個後端服務，只要確保 DNS 正確指向該 IP，並在 Azure 上完成對應的網域註冊即可。

有多個網域分流, app gateway how to setup

在 Azure 應用程式閘道（Application Gateway）中處理多個網域分流，核心機制是使用 多站台（Multi-site）接聽程式。

這就像是在同一個門牌號碼（IP）下，根據信封上的收件人姓名（網域）把信件分派給不同的辦公室。

以下是具體的設定步驟：

1. 建立後端集區（Backend Pools）

首先，你要為不同的 App 建立各自的集區。

• 建立後端集區 A：加入第一個 Web App 的位址。
• 建立後端集區 B：加入第二個 Web App 的位址。

2. 設定接聽程式（Listeners）

這是最關鍵的一步。你需要為每個網域建立一個獨立的接聽程式。

• 接聽程式 A：
  • 關聯的前端 IP：選擇你的公用 IP。
  • 接聽程式類型：選擇多站台（Multi-site）。
  • 主機名稱：輸入第一個網域（例如 app1.example.com）。
• 接聽程式 B：
  • 接聽程式類型：選擇多站台（Multi-site）。
  • 主機名稱：輸入第二個網域（例如 app2.example.com）。

3. 設定後端設定（Backend Settings）

針對多租用戶服務（如 App Service），這裡有兩個重點：

• 主機名稱覆寫：根據 Azure 的建議，如果你已經在後端 App 註冊了自訂網域，請選擇從後端目標選取主機名稱，或者手動輸入對應的網域。
• 通訊協定：通常設定為 HTTPS (Port 443)。

4. 建立路由規則（Routing Rules）

最後，把「接聽程式」與「後端集區」串聯起來。

• 規則 A：當接聽程式 A 收到請求時，將流量導向後端集區 A。
• 規則 B：當接聽程式 B 收到請求時，將流量導向後端集區 B。

常見問題排查

如果設定後無法連線，請檢查以下幾點：

• DNS 設定：確認 app1.example.com 與 app2.example.com 的 CNAME 或 A 紀錄都指向應用程式閘道的 IP。
• 後端註冊：在 Azure App Service 的自訂網域設定中，必須已經新增了該網域，否則 App Service 會因為無法識別 Host Header 而回傳 404 錯誤。
• 憑證問題：如果你使用 HTTPS，接聽程式必須上傳對應網域的 SSL 憑證。如果是多網域，可以使用萬用字元憑證（Wildcard Certificate）或針對每個接聽程式上傳專屬憑證。

同一個 port 只能有一個Listeners?

在 Azure 應用程式閘道中，同一個 Port（埠號）是可以有多個接聽程式（Listeners）的，但前提是這些接聽程式必須是 多站台（Multi-site） 類型。

如果你的設計是想在同一個 IP 的 Port 80 或 443 下跑多個網站，這是完全沒問題的。

以下是運作的核心規則：

1. 基本規則：唯一性

應用程式閘道判斷要把流量交給哪個接聽程式，是根據 IP + Port + 主機名稱（Host Name） 的組合來決定的。

• 基本型（Basic）接聽程式：會「佔據」該 Port 的所有流量。如果你在 Port 443 設了一個基本型接聽程式，你就不能再針對同一個 Port 建立其他的接聽程式。
• 多站台（Multi-site）接聽程式：允許多個接聽程式共享同一個 Port。

2. 如何在同一個 Port 設定多個接聽程式

當你需要多個網域（例如 a.com 和 b.com）都使用 Port 443 時，你的設定會長這樣：

3. 系統如何判斷流量去哪？

當一個請求進來時，應用程式閘道會檢查 HTTP 標頭中的 Host 欄位：

1. 如果連線請求的網域是 a.com，它會精準比對到 Listener-A。
2. 如果連線請求的網域是 b.com，它會精準比對到 Listener-B。
3. 如果 Host 欄位跟所有接聽程式都對不起來，該連線就會失敗（回傳錯誤），除非你有設定一個「預設」的路由規則。

4. 注意事項

• SSL 憑證：如果你在同一個 Port 跑多個 HTTPS 站台，應用程式閘道會使用 SNI（伺服器名稱指示） 技術。這意味著每個接聽程式都可以綁定各自對應網域的 SSL 憑證。
• 避免衝突：你不能在同一個 Port 同時存在一個「基本型」接聽程式與多個「多站台」接聽程式，系統會判定這會產生衝突。

簡單來說： 只要你把接聽程式類型選為 多站台（Multi-site） 並填入正確的 主機名稱，你就可以在同一個 Port 上掛載非常多個不同的網站。

Error log

無法將設定變更儲存至應用程式閘道 'agw-stg-jpe-001'。錯誤: Application Gateway listener-policyhub-stg 和 appGatewayHttpsListener 的兩個 Http Listener 使用了相同的 Frontend Port

這個錯誤訊息非常明確，問題在於你的應用程式閘道中發生了 設定衝突。

簡單來說，系統發現你有兩個接聽程式（Listeners）在搶奪相同的「通訊窗口」。

衝突原因分析

根據錯誤訊息，以下三個關鍵要素在兩個接聽程式之間完全重複了：

1. Frontend Port：都是 port_443。
2. Frontend IP：都是 appGatewayFrontendIP。
3. HostName：都是 policyhub.test.com.tw。

在 Azure 應用程式閘道中，這三個元素的組合必須是 唯一 的。如果 HostName 完全一樣，閘道器就無法判斷當流量進來時，到底該交給 listener-hub-stg 還是 appGatewayHttpsListener 來處理。

解決方案

請依照你的實際需求，選擇以下其中一種調整方式：

方案一：刪除多餘或舊的接聽程式

如果你發現 appGatewayHttpsListener 是之前測試留下的舊設定，或者它原本就應該被新的 listener-hub-stg 取代，請直接刪除其中一個。

方案二：合併路由規則（最推薦）

如果你希望這個網域 hub.test.com.tw 對應到某個後端，你只需要 一個 接聽程式。

1. 保留其中一個接聽程式（例如 listener-hub-stg）。
2. 確保該接聽程式關聯到正確的 要求路由規則（Request Routing Rule）。
3. 在路由規則中定義流量該去哪個 後端集區（Backend Pool）。

方案三：區分主機名稱（Host Name）

如果你原本的意圖是要讓兩個不同的網域共用 443 Port，請檢查這兩個接聽程式的 HostName 設定：

• 將 listener-hub-stg 設定為 hub.test.com.tw。
• 將另一個接聽程式設定為另一個網域，例如 other.test.com.tw。
• 注意：不可以兩個都留空白（基本型），也不可以兩個都填入相同的網域。

操作建議步驟

1. 進入 Azure 入口網站，開啟 agw-stg-jpe-001。
2. 點選左側選單的 接聽程式 (Listeners)。
3. 找到 appGatewayHttpsListener 和 listener-policyhub-stg。
4. 檢查這兩個接聽程式是否都設定了相同的網域。如果是，請決定要保留哪一個，並將另一個 刪除 或 更改主機名稱。
5. 儲存變更後，再次嘗試部署。

通常這種情況發生在「手動新增新的接聽程式」時，忘記舊有的接聽程式已經佔用了該網域的 443 Port。

Error:

502 Bad Gateway
Microsoft-Azure-Application-Gateway/v2

遇到這個錯誤代表你的 Application Gateway 已經收到請求，但它在嘗試與後端伺服器（如 App Service 或 VM）溝通時失敗了。

既然你正在進行多租用戶服務（App Service）的設定，這通常與「主機名稱不一致」或「健康狀態探查（Health Probe）失敗」有關。請依照以下步驟排查：

1. 檢查後端健康狀態 (最直接的方法)

在 Azure 入口網站中，進入您的 Application Gateway：

• 點選左側選單的 後端狀況 (Backend Health)。
• 查看您的後端集區狀態。如果是 Unhealthy，右側通常會顯示具體的錯誤訊息。

2. 常見原因：主機名稱（Host Name）不匹配

多租用戶服務（如 App Service）非常依賴 HTTP 要求中的 Host 標頭。

• 問題點：如果你的 Gateway 傳送要求到後端時，使用的是 hub.test.com.tw，但後端的 App Service 沒有註冊這個網域，App Service 會拒絕連線，導致 502。
• 解決方案：
  1. 確認 App Service 的 自訂網域 (Custom domains) 中已經新增了 hub.test.com.tw。
  2. 在 Application Gateway 的 後端設定 (Backend Settings) 中，確認是否開啟了 覆寫後端主機名稱。
  3. 根據先前的建議，應選擇 從後端目標選取主機名稱 或手動輸入該 App 的預設網域（如 xxxx.azurewebsites.net）。

3. 健康狀態探查 (Health Probe) 失敗

如果後端設定要求使用 HTTPS，但探查的目標不正確，閘道器會認為後端已掛掉，進而回傳 502。

• 檢查點：進入 健康狀態探查 (Health Probes) 設定。
• 建議：針對 App Service，勾選 從後端設定中選取主機名稱。這能確保探查時傳送的主機名稱與後端設定一致。

4. SSL 憑證與 HTTPS 握手失敗

如果你在 Application Gateway 與後端 App Service 之間使用 HTTPS 連線：

• 確認後端 App Service 能夠處理 HTTPS。
• 如果使用自簽憑證，必須在 Application Gateway 中上傳該信任的根憑證（.cer 檔）。

5. 後端伺服器逾時

如果你的 Web App 處理請求的時間太長（例如正在進行大型資料庫搬遷或運算），Application Gateway 會因為超過預設的 要求逾時 (Request timeout) 時間而主動中斷連線。

• 檢查點：進入 後端設定，嘗試增加 要求逾時 的秒數（預設通常是 20 秒，可以試著改為 60 秒或更高）。

快速排查建議

如果你剛處理完前面的 Listeners 衝突問題，請先確認：

1. 路由規則 是否正確連結到正確的 後端集區。
2. 後端集區 內的位址（FQDN）是否正確無誤。

只要 後端狀況 (Backend Health) 顯示為 Healthy，502 錯誤通常就會消失。

微軟現在有個超讚的設定，可以把 Azure SQL 資料庫變成 僅限 Microsoft Entra ID 驗證。這聽起來很專業，其實就是把傳統的帳號密碼大門關起來，規定大家只能用正式的微軟雲端帳號登入。

停用本地驗證方法並僅允許 Azure Active Directory 驗證，可確保只有 Azure Active Directory 識別身分才能存取 Azure SQL Database，以提升安全性。

這樣做有什麼好處呢？

• 第一個好處是統一管理。所有的權限都歸雲端帳號管，不用在資料庫裡建一堆帳號。
• 再來是安全性大升級！因為雲端帳號可以開啟手機簡訊或 APP 的多重驗證，駭客就算偷到密碼也進不來！

操作起來其實很簡單，不論你是習慣打指令還是用滑鼠點網頁都能搞定。

如果你是用圖形網頁操作，只要在建立資料庫的時候，去 身份驗證 分頁點一下 僅限 Microsoft Entra 驗證。

接著搜尋你自己的帳號，把它設成 管理員 就大功告成。

設定完記得測試看看，這時候你會發現原本的 SQL 舊帳號已經被 封鎖 沒辦法用了，一定要改用微軟帳號才能進去。

我覺得這功能真的超方便！以前要記一堆資料庫密碼真的很痛苦，現在只要保護好一個主帳號就好。

把複雜的事情變簡單，而且還更安全，這絕對是現代開發者必學的懶人自保術呀！

既然程式是跑在 Docker 裡，沒辦法手動點選視窗，那我們就要幫程式申請一張「專屬通行證」，也就是 Client Secret 。

這張通行證要在 Azure 入口網站（Azure Portal）裡面產生，步驟其實很簡單，就像是在幫你的程式辦身分證一樣：

第一步：註冊應用程式

首先去 Azure Portal 搜尋「應用程式註冊」（App Registrations）:
https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade

點進去後選「新註冊」。幫你的程式取個名字，然後按註冊就好。這時候你會看到一個「應用程式 (用戶端) 識別碼」，這就是連線字串裡的 Client ID 。

第二步：產生秘密金鑰

在左邊選單找到「憑證與密碼」，點進去後選「用戶端密碼」，接著按「新用戶端密碼」。你可以設定這組密碼多久會過期。

第三步：立刻存檔

按下的那一刻，畫面會出現一串長長的字，那就是 Client Secret。記得這時候一定要趕快複製存起來！因為一旦離開這個畫面，系統就會把它遮起來，你再也看不到了，只能重新再產生一個 。

最後別忘了，還要回到你的 SQL Server 裡面，把這個應用程式的名字加進去並給它權限，你的程式才能順利進門。

我覺得這種做法雖然多了一點步驟，但把權限跟程式碼分開管理，程式碼裡不再放死板板的密碼，而是改用這種可以隨時更換、受雲端監控的通行證。

這樣一來，不只開發起來更優雅，安全等級也是直接拉滿，這才是專業開發者的懶人自保術呀

你知道除了手動複製，其實還有更安全的方法來管理這些秘密金鑰嗎？

既然都聊到這了，那一定要跟你分享進階版的絕招！

雖然把 Client Secret 存在 Docker 的環境變數裡已經比以前進步，但對追求極致安全的工程師來說，這還不夠。因為金鑰還是存在某個地方，萬一主機被攻破，祕密還是會外流。

這時候，我們可以用 Azure 提供的一種超神科技，叫做受控識別（Managed Identity）。

這概念就像是你不用再幫程式辦身分證了，而是直接讓 Azure 認得這台 虛擬機 或 容器 服務本身。當程式要去連資料庫時，它會直接跟 Azure 說：「嘿，我是你家養的容器，讓我進去吧！」

簡單來說，更安全的作法有兩種：

一、使用受控識別（最推薦）

這就像是 刷臉認證。你只要在 Azure 平台上把你的服務（例如 Azure Container Instances）開啟 受控識別 功能，並在 SQL 資料庫裡授權給它。

這時候 Python 的連線字串就會變得超乾淨，完全不需要 UID 也不需要 PWD：

driver = {ODBC Driver 18 for SQL Server}
connection_string = (
　f"DRIVER={driver};"
　f"SERVER={server},{port};"
　f"DATABASE={database};"
　"Authentication=ActiveDirectoryMSI;"
　"Encrypt=yes;"
　"TrustServerCertificate=no;"
　"Connection Timeout=30;"
)

這真的是 懶人包 的極致，程式碼裡完全沒有任何祕密，安全性滿分！

二、使用 Azure Key Vault

如果你還是需要用 Client Secret，可以把它藏在 雲端保險箱（Key Vault）裡面。

程式執行時才去保險箱領鑰匙，而不是直接把鑰匙貼在門口。這樣就算別人看到你的程式碼或 Docker 設定，也拿不到真正的密碼。

範例程式碼：

driver = {ODBC Driver 18 for SQL Server}
connection_string = (
　f"DRIVER={driver};"
　f"SERVER={server},{port};"
　f"DATABASE={database};"
　f"UID={client_id};"
　f"PWD={client_secret};"
　"Authentication=ActiveDirectoryServicePrincipal;"
　"Encrypt=yes;"
　"TrustServerCertificate=no;"
　"Connection Timeout=30;"
)

• 關鍵改版：我們把原本放「帳號」的地方換成 應用程式 ID（UID），把原本放「密碼」的地方換成 秘密金鑰（PWD）。
• 認證模式：這行 Authentication=ActiveDirectoryServicePrincipal 是最關鍵的！它就像是跟資料庫打暗號，說：「嘿！我是用程式身分來敲門的，不是真人喔！」
• 安全提醒：連線字串裡的 Encrypt=yes 建議要留著，這樣資料在傳輸過程中才會被加密，就像是幫資料坐上防彈運鈔車一樣安全。

我的小小建議：

我覺得最高境界，就是根本不要持有秘密。

當我們用受控識別（Managed Identity）的時候，身為開發者的我們連密碼長什麼樣子都不知道。不用擔心密碼過期、不用定期更換，更不用怕不小心把密碼推到 GitHub 上面去。

這種把 安全性 融入到環境架構裡的作法，不只讓開發過程變得超清爽，心裡也會覺得非常踏實，這才是真正的優雅開發呀！

這種 不用記密碼 的生活，是不是聽起來就很吸引人呢？

請注意，ODBC Driver 18 預設啟用了加密連線（Encrypt=yes），這與舊版本（v17）不同，連線時可能需要調整連線字串。

第一步：安裝 Microsoft ODBC Driver 18

請根據你的 Ubuntu 版本執行以下指令（適用於 20.04, 22.04, 24.04）：

導入 Microsoft 公鑰與來源清單

# 取得 Ubuntu 版本號 (如 22.04)
UBUNTU_VERSION=$(lsb_release -rs)

# 下載 Microsoft GPG 金鑰
curl https://packages.microsoft.com/keys/microsoft.asc | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

# 加入 Microsoft Ubuntu 套件庫
curl https://packages.microsoft.com/config/ubuntu/$UBUNTU_VERSION/prod.list | sudo tee /etc/apt/sources.list.d/mssql-release.list

安裝驅動程式與開發標頭檔

sudo apt-get update

ACCEPT_EULA=Y 會自動同意授權合約

sudo ACCEPT_EULA=Y apt-get install -y msodbcsql18 unixodbc-dev

（選填）安裝 SQL Server 命令列工具 (sqlcmd/bcp)

sudo ACCEPT_EULA=Y apt-get install -y mssql-tools18
echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bashrc
source ~/.bashrc

第二步：安裝 Python 套件

在你的 Python 虛擬環境中安裝 pyodbc：

pip install pyodbc

第三步：Python 程式碼範例與注意事項

由於 ODBC 18 預設強制加密，如果你的 Azure SQL 伺服器證書不是由受信任的授權單位簽發的（或者你在本地測試），你可能需要在連線字串中加入 TrustServerCertificate=yes。

import pyodbc

# 請替換成你的 Azure SQL 資訊
server = 'your_server.database.windows.net'
database = 'your_db'
username = 'your_username'
password = 'your_password'

# 注意 Driver 名稱必須精確匹配：{ODBC Driver 18 for SQL Server}
conn_str = (
    f"DRIVER={{ODBC Driver 18 for SQL Server}};"
    f"SERVER={server};"
    f"DATABASE={database};"
    f"UID={username};"
    f"PWD={password};"
    "Encrypt=yes;"
    "TrustServerCertificate=no;" # 若連線失敗可改為 yes 測試，但在正式環境建議保持 no
    "Connection Timeout=30;"
)

try:
    conn = pyodbc.connect(conn_str)
    cursor = conn.cursor()
    cursor.execute("SELECT @@version;")
    row = cursor.fetchone()
    print(f"Connected! SQL Server Version: {row[0]}")
except Exception as e:
    print(f"Error: {e}")

常見問題排除

• 找不到驅動程式：執行 odbcinst -q -d。你應該會看到 [ODBC Driver 18 for SQL Server]。如果沒有，請確認第一步安裝是否成功。
• SSL/TLS 錯誤：Azure SQL 要求 TLS 1.2 以上版本。Ubuntu 20.04+ 通常預設支援，但如果你在連線時遇到證書驗證錯誤，請檢查 Azure SQL 的防火牆設定，並確認 TrustServerCertificate 的設定。
• 權限問題：在 Azure VM 上，確保網路安全性群組 (NSG) 已允許 1433 埠通訊，且 Azure SQL 的防火牆已將該 VM 的公用 IP 加入白名單。

Error

W: OpenPGP signature verification failed: https://packages.microsoft.com/ubuntu/26.04/prod resolute InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EE4D7792F748182B
E: The repository 'https://packages.microsoft.com/ubuntu/26.04/prod resolute InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

看來在 Ubuntu 24.04 (Noble) 上，系統沒能正確識別或找到你剛才匯入的 Microsoft GPG 金鑰。這通常是因為金鑰存放路徑與來源清單（.list）中定義的路徑不一致導致的。

從你的錯誤訊息看，noble InRelease 找不到金鑰 EB3E94ADBE1229CF。

解決方案

請按照以下步驟重新匯入金鑰並修正路徑：

1. 下載並轉換金鑰格式

Ubuntu 24.04 偏好使用 .gpg 格式存放在 /usr/share/keyrings/。

# 下載並將金鑰轉換為 gpg 格式存放到指定位置
curl -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /usr/share/keyrings/microsoft-prod.gpg > /dev/null

2. 更新來源清單 (Source List)

確保你的 mssql-release.list 指向的是正確的金鑰路徑（剛才建立的那個）：

echo "deb [arch=amd64,arm64,armhf signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/ubuntu/24.04/prod noble main" | sudo tee /etc/apt/sources.list.d/mssql-release.list

3. 再次執行安裝

現在更新索引，這一次應該不會報 GPG 錯誤了：

sudo apt-get update
sudo ACCEPT_EULA=Y apt-get install -y msodbcsql18 unixodbc-dev

為什麼會失敗？（小知識）

• NO_PUBKEY 錯誤：這表示 apt 下載了軟體清單，但因為沒有對應的「印章」（公鑰），它不敢相信這些檔案是 Microsoft 官方發布的，所以拒絕執行。
• Killed 訊息：我在你的 Log 看到一個 Killed。如果 apt-get update 過程中出現 Killed，通常是 RAM（記憶體）不足。如果你的 Azure VM 是 B1s 或 B1ls 等微型規格，建議先關閉一些佔用記憶體的程序，或暫時增加 Swap。
• Ubuntu 24.04 (Noble)：這是比較新的版本，Microsoft 的路徑配置有時會與舊版（使用 /etc/apt/trusted.gpg.d/）略有不同。

驗證安裝結果

安裝完成後，你可以執行這個指令確認驅動程式已經就緒：

odbcinst -q -d -n "ODBC Driver 18 for SQL Server"

如果出現驅動程式的路徑資訊，就代表你成功了！接著就可以繼續用 pip install pyodbc 進行 Python 開發。

要在 Ubuntu 終端機直接測試連線，我們通常會使用 sqlcmd (隨 mssql-tools18 安裝) 或者使用 isql (unixODBC 自帶工具)。

由於你安裝的是 ODBC Driver 18，請特別注意連線字串中的加密選項。

方法一：使用 isql 進行快速測試

isql 是 unixODBC 提供的工具，適合用來驗證驅動程式是否能正確與資料庫握手。

請在終端機輸入以下指令（將參數直接寫在連線字串中）：

# -v 代表 verbose (詳細輸出)，可以幫你判斷錯誤原因
# 注意：ODBC 18 預設強制加密，若伺服器憑證未經第三方認證，需加上 TrustServerCertificate=yes
isql -v -k "DRIVER={ODBC Driver 18 for SQL Server};SERVER=1.2.3.4,1433;DATABASE=YOUR_DB;UID=userid;PWD=userpwd;Encrypt=yes;TrustServerCertificate=yes"

• 如果成功，你會看到 Connected! 提示。
• 輸入 quit 即可結束連線。

方法二：使用 sqlcmd (Microsoft 官方工具)

如果你之前有安裝 mssql-tools18，這是最推薦的測試方式：

sqlcmd -S 1.2.3.4,1433 -d YOUR_DB -U userid -P 'userpwd' -C

• 參數 -C 代表 TrustServerCertificate（信任伺服器憑證）。
• 注意：如果密碼包含特殊字元，請用單引號 ' ' 包起來。

疑難排解：連線失敗的常見原因

1. Network Timeout (連線逾時)：
   • 檢查 Azure NSG：確保你的 Azure VM 出站規則 (Outbound) 允許 1433 埠。
   • 檢查目標伺服器：1.2.x.x 的 IP，請確認該伺服器防火牆是否有將你的 Azure VM 公用 IP 加入白名單。
2. SSL Provider 錯誤 (憑證問題)：
   • 這是 ODBC 18 最常見的問題。如果沒加 TrustServerCertificate=yes (或 isql 中的參數)，連線會因為無法驗證憑證而中斷。
3. Login Failed：
   • 請確認資料庫名稱 YOUR_DB 與帳密無誤。

Python 程式碼快速驗證

如果你已經進入了虛擬環境並安裝了 pyodbc，可以用這段代碼直接測試：

Python

import pyodbc

conn_str = (
    "DRIVER={ODBC Driver 18 for SQL Server};"
    "SERVER=1.2.3.4,1433;"
    "DATABASE=YOUR_DB;"
    "UID=userid;"
    "PWD=userpwd;"
    "Encrypt=yes;"
    "TrustServerCertificate=yes;"
)

try:
    with pyodbc.connect(conn_str, timeout=5) as conn:
        print("連線成功！")
        cursor = conn.cursor()
        cursor.execute("SELECT TOP 1 name FROM sys.databases")
        print(f"資料庫清單測試: {cursor.fetchone()}")
except Exception as e:
    print(f"連線失敗原因: {e}")

你的連線測試結果出現什麼錯誤訊息嗎？

這些內部資源通常是在公司防火牆後面的資料庫（例如 SQL Server、MySQL）或具備 TCP 連線能力的 HTTP 服務。

運作原理

混合式連線不要求你在防火牆上開啟任何對外的通訊埠（Inbound Port），也不需要建立複雜的 VPN 或 ExpressRoute。它的運作基礎是 Azure Relay。

當你安裝了混合式連線管理員（Hybrid Connection Manager, HCM）在內部網路的伺服器上後，HCM 會透過 443 埠（HTTPS/WebSockets）向 Azure 發起「對外」的連線。雲端的應用程式與內網的 HCM 之間會建立一條雙向的安全隧道，藉此傳輸資料。

選取與建立的區別

在 Azure 控制台看到的那兩段文字，分別代表不同的操作情境：

• 新增選取的混合式連線：如果你之前已經在同一個服務匯流排（Service Bus）命名空間中建立過連線，你可以直接從清單中挑選現有的定義，並套用到目前的應用程式。這適合多個 App 需要存取同一個後端資源時使用。
• 建立新混合式連線：這表示要從頭開始定義一個新的存取路徑。你需要填寫後端資源的主機名稱（如 db-server-01）以及對應的通訊埠（如 1433）。建立完成後，系統會提供一段金鑰，讓你安裝在內網的 HCM 程式使用，完成配對連線。

優點

跨平台：只要後端資源支援 TCP 協議（例如資料庫、網頁服務），基本上都能透過這種方式連通。

安全性高：不需要開啟防火牆進入點，大幅降低被攻擊的風險。

設定簡單：不需要變更網路架構或申請靜態 IP。

針對混合式連線管理員（HCM）與服務匯流排（Service Bus）命名空間，若結合 Microsoft 雲端導入框架（Cloud Adoption Framework, CAF）的規範與實務建議，可以從架構、命名、以及資源管理三個層面來理解。

資源與命名空間的關係

混合式連線本質上是建立在 Azure Relay 服務之上的功能。在設定時，系統會要求你選擇或建立一個服務匯流排（Service Bus）命名空間來存放這些連線實體。

• 隸屬關係：每一個混合式連線（Hybrid Connection）都必須隸屬於一個 Service Bus 命名空間。
• 延遲考量：CAF 建議將 Service Bus 命名空間部署在與你的 App Service（雲端應用程式）相同的 Azure 區域，以減少網路傳遞的延遲。

CAF 命名建議與規範

根據 CAF 的資源命名慣例，命名應具備可讀性與組織性，建議格式如下：

sb-<應用程式名稱>-<環境>-<地區>-<編號>

• sb (Service Bus Prefix)：資源類型的簡寫，Service Bus 命名空間通常使用 sb。
• 環境：例如 prod (正式)、dev (開發) 或 test (測試)。
• 地區：例如 tw (台灣) 或 hk (香港)。

範例： sb-hrsystem-prod-tw-01

這讓 MIS 或維運人員一看就知道這是用於 HR 系統、正式環境、位於台灣機房的服務匯流排。

混合式連線管理員 (HCM) 的部署建議

HCM 是安裝在內部網路伺服器上的代理程式（Agent），它是連線成功的關鍵。

• 高可用性 (High Availability)：CAF 建議在生產環境中，針對同一個混合式連線，應在不同的伺服器上安裝至少兩個 HCM 執行個體。Azure 會自動在這些活動狀態的執行個體之間進行負載平衡與故障轉移。
• 安全性 (Security)：
  • HCM 伺服器只需要對外存取 Azure 的 443 埠（HTTPS/WebSockets）。
  • 不需要開啟任何入站（Inbound）防火牆規則。
  • CAF 強烈建議啟用用戶端授權，並使用共用存取簽章（SAS）金鑰來管理連線權限。

實務建議整理表

在 Azure 控制台中操作時，選擇「建立新混合式連線」通常會自動引導你完成命名空間的建立或選擇，此時套用上述命名慣例，會對未來的維護有很大幫助。

針對混合式連線管理員（HCM）與相關資源的命名，遵循 Microsoft 雲端導入框架（CAF）可以確保架構在擴充時保持清晰。以下是具體的命名建議與實務做法。

資源命名建議

在 Azure 中，混合式連線（Hybrid Connection）並非獨立存在的實體，它依賴於服務匯流排（Service Bus）命名空間以及轉送（Relay）實體。

1. 服務匯流排命名空間（Service Bus Namespace）建議格式：sb-<系統/專案名稱>-<環境>-<區域>範例：sb-hr-prod-tw用途：這是承載所有連線的容器，應以「用途」而非單一伺服器命名。
2. 混合式連線實體（Hybrid Connection Entity）建議格式：hc-<目標伺服器/服務>-<通訊埠>範例：hc-sqlserver01-1433 或 hc-api-endpoint-8080用途：直接反映這個連線要通往內網的哪台主機與哪個服務。
3. 混合式連線管理員（HCM）安裝主機建議格式：hcm-vm-<流水號>範例：hcm-vm-01, hcm-vm-02用途：安裝在內網的實體機或虛擬機。建議在主機名稱加上 hcm 前綴，方便網路管理員識別這台機器的流量性質。

CAF 命名組成要素

CAF 建議的命名應包含以下標籤資訊，透過連字號（-）組合：

資源類型縮寫（Resource type）：例如 sb (Service Bus), hc (Hybrid Connection)。

應用程式名稱（App name）：代表這個連線服務的系統。

環境（Environment）：例如 dev, test, prod。

區域（Region）：縮寫如 tw (Taiwan), hk (Hong Kong)。

部署與架構建議

為了符合企業級的穩定性，除了命名外，CAF 還有幾點關鍵建議：

1. 分組管理（Grouping）不要將所有不相關的連線塞進同一個服務匯流排。建議依據工作負載（Workload）來區分。例如：薪資系統使用一個 sb，差勤系統使用另一個 sb。這樣在金鑰管理與權限控管上會更安全。
2. 高可用性（High Availability）在內網環境中，針對同一個混合式連線，應至少在兩台不同的主機上安裝 HCM。Azure 會自動在這些主機之間切換流量。這時命名可採用 hcm-host-a 與 hcm-host-b 來區分冗餘成員。
3. 規格層級在正式生產環境中，Service Bus 建議至少選擇標準版（Standard），以支援足夠的連線數與混合式連線功能。

透過這種標準化的命名方式，當系統搬遷或擴充規模時，MIS 人員能迅速識別資源歸屬，減少誤刪或配置錯誤的風險。

要讓位於 Azure 雲端的應用程式連回地端資源，混合式連線管理員（HCM）扮演的是一個主動外連的轉運站角色。它的運作邏輯並非由雲端直接「戳」進你的防火牆，而是從內部主動向外建立通道。

安裝與連通的具體流程如下：

安裝與配對

首先，你需要在地端內網找一台伺服器（Windows Server 2012 以上版本）安裝 HCM 程式。

• 在 Azure 入口網站點擊建立新混合式連線後，會得到一串連線字串（Gateway Connection String）。
• 將此字串貼入地端的 HCM 程式中。
• 此時 HCM 會透過 TCP 443 埠向 Azure Relay 服務發起連線。

建立通訊隧道

一旦 HCM 與 Azure 握手成功，連線狀態會顯示為已連線（Connected）。

• 外連請求：雲端的 App Service 發出存取請求（例如指向 db-server:1433）。
• 代理轉送：Azure Relay 收到請求後，會透過剛才 HCM 建立的長連線通道，將封包傳送給地端的 HCM。
• 本地派送：地端的 HCM 接收到封包，再以地端伺服器的身份，將請求發送給內網中真正的目標（如 SQL Server）。

關鍵技術特性

這種方式之所以適合企業環境，主要有三個原因：

• 免開入站埠：防火牆不需要開啟任何 Incoming Port，這對資安部門來說非常重要。只要內網主機可以連上網（443 埠），連線就能建立。
• 無需 VPN：它不需要建立點對點 VPN 或昂貴的專線，設定過程只需幾分鐘。
• 解析機制：App Service 會使用 HCM 所在的內網 DNS 環境。只要在 Azure 上設定的主機名稱地端能認得，連線就能成功。

實際操作建議

如果你的環境需要穩定運作，請注意以下幾點：

• 多主機部署：在兩台不同的地端伺服器安裝同一個連線的 HCM，這樣當其中一台重啟或更新時，服務不會中斷。
• 網路出口：確保地端 HCM 所在的主機沒有嚴格限制對外連線，否則無法連接到 Azure 的服務匯流排。
• 資源隔離：一個連線只對應一個特定主機與通訊埠（例如 192.168.1.50:1433），這符合最小權限原則，不會讓整個內網暴露在雲端。

資源隔離：一個連線只對應一個特定主機與通訊埠, 地端的API 只能被一台雲端的web app access ?

並非如此。資源隔離的定義是指每個混合式連線（Hybrid Connection）的「終點」是固定的，但「起點」可以非常靈活。

多對一的存取關係

一個地端資源（例如一台 API Server）可以同時被多個雲端應用程式存取。

在 Azure 的設定中，混合式連線是一個獨立的資源實體。只要你將該連線實體關聯到不同的 Web App，這些 App 都能透過同一個 HCM 通道連回地端的同一個 API。這在微服務架構中非常常見，例如你的前端 Web App、後端 API App 以及排程用的 Azure Functions，都可以共用同一個連往地端資料庫的混合式連線。

資源隔離的真正含義

所謂的資源隔離（Resource Isolation），重點在於安全控管與範圍限制：

• 精確的目標定義：一個混合式連線必須明確指定目標主機名稱（或 IP）與通訊埠（Port）。例如，你建立了一個連往 api-server:8080 的連線，雲端 App 就只能存取這個主機的 8080 埠，無法存取該機器的 1433 埠或其他內網主機。
• 按需分配：你可以決定哪些 Web App 有權掛載這個連線。如果 Web App A 有掛載，它就能連通；如果 Web App B 沒有掛載，它完全無法偵測到地端資源的存在。

實務建議

如果你有多個雲端 App 需要存取地端 API，建議做法如下：

• 建立單一連線實體：在 Service Bus 命名空間下建立一個名為 hc-internal-api-8080 的連線。
• 多點掛載：分別進入各個 Web App 的「網路」設定頁面，選擇「新增選取的混合式連線」，並指名同一個 hc-internal-api-8080。
• 流量監控：雖然多個 App 共用連線，但你仍可以在 Service Bus 的監控圖表中看到整體的連線數與資料傳輸量。

總結來說，地端 API 並非只能被一台雲端 App 存取，而是能被「你授權過的」所有雲端資源存取。這種設計讓你在維護地端 HCM 代理程式時更方便，不需要為每個雲端 App 都重複安裝一套地端代理。

地端的 outbound 要怎麼開?

要讓地端的混合式連線管理員（HCM）成功連回 Azure，地端防火牆不需要開啟任何「入站（Inbound）」規則，但必須確保「出站（Outbound）」通訊順暢。

HCM 是透過 HTTPS（TCP 443 埠）連向雲端的，且必須能與特定類型的 Azure 資源溝通。

出站防火牆設定規則

建議 MIS 人員在地端防火牆或代理伺服器（Proxy）上，針對 HCM 所在的主機設定以下規則：

• 連接埠（Port）：必須開啟 TCP 443。
• 傳輸通訊協定：HTTPS 與 WebSockets（混合式連線依賴 WebSocket 進行雙向傳輸）。

建議開通的網域名稱（FQDN）

由於 Azure 的 IP 位址會變動，CAF 建議優先使用 FQDN（網域名稱）進行過濾：

1. *.servicebus.windows.net這是最重要的核心。混合式連線底層跑的是 Azure Relay，而 Relay 服務掛在 Service Bus 之下。
2. *.table.core.windows.netHCM 需要存取 Azure 儲存體資料表來確認連線狀態與配置。
3. https://www.google.com/search?q=login.microsoftonline.com用於身份驗證與取得存取權杖（Access Token）。

如果資安要求必須使用固定 IP

如果貴單位的防火牆嚴格限制不能使用萬用字元（Wildcard）網域，則必須下載 Azure IP Ranges and Service Tags 列表。

• Service Tag：請搜尋 AzureRelay 與 ServiceBus 兩個標籤。
• 注意事項：Azure 每個區域的 IP 範圍很大且會定期更新。如果使用 IP 過濾，MIS 必須定期更新防火牆白名單，維運成本較高。

如何測試連線是否成功

在地端 HCM 主機上，你可以使用 PowerShell 快速測試網路路徑是否通暢：

PowerShell

# 測試連往 Service Bus 命名空間的 443 埠
Test-NetConnection -ComputerName [您的命名空間名稱].servicebus.windows.net -Port 443

如果 TcpTestSucceeded 顯示為 True，表示地端的 outbound 已經成功開通。

特別提示：關於 Proxy（代理伺服器）

如果地端環境必須經過 Proxy 才能上網，安裝完 HCM 後，你需要手動修改 HCM 的設定檔（通常是 Microsoft.HybridConnectionManager.Core.dll.config），在 <system.net> 標籤中加入 proxy 設定，它才能正常穿透代理服務。

你可以把它想像成一個**「全球性的交通樞紐」，而 WAF 是這個樞紐上的「安檢門」**。

1. 它們的關係是什麼？

• Azure Front Door (AFD): 是一個全球性的 內容傳遞網路 (CDN) 和 第 7 層負載平衡器。它的主要工作是讓你的網站跑得更快（加速）、更穩（高可用性）。
• Azure WAF: 是一個安全插件/策略，可以掛載在 Azure Front Door 上。它的主要工作是過濾惡意攻擊（如 SQL 注入、XSS 跨站腳本攻擊）。

2. 為什麼大家常把它們放在一起講？

因為當你使用 Azure Front Door 時，通常會啟用它的 WAF 功能。這有幾個好處：

• 邊緣防護 (Edge Security): 攻擊在還沒進入你的伺服器（甚至還沒進入 Azure 區域中心）之前，就在全球各地的邊緣節點被攔截了。
• 集中管理: 你只需要設定一份 WAF 規則，就能保護全球各地的後端服務。

3. Azure Front Door 的兩個版本與 WAF 的差異

總結

如果你需要的是 WAF（Web 應用程式防火牆），在 Azure 中你有兩個主要選擇：

1. Azure Front Door + WAF: 適用於全球性/對外的網站，在邊緣端就攔截攻擊。
2. Application Gateway + WAF: 適用於區域性/虛擬網路內的架構。

你的需求是要幫全球分佈的網站做防護嗎？ 如果是的話，Azure Front Door 的 WAF 功能會是非常強大的選擇。

在選擇 Azure 防禦方案時，價格結構主要分為「固定月費」與「變動流量費」。以下為 Azure Front Door (AFD) 兩個版本與 Application Gateway (AppGW) 的價格與定位比較：

1. 價格比較表 (預估)

2. 重點解析：該選哪一個？

Azure Front Door Standard (標準版)

• 適合誰： 預算有限、主要需要 CDN 加速，且只需要簡單的安全規則（如封鎖特定 IP 或地理位置）。
• 注意： 如果你需要微軟自動更新的 SQLi/XSS 規則，這個版本「不支援」受管規則集，防禦力較弱。

Azure Front Door Premium (高級版)

• 適合誰： 大型企業、跨國網站、對安全性有高度要求的服務。
• 關鍵價值： 它包含了 WAF 受管規則集（不需要自己寫防禦代碼）和 Private Link。如果你不希望你的後端伺服器暴露在公網上，Premium 是唯一能透過私有網路連接後端的方案。
• 省錢點： 雖然月費高，但它免除了 WAF 的政策費與規則費。

Application Gateway + WAF v2 (區域型)

• 適合誰： 服務集中在 單一區域 (例如只在台灣或香港)，不需要全球加速，且後端架構多為 VM 或 AKS (Kubernetes)。
• 關鍵差異： 它是一個區域性服務。如果你有 3 個區域的後端，你就需要買 3 組 AppGW，成本會迅速超過 Front Door。
• 價格陷阱： 除了固定費用，它的 CU (Capacity Unit) 計費方式較複雜，高併發流量下成本可能波動較大。

3. 決策建議

• 如果你要保護「全球」流量： 直接看 Front Door。如果只是小型個人網站選 Standard，如果是商業營運、怕被黑、怕爬蟲，請直上 Premium。
• 如果你要保護「單一區域」內的 VNet 資源： 選擇 Application Gateway + WAF。它能更深層地整合你的虛擬網路空間。
• 如果你極度重視安全（尤其是 Bot 攻擊）： Front Door Premium 的 Bot 防護是三者中最強的（基於微軟威脅情報中心數據）。

你是打算保護已經上線的既有網站，還是正在規劃新的跨區域架構？

Azure Communication Services (ACS)

這是目前 Azure 原生的推薦方案。它提供 Email 服務，且支援 SMTP Relay 功能。

• 特點：按量計費，整合在 Azure 資源管理內，安全性高。
• 認證方式：支援透過 Entra ID (原 Azure AD) 的應用程式註冊與 Service Principal 進行認證。
• 連線資訊：伺服器通常為 smtp.azurecomm.net，使用連接埠 587。

Twilio SendGrid

長期以來 Azure 官方合作的第三方服務，在 Azure 市集中可以直接購買與整合。

• 特點：功能最成熟，有豐富的報表、開信追蹤與行銷工具。
• 適用場景：除了簡單的系統通知，還需要處理電子報或進階郵件管理時的首選。
• 連線資訊：伺服器為 smtp.sendgrid.net，使用 API Key 作為認證密碼。

Microsoft 365 (Exchange Online)

如果你公司本身有在使用 Microsoft 365，也可以透過 Exchange Online 寄信。

• 注意事項：微軟正在全面停用 SMTP 的「基本驗證」（Basic Auth），到 2026 年底後，傳統的帳號密碼登入將失效，必須改用 OAuth 2.0。
• 限制：有每日寄信限額，且不適合發送大量行銷郵件，較適合內部系統或小量自動化腳本。

關鍵技術限制與建議

1. 封鎖 Port 25：Azure 所有的虛擬主機 (VM) 預設都會封鎖對外的 Port 25，以防垃圾郵件。請務必改用 Port 587 (TLS)。
2. 固定 IP 信用度：不建議在 VM 內自建 SMTP 伺服器直接對外寄信，因為雲端 IP 很容易被列入黑名單，寄達率極低。
3. 首選建議：如果你追求純 Azure 環境與簡單的系統通知，優先考慮 Azure Communication Services；如果需要強大的退信分析與行銷功能，選擇 SendGrid。

要在 Exchange Online 使用 SMTP 寄信，由於微軟已經全面停用基本驗證，目前的標準做法是透過 Azure 註冊應用程式並使用 OAuth 2.0。以下是開發者最常用的用戶端憑證流程步驟：

1. 在 Microsoft Entra ID 註冊應用程式

首先要在 Azure 入口網站建立一個身份，讓系統允許你的程式存取 Exchange Online。

• 進入 Azure Portal，搜尋並進入 Microsoft Entra ID。
• 點選 應用程式註冊，新增一個註冊。
• 記下 應用程式 (用戶端) 識別碼 以及 目錄 (租戶) 識別碼，稍後程式碼會用到。
• 在 憑證與密碼 中，新增一個 用戶端密碼，產生的數值請立即複製儲存，離開頁面後就看不到了。

2. 設定 API 權限

賦予這個應用程式寄信的權利。

• 在應用程式註冊頁面點選 API 權限。
• 點選 新增權限，選擇 Microsoft Graph。
• 選擇 應用程式權限 (不是委派權限)。
• 搜尋並勾選 Mail.Send。
• 儲存後，務必點選 代表 [你的組織名稱] 授與管理員同意，狀態變為綠色勾勾才算生效。

3. 配置 Exchange Online 服務主體

這是一個純指令步驟，目的是在 Exchange 系統內建立一個對應的服務主體，並賦予它寄件者權限。你需要安裝 PowerShell 的 ExchangeOnlineManagement 模組。

• 連線到 Exchange Online：Connect-ExchangeOnline。
• 執行以下指令建立連結：

PowerShell

New-ServicePrincipal -AppId <你的應用程式ID> -ServiceId <你的應用程式物件ID>

• 賦予特定信箱的寄信權限：

PowerShell

Add-MailboxPermission -Identity "sender@yourdomain.com" -User <你的應用程式ID> -AccessRights FullAccess

4. 撰寫程式碼獲取 Token 並寄信

不能再像以前只輸入帳號密碼，程式邏輯需要改為：

1. 向 Microsoft Entra ID 請求 Token。
2. 將 Token 放入 SMTP 連線的認證標頭中。

如果使用 Python，可以使用 msal 函式庫來處理認證。

Python

import msal

app = msal.ConfidentialClientApplication(
    client_id, authority=f"https://login.microsoftonline.com/{tenant_id}",
    client_credential=client_secret
)
result = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])
access_token = result['access_token']

5. SMTP 連線設定

連線資訊維持不變，但認證方式必須支援 XOAUTH2。

• SMTP 伺服器：smtp.office365.com
• 連接埠：587
• 加密方式：STARTTLS
• 使用者名稱：你的完整 Email 地址
• 密碼：剛才取得的 access_token 長字串

常見問題提醒

• 安全性限制：如果你的租戶啟用了「安全性預設值」(Security Defaults)，可能會強制要求 MFA，這會導致傳統 SMTP 連線失敗。使用 OAuth 2.0 應用程式權限可以繞過此限制。
• 寄件人一致性：你在程式碼中 From 欄位填寫的地址，必須與步驟 3 授權的信箱一致，否則會被 Exchange 拒絕寄送。
• 權限生效時間：在 Azure 修改權限後，有時需要等待 5 到 15 分鐘才會完全同步到 Exchange 伺服器。

在 Azure VNet 內部的後端服務向 Entra ID 請求 Token 是標準做法，但為了符合企業級的安全與效能規範，建議不要直接走公網連線，而是透過以下兩種技術進行優化：

1. 使用受控識別 (Managed Identities)

這是最推薦的方案。如果你是將後端服務部署在 Azure VM、App Service 或 Azure Container Apps 上，不應該在程式碼中寫死 Client ID 或 Secret。

• 安全性：你不需要管理憑證或金鑰，Azure 會自動處理身份認證。
• 運作機制：程式碼向本地端的一個特定 Endpoint 請求 Token，Azure 基礎設施會負責與 Entra ID 對接並回傳 Token。
• 網路路徑：這類請求通常走 Azure 內部的管理平面，不會暴露在公網。

2. 使用受控識別 (Managed Identity) 結合 Private Link

如果你的 VNet 有嚴格的資安限制（封鎖所有對外 443 流量），連 Entra ID 的公用端點都不想連，可以考慮使用 Microsoft Entra Private Link。

• 原理：在 VNet 內部建立一個 Private Endpoint，讓請求 Entra ID 的流量完全限制在私有網路內。
• 缺點：設定較為複雜，且這項功能目前主要針對特定資源存取，對於純粹的 Token 請求，通常只要確保 VNet 允許 HTTPS (443) 傳出至 login.microsoftonline.com 即可。

為什麼這對後端服務是安全的

• Service-to-Service 認證：Entra ID 產生的 Token 是基於應用程式身份（App Role），而不是特定使用者。這非常適合後端無人值守（Headless）的環境。
• 範圍縮小 (Scoped)：你可以限制該 Token 僅能用於發送郵件（Mail.Send），無法存取其他資料。
• 加密傳輸：所有的 Token 請求都必須強制使用 TLS 1.2 以上加密。

潛在的效能疑慮與對策

如果你擔心後端服務頻繁請求 Token 會造成延遲：

• 快取機制：不應每次寄信都請求新 Token。Token 通常有一小時的有效期，程式碼中應該實作快取邏輯，只有在 expires_in 快到期時才重新獲取。如果你使用官方的 MSAL SDK，它會自動幫你處理快取。
• 網路開銷：Token 請求只是極小的 JSON 資料，對 VNet 頻寬幾乎沒有影響。

總結建議

對於 VNet 內部的後端服務，請求 Token 是完全適合的。最佳實踐是：優先使用 System-assigned Managed Identity，並在程式中透過 DefaultAzureCredential 來獲取 Token。這樣既不需要在設定檔存密碼，也能確保認證過程符合 Azure 最新的安全規範。

對於寄信這種非高併發的任務，這點認證開銷是可以忽略不計的。你目前比較需要擔心的反而是 VNet 的 NSG 是否有開啟 587 連接埠對外連線至 Office 365 的權限。

這是一個關於雲端架構安全性的好問題。簡單來說，Microsoft Graph 的確是一個外網端點（https://graph.microsoft.com），但這並不代表它不安全。

以下從網路層級、認證機制與最佳實踐來分析：

Microsoft Graph 的網路位置

Microsoft Graph 是微軟雲端服務的統一入口，本質上是一個公用端點 (Public Endpoint)。這意味著你的 VNet 內部服務需要透過 HTTPS (Port 443) 才能存取它。

Backend 存取外網的安全考量

雖然它是「外網」端點，但實務上它是安全的，原因如下：

• 傳輸層加密 (TLS)：所有與 Graph API 的通訊都強制使用 TLS 1.2 或更高版本，資料在傳輸過程中是加密的。
• 身分驗證強制性：沒有有效的 OAuth 2.0 Token，任何人（即使連得上網址）都無法存取任何資料。
• 微軟骨幹網路：如果你的 Backend 服務是在 Azure VNet 內，發往 Microsoft Graph 的流量通常會留在 Microsoft 骨幹網路 (Global Network) 內部路由，而不會真的繞到公眾網際網路 (Public Internet) 的路由器。

如何讓存取過程更安全？

如果你的 VNet 是嚴格隔離的環境（封鎖所有 Outbound 流量），你可以採用以下對策：

1. 使用受控識別 (Managed Identity)

這是最重要的安全措施。

• 優點：你的 Backend 服務不需要儲存任何 Client Secret（金鑰）。身份辨識由 Azure 平台自動處理。
• 安全性：即使程式碼外洩，也沒有金鑰可以被盜用。

2. 設定網路安全組 (NSG) 或是服務標記 (Service Tags)

你不需要開放「所有外網」權限。

• 在 VNet 的 NSG 中，將輸出規則目的地設定為 Service Tag：AzureActiveDirectory。
• 這樣你的後端服務就只能存取身份驗證相關的微軟服務，而不能隨便連到其他的惡意網站。

3. 透過 Private Link (私密連結)

雖然 Microsoft Graph 目前還不像 Storage 或 SQL 提供完全的「私有端點」來收發郵件（它主要是針對資料整合），但你可以透過 Azure API Management (APIM) 作為代理。

• 架構：VNet -> Private Endpoint -> APIM -> Microsoft Graph。
• 優點：你的後端服務完全不需要開啟任何對外網的存取權限。

總結建議

對於一般公司內部的後端服務，直接存取 Microsoft Graph 是符合業界標準的。只要你：

1. 使用 HTTPS 連線。
2. 採用 Managed Identity (受控識別) 取代金鑰。
3. 在 NSG 中限制僅允許存取 AzureActiveDirectory 的 Service Tag。

這樣的安全強度對於 MIS 與資安稽核來說通常是足夠的。

根據 2026 年最新的官方公告與限制說明，Exchange Online 的寄信限額如下：

核心寄送限制

• 每日收件者上限：每個人員信箱每天最多可寄送給 10,000 個收件者。
• 計算方式：這是一個 24 小時的滑動視窗（Rolling Window），而不是每天凌晨重置。
• 外部收件者限額 (ERR)：微軟原本計畫在 2026 年 4 月將「外部收件者」限制在每日 2,000 人，但因客戶反饋激烈，該計畫已於 2026 年 1 月正式取消。目前外部收件者依然併入總量 10,000 人的額度內，沒有獨立的較低上限。

其他關鍵節流限制

除了總量，還有以下技術限制會影響你的後端程式：

• 每分鐘傳送速率：每分鐘最多寄送 30 封郵件。如果超過此速度，Exchange 會回傳重試代碼（Throttling）。
• 單封郵件收件者人數：單封 Email 最多只能包含 500 個收件者（可由管理者調高至 1,000 個）。
• 並行連線數：使用 SMTP AUTH 時，最多支援 3 個並行連線。

租戶層級總額 (TERRL)

除了單一信箱的限制，整個組織（Tenant）也有一個總對外寄信額度，通常是根據你購買的授權數量來計算：

• 公式大致為：500 x (授權數量 ^ 0.7) + 9,500。
• 這意味著如果你的公司只有 1 個授權，總額就是 10,000 封；如果有 1,000 個授權，總額約為每日 7.2 萬封。

專家提醒

如果你的後端服務需要發送大量的系統通知或電子報（例如一天超過一萬封），Exchange Online 並不是合適的選擇。它被定位為「人員商務通訊」，過量發信容易被系統標記為垃圾郵件發送者。建議若需求量大，應轉向使用 Azure Communication Services (ACS) 或 SendGrid，這類服務才有專門的信用額度管理與更高的寄送上限。

核心原則：區分「機關屬性」與「資料內容」

在台灣，存取紀錄 (access log) 能否出境，主要取決於該紀錄是否包含機敏資料或個人資料，以及該單位是否為政府機關/關鍵基礎設施。

實務合規建議

1. 日誌去識別化：若需將 access log 傳送到境外資安中心（如國外總部的 SOC 或 SIEM），應先過濾或遮蓋日誌中的敏感資訊（如姓名、身分證字號、非必要之個資欄位）。
2. 保留期限要求：根據《資通安全責任等級分級辦法》，核心資通系統之日誌應至少保留 6 個月，且需確保其完整性（防竄改）。
3. 雲端服務條款：若使用 Google Cloud、AWS 或 Azure 等境外雲端平台，應確認合約中關於資料存放地 (Data Residency) 的設定，並確認是否符合特定目的事業主管機關之規定。
4. 稽核義務：不論 Log 存放在何處，機關或企業必須保證當發生資安事件時，能及時提供完整日誌供主管機關調查。 [2, 5, 6, 7, 8]

您的單位是否屬於 A、B、C 級資通安全責任等級 機關，或是 關鍵基礎設施 (CII) 提供者？這將決定您是否有更嚴格的在地化儲存義務。

[1] https://stellexlaw.com

[2] https://pcw.tp.edu.tw

[3] https://www.jcic.org.tw

[4] https://law.moea.gov.tw

[5] https://www.ba.org.tw

[6] https://moda.gov.tw

[7] https://dsp.twse.com.tw

[8] https://law.moda.gov.tw

是的，根據台灣法律與資安實務規範，公立大學（含國立、市立大學）在《資通安全管理法》與《個人資料保護法》的定義下，通常被視為「公務機關」。 [1, 2]

這意味著在處理 access log（存取紀錄）時，公立大學受到的限制遠比一般私人企業嚴格。以下為詳細分類與規範說明：

1. 公立大學的法規身份

• 資安法定位：公立學校被列為公務機關，必須遵守《資通安全管理法》及其子法。相對於此，私立大學通常被歸類為「特定非公務機關」。
• 個資法定位：在個資法中，公立學校亦屬於公務機關，負有更高的個資保護與管理義務。 [2, 3, 4, 5]

2. 資通安全責任等級

教育部已根據學校規模與業務性質，將各公立大學核定為不同的資安責任等級：

• A 級 (最高)：教學醫院（如 台大醫院、成大醫院）或涉及國家安全機密研究的特定系所。
• B 級 (多數公立大學)：一般公立大學（如 台灣大學、陽明交通大學、政治大學）多被核定為 B 級機關。
• C 級：獨立學院或規模較小的專科學校。 [6, 7, 8, 9, 10]

3. Log 出境與存放之限制

由於身分為「公務機關」，公立大學在處理 log 時須遵守以下規範：

• 禁止使用具資安疑慮產品：禁止使用大陸廠牌之資通訊產品處理公務資料或紀錄。
• 在地化保存原則：公務機關的核心資通系統日誌以在地化保存為原則，特別是涉及機敏業務或個資的 log。
• 國際傳輸限制：若欲將包含個資的 log 傳輸至境外（例如使用國外雲端 SIEM 服務），需符合 個人資料保護法 第 21 條規定，且主管機關（教育部）有權限制此類國際傳輸。
• 保存期限：B 級（含）以上機關之核心系統 log 應至少保存 6 個月，且需具備防竄改機制。 [3, 9, 11, 12, 13, 14]

總結建議

若您在公立大學任職並計畫將 access log 傳送到境外：

1. 確認系統等級：確認該 log 所屬系統是否為「核心資通系統」。
2. 去識別化處理：傳輸前務必過濾個資與機敏欄位。
3. 合約審查：若使用境外雲端服務，需確保符合教育部針對「委外辦理資通事項」的相關資安查核要求。

您目前是需要將學校的 Web Log 還是 內部行政系統的 Log 傳送到境外的資安平台嗎？

[1] https://moda.gov.tw

[2] https://powilaw.com

[3] https://www.taccst.moe.edu.tw

[4] https://moda.gov.tw

[5] https://www.pdpc.gov.tw

[6] https://topu.nccu.edu.tw

[7] https://www.tcrc.edu.tw

[8] https://www.net.fju.edu.tw

[9] https://www.cc.ntu.edu.tw

[10] https://it.nycu.edu.tw

[11] https://www.hhps.kh.edu.tw

[12] https://lic.niu.edu.tw

[13] https://www.zzm.kh.edu.tw

[14] https://www.pdpc.gov.tw

針對公立大學的 Web Log（網頁伺服器存取紀錄）傳輸至境外，雖然其性質通常比行政系統紀錄（如人事、薪資）稍微不敏感，但身為公務機關，仍須遵循以下實務規範：

1. 核心判斷：是否包含「個資」或「帳號」？

• 純技術 Log：如果 Log 僅包含 來源 IP、訪問時間、URL 路徑、HTTP 狀態碼、User-Agent，在現行法規下通常被視為技術資訊。這類資訊傳輸至境外（如使用 Cloudflare, Akamai 或國外資安監控中心）的門檻較低。
• 含個資 Log：若 URL 參數中包含 身分證字號、學號、姓名（例如：GET /profile?id=A123456789），或 Log 紀錄了 使用者帳號，這就涉及《個資法》的「國際傳輸」。身為公立大學（公務機關），應盡量避免這類資訊出境。

2. 教育部與資安法之要求

根據《資通安全管理法》及教育部對公立學校的指導原則：

• 優先在地儲存：核心資通系統（如校務系統入口、首頁）的原始日誌（Raw Logs）應在校園內部或國內儲存空間備份至少 6 個月。
• 境外傳輸前置作業：若要將 Web Log 送往境外的 SIEM 或分析平台，建議先在校內進行 去識別化 (Anonymization/Masking)，將學號或敏感參數遮蓋後再外傳。

3. 禁止使用「危害國家資通安全產品」

這是公立大學最嚴格的紅線：

• 禁止名單：絕對不能將 Log 傳輸至中國大陸廠牌的雲端空間或使用其資安分析服務（如阿里雲、華為雲等），這違反行政院及教育部的資安規定。
• 合格供應商：使用如 Google (GCP)、Amazon (AWS) 或 Microsoft (Azure) 等美商雲端，且選擇台灣或鄰近非紅區節點，是目前較常見且合規的作法。

4. 實務操作建議

若您計畫將 Web Log 傳送到境外資安分析平台：

1. 確認合約：確保服務供應商（如 CDN 或 WAF 服務商）符合資安法規要求，且有提供資料安全保護協議。
2. 稽核準備：確保當教育部或資通安全署進行資安稽核時，您能在校內調取出「完整、未經過境外過濾」的原始日誌。
3. 隱私宣告：在大學官網的「隱私權政策」中，應載明會蒐集存取紀錄，並可能用於資安防護目的。

您是打算使用 境外 CDN/WAF（如 Cloudflare），還是要將 Log 匯入到 國外的總部或第三方分析軟體 中？不同的使用情境，對合規文件的要求也會有所不同。

若您是公立大學（公務機關），計畫將 Web Log 匯入 Azure Monitor (Log Analytics)，主要會涉及「資料儲存地」與「公務雲端規範」兩大重點。

以下是針對您的情境（Azure 境外分析）的具體合規分析與建議：

1. Azure 資料駐留 (Data Residency) 的選擇

Azure 雖然是境外廠商，但他在台灣已有資料中心。

• 建議做法：在建立 Log Analytics Workspace 時，區域（Region）請優先選擇 Taiwan North (台灣北部)。
• 合規意義：若 Log 儲存在台灣本地節點，則不屬於「資料出境」，可直接規避《個資法》第 21 條關於國際傳輸的複雜限制，也最符合教育部對公務機關「資料在地化」的期待。

2. 若必須傳輸至國外區域（如 East US 或 Singapore）

若因特定功能或預算考量需傳往國外，公立大學須滿足以下條件：

• 個資去識別化：在 Log 發送至 Azure 之前，應透過 Azure Monitor Agent (AMA) 的 資料收集規則 (DCR) 或中繼伺服器，將 URL 參數中的學號、身分證字號或使用者帳號進行 Hashing 或 Masking（遮罩）。
• 排除具資安疑慮之廠商：Azure 屬美商，符合行政院針對公務機關使用雲端服務的合格供應商範疇（非大陸廠牌）。

3. 遵守《資通安全管理法》子法規範

身為 B 級（或以上）機關，將 Web Log 匯入 Azure 時需確保：

• 完整性與防竄改：Azure Log Analytics 具備唯讀特性，符合資安法對日誌不可竄改的要求。
• 備份義務：法律要求 Log 需保存 6 個月。雖然 Azure 可以設定保留期，但建議校內仍需留有一份原始 Log 備份，以應付教育部或資安署的實地稽核。
• 委外資安稽核：公立大學將資通業務委外處理（使用雲端算委外的一種），應每年對受託資服商進行資安稽核。實務上通常以查閱微軟提供的 合規性報告 (Compliance Reports, 如 SOC 2) 代替實地查核。

4. 實務操作風險提醒

• IP 位址爭議：雖然 IP 位址在台灣目前的法律實務中，對於是否屬於「個資」仍有討論空間，但在公務機關的嚴格標準下，建議將 IP 的最後一碼（Last Octet）遮蓋後再傳往境外區域，可大幅降低合規壓力。

總結建議：
最省事的合規方式是將 Azure Log Analytics Workspace 建立在 台灣區域 (Taiwan North)。若必須放在國外，請務必先在校內端完成 敏感欄位遮蓋。

您目前預計匯入的 Log 數量大嗎？是否需要針對 自動化遮蓋敏感資訊 的技術設定提供建議？

這確實是目前許多單位在評估 Taiwan North (台灣北部) 節點時會遇到的典型問題：「資料在地化」與「服務完整度」的衝突。

既然因為 Container Apps 的技術限制必須使用境外區域（例如 East Asia 香港或 Southeast Asia 新加坡），針對公立大學（公務機關）的身份，您可以採取以下合規路徑來處理 Web Log：

1. 採取「混合式」日誌架構 (最推薦)

不要直接將原始 Log 從 Container Apps 丟往境外的 Log Analytics。

• 做法：在 Container Apps 輸出的流量中，先經過一個位於校內（或國內雲端 VM）的 中繼站 (Forwarder/Collector)，例如 Fluentd 或 OpenTelemetry。
• 關鍵動作：在中繼站進行 去識別化 (De-identification)。
  • 遮蓋 URL 中的敏感字串（學號、姓名）。
  • 將來源 IP 去標籤（例如 192.168.1.100 改為 192.168.1.x）。
• 合規點：傳出國外的資料已不具備「個資」屬性，這對教育部和稽核單位來說，合規壓力會降到最低。

2. 完備「委外資安」行政手續

依據《資通安全管理法》子法，公立大學將資通業務（含 Log 存儲）委外給 Azure 時，應履行以下行政程序：

• 受託對象安全性：Azure (Microsoft) 屬非大陸廠牌，過關。
• 資料國際傳輸聲明：在校內資安會議或公文中，敘明因技術限制（Taiwan North 尚無該功能），資料暫存於國外節點，並已實施去識別化措施。
• 下載 SOC 報告：從 Microsoft Service Trust Portal 下載最新的 SOC 1/2 或 ISO 27001 報告存檔，證明該區域已通過國際資安標準。

3. 設定「異地備援」至校內

即便分析是在境外的 Azure Monitor 進行，法律要求的「6 個月日誌保存」建議還是要有一份在校內。

• 做法：將 Log 同時導流一份回校內的伺服器儲存。
• 合規點：若資安署或教育稽核要看「原始原始碼（Raw Log）」，您可以出示校內這份。境外那份僅定義為「分析用途」，而非「唯一保存地」。

4. 實務折衷方案：選用「新加坡」優於「香港」

若必須選境外：

• 優先選 Southeast Asia (新加坡)：政治風險相對較低，且與台灣網路連線品質優。
• 避免 East Asia (香港)：雖然連線快，但因《國安法》等因素，部分公務機關在資安稽核時對香港區域的資料存放會更為敏感。

總結建議：
既然技術上非出國不可，請務必在 Log 送入 Azure 之前，先在校園端過濾掉明文個資。只要 Log 裡沒有「可辨識特定人」的資料，它就是純粹的「技術數據」，出境的爭議會小很多。

您目前的 Container Apps 是要處理 校內行政系統 的 Web 流量，還是 一般學術研究/宣傳型 的網站？（後者的敏感度較低，處理起來會更彈性）

第一部分：Azure CLI 指令集

請確保你的 Azure CLI 已安裝 containerapp 擴充功能：az extension add --name containerapp。

1. 建立資源群組 (Resource Group)

Bash

az group create \
  --name my-aca-rg \
  --location taiwannorth

2. 建立 Log Analytics 工作區

ACA 需要一個工作區來儲存日誌。

Bash

az monitor log-analytics workspace create \
  --resource-group my-aca-rg \
  --workspace-name my-aca-logs \
  --location taiwannorth

3. 建立 Container Apps Environment

這是 ACA 的基礎設施邊界。根據你的需求，我們不設定 VNet 整合。

Bash

az containerapp env create \
  --name my-aca-env \
  --resource-group my-aca-rg \
  --logs-workspace my-aca-logs \
  --location taiwannorth

4. 佈署 Container App

假設你的映像檔在 Docker Hub 或公共倉庫（若是私有倉庫如 ACR，則需額外參數）。

Bash

az containerapp create \
  --name my-web-app \
  --resource-group my-aca-rg \
  --environment my-aca-env \
  --image mcr.microsoft.com/k8se/quickstart:latest \
  --target-port 80 \
  --ingress external \
  --query properties.configuration.ingress.fqdn

第二部分：關於「不連內網」與「其他服務整合」

你的需求是 「不需連內網 (VNet)」，這在 ACA 中被稱為 Managed Environment。

1. 這是否會影響與其他 Azure 服務的溝通？

不會。 即使不加入自定義 VNet，ACA 預設就能透過 公用端點 (Public Endpoint) 與其他 Azure 服務溝通，例如：

• Azure SQL / Cosmos DB： 透過公用存取或防火牆白名單連接。
• Blob Storage： 透過 SDK 直接存取。
• Static Web Apps (SWA)： 這兩者經常搭配使用。

2. 與「靜態網頁 (Static Web Apps)」的整合場景

這是一個非常經典的架構：

• 前端： 使用 Azure Static Web Apps 佈署 React/Vue/Angular。它全球佈署，速度快且成本極低。
• 後端： 使用 Azure Container Apps 作為 API Server 或處理複雜邏輯。
• 串接方式： 1. 你可以在 SWA 的設定中，將 ACA 的 FQDN 設定為 API 的來源。2. 利用 SWA 的 “Bring your own backend” (BYOB) 功能，將 ACA 連結到 SWA，這樣前端請求 /api 時，Azure 會自動路由到你的 ACA，且不需要處理跨網域 (CORS) 問題。

補充建議

• 成本控制： ACA 的優勢在於可以「縮減至 0 (Scale to Zero)」，如果你的服務不是 24/7 都有流量，這比 Web App 便宜非常多。
• 安全性： 既然不使用 VNet，建議在 ACA 內啟用 Managed Identity (受控識別) 來存取 Key Vault 或資料庫，這樣就不需要在程式碼裡寫死密碼。

你的 Web App 目前是跑什麼樣的程式語言？如果涉及私有映像檔倉庫（如 ACR），我再幫你補上相關的認證指令。

佈署 Container App, 只能用 http (port:80) 不能用 https 連?

在 Azure Container Apps (ACA) 中，關於連線協議的設計非常明確：對外（Ingress）強制使用 HTTPS，而內部（Container 之間）則可以使用 HTTP。

以下是針對你疑問的詳細拆解：

1. 對外連線：強制 HTTPS

當你將 ingress 設定為 external 時，Azure 會自動為你的 Container App 提供一個預設的 FQDN（例如 my-app.taiwannorth.azurecontainerapps.io），並且：

• 自動處理 SSL/TLS 憑證： Azure 會自動管理並為該網址簽發憑證。
• 強制導向： 預設情況下，所有來自外部的 HTTP (Port 80) 請求都會被自動轉址 (Redirect) 到 HTTPS (Port 443)。
• 安全性： 你不需要在容器內部處理複雜的憑證設定，這些都在 ACA 的邊界（Ingress）層級處理掉了。

2. 內部通訊：可以使用 HTTP

雖然外部使用者必須透過 HTTPS 連線，但你的 容器內部（Container Port） 通常只需要監聽 HTTP 即可。

• SSL Termination (SSL 卸載)： 流量到達 ACA 環境的入口時，HTTPS 會被「卸載」。接著，ACA 的負載平衡器會透過 HTTP 將流量轉發給你的容器。
• 指令中的 --target-port 80： 這就是告訴 ACA，你的程式碼在容器內監聽的是 Port 80。

[!TIP]

結論： 使用者訪問你的網址時「一定是用 https」，但你寫程式時，只要讓 App 監聽 http port 就可以了。

3. 如果你想更動 Ingress 設定

如果你希望調整，以下是相關的指令邏輯：

4. 與靜態網頁 (Static Web App) 串接時的 HTTPS

既然你提到可能配合「靜態網頁」使用：

• Static Web Apps 同樣強制 HTTPS。
• 由於兩者都是 HTTPS，在瀏覽器端發送 API 請求時，不會遇到「混合內容 (Mixed Content)」的安全警告。

最後一個小提醒：

在 taiwannorth (台北) 部署時，請確認你的 CLI 版本是最新的，因為新區域的資源類型有時需要最新版的 API 支援。

你的程式碼是使用特定的框架（如 .NET, Node.js, Python）嗎？我可以幫你確認該框架預設的 Port 是否需要調整。

–target-port 參數要換成 443?

不需要。在 --target-port 參數中，你應該維持設定為你的程式（容器）真正監聽的 Port（通常是 80, 8080 或 5000），而不是 443。

這裡有一個關鍵觀念：ACA 的 Ingress 層會幫你做「SSL 卸載 (SSL Termination)」。

為什麼不填 443？

1. 流量轉發流程：
   • 外部使用者：透過 https://... (Port 443) 訪問你的 FQDN。
   • ACA Ingress 控制器：接收 HTTPS 流量，處理 SSL 憑證，解密後將流量轉為 HTTP。
   • 你的容器：接收來自 Ingress 轉發的 HTTP 流量。
2. 容器內部配置：大多數 Docker 映像檔（例如 Nginx, Node.js, Python）在容器內預設都是跑 HTTP (Port 80/8080)。如果你強行設定 --target-port 443，ACA 會試圖把流量導向容器的 443 Port，但如果你的程式沒在該 Port 監聽或沒配置憑證，連線就會失敗。

指令情境建議

• 如果你的程式碼監聽 80 (如 Nginx 預設)：Bash--target-port 80
• 如果你的程式碼監聽 8080 (如 Spring Boot 或許多 Node.js 框架)：Bash--target-port 8080
• 只有在一種極罕見的情況下才用 443：除非你自己把 SSL 憑證打包進 Docker Image 裡，並且讓你的程式碼直接監聽 443 Port 並處理加密（這在雲端原生架構中不建議，因為管理憑證很麻煩）。

總結

外部連線時，Azure 會強制幫你加密，所以使用者看到的絕對是 https://。

驗證方法：

部署完成後，你可以試著在瀏覽器輸入 http://<你的網址>，你會發現它會自動跳轉成 https://<你的網址>。這證明了 HTTPS 是在「入口處」就處理好的，跟你的 --target-port 設定無關。

目前你的 Web App 程式碼裡面，監聽的是哪個 Port 呢？

1. 實測新加坡速度 (Southeast Asia)

PowerShell

$time = Measure-Command { $socket = New-Object Net.Sockets.TcpClient; $socket.Connect("20.195.69.73", 443); $socket.Close() }
Write-Host "新加坡 (Southeast Asia) 回應時間: $($time.TotalMilliseconds) ms"

2. 實測日本東部速度 (Japan East)

PowerShell

$time = Measure-Command { $socket = New-Object Net.Sockets.TcpClient; $socket.Connect("20.43.64.106", 443); $socket.Close() }
Write-Host "日本東部 (Japan East) 回應時間: $($time.TotalMilliseconds) ms"

執行結果:

數據出來了，結果非常明確：日本東部 (Japan East) 的物理連線速度明顯優於新加坡，快了將近 27ms (約 40%)。

在網路環境下，42ms 是一個非常漂亮的速度。既然日本區的 TCP 連線反應更快，我們就選 japaneast。

最終決定：使用 Japan East (日本東部)

雖然它比較快，但因為你的環境 DNS 解析不穩，建議你在執行 Azure 指令前，先確保你的環境能正確解析網域名稱。

解決 DNS 不穩的小技巧： 如果你之後又遇到 Name resolution failed，請將你的電腦 DNS 暫時手動設定為 8.8.8.8 (Google) 或 1.1.1.1 (Cloudflare)，這通常能解決學術網路對部分 Azure 區域解析不良的問題。

以下是完整的建立步驟與語法：

1. 建立 Log Analytics Workspace

你可以直接執行以下指令來建立一個新的工作區：

PowerShell

az monitor log-analytics workspace create `
  --resource-group $RESOURCE_GROUP `
  --workspace-name $WORKSPACE_NAME `
  --location $LOCATION

2. 為什麼需要它？

在建立 Container App Environment (CAE) 時，工作區就像是一個「大型儲存桶」，負責接收並儲存容器產生的所有日誌（Logs）和指標（Metrics）。

3. 自動化整合腳本 (從建立到取得 ID/Key)

為了讓你後續建立 Container App Environment 順利，建議依照這個流程操作：

PowerShell

# 設定 Workspace 名稱 (自定義)
$WORKSPACE_NAME = "log-pr-prod-twn-01"

# Step A: 建立 Workspace
az monitor log-analytics workspace create `
  --resource-group $RESOURCE_GROUP `
  --workspace-name $WORKSPACE_NAME `
  --location $LOCATION

# Step B: 取得該 Workspace 的 ID
$WORKSPACE_ID = az monitor log-analytics workspace show `
  --resource-group $RESOURCE_GROUP `
  --workspace-name $WORKSPACE_NAME `
  --query id --output tsv

# Step C: 取得該 Workspace 的 Key
$WORKSPACE_KEY = az monitor log-analytics workspace get-shared-keys `
  --resource-group $RESOURCE_GROUP `
  --workspace-name $WORKSPACE_NAME `
  --query primarySharedKey --output tsv

# Step D: 現在你可以成功建立 Container App Env 了！
az containerapp env create `
  --name $CONTAINERAPP_ENVIRONMENT `
  --resource-group $RESOURCE_GROUP `
  --location $LOCATION `
  --logs-workspace-id $WORKSPACE_ID `
  --logs-workspace-key $WORKSPACE_KEY

小提醒

• 定價層 (Pricing Tier)：預設建立的會是 PerGB2018，這是目前的標準定價模式，按量計費。
• 保留天數：預設通常會保留 30 天的日誌，如果需要更長，可以在建立後調整。
• 資源群組：請確保 $RESOURCE_GROUP 已經先建立好了（az group create），否則指令會報錯。

你現在的 $RESOURCE_GROUP 和 $LOCATION 變數都已經設定好了嗎？（例如 $LOCATION = "eastasia"）

關於 Azure Log Analytics Workspace 的計費，這是一個「進來要錢、留著要錢、查一般不用錢」的邏輯。

以下是針對 2026 年最新計費模式的詳細拆解：

1. 實際會被收多少？ (按量計費)

基本的「隨用隨付 (Pay-As-You-Go)」主要由兩個部分組成：

• 資料擷取 (Ingestion)： 每 GB 約為 $2.30 USD。
  • 註：每個月通常有前 5 GB 的免費額度。
• 資料保留 (Retention)： * 前 31 天免費。
  • 超過 31 天後，每 GB 每月約收 $0.10 USD。
  • 如果你是為了法規需要存好幾年（長效保留），價格會降到每 GB 約 $0.02 USD。

簡單試算：

如果你每天產生 1 GB 的日誌，一個月 30 GB。

(30GB – 5GB 免費) × $2.30 = $57.5 USD / 月 (約台幣 $1,800)。

2. 分析（查詢）需要錢嗎？

這取決於你使用的「資料層次 (Tier)」：

• Analytics Logs (預設)： 查詢完全免費。你可以無限次執行 KQL 查詢來產出圖表。
• Basic Logs (基本日誌)： 這種層次擷取很便宜（約 $0.50/GB），但查詢要錢，每掃描 1 GB 資料約收 $0.005 USD。適合存那些「平常不看，出事才查」的資料。
• Search Job (搜尋作業)： 如果要在海量歷史資料中搜尋，會按掃描量計費。

3. 定價層 (Pricing Tiers)

除了按量計費，如果你資料量很大，可以使用「承諾層級 (Commitment Tiers)」來打折：

4. 有 EPS (每秒事件數) 上限嗎？

Azure Log Analytics 沒有嚴格的 EPS 硬性上限，它是彈性擴張的，但有以下限流 (Throttling) 規則：

• 資料擷取速度： 單一個 Workspace 通常支援到 6 GB/分鐘 的擷取速度。如果超過，可能會遇到延遲，但資料不會遺失（會排隊）。
• API 調用限制： 如果你是透過 API 狂發日誌，每分鐘約有 200 次請求的限制。
• 查詢限制： 為了防止惡意查詢榨乾資源，單一查詢最多跑 10 分鐘，且回傳結果上限為 30,000 列。

專業建議：如何省錢？

1. 過濾掉沒用的日誌： 在 az containerapp 設定中，只傳送「錯誤 (Error)」或「重要 (Warning)」等級的日誌到 Workspace。
2. 善用 Basic Tier： 對於開發環境或測試環境的日誌，可以設定為 Basic 模式來節省 75% 的擷取成本。
3. 設定預算上限 (Daily Cap)： 你可以設定 Workspace 每天最多只能收多少 GB（例如 5GB），避免因為程式 Bug 產生無窮迴圈 Log 導致帳單爆炸。

你目前預計每天產生的日誌量大約是多少？如果量很大，我可以直接幫你算承諾層級的划算程度。

台灣資案法規, log 可以放其他國家嗎?

這是一個非常關鍵的合規性問題。在台灣，Log（日誌）是否可以存放於境外，取決於你的產業屬性、公司身分以及 Log 內是否包含個人資料（PII）。

依照 2026 年最新的法規趨勢與《資通安全管理法》，我為你整理如下：

1. 公務機關與關鍵資訊基礎設施 (CII)

如果你屬於政府單位、公務機關，或受託開發的廠商：

• 原則：禁止。 根據資安署規定，公務機關雲端資料（含備份、備援、日誌）的實體所在地不得位於大陸地區（含港澳）。
• 落地要求： 對於高等級資安系統，通常要求資料儲存與處理需在本國境內。即使使用雲端，也傾向於選擇有「台灣資料中心」的服務（如 Azure 台灣區域）。

2. 特殊監管產業 (如金融、醫療)

• 金融業： 受金管會高度監管。雖然目前法規已放寬雲端委外，但如果 Log 涉及客戶交易明細或個人敏感資料，通常需要報備，且必須確保受監管單位（金管會）能隨時進行實地稽核。
• 醫療業： 根據最新的電子病歷及相關法規，涉及病患隱私的資料與 Log 通常要求存放於境內。

3. 一般民間企業 (受《個資法》規範)

如果你是一般民間企業，Log 是否出境主要看 《個人資料保護法》第 21 條：

• 可以出境，但有條件： 除非主管機關（如經濟部、數發部）針對特定產業發布禁止令（例如過去曾禁止電商將個資傳往大陸），否則原則上可以國際傳輸。
• 保護措施： 你必須確保接收資料的國家對個資有完善保護，且必須在隱私政策中告知用戶。

4. 實務建議：Log 存放於 Azure 的策略

既然你在使用 Azure，建議採取以下三種策略來規避法律風險：

方案 A：使用 Azure 台灣區域 (Taiwan North)

Azure 已經在台灣（桃園/板橋一帶）設立資料中心。

• 做法： 建立 Log Analytics Workspace 時，將 Location 設定為 Taiwan North。
• 優點： 滿足最嚴苛的「資料落地」要求，且網路延遲最低。

方案 B：資料去識別化 (Data Masking)

如果你的應用程式 Log 包含使用者的 IP、Email、手機號碼，這些都屬於個資。

• 做法： 在將 Log 送往 Log Analytics 之前，在應用程式端進行加密（Hash）或遮罩處理。
• 優點： 脫敏後的 Log 就不再屬於《個資法》定義的個人資料，存放於新加坡（Southeast Asia）或美國通常沒有合規問題。

方案 C：分層儲存

• 做法： * 一般日誌： 放境外（便宜）。
  • 稽核日誌 (Audit Logs)： 包含敏感操作或個資，強制放在台灣境內或地端。

總結檢查清單

提示： 雖然 Azure East Asia 指的是香港，但根據台灣目前的資安政策，高度建議不要將涉及個資或資安的 Log 放在香港，建議優先選擇 Taiwan North。

你的應用程式是否會處理到身分證字號、信用卡號等敏感資料並印在 Log 裡呢？

az containerapp env create `
>>   --name $CONTAINERAPP_ENVIRONMENT `
>>   --resource-group $RESOURCE_GROUP `
>>   --location $LOCATION `
>>   --logs-workspace-id $WORKSPACE_ID `
>>   --logs-workspace-key $WORKSPACE_KEY
You cannot create a Containerapp environment in location taiwannorth. List of eligible locations: westus2, southeastasia, swedencentral, canadacentral, westeurope, northeurope, eastus, eastus2, eastasia, australiaeast, germanywestcentral, japaneast, uksouth, westus, centralus, northcentralus, southcentralus, koreacentral, brazilsouth, westus3, francecentral, southafricanorth, norwayeast, switzerlandnorth, uaenorth, canadaeast, westcentralus, ukwest, centralindia, japanwest, australiasoutheast, francesouth, spaincentral, italynorth, polandcentral, southindia.

看起來你撞到了 Azure 區域功能的硬傷。雖然 Taiwan North (台灣北部) 已經上線，但並非所有服務（特別是 Container Apps 這種比較新的託管服務）都會在第一時間支援該區域。

根據錯誤訊息，Taiwan North 目前還不支援 Container Apps Environment。

1. 解決方案：更換區域

既然 Log 法律合規性是你考量的重點，且台灣暫時不可用，建議改用 Singapore (southeastasia)。

• 優點： 離台灣最近，延遲低，且非中國地區，符合多數民間企業的資安規範。
• 注意： 如果你改了區域，Log Analytics Workspace 也必須重新建立在同一個區域，否則會報錯或產生跨區域流量費用。

2. 修正後的執行腳本

請依序執行以下步驟（我們把 Location 硬切到 southeastasia）：

PowerShell

# 1. 更新區域變數
$LOCATION = "southeastasia"

# 2. 重新建立或更新 Workspace (要在同一個區域)
az monitor log-analytics workspace create `
  --resource-group $RESOURCE_GROUP `
  --workspace-name $WORKSPACE_NAME `
  --location $LOCATION

# 3. 重新抓取 ID 和 Key (確保是新的)
$WORKSPACE_ID = az monitor log-analytics workspace show --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --query id -o tsv
$WORKSPACE_KEY = az monitor log-analytics workspace get-shared-keys --resource-group $RESOURCE_GROUP --workspace-name $WORKSPACE_NAME --query primarySharedKey -o tsv

# 4. 再次嘗試建立 Container App Environment
az containerapp env create `
  --name $CONTAINERAPP_ENVIRONMENT `
  --resource-group $RESOURCE_GROUP `
  --location $LOCATION `
  --logs-workspace-id $WORKSPACE_ID `
  --logs-workspace-key $WORKSPACE_KEY

3. 關於法規的應對 (當 Location 為新加坡時)

如果你的公司必須遵守「資料落地台灣」，而技術上又必須使用 Container Apps，目前有兩種彈性做法：

• 混合雲模式： 把運算放在 southeastasia，但資料庫（SQL/Storage）放在 taiwannorth。Log 則透過 Diagnostic Settings 同步一份備份回台灣境內的 Storage Account。
• 等待期： 依照 2026 年的進度，台灣區域的服務正在陸續補齊。你可以先在新加坡開發，等 taiwannorth 支援 Container Apps 後再進行區域轉移（Region Move）。

4. 如何檢查該區域支援哪些服務？

如果你想確認某個區域到底能不能用，可以執行：

PowerShell

az provider show -n Microsoft.App --query "resourceTypes[?resourceType=='managedEnvironments'].locations" -o json

這會直接噴出目前全球支援 Container App Environment 的所有清單，你可以看到 taiwannorth 是否在裡面。