误解一：有单点登录就够
单点登录解决认证，授权仍要在每个应用里做。很多越权问题恰恰发生在登录之后：同一个账号能看到不该看的数据，而单点登录一点忙都帮不上。它甚至让越权看起来更「正规」，因为入口是统一的。
误解二：权限给宽点省事
宽权限短期减少申请，长期会累积成大量无人复核的授权。人员轮岗后权限只增不减，最终没人说得清谁能看什么，审计时既解释不了，也不知道该从哪里开始收，收权限比加权限要难得多得多，边界模糊时最易出事。
误解三：内网就安全
内网假设一旦被打破，攻击者可以横向移动，而内部系统往往认证更弱、日志更少。把边界全部押在网络位置上，等于把风险集中在一个假设上，而这个假设经常不成立，内部系统往往是最弱的一环。
误解四：有日志就可审计
日志要完整、可检索、有保留期、有人看。只采集不告警、不归档，出事时既查不到也证明不了，形式上合规、实质上没有作用，还会给管理层一种虚假的安全感，同时还要能证明日志没有被篡改过，这一点常被低估。
边界：控制挡不住有权限的人
访问控制能减少越权，但无法阻止合法权限下的恶意导出。需要配合数据防泄漏、行为基线与离职管理，把「有权限」和「被监督」分开处理。这两件事必须同时做，只做一件都会留下明显的缺口，补起来都不便宜。
适用与不适用
适合谁
- 对权限治理重视不足的管理层，需要案例
- 刚上线单点登录、以为问题解决了的团队
- 需要向审计解释现状的安全负责人
不适合谁
- 完全没有多用户体系的单机应用，无授权概念
- 希望靠一次整改永久解决权限问题的组织
典型场景
某公司在审计中被问到「谁能看客户手机号」，三个部门给出了三个答案。排查发现单点登录统一了入口，但各系统的角色是历史遗留，权限只增不减。整改从角色矩阵开始，先把答案统一到一张表上，再谈技术，技术改造排在后面。
可执行步骤
- 挑一个敏感字段，分别问三个部门谁能看，比对答案是否一致，不一致就是风险点。
- 检查单点登录之外，各应用的角色与数据权限是否仍在维护，形成书面结论。
- 统计近一年只增不减的权限条目，评估累积规模与分布，在例会上过一遍。
- 用受控测试验证内网横向访问的实际可达范围，限定测试时间，测试前知会运维。
- 检查日志是否具备告警、保留期与按人检索的能力，在系统里留操作记录。
常见坑
- 把单点登录当成权限治理的终点，应用内权限继续各自为政，越权的问题仍然照旧存在，风险从局部扩散。
- 权限只批不收，三年后没人说得清谁有什么权限，审计只能从头一点点梳理，业务方会逐渐失去信任。
- 以为内网就安全，内部系统的弱口令与共享账号长期存在，也长期没有人愿意整改，争议时各说各话。
- 日志采集了却没人看，异常登录半年后才被发现，追溯的窗口期早已过去，事后也补不回来，责任也难界定。
自检与验收清单
- 敏感字段的可见范围是否能给出唯一答案，可验证
- 单点登录之外的应用内角色与数据权限是否仍在维护
- 是否统计过只增不减的权限条目规模，有数据支撑
- 内网横向可达范围是否用受控测试验证过，在受控范围
- 日志是否具备告警、保留期与检索能力，可按人检索
常见问题
权限收紧了业务会抱怨吗？
会，尤其是习惯了宽权限的岗位。做法是先按角色给出标准权限包，让大多数申请一次到位，再对例外走审批。比逐个砍权限更容易被接受，也更容易长期维持，标准包要提前公示。
内网还需要零信任吗？
不一定全套上，但「默认不信任、每次验证」的思路值得借鉴。至少要对核心数据系统做独立认证与授权，不把网络位置当作信任依据，这一条成本并不高，核心系统尤其如此，要预留出时间。
日志留多久才够？
多久要看场景：财务与人事类通常需要覆盖考核周期，运维类可以短一些，具体以适用法规与合同为准。关键是保留期内可检索、可导出、能证明未被篡改，只留不查，留多久意义都不大。