首頁  >  文章  >  運維  >  如何合理規劃和區分不同的安全群組

如何合理規劃和區分不同的安全群組

坏嘻嘻
坏嘻嘻原創
2018-09-19 13:23:471980瀏覽

這篇文章帶給大家的內容是關於如何合理規劃和區分不同的安全群組,有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助。

在安全群組的使用過程中,通常會將所有的雲端伺服器放置在同一個安全群組中,從而可以減少初期配置的工作量。但從長遠來看,業務系統網路的互動將變得複雜且不可控制。在執行安全群組變更時,您將無法明確新增和刪除規則的影響範圍。

合理規劃和區分不同的安全群組將使得您的系統更便於調整,梳理應用程式提供的服務並對不同應用進行分層。這裡推薦您對不同的業務規劃不同的安全群組,設定不同的安全群組規則。

區分不同的安全性群組

公網服務的雲端伺服器和內網伺服器盡量屬於不同的安全性群組

#是否對外提供公網服務,包括主動暴露某些連接埠對外存取(例如80、443 等),被動地提供(例如雲端伺服器具有公網IP、EIP、NAT 連接埠轉送規則等)連接埠轉送規則,都會導致自己的應用程式可能被公網存取。

2 種場景的雲端伺服器所屬的安全群組規則要採用最嚴格的規則,建議拒絕優先,預設應關閉所有的端口和協議,僅暴露對外提供需要服務的端口,例如80 、443。由於僅對屬於對外公網存取的伺服器編組,因此調整安全群組規則時也較容易控制。

對於對外提供伺服器編組的職責應該比較明晰和簡單,避免在同樣的伺服器上對外提供其它的服務。例如 MySQL、Redis 等,建議將這些服務安裝在沒有公有網路存取權限的雲端伺服器上,然後透過安全群組的群組授權來存取。

如果目前有公有網路雲端伺服器已經和其它的應用在同一個安全群組 SG_CURRENT。您可以透過下面的方法來進行變更。

梳理目前提供的公網服務暴露的連接埠和協議,例如 80、443。

新建立一個安全群組,例如 SG_WEB, 然後新增對應的連接埠和規則。

說明:授權策略:允許,協定類型:ALL, 埠: 80/80,授權對象: 0.0.0.0/0,授權策略:允許,協定類型:ALL,連接埠: 443/443 授權對象: 0.0.0.0/0。

選擇安全群組 SG_CURRENT, 然後新增一條安全性群組規則,群組授權,允許 SG_WEB 中的資源存取SG_CURRENT。

說明:授權策略:允許,協定類型:ALL,連接埠:-1/-1,授權物件:SG_WEB,優先權:依照實際情況自訂[1-100]。

將一台需要切換安全性群組的實例 ECS_WEB_1 新增到新的安全性群組。

在 ECS 控制台中,選擇 安全性群組管理。

選擇 SG_WEB > 管理實例 > 新增實例,選擇實例 ECS_WEB_1 加入新的安全性群組 SG_WEB 中,確認 ECS_WEB_1 實例的流量和網路運作正常。

將 ECS_WEB_1 從原來的安全群組中移出。

在 ECS 控制台中,選擇 安全性群組管理。

選擇 SG_CURRENT > 管理實例 > 移出實例,選擇 ECS_WEB_1 ,從 SG_CURRENT 移除,測試網路連通性,確認流量和網路正常運作。

如果工作不正常,將 ECS_WEB_1 仍加回安全性群組 SG_CURRENT 中,檢查設定的 SG_WEB 暴露的連接埠是否符合預期,然後繼續變更。

執行其它的伺服器安全性群組變更。

不同的應用程式使用不同的安全性群組

#在生產環境中,不同的作業系統大多情況下不會屬於同一個應用分組來提供負載平衡服務。提供不同的服務意味著需要暴露的連接埠和拒絕的連接埠是不同的,建議不同的作業系統盡量歸屬於不同的安全性群組。

例如,對於 Linux 作業系統,可能需要暴露 TCP(22)連接埠來實作 SSH,對 Windows 可能需要開通 TCP(3389) 遠端桌面連線。

除了不同的作業系統歸屬不同的安全群組,即便同一個鏡像類型,提供不同的服務,如果之間不需要透過內部網路存取的話,最好也劃歸不同的安全群組。這樣方便解耦,並對未來的安全群組規則進行變更,做到職責單一。

在規劃和新增應用程式時,除了考慮分割不同的虛擬交換器設定子網,也應該同時合理的規劃安全群組。使用網段 安全群組約束自己作為服務提供者和消費者的邊界。

具體的變更流程請參考上面的操作步驟。

生產環境和測試環境使用不同的安全組

#為了更好的做系統的隔離,在實際開發過程中,您可能會建構多套的測試環境和一套線上環境。為了更合理的做網路隔離,您需要對不同的環境配置使用不通的安全策略,避免因為測試環境的變更刷新到了線上影響線上的穩定性。

透過建立不同的安全性群組,限制應用程式的存取域,避免生產環境和測試環境連結。同時也可以對不同的測試環境分配不同的安全組,避免多套測試環境之間互相干擾,提升開發效率。

只對需要公網存取子網路或雲端伺服器分配公網IP

不論是經典網路還是專有網路(VPC)中,合理的分配公網IP 可以讓系統更方便地進行公網管理,同時減少系統受攻擊的風險。在專有網路的場景下,在建立虛擬交換器時,建議您盡量將需要公網存取的服務區的IP 區間放在固定的幾個交換器(子網路CIDR)中,方便審計和區分,避免不小心暴露公網訪問。

在分散式應用程式中,大多數應用程式都有不同的分層和分組,對於不提供公網存取的雲端伺服器盡量不提供公網IP,如果有多台伺服器提供公網訪問,建議您設定公網流量分送的負載平衡服務來公網服務,提升系統的可用性,避免單點。

對於不需要公網存取的雲端伺服器盡量不要分配公網 IP。專有網路中當您的雲端伺服器需要存取公網的時候,優先建議您使用NAT 網關,用於為VPC 內無公網IP 的ECS 執行個體提供存取網際網路的代理服務,您只需要設定對應的SNAT 規則即可為具體的CIDR 網段或子網路提供公網存取能力,具體設定請參考SNAT。避免因為只需要存取公網的能力而在分配了公網 IP(EIP) 之後也向公網暴露了服務。

最小原則

安全群組應該是白名單性質的,所以需盡量開放和暴露最少的端口,同時盡可能少地分配公網IP。若想存取線上機器進行任務日誌或錯誤排查的時候直接分配公網IP 或掛載EIP 雖然簡便,但是畢竟會將整個機器暴露在公網之上,更安全的策略是建議透過跳板機來管理。

使用跳板機

跳板機由於自身的權限龐大,除了透過工具做好審計記錄。在專有網路中,建議將跳板機分配在專有的虛擬交換器之中,對其提供相應的 EIP 或 NAT 連接埠轉發表。

首先建立專有的安全群組 SG_BRIDGE,例如開放對應的端口,例如 Linux TCP(22) 或 Windows RDP(3389)。為了限制安全群組的入網規則,可以限制可以登入的授權對象為企業的公網出口範圍,減少被登入和掃描的機率。

然後將作為跳板機的雲端伺服器加入到該安全性群組中。為了讓機器能存取對應的雲端伺服器,可以配置對應的群組授權。例如在 SG_CURRENT 新增一條規則允許 SG_BRIDGE 存取某些連接埠和協定。

使用跳板機 SSH 時,建議您優先使用 SSH 金鑰對而不是密碼登入。

總之,合理的安全群組規劃使您在擴容應用時更加游刃有餘,同時讓您的系統更加安全。

以上是如何合理規劃和區分不同的安全群組的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn