在使用安全組的過程中，一個常見的錯誤是將所有的雲服務器放置在一個安全組之中，這樣雖然減少了初期配置的工作量，但是長期來看將會使得您的業務系統網絡交互變得複雜和不可控，在執行安全組變更的時候沒辦法明確的知道添加和刪除規則的影響範圍。
合理的規劃和區分不同安全組將使得您的系統更加便於調整，同時可以梳理應用的提供的服務和不同的應用進行分層。所以我們推薦您對不同的業務規劃不同的安全組，設置不同的安全組規則。
例如對於是否提供公網訪問和內網的應用使用不同的安全組，避免不小心疏忽暴露了不需要的服務到公網。同時要對測試環境和生產環境使用不同的安全組，這樣講使得發佈和變更更加安全，避免測試環境的業務影響線上的穩定性。本文將着重介紹一些在應用中創建和使用安全組的一些規則。
區分不同的的安全組
提供公網服務的雲服務器和內網服務器儘量屬於不同的安全組
是否對外提供公網服務，包括主動暴漏某些端口對外訪問，例如80、443等，被動的提供例如雲服務器具有公網IP、EIP、NAT端口轉發規則等都會導致自己的應用可能被公網訪問到。
這兩種場景的雲服務器所屬的安全組規則要採用最嚴格的規則，我們建議是拒絕優先，默認情況下應當關閉所有的端口和協議，僅僅暴露對外提供需要服務的端口，例如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暴漏的端口是否符合預期。然後繼續變更。
- 執行其它的服務器安全組變更。
不同的應用使用不同的安全組
在我們的生產環境中，不同的操作系統大部分情況下不會屬於同一個應用分組來提供負載均衡服務，提供不同的服務意味着需要暴露的端口和拒絕的端口是不同的，建議不同的操作系統儘量歸屬於不同的安全組。
例如對於我們常見的Windows和Linux，對於Linux操作系統，我們可能需要暴露TCP（22）端口來實現SSH，對於Windows可能需要開通TCP(3389)遠程桌面連接。
其實不只是不同的操作系統屬於不同的安全組，即便同一個鏡像類型，提供不同的服務，如果之間不需要通過內網進行訪問的話，最好也劃歸不同的安全組，這樣方便解耦和未來的安全組規則變更，做到職責單一。
在規劃和新增應用的時候，除了考慮劃分不同的虛擬交換機配置子網，也應該同時合理的規劃安全組。使用網段+安全組約束自己的作爲服務提供者和消費者的邊界。
具體的變更流程參見上面的操作步驟。
生產環境和測試環境使用不同的安全組
爲了更好的做系統的隔離，在實際開發過程中，我們可能會構建多套的測試環境和一套線上環境。爲了更合理的做網絡隔離，我們需要對不同的環境配置使用不通的安全策略，避免因爲測試環境的變更刷新到了線上影響線上的穩定性。
通過創建不同的安全組，限制應用的訪問域，避免生產環境和測試環境聯通。同時也可以對不同的測試環境分配不同的安全組，避免多套測試環境之間互相干擾，提升開發效率。
僅對需要公網訪問子網或者雲服務器分配公網IP
不論是經典網絡還是專有網絡(VPC)中，合理的分配公網IP可以讓系統更加方便的做公網管理，同時減少系統受攻擊的風險。在專有網絡的場景下，創建虛擬交換機的時候，我們也建議您儘量將需要公網訪問的服務區的IP區間放在固定的幾個交換機(子網CIDR)之中，這樣方便審計和區分，避免不小心暴漏公網訪問。
在分佈式應用中，大多數應用都有不同的分層和分組，對於不提供公網訪問的雲服務器儘量不提供公網IP，如果是有多臺服務器提供公網公網訪問，建議您配置公網流量分發的負載均衡服務（SLB）來公網服務，提升系統的可用性，避免單點。
對於不需要公網訪問的雲服務器儘量不要分配公網IP。專有網絡中當您的雲服務器需要訪問公網的時候，優先建議您使用NAT網關，用於爲VPC內無公網IP的ECS實例提供訪問互聯網的代理服務，您只需要配置相應的SNAT規則即可爲具體的CIDR網段或者子網提供公網訪問能力。避免因爲只需要訪問公網的能力而在分配了公網IP(EIP)之後也向公網暴露了服務。
最小原則
安全組應該是白名單的性質的，所以需要儘量開放和暴露最少的端口同時儘量少的分配公網IP。如果想要訪問線上機器進行任務日誌或錯誤排查的時候直接分配公網IP或者掛載EIP雖然簡便，但是畢竟會將整個機器暴露在公網之上，更安全的策略是建議通過跳板機來管理。
使用跳板機
跳板機由於其自身的權限巨大，除了通過工具做好審計記錄。在專有網絡中，建議將跳板機分配在專有的虛擬交換機之中，對其提供相應的EIP或者NAT端口轉發表。
首先創建專有的安全組SG_BRIDGE，例如開放相應的端口例如 Linux TCP(22) 或者 Windows RDP(3389)。爲了限制安全組的入網規則，可以限制可以登錄的授權對象爲企業的公網出口範圍，減少被登陸和掃描的概率。
然後將作爲跳板機的雲服務器加入到這個安全組之中。爲了能讓這個機器能訪問相應的雲服務器，可以配置相應的組組授權，例如在SG_CURRENT 添加一條規則允許SG_BRIDGE 訪問某些端口和協議。
使用跳板機SSH的時候，建議您優先使用SSH 密鑰對而不是密碼登陸。
總結
合理的安全組規劃會使得您在擴容應用的時候更加的遊刃有餘，同時讓您的系統更加的安全。回顧下上文中總結到的實踐主要爲：
- 提供公網服務的雲服務器和內網雲服務器儘量屬於不同的安全組
- 不用的應用使用不同的安全組，尤其是不同的操作系統
- 生產環境和測試環境使用不同的安全組隔離
- 僅對需要從公網進行訪問的實例分配公網IP
- 使用跳板機約束和審計可訪問生產環境的權限