華為雲帳號開戶服務 華為雲國際站ECS安全組規則設置教學

第一章：為什麼要先懂安全組

在華為雲國際站上買了一台 ECS，很多人第一反應是「先把服務跑起來」。但真正踩坑的，往往不是程式，而是網路通道。你以為服務已啟動、端口也開了，外部卻連不上；或者你明明只想讓管理端口對你開放，最後卻把 0.0.0.0 全放通，等於把門敞著。這就是安全組存在的意義：把網路訪問用規則「收口」到你允許的範圍內。

安全組的核心觀念其實不難：它是一組封包過濾規則，決定「哪些流量能進 ECS」以及「ECS 能向哪裡發起連線」。在大多數雲平台中，安全組常被視為虛擬防火牆。你需要的不是記住所有參數，而是建立一套思考流程：先定使用場景，再定最小暴露面，最後用規則落實。

接下來的教學會以「入站規則為主、出站規則為輔」的方式展開。你會看到從零開始怎麼設：協議選什麼、端口填哪個範圍、來源怎麼限定、怎樣避免常見錯誤。最後還會提供幾個常見服務的配置模板，並教你排障時從哪裡查起。

第二章：ECS 安全組規則的基本結構

安全組通常由「規則」組成。每條規則大致包含這幾個要素：方向（入站/出站）、協議（TCP/UDP/ICMP 等）、端口範圍、來源/目標（IP 或網段，或其他安全組）。不同平台的界面會有差異，但邏輯一致。

2.1 入站規則：控制外部怎麼連進來

入站規則決定「誰能打到你的 ECS」。例如你想讓外網訪問網站的 80/443，就要在入站規則中允許 TCP 的 80、443，來源填入你希望放行的範圍（常見是你的公網 IP 或允許的地區網段）。如果你把來源設成 0.0.0.0/0，就等於任何人都能連。

對於 SSH（22）、RDP（3389）這種管理端口，入站規則更應該嚴格。最常見的做法是：只允許你的辦公室出口 IP，或只允許特定 VPN 網段。你也可以用「只允許某一安全組」來做內網服務互通，這樣更可控。

2.2 出站規則：控制你的 ECS 能去哪裡

出站規則決定「ECS 能對外發起連線」。例如你的 Web 服務需要連到外部 API、或需要拉取更新套件，就要允許它相應的連線。很多人懶得改出站，因為預設通常已足夠。但如果你追求嚴格隔離（例如雲上做內網安全區），出站規則就很重要。

實務上，出站規則常見的策略是：要能用就放行必要的目的（例如目標網段或必要端口），其餘一律拒絕。這樣就算某個服務被攻破，攻擊者在內的「橫向外連」能力也會被限制。

華為雲帳號開戶服務 2.3 協議與端口：不要只會填數字

很多初學者只記得「Web 是 80/443、SSH 是 22、MySQL 是 3306」。但真正要填正確的是「協議」和「端口方向」。比如：HTTP/HTTPS 是 TCP；DNS 通常是 UDP 53（但某些情境也用 TCP 53）；ICMP 用於 ping，並非所有場景都需要放行。

此外，端口範圍不要瞎用「全部端口」。例如你只需要 8443，就只開 8443，而不是 1-65535。越寬鬆，你的風險面越大，排障也越難，因為任何流量都可能通過安全組，問題就會變成「到底是哪一層」造成。

第三章：在華為雲國際站建立並套用安全組

下面用教學方式描述操作流程。由於介面可能會隨版本略有不同，但你可以把它當作「路線圖」。你需要完成兩件事：先建立安全組並加規則，再把安全組掛到 ECS 實例。

3.1 先找到 ECS 與安全組的位置

一般在雲平台的控制台中，會有「計算」或「ECS」服務入口。進入 ECS 後，常見會看到「安全組」或「Security Group」相關入口。你可以先確認你所在區域（Region）是正確的，因為不同區域的網路資源彼此不互通。

3.2 建立安全組：命名與基本選項

建立安全組時，建議你做兩件事：第一，命名要能識別用途與環境，例如：prod-web-sg、staging-ssh-allow、dev-db-only。第二，明確使用目的。不要一個安全組什麼都開，最後所有伺服器都套同一個規則，風險會成倍放大。

如果平台提供「描述」欄位，請把簡短目的寫清楚：例如「允許外網 80/443；SSH 僅允許辦公網段」。這對日後排障、交接尤其重要。

3.3 新增入站規則：一步一步填對

新增入站規則時，你需要面對幾個選擇：規則方向、協議、端口、來源。

• 方向：選「入站」。
• 協議：Web 用 TCP；SSH 用 TCP。
• 端口：填單端口或端口範圍，例如 80、443、22。
• 來源：用你的公網 IP（/32）或允許網段；不確定就先保守，能用白名單就不要用全放。

如果介面支持「IPv4 / IPv6」，也請注意你實際服務是否綁定到對應協議棧。尤其你若使用的是 IPv6，錯誤的來源型別會導致你以為「規則沒有生效」。

3.4 新增出站規則：先放行必要，再逐步收斂

出站規則同樣要填協議與端口，但方向是出站。通常預設允許所有出站，對初期建置比較方便。若你要做更安全的限制，建議循序推進：先以「能跑起服務」為第一目標，確認連線需求後，再逐項收斂出站。

特別是你如果使用需要外網的功能（更新套件、NTP 校時、連接第三方 API），盲目把出站限制成少數端口，可能會導致服務表面上正常、但其實功能異常。這時候排障會很痛苦。

3.5 把安全組掛到 ECS：讓規則真正生效

建立好安全組後，你需要在建立 ECS 或後續配置時，將該安全組選中並套用到實例。某些平台允許多個安全組同時掛載，這時入站/出站規則可能是「合併效果」。要小心的是：你可能以為「只要加入一條允許規則就夠」，但另一個安全組已經允許更寬的來源，結果會和你預期不一致。

所以最佳做法是：每個 ECS 實例保持安全組用途單一，或至少在設計上清楚「哪些安全組會被套到同一台」。

第四章：常見場景的安全組規則落地範例

下面給你幾個常見場景的「規則思路」與實際填法。你可以把它當作模板來套用，然後根據你的網段與端口調整。

4.1 場景一：公網 Web（HTTP/HTTPS）+ 嚴格 SSH

目標：讓外部訪問網站，但只允許你的 IP 管理。

• 入站：TCP 80，來源設為 0.0.0.0/0（或限定地區/白名單，視需求）。
• 入站：TCP 443，來源設為 0.0.0.0/0（或限定）。
• 入站：TCP 22，來源設為你的辦公公網 IP（例如 x.x.x.x/32），不要用 0.0.0.0/0。

出站：若預設允許所有出站也可先不改；若你要限制，至少放行必要端口（如 443 用於更新與 API），其餘按需求收斂。

這個組合是最常見的「可用且相對安全」做法。SSH 嚴格白名單能大幅降低掃描與暴力破解風險。

4.2 場景二：只對內提供服務（內網互通）

目標：網站不對公網開放，只讓內網其他 ECS 或同 VPC 的服務訪問。

• 入站：TCP 80/443，來源設為內網網段（例如 10.0.0.0/16 或你的實際子網）。
• 入站：TCP 22，來源設為運維跳板機的內網 IP 或安全組。

這裡的關鍵是「來源」要改成內網範圍，而不是公網。你如果用錯成 0.0.0.0/0，服務就會暴露在公網。

此外，如果你使用了多網卡或多子網，請確認來源網段和對端實際地址一致。很多內網問題其實不是安全組，而是路由或地址配置錯位。

4.3 場景三：資料庫（MySQL/PostgreSQL）僅限特定服務訪問

目標：資料庫只允許應用伺服器連線，禁止外部與其他主機自由連。

• 入站：TCP 3306（MySQL）或 TCP 5432（PostgreSQL），來源設為「應用伺服器」的 IP/網段，或使用安全組作為來源。
• 入站：TCP 22 只給管理來源。

若你採用「來源為某安全組」，通常會更穩定：當應用伺服器擴縮容時，只要它們都掛在那個安全組上，資料庫規則不用反覆修改。

華為雲帳號開戶服務 務必注意：資料庫端口不要對公網開。就算你設了密碼，也會面臨大量掃描。更糟的是，攻擊者常常不是靠爆破，而是靠漏洞與弱口令嘗試。

4.4 場景四：需要 ICMP（ping）但不要過度放行

有些情境你需要確認連線可達性，會想放行 ICMP。一般做法是：只允許來自特定來源的 ICMP，例如你監控系統或跳板機。

• 入站：協議選 ICMP，端口可能不適用（視平台），來源設為監控 IP 或管理網段。

不建議你為了方便就放行全部 ICMP。因為你開了會增加外部偵測與探測的可能性，安全收益並不划算。

第五章：進階設置要點（多安全組、多網卡與來源選擇）

當你部署的系統開始複雜，安全組的細節就會逐漸顯影。這一章講三個最常見的進階問題：多安全組疊加、來源選錯、以及多網卡或路由導致的誤判。

5.1 多安全組疊加：不要假設「只有一條規則」

很多平台允許同一 ECS 掛多個安全組。此時入站/出站的判斷可能是「只要有規則允許就放行」或「按規則合集」的效果。結果是：你後來加的一個規則，可能讓你原本以為被阻擋的流量也通過了。

建議你在設計上做「安全組職責分離」。例如：web-ports、ssh-admin、db-only 三個用途分開；並在部署時清楚每台 ECS 掛了哪幾個。你也可以在排障時暫時移除某個安全組來驗證原因，但實務上要小心服務中斷。

5.2 來源選擇：網段與單 IP 的差別

來源可以用單 IP（/32）或網段（例如 /24、/16）。你如果只需要允許一個出口 IP，就用 /32。你如果允許公司整段網段，才用更大的 CIDR。

常見錯誤是：把來源寫成錯誤網段。這會造成你「明明規則看起來正確，但就是連不上」。當你遇到這種情況，不要急著改端口，先確認你的連線出口 IP 是否確實落在規則來源範圍內。很多公司上網經過 NAT 或代理，出口 IP 可能和你以為的不一致。

華為雲帳號開戶服務 5.3 多網卡與路由：安全組只是其中一層

安全組只負責「是否允許封包」，但封包還要經過路由、交換、子網設定等。你可能遇到的情況是：安全組已允許，但因為路由或目的地址錯誤仍然連不上。

因此排障時要分層思考：先確認安全組是否允許；再確認 ECS 作業系統防火牆（例如 ufw、iptables、firewalld）是否放行；最後檢查服務是否真的在監聽該端口，以及是否綁定到正確的網卡 IP。

第六章：排障思路：連不上時怎麼查

連不上最常見的原因並不是安全組壞了，而是你在某個環節少做一步。下面用「由外到內」的順序幫你建立排查清單。

6.1 先確認目標端口與協議

例如你開了 TCP 443，但你的服務其實監聽的是 8443；或你以為是 HTTPS，其實前端連到的是 HTTP。先把「你要連的那個端口」與「服務實際監聽端口」對上。

6.2 再確認安全組規則是否真的命中

檢查三件事：協議是否一致、端口是否一致、來源 IP 是否在允許範圍內。尤其是來源，你要確認你的連線出口 IP 是不是會被代理或 NAT 替換成另一個地址。只要差一點點 CIDR 範圍就會失效。

6.3 檢查操作系統防火牆與服務狀態

即使安全組允許，ECS 作業系統仍可能阻擋。常見狀況包括：服務沒起來、只綁在 localhost、或系統防火牆沒有開該端口。你應該先在 ECS 上確認：服務是否在監聽（例如 netstat/lsof 類命令）、系統防火牆狀態、並確認程序是否有報錯。

華為雲帳號開戶服務 6.4 用最少測試縮小範圍

如果你開了多個端口，請先做最小化測試：只測 80 或只測 22。當你能確定其中一個通了，再逐步增加端口與來源範圍。這種方式通常比一開始全改全開更快找到根因。

第七章：安全性建議：把「可用」變成「可控」

華為雲帳號開戶服務 設定安全組的目的不是只讓功能跑起來，而是讓整套系統可維護、可稽核、可預期。下面是幾個值得你在部署時就固定下來的做法。

7.1 預設拒絕，放行最小需求

如果能用「白名單」就不要用「全放」。尤其管理端口（SSH/RDP）一定要收口。對 Web 服務，你可以根據業務需要決定是否對全網開放，但即使對全網開放，也應搭配最小化其他端口與服務端硬化。

7.2 用安全組作為來源，比用固定 IP 更穩

當你的應用伺服器會擴縮容，固定 IP 的管理會變得脆弱。改用「來源為某安全組」能把規則的生命週期與資源的生命週期綁在一起：新實例加入安全組，就自然取得連線權。

7.3 記錄規則的用途與變更原因

安全組規則看起來只是幾行設定，但日後出問題要回溯。建議你在建立安全組時填好描述，並在變更時記錄「為什麼放開」「放開到什麼範圍」「何時收回」。這對團隊交接與審計非常實際。

第八章：一份你可以直接套用的配置清單

華為雲帳號開戶服務 最後我給你一份簡單但實用的清單。你不需要把它背下來，只要照著走，你就能快速完成從零到可用的安全組設置。

8.1 建置前先寫三句話

• 這台 ECS 對外提供什麼服務？（例如 Web、API、SSH 管理）
• 誰需要連進來？（公網所有人？公司出口 IP？內網某網段？）
• 需要哪些端口與協議？（80/443 TCP、22 TCP、3306 TCP 等）

8.2 建安全組並按用途分拆規則

• 建立 web 類安全組：只放行必要的 Web 端口與來源。
• 建立 admin 類安全組：只放行 SSH/RDP，來源限定。
• 建立 db 類安全組：只放行資料庫端口，來源限定到應用端。

8.3 套用安全組並做最小測試

• 先測一個必需端口（例如 80 或 22）。
• 確認通後再逐步加入其他服務端口。
• 測試失敗時按「安全組→操作系統防火牆→服務監聽→路由」順序排查。

結語：安全組不是設定完成，而是持續管理

很多人把安全組當成一次性設定，但實際上它是安全策略的一部分。你會隨著業務擴張、服務升級、網段調整而不斷面臨新需求。真正成熟的做法是：每次擴展都回到「最小需求」的原則，不用臨時放開一堆端口解燃眉之急。

當你能把安全組規則理解成「對流量的合約」——只允許必要、允許可追溯、允許可維護——你就不會再把連不上當成運氣，也不會把安全當成事後補丁。你配置得越乾淨，日後越省時間；你收口得越早，風險越低。

如果你願意，我也可以根據你的具體場景（例如：你用的是哪個 Web 端口、是否需要外網、你管理連線來源是什麼網段、資料庫類型是 MySQL 還是 PostgreSQL）幫你把入站/出站規則整理成一份可直接照抄的安全組配置表。