安全组通过最小权限白名单和业务角色隔离实现内网横向移动防控，需禁用全网段放行规则、按服务职责划分安全组、区分生产/非生产环境，并叠加主机级防护弥补网络层盲区。

安全组本身不直接防御内网横向移动，但它在云环境中是实施网络分段和最小权限访问控制的关键执行层。真正起作用的，是把安全组当作“虚拟防火墙”来用——只允许业务必需的内网通信，其他一律拒绝。重点不在“加规则”，而在“砍规则”。

按业务角色划分安全组，不按操作系统或环境类型

把所有 Windows 服务器塞进一个“win-servers”安全组、所有 Linux 塞进“linux-servers”，这种做法会放大横向风险。正确做法是按服务职责隔离：

• 数据库实例单独一组，仅放行应用服务器安全组的指定端口（如 PostgreSQL 的 5432），禁止同组内互通
• API 网关与后端微服务分属不同安全组，网关组只出不入，微服务组只接受网关组入向请求
• 堡垒机/跳板机使用独立安全组，仅允许管理员办公网段+运维终端 IP 入向 SSH/RDP，且禁止该组内任何出向到生产数据库或域控网段

默认拒绝 + 白名单授权，禁用“全内网放行”规则

很多企业为图省事，在安全组里加一条“源地址：10.0.0.0/8，协议：全部，策略：允许”，这等于给攻击者发了内网通行证。必须杜绝：

• 删除所有源地址为整个 VPC 网段（如 172.16.0.0/16）的入向规则
• 每条允许规则都明确指定源安全组 ID（如 sg-abc123）或最小化 CIDR（如 10.10.5.0/28），而非 /24 或更大
• 对数据库、Redis、ZooKeeper 等中间件，禁止除管理节点外的任何其他安全组直连

区分生产/非生产，阻断测试流量渗入核心区域

开发、测试环境常因配置宽松成为横向跳板。安全组设计要物理或逻辑切断其通路：

• 测试 ECS 实例所在安全组，禁止任何出向到生产数据库、财务系统、域控所在安全组
• CI/CD 构建机安全组不允许访问生产配置中心（如 Nacos、Apollo）或密钥管理服务（KMS）
• 若需调试，通过临时端口转发（如 SSH Tunnel）或专属调试代理节点实现，不开放永久规则

配合主机级策略，弥补安全组无法覆盖的盲区

安全组工作在三层/四层，对 SMB、LLMNR、NetBIOS 广播、本地 IPC 调用等无效。必须叠加主机防护：

• Windows 主机禁用 LLMNR、NetBIOS、SMBv1，并关闭 IPC$、ADMIN$ 共享
• Linux 主机用 iptables/nftables 封堵同子网的高危端口（445、139、3389、5985）入向连接
• 所有服务账户使用专用域账号或 gMSA，禁用交互式登录和远程桌面权限