摘要:企业访问控制的核心问题不在模型命名,而在工程抽象:身份与权限未解耦、跨模型业务操作缺少“权限”的统一表达、上下文未前置到“权限”的配置导致无法动态感知。本文提出以操作(Operation)为一等公民的统一抽象:权限 = 资源 + 操作 + 条件(其中条件包括上下文模型,用以限制权限的生效范围),沿认证—授权—鉴权完整链路实现集中定义、动态评估、可审计落地,并结合 AI 风控与零信任给出可执行的设计蓝图与实践指南。

关键词:访问控制、授权、鉴权、上下文模型、统一抽象


🧭 背景与目标

  • 问题聚焦: 企业权限工程常见的混乱与高成本根源在抽象缺失。
  • 文章目标:
    • 定位三大原罪
    • 重构核心概念(权限/身份/授权/鉴权)
    • 提出统一抽象蓝图(权限 = 资源 + 操作 + 条件)
    • 给出规范、流程与落地步骤
    • 融合 AI 风控与零信任

🧩 核心概念重构

  • 身份(Identity): 主体的唯一标识(用户、服务、设备)。只回答“你是谁”。
  • 权限(Permission): 对资源执行操作的能力。权限 = 资源 + 操作 + 条件;其中条件包括上下文模型(时间、地点、设备、风险评分、网络环境等),用于限制权限的生效范围。
  • 授权(Authorization): 将权限配置到抽象主体(角色、属性、组、策略)。授的是权限,不是人。
  • 鉴权(Access Control): 请求发生时,依据当前上下文动态判定已授权的权限是否可执行。

⚠️ 三大原罪

1. 身份与权限未解耦

  • 表现: 角色强绑定权限、属性写进策略、策略直指具体主体。
  • 后果: 维护困难、审计不清、越权风险上升。
  • 修正: 权限独立存在;授权只面向抽象主体;策略去人化。

2. 跨模型操作缺乏抽象

  • 表现: 权限仅支持单资源单操作,无法表达复合业务动作依赖。
  • 示例: 修改用户性别需同时具备 "user.gender:edit""dict.gender:view"
  • 修正: 引入操作抽象层,通过依赖声明组合基础操作权限,授权直面业务操作权限。

3. 上下文未前置到权限的条件中

  • 表现: 上下文条件零散在鉴权逻辑里,导致静态授权与体验/风险两难。
  • 修正: 将上下文模型纳入权限的“条件”维度;鉴权时实时感知并匹配;与零信任架构一致。

🧠 权限的统一抽象蓝图:权限 = 资源 + 操作 + 条件

  • 权限是一等公民: 以操作为中心表达系统能力。
  • 操作即权限的核心部分: 业务操作天然承载权限语义。
  • 条件前置: 上下文模型作为条件纳入权限定义,用以限制权限生效的范围。
  • 授权面向抽象: 授权只绑定角色、属性或策略组。
  • 鉴权动态评估: 上下文实时采集,匹配已授权权限的条件。

🔄 全链路重塑:认证—授权—鉴权

认证:确认身份
身份抽象:角色/属性/组
授权:将权限配置到抽象主体
权限库:权限 = 资源 + 操作 + 条件
用户请求
上下文采集:时间/地点/设备/风险
鉴权引擎:匹配已授权的权限 + 条件
决策:允许 / 拒绝 / 追加条件(MFA)

🧩 操作抽象层落地:Operation = 权限的工程化表达

业务操作权限
权限定义
operation.modifyUserGender
基础操作权限:user.gender:edit
基础操作权限:dict.gender:view
条件:device=managed, time=09:00-18:00
  • 业务操作权限通过依赖声明组合多个基础操作权限,并附加上下文条件作为限制范围。
  • 授权面向业务操作权限,系统在鉴权时自动校验其依赖与条件。

📊 权限命名与条件字段规范

  • 命名规范:
    • 资源:<域>:<资源>(如 user:profile, dict:gender
    • 操作:<资源>.<动作>(如 profile.read, gender.edit
    • 业务操作:operation.<业务动作>(如 operation.modifyUserGender
  • 条件字段建议(上下文模型):
    • time(如 09:00-18:00
    • location(如 office, remote
    • device(如 managed, unmanaged
    • risk_score(如 <=20
    • network(如 vpn, public
    • mfa(布尔值)

⚙️ 策略与引擎:策略即代码,鉴权即计算

请求到达
身份令牌解析
加载授权:抽象主体的权限清单
上下文采集
权限与条件匹配
决策:允许 / 拒绝 / 追加挑战
审计记录写入
  • 权限定义与授权规则集中管理、版本化。
  • 鉴权引擎实时采集上下文并匹配权限条件,输出决策并记录审计。

🔍 实战用例

用例一:修改用户性别

  • 基础操作权限:user.gender:editdict.gender:view
  • 业务操作权限:operation.modifyUserGender
    • requires = [user.gender:edit, dict.gender:view]
    • conditions = {device=managed, time=09:00-18:00}
  • 授权: 授予角色 "HR专员"
  • 鉴权: 公司设备 + 工作时间 → 允许;否则拒绝或追加 MFA

🧭 总结与落点

  • 三大原罪:

    1. 身份与权限未解耦
    2. 跨模型操作缺乏抽象
    3. 上下文未前置到权限条件中
  • 统一抽象蓝图:

    • 权限 = 资源 + 操作 + 条件
    • 条件包括上下文模型字段,用于限制权限的生效范围
    • 操作抽象层为一等公民
    • 授权面向抽象主体
    • 鉴权动态匹配条件

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐