服务器网站权限修改须系统性清点重置，以“谁该访问、凭什么访问、是否还在用”为核心，落实最小权限原则，分层建模授权对象，绑定业务/安全/合规依据，结合网络、主机、应用三层ACL收敛，并建立自动化验证与持续审计闭环机制。
这不是单纯删规则或加白名单的事，而是围绕“谁该访问、凭什么访问、是否还在用”做一次系统性清点与重置。核心是把权限从模糊经验式管理，转向可验证、可审计、可回收的标准化状态。
明确授权对象范围并分类建模
先厘清“所有访问授权对象”具体指哪些实体：不是泛泛而谈“用户”，而是分层归类——
- 人：运维管理员、开发人员、外包账号（含离职未注销账号）
- 系统/服务：监控平台、日志采集Agent、CI/CD流水线、备份服务等自动调用方
- 网络端点：办公网段、IDC出口IP、云厂商API网关地址、第三方合作方固定出口
每一类单独建表，标注来源（如AD同步、手动创建、API自动注册）、生命周期状态（在职/离岗/临时/长期）、最小必要权限等级（只读/读写/执行/sudo）。
统一权限判定依据与最小化原则落地
拒绝“因为以前能连，所以现在也能连”的惯性。每项授权必须绑定明确依据：
- 业务需求文档编号（如PRD-2026-045中明确“BI系统需直连MySQL从库查询报表”）
- 安全策略条款（如《服务器访问控制规范》第3.2条：“数据库仅允许应用服务器IP通过3306端口访问”）
- 合规基线要求（如等保2.0三级要求：“特权账号须双因子认证+会话审计”）
对现有授权逐条回溯依据，无明确支撑的一律暂停，进入“待复核池”；有依据但超出最小范围的（例如开发账号拥有root权限），降权至对应角色组或临时提权流程。
基于ACL与系统级策略分层实施清理
权限清理不能只靠Linux chmod或数据库GRANT，要结合网络层、主机层、应用层三道防线同步收敛：
- 网络层ACL：在防火墙或交换机上收紧入向规则，仅放通已确认的源IP/端口组合（如只允10.5.10.0/24网段的22端口SSH，禁用0.0.0.0/0）
- 主机层访问控制：禁用密码登录，强制密钥+证书；用PAM模块限制sudo命令范围（如仅允许/usr/bin/systemctl restart nginx）；启用文件系统ACL细化目录级权限（setfacl -m u:appuser:r-x /opt/app/conf）
- 应用/服务层白名单：数据库配置bind-address与host限制（MySQL的GRANT … FROM 'app'@'10.5.20.%'）；Redis启用requirepass+rename-command；API网关配置JWT校验与IP网段校验双重策略
建立自动化验证与持续审计机制
清理不是一次性动作，而是启动闭环管理：
- 每周自动扫描：比对当前活跃连接（netstat -tulnp）、登录历史（last）、sudo日志（/var/log/auth.log）与授权清单，标记偏差项
- 每月人工抽检：随机抽取10%授权对象，验证其权限是否仍被业务真实使用（联系负责人签字确认或提供近30天操作日志截图）
- 上线前强卡点：所有新服务部署必须提交《访问关系矩阵表》，经安全团队审批后才允许开通网络策略与账号权限
清理完成后，输出《服务器访问授权基线报告》，包含当前有效授权清单、失效账号列表、策略缺口说明及整改时间表，作为后续审计直接依据。
