本文說明如何透過網路安全群組（NSG）進行流量過濾來控制 Azure 虛擬網路中的網路流量。 它也涵蓋用於邏輯網路介面分組的應用程式安全群組（ASG）。
本文涵蓋的內容
網路安全性群組可讓您篩選 Azure 虛擬網路中資源的輸入和輸出流量。 應用程式安全群組讓你依角色來分組網路介面。 撰寫 NSG 規則，參考邏輯群組而非個別 IP 位址。
誰需要這篇文章
如果你符合以下情況，請閱讀這篇文章：
- 部署任何連接到 Azure 虛擬網路的資源。
- 需要控制子網路、虛擬機或 Azure 服務之間的流量。
- 想要簡化規則管理，適用於虛擬機頻繁擴充或 IP 位址變動的環境。
- 正在為新的 Azure 工作負載建立安全基線。
隨即轉移焦點： 將內部部署防火牆與分段規則重建為子網路之間的 NSG，對應到應用程式已在使用的各層級間流量。
現代化焦點： 使用應用程式安全群組以工作負載角色來表達規則，而非依 IP 位址，並將子網 NSG 與集線器防火牆及使用者自訂路由配對，強制檢查出口。
跨雲焦點：將 AWS 和 Google Cloud 的安全群組規則鏡像到 Azure NSG，讓流量政策在工作負載間移動時保持一致。
Azure 服務與功能
下表說明了 Azure 虛擬網路中用於網路流量過濾的服務與功能。
| 服務或功能 | 它所提供的是什麼 | 何時使用它 |
|---|---|---|
| 網路安全性群組 (NSG) | 一套套用於子網或網路介面的入站與出站安全規則。 規則依優先權評估：最低點數獲勝。 | 控制子網路或個別虛擬機層級的流量。 對所有使用虛擬網路的工作負載都適用。 |
| 應用程式安全群組（ASG） | 一個邏輯上的網路介面群組。 在 NSG 規則中，使用 ASG 作為來源或目的地，而非 IP 位址。 | 你有多個虛擬機扮演相同角色（網頁伺服器、應用程式伺服器），它們的 IP 位址會隨擴展而改變。 所有分組的網卡必須位於同一虛擬網路中。 |
| 服務標籤 | Azure 服務的命名 IP 位址前綴群組，由 Microsoft 自動管理與更新。 範例：AzureCloud、Storage、AzureLoadBalancer、Sql。 |
在 NSG 規則中參照 Azure 服務，而無需將 IP 範圍硬式編碼。 Microsoft 會自動更新底層的 IP 範圍。 你無法建立自訂服務標籤。 |
常見服務標籤
下表列出 NSG 規則中最常用的服務標籤。
| 服務標記 | Description |
|---|---|
Internet |
虛擬網路外的所有公共 IP 位址空間。 匹配任何來自或流向公共網際網路的流量。 |
VirtualNetwork |
你的虛擬網路位址空間、所有連接的位址空間（對等 VNet）、透過 VPN/ExpressRoute 連接的本地網路，以及任何服務端點。 包含預設路線。 |
AzureLoadBalancer |
Azure 基礎結構負載平衡器 這也代表 Azure 健康探測器起源的主機虛擬 IP。 用於輸入規則中允許健全狀態探查流量。 |
Storage |
Azure 儲存體 服務 IP 位址空間。 支援區域變體，如 Storage.WestUS2。 使用來允許或限制從 VNet 內部存取 Azure 儲存體。 |
AzureCloud |
所有 Azure 資料中心的公共 IP 位址。 支援區域變體，如 AzureCloud.EastUS。 適合用於允許一般 Azure 服務的輸出流量。 |
Sql |
Azure SQL Database、適用於 MySQL 的 Azure 資料庫、適用於 PostgreSQL 的 Azure 資料庫、適用於 MariaDB 的 Azure 資料庫，以及 Azure Synapse Analytics IP 位址前置詞。 支援區域變體。 |
| 增強安全規則 | 擴展的 NSG 規則，允許在同一規則中包含多個 IP 位址、IP 範圍及埠口。 當你需要允許或拒絕多個 IP 或埠口範圍的流量時，減少規則數量。 支援每個規則的多個 IP 和埠範圍，最多支援 10 個應用程式安全群組，但每個規則僅支援一個服務標籤。 |
如何選擇
請參考以下指引，為您的情況選擇合適的安全架構。
NSG限制與配額
Azure 對 NSG 資源執行以下預設限制。 要提高大部分限制，請透過 Azure 支援 申請提高。
| 資源 | 預設限制 | 上限 |
|---|---|---|
| 各 NSG 的規則 | 2,000 | 2,000 |
| 每個訂用帳戶的 NSG 數量 | 5,000 | 5,000 |
| 每個子網路的 NSG | 1 | 1 |
| 每個 NIC 的 NSG | 1 | 1 |
| 每個訂用帳戶的 ASG 數量 | 3,000 | 3,000 |
| 每個 ASG 的網卡數 | 依訂閱方式而異 | 聯絡客服 |
| 每條規則中參考做為來源或目的地的 ASG | 10 | 10 |
Note
每個 NSG 的 2,000 條規則限制包含自訂規則與預設規則。 如果你接近這個限制，可以使用增強安全規則，將多個 IP 或埠口範圍合併成更少的規則。
NSG 與 ASG：何時使用
請參考下表，找出最適合你情境的安全架構。
| 狀況 | 使用 | 原因為何 |
|---|---|---|
| 控制子網中所有虛擬機的流量 | 子網路層級的 NSG | 一個 NSG 適用於子網中的每一個資源。 對於整合原則，管理起來最為簡便。 |
| 可獨立於其子網路控制特定虛擬機器的流量 | NIC 層級的網路安全性群組（NSG） | 允許例外且不影響其他虛擬機。 適合用於跳板機或堡壘主機。 |
| 許多虛擬機扮演相同角色，且 IP 位址經常更換 | ASG | 依角色（網頁、應用程式、資料）將虛擬機加入群組。 撰寫針對群組名稱的規則。 虛擬機擴展或取得新 IP 時不需要更新。 |
| 參考 Azure 服務（Storage、SQL、金鑰保存庫）作為來源或目的地 | 具有服務標籤的 NSG | 避免將 Microsoft 可能更新的 IP 範圍硬編碼。 服務標籤會自動保持最新狀態。 |
下圖展示了 ASG 如何讓你依角色分組虛擬機，並在邏輯群組間撰寫 NSG 規則，而非單一 IP 位址。
安全態勢檢查清單
部署到生產環境前，請依此清單驗證你的 NSG 設定。
| Requirement | Action | Reference |
|---|---|---|
| 預設-拒絕姿勢 | 確認你是否依賴預設 DenyAllInbound 規則（優先權 65500）。 不要建立會繞過預設拒絕原則的過於寬泛的「全部允許」規則。 |
安全性考量 |
| 管理埠無法上網 | 封鎖來自 0.0.0.0/0 SSH （22） 和 RDP（3389） 的入站流量。 管理權限請使用 Azure Bastion 或 VPN。 |
安全性考量 |
| 與 Azure 防火牆 結合進行深度檢查 | NSG 僅在第 3 層和第 4 層進行篩選。 新增 Azure 防火牆 用於應用層（第 7 層）過濾、TLS 檢查及威脅情報。 | Azure 防火牆 and network segmentation |
| 啟用流量日誌以進行診斷 | 使用 VNet 流程記錄來擷取流量資料，以便安全調查與合規。 | 網路監控與診斷 |
規則評估順序
NSG 規則使用首場獲勝即勝的語意：
- Azure 依優先順序評估規則：最低數（最高優先權）先行。
- Azure 會依據五元組來評估每條規則：來源、來源埠、目的地、目的地埠和通訊協定。
- 當流量符合規則時，處理會停止。 Azure 不會評估後續規則。
- 若自訂規則不符，則適用預設規則。 預設規則無法刪除，但可以透過建立優先順序號介於 100 到 4096 之間的自訂規則來覆蓋預設規則。
預設規則（共六條）：
| 方向 | 規則名稱 | Priority | Action |
|---|---|---|---|
| Inbound | AllowVNetInBound | 65000 | 允許 |
| Inbound | AllowAzureLoadBalancerInBound | 65001 | 允許 |
| Inbound | DenyAllInbound | 65500 | Deny |
| 外發 | AllowVnetOutBound | 65000 | 允許 |
| 外發 | AllowInternetOutBound | 65001 | 允許 |
| 外發 | DenyAllOutBound | 65500 | Deny |
ASG 限制
使用應用程式安全群組時，請注意以下限制條件：
- ASG 中的所有網路介面必須與第一個分配給 ASG 的網路介面存在於同一虛擬網路中。
- 如果您在規則的來源和目的地中都參考 ASG，則這兩個群組中的網路介面都必須位於同一個虛擬網路中。
- 你可以在規則的來源或目的地中引用最多 10 個 ASG。
子網路層級與網路介面層級的 NSG 同時使用
你可以將 NSG 與子網路及該子網路中的虛擬機介面關聯。 當你這樣做時，Azure 會評估兩個 NSG，流量必須同時通過。 限制最嚴格的組合獲勝。
| 方向 | 首次評估 | 第二次評估 |
|---|---|---|
| Inbound | 子網路 NSG | NIC NSG |
| 外發 | NIC NSG | 子網路 NSG |
Tip
為了更簡單的故障排除，建議將 NSG 與子網路或網路介面之一關聯，但不要同時關聯兩者。 如果你需要兩者，請清楚記錄預期的規則互動。
實務範例：帶有跳線盒的網頁層
假設一個子網路有子網路層級的 NSG，則允許網際網路的 HTTPS (連接埠 443) 輸入，其他所有東西都被拒絕。 該子網路中的跳板機 VM 在網路介面層級設有 NSG，並且允許來自特定管理 IP 範圍的輸入 SSH 流量 (連接埠 22)。
-
網路流量（埠 443）： 子網 NSG 允許這樣做。 網路虛擬機上的網路介面 NSG 對 443（預設
AllowVNetInBound許可）沒有拒絕規則。 流量正常運作。 - SSH 連接跳板機 (管理 IP 的連接埠 22)：子網路 NSG 會拒絕連接埠 22 的網路流量。 儘管網路介面 NSG 允許管理範圍內的 SSH，但子網 NSG 會先阻擋該範圍。 解決：在子網 NSG 中加入規則，允許管理 IP 範圍的第 22 埠，或使用 Azure Bastion 完全繞過公共網路路徑。
此例子說明了雙重國家安全組（NSG）為何會增加複雜度。 兩者都必須獨立允許流量。
下圖顯示當您同時將子網路 NSG 和 NIC NSG 建立關聯時的輸入流量評估路徑。 流量必須通過這兩個 NSG。 限制最嚴格的組合獲勝。
Azure 虛擬網路管理員互動
如果您的組織使用 Azure Virtual Network Manager（AVNM）的安全管理規則，Azure 會先評估這些規則，然後再評估 NSG 規則。 安全管理規則可為允許（繼續至 NSG 評估）、始終允許（繞過 NSG）或拒絕（在 NSG 評估前封鎖）。 關於集中式網路安全管理，請參見 Azure Virtual Network Manager 與集中管理。
設計考量
隨即轉移 NSG 與 ASG 設計焦點
- 將你的本地區域分段轉換成子網層級的 NSG：只允許應用程式已使用的層對層流程（例如網頁到應用程式和應用程式到資料庫），其他一切則不允許。
- 從你目前的防火牆規則庫開始，遷移後再加強，利用 NSG 的流程日誌確認哪些流程是真正需要的。
- 為了簡化，請先在子網層級套用 NSG;僅在個別虛擬機需要例外時，才加入網卡層級規則。
- 使用服務標籤（如
VirtualNetwork和AzureLoadBalancer）取代硬編碼的 IP 位址，讓規則在遷移時能存活。
現代化 NSG 與 ASG 設計焦點
- 使用應用程式安全群組依角色（網頁、應用程式、資料）分組網路介面，讓規則描述意圖並隨著實例擴展自動調整。
- 將子網 NSG 與樞紐結合 Azure 防火牆：NSG 負責層級間的微分段，而防火牆則檢查跨越信任邊界的流量。
- 允許只有私有端點子網能存取 PaaS 服務，並強制外出流量透過由使用者自訂路由的樞紐防火牆傳送。
- 如果你使用 Azure Virtual Network Manager 的安全管理規則，請規劃它們的優先順序（它們會在 NSG 之前評估），這樣平台範圍的防護欄就不會與工作負載 NSG 衝突。
跨雲 NSG 與 ASG 設計重點
- 將 AWS 和 Google Cloud 的安全群組規則鏡像到 Azure NSG，讓等效層級在遷移後執行相同的政策。
- 只允許跨雲應用程式相依所需的特定埠口與來源，並將這些流量路由經過檢查的 IPsec 隧道。
- 在雲端間標準化應用程式安全群組名稱，讓營運團隊在排除故障時能對應同等的工作負載。
- 將 NSG 與安全的 Virtual WAN 集線防火牆配對，讓跨雲端與分支流量同時被 NSG 過濾並由防火牆檢查。
先決條件
在實施 NSG 與 ASG 之前，請確保具備：
- 一個包含子網路的虛擬網路： NSG 會附加到虛擬網路中的子網路或 NIC。 請參閱 虛擬網路與子網 以獲取規劃指引。
- IP 位址方案： NSG 規則會參考 IP 位址和範圍。 智慧財產權計畫確保你能制定精確的規則。 請參閱 IP 位址規劃 以獲得指引。
- 以下是所需交通流量清單： 在撰寫規則前，先記錄哪些資源需要通訊、在哪些埠口以及朝向哪個方向。
安全性考慮
Important
預設否認才是正確的態度。 Azure 的預設入站規則會拒絕所有未明確允許的網路流量。 不要因為制定寬鬆的許可規則而削弱這種立場。
絕對不要對管理埠開放 0.0.0.0/0
注意事項
切勿建立允許來自 0.0.0.0/0（網際網路上的任何來源）之輸入流量，並透過 SSH（連接埠 22）或 RDP（連接埠 3389）等管理連接埠進入的 NSG 規則。 攻擊者持續掃描網路，尋找開放的管理埠。 相反地，請使用 Azure Bastion、VPN 或 Azure Private Link 來安全存取虛擬機。
結合 NSG 與 Azure 防火牆
NSG 在第 3 層和第 4 層（網路與傳輸）運作。 它們會根據 IP 位址、埠口和協定來過濾，但不會檢查封包內容。 對於需要應用層過濾、威脅情報或 TLS 檢查的工作負載，請與 NSG 同時部署 Azure 防火牆。 請參閱 Azure 防火牆 與網路分段。
使用 VNet 流量日誌來提升流量可見性
Note
NSG 流量記錄預計於 2027 年 9 月 30 日淘汰。 2025 年 6 月 30 日之後，無法建立新的 NSG 流量日誌。 遷移到 VNet 流量日誌，提供相同功能外，還有虛擬網路層級的流量分析。
VNet 流程日誌可擷取虛擬網路中所有工作負載的每個流程狀態與吞吐量資料。 它們用於：
- 安全調查：識別意外流量模式。
- 合規稽核：證明交通流量符合文件化政策。
- 容量規劃：了解子網間的頻寬消耗。
關於監控與診斷的配置，請參見 網路監控與診斷。
應避免的常見錯誤
| 錯誤 | 為什麼這是個問題 | 更好的方法 |
|---|---|---|
建立允許所有入站規則（優先權 100、來源 *、目的地 *） |
繞過預設拒絕態勢，將所有資源暴露於網際網路流量之下。 | 只允許特定的來源/目的地/埠組合。 使用可行的最高優先順序來設定允許規則。 |
| 忘了預設拒絕原則的存在 | 團隊會為已知流量建立允許規則，但不會測試其他流量是否被封鎖。 無意中開啟的埠口可能會被忽略。 | 部署 NSG 後，使用 VNet 流量記錄或 NSG 診斷確認只有預期流量。 明確測試被拒絕的路徑。 |
| 不使用 ASG 來處理動態工作負載 | 當虛擬機擴展或取得新 IP 時，基於 IP 的規則就會失效。 隊伍會不斷更新規則。 | 用 ASG 將虛擬機依角色分組。 參照 ASG 的規則在虛擬機器新增至群組或從群組移除時仍然有效。 |
| 忽略流程日誌直到安全事件發生 | 若不啟用流量日誌，您將無法獲得歷史交通資料，供調查或合規稽核使用。 | 從第一天起就啟用 VNet 流程日誌。 配置流量分析系統，以視覺化並警示異常現象。 |
| 在無文件的情況下同時套用子網與 NIC NSG | 雙重 NSG 會造成混亂的互動，導致流量意外被拒絕。 排除故障會變得非常耗時。 | 選擇子網路層級或網卡層級的 NSG 作為標準。 若兩者皆需，請記錄每個子網的預期互動方式。 |
相關文章
- 虛擬網路與子網：你在哪裡應用 NSG
- Azure 防火牆 與網路區隔：第 7 層檢測，補強 NSG 功能
- 網路監控與診斷：VNet 流量日誌與 NSG 診斷
- Azure Virtual Network Manager 與集中管理：安全管理規則與集中式 NSG 管理
瞭解更多資訊
下一步
Tip
自己探索？ 回到 總覽導航 器，依能力尋找你的下一篇文章。
您的隨即轉移之旅的下一步：
設計你的樞紐輻射式拓撲：將 DNS、防火牆和 VPN 閘道 等共享服務集中在遷移後的工作負載中。
接下來的現代化旅程：
設計您的 hub-and-spoke 拓撲：為您的 PaaS 工作負載建置雙 hub 拓撲，由 IT 團隊管理的 hub 與應用程式團隊管理的 spoke 所組成。
接下來的跨雲端旅程：
設定加密隧道連接其他雲端：設定 VPN 閘道 連接至 Amazon Web Services （AWS）、虛擬私人閘道和 Google Cloud VPN 進行跨雲傳輸。