← 返回概念解读

Concept Fable精修版

基于属性的访问控制

Attribute-Based Access Control, ABAC · Security

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

会看天气和身份的仓门

王府库房不再只按官衔发钥匙,因为同一官衔来意各不相同。库官起初靠人、物、时辰和事由办事,熟人熟路,日子小的时候很少出错。库官发现,职位名称过于粗糙:同一个人能否开门,取决于他是谁、要看什么、何时来以及是否有当前差遣。

后来有人白天可查粮册,夜里却不该开银柜;有人能看东库,不能碰西库。固定职位钥匙无法表达临时任务、时间窗口和资源范围;条件一变,过宽的权限便会沿着共享钥匙扩散。

第一次修补很急:只给每个职位配一串固定钥匙,调一次差事就重打一串。按职位重配固定钥匙看似整齐,却无法表达临时任务、时间窗口和资源范围。可新毛病跟着出来,大家只盯最容易被看见的地方,远处的小偏差越积越深。

他们把主体、资源、动作、环境和事由写成属性,由策略在请求当下组合判断,并记录命中的规则与拒绝原因。

库官改看腰牌、差遣令、库房类别、时辰和陪同人,几项合上才开门。这一步麻烦,起初还拖慢了工期;可几轮之后,返工少了,师傅也不再凭脾气改规矩。开门决定终于随主体、资源、动作和环境变化,并且每次判断都留下了可审计的理由。

从此“能不能开门”不再是职位的永久待遇,而是对当前条件的精确判断;属性策略既减少过度授权,也保留审计线索。

一次管粮主事夜里想取银,官衔够高,事由和库别却对不上,被挡在门外。从那以后,权力不只看人名,还要看他在什么条件下要动哪样东西。

概念落点

这个故事讲的是:基于属性的访问控制

基于属性的访问控制(ABAC)不是只看一个人的角色,而是根据主体、资源、动作和环境等属性共同决定是否放行。主体可以是用户或 Agent,资源可以是客户数据或工具,动作可以是读取、导出、删除,环境可以是时间、设备、网络、租户和审批状态。

它比单纯按角色授权更细,因为真实风险常由上下文决定。同一个 Agent 白天读取本租户低敏数据可以放行,夜间导出跨租户高敏数据就应该被拒绝或转入审批。

故事对应

  • 仓门:Agent 调用工具或读取数据前的策略检查点
  • 腰牌颜色:传统角色权限
  • 人、货、动作、环境属性:ABAC 的 subject、resource、action、environment
  • 夜间外发清单:高风险 Agent 操作
  • 退回并说明条件:可解释的策略拒绝
  • 最后洞察:ABAC 适合企业 Agent 的动态权限,因为真实风险常由上下文决定

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

RBACpolicy engine

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。