為什麼安全性群組與 NACL 對 ANS-C01 至關重要
安全性群組 (Security Groups, SGs) 與網路存取控制清單 (Network Access Control Lists, NACLs) 是 Amazon VPC 中兩個基礎的封包過濾控制項，ANS-C01 考試對它們的測試極其精確。網域 4 任務陳述 4.1 中任何涉及「為什麼我的流量被封鎖」或「設計一個多層安全 VPC」的問題，都取決於你是否能立即且正確地說出有狀態與無狀態過濾、暫時連接埠 (Ephemeral ports) 範圍、評估順序以及跨 VPC 參考規則之間的差異。通過 ANS-C01 的考生幾乎普遍認為，SG/NACL 陷阱題是相對於投入的學習時間，題目密度最高的部分。
在這份進階學習指南中，我們將從協定層級開始剖析安全性群組與 NACL：有狀態連線追蹤實際上是如何運作的、為什麼 NACL 需要顯式的暫時連接埠傳出規則、如何跨帳戶與跨 VPC 參考 SG、NACL 的精確規則評估順序 (編號、首個匹配勝出、終止)、你必須知道的限制與配額、標準的多層式與周邊 (Perimeter) VPC 模式、與 VPC 端點策略的整合，以及 AWS Firewall Manager 如何套用全組織的 SG 基準。
閱讀完本指南後，你應該能夠讀懂任何 ANS-C01 關於 SG/NACL 的問題，並在看到選項前就識別出陷阱。我們在結尾提供了常見問題 (FAQ)、情境演練以及中文陷阱提醒清單。
安全性群組：設計上即為有狀態
安全性群組是附加在彈性網路介面 (ENI) 上的虛擬有狀態防火牆。當流量到達 ENI 時，SG 會評估流量是否被傳入 (Inbound) 規則允許。當工作負載回應時，SG 會自動允許傳回的流量，而無視傳出 (Outbound) 規則。這就是「有狀態 (Stateful)」的含義：SG 會記住活躍的連線並自動允許回程的一半流量。
傳入與傳出規則
每個 SG 有兩套規則集：傳入規則與傳出規則。兩者皆為「僅限允許 (Allow-only)」 — 安全性群組中沒有「拒絕 (Deny)」規則。每條規則都有協定 (TCP, UDP, ICMP 或數字協定)、連接埠範圍 (單個連接埠、範圍或「所有」) 以及來源或目的地 (可以是 CIDR 區塊、另一個安全性群組 ID 或受管字首清單)。
預設情況下，每個 SG 啟動時都沒有傳入規則 (拒絕所有傳入)，且有一條允許所有流量流向 0.0.0.0/0 的傳出規則。在鎖定工作負載時，修改這些預設值是首要任務之一。考試經常測試考生是否記得預設傳出規則允許所有流量 — 未移除該規則是一個常見的安全發現項目。
安全性群組是與 VPC 中一個或多個彈性網路介面相關聯的有狀態封包過濾器。規則僅限允許。有狀態追蹤意味著已建立連線的回程流量會被自動允許。SG 會評估所有規則；所有允許規則的聯集決定了哪些流量被允許。單個 SG 內部沒有規則順序或優先級。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
安全性群組規則評估
在單個 SG 內部，所有規則按邏輯 OR 進行評估 — 只要匹配任何一條規則，封包就會被允許。這裡沒有順序、沒有優先級，也沒有首個匹配 (First-match) 邏輯。如果你為一個 ENI 附加了多個 SG (預設最多 5 個，可調高至 16 個)，則適用於所有 SG 規則的聯集。
這與傳統防火牆中規則順序至關重要有本質上的不同。在 SG 的世界裡，你不能寫「允許 X」然後「拒絕其他所有內容」 — 拒絕是隱含的 (沒有規則即代表不允許)。要執行「拒絕」，你只需不添加允許規則即可。
有狀態連線追蹤細節
AWS 中的有狀態追蹤使用底層 Hyperplane 基礎設施中的連線追蹤項目。對於 TCP，每個連線都由 5-tuple (來源 IP、來源連接埠、目的地 IP、目的地連接埠、協定) 加上 TCP 狀態機 (SYN, SYN-ACK, ESTABLISHED, FIN, RST) 來追蹤。對於 UDP，AWS 使用帶有閒置逾時的偽狀態 (Pseudo-state)。對於 ICMP，AWS 追蹤請求/回覆對。
一個微妙但與考試相關的細節：極高頻率的連線 (每個 ENI 每秒超過 100,000 個) 可能會超過連線追蹤預算，並迫使 AWS 將某些連線標記為「未追蹤」，這意味著回程流量不再被自動允許。這很少被直接測試，但解釋了一些營運上的異常現象。
一旦傳入的 TCP 連線被安全性群組的傳入規則允許，該連線方向的回應封包將被 SG 自動允許，而無視傳出規則集。你不需要為回程流量添加傳出規則。這是 ANS-C01 中關於 SG 被測試最頻繁的概念 — 且它與 NACL 有本質區別。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
NACL：無狀態且具備規則編號
網路存取控制清單 (NACL) 是套用於子網路邊界的無狀態封包過濾器。無狀態意味著每個封包 — 包括已建立連線的回程流量 — 都會針對傳入與傳出規則進行獨立評估。NACL 沒有對過去封包的記憶。
NACL 規則與評估順序
NACL 規則是帶有編號的 (通常以 100 為增量：規則 100, 200, 300...)。在每個方向上，規則按數字從小到大進行評估，首個匹配的規則將終止評估。這與 SG 有本質不同：在 NACL 中，規則順序絕對關鍵。
每條規則指定一個編號、協定、連接埠範圍、來源或目的地 CIDR，以及一個動作 — ALLOW (允許) 或 DENY (拒絕)。與 SG 不同，NACL 同時支援 ALLOW 與 DENY 動作。
預設 NACL 允許所有傳入與傳出流量。自訂 NACL 預設拒絕所有傳入與傳出流量 — 你必須手動添加顯式的允許規則。考試非常喜歡測試兩者的區別：新建立的自訂 NACL 比預設 NACL 要嚴格得多。
暫時連接埠 — 最常見的 NACL 陷阱
因為 NACL 是無狀態的，回程流量不會被自動允許。當你 VPC 中的用戶端對伺服器的 443 連接埠發起傳出 TCP 連線時，伺服器會從 443 連接埠回覆到用戶端上隨機選擇的暫時連接埠 (Ephemeral port，Linux 通常在 1024–65535 範圍，Windows 則在 49152–65535)。如果沒有允許暫時連接埠範圍的傳入 NACL 規則，回應封包將在子網路邊界被丟棄。
這是 ANS-C01 中頻率最高的 NACL 陷阱。「為什麼我的 EC2 執行個體無法從網際網路下載內容」的「顯而易見」答案是「缺少傳出規則」 — 但實際答案往往是「缺少針對暫時連接埠的傳入 NACL 規則」。
NACL 是無狀態的。要允許傳出 HTTPS (TCP 443)，你需要：
- 一條傳出 NACL 規則，允許 TCP 443 流向 0.0.0.0/0 (請求)。
- 一條傳入 NACL 規則，允許 TCP 1024-65535 來自 0.0.0.0/0 (回應，在暫時連接埠上)。
缺少規則 2，連線會神秘地失敗 — SYN 發出了，但 SYN-ACK 在 NACL 處被丟棄，你會看到 TCP 重傳。AWS 建議使用 1024-65535 作為暫時連接埠範圍，以涵蓋所有用戶端作業系統。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/nacl-ephemeral-ports.html
NACL 規則編號策略
最佳實踐是以 100 為增量來間隔規則編號，以便為後續插入留出空間。萬用規則 * DENY 始終存在於底部且無法移除。AWS 定義的規則編號必須在 1 到 32766 之間；超過 32766 的編號為預留。
常見模式如下：
- 100: ALLOW 來自 0.0.0.0/0 的傳入 HTTPS 到 TCP 443
- 200: ALLOW 來自 10.0.0.0/8 的傳入 SSH 到 TCP 22
- 300: ALLOW 來自 0.0.0.0/0 的傳入暫時連接埠到 TCP 1024-65535
- 400: DENY 來自受威脅 CIDR 的所有流量
- *: DENY (隱含)
如果規則 100 (ALLOW HTTPS) 出現在規則 200 (DENY 來自特定 CIDR 的 HTTPS) 之前，則 ALLOW 勝出，因為它先匹配。要 DENY 一個特定的 CIDR，該 DENY 規則的編號必須比 ALLOW 規則更小。這是 ANS-C01 中關於 NACL 行為最常考的點之一。
安全性群組 vs NACL：對比表
| 屬性 | 安全性群組 (SG) | NACL |
|---|---|---|
| 有狀態 | 是 | 否 |
| 允許 + 拒絕 | 僅允許 | 允許與拒絕 |
| 規則順序 | 順序不重要 | 順序很重要 (具編號) |
| 作用範圍 | ENI / 執行個體 | 子網路 |
| 預設規則 | 無傳入，所有傳出 | 預設 NACL：允許所有；自訂 NACL：拒絕所有 |
| 參考類型 | CIDR, SG ID, 字首清單 | 僅限 CIDR |
| 跨帳戶參考 | 透過 VPC 對等連接/TGW | 不支援 |
| 規則限制 (預設) | 每 SG 60 傳入 + 60 傳出 | 每 NACL 20 傳入 + 20 傳出 |
| 層級 | 執行個體級別 | 子網路級別 |
| 相互評估順序 | 傳入先過 NACL，傳出先過 SG (從執行個體發出時) | (見右側) |
網路 ACL 是套用於子網路與 VPC 其他部分之間邊界的無狀態封包過濾器。規則具有編號 (1-32766)，按升序評估，並在第一個匹配時終止。每條規則指定 ALLOW 或 DENY。傳入與傳出規則集是獨立的。無狀態意味著回程流量必須顯式地被允許。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
安全性群組參考 (Security Group Referencing)
SG 最強大的功能之一 — 也是考試最常考的功能 — 是能夠將另一個 SG 引用為規則的來源或目的地。與其寫「允許來自 10.0.1.0/24 的傳入」，你可以寫「允許來自 sg-12345678 (附加在應用伺服器上的 SG) 的傳入」。這是動態的：隨著執行個體的啟動與終止，SG 成員資格會自動更新，無需編輯規則。
同 VPC 內的 SG 參考
在單個 VPC 內，SG 對 SG 的參考原生可用。經典的三層式架構使用三個 SG (web, app, db) 並逐層參考：
- Web SG: 允許來自 0.0.0.0/0 的 TCP 443
- App SG: 允許來自 Web SG 的 TCP 8080
- DB SG: 允許來自 App SG 的 TCP 5432
此模式強制執行嚴格的層級分離：即便攻擊者攻破了 Web 層，他們也只能透過 TCP 8080 到達 App 層 — 他們無法直接連接到資料庫，因為他們的來源 SG 是 Web SG 而非 App SG。ANS-C01 將此稱為「透過安全性群組參考實現的微分割 (Micro-segmentation)」。
跨 VPC 的 SG 參考
SG 對 SG 的參考可以跨越對等連接 (Peered VPCs) 以及 Transit Gateway 運作，但僅限於同一個 AWS 區域內。跨區域的 SG 參考要求在每一側重新建立 SG 參考，因為 SG 是區域性資源。
對於 VPC 對等連接，SG 參考是透明運作的 — 你指定來自對等 VPC 的 SG ID 作為來源，對等連線會使被參考的 SG ID 能夠解析。對等 VPC 必須位於同一區域。
對於 Transit Gateway，自 2023 年起支援 SG 參考，但僅限於兩個 VPC 附加到同一個區域內的同一個 TGW。如果 VPC 位於不同區域且透過 TGW 對等連接連接，則 SG 參考不會傳遞 — 你必須改用 CIDR 參考。
你可以引用另一個 AWS 帳戶的安全性群組 ID，但僅限於兩個 VPC 透過 VPC 對等連接或 Transit Gateway 連接，且僅限於同一個區域。擁有帳戶必須使用 SG ID 加上對端帳戶編號的組合格式 (sg-1234abcd/123456789012)。對於 Transit Gateway，兩個 VPC 必須附加到同一個 TGW。ANS-C01 中關於跨帳戶存取的問題通常取決於此。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html
用於大規模管理的字首清單 (Prefix lists)
受管字首清單是一組具名的 CIDR 區塊，你可以在 SG 規則與路由表中引用。AWS 發佈了針對 AWS 服務的受管字首清單 (S3, DynamoDB, EC2 Instance Connect, CloudFront 面向源的清單, Route 53 健康檢查)。你也可以為自己的 CIDR 集建立客戶受管字首清單。
客戶受管字首清單在多帳戶情境下大放異彩 — 透過 AWS RAM 共享，從成員帳戶引用，集中更新。考試經常測試「跨組織大規模管理 CIDR 規則」 — 答案是透過 RAM 共享客戶受管字首清單。
SG 與 NACL 的限制與配額
對於 ANS-C01，請記住以下軟限制 (均可透過 Service Quotas 申請調高)：
- 每個 ENI 預設 5 個 SG，最大 16 個
- 每個 SG 預設 60 條傳入 + 60 條傳出規則
- 每個 ENI 的有效規則數為 1,000 (SGs × 每 SG 規則數)
- 每個 VPC 預設 2,500 個 SG
- 每個 NACL 預設 20 條傳入 + 20 條傳出規則 (調高存在硬性上限)
- 每個 VPC 預設 200 個 NACL
「每個 ENI 1,000 條有效規則」這項限制常難倒那些在不考慮總規則數的情況下擴展基於 SG 控制的團隊。解決方案是合併 SG、使用字首清單或將控制權移至 AWS Network Firewall。
多層式架構模式
經典的三層式網頁架構是考試測試的規範化 SG/NACL 模式：
網際網路
│
▼ (NACL: 允許 80/443 入, 暫時連接埠出)
公有子網路 (Public Subnet)
└── ALB (sg-web-lb: 允許來自 0.0.0.0/0 的 443)
│
▼ (NACL: 允許暫時連接埠入, 8080 出)
私有子網路 (Private Subnet, App 層)
└── EC2 (sg-app: 允許來自 sg-web-lb 的 8080)
│
▼ (NACL: 允許暫時連接埠入, 5432 出)
隔離子網路 (Isolated Subnet, DB 層)
└── RDS (sg-db: 允許來自 sg-app 的 5432)
每一層都有自己的子網路 (可選擇性配備專用 NACL) 與自己的 SG。SG 透過 ID 相互參考，而非透過 CIDR — 這就是微分割模式。攻破 Web ALB 的攻擊者無法直接接觸資料庫，因為他們的來源 SG 是 sg-web-lb 而非 sg-app。
周邊 VPC 與不信任網路模式
周邊 VPC (有時稱為 DMZ VPC 或檢查 VPC) 是專門用於處理多 VPC 架構中傳入與傳出的 VPC。周邊 VPC 託管公有負載平衡器、AWS Network Firewall 端點以及反向代理。支點 (Spoke) VPC 僅與周邊 VPC 通訊 (通常透過 Transit Gateway)，絕不直接與網際網路通訊。
在此模式中：
- 周邊 VPC 公有子網路：SG 允許來自網際網路的 80/443 傳入；NACL 針對這些連接埠 + 暫時連接埠進行強化。
- 周邊 VPC 私有子網路：SG 僅允許傳出到支點 VPC。
- 支點 VPC：NACL 拒絕任何往返網際網路 IP 的流量；SG 僅參考周邊 VPC 的 SG。
對於 PCI DSS、HIPAA 或其他要求明確進出點的合規框架，周邊 VPC 模式是規範化答案。它將 WAF、Shield、Network Firewall 與 NAT 閘道集中在一個可稽核的 VPC 中。每個支點 VPC 都繼承了安全態勢而無需擁有控制項。搭配 Firewall Manager 進行全組織範圍的強制執行。 來源：https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/aws-network-perimeter.html
VPC 端點策略與深度防禦
VPC 介面端點 (PrivateLink) 帶有其自身的安全控制：端點 ENI 上的安全性群組，外加端點策略 (Endpoint policy) (一個 JSON 資源策略，限制哪些主體可以透過該端點執行哪些動作)。這是深度防禦的體現。
典型的 S3 閘道端點配置：
- 端點策略：僅允許存取你 AWS 帳戶擁有的特定儲存貯體。
- 儲存貯體策略：包含限制存取來源為你的端點 ID 的
aws:SourceVpce條件。
這種組合防止了兩種故障模式：工作負載存取了不該存取的儲存貯體 (由端點策略攔截) 以及外部對你儲存貯體的存取 (由儲存貯體策略的 SourceVpce 條件攔截)。對於通往 Secrets Manager 或 KMS 等 AWS 服務的介面端點，端點策略 + 服務資源策略的組合提供了同樣的深度防禦。
考試會測試你是否理解端點策略不是 SG 的替代品 — 它們是層疊在一起的。介面端點 ENI 仍有 SG，而該 SG 控制了來自你工作負載的 TCP 層級存取。
閘道端點 (僅限 S3 與 DynamoDB) 不使用 ENI，也沒有安全性群組。它們透過路由表中的字首清單 ID 進行引用。閘道端點的存取控制依賴於端點策略以及儲存貯體/資料表的資源策略。介面端點確實有 ENI 且確實有安全性群組 — 這個區別是常考陷阱。 來源：https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
用於安全性群組策略的 AWS Firewall Manager
AWS Firewall Manager 透過兩種策略類型擴展至安全性群組：稽核策略 (Audit policies) 與內容稽核策略 (Content audit policies)。稽核策略會持續評估全組織的 SG 規則是否符合允許的規則模式。內容稽核策略則強制要求將特定的 SG (一個「主要 SG」) 附加到範圍內的所有 ENI 上。
常見的考試場景：
- 封鎖 0.0.0.0/0:22 (來自任何地方的 SSH)：Firewall Manager 內容稽核策略偵測並修復。
- 強制全組織的「基準 SG」附加到每個 EC2 執行個體：內容稽核策略。
- 稽核是否有 SG 同時具備 0.0.0.0/0 傳入與 0.0.0.0/0 傳出：稽核策略。
Firewall Manager 要求啟用 AWS Organizations 的所有功能、啟用 AWS Config 的成員帳戶以及委派管理員。如果沒有這些前提條件，即便需求匹配，「使用 Firewall Manager」也是錯誤答案。
白話文解釋
Security Group 跟 NACL 的差異是 ANS-C01 必考題，用三個生活類比把它們分開：
類比一：保鑣 vs 大樓警衛
把 EC2 instance 想像成你住的房間，整棟大樓是 VPC，你住的那一層樓是 subnet：
- Security Group = 你個人僱的私人保鑣。保鑣站在你的房門口，記得誰被允許進門（stateful）。客人進來談完事要離開，保鑣不用再問就放行（return traffic 自動允許）。保鑣只會「同意誰進來」，沒有「拒絕誰進來」這個動作（allow only）。
- NACL = 整層樓的大樓警衛。警衛站在電梯口，每個進出的人都當第一次見面（stateless）。即使你的客人才剛進門，他要離開時警衛還是會擋下來查證（return traffic 不自動允許）。警衛有規則手冊，且按編號順序檢查，第一個匹配就決定（first match wins）。手冊上有「同意」和「拒絕」兩種動作。
如果你的客人帶了禮物上樓進入你房間（inbound HTTPS 443），警衛要放他進來；客人要離開時，警衛要再次確認他可以走（outbound ephemeral port 1024-65535）— 這就是為什麼 NACL 必須同時設定 inbound 跟 outbound 的 ephemeral port 規則。
類比二：機場安檢（Allow-list vs Deny-list）
把 VPC 想成機場，subnet 是不同的航廈：
- NACL = 航廈大門：每個人進出都要檢查護照，警衛拿著一張按編號排序的「黑名單 + 白名單」清單。看到第一個符合的條目就決定（terminating first match）。如果規則 100 是「允許 A 國護照」，規則 200 是「拒絕 A 國護照」，A 國的人會被允許（因為規則 100 先匹配）。
- Security Group = 個別登機口的人臉辨識：只認得登機證上的人臉，沒登錄就一律拒絕。但是一旦你進去，回頭出去再進來（return traffic）系統會記得你（stateful）。
類比三：圖書館的借書規則（micro-segmentation）
把三層式架構想成圖書館的三個區域：閱覽區（web）、編目區（app）、書庫（db）：
- 閱覽區的讀者證（sg-web）才能進閱覽區。
- 編目區只接受閱覽區員工的工作證（sg-app 只允許 source = sg-web）。
- 書庫只接受編目區員工的工作證（sg-db 只允許 source = sg-app）。
讀者拿到閱覽區證也進不去書庫，因為書庫只認編目區員工的證件 — 就算讀者闖進閱覽區櫃台拿到 web 員工的證，也只能去編目區，到不了書庫。這就是 SG 互相 reference 的微分段邏輯。
常見情境
情境 A：App 層無法連接資料庫
症狀：私有子網路中的應用伺服器無法連接到隔離子網路中 TCP 5432 上的 RDS。
診斷路徑：
- 檢查 sg-db 傳入規則：是否允許來自 sg-app 的 TCP 5432？
- 檢查 sg-app 傳出規則：預設傳出為允許所有；通常沒問題。
- 檢查 App 子網路上的傳出 NACL：是否允許前往 DB 子網路 CIDR 的 TCP 5432？是否允許回程流量在暫時連接埠傳入？
- 檢查 DB 子網路上的傳入 NACL：是否允許來自 App CIDR 的 TCP 5432？是否允許回程流量暫時連接埠傳出？
- 使用 VPC Reachability Analyzer 確認意圖與現實。
典型的根本原因是某一側缺少 NACL 暫時連接埠規則。純 SG 的配置很少導致此問題，因為 SG 是有狀態的且回程流量自動允許。
情境 B：封鎖子網路除了傳出 HTTPS 以外的所有網際網路存取
要求：私有子網路必須允許向 0.0.0.0/0 傳出 HTTPS，但封鎖所有其他網際網路流量，包括其他協定的回程流量。
解決方案：
- NACL 傳入規則 100：ALLOW 來自 0.0.0.0/0 的 TCP 1024-65535 (用於 HTTPS 的回程暫時連接埠)。
- NACL 傳入規則 *: DENY (隱含)。
- NACL 傳出規則 100：ALLOW 到 0.0.0.0/0 的 TCP 443。
- NACL 傳出規則 *: DENY (隱含)。
- SG：允許傳出到 0.0.0.0/0 的 TCP 443；無傳入規則。
這種組合利用 NACL 作為預設拒絕的子網路邊界，並利用 SG 作為工作負載級別的允許控制。
常見考試陷阱
- NACL 暫時連接埠 — 忘記傳入暫時連接埠規則意味著回程流量會被丟棄。
- NACL 規則順序 — ALLOW 100 在 DENY 200 之前，意味著 ALLOW 勝出；規則順序至關重要。
- SG 預設傳出 — 新建的 SG 允許所有傳出；如果需要傳出過濾則必須移除。
- 跨 VPC SG 參考 — 僅限同區域內，配合 VPC 對等連接或 TGW (同區域) 運作。
這四點涵蓋了網域 4 任務 4.1 中絕大多數的陷阱題。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html
其他反模式：
- 認為 SG 支援 DENY 規則 — 它們不支援。
- 認為 NACL 是有狀態的 — 它們不是。
- 認為預設 NACL 與自訂 NACL 相同 — 預設允許所有，自訂拒絕所有。
- 將 NACL 作為主要控制項 — 它們太粗糙且無狀態；SG 是主要控制項，NACL 是深度防禦的備援。
- 忘記 NACL 的更改會立即套用到所有與該 NACL 關聯的子網路上。
- 在太多 SG 上放置太多規則 (觸及每個 ENI 1,000 條有效規則的限制)。
營運考量
事件期間的 SG 與 NACL 變更
SG 與 NACL 的規則更改都會立即生效。沒有傳播延遲 (與 Route 53 DNS 或某些 IAM 變更不同)。在事件期間，你可以透過移除所有 SG 並附加一個沒有規則的「隔離 SG」來隔離受攻陷的執行個體。該執行個體會在幾秒內變得無法存取。這是規範化的「事件回應隔離」模式。
記錄 SG 與 NACL 丟包
VPC 流程日誌會記錄動作欄位為 REJECT 的 SG 與 NACL 丟包。結合新的流程日誌欄位 flow-direction (傳入/傳出) 與現有的 5-tuple，你可以精確識別出是哪條 SG 或 NACL 規則拒絕了流量。NACL 丟包通常出現在子網路邊界；SG 丟包出現在 ENI 邊界。
監控 SG 變更
CloudTrail 會記錄 AuthorizeSecurityGroupIngress, AuthorizeSecurityGroupEgress, RevokeSecurityGroupIngress, RevokeSecurityGroupEgress, CreateSecurityGroup 與 DeleteSecurityGroup API 呼叫。AWS Config 規則 (如 restricted-ssh 與 vpc-sg-open-only-to-authorized-ports) 會持續評估合規性。SG 相關 CloudTrail 事件上的 EventBridge 規則可觸發自動化修復。
- SG = 有狀態；NACL = 無狀態。
- SG = 僅限允許；NACL = 允許 + 拒絕。
- SG = 無規則順序；NACL = 具編號，首個匹配即終止。
- SG 附加到 ENI；NACL 附加到子網路。
- NACL 規則按升序評估：規則 100 優於 200；編號越小優先級越高。 來源：https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
FAQ
Q1：我什麼時候應該使用 NACL 而不只是安全性群組？
NACL 在兩種情景下最有價值。第一，子網路級別的深度防禦 — 在 SG 看到封包前，NACL 就會在子網路邊界執行丟棄，為已知惡意 CIDR 提供粗篩選。第二，顯式的 DENY 規則 — 你可以在允許廣泛範圍的同時，單獨拒絕特定的 IP。對於大多數工作負載，單獨使用 SG 就足夠且易於管理；當合規性要求子網路級別隔離或當你想要在整個子網路中封鎖某個已知威脅 IP 時，則添加 NACL。
Q2：安全性群組可以參考另一個帳戶的 SG 嗎？
可以，但僅限於兩個 VPC 透過 VPC 對等連接或 Transit Gateway 連接，且僅限於同一個 AWS 區域。你以 sg-12345678 格式指定 SG ID，AWS 會根據對等或 TGW 關係自動添加對端帳戶的所有權標記。不支援跨區域的跨帳戶參考 — 必須改用 CIDR 範圍。
Q3：既然 SG 是有狀態的，為什麼我還需要傳入 NACL 規則？
因為 SG 與 NACL 運作在不同層級。NACL 無視 SG 狀態，在子網路邊界評估每個封包。因此，即便 SG 會允許回程封包 (它記得該連線)，NACL 仍必須獨立允許該回程封包的連接埠範圍 (暫時連接埠範圍，1024-65535)。如果沒有針對暫時連接埠的傳入 NACL 規則，封包會在到達 SG 前就在子網路邊界被丟棄。
Q4：我可以在 NACL 規則中使用受管字首清單嗎？
不行。NACL 規則僅支援 CIDR 區塊作為來源與目的地。受管字首清單僅支援在安全性群組與路由表中使用。如果你需要維護一份集中管理的 CIDR 清單並將其套用到 NACL，你必須透過腳本將字首清單轉換為個別的 NACL 規則。
Q5：當附加多個 SG 時，每個 ENI 的規則限制是多少？
每個 ENI 的有效規則限制為 1,000 — 計算方式為附加的 SGs × 每 SG 規則數。在預設的 5 個 SG 且每個 60 條規則 (60傳入+60傳出) 的情況下，上限為 5 × 120 = 600 條規則。若調高配額至 16 個 SG 且每個 60 條規則，理論上達 1,920 條，但硬性限制仍為 1,000 條有效規則。超過此限制，你將無法附加額外的 SG。
Q6：我如何封鎖特定的 IP 存取我的 VPC？
有兩個選項。(1) 添加一條規則編號較小 (例如 50) 的 NACL 拒絕規則，針對該特定 IP。拒絕動作會終止評估，在子網路邊界將其封鎖。(2) 使用 AWS Network Firewall 並配合無狀態丟棄規則。NACL 更簡單且免費；Network Firewall 更強大但按 GB 收費。SG 無法封鎖特定 IP，因為 SG 僅限允許 — 你無法寫一條 SG 拒絕規則。
Q7：如果我不為 ENI 附加任何 SG 會發生什麼事？
每個 ENI 必須至少有一個 SG。當你啟動執行個體而不指定 SG 時，AWS 會附加該 VPC 的預設 SG。預設 SG 允許同一 SG 成員之間的所有流量 (預設 SG 內部的執行個體互通)，並允許所有傳出到 0.0.0.0/0。你無法刪除預設 SG，只能修改其規則。
Q8：SG 更改是立即生效的嗎？
是的。SG 規則更改與 SG 到 ENI 的關聯更改都會在幾秒鐘內傳播。資料平面沒有傳播延遲 — 一旦 API 返回成功，新封包就會根據新規則進行評估。NACL 更改具備同樣的即時行為。
Q9：我可以使用 IAM 控制誰可以修改 SG 嗎？
可以。針對 ec2:AuthorizeSecurityGroupIngress, ec2:RevokeSecurityGroupIngress 等動作的 IAM 策略可以控制誰能修改 SG 規則。搭配 CloudTrail 日誌記錄與 AWS Config 規則，可進行持續的合規評估。AWS Firewall Manager 則將此擴展至全組織策略。
Q10：VPC 端點是否遵循安全性群組規則？
介面端點 (PrivateLink) 具有 ENI 與安全性群組。工作負載必須具備允許存取端點 SG 的傳出規則，且端點 SG 必須具備允許來自工作負載 SG 的傳入規則。閘道端點 (S3, DynamoDB) 沒有 ENI 且沒有安全性群組 — 它們依賴於端點策略以及路由表中的字首清單。
總結：SG/NACL 答案模式
當你在 ANS-C01 中讀到 SG/NACL 相關問題時，請執行以下檢查表：
- 問題是否關於回程流量神秘失敗？ → 缺少 NACL 暫時連接埠規則。
- 問題是否關於規則順序行為？ → NACL (具編號、首個匹配)，而非 SG (無順序)。
- 問題是否關於跨帳戶存取？ → 透過對等連接/TGW 進行 SG 對 SG 參考，限同區域。
- 問題是否關於拒絕特定 IP？ → NACL 拒絕規則，或 Network Firewall。
- 問題是否關於三層式隔離？ → SG 對 SG 參考 (web→app→db)。
- 問題是否關於全子網路範圍的封鎖？ → NACL。
- 問題是否關於執行個體級別的識別碼過濾？ → SG。
- 問題是否關於跨帳戶的大規模 CIDR 管理？ → 透過 RAM 共享受管字首清單。
- 問題是否關於全組織的 SG 基準？ → AWS Firewall Manager 安全性群組策略。
掌握有狀態與無狀態的區別、暫時連接埠規則、規則順序行為以及 SG 參考模式，ANS-C01 任務 4.1 中的 SG/NACL 問題將變得有跡可循。
常考陷阱
- NACL ephemeral port — 傳出開了 443，記得傳入要開 1024-65535 才收得到回應。
- NACL 規則編號順序 — ALLOW 100 在 DENY 200 之前，ALLOW 先匹配就不會走到 DENY；要 DENY 必須編號更小。
- SG 是有狀態 (Stateful)，NACL 是無狀態 (Stateless) — 回程流量 SG 自動允許，NACL 必須明確設定。
- SG 沒有 DENY — SG 只能允許，要拒絕就用 NACL 或 Network Firewall。
- 預設 SG vs 預設 NACL — 預設 SG 拒絕所有傳入、允許所有傳出；預設 NACL 允許所有；自訂 NACL 拒絕所有。
- 跨帳戶 SG 參考 — 必須同區域，且兩個 VPC 已建立對等連接或附加到同一個 TGW。
- 閘道端點沒有 SG — S3 / DynamoDB 閘道端點使用字首清單路由，無 ENI 無 SG。
- 介面端點有 SG — 別忘了允許工作負載連線至端點。
- 每個 ENI 1,000 條有效規則 — SGs 數量 × 規則數，超過就無法附加更多 SG。
- Firewall Manager 需要 Organizations + Config — 缺少這兩項，無法使用組織級 SG 策略。