在使用安全组的过程中，一个常见的错误是将所有的云服务器放置在一个安全组之中，这样虽然减少了初期配置的工作量，但是长期来看将会使得您的业务系统网络交互变得复杂和不可控，在执行安全组变更的时候没办法明确的知道添加和删除规则的影响范围。
合理的规划和区分不同安全组将使得您的系统更加便于调整，同时可以梳理应用的提供的服务和不同的应用进行分层。所以我们推荐您对不同的业务规划不同的安全组，设置不同的安全组规则。
例如对于是否提供公网访问和内网的应用使用不同的安全组，避免不小心疏忽暴露了不需要的服务到公网。同时要对测试环境和生产环境使用不同的安全组，这样讲使得发布和变更更加安全，避免测试环境的业务影响线上的稳定性。本文将着重介绍一些在应用中创建和使用安全组的一些规则。
区分不同的的安全组
提供公网服务的云服务器和内网服务器尽量属于不同的安全组
是否对外提供公网服务，包括主动暴漏某些端口对外访问，例如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网段或者子网提供公网访问能力，具体配置SNAT参见。避免因为只需要访问公网的能力而在分配了公网IP(EIP)之后也向公网暴露了服务。
最小原则
安全组应该是白名单的性质的，所以需要尽量开放和暴露最少的端口同时尽量少的分配公网IP。如果想要访问线上机器进行任务日志或错误排查的时候直接分配公网IP或者挂载EIP虽然简便，但是毕竟会将整个机器暴露在公网之上，更安全的策略是建议通过跳板机来管理。
使用跳板机
跳板机由于其自身的权限巨大，除了通过工具做好审计记录。在专有网络中，建议将跳板机分配在专有的虚拟交换机之中，对其提供相应的EIP或者NAT端口转发表。
首先创建专有的安全组SG_BRIDGE，例如开放相应的端口例如 Linux TCP(22) 或者 Windows RDP(3389)。为了限制安全组的入网规则，可以限制可以登录的授权对象为企业的公网出口范围，减少被登陆和扫描的概率。
然后将作为跳板机的云服务器加入到这个安全组之中。为了能让这个机器能访问相应的云服务器，可以配置相应的组组授权，例如在SG_CURRENT 添加一条规则允许SG_BRIDGE 访问某些端口和协议。
使用跳板机SSH的时候，建议您优先使用SSH 密钥对而不是密码登陆。
总结
合理的安全组规划会使得您在扩容应用的时候更加的游刃有余，同时让您的系统更加的安全。回顾下上文中总结到的实践主要为：
- 提供公网服务的云服务器和内网云服务器尽量属于不同的安全组
- 不用的应用使用不同的安全组，尤其是不同的操作系统
- 生产环境和测试环境使用不同的安全组隔离
- 仅对需要从公网进行访问的实例分配公网IP
- 使用跳板机约束和审计可访问生产环境的权限
本篇是安全组实践的第三篇，您可以通过查看下面的文章了解更多的安全组的细节。您可以留言提出关于安全组的问题，谢谢！