假設今天你人在家，突然收到同事的訊息：「洧杰網站出問題了，求救 RRR！！！」

於是乎你打開電腦，準備用 SSH 遠端登入 AWS 上的 EC2 主機，卻發現怎麼連都連不上

奇怪，白天在公司明明可以，TCP 22 也有開啊？

這就接回我們本日的主題哩，Port 有開，但允許的來源是誰？

上一篇我們認識了 Security Group（安全群組），後面簡稱 SG，也知道 Inbound 是連進來、Outbound 是連出去。今天就用這個情境，繼續看規則裡的 Port 跟 Source（來源）

先回到這張全貌圖，今天一樣看橘色的 SG，本日主角就是旁邊那一小格的「TCP 443、來源 0.0.0.0/0」

這裡也幫大家整理一下目前我們走到哪裡：

例如網站要給大家看，但 SSH 遠端登入只想給辦公室，資料庫只想給網站主機連

都是「允許連進來」，允許的對象卻不一樣，這樣資訊安全才能做到落實把關

或許大家會很疑惑，不是在教 AWS 嗎？為啥要花時間講這段，但真正安全的雲服務設計，絕大部分時間都得在這些最基礎實務上的網路安全做好把關，才能讓基礎設計好好運作勒 :D

我們繼續接著下去~

一條 Inbound 規則，要看哪些欄位？

假設網站要給大家看，但遠端登入主機的 SSH 只給辦公室使用，可以像這樣設定：

203.0.113.10 是這篇舉例用的 IP，實際設定 SSH 來源時，要換成公司對外連線使用的公有 IP；網站那一行的 0.0.0.0/0 則表示所有 IPv4 來源

第一行是在說：「允許任何 IPv4 來源連到 TCP 443。」第二行則是：「只有來源 IP 是 203.0.113.10，才能連到 TCP 22。」（可以看下 AWS 規則範例）

前幾篇我們看過 /16、/24，這裡的 /32 就是只指定一個 IPv4 位址。而 0.0.0.0/0 的範圍包含所有 IPv4 位址

如果整間辦公室共用一個對外 IP，那符合 /32 的可能有好幾台電腦，不是只認得你這個人。SSH 登入時需要的金鑰等驗證，也還是要照常處理

所以 Port 是允許連哪個服務，來源是允許誰來連。想限制哪些來源可以用 SSH 連進來，要改的是來源才是。如果把規則的 22 改成 443，不會讓 SSH 自動變安全，也不會讓主機上的 SSH 服務跟著換 Port 哦

我人在家，為啥連不上勒？

回到剛剛的情境，假設公司對外連線使用的公有 IP 是 203.0.113.10，家裡的是 198.51.100.20，而 EC2 使用的 SG 只有前面那條 SSH 規則

白天從公司連，來源符合 203.0.113.10/32。晚上換成家裡直接連，來源就不符合了

同一個人、同一台筆電、同一把 SSH 金鑰，也會因為來源 IP 不同，被 SG 擋住

那公司限制這麼嚴，人在家遇到問題，要怎麼處理？

先連公司電腦，再由公司電腦連 EC2

假設公司原本就有一套透過 VPN 與遠端桌面，讓工程師遠端處理主機問題的流程，你在家使用的是公司核准、符合設備要求的筆電

VPN 可以讓你透過加密連線，連到公司允許你使用的內部主機或服務。在這個例子裡，公司只開放你連到需要的管理電腦，沒有把整個內網都開給你

那流程就可以整理成：

公司核准的筆電 → 公司 VPN＋MFA → 遠端操作公司管理電腦 → SSH 到 EC2

你先登入公司 VPN，完成 MFA 多因素驗證，例如密碼加上驗證器，再透過遠端桌面操作公司管理電腦。接下來，是在公司那台電腦上執行 SSH，連到 EC2

如果公司電腦是透過公司的網路連到 EC2，EC2 看到的來源就是公司的公有 IP，所以會符合規則

所以雖然你人還坐在家裡，送到 EC2 的這段 SSH，已經是從公司電腦發出去了。SG 檢查的是連線來源，不是工程師現在坐在哪裡~

注意，這裡限制的是「SSH 連進這台 EC2」，不是說整個 AWS 網站都只能在公司登入。AWS Console（你用瀏覽器操作 AWS 的管理頁面）的登入與權限，是另外一件事

經過公司電腦，就一定安全嗎？

也不能這樣想勒，圖裡綠色的勾勾，只代表來源符合 SG 規則，不代表 SSH 已經登入成功。公司核准的設備與流程、MFA、操作權限和紀錄仍然要做得 ok

如果公司電腦被入侵，也可能從同一個 IP 發出連線，所以不能只看公司 IP 就認定安全、合規，這裡也可以看（AWS 遠端存取說明）

實務上，一定要繞回公司電腦嗎？

我覺得也不一定，還是看公司的技術長決定要怎麼規劃

前面是公司已經有這套流程的例子。如果是重新規劃工程師要怎麼遠端管理 EC2，也可以評估 AWS Systems Manager Session Manager：透過 IAM 控制誰能連哪台主機，不必先繞回公司電腦

也不用為這種連線開放 SSH 的連入 Port。就提供給讀者另一個選項（官方介紹）

如果改成筆電連上 VPN 後直接 SSH，EC2 看到的來源，要看這段 SSH 是走家裡的網路，還是透過 VPN 走公司的網路，不一定會變成公司 IP 哩。前面圖裡則是由公司電腦發出 SSH，兩種情況就也不一樣（AWS 說明：哪些連線會走 VPN）

那直接增加家裡的 IP 呢？如果公司政策允許，而且經過核准，可以新增家裡的 /32 規則；原本辦公室還要用，就保留原本那條。臨時開放的來源，用完也要依流程移除

但不要為了救急，把 SSH 來源直接改成 0.0.0.0/0，或把一個 IP 的 /32 放大成整段 /24。那會把不需要的來源一起放進來

從上面分享的系列，你就發現要連進 ec2 主機有很多種方式，你也能從上面所提到的關鍵字來評估，究竟公司要採取哪種方式可以既嚴謹又保持彈性空間勒 :D

下一個討論的議題，資料庫的來源，為什麼可以填 web-sg？

剛剛看的是工程師從外面連 EC2，接下來回到第一張全貌圖，把網站再往後接一段：網站上的後端程式要查資料，所以會主動連到資料庫

下面用 Web 代表網站主機，DB 代表資料庫主機。兩台都在同一個 VPC，透過私有 IP 直接連線

這裡以 PostgreSQL 資料庫常用的 TCP 5432 為例

我們把網站使用的 SG 叫 web-sg，資料庫使用的叫 db-sg。如果 DB 只需要給網站主機查資料，可以在 db-sg 的 Inbound 放這一行：

這意思是 允許使用這個 web-sg 的來源主機，連到 DB 的 TCP 5432。AWS 實際用來辨認 SG

這張圖先假設路由、Web 的出站規則，以及其他網路與服務設定都正常，DB 也沒有其他允許規則。我們只看「新的連線能不能通過 DB 的 Inbound」

你會發現，兩邊都要連 TCP 5432，但只有上面使用 web-sg 的主機符合來源條件，下面那台不符合

例如網站的私有 IP 從 10.0.1.10 換成 10.0.1.30，只要新的網站主機仍然使用這個 web-sg，DB 就不必為這次 IP 變動修改來源

相對來說，另一台主機就算也在同一個 Subnet，沒有使用 web-sg，也不會符合這條規則

這裡再來換個條件，假如 IP 沒變，但 Web 改成只使用另一個 new-web-sg 呢？這時就不符合原本的來源了，因為 DB 規則的來源，填的還是舊的 web-sg

所以要看的是「Web 現在實際使用哪個 SG」，不能只看主機的 IP 有沒有變

那 web-sg 裡如果有開網站的 443，會不會也複製到 DB？

不會喔，這裡只是拿 web-sg 辨認哪些來源符合規則，沒有把它整份規則搬過來。DB 允許的仍然是這一行寫的 TCP 5432

不過，網站主機的 Outbound 也要允許它連到資料庫的 TCP 5432。你在 DB 設定「允許網站主機連進來」，不會連網站主機那邊的規則也一起改好，兩邊都要確認喔

Port 對了，但來源卻選成另一個 SG，會發生什麼事呢？

最後把今天的內容串起來看

假設資料庫原本給報表主機使用，它的 Inbound 只有這條：

現在網站也要查同一個資料庫。網站只使用 web-sg，但 DB 的規則允許的是 report-sg，所以雖然 Port 一樣，網站發起的新連線還是不符合來源條件

這時候如果報表主機也還要用，就新增一條 web-sg 的規則：

不用為了網站，把原本的報表來源換掉，也不用把資料庫開給所有 IP

檢查的順序也可以照這個順序看：

小結

回頭看第一張全貌圖，紫色路由表管資料往哪裡送，橘色 SG 則要繼續確認方向、Port 跟來源

下次如果你聽到工程師問「我明明已經開 Port 了，怎麼還是連不上」，就可以接著問：

1. 是誰要連誰？改的是被連線那台主機的 Inbound 嗎？
2. 協定、Port 和來源，有沒有一起符合規則？
3. 如果要新增來源，原本那個來源是不是也還要保留？

這樣就比較知道要查哪一段出了問題，不用看到連不上，就把所有設定亂改一通.. 冏

希望這篇有讓你對 SG 的規則更有概念，我們下篇見 :D