安全组是云服务器第一道逻辑防线，需按业务边界分组、白名单原则配置端口与源IP，禁止全网开放高危端口，多安全组叠加时注意优先级，且不替代应用层防护或暴力破解防御。
安全组不是“开了端口就能用”的开关，而是云服务器的第一道逻辑防线。配置得当，能大幅缩小攻击面；疏忽大意，哪怕只开放一个 22 端口且授权 0.0.0.0/0，就等于把钥匙挂在门口。
明确业务边界再动手
别急着点“添加规则”。先画一张简图：哪些服务要对外提供？谁访问它们？哪些组件只在内网通信？比如 Web 前端需开放 80/443 给公网，但后端 API 和数据库应完全屏蔽公网，仅允许来自前端所在安全组的内网请求。
- 公网服务和内网服务必须分属不同安全组，不能混在一个组里靠 IP 判断
- 生产、测试环境使用独立安全组，避免测试时临时放开的 3389 或调试端口误伤线上
- 不对外提供服务的 ECS（如 Redis、MySQL、内部任务队列）不要分配公网 IP，也不绑定任何允许公网入向的规则
按白名单原则写规则
安全组默认拒绝所有流量，这是它的设计前提。所谓“白名单”，就是只显式放行真正需要的组合：协议 + 端口 + 源（入向）或目标（出向）。
- SSH（22）或 RDP（3389）只授权办公网络段（如 192.168.10.0/24）或固定公网 IP，绝不用 0.0.0.0/0 长期暴露
- Web 服务（80/443）可对公网开放，但建议前置 WAF 或云防火墙做第一层过滤，安全组只作兜底
- 出方向规则也要管：企业级安全组默认拒绝所有出向，若需调用外部 API，必须单独添加允许规则；普通安全组虽默认全通，但仍建议限制——例如禁止实例主动连接已知恶意 IP 段
关联与生效的几个关键点
安全组不是配置完就自动起效的“全局策略”，它绑定到实例的主网卡上，且多安全组叠加时按优先级匹配（控制台中越靠前的组优先级越高）。
- 新建实例时勾选“快速配置”只能开基础端口，且无法指定源 IP，务必创建后立即进安全组详情页编辑规则
- 一个实例可绑定多个安全组，适合分层控制：比如“基础防护组”统一禁用危险端口，“业务组”按需放行服务端口
- 修改规则实时生效，无需重启 ECS；但若涉及网络连通性问题，需确认 VPC 内路由、NAT 网关、子网 ACL 等其他环节是否配合
常见误区与替代方案
很多人把安全组当成万能锁，其实它有明确作用边界。有些需求，换种方式更安全、更可持续。
- 远程管理不依赖公网 SSH：用阿里云 Workbench、跳板机或会话管理 CLI 的端口转发功能，让无公网 IP 的实例也能被安全访问
- 出网不靠实例直连：若只需访问公网（如 yum 更新、下载依赖），用 NAT 网关配 SNAT，避免给每台 ECS 分配 EIP
- 防暴力破解不能只靠安全组：它不识别登录失败次数，需配合系统层 fail2ban 或云平台的主机安全服务
- 安全组不代替应用层防护：SQL 注入、XSS 这类攻击需 WAF、代码加固或运行时防护，安全组只管“能不能连上”
