"最小权限原则"这个词，我相信每个做信息安全的都听过。
但企业里最常见的情况是：制度写了"最小权限"，但一问怎么做到的——没人能说清楚。
权限最小化不是一句口号。它是27001 A.8.9明确要求的过程控制。这篇文章只聚焦一件事：在企业里，访问权限最小化到底怎么落地，每一步需要什么证据。
一、权限最小化真正要解决什么问题
先搞清楚：最小权限的本质不是"能不给就不给"，而是**"刚好够用、可复核、有证据"**。
我见过一家企业，他们的IT主管可以访问全公司的所有系统——因为他是"管IT的"。这不是个案。
权限最小化在企业落地时的核心矛盾是：
- 业务部门想："人来了，赶紧开权限，不然没法干活"
- 安全部门想："不能给太多，出事了追不到人"
两边都没错。最小权限要解决的是：建立一个"给权限有依据、回收有时限、变更可追溯"的流程。
二、账号生命周期管理——三阶段+必须留的字段
最小权限不是一个静态配置。账号从创建到回收，每个阶段都要有对应的控制。
阶段1：入职开通
业务部门发起申请 → 部门主管审批 → IT开通 → 安全复核。
这个阶段最容易犯的错：不给审批人就先开权限，说是"先赶上进度"。
关键字段（建议做成表单模板）：
| 字段 | 说明 | 必填 |
|---|---|---|
| 账号ID | 员工工号或邮箱前缀 | 是 |
| 申请人 | 业务部门负责人 | 是 |
| 岗位角色 | 对应标准的权限模板 | 是 |
| 所需系统 | 需要访问的系统列表 | 是 |
| 权限范围 | 读取/修改/管理/管理员 | 是 |
| 审批人 | 部门负责人+安全负责人（L3以上） | 是 |
| 预设到期日 | 临时权限必须设定 | 临时权限必填 |
| 开通确认时间 | IT开通后回填 | 是 |
阶段2：角色变更/调动
员工换了岗位 → 旧权限必须回收 → 新权限按新角色开通。
这是最容易出事的阶段。很多企业的数据泄露事件发生在员工调动时——人去了新部门，旧权限还在。
关键动作：
- 调动单必须走审批（HR触发）
- 旧部门确认权限回收
- 新部门重新走开通流程（不能"从旧部门平移"）
阶段3：离职回收
员工离职 → 当天必须回收所有权限。
常见做法：
- HR在离职流程中触发权限回收
- IT当天执行并在系统日志中记录回收时间
- 安全部门做确认验证
这里有一个很"技术"的细节：回收不只是"禁用账号"，还包括：
- 撤销所有系统访问
- 清除VPN/远程访问凭据
- 回收物理门禁卡
- 检查邮件自动转发规则（离职员工常设的隐形数据通道）
三、权限审批流设计——给多少、谁批准、怎么留证据
最小权限落到审批流上，需要解决三个问题：给多少、谁批准、怎么留证据。
给多少（权限粒度）
按岗位角色预设权限模板是最高效的做法。
| 角色 | 典型权限范围 | 说明 |
|---|---|---|
| 普通员工 | 本部门文件服务器（读）+ 内部系统（操作） | 默认最小权限 |
| 部门主管 | 同上 + 下属数据查看权 + 流程审批权 | 控制"能查看但不能删除" |
| 系统管理员 | 负责系统的全部管理权限 | 单独列管，双人复核 |
| 外部合作方 | 仅项目相关系统（受限环境/沙箱） | 必须有到期时间 |
| 实习生 | 只读权限 + 模板操作，无下载权 | 到期自动删除 |
谁批准（审批层级）
| 权限变更类型 | 审批流 | 说明 |
|---|---|---|
| 同部门内常规权限 | 部门负责人 → IT开通 | 标准流程 |
| L3/L4级数据访问 | 部门负责人 + 安全负责人 | 关键数据必须双人审批 |
| 管理员权限开通 | 部门负责人 + 安全负责人 + IT经理 | 三审制 |
| 跨部门访问 | 双方部门负责人 + 安全负责人 | 防止权限滥用 |
| 外部人员访问 | 项目负责人 + 安全负责人 | 必须有到期时间 |
怎么留证据
权限审批的每一步都要留记录。"我跟XX说过了"不是证据。
最低要求：
- 审批单必须走电子流程（邮件审批/OA/ITSM工单）
- 审批单必须包含：申请内容、审批意见、审批人签名（或邮件确认）
- 所有变更操作必须在系统中记录日志（谁+什么时候+做了什么+为什么）
四、系统层面怎么落地
制度和流程写了，接下来是对接到系统。没有系统对接的权限管理，就是一张没人看的Excel。
RBAC vs ABAC
| 模型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| RBAC（基于角色） | 200人以上企业，岗位角色明确 | 管理简单、标准化 | 角色多时管理复杂 |
| ABAC（基于属性） | 大型企业/云原生场景 | 细粒度高、动态授权 | 实施成本高、维护复杂 |
建议：大多数企业从RBAC起步，成熟后再扩展ABAC。
审计日志必须对齐
做了权限控制之后，如果审计日志不完整，出了事你依然无法追溯。
日志至少需要以下字段：
| 字段 | 用途 |
|---|---|
| 操作时间戳 | 精确到秒 |
| 操作人 | 账号ID或工号 |
| 操作类型 | 登录/访问/修改/删除/授权 |
| 目标资源 | 访问的具体系统/文件/数据 |
| 操作结果 | 成功/失败/拒绝 |
| 源IP | 从哪里发起操作 |
| 关联审批单号 | 审批记录的可追溯性 |
保留周期建议：
- 常规操作日志：≥6个月
- 权限变更日志：≥12个月
- 管理员操作日志：永久保留
常见工具路径
- 小型企业（50-100人）：AD域 + 文件服务器NTFS权限
- 中型企业（100-500人）：Azure AD/Okta + RBAC + ITSM审批集成
- 大型企业（500人以上）：IAM平台 + ABAC + 自动化审批流 + SIEM日志对接
五、权限复评机制
最小权限不是一次性配置完就结束了。它是持续运行的流程。
复评频率
| 复评类型 | 频率 | 范围 |
|---|---|---|
| 季度抽评 | 每季度一次 | 管理员账号 + 高特权账号 |
| 年度全量复评 | 每年至少一次 | 全量账号 |
| 触发式复评 | 事件驱动 | 部门重组/人员通报/系统变更 |
年度复评建议覆盖字段
| 字段 | 核验点 |
|---|---|
| 账号状态 | 是否仍在使用（最近30天是否有登录） |
| 当前权限 | 与岗位角色是否匹配 |
| 权限变更记录 | 过去一年是否有过变更、是否走审批 |
| 上次使用时间 | 疑似休眠账号（90天未登录→标记为待回收） |
| 是否需要保留 | 部门确认保留或回收 |
触发式复评的场景
不是所有复评都要等年度。以下场景发生后，必须触发权限复评：
- 安全事件：发生了数据泄露，第一件事是回查涉事人员的权限是否超范围
- 部门重组：合并/拆分部门，对应员工的权限必须重新评估
- 人员通报：员工被合规调查/通报，应立即冻结权限
- 系统迁移/下线：系统下线了，但授予的权限还在——这是最常见的安全盲区
六、与9001的简短对照
9001的7.2条款要求"确保人员具备胜任能力"。这个"胜任能力"不只包括技能，还包括**"谁有资格操作什么过程"**。
你把27001的访问权限最小化逻辑平移过去：
- 每个过程岗位定义权限范围（对应9001的7.2：能力要求）
- 权限变更走审批（对应9001的7.5：成文信息控制）
- 权限复评记录（对应9001的9.1：监视和测量）
控制≠限制，控制=可追溯。这个原则在9001和27001里是共通的。
七、小结
权限最小化这件事的本质是：
- 开通有依据：按岗位角色预设权限模板，走审批流程
- 变更可追溯：每一个权限变更都有记录、有审批
- 回收有时限：离职当天回收，调动立即更新
- 复评有制度：定期复评+事件触发复评
做到这四点，你的访问控制才能说"落地了"。
否则它会陷入大多数企业的困境：出了安全事件，查不到是"谁"在"什么时候"做了"什么"——因为权限管了，但管的全是流程，没留下证据。
周知ISO，专注于ISO 27001/9001/20000-1审核实务，持续分享企业ISO管理体系经验。
