系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：NSG 套用位置（Subnet vs NIC）、雙層評估模型（Effective Rules）、規則優先序（100–4096）、平台預設規則與 DenyAll 收口、狀態式（Stateful）連線追蹤、Service Tag、Application Security Group (ASG) 邊界、Network Watcher 觀測工具（IP Flow Verify / NSG Flow Logs）。
Day 11 我們替 Titan 科技劃出了 VNet、Subnet 與 Private Endpoint 的網路疆域；但「資源在私有網路裡」絕不等於「封包天生安全」。如果內部網路處於完全放任狀態，一旦前台 Web 伺服器遭遇漏洞攻破，黑客便能毫無阻礙地橫向移動（Lateral Movement）直搗核心資料庫。今天我們要在每一道子網路門口與虛擬網卡前部署重兵守衛：誰可以進來、誰可以出去、多條規則發生衝突時誰說了算，以及如何在不手工維護成百上千個動態 IP 的前提下，優雅地為工作負載分組。
這一關最容易把 AWS 的肌肉記憶直接複製過來而釀成大禍。在 AWS 架構中，Security Group (SG) 是掛載在 ENI 上的狀態式防護，而 Network ACL (NACL) 才是掛在 Subnet 上的無狀態（Stateless）邊界；但在 Azure 中，Network Security Group (NSG) 既能掛在 Subnet，也能掛在 NIC，且無論掛在哪裡都是狀態式（Stateful）！很多資深 AWS 架構師看到子網路層級的 NSG，就下意識以為它是 NACL，在 Outbound 手動開放大範圍臨時連接埠（Ephemeral Ports），無形中在城牆上鑿出了致命的大洞。
今天的目標是建立原廠級架構推理鏈：掌握 NSG 雙層過濾機制、優先序數值決策鏈、ASG 角色分組實務，以及透過 Network Watcher 進行網路流量可觀測性稽核。
Internet / 外部連線請求
▼
┌──────────────────────────────────────────────┐
│ 第 1 道城門：Subnet 層級 NSG │
│ • 共同安全基線 (如: 拒絕特定惡意來源 IP) │
└──────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────┐
│ 第 2 道城門：NIC (網卡) 層級 NSG │
│ • 工作負載專屬規則 (使用 ASG 限制特定角色) │
└──────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────┐
│ 目的地：工作負載實體 │
│ • Azure Virtual Machine / AKS Node │
└──────────────────────────────────────────────┘
User
|
v
Public IP --> Application Gateway
|
| HTTPS 443
v
+------------------------------------------------------------------+
| Azure VNet: 10.20.0.0/16 |
| |
| +----------------------+ +----------------------+ |
| | Web subnet | | API subnet | |
| | Subnet NSG |--->| Subnet NSG | |
| | Allow Internet:443 | | Allow ASG-Web:8080 | |
| | DenyAll catch-all | | | |
| | Web VM NIC | | API VM NIC | |
| | NIC NSG | | NIC NSG | |
| | ASG-Web |--->| ASG-API | |
| +----------------------+ +----------+-----------+ |
| | SQL 1433 |
| v |
| +----------------------+ |
| | Data subnet | |
| | Subnet NSG | |
| | Allow ASG-API:1433 | |
| | Database VM NIC | |
| | NIC NSG | |
| | ASG-DB | |
| +----------------------+ |
| |
| Inbound: Subnet NSG ---> NIC NSG |
| Outbound: NIC NSG ---> Subnet NSG |
| ASG rules use workload roles instead of fixed VM IP addresses. |
+------------------------------------------------------------------+
^
|
+----------------+----------------+
| Network Watcher |
| IP Flow Verify / NSG Flow Logs |
+---------------------------------+
Observes effective NSG rules and flow records
讀圖方式：Inbound 流量依序通過 Subnet NSG，再通過 NIC 層級的 NSG；
任一層拒絕即停止。Web 到 API、API 到 Data 的規則以 ASG 代表工作負載角色，
不必把會隨擴縮變動的 VM IP 寫死在規則中。NSG 是狀態式連線追蹤，允許的連線
回應流量會自動放行；Network Watcher 則用來驗證實際有效規則與流量紀錄。
💡 架構師重點筆記：NSG 可以在 Subnet 與 NIC 兩個層級獨立配置。當外部流量流入時，必須先通過 Subnet NSG，再通過 NIC NSG，任一層級被 Deny 封包就立刻丟棄；當內部流量流出時，順序正好相反（先評估 NIC NSG，再評估 Subnet NSG）。
┌────────────┬──────────────────────────────┬──────────────────────────────┐
│ 比較維度 │ AWS Security Group (SG) │ Azure NSG (安全群組) │
├────────────┼──────────────────────────────┼──────────────────────────────┤
│ 套用層級 │ ENI / Instance 網卡層級 │ Subnet 或 NIC (網卡) │
│ 狀態機制 │ Stateful（連線追蹤回程） │ Stateful（連線追蹤回程） │
│ 規則模型 │ 僅允許規則 (Allow-only) │ Allow / Deny 雙向支援 │
│ 優先順序 │ 無序號；任一符合即放行 │ Priority 100-4096 小者優先 │
│ 預設收口 │ 未明確允許即隱式拒絕 │ 規則 65500 DenyAll 收口 │
│ 角色分組 │ SG Reference (參照其他SG) │ ASG (應用程式安全性群組) │
└────────────┴──────────────────────────────┴──────────────────────────────┘
💡 架構師重點筆記：AWS SG 只有「允許清單」，未符合者直接隱式拒絕；Azure NSG 則同時支援 Allow 與 Deny，且完全依靠 Priority（優先序） 由小到大評估，第一個符合的規則直接決定生死。
NSG 包含一組安全性規則，每條規則由六大要素構成：來源 (Source)、來源連接埠 (Source Port)、目的地 (Destination)、目的地連接埠 (Destination Port)、通訊協定 (Protocol：TCP/UDP/ICMP/Any) 以及 動作 (Action：Allow/Deny)。
每個 NSG 建立時，Azure 都會自動注入一組隱私預設規則（優先序由 65000 開始），負責維持基礎網路運作：
AllowVNetInBound (Priority 65000)：允許同一 VNet 內的所有資源互通。AllowAzureLoadBalancerInBound (Priority 65001)：允許 Azure 負載平衡器的健康探測封包進入。DenyAllInBound (Priority 65500)：全域拒絕收口！所有未被前面自訂規則允許的外部 Inbound 流量一律丟棄。AllowInternetOutBound (Priority 65001 Outbound)：預設允許向外連線至公開網際網路。Source: 0.0.0.0/0, Port: *, Action: Allow。在傳統資料中心，防火牆規則充斥著寫死的靜態 IP。一旦雲端資源彈性擴縮或微軟服務更換 IP，規則立刻失效或造成安全漏洞。Azure 提供了兩大高階抽象概念：
Internet（所有非私有位址）、VirtualNetwork（VNet 與所有對等互連網路）、AzureLoadBalancer（平台健康探測器）、Storage（Azure 儲存服務）、Sql（Azure SQL 服務）。Storage 標籤代表允許連往 Azure 儲存體服務，但具體能存取哪個 Storage 帳戶仍需靠 IAM 與金鑰把關。ASG-Web、ASG-API、ASG-DB）。ASG-Web 存取目的地 ASG-API 的 Port 8080」。對標 AWS Skill Builder 原廠標準，我們透過 Side-by-Side 程式碼解構 Azure NSG 規則的核心語法與屬性定義：
// Azure Bicep: 定義 NSG 並透過 ASG 宣告工作負載規則
resource nsgBackend 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
name: 'nsg-titan-backend'
location: 'eastus'
properties: {
securityRules: [
{
name: 'Allow-Web-To-API'
properties: {
priority: 110 // 數值小者優先
direction: 'Inbound'
access: 'Allow'
protocol: 'Tcp'
sourcePortRange: '*'
destinationPortRange: '8080'
// 使用 ASG 宣告來源，擺脫靜態 IP
sourceApplicationSecurityGroups: [
{
id: resourceId(
'Microsoft.Network/applicationSecurityGroups',
'asg-web'
)
}
]
destinationAddressPrefix: 'VirtualNetwork'
}
}
]
}
}
# AWS Terraform: 定義 Security Group 規則 (使用 SG Reference)
resource "aws_security_group_rule" "allow_web_to_api" {
type = "ingress"
from_port = 8080
to_port = 8080
protocol = "tcp"
security_group_id = aws_security_group.api_sg.id
# ⚠️ AWS 使用 source_security_group_id 參照前台 SG
source_security_group_id = aws_security_group.web_sg.id
}
安全的最後一哩路是驗證與觀測。Azure Network Watcher 是專為虛擬網路設計的原生診斷套裝服務：
Internet、AzureLoadBalancer）。Titan 科技的電商微服務包含：Web-Subnet（執行前端 VMSS）、API-Subnet（業務邏輯運算）以及 DB-Subnet（儲存後端）。
在即將上線的資安審查會議上，實習架構師提交了一份網路安全配置：
「為了方便排查問題，在 Web NIC 上開放 0.0.0.0/0:22（SSH）方便隨時連線；因為 NSG 掛在 Subnet 上很麻煩，我們把所有規則寫在 Web VM 的 Windows/Linux 本機防火牆裡；另外，因為 Azure 是狀態式網路，所以我們乾脆在 Outbound 把所有 Port 全封死，包含 DNS 與套件更新都不給出。」
CTO 聽完後轉向 Chief Cloud Architect（你）：「這份規則如果推向生產環境，我們的系統是不是連啟動更新都做不到，甚至會被公網掃描打穿？請提出符合最小權限原則的防禦性架構。」
ASG-Web 與 ASG-API 定義工作負載信任鏈；管理流量全面改走 Azure Bastion；Outbound 保持適度連網與內部 DNS 解析。方案 B 展現了微軟推薦的原廠深度防禦（Defense-in-Depth）最佳實踐：
ASG-Web ➔ ASG-API 形式表達，VM 彈性擴縮時完全不需要手動修改 IP 清單。本節收錄 5 題核心真題（3 題 ExamTopics 高頻題 ＋ 2 題 gratisexam 歷史題庫題），全數改寫為 Titan 科技情境，依原廠架構師思維鏈深入剖析。
Titan 科技計劃在 Azure 部署多台虛擬機器。網路安全管理員需要嚴格控制網際網路（Internet）上的裝置能夠存取這些虛擬機器的特定網路連接埠（Ports）。請問架構師應推薦使用哪項 Azure 服務？
【關鍵字識別】：control ports（控制連接埠）、devices on the Internet access VMs（外部連線存取）。
【核心考點定位】：第 3/4 層（L3/L4）網路流量過濾服務選型。
【陷阱識破】：雖然 Entra ID 負責身分安全，但它作用於身分平面，完全無法阻擋 TCP/UDP 傳輸層的網路連接埠掃描與連線。
【逐一排除干擾項】：
【關聯官方最佳實踐】：控制特定 IP 與 Port 進入 Azure VM 的標準原生工具就是 Network Security Group (NSG)。正解為 A。
來源與驗證：改寫自 ExamTopics Topic 1 Question 256（社群討論全數達成共識，真實 tally 票數 100% 投 A，討論區 Sandy4912 等資深架構師均強調 L4 封包過濾職責）；並經 Microsoft Learn：網路安全性群組概觀 交叉驗證確認。
Titan 科技的 Azure 環境包含多台虛擬機器。維運團隊需要確保名為 VM1 的虛擬機器能夠透過 HTTP（Port 80）接受來自網際網路的連線存取。
提案方案：修改 Azure Traffic Manager 的設定檔（Profile）。
請問這項方案是否能達成目標？
【關鍵字識別】：accessible over HTTP（透過 HTTP 存取）、Azure Traffic Manager。
【核心考點定位】：Traffic Manager 的本質與網路防火牆之職責劃分。
【陷阱識破】：許多初學者看見「Traffic（流量）」就以為它能放行流量。Azure Traffic Manager 是一個基於 DNS 的全域負載平衡器，它只負責將網域名稱解析為不同端點的 IP，根本不經手實際的資料封包，更不具備防火牆放行功能！
【逐一排除干擾項】：
【關聯官方最佳實踐】：Traffic Manager 僅操作 DNS 解析；開放存取必須修改 NSG 或 Azure Firewall。因此方案無法達成目標，正解為 B (No)。
來源與驗證：改寫自 ExamTopics 經典情境系列題 Topic 1 Question 217（社群討論高度共識，真實 tally 顯示 100% 判定 B (No)，置頂評論高達 68 次 upvotes 標明 Traffic Manager 僅為 DNS 層級服務）；並經 Microsoft Learn：什麼是 Traffic Manager 交叉驗證確認。
Titan 科技正在進行企業級架構重構，環境中包含了多個 Azure 訂用帳戶（Subscriptions）與十幾個虛擬網路（VNets）。資安長要求架構團隊推薦一項能夠「跨多個訂用帳戶與多個虛擬網路」提供集中式網路流量過濾與安全原則強制執行的服務。請問應選擇哪項服務？
【關鍵字識別】：filtering across multiple subscriptions and virtual networks（跨多個訂用帳戶與虛擬網路過濾）。
【核心考點定位】：Azure Firewall 與 NSG 的管理界限與防禦維度差異。
【陷阱識破】：NSG（D）與 ASG（B）只能作用在單一 VNet 內部，完全無法跨訂用帳戶或跨 VNet 集中管理與強制執行規則！
【逐一排除干擾項】：
【關聯官方最佳實踐】：Azure Firewall 是一項完全受管的雲端狀態式防火牆，具備內建高可用性與無限擴縮彈性，能夠透過 Azure Firewall Policy 集中跨多個訂用帳戶與 VNet 強制執行網路與應用程式過濾。正解為 A。
來源與驗證：改寫自 ExamTopics 核心架構題 Topic 1 Question 220（真實 tally 顯示 100% 支持 A (Azure Firewall)，社群一致釐清 NSG 屬於單一 VNet 本地防護，跨訂用帳戶必須仰賴 Azure Firewall）；並經 Microsoft Learn：什麼是 Azure 防火牆 交叉驗證確認。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q71 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，更新現行工作負載分組架構概念。
Titan 科技計劃在 Azure 上部署多台 Web 伺服器與多台 Database 伺服器。為了落實內部網路隔離，架構師需要推薦一項解決方案，用以嚴格限制「從 Web 伺服器到 Database 伺服器之間允許的網路連線類型與連接埠」。請問推薦方案中應包含什麼？
【關鍵字識別】：limit types of connections between web and database（限制層與層之間的連線類型）。
【核心考點定位】：多層式（Multi-tier）架構之內部隔離機制。
【陷阱識破】：Service Bus 是非同步訊息佇列 PaaS，不是網路過濾器；Local Network Gateway 用於代表地端機房 IP，與內部 VM 互聯無關。
【逐一排除干擾項】：
【關聯官方最佳實踐】：透過將 NSG 掛載於 Database Subnet（或搭配 ASG），設定 Inbound 僅允許來自 Web 層的特定資料庫連接埠（如 Port 1433/5432），其餘一律由預設規則 Deny。正解為 A。
來源與驗證：改寫自 2020 gratisexam Q71；並經 Microsoft Learn：使用網路安全性群組篩選網路流量 交叉驗證確認。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q64 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，聚焦於 NSG 規則修改實務。
在 Azure 中建立虛擬機器後，該虛擬機器的應用程式需要監聽並接受 TCP 連接埠 8080 的連線請求。請問架構師必須修改哪項資源的設定？
【關鍵字識別】：allow connections to TCP port 8080 on VM（允許連線至特定 TCP 連接埠）。
【核心考點定位】：自訂應用程式連接埠之放行通道。
【陷阱識破】：修改 Virtual Network（C）只能增減位址空間，無法放行特定的傳輸層連接埠；路由表（D）只管下一個躍點（Next Hop），不管連接埠檢查。
【逐一排除干擾項】：
【關聯官方最佳實踐】：在關聯於該 VM 網卡或子網路的 NSG 中，新增一條 Priority 較小（高優先權）的 Inbound 規則，將 Destination Port 設為 8080、Action 設為 Allow。正解為 A。
來源與驗證：改寫自 2020 gratisexam Q64；並經 Microsoft Learn：管理網路安全性群組規則 交叉驗證確認。
為了幫助具備 AWS 背景（CLF-C02 / SAA-C03）的雲端架構師建立扎實的雙向思維映射，我們整合 cxcxc-io 雲端架構圖庫（圖 3：VPC 手寫筆記 NACL vs SG 與 SG Reference）與 Gemini 深度研究報告，精選 2 題高頻經典網路安全性考題進行深度對照演練：
AWS 考題情境：
參考cxcxc-io圖 3 的手寫筆記對比：某架構師在 Amazon EC2 前配置了 Security Group，並在 Inbound 開放了 TCP Port 443（HTTPS）。然而，客戶端發送 HTTPS 請求後，該架構師發現在 Security Group 的 Outbound 並未放行任何連接埠，卻驚訝地發現客戶端依然能順利收到伺服器的回應封包。請問背後的原因為何？
A. Security Group 在偵測到 Port 443 流量時會自動在 Outbound 動態開啟對應連接埠
B. Security Group 是狀態式（Stateful）防火牆，底層連線追蹤機制會自動放行已建立連線的回應流量
C. 封包的回應路徑被自動重導向至 Network ACL 進行處理
D. 這是 AWS 平台的短暫 Bug，實際上必須在 Outbound 明確開啟 Ephemeral Ports (1024–65535)
- AWS 解題思維：正確答案為 B。在
cxcxc-io圖 3 的筆記中特別強調：Security Group 是 Stateful，連線一旦被 Inbound 允許，其雙向回應流量自動暢通；相反地，Network ACL (NACL) 是 Stateless（無狀態），若在 NACL 擋了 Outbound 臨時連接埠，回應封包將被直接丟棄。- 🔄 Azure 知識映射：這正是資深 AWS 架構師轉戰 Azure 最常踩的肌肉記憶陷阱！
在 AWS 中，只有掛在網卡（ENI）上的 SG 是狀態式，掛在子網路上的 NACL 是無狀態；但在 Azure 中，Network Security Group (NSG) 無論套用在 Subnet 還是 NIC，通通都是狀態式（Stateful）！
因此，在 Azure Subnet NSG 中允許了 Inbound 443 後，千萬不要在 Outbound 畫蛇添足地手動開放大範圍的臨時連接埠，否則只會無謂鑿出允許木馬反向連線的安全漏洞。
AWS 考題情境：
某三層式 Web 應用包含數十台 Web 伺服器與多台後端資料庫伺服器，所有 Web 伺服器隨 Auto Scaling Group 動態增減，IP 位址隨時變動。為達成最小權限隔離，架構師希望「資料庫僅接受來自 Web 伺服器的 Port 3306 連線」，且不希望每次 Web 伺服器擴縮時都手動修改資料庫防火牆規則。應如何設計？
A. 在資料庫的 Security Group Inbound 規則中，將 Source 指定為 Web 伺服器的 Security Group ID（SG Reference）
B. 必須將所有 Web 伺服器配置 Elastic IP (EIP)，並將這些固定 IP 寫進資料庫規則
C. 在資料庫 Subnet 配置 NACL，將來源設為整個 VPC 的 CIDR 網段
D. 在 Web 與 Database 之間架設 NAT Gateway 進行 IP 偽裝
- AWS 解題思維：正確答案為 A。AWS Security Group 支援相互參照（SG Reference）：直接將來源設為
sg-xxxxxx。如此一來，任何掛載該 Web SG 的 EC2 實體都能自動獲得存取權，徹底擺脫維護動態 IP 的夢魘。- 🔄 Azure 知識映射：這正是 Azure Application Security Group (ASG) 的核心價值！
- AWS SG Reference ➔ Azure Application Security Group (ASG)
在 Azure 中，NSG 本身不支援「以另一個 NSG 作為來源」，微軟特地設計了 ASG 作為角色標籤（如ASG-Web➔ASG-DB）。
但必須牢記 Gemini 深度研究報告所提醒的原廠硬性邊界：加入同一個 ASG 的所有虛擬網卡（NIC），必須位於「同一個 Virtual Network」之內，無法跨 VNet 參照！
┌──────────────────────────────────────────────────────────┐
│ cxcxc-io 圖 3 概念對照：AWS SG Reference vs Azure ASG │
├──────────────────────────────────────────────────────────┤
│ AWS 模式 (Security Group Reference 角色參照) │
│ [Web EC2] ──(掛載 web-sg)──► [DB EC2] (掛載 db-sg) │
│ • Inbound: Allow web-sg:3306│
│ │
│ Azure 模式 (Application Security Group 角色分組) │
│ [Web VM] ──(加入 ASG-Web)──► [DB VM] (加入 ASG-DB) │
│ • NSG: Allow ASG-Web:1433 │
│ • 鐵律：必須在同一個 VNet │
└──────────────────────────────────────────────────────────┘
| 項目 | 內容 |
|---|---|
| 對應課程章節 | 第 2 章 ▸ Public vs Private Endpoint、NSG、Azure DNS / Private DNS（p88–90） |
| 官方考綱領域 | Describe Azure Architecture & Services（占比 35–40%） |
| 課程涵蓋範圍 | Public 與 Private Endpoint、NSG、Azure DNS / Private DNS 的基本定位 |
| 本文補充範圍 | Microsoft Learn 的 NSG 雙層過濾模型（Subnet vs NIC）、Priority 決策鏈與預設規則收口；Stateful 狀態式連線追蹤機制；Service Tag 與 ASG 工作負載分組實務（課程完全未涵蓋 ASG，本文完整補充）；AWS SG/NACL 跨雲對照；Network Watcher 流量觀測與診斷 |
⚠️ 課程缺口說明：Application Security Group (ASG) 與 Network Watcher Flow Logs 在課程教材中完全未收錄，但皆為官方考試與實務架構極高頻的關鍵概念，本文已依微軟官方 Microsoft Learn 標準補齊。
ASG-Web ➔ ASG-API 取代逐台維護 IP 清單，杜絕組態漂移；記住鐵律：加入同一 ASG 的網卡必須位於「同一個 VNet」。城牆與門禁規則確立後，Titan 科技邁向混合雲的終極戰役即將展開：如何將地端企業總部與資料中心，以高可用且合規的通道接入 Azure？
明天進入 Day 13：Azure ExpressRoute & VPN Gateway。我們將深度拆解公網加密通道（Site-to-Site VPN）與專屬私有光纖直連（ExpressRoute）在延遲、SLA、成本以及交付前置時間上的巨大鴻溝，敬請期待！
iThome鐵人賽
看影片追技術