这一类问题在说什么
访问控制粗放是测评里覆盖面很广的一类问题：防火墙存在 any-any 规则、数据库业务账号拥有全库权限、文件共享目录对所有人开放读写、运维账号 sudo 全权。它直接对应最小权限与按需授权的要求，整改的关键不是把策略收紧到极限，而是先梳理业务依赖，再按「默认拒绝、按需放行」重建规则。
整改方向
整改方向
# 分层收敛，别只改一层
网络层：按业务开通必要端口与地址，默认拒绝
主机层：按角色授权，清理 sudo 全权滥用
数据库：业务账号按库表授权，禁用高权账号直连业务
文件共享：按需授权并定期复核权限清单主机侧权限复核命令
主机侧权限复核命令
# 查看指定账号的 sudo 授权范围
sudo -l -U deploy
# 抽查全局可写目录（潜在越权风险）
find /srv /data -xdev -type d -perm -0002 2>/dev/null | head
# 查看共享目录 ACL 设置
getfacl -R /srv/share 2>/dev/null | head -40收敛顺序建议
- 先盘点：导出网络策略、数据库授权、共享目录权限，形成现状清单
- 再标注：区分必要、冗余、临时三类规则，临时规则要能说清来源与到期时间
- 影子策略观察：新策略先以日志模式运行一段时间，确认不影响业务
- 正式切换：分批次收紧，保留回滚方案
- 定期复核：规则与权限清单每季度核对一次，清理失效项
数据库侧经常被忽略：业务账号拥有全库读写、高权账号可用于应用连接，都属于典型的权限过宽，整改时要与开发团队一起梳理实际需要的对象与操作类型。
未梳理业务依赖就收紧策略，可能造成大面积业务中断；采用影子策略或分批实施能在保留安全收益的同时控制风险。
规则精简本身也是条款要求：策略条目多、注释少、长期无人梳理会被判定为配置不合理，定期复核并删除失效规则同样是整改内容。