AWS代理商開戶 AWS安全組Security Group規則設置教學
第一章：你真的需要先搞懂安全組在做什麼
AWS 安全組（Security Group，SG）是你為 EC2、以及部分支持 SG 的資源設定網路通行規則的工具。直白點說，它像一張「防火牆通行證」，指定哪些來源可以進來、哪些目的端口可以連、以及允許的網路範圍是什麼。當你在控制台新增一條規則，你並不是在「開通網路」，而是在明確回答：從哪裡來、要走哪個門、用什麼協定，可以進到資源上。
安全組的特性決定了你後續的設置方式。它主要有兩個方向：入站（Inbound）與出站（Outbound）。入站是別人連你能不能成功；出站是你要連別人要不要放行。這兩者都要想清楚，因為很多人只關心入站，卻忽略了應用程式需要回連、或需要對外下載套件、連到資料庫等情況，結果就卡在「連線逾時」或「連上但回應不通」這種難排錯的狀況。
另外，安全組是「狀態防火牆」（Stateful）：一旦你允許了入站流量並且建立連線，回程通常會自動放行（不需要你額外寫出回應方向的規則）。但這不代表你可以放鬆出站。狀態的概念主要幫你省掉很多回包規則，卻不會替你處理「你連不出去」的問題。
最後，也是最常被忽略的：安全組規則是「允許清單」。未被允許的流量一律不通。你看到的規則越少，代表暴露面越小；你看到的範圍越寬（例如 0.0.0.0/0），風險越高。教學的重點，就是教你用最少的規則達成需求，同時把風險降到合理範圍。
第二章：安全組的基本結構與幾個關鍵概念
2.1 安全組綁在什麼地方？
對 EC2 來說，安全組綁在網路介面（Network Interface）或直接綁在實例上。你同一個實例可以綁多個安全組，而規則效果會「合併」：只要其中一個安全組允許，就可能通過。這帶來好處：你能把規則拆成角色或用途（例如 Web、安全運維、資料庫），但也容易造成「以為自己沒開，結果其他安全組開了」的誤判。因此在設置時要保持命名與文件化。
2.2 入站規則：你在問「誰可以連我、連什麼」
AWS代理商開戶 入站規則通常包含以下欄位：協定（TCP/UDP/ICMP）、來源（Source，常見是 CIDR，例如公司網段、或另一個安全組）、端口範圍（Port Range）、描述（Description）。你每新增一條規則，都等於把「某類連線」允許進入該資源。
來源的選擇很重要。來源可以用 IP/CIDR，也可以用「另一個安全組」。例如你希望只有前端安全組的資源可以連你的後端服務，就可以用「Source = 前端安全組」的方式。這比寫死 IP 網段更穩，因為前端的擴縮容不需要你反覆改 CIDR。
AWS代理商開戶 2.3 出站規則：別只看入站
很多情況下，安全組的預設出站會是允許（例如允許所有目的地）。這在教學或小型測試環境可能看起來方便，但在正式環境你應該思考：你的服務是否真的需要對外開放所有目的地所有端口？通常不需要。
如果你的服務只要連到特定的資料庫、安全的外部 API、或內部的其他服務，就應限制出站目的地与端口。這樣即使應用程式有漏洞被利用，也更難把連線擴散到你不想暴露的系統。
AWS代理商開戶 第三章：最小權限原則如何落到規則設置上
「最小權限」聽起來抽象，但你完全可以把它變成具體做法：只開你需要的協定與端口，只允許你需要的來源與目的地，且可預期地縮小範圍。
在安全組裡，你能控制三個主要維度：
- 協定：例如 Web 多半是 TCP 80/443；DNS 是 UDP 53；SSH 是 TCP 22。不要用錯協定。
- 端口：只開必要端口。很多人會把「整段 0-65535」當作省事，但那會把風險放到最大。
- 來源/目的地範圍：能用安全組就用安全組；能用公司網段就用公司網段；如果必須用公網，至少先限制到必要的少數來源。
此外，描述（Description）一定要寫。描述不是給系統看的，是給未來的你、或團隊成員看的。當你半年後回頭排查「為什麼可以連上」或「為什麼改不了」，描述能把你從猜測拉回到事實。
第四章：從零開始設置一個安全組（以 Web 服務為例）
4.1 假設場景
你有一台 EC2 提供 Web 服務（例如 Nginx 或應用程式），需要對外開放 HTTPS（443）。同時你希望允許 HTTP（80）只做跳轉或健康檢查。你不打算把 SSH 直接暴露給公網，而是只允許公司固定出口 IP 或堡壘機。
4.2 入站規則設置
你可以這樣規劃：
- HTTPS（TCP 443）：來源設為你可接受的範圍。如果是對全網公開的網站，就允許 0.0.0.0/0 或你的入口（例如 CloudFront 使用的來源）。如果是內部服務，就改成內部網段。
- HTTP（TCP 80）：若只做導流或健康檢查，同樣可從必要來源開放；若你完全不需要 80，可以直接不開。
- AWS代理商開戶 SSH（TCP 22）：來源設為你的管理來源（公司網段、VPN 網段、或運維安全組）。不要用 0.0.0.0/0。
注意：規則順序在安全組中通常不影響結果，因為它是「允許清單」而不是「從上到下命中」。因此你更該關心的是「有沒有」與「範圍是不是正確」。
4.3 出站規則設置
接著你要看應用程式需要連什麼。常見 Web 伺服器會：
- 連到外部更新服務或套件倉庫（例如 npm、apt）
- 連到內部資料庫（例如 RDS）
- 連到內部 API 或其他服務
AWS代理商開戶 如果你允許出站所有目的地，先能跑起來，但不利於控風險。更好的方式是把出站改成「只允許必要目的地與端口」。例如：
- 目的地是資料庫安全組，端口是資料庫端口（如 MySQL 3306、PostgreSQL 5432）
- 目的地是內部服務安全組，端口是該服務的端口
- 若需要對外 DNS/HTTPS 做外部呼叫，再分別允許必要的 DNS（53）與 HTTPS（443）
你不一定一開始就做到完全嚴格。教學的重點是：先建立合理可用的規則，再逐步收斂出站範圍。
第五章：用安全組作為來源（Source = Security Group）的實戰好處
很多團隊一開始喜歡寫 CIDR，因為看起來直觀。但 CIDR 的痛點是：你的服務節點一旦擴縮容、或部署到不同子網，IP 可能變動，你的規則就要跟著改。更麻煩的是跨 VPC、跨環境、跨區域的治理。
AWS代理商開戶 如果你的來源與目的地都在同一個 VPC，且使用安全組能代表「角色」，你就能用「Source = 另一個安全組」。這時候你不需要知道來源節點的 IP 是什麼，因為只要它屬於那個安全組，流量就被允許。
例如：
- 前端安全組：只允許外部負載平衡器到前端服務的入站 80/443
- 後端安全組：只允許前端安全組到後端的入站 8080 或 3000
這種設計讓你在擴容或替換節點時不用大動規則。規則會更像「架構圖」，而不是「IP 表格」。在中大型環境，這會顯著降低維運成本與出錯率。
第六章：SSH、管理介面與運維風險控制
SSH 是最常見的被攻擊入口。即使你把 SSH 用在內網運維，也仍需要防範「憑證被撞庫」與「暴力掃描」。因此在安全組上，你要做的不只是「能連上」，而是「連線來源可控、可追溯、範圍可收斂」。
建議做法：
- 不要用 0.0.0.0/0 對 22/tcp。
- 能用 VPN 或堡壘機就用堡壘機：運維入口集中管理，其他伺服器只允許堡壘機安全組。
- 只允許你實際需要的來源 IP/CIDR（例如辦公室固定出口）。如果你出口 IP 會變動，記得定期更新或改用 VPN。
- 把 SSH 的規則加上描述，包含「目的」與「責任人」。例如「For ops admin from Corp VPN」。
此外，安全組不是唯一防護。即使你設了來源限制，你也應搭配更安全的做法，例如禁用密碼登入、使用金鑰、限制登入用戶、搭配 fail2ban 或更高層級的控管。這些策略不在安全組內，但它們共同決定你整體的風險。
第七章：資料庫連線（例如 RDS）如何寫規則才合理
資料庫的安全組規則通常比 Web 更敏感。因為資料庫不該被「到處連」。一個常見誤區是：資料庫安全組允許整個 VPC 的網段進入端口。聽起來方便，但在 VPC 裡任何被攻破的服務，都可能嘗試直接攻擊資料庫。
更好的做法是用安全組串起來：只允許應用服務的安全組連到資料庫的端口。
例如：
- 應用安全組：對外提供 443/80（入站自負載平衡器或公網必要來源）
- 資料庫安全組：入站只允許「應用安全組」到「3306」或「5432」
這樣你即使增加新的應用節點，只要它綁在正確的安全組，資料庫就能自動允許連線。反之，如果沒有綁到那個安全組，資料庫不會被開放。
出站方面，資料庫通常不需要連外很多。你至少可以先確保資料庫不會對外開放不必要的端口。是否收斂出站依你的運維與告警需求而定，例如資料庫可能需要連到備份服務、時間同步或監控代理。
第八章：常見場景的規則模板（你可以直接套用思路）
8.1 公網 Web 伺服器
- 入站：TCP 443，來源 0.0.0.0/0（或你的入口網段）
- 入站：TCP 80 視需求；若不需要可不開
- 入站：TCP 22 只允許運維來源（公司網段/VPN/堡壘機安全組）
- 出站：只允許連到資料庫安全組、必要外部服務端口
這樣做的核心是：對外開門，但對管理與底層保留嚴格控制。
8.2 內部 API（只讓特定服務呼叫）
- 入站：TCP 端口（例如 8080），來源設為「呼叫方安全組」而不是 CIDR
- 入站：SSH/管理端口（22）只允許運維安全組
- 出站：只允許需要的內部服務與必要外部端口
內部 API 常見需求是「服務之間授權」。用安全組串起來，規則就像權限模型，不像固定 IP。
8.3 容器或多服務共用一個節點
當你同一台 EC2 內跑多個服務，你通常會在應用層做路由（例如以 Nginx 或 API Gateway）。這時候安全組規則可能只需要開少數端口（例如 80/443），而不是讓每個內部服務的端口都對外暴露。
建議：
- 對外只開單一入口端口（80/443）
- 後端服務端口只允許來自本機或特定安全組（若能隔離，仍應隔離）
- 避免「把所有服務端口都開給內網網段」這種偷懶做法
8.4 需要對外呼叫第三方 API 的服務
- 入站如 Web/內部 API 的邏輯設定
- 出站：允許目的地在 443/tcp（HTTPS）到必要的域名所對應的 IP 範圍（若無法精準，至少限制到必要網段或使用更上層的網路控管）
如果你用的是 VPC NAT 或 Gateway，出站規則的控制仍能降低風險。尤其是你不應該「出站允許所有目的地所有端口」然後覺得無所謂。
第九章：排錯思路——連不上不是只有安全組這一件事
當你部署後發現「連線失敗」，很多人第一反應就是：安全組是不是壞了？安全組確實常見，但排錯要有順序，不然會越修越亂。
9.1 先確認是哪一段方向失敗：入站還是出站
- 如果你是外部用戶連不上 Web：優先檢查入站規則、來源 IP、端口與協定。
- 如果服務能被連到但內部無法呼叫資料庫：檢查出站規則與資料庫安全組。
- 如果你是從內網測試卻失敗：確認你測試端的來源 IP 是否落在來源 CIDR，或是否屬於被引用的安全組。
9.2 常見錯誤清單
- 端口寫錯（例如把 8080 寫成 8008）
- 協定寫錯（TCP/UDP 搞反）
- 來源 CIDR 錯誤（少了一個位元、或網段其實不同）
- 使用了 0.0.0.0/0 卻仍連不上（通常是其他層，例如目標服務未監聽、或 NACL/VPC 路由問題）
- 同一實例綁了多個安全組，卻忘了其中一個安全組其實允許或拒絕了你以為的方向（記得允許是合併效果）
9.3 同時檢查 NACL、路由與應用層
安全組只是一層。AWS 還有網路 ACL（NACL），還有子網路由、網關、以及目標服務是否真的在正確端口監聽。當你排查時，請把順序固定下來：
- 確認目的端口與協定在目標實例/容器內是否監聽
- 確認安全組入站/出站是否允許
- 確認 NACL 是否也允許該方向
- 確認路由與防火牆/網關設定（例如是否有 NAT、IGW、或企業出口策略）
把排錯做成流程，你就不會每次靠運氣。
AWS代理商開戶 第十章：規則管理與審計：讓安全組成為可控資產
當你的服務越來越多，安全組規則也會越來越多。這時候「規則管理」比你想像的更重要。否則你會在幾個月後失去掌控，出現以下狀況：
- 同一功能的安全組命名混亂，大家不知道該用哪一個
- 規則描述缺失，改了也不知道為何改
- 有些規則多年沒用仍保留，因為沒有人敢刪
實務上你可以做幾件很有效的事：
- 命名規則統一：例如 sg-角色-環境-區域。讓人一眼看出它的用途。
- 描述規則意圖：每一條入站至少寫明用途與來源（例如「Allow HTTPS from public」「Allow DB port from app-sg」）。
- 規則最小化：能用安全組來源就用安全組來源，避免用廣網段替代。
- 定期回顧：每個季度或每次發版後檢查是否有新增但沒移除的規則。
如果你有合規需求，還要能追蹤變更。你可能需要依靠 AWS 的審計與日誌機制（例如 CloudTrail 之類的系統）來記錄誰在何時改了安全組。即使沒有嚴格法規，這也能降低人為錯誤造成的風險。
第十一章：一套你能帶走的設置方法（照著做就不會亂）
最後把整篇文章變成可執行的步驟。當你要新建安全組或調整規則時，照這個順序走：
- 先列出需求：有哪些服務需要對外或對內被呼叫？使用哪些端口與協定？
- 定義來源與角色：使用安全組來代表角色，或用最小的 CIDR 範圍代表來源。
- 先寫入站，再寫出站：入站回答「誰可以連我」；出站回答「我需要連誰」。
- 避免廣網段預設：能收就收，能用安全組就用安全組。
- 加入描述與文件：每條規則寫清楚原因與對應系統。
- 測試後再收斂：先確保服務可用，再逐步把出站與來源收縮到更嚴格。
- 排錯按流程：先看端口與協定，再看安全組方向，再看 NACL 與路由，再回到應用層。
當你用這套方法，每次改規則都更接近「工程化」而不是「試錯」。更重要的是，你會逐漸建立一張清晰的安全架構圖：每個服務需要什麼權限、哪些規則是為了什麼而存在。
AWS代理商開戶 結語：把安全組當成權限模型，而不是設定頁面的臨時拼貼
AWS 安全組看起來只是幾條入站與出站的規則，但它背後其實是在表達權限：誰能連你、誰能被你連、以及在什麼端口上互動。只要你遵循最小權限、用安全組串角色、把描述與文件做好，再加上有節奏的排錯流程，你就能在不增加複雜度的情況下把安全性與可維運性一起提升。
你不需要一次就做到最嚴格。你需要的是把方向走對：從「能跑」走向「可控」，從「靠預設」走向「有意圖」。當你開始這樣做，安全組就不再是麻煩的設定，而是你的系統安全設計的落地工具。
