云联信息：安全组规则越加越多，该做一次梳理了
一、先导出现有规则清单
把所有安全组规则导出，按端口和来源排序。多数人会发现自己开过测试用的全端口放通，而且忘了删。看清现状，才知道该改哪些。
二、默认拒绝比默认放通安全
安全组的原则是只放通需要的，其余一律拒绝。默认全放通再逐条禁止，看起来省事，实际漏洞最多。
三、管理端口要限定来源
SSH的22端口、数据库的3306和6379，绝不能对全网开放。限定到办公网IP或者跳板机，是基本要求。数据库更应该只允许内网访问。
四、按业务分安全组
给应用、数据库、缓存分别建安全组，通过组间引用授权。这样新增机器只要加入对应的组，不用逐条加规则，也不会漏。
五、临时规则要设到期提醒
为了排查问题临时放通的规则，事后十有八九忘记收回。加一条备注写清原因和预计删除时间，每周清理一次。
六、用工具验证实际暴露面
从外网扫描自己的公网IP，看哪些端口真的对外开放。控制台的规则和实际暴露面可能不一致，以扫描结果为准。
七、变更要留记录
每次改安全组，记录时间、原因、操作人。出问题时能快速回溯是哪次变更引入的。多人协作的团队尤其需要。
八、定期复核形成节奏
每季度做一次全量复核，重点看管理端口、数据库端口和来源为全网的规则。养成节奏之后，安全组不会是隐患来源。
安全组和网络ACL要分清
安全组作用于实例，网络ACL作用于子网。两者叠加生效，规则都放通才能通。配置时先看安全组，再看子网ACL，否则会找不到原因。
出方向规则也别忽略
多数人只关心入方向，出方向默认全放通。如果业务被入侵，攻击者可以自由外联。对安全要求高的环境，出方向也应该限制。
规则顺序影响结果
安全组按规则匹配，先匹配到的生效。放通和拒绝混在一起时，顺序错了结果完全不同。修改后务必用实际连接验证，别只看规则列表。
批量管理用标签
实例多了之后逐个改安全组容易漏。用标签把机器分组，按组维护规则，新增机器打上标签就自动继承，效率和一致性都好。
把规则当代码管
安全组规则写成配置文件或者脚本，改动走审核流程，变更记录可追溯。手工在控制台点来点去，时间长了没人说得清每条规则为什么存在。
云联信息【资深云服务专家微信：cloud7591】一般会先梳理现有架构图，把公网入口、数据流向和依赖关系画清楚，再谈优化。规则变更之后，用一台无关机器尝试连接不该开放的端口，确认确实被拒绝再结束变更。