AWS 網路安全雙防線：NACL 與 Security Group 完全指南

在 AWS 雲端環境中，保護您的資源安全是最重要的課題之一。

AWS 提供了兩層防火牆機制來保護您的資源：NACL（Network Access Control List） 和 Security Group。

許多初學者常常搞不清楚這兩者的差異，甚至不知道它們各自綁定在哪個層級上。

本文將用最淺顯易懂的方式，帶您完整了解：

• NACL 和 Security Group 各自的功能與定位
• 它們分別綁定在哪個網路元件上
• 兩者之間的關鍵差異
• 實際的流量控制運作流程

無論您是剛接觸 AWS 的新手，還是想釐清這兩個觀念的學習者，這篇文章都能幫助您建立正確且完整的知識架構。

核心概念：兩道防線的定位

一句話總結

NACL 是 Subnet（子網路）的防火牆；Security Group 是 ENI（網卡）的防火牆。

這是理解整個 AWS 網路安全架構最重要的一句話。只要記住這個原則，就能清楚知道該在哪個層級設定哪種防火牆規則。

graph TB
    subgraph VPC["VPC (Virtual Private Cloud)"]
        subgraph Subnet["Subnet (子網路)"]
            NACL["🔒 NACL<br/>(Network ACL)<br/>綁定在 Subnet"]

            subgraph EC2_Instance["EC2 實例"]
                ENI["網卡 (ENI)"]
                SG["🔐 Security Group<br/>綁定在 ENI"]
                Instance["EC2<br/>運算資源"]
            end
        end
    end

    Internet["🌐 網際網路"] --> NACL
    NACL --> SG
    SG --> ENI
    ENI --> Instance

    style NACL fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style SG fill:#99ccff,stroke:#0066cc,stroke-width:3px
    style Subnet fill:#fff9e6,stroke:#ffcc00,stroke-width:2px
    style ENI fill:#e6f3ff,stroke:#0066cc,stroke-width:2px

架構說明：

• 🔒 NACL 在 Subnet 層級，保護整個子網路
• 🔐 Security Group 在 ENI 層級，保護個別資源
• 流量必須依序通過 NACL → Security Group 才能到達 EC2 實例

什麼是綁定層級？

在 AWS 的網路架構中，不同的安全機制會「綁定」在不同的網路元件上：

• Security Group：綁定在 ENI（Elastic Network Interface，彈性網路介面） 上，也就是每個 EC2、RDS 等資源的網卡
• NACL：綁定在 Subnet（子網路） 上，保護整個子網路內的所有資源

用生活化的比喻理解

想像一下：進入您家之前，訪客必須先通過社區大門（NACL）的檢查，進入社區後，還要有正確的鑰匙才能打開您家的門鎖（Security Group），最終才能進入您家（EC2 實例）。

深入認識 NACL（Network Access Control List）

NACL 是什麼？

NACL（Network Access Control List）是一種「無狀態的防火牆」，專門用來保護整個 Subnet 的進出流量。

重要特性：

• 綁定在 Subnet 層級
• 無狀態（Stateless）機制
• 可以設定「允許」和「拒絕」規則
• 控制所有進出該 Subnet 的流量

Subnet 與 NACL 的綁定關係

綁定規則：

• ✅ 一個 Subnet 只能綁定一個 NACL
• ✅ 一個 NACL 可以同時保護多個 Subnet

graph TB
    subgraph VPC["VPC"]
        NACL1["🔒 NACL-A"]
        NACL2["🔒 NACL-B"]

        subgraph Subnet1["Subnet-1"]
            EC2_1["EC2"]
            RDS_1["RDS"]
        end

        subgraph Subnet2["Subnet-2"]
            EC2_2["EC2"]
            Lambda["Lambda"]
        end

        subgraph Subnet3["Subnet-3"]
            EC2_3["EC2"]
            ECS["ECS"]
        end
    end

    NACL1 -.綁定.-> Subnet1
    NACL1 -.綁定.-> Subnet2
    NACL2 -.綁定.-> Subnet3

    Subnet1 --> EC2_1
    Subnet1 --> RDS_1
    Subnet2 --> EC2_2
    Subnet2 --> Lambda
    Subnet3 --> EC2_3
    Subnet3 --> ECS

    style NACL1 fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style NACL2 fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style Subnet1 fill:#e6f7ff,stroke:#0066cc,stroke-width:2px
    style Subnet2 fill:#e6f7ff,stroke:#0066cc,stroke-width:2px
    style Subnet3 fill:#e6f7ff,stroke:#0066cc,stroke-width:2px

圖例說明：

• 🔒 NACL-A 同時保護 Subnet-1 和 Subnet-2（一對多關係）
• 🔒 NACL-B 只保護 Subnet-3（一對一關係）
• 每個 Subnet 內的所有資源（EC2、RDS、Lambda 等）都會被該 NACL 影響

NACL 的重要特性：無狀態（Stateless）

「無狀態」是 NACL 最重要的特性，也是最容易被忽略的細節：

什麼是無狀態？

• NACL 不會記住之前的連線狀態
• 進站（Inbound）和出站（Outbound）規則必須分別設定
• 即使是「回應流量」，也需要明確的規則允許

實際範例：

假設您允許外部流量從 Port 80 進入 Subnet：

• 您必須設定 Inbound 規則允許 Port 80
• 同時也要設定 Outbound 規則允許回應流量（通常是隨機高端口，如 1024-65535）

預設 NACL 的行為

⚠️ 重要提醒：
如果您沒有手動修改過，AWS 為您建立的預設 NACL 是「全開放」的：

• 預設允許所有 Inbound 流量
• 預設允許所有 Outbound 流量

這意味著在預設情況下，NACL 不會阻擋任何流量，實際的安全控制會交由 Security Group 來負責。

Security Group 回顧

Security Group 的綁定位置

如前面提到的，Security Group 是綁定在 ENI（網卡）上，而不是 Subnet。

關鍵要點：

• 每個 EC2 實例都有至少一張 ENI
• Security Group 直接保護這張網卡
• 可以更細緻地控制每個資源的流量

Security Group 的重要特性：有狀態（Stateful）

「有狀態」是 Security Group 與 NACL 最大的差異：

什麼是有狀態？

• Security Group 會記住連線狀態
• 如果您允許一個 Inbound 請求，對應的 Outbound 回應會自動被允許
• 反之亦然：允許 Outbound 請求，Inbound 回應也會自動放行

實際範例：

假設您允許外部流量從 Port 80 進入 EC2：

• 您只需設定 Inbound 規則允許 Port 80
• 回應流量會自動被允許，不需要額外設定 Outbound 規則

Security Group 只能設定「允許」規則

與 NACL 不同，Security Group 只能設定允許規則，沒有明確的「拒絕」規則：

• 預設拒絕所有流量
• 只有明確允許的流量才能通過
• 採用「白名單」機制

NACL vs Security Group：關鍵差異對照表

流量控制的完整流程

流量進入 AWS 資源的路徑

當外部流量要進入您的 EC2 實例時，必須依序通過兩道防線：

🌐 外部流量
    ↓
1️⃣ NACL (Subnet 層級檢查)
    ↓ 允許通過
2️⃣ Security Group (ENI 層級檢查)
    ↓ 允許通過
3️⃣ EC2 實例

🌐 外部流量
    ↓
1️⃣ NACL (Subnet 層級檢查)
    ↓ 允許通過
2️⃣ Security Group (ENI 層級檢查)
    ↓ 允許通過
3️⃣ EC2 實例

詳細說明：

1. 第一關：NACL

• 檢查流量是否符合 Subnet 層級的 Inbound 規則
• 如果被拒絕，流量直接丟棄，不會進入 Subnet

2. 第二關：Security Group

• 檢查流量是否符合 ENI 層級的 Inbound 規則
• 如果被拒絕，流量無法抵達 EC2 實例

3. 到達目標

• 只有通過兩道檢查的流量，才能真正進入 EC2 實例

流量離開 AWS 資源的路徑

當 EC2 實例的回應流量要送出時，也必須經過兩道檢查：

EC2 實例
    ↓
1️⃣ Security Group (ENI 層級檢查)
    ↓ 允許通過
2️⃣ NACL (Subnet 層級檢查)
    ↓ 允許通過
🌐 送出到外部

EC2 實例
    ↓
1️⃣ Security Group (ENI 層級檢查)
    ↓ 允許通過
2️⃣ NACL (Subnet 層級檢查)
    ↓ 允許通過
🌐 送出到外部

重要差異：

• Security Group（有狀態）：如果 Inbound 請求被允許，對應的 Outbound 回應會自動放行
• NACL（無狀態）：即使是回應流量，也必須有明確的 Outbound 規則允許

實際案例分析

情境：允許外部 HTTP 流量訪問 EC2

NACL 設定（無狀態，需設定兩個方向）：

• Inbound Rule：允許來源 0.0.0.0/0 的 Port 80 流量
• Outbound Rule：允許目的地 0.0.0.0/0 的 Port 1024-65535（回應使用的隨機端口）

Security Group 設定（有狀態，只需設定一個方向）：

• Inbound Rule：允許來源 0.0.0.0/0 的 Port 80 流量
• Outbound：不需額外設定，回應會自動放行

Security Group 與 Network ACL 對比詳解

Security Group

Security Group 是最常用的防火牆，作用在 EC2 實例層級。

SSH 連線範例

需求：允許從你的電腦 SSH 登入 EC2

Security Group Inbound 設定：

常見錯誤：

❌ 錯誤 1：Source 設為 0.0.0.0/0
   → 風險：任何人都可以嘗試 SSH（安全隱患）

❌ 錯誤 2：忘記開 Port 22
   → 結果：Connection Refused

❌ 錯誤 3：Protocol 選錯（選到 UDP）
   → 結果：無法連線

❌ 錯誤 1：Source 設為 0.0.0.0/0
   → 風險：任何人都可以嘗試 SSH（安全隱患）

❌ 錯誤 2：忘記開 Port 22
   → 結果：Connection Refused

❌ 錯誤 3：Protocol 選錯（選到 UDP）
   → 結果：無法連線

Web 伺服器範例

需求：讓任何人都能造訪你的網站

Security Group Inbound 設定：

Network ACL

Network ACL 作用在 Subnet 層級，提供額外的安全保護。

何時需要設定 NACL：

• ✅ 需要明確拒絕某些 IP 範圍
• ✅ 需要 Subnet 層級的統一管制
• ✅ 企業合規要求多層防護
• ✅ 防止 DDoS 攻擊（封鎖可疑來源）

NACL 規則範例（Web Server Subnet）

Inbound 規則：

Outbound 規則：

重要觀念：為什麼需要 1024-65535？

客戶端連線流程：
1. 客戶端用隨機 Port（例如 54321）連到 Server 的 Port 80
2. Server 回應時，目的地是客戶端的 54321 Port
3. NACL 是 Stateless，所以 Outbound 要開 1024-65535（臨時 Port 範圍）

這就是為什麼 NACL 設定比 Security Group 複雜！

客戶端連線流程：
1. 客戶端用隨機 Port（例如 54321）連到 Server 的 Port 80
2. Server 回應時，目的地是客戶端的 54321 Port
3. NACL 是 Stateless，所以 Outbound 要開 1024-65535（臨時 Port 範圍）

這就是為什麼 NACL 設定比 Security Group 複雜！

Stateful vs Stateless 實際案例：

場景：客戶端從 Port 54321 連到 EC2 的 Port 80

Security Group（Stateful）：
✅ Inbound: 允許 Port 80
✅ Outbound: 自動允許回應（不用設定）

Network ACL（Stateless）：
✅ Inbound: 允許 Port 80
✅ Outbound: 必須允許 Port 54321（或整個範圍 1024-65535）
❌ 如果忘記設定 Outbound，連線會失敗！

場景：客戶端從 Port 54321 連到 EC2 的 Port 80

Security Group（Stateful）：
✅ Inbound: 允許 Port 80
✅ Outbound: 自動允許回應（不用設定）

Network ACL（Stateless）：
✅ Inbound: 允許 Port 80
✅ Outbound: 必須允許 Port 54321（或整個範圍 1024-65535）
❌ 如果忘記設定 Outbound，連線會失敗！

常見問題解答

一個 Subnet 可以綁幾個 NACL？

❌ 只能綁定一個 NACL

每個 Subnet 在同一時間只能綁定一個 NACL。如果您需要更改，可以將 Subnet 重新關聯到另一個 NACL，但無法同時使用多個。

一個 NACL 可以綁幾個 Subnet？

✅ 可以綁定多個 Subnet

一個 NACL 可以同時保護多個 Subnet。這在您需要對多個子網路套用相同安全政策時非常有用。

NACL 控制哪一層的流量？

✅ 控制整個 Subnet 的流量

NACL 在 Subnet 層級運作，會影響該 Subnet 內所有資源（EC2、RDS、Lambda 等）的流量。

NACL 與 Security Group 需要一起使用嗎？

✅ 通常會一起使用，形成兩道防線

最佳實踐是：

• 使用 NACL 提供 Subnet 層級的基礎防護
• 使用 Security Group 提供資源層級的精細控制

這種「縱深防禦」策略能提供更完整的安全保護。

什麼時候應該使用 NACL？

建議使用 NACL 的情境：

• 需要明確「拒絕」特定 IP 或 IP 範圍
• 需要在 Subnet 層級加強防護
• 需要統一管理整個 Subnet 的流量政策
• 需要額外的防護層以符合合規要求

大多數情況下，Security Group 就足夠了，但 NACL 可以提供額外的防護層。

總結與最佳實踐

核心觀念總結

設計安全架構的建議

1. 以 Security Group 為主要防護手段

• 更容易管理和維護
• 有狀態機制降低設定複雜度
• 可以精細控制每個資源

2. 使用 NACL 作為額外防護層

• 在 Subnet 層級阻擋惡意流量
• 使用拒絕規則封鎖特定 IP
• 符合合規或稽核要求

3. 定期檢視和測試規則

• 確保規則設定正確
• 避免過於寬鬆或過於嚴格
• 記錄所有變更以便追蹤

給初學者的建議

學習步驟：

1. 先徹底理解 Security Group（較常用且較簡單）
2. 熟悉 Security Group 後再學習 NACL
3. 理解兩者的差異和互補關係
4. 在測試環境中實際操作和驗證

避免常見錯誤：

• ❌ 不要搞混綁定層級（Subnet vs ENI）
• ❌ 不要忘記 NACL 是無狀態的
• ❌ 不要過度依賴 NACL，忽略 Security Group 的重要性
• ❌ 不要在生產環境直接測試規則變更

結語

NACL 和 Security Group 是 AWS 網路安全的兩大支柱，理解它們的差異和互補關係，是設計安全 AWS 架構的基礎。

記住最重要的一句話：NACL 是 Subnet 的防火牆，Security Group 是 ENI 的防火牆。

透過這兩道防線的正確配置，您可以建立一個既安全又靈活的雲端環境。建議初學者先從 Security Group 開始學習，待熟悉後再深入研究 NACL，這樣能更有系統地建立完整的 AWS 網路安全知識。

希望這篇文章能幫助您清楚理解 AWS 的網路安全機制！