Day37-17｜18.5.3 访问控制框架：把“谁能做什么”落到可验证的架构机制

对应教材目录：第 18 章 安全架构设计理论与实践 → 18.5 网络安全体系架构设计 → 18.5.3 访问控制框架

学习目标：理解访问控制的基本问题、主体与客体、授权模型和策略执行链路；能够在案例分析中从身份认证继续推导到授权、会话、审计和动态策略；能够在论文中写出“需求—策略—机制—验证”的完整闭环。

一、为什么认证之后还必须做访问控制

认证解决的是“你是谁”，访问控制解决的是“你能对什么资源做什么操作”。两者不能混为一谈。用户通过登录验证，只说明系统已经以一定可信度确认了一个主体身份，并不意味着这个主体可以读取所有数据、调用所有接口或执行所有管理操作。

以企业报销系统为例，员工可以提交自己的报销单，部门负责人可以审批本部门单据，财务人员可以进行付款审核，系统管理员可以维护字典但不应直接修改付款金额。同一个人可能同时拥有多个身份：普通员工、项目负责人、部门负责人；同一个资源也有不同操作：查看、创建、修改、审批、导出、删除。访问控制就是把这些关系表达成可执行的策略。

可以用下面的逻辑描述授权结果：

访问请求 = 主体 Subject + 动作 Action + 客体 Object + 环境 Environment
授权决策 = Policy(主体属性、客体属性、动作、环境、风险、上下文)
执行结果 = Permit / Deny / Step-up / Obligation

其中，环境条件很重要。例如，财务人员在办公网内可以导出汇总数据，在公网环境下只能在线查看；夜间高风险操作需要再次进行多因素认证；某个账号虽然拥有“管理员”角色，但当账号处于冻结状态时仍然必须拒绝请求。

二、访问控制框架的基本构成

1. 主体、客体和操作

主体是发起访问请求的实体，可以是用户、用户组、应用程序、服务、设备或自动化任务。客体是受保护的资源，可以是文件、数据库表、数据行、API、消息主题、服务器、配置项或业务操作。操作描述主体准备执行的行为，例如读取、写入、删除、审批、发布、导出和调用。

访问控制设计至少要回答以下问题：

1. 谁发起了请求，身份是否已经认证？
2. 主体拥有何种角色、属性、组织关系和信任等级？
3. 请求访问哪个客体，客体的密级、所属组织和数据类型是什么？
4. 主体要做什么操作，这个操作是否具有高风险？
5. 当前时间、地点、设备、网络和会话状态是否满足条件？
6. 决策结果如何被可靠地执行和记录？

2. 策略管理、策略决策与策略执行

在架构题中，建议把访问控制拆成三个职责：策略管理点、策略决策点和策略执行点。

管理员/安全人员
       |
       v
策略管理点 PAP ---- 发布 ----> 策略库 / 规则中心
                                      |
请求 --> 策略执行点 PEP --> 策略决策点 PDP <---- 属性/身份信息
   |              |                  |
   |              +-- Permit/Deny --+
   +------ 审计日志、告警、限流、二次认证

策略管理点负责制定、审核、版本化和发布规则，不能让业务代码随意拼接权限条件。策略决策点根据请求上下文计算允许或拒绝结果。策略执行点位于网关、服务、数据库代理、消息系统或文件系统等位置，负责真正拦截请求并执行决定。

有时还会把属性信息单独抽象为属性信息点 PIP，把主体、客体和环境属性提供给决策点。例如用户所在部门、资源所属项目、设备是否受管、当前风险等级等，都可能由 PIP 查询。这样做的好处是策略与属性来源解耦，缺点是决策链路变长，需要考虑缓存、超时、一致性和故障降级。

三、几种典型访问控制模型

1. 自主访问控制 DAC

自主访问控制由资源拥有者决定谁可以访问资源。例如文件创建者可以把读取权限授予其他用户。它的优点是灵活、易理解，适合个人文件、协作空间和一般业务系统；缺点是权限容易被转授，难以保证统一的安全边界，权限关系复杂后容易形成“权限扩散”。

案例题中若出现“数据所有者可以授权其他用户”，通常可以判断具有 DAC 特征。但在强监管、强隔离场景中，不能只依靠 DAC，因为资源拥有者可能错误授权，也可能被恶意主体利用。

2. 强制访问控制 MAC

强制访问控制由系统统一设定安全级别和访问规则，主体和客体都带有安全标记。主体只能在策略允许的范围内访问客体，普通用户不能自行降低安全限制。典型思想包括机密级别、信息流向和安全域隔离。

MAC 适用于军工、政务、核心生产系统等需要严格控制信息流动的环境。设计时要注意安全标记的完整性、标签继承规则、跨域交换和管理员越权风险。单纯把“管理员”视为绝对可信并不严谨，管理员操作也应受到分权和审计约束。

3. 基于角色的访问控制 RBAC

RBAC 把用户与角色关联，把角色与权限关联。用户不直接绑定每项权限，而是通过角色获得权限。

用户 User --属于--> 角色 Role --拥有--> 权限 Permission --作用于--> 资源 Resource

RBAC 的优点是权限管理集中、符合组织职责、容易审计，特别适合企业管理系统。常见扩展包括角色层次、角色互斥、基数约束和会话角色激活。例如“部门负责人”继承“普通员工”权限，但“付款复核”和“付款执行”两个角色不能由同一账号同时激活，以实现职责分离。

RBAC 的问题是角色数量可能爆炸。若把项目、地区、客户、数据范围等所有条件都编码成角色，最终会形成大量临时角色。因此复杂场景通常要结合 ABAC 或数据权限模型。

4. 基于属性的访问控制 ABAC

ABAC 根据主体属性、客体属性、动作属性和环境属性进行决策。比如：

允许条件：
主体.department = 资源.department
且 主体.role in {Manager, Auditor}
且 action = read
且 environment.network = Office
且 risk < High

ABAC 表达能力强，适合多租户、跨组织、动态风险和细粒度数据访问。但属性来源较多，策略解释难度和运行时成本都更高。实施时必须建立属性目录、属性可信来源、缓存策略、策略版本和冲突处理规则。

5. 基于任务和规则的控制

基于任务的控制把业务流程状态纳入授权。例如订单进入“待审批”状态后，只有指定审批人可以执行审批；订单已经付款后，普通修改权限自动失效。基于规则的控制可以进一步加入金额、时间、地域、风险和设备条件。

高质量案例答案往往不是简单写“采用 RBAC”，而是说明“RBAC 管理粗粒度职责，ABAC 控制组织和环境属性，任务状态约束流程操作，数据库行级权限限制数据范围”。这才体现系统架构设计能力。

四、授权决策的关键设计问题

1. 默认拒绝还是默认允许

安全系统通常采用默认拒绝，即没有明确授权时拒绝访问。默认允许虽然开发方便，但一旦新接口、新资源或新角色未配置规则，就可能意外暴露权限。默认拒绝需要完善的权限配置、可观测性和异常处理，否则会影响业务体验。因此应建立“拒绝原因可解释、申请流程可追踪、紧急授权可回收”的配套机制。

2. 权限最小化与职责分离

最小权限原则要求主体只拥有完成任务所需的最小权限，并且权限应有作用范围和有效期。职责分离要求关键流程由不同角色完成，避免一个账号同时申请、审批和执行。

例如采购系统可以设计为：申请人创建采购申请，部门负责人审批预算，采购人员下单，财务人员付款，审计人员只读检查。即使某一账号泄露，攻击者也难以直接完成完整的资金链路。

3. 访问控制的粒度

粒度过粗，容易越权；粒度过细，策略复杂且性能成本高。常见粒度包括系统级、菜单级、接口级、功能级、字段级、行级和单元格级。架构设计时应根据数据敏感性和业务风险选择粒度。

粗粒度：是否可以进入订单模块
接口粒度：是否可以调用 /orders/{id}/approve
行级：只能查看本部门订单
字段级：可以查看订单，但不能查看客户身份证号
动作级：可以导出汇总，但不能导出明细

4. 权限变更与缓存一致性

权限通常会缓存于网关、应用节点和令牌中。若用户被禁用后，旧令牌仍然有效，就会产生安全窗口。常见做法包括短时访问令牌、令牌版本号、权限版本号、撤销列表、事件驱动失效和高风险操作实时回源。

缓存策略不能只写“使用 Redis 缓存权限”。还应说明缓存键、过期时间、更新事件、故障处理、权限撤销传播和一致性要求。例如普通查询允许几十秒延迟，但账号冻结、管理员降权和高危操作必须优先走实时校验。

五、访问控制的端到端执行流程

一个完整请求可以按以下步骤处理：

1. 客户端提交请求，携带令牌、设备标识和请求参数。
2. 网关验证令牌签名、有效期、受众和令牌版本。
3. PEP 提取主体、客体、动作和环境属性。
4. PDP 查询策略，并从 PIP 获取组织、资源、风险等属性。
5. 决策点返回允许、拒绝或需要增强认证。
6. PEP 执行结果，必要时进行字段脱敏、数据过滤、限流或二次确认。
7. 记录主体、资源、动作、结果、策略版本、原因和链路标识。
8. 对连续拒绝、异常地理位置、高频导出等行为触发风险分析。

访问控制不仅是一个 if 判断，而是一条可追踪的安全链路。审计日志最好采用结构化格式，至少包括：subject、tenant、resource、action、decision、policyVersion、sourceIp、deviceId、requestId、timestamp 和 reason。涉及个人信息时，应避免把完整敏感数据写入日志。

六、案例分析：多租户项目管理平台的访问控制设计

某项目管理平台服务多个企业租户，包含项目、任务、合同和成本数据。平台要求：租户之间完全隔离；企业管理员可管理本租户用户；项目经理只能管理所属项目；财务人员可查看成本但不能修改任务；合同金额超过阈值时需要二次审批；公网访问禁止批量导出。

可按四层设计：

第一层是认证。采用统一身份认证，令牌包含 userId、tenantId、roles 和 tokenVersion；高风险操作要求多因素认证。

第二层是粗粒度授权。网关或服务入口根据角色判断是否允许访问项目、合同和成本模块，并在服务端再次校验，避免只依赖前端菜单。

第三层是细粒度授权。通过 ABAC 判断 resource.tenantId == subject.tenantId；项目操作还需满足 subject.projectIds 包含 resource.projectId；财务角色只开放成本读取动作。

第四层是数据和审计。数据库查询自动追加租户和项目过滤条件，敏感字段返回脱敏值；所有导出、审批、权限变更记录审计日志，并通过风险规则检测异常行为。

架构风险及对策如下：

七、考试答题模板

遇到访问控制类案例题，可以按以下顺序组织答案：

1. 说明安全目标：身份可信、资源隔离、最小权限、职责分离、可审计。
2. 识别主体、客体、动作和环境属性，避免只写角色名称。
3. 采用 RBAC 管理组织职责，ABAC 或数据权限控制动态和细粒度范围。
4. 设计 PAP、PDP、PEP、PIP 及策略库，说明策略发布和版本管理。
5. 说明默认拒绝、最小权限、职责分离、双人复核和临时授权。
6. 说明令牌、会话、缓存、撤销、故障和降级策略。
7. 增加审计、告警、风险识别、脱敏、水印和数据导出控制。
8. 最后写验证方法：越权测试、租户隔离测试、权限撤销测试、策略回归测试和审计完整性测试。

八、课后练习

练习 1：概念辨析

某文件由创建者决定是否授权其他用户访问。该控制模型属于什么类型？它的主要风险是什么？

参考答案：属于 DAC。优点是灵活，风险是资源拥有者可能错误授权，权限可能被继续转授，系统难以形成统一安全边界。

练习 2：模型选择

某政务系统要求按照用户密级和文件密级控制信息流动，普通用户不能自行修改安全标签。应优先采用哪种模型？还应关注什么？

参考答案：优先采用 MAC，同时关注标签完整性、跨域交换、管理员分权、审计和策略冲突。

练习 3：架构设计

请为多租户 SaaS 设计访问控制机制，要求租户隔离、项目级权限、财务字段保护和管理员临时授权。

参考答案要点：认证令牌携带租户和主体信息；RBAC 管理管理员、项目经理、财务等职责；ABAC 校验租户、项目和环境属性；数据库查询强制租户过滤；字段脱敏；临时授权设置审批人、有效期和可撤销机制；所有高风险操作审计。

练习 4：论文训练

以“某企业统一访问控制平台的设计与实现”为题，写出摘要中的背景、问题、方案和效果四个要素。

参考结构：背景说明多系统权限不一致和越权风险；问题说明角色爆炸、权限撤销滞后和审计分散；方案写统一认证、RBAC+ABAC、PAP/PDP/PEP、缓存与撤销、审计告警；效果写租户隔离、权限变更时延、越权测试结果和运维效率提升。不要虚构没有依据的精确数据，可以使用“显著降低”“满足目标”等谨慎表述。

九、今日复盘清单

• 我能否用一句话区分认证和访问控制？
• 我能否说清主体、客体、动作、环境四类请求要素？
• 我是否理解 DAC、MAC、RBAC、ABAC 的适用场景和缺点？
• 我能否画出 PAP、PDP、PEP、PIP 的关系？
• 我是否考虑了默认拒绝、最小权限、职责分离和权限撤销？
• 我能否把访问控制写成案例题中的“需求—策略—机制—验证”闭环？

今天最重要的结论是：访问控制不是简单的角色判断，而是围绕主体、客体、动作和环境建立策略，并通过决策、执行、审计和验证形成完整安全架构。高级系统架构设计师答题时，要同时说明“授权依据是什么”“在哪里拦截”“如何撤销”“如何证明没有越权”。