AWS帳號安全認證 AWS EC2安全組設置方法
安全組是什麼？——雲端伺服器的「守門人」
AWS EC2安全組就像你家的門禁系統，只讓「白名單」的人進出。它是一個虛擬防火牆，控制進出EC2實例的流量。誤設安全組可能導致：
- 黑客直接入侵伺服器
- 合法用戶無法連接
- 資料外洩風險
但別怕！只要掌握以下技巧，安全組設置就像玩「樂高」一樣簡單～
第一步：創建安全組——手把手教學
打開AWS控制台 → EC2 → 左側導航欄點擊「安全組」→ 點「建立安全組」按鈕。這時你需要填：
- 安全組名稱：建議用「專案-環境-用途」格式，例如「e-commerce-prod-web」，別用「test」或「default」，否則你後悔莫及！
- 描述：詳細說明用途，例如「生產環境Web伺服器，僅允許HTTP/HTTPS和指定IP的SSH」
- VPC：選擇正確的VPC，錯誤的VPC會導致安全組無法綁定到實例
點擊「建立安全組」後，你會看到空規則列表，這時就要開始添加規則了。
命名避坑指南
AWS帳號安全認證 很多人覺得命名不重要，但實際上，安全組名稱就像公司的員工編號，亂七八糟的名字會讓維護變得瘋狂。例如：
- 錯誤範例：sg-12345（AWS自動生成的ID）、web-sg、prod-sg
- 正確範例：shop-prod-web-01、blog-staging-db
記住：名稱要易讀、可搜索、有含義。AWS允許最多255個字符，但建議控制在20字內，方便管理。
第二步：設定入站規則——誰能敲門？
入站規則決定哪些流量可以進入你的實例。重點在「最小權限」，能開一個端口，絕不開兩個！
HTTP/HTTPS開放策略
如果你要運行網站，必須開放80（HTTP）和443（HTTPS）端口。但別傻傻地填「0.0.0.0/0」（代表全球都能訪問）！除非你的網站是公開的，否則應該：
- 只允許特定IP（如公司辦公室IP）
- 或用AWS WAF過濾流量，再配合安全組
舉例：在「來源」欄位填「203.0.113.1/32」，這樣只有IP 203.0.113.1能訪問。但若你用雲端CDN（如Cloudflare），就要開放CDN的IP段，而不是直接開放0.0.0.0/0。
SSH連接小心機
SSH（端口22）是黑客最喜歡的攻擊目標！千萬別開放給全網：
- 錯誤做法：來源 0.0.0.0/0
- 正確做法：只允許你電腦的IP，例如「192.0.2.1/32」
如果需要從多個地點連接，可以用「AWS EC2 Session Manager」直接在控制台連接，無需SSH，這樣更安全。或者用「堡壘機」集中管理。
第三步：出站規則——你的伺服器能去哪？
出站規則控制實例發出的流量。AWS預設是「允許所有出站」，但這其實有風險！
預設規則的隱形危機
如果安全組的出站規則是「允許所有」，即使你限制了入站，實例仍可能：
- 被駭客用來攻擊別人
- 發送垃圾郵件
- 下載惡意軟體
所以，建議針對性設定出站規則。例如：
- Web伺服器只需要連接特定的API，就只開對應的端口
- 資料庫伺服器只允許Web伺服器的IP連接（入站規則），但出站可以限制為僅允許特定應用伺服器的IP
實際操作：在安全組規則頁面，點擊「新增出站規則」，設定協議、端口、目標IP範圍。例如：TCP/3306，來源為Web伺服器的安全組ID。
第四步：常見問題與解決方案
即使設好安全組，還是常遇到問題？以下是幾個典型情況：
問題一：無法SSH連接伺服器
可能原因：
- 安全組未開放SSH端口（22）
- 來源IP未正確設定（例如你現在的IP變了，但安全組沒更新）
- 實例的網路ACL（NACL）阻擋了流量
- 本地防火牆設置問題
解決步驟：
- 檢查安全組入站規則，確認22端口允許你的IP
- 在AWS控制台確認實例的IP地址是否正確
- AWS帳號安全認證 檢查網路ACL是否允許入站流量（網路ACL是VPC層級，預設允許所有，但若修改過需確認）
- 嘗試用AWS Systems Manager Session Manager連接，跳過SSH直接操作
問題二：網站無法訪問
檢查點：
- 80/443端口是否開放？來源是否正確？
- Web服務（如Apache/Nginx）是否正在運行？
- SSL證書是否過期？
- 負載均衡器（ELB）的安全組設定是否正確？
特別注意：如果你用ELB，安全組要設定在ELB上，而不是實例本身！很多新手把規則設在實例上，卻忘記ELB的安全組也需要開放80/443。
第五步：安全組最佳實踐——老司機的保命秘訣
以下這些方法，能讓你的安全組更安全、更易管理：
最小權限原則：能開1個，絕不開2個
舉例：資料庫伺服器只需要被Web伺服器訪問，就只開放Web伺服器的安全組ID作為來源，而不是整個VPC（0.0.0.0/0）。這樣就算Web伺服器被攻破，黑客也無法直接連接資料庫。
使用安全組引用：避免寫死IP
假設你有10台Web伺服器，每台都需要開放SSH給管理員。如果每個安全組都手動填管理員IP，當IP變更時，要改10次！正確做法是：
- 建立一個「Admin-SG」安全組，包含所有管理員的IP
- Web伺服器的安全組中，入站規則的「來源」填「Admin-SG」的ID
AWS帳號安全認證 這樣管理員IP只要更新一次，所有Web伺服器自動同步，省時又省心。
定期審查：別讓安全組「長毛」
很多公司的安全組規則堆積了大量歷史遺留配置，例如：
- 過去測試用的臨時規則
- 已下線服務的端口開放
- 錯誤的IP範圍
建議：
- 每季度檢查一次安全組規則
- 用AWS Config設定自動檢查規則，例如「禁止0.0.0.0/0開放22端口」
- 刪除不再使用的規則，保持簡潔
實際案例：架設WordPress的安全組配置
假設你要建立一個WordPress網站，以下是正確配置步驟：
步驟一：創建Web伺服器安全組
名稱：web-sg-prod，描述：WordPress Web Server
AWS帳號安全認證 入站規則：
- HTTP (TCP/80) → 來源：0.0.0.0/0
- HTTPS (TCP/443) → 來源：0.0.0.0/0
- SSH (TCP/22) → 來源：[你的辦公室IP]/32
步驟二：創建資料庫安全組
名稱：db-sg-prod，描述：MySQL Database
入站規則：
- MySQL (TCP/3306) → 來源：web-sg-prod的安全組ID（例如sg-123456）
這樣，只有Web伺服器可以存取資料庫，其他任何設備都無法直接連接，大幅提升安全性。
結語：安全組是你的最後一道防線
安全組雖小，卻是雲端安全的關鍵環節。設定時要像檢查門鎖一樣仔細，定期維護才能確保萬無一失。記住：沒有絕對的安全，只有持續的改進。現在就去檢查你的安全組，別讓黑客有機可乘！
