安全组配置是等保2.0三级合规在云环境中的刚性执行，必须显性落实最小权限、默认拒绝、源地址限制和日志可审计要求，覆盖安全区域边界与安全计算环境控制域，严禁“全通内网”或依赖事后补救。
安全组配置不是简单放通端口，而是等保合规在云环境中的具体执行动作。它直接对应等保2.0“安全区域边界”和“安全计算环境”两大控制域，尤其在三级系统中，必须体现最小权限、默认拒绝、源地址限制、日志可审计等硬性要求。仅靠云平台默认安全组或“全通内网”策略，100%无法通过测评。
安全组必须覆盖的等保三级核心项
对照GB/T 22239-2019，以下控制点必须在安全组配置中显性落地，不能依赖上层防火墙或事后补救：
- 身份鉴别与访问控制联动：安全组本身不处理认证，但必须配合IAM策略——例如禁止root/ Administrator直连，SSH/RDP只允许跳板机IP段访问，且端口需绑定MFA启用状态（如阿里云RAM策略+安全组双重限制）
- 网络区域隔离刚性执行：生产、测试、管理三网段之间安全组规则必须为“显式拒绝”，不能留空；数据库组严禁开放3306/1433到任意地址，只允许可信应用服务器IP+端口白名单
- 高危端口默认关闭：Redis（6379）、MongoDB（27017）、Elasticsearch（9200）等非业务必需端口，在所有安全组中默认deny，确需开放须单独审批并记录到《云资源变更台账》
- 日志留存与行为可溯：云平台需开启VPC流日志，并将日志投递至独立日志服务（如SLS/CloudTrail），保留至少180天；安全组规则变更操作必须触发审计事件，且能关联到具体账号与时间戳
常见错误配置与合规替代方案
很多团队把安全组当成“云版iptables”，结果踩中高频落红项。以下是真实测评中被标记为“重大风险隐患”的典型场景及修正方式：
- 错误：Web服务器安全组对0.0.0.0/0开放80/443，同时又对0.0.0.0/0开放22 —— 测评结论直接判“不符合”
- 合规做法：80/443保持对外，22端口仅允许堡垒机IP段（如10.10.100.0/24）+ 源端口限定为2222（跳板机代理端口），并启用会话水印与操作录像
- 错误：数据库安全组设置为“来源=应用服务器安全组ID”，但该组包含测试环境实例 —— 违反“最小权限”与“生产隔离”原则
- 合规做法：为生产应用服务器单独创建标签化安全组（如sg-prod-app-web），数据库组只引用该ID；测试环境使用完全独立的安全组与子网
从配置到证据链：如何准备测评材料
等保测评不看截图，要看可验证、可回溯、可归责的证据链。安全组配置必须配套三类材料：
- 策略清单表：Excel格式，含安全组ID、名称、用途、每条规则的协议/端口/源IP/描述、责任人、生效日期、是否经审批（附OA链接）
- 变更记录：导出近6个月所有安全组修改的云平台操作日志（含operator、timestamp、before/after diff），按月归档为PDF并加盖电子章
- 审计验证脚本：提供Python脚本（如基于boto3/aliyun-python-sdk-ecs），可自动扫描全账号安全组，输出“是否存在全通规则”“是否存在高危端口暴露”“是否满足区域隔离”三类检查结果，测评时现场运行
安全组是云上最基础也最容易失守的一道防线。它不难配，但必须配得有依据、留痕迹、能闭环。把每一条规则都当作等保条款的映射点，而不是运维习惯的延续，整改才能一次到位。
