AWS國際帳號服務 AWS VPC安全組規則設計

AWS國際帳號服務 一、先釐清：安全組到底在防什麼？

很多團隊把安全組當成「開端口清單」，最後規則越長越亂，出了事故也很難追溯。要設計得好，先把安全組的本質想清楚：它是針對 網路流量（Ingress/Egress） 的狀態式防火牆規則集合，附著在 VPC 內的網卡（通常是 EC2、ENI，也包含部分受管理服務的網路介面）。

你需要的不是「我加上去能通」，而是「我知道為什麼要通、允許什麼、拒絕什麼，以及未來怎麼改還能保持安全與可維運」。安全組的設計目標，往往同時包含：可讀性、最小權限、可擴展、可審查、可回溯。

1.1 方向與狀態機：不要把它當傳統防火牆

安全組有進站（Ingress）與出站（Egress）。但它是「狀態式」：對於已建立的連線回包，通常不需要你再寫反向規則。這會影響你的規則設計方式。舉例：如果你允許外部連到服務的 443（Ingress），回應流量通常會自動放行；你不必為了回包額外開放 1024-65535（但前提是連線是正常建立的）。

因此，設計時要把規則的責任分開：你要決定的是「哪些來源可以開始連線、以什麼協議和端口開始」。而不是把所有可能埠都當成要逐一放行。

1.2 最小權限：落到「來源、端口、協議」

最小權限在安全組上要落到三個維度：來源（Source）、端口（Port）、協議（Protocol）。來源可以是 CIDR、另一個安全組（SG-to-SG）、或特定類型（如使用前置服務的安全組）。端口要盡量是應用實際需要的端口，避免用 0-65535 這種「保證可用但失去防護」的做法。

你會發現很多風險不是來自「有沒有開」，而是來自「開得太廣」：例如來源設成 0.0.0.0/0，端口設成全部，或用同一套規則給所有層（ALB、應用、資料庫）套到底。

二、規則設計的基本原則：從結構而不是從例外開始

良好的安全組不是靠「補丁」堆出來的，而是用結構讓例外變少。可以把整體設計拆成「層級、角色與流量路徑」。

2.1 用層級思考：邊界、接入、應用、資料

典型 VPC 應用可以拆成幾層：

• 邊界/入口層：例如 ALB 或 NLB、WAF 前置（WAF 不在安全組，但安全組仍是第一道可控網路策略）。
• 接入層：如 API Gateway 轉發後，或直連 EC2 的前端。
• 應用層：業務服務（Web、API、Worker）。
• 資料層：RDS、ElastiCache、OpenSearch、內部服務。

每層的安全目的不同：入口層容忍面向公網的攻擊面，但範圍要狹窄；資料層應只允許來自應用層的必要端口；應用層則只接受来自入口/依賴服務的流量。

當你把「誰能連誰」固定成路徑，規則就會自然收斂。

2.2 先定義允許清單，再處理拒絕

安全組通常採「允許所列」的模式（特別是 Ingress）。因此你的策略可以是：用白名單定義通路，而不是用黑名單列舉危險來源。黑名單會漏、會忘、還會在團隊擴張時失控。

具體做法是：先在設計文件中列出每個服務「必需被哪些來源訪問、每個來源的協議/端口」。例如「API 只允許 ALB SG 透過 443 轉發」「Worker 只允許內部隊列端口」「資料庫只允許應用 SG 連線」。

2.3 優先用 SG-to-SG，少用寬 CIDR

如果你把來源寫成 0.0.0.0/0，等於把防線交給應用層或其他控管（WAF、Rate Limit）。那不是不好，但安全組失去了精準性。

更理想的方式是用 安全組作為來源：例如允許「來自 ALB 的安全組」連到應用的 8080。這樣即使你未來更換後端實例、擴容多台，來源仍保持正確。

SG-to-SG 的維運優勢很明顯：規則表達的是「關係」，不是「地址」。地址會漂移，關係通常穩定。

三、把安全組做成可讀：命名、分層與規則粒度

安全組之所以常見「越改越亂」，通常不是人不努力，而是缺少可讀性設計。你需要讓未來接手的人看得懂。

3.1 命名規則：用角色、環境、層級、用途

命名不只是好看，它直接影響你能不能快速定位。建議安全組名稱包含至少四段資訊：

• 環境：prod/stage/dev
• 應用或服務名稱：payment-api、orders-worker
• 層級或角色：alb、app、db
• 用途或協議摘要：ingress-443、egress-s3、mysql-3306

例如：prod-orders-app-ingress-8080、prod-orders-db-mysql-3306。當你有一致命名，規則審查時可以用名稱直接判斷目的。

3.2 規則拆分：避免把所有端口塞在同一個 SG

很多團隊習慣「一個服務一個 SG」，但如果這個 SG 同時承擔入口、管理介面、內部通信、資料訪問，規則會迅速變成大雜燴。

更可維運的做法是：依照流量路徑拆分安全組。例如：

• 應用 SG：只負責接收來自入口層的流量
• 應用管理 SG：只負責 SSH/SSM 之類的管理通路
• 資料庫 SG：只負責資料埠（例如 3306、5432、6379）

AWS國際帳號服務 這樣當你要調整某個能力（例如新增管理端口），你不會動到整個服務核心通路。

3.3 粒度：端口用精準範圍，協議避免「全允許」

AWS國際帳號服務 如果你需要 TCP，請寫 TCP；如果你不需要 UDP，避免用「-1」（所有）。端口也要以實際範圍為準。只有在確實必要（例如某些自研協定或多端口動態服務）時才考慮範圍放寬。

另外要注意的是：即使安全組允許了某些流量，應用層仍需驗證連線與授權；但反過來也一樣：應用層不會替你完成網路層的最小權限。

四、方向與出站策略：Egress 也要管

很多人只關注 Ingress，因為「外部進來要防」。但現實中，資料外傳、橫向移動、以及被攻擊後的回連都跟出站有關。雖然安全組是有狀態的，但 Egress 規則仍然決定了你允不允許被攻擊的實例對外連線。

4.1 建議採用「受控出站」模型

AWS國際帳號服務 如果你現在的安全組預設 Egress 是允許全部，你可以逐步收斂。做法不是一口氣全部鎖死，而是採用「先盤點、再限制、再驗證」。

常見需要出站的項目包括：

• 連到資料庫（應用到 RDS）
• 連到快取或搜尋（ElastiCache、OpenSearch）
• 連到對象儲存（S3）或憑證服務（取決於架構）
• 連到外部 API（第三方）
• 更新與系統服務（DNS、NTP、鏡像更新等）

每一項都要對應到協議與目標範圍。若你使用 VPC 內的服務，優先用 SG-to-SG；如果是特定網段，再用最小 CIDR。

4.2 NAT 與流量路徑：安全組不要忽略 VPC 其他元件

很多人以為只要安全組開了出站，就一定能連到外網；但實際上仍要看路由表（route table）、NAT Gateway/Instance 設置與目的地。安全組只管「能不能出」，但「怎麼出去」由路由與網關決定。

設計時應把流量路徑當成整體方案：例如私有子網的 EC2 要上網，需要經過 NAT；因此除了 Egress 允許（例如 TCP 443）之外，還要確認路由到 NAT，且 NAT 所在的安全組允許必要回程。

五、常見場景的安全組設計模式

下面用幾個最常見的架構，給出設計思路。你可以把它當作「模板思維」，再依你的端口與服務調整。

5.1 ALB 對應的應用層：只開必要的轉發端口

場景：ALB（外部）把流量轉發到應用實例。這裡的關鍵不是「外部 443」，而是「ALB SG 到應用 SG 的連線」。

• ALB 安全組：Ingress 許可 443（來源可為 0.0.0.0/0，或只允許你的特定前端網段；通常搭配 WAF/Ratelimit）。
• 應用安全組：Ingress 許可來自 ALB 安全組的目標端口（例如 8080 或 80，取決於你的容器/服務設定）。
• 應用安全組：Egress 許可到資料層的端口（例如 DB 3306/5432）以及必要服務。

這樣你把攻擊面鎖定為「只能從 ALB SG 進入應用端口」，避免直接把 8080 端口暴露到公網。

5.2 應用連資料庫：用 SG-to-SG，關閉公網路徑

場景：RDS 只應由應用層訪問。設計要點：

• 資料庫安全組：Ingress 只允許來自應用安全組的資料庫端口。
• 資料庫通常不需要任何對外管理（如 SSH 之類）。
• 資料庫 Egress 視情況決定是否允許連到外部（例如備份、告警 webhook）。若資料庫僅做內部用途，可以收斂得更嚴格。

一旦你用 CIDR 代替 SG-to-SG，例如把應用子網整段 CIDR 放進去，你就提高了誤連風險：子網裡未必只有應用實例，未來擴充時也容易把不該連的人連進來。

5.3 Worker/Queue：只允許必要的內部訪問

場景：Worker 由內部排程或隊列驅動（例如 SQS、Kafka、或自建服務）。

• 若是 SQS，通常不需要安全組對 SQS 設置（SQS 是服務端，不是傳統端口連線）。
• 若是 Kafka 或自建隊列，才需要安全組規則。

對於 Kafka 這類多端口協定，你要先確定實際用到的 listener 端口（例如 9092、9093），以及是否有管理通道（如 7199）。把這些端口限定在「特定 producer/consumer 安全組」之間。

5.4 管理介面（SSH/HTTP Admin）：最容易被忽略的風險點

很多事故不是發生在 443，而是發生在 22 或某個管理 API。管理介面建議：

• AWS國際帳號服務 優先使用 SSM 或基於 IAM 的管理方式，降低對外暴露。
• 若必須走網路（SSH），來源應限制為跳板機安全組，而不是 0.0.0.0/0。
• 管理端口與一般服務端口應分開安全組，避免用同一個 SG 同時承擔「對外服務」與「管理入口」。

六、可維運流程：讓規則可審查、可追蹤、可回滾

設計不是交出去就結束。安全組在團隊擴張後會不斷被改動，必須有流程。

6.1 變更審查：把安全假設寫進規則的目的

每一次新增規則都應回答：「為什麼需要這個來源？」、「為什麼需要這個端口？」、「這會不會讓攻擊面擴大？」。審查時不要只看技術可行性，還要看是否破壞了最小權限。

實務上可以在規則變更描述（或內部工單欄位）寫清楚依據，例如「新增 payment-api 連線到 cache-cluster 的 6379 用於讀取快取」。讓未來審查的人不必猜。

6.2 盤點與告警：規則漂移（rule drift）要被看見

AWS國際帳號服務 規則漂移是指：初始設計是正確的，但隨著功能迭代，許多不該存在的開放被保留，甚至增加。

可以採取以下做法：

• 定期盤點：找出任何來自 0.0.0.0/0 的非必要端口。
• 定期比較：同類型安全組是否存在不一致（例如 dev 開得很寬，prod 卻更寬）。
• 變更告警：當某個安全組新增 ingress 來源或放寬端口範圍時發出通知。

告警不是為了懲罰，而是為了讓問題能被及早看見並修正。

6.3 測試策略：先驗證通路，再驗證拒絕

測試不能只做「連得到」。最小權限要求你也驗證「連不到」。

例如你要鎖定資料庫安全組只允許應用層連入，就應測試：

• 來自應用安全組的連線成功（TCP handshake、應用層查詢 OK）。
• 來自同子網但非應用安全組的來源連線失敗。
• 來自外部的連線失敗，確認沒有誤開公網或 VPN 網段。

測試最好能在變更前後做對照，避免「看似正常」卻其實暴露了更多端口。

七、常見反例與修正方向

AWS國際帳號服務 知道怎麼做還不夠，你也要知道常見做法為什麼會出問題。

7.1 反例：一個安全組通吃所有層

現象：同一個 SG 既放行 443 給公網，又放行 3306 給同子網，還開了 22 供管理。結果就是規則越堆越長，任何人改任何端口都不敢確認風險。

修正：按層級拆 SG，將「入口、應用、資料、管理」分開；並使用 SG-to-SG 表達關係。

7.2 反例：用 CIDR 代替來源關係，導致誤連

現象：用子網 CIDR（例如 10.0.0.0/16）作為資料庫來源，因為「省事」。但子網裡可能後來塞了維運工具、測試環境或其他服務。

修正：改為應用安全組作為來源，或至少用更小、可確定的來源範圍。

7.3 反例：Egress 全開，等於把出站防線交出去

現象：為了避免連線失敗，把 Egress 設成 all traffic。當某台主機被入侵後，攻擊者可能能更容易連到外部控制端或橫向移動。

修正：先盤點實際目的地與端口，再逐步收斂；先收斂內部與常見依賴，對外部才採取白名單策略。

7.4 反例：管理端口直接暴露公網

AWS國際帳號服務 現象：把 22 或管理 API 對 0.0.0.0/0 開著。就算你加了密碼機制或基本身份驗證，也只是把攻擊成本降到最容易的區間。

修正：來源限制到跳板機 SG，或直接採用 SSM 類方案。

八、落地建議：一份可以執行的設計清單

最後把方法變成可操作的檢查清單。你可以在每次設計或改動安全組時逐項走一遍。

8.1 需求輸入

• 這個服務要被誰訪問？（列出角色：ALB、管理端、其他微服務、安全組。）
• 需要哪些協議與端口？（不要假設，用實際設定與日誌/監控佐證。）
• 這個服務是否需要出站？出站到哪些目標？

8.2 規則輸出

• Ingress：只允許必要來源與必要端口。
• 盡量使用 SG-to-SG，減少寬 CIDR。
• Egress：若目前全開，至少先收斂內部依賴，再評估外部白名單。
• 管理端口與一般服務端口分開安全組。

8.3 可維運性

• 安全組命名一致、規則目的能在審查時被理解。
• 定期盤點 0.0.0.0/0 的非必要端口、以及安全組之間關係是否合理。
• 所有變更都能追蹤：誰改的、為什麼改、影響什麼通路。

九、結語：安全組的價值是「讓風險變得可管理」

VPC 安全組不是用來炫技的設定頁，它真正的價值在於把網路風險「描述得清楚」。當你用層級與角色設計通路、用最小權限限制來源與端口、用 SG-to-SG 表達關係，再配合變更審查與定期盤點，安全組就會從負擔變成資產。

你會發現真正難的不是一次把規則寫對，而是讓團隊在未來仍能改得安全、改得快、改得安心。把安全組設計成可讀、可審查、可回滾的結構，你就在本質上完成了「安全」到「工程化治理」的落差。