2. 访问控制策略：最小权限原则、职责分离、账户生命周期管理
好，咱们今天聊访问控制。说实话，这是安全里最基础、也最容易出问题的一块。我见过太多公司，防火墙买得挺贵，加密做得挺花哨，结果一个普通员工的账号能访问财务系统——你说这防线还有什么意义？
访问控制的核心，说白了就三件事：给谁开什么门、谁和谁不能一起进门、门什么时候该关。对应到专业术语，就是最小权限、职责分离、账户生命周期管理。咱们一个一个拆开讲。
2.1 最小权限原则
这个原则听起来简单——给用户刚刚好的权限，不多给一分。但实际落地的时候，我踩过的坑可不少。
核心思想：用户只拥有完成本职工作所必需的最小权限集合。注意，是「必需」，不是「方便」。
我个人的经验法则：
- 默认拒绝（Deny by default）——没明确说能做的，一律禁止
- 权限粒度要细——别动不动就给管理员角色
- 定期审查——权限会像杂草一样疯长
举个例子。我在一个项目中遇到过这样的情况：开发团队为了方便，给所有开发人员都配了生产数据库的读写权限。结果有一次，一个实习生误操作，把生产环境的一张核心表给清空了。嗯，那天晚上我们都在加班恢复数据。
怎么落地？ 我建议用角色-权限模型。别直接给用户赋权，而是先定义角色，再把角色分配给用户。
# 一个简单的角色权限设计示例
roles:
- name: "只读用户"
permissions:
- SELECT on table:orders
- SELECT on table:products
- name: "订单管理员"
permissions:
- SELECT, INSERT, UPDATE on table:orders
- SELECT on table:products
- name: "系统管理员"
permissions:
- ALL on all tables你看，这样设计之后，新员工入职只需要分配一个「只读用户」角色，而不是纠结于「他该不该有这张表的权限」。
避坑指南：我曾经见过一个团队，把权限粒度拆得太细，结果角色数量比用户还多。这其实走向了另一个极端。我的建议是：角色数量控制在用户数的10%以内，超过这个数，你就该考虑是不是设计得太复杂了。
2.2 职责分离
职责分离，说白了就是「不能既当运动员又当裁判员」。这个原则在金融、政务系统里尤其重要。
为什么需要这个？ 你想想看，如果一个人既能创建采购订单，又能审批付款，那他完全可以虚构一个供应商，把钱转给自己。这不是技术问题，是信任问题。
我参与过的一个审计项目里，就发现过这样的案例：一个财务主管同时拥有「创建发票」和「审批付款」的权限。虽然公司制度上不允许，但系统里没有做强制分离。结果这个人利用这个漏洞，在两年内挪用了公司300多万。系统没有报错，因为所有操作都是「合法」的。
常见的职责分离场景：
| 业务场景 | 不应由同一人执行的操作 |
|---|---|
| 采购流程 | 创建采购订单 vs 审批采购订单 |
| 财务流程 | 录入发票 vs 审批付款 |
| IT运维 | 提交变更申请 vs 审批变更 |
| 代码发布 | 编写代码 vs 合并到主分支 |
怎么实现？ 我建议用「互斥角色」机制。在系统里定义哪些角色不能同时分配给同一个人。
# 互斥角色定义示例
mutually_exclusive_roles:
- ["采购创建者", "采购审批者"]
- ["发票录入员", "付款审批员"]
- ["代码提交者", "代码审核者"]
# 当系统检测到用户同时拥有互斥角色时，自动阻止并告警注意：职责分离不是万能的。小团队里可能一个人要干三个人的活，这时候强行分离反而影响效率。我的建议是：先识别高风险操作组合，对这些组合强制分离；低风险的，可以用「双人复核」替代。
2.3 账户生命周期管理
这个我特别想多说两句。很多公司把精力都花在「怎么创建账户」上，却忽略了「怎么回收账户」。结果就是：离职员工的账号还活着，成了黑客最喜欢的目标。
账户生命周期分四个阶段：
- 注册：创建账户，分配初始权限
- 使用：日常登录、权限变更、密码重置
- 暂停：长期休假、调岗时的临时冻结
- 注销：离职或转岗后的彻底清理
我记得有一次做安全审计，发现一个系统里有300多个「僵尸账户」——这些账户的主人早就离职了，但账户还在活跃状态。更可怕的是，其中一个是前CTO的账号，拥有超级管理员权限。你想想，如果这个账号被攻破，整个公司的数据就全暴露了。
我建议的自动化流程：
# 账户生命周期自动化脚本（伪代码）
def handle_employee_offboarding(employee_id):
# 1. 立即禁用所有账户
disable_all_accounts(employee_id)
# 2. 转移所有权（邮件、文档等）
transfer_ownership(employee_id, manager_id)
# 3. 设置30天保留期
set_retention_period(employee_id, days=30)
# 4. 30天后彻底删除
if retention_expired(employee_id):
delete_all_accounts(employee_id)
log_audit("Account deleted: " + employee_id)关键指标：我建议每个季度检查一次「账户清理率」。目标值：离职后24小时内账户禁用率达到100%。如果做不到，说明你的流程有问题。
几个容易忽略的点：
- 服务账户：很多公司只管理人用的账户，忽略了程序用的服务账户。这些账户往往权限更大，更容易被遗忘。
- 共享账户：root、admin这种共享账户，最好禁用。如果实在要用，必须记录谁在什么时候用过。
- 紧急账户：保留一两个紧急备用账户，但平时要封存，使用时需要双人审批。
我的一个小习惯：每个月1号，我会让系统自动生成一份「账户健康报告」，列出所有超过90天未登录的账户、权限异常的账户、以及离职未清理的账户。然后发给各团队负责人，让他们确认。这个习惯帮我发现过不少问题。
好了，访问控制这块就聊到这儿。总结一下：最小权限让你少犯错，职责分离让你防内鬼，账户生命周期管理让你不留下烂摊子。这三样做好了，你的系统安全至少能提升一个档次。下一节咱们聊聊认证机制，那又是另一番天地了。