基于属性的访问控制（ABAC）：完整指南

基于属性的访问控制（ABAC）是什么？

ABAC 是一种访问控制范式，其中通过使用与以下内容相关联的属性来授予访问权限：

• 主体（用户或系统）
• 客体（文件、数据库或服务等资源）
• 操作（读取、写入、删除等）
• 环境（如时间、位置或设备类型等上下文数据）

访问决策是通过评估这些属性的策略规则来做出的。例如，医生只有在值班且患者属于其所在科室时，才能访问患者记录。

ABAC vs. RBAC 及其他模型

让我们将 ABAC 与其他访问控制模型（如基于角色的访问控制（RBAC）、强制访问控制（MAC）和自主访问控制（DAC））进行对比。

为什么在复杂、分布式且受监管的环境中 ABAC 至关重要

在复杂、分布式且受监管的环境中实施 ABAC 安全策略，可以基于诸如用户角色、位置、设备和时间等实时属性，实现细粒度、动态的访问控制。这种灵活性有助于在去中心化系统中实现可扩展性，确保遵循严格的监管要求（例如 HIPAA、GDPR、FISMA），并通过使访问决策具备情境感知能力而非静态固定，从而与 Zero Trust 原则保持一致。随着组织不断发展并采用云端与混合基础设施，ABAC 提供了传统模型（如 RBAC）难以匹敌的精确性与适应性。

谁在使用 ABAC？

ABAC 在安全性、合规性以及具备情境感知能力的访问至关重要的行业中得到了广泛应用。

• 医疗保健——保护电子病历并满足 HIPAA compliance
• 金融 – 根据风险、交易类型或监管需求来实施访问控制
• 国防/政府 – 用于对敏感与机密数据进行精细化访问控制
• SaaS 应用 – 支持大规模云应用中的多租户以及动态的用户访问控制
• 研究与学术 – 用于管理对敏感研究数据的访问

ABAC 的核心组件

ABAC 的核心组件用于评估访问请求，并确定是否应向用户授予或拒绝其对特定资源的访问权限。让我们逐一看看每个组件。

主体（用户）属性

主体属性是指请求访问的用户、系统或进程的描述性特征。这些属性有助于界定用户是谁、允许其做什么，以及在什么条件下允许。属性可能包括：

• 用户 ID / 用户名
• 角色或职位名称
• 部门 / 业务单元
• 安全许可等级（Security Clearance Level）— 例如：Confidential、Secret、Top Secret）
• 雇佣类型 – 例如：全职、合同工、实习生
• 认证方式 – 例如：使用 MFA、SSO、生物识别
• 用户位置 – 用户的 IP 地址或地理位置
• 设备类型或信任级别——例如：公司笔记本、未受管理的移动设备

对象（资源）属性

对象属性（也称为资源属性）用于描述主体希望访问的数据、系统或资源。这些属性有助于确定正在访问什么，以及在何种条件下允许或拒绝访问可能更为合适。属性可能包括：

• 资源类型——例如：文件、数据库记录、API 端点、应用程序
• 数据分级——例如：公开、机密、受限、绝密
• 所有者或创建者——创建或拥有该资源的个人或团队
• 部门关联——例如，与人力资源（HR）相关联的文档
• 文件元数据——例如创建日期、最后修改时间、文档标签
• 敏感度等级——与暴露相关的重 要性或风险程度
• 资源位置——资源存储在哪里，例如欧盟数据中心、云存储
• 保留策略或到期日期 — 适用于对时间敏感或受监管的数据

操作属性

操作属性定义了主体希望在资源上执行的操作类型。这些属性至关重要，因为访问决策往往不仅取决于 谁正在访问 什么，还取决于他们打算对其做什么。属性可能包括：

• 操作类型 — 例如：读取、写入、编辑、删除、批准、执行
• 请求方法 — 例如：GET、POST、PUT、DELETE（常用于 API 访问）
• 操作敏感度级别——某些操作可能更敏感，或需要更高权限，例如数据导出与仅查看之间的区别。
• 操作频率或规模——例如，速率限制、批量更新、大规模数据导出。
• 命令或函数名称——尤其是在应用程序或系统级访问控制中，例如关机或重新启动服务。

环境/情境属性

环境或情境属性是指围绕访问请求的动态条件。与主体或客体属性不同，这些属性并不与用户或资源本身绑定，而是与请求发生时的具体情形相关。它们为访问决策提供实时的态势感知能力。属性可能包括：

• 日期和时间——例如：仅在工作时间或特定日期允许访问
• 位置——基于 IP 地址、GPS 坐标或地理区域，例如国家、办公网络
• 设备类型或信任级别——例如：公司笔记本电脑与个人移动设备
• 网络安全态势——例如：安全 VPN、公用 Wi‑Fi、零信任区域
• 威胁情报或风险分数——例如：对当前会话或用户的风险评估
• 认证上下文——例如：SSO、MFA、生物特征验证
• 会话属性——例如：会话时长、失败的登录尝试次数

ABAC 架构解析

ABAC 架构旨在根据与主体、资源、操作以及环境条件相关联的属性来评估访问请求。它将决策逻辑与执行分离，从而实现可扩展、动态且由策略驱动的访问控制。

以下将讨论 ABAC 架构的关键组成部分。

PEP (Policy Enforcement Point)

PEP 作为用户与受保护资源之间的第一道交互接口，能够实时执行策略决策点（Policy Decision Point，PDP）所做出的访问控制决策。

PEP 的角色与职责

1. 拦截访问请求
   PEP 会捕获对资源的用户或系统访问请求，例如文档、API 或数据库。
2. 将请求转发给 PDP
   它会将请求连同上下文信息（主体、目标、操作以及环境属性）一起发送给策略决策点（Policy Decision Point，PDP）进行评估。
3. 执行 PDP 的决策
   一旦 PDP 返回访问决策（允许或拒绝），PEP 会通过允许或阻止对所请求资源的访问来执行该决策。
4. 可选的日志记录/审计
   PEP 还可以记录访问尝试和强制执行操作，以便进行审计和合规性跟踪。

包含 PEP 的示例工作流程

1. 用户尝试下载一份敏感报告。
2. PEP 会拦截该请求。
3. 它收集必要的属性（用户角色、 file classification、一天中的时间）。
4. PEP 将这些数据发送到 PDP 以进行策略评估。
5. PDP 会返回一个决策，例如： “Deny: access attempted outside business hours”。
6. PEP 执行“拒绝”决策并阻止下载。

PEP 在哪里实现？

• Web 服务器
• 应用网关
• 数据库查询引擎
• API 管理平台
• 云端 IAM 服务

PDP (Policy Decision Point)

PDP 是 ABAC 架构中的核心智能组件。它负责根据已定义的策略对访问请求进行评估，并确定应当授予还是拒绝访问。

PDP 的角色与职责

1. 评估访问请求
   PDP 从 PEP 接收访问请求（以及属性），并根据适用的策略对其进行评估。
2. 应用策略逻辑
   PDP 使用 Policy Administration Point (PAP) 定义的策略，根据以下内容评估请求：
3. 主体属性（例如：用户角色、许可级别/清理级别）
4. 客体属性（例如：资源敏感度）
5. 操作属性（例如：读取、写入）
6. 环境属性（例如：时间、位置）
7. 返回决策
   PDP 会发出如下决策：
8. 允许
9. 拒绝
10. 不适用（没有匹配的策略）
11. 无法判定（评估过程中出错）

带 PDP 的示例工作流

1. 用户尝试访问受限制的 HR 文档。
2. PEP 会收集所有相关属性，并将请求发送给 PDP。
3. PDP 会检查诸如以下之类的策略：“仅当用户属于人力资源部门且在工作时间使用公司设备时，才允许访问 HR 记录”。
4. 如果所有条件都满足，PDP 会返回“Permit（允许）”的决定。
5. 随后，PEP 允许访问该资源。

PDP 在哪里实现？

• 访问控制引擎
• IAM 平台
• 基于 XACML 的策略服务器
• 云访问管理工具
• 企业安全网关

PIP (Policy Information Point)

PIP 是 ABAC 架构中的数据检索引擎。它负责向策略决策点（Policy Decision Point，PDP）提供评估访问请求所需的属性值。

PIP 的角色与职责

1. 提供属性数据
   PIP 充当 PDP 与外部数据源之间的桥梁，传递访问决策所需的主体、客体、操作以及环境属性。
2. 从多个来源获取数据
   PIP 会从各种存储库中拉取实时属性数据，包括：
3. 身份与访问管理 (IAM) 系统
4. 人力资源数据库，例如部门、雇佣状态
5. 资源元数据服务
6. 网络与设备监控工具
7. 时间、地理位置或环境传感器
8. 确保数据的准确性和一致性
   PDP依赖PIP来提供最新且可靠的信息，以便做出正确并符合要求的决策。

使用 PIP 的示例工作流程

1. 主体/用户尝试访问一条财务记录。
2. PEP将请求发送给PDP进行评估。
3. PDP 需要诸如主体/用户的部门与角色、请求时间以及设备类型等属性。PIP 会从以下位置获取这些信息：
4. 人力资源（HR）数据库
5. 文件元数据存储库
6. 系统时钟
7. 终端管理工具
8. PDP 使用属性来评估策略，并返回决策结果。

与 PIP 集成的常见属性来源

• LDAP / Active Directory – 用于用户角色、组、组织单位
• 云目录（例如 Microsoft Entra ID、Okta）– 用于身份和设备信息
• 元数据仓库 – 用于文件/资源分类
• SIEM 或 CASB ——用于提供环境上下文或风险指标
• 自定义 API / 数据库 ——用于动态或特定领域的属性

PAP（Policy Administration Point）

PAP 是 ABAC 中用于集中管理策略的核心组件。它负责创建、管理和存储访问控制策略，用于定义何时允许或拒绝访问的条件。

注释：策略定义在何种条件下，谁可以做什么。

PAP 的角色与职责

1. 定义访问策略
   PAP 为管理员提供工具或界面，用于使用结构化逻辑编写和管理策略（通常使用 XACML 等策略语言）。
2. 管理策略生命周期
   当业务需求或合规要求发生变化时，包括创建、编辑、发布以及停用策略。
3. 存储并组织策略
   充当中央存储库：在其中安全地维护策略，并使其能够供策略决策点（Policy Decision Point，PDP）访问。
4. 确保策略一致性
   有助于确保策略内容连贯、互不冲突，并与组织治理以及监管框架保持一致。

由 PAP 管理的策略示例

规则：“仅当用户来自人力资源部门、请求发生在工作时间内，并且设备是由企业管理的笔记本电脑时，才允许访问人力资源文档。”

该策略在 PAP 中编写和维护；当提出请求时，由 PDP 检索并进行评估。

PAP 使用的工具和格式

• 策略语言：
• XACML（eXtensible Access Control Markup Language）
• 基于 JSON/XML 的策略格式
• 管理界面：
• 图形化策略构建器
• 命令行工具
• 策略版本管理与审计控制
• 与治理工具的集成：
• 角色与权限审查
• 合规仪表盘

与其他 ABAC 组件的关系

• PDP – 向 PAP 发起查询，以检索用于评估的相关策略。
• PEP – 间接依赖于 PAP，因为执行是基于从 PAP 定义的策略中得出的决策。
• PIP – 提供 PAP 定义的策略条件所需的属性数据。

ABAC 策略编写：工作原理

ABAC 模型是一种可靠的策略，用于根据属性来管理对资源的访问，而不仅仅依赖角色或身份本身。下面概述如何制定有效的 ABAC 策略。

布尔逻辑 + “if/then” 条件)

使用布尔表达式和逻辑运算符来定义 ABAC 规则：

• AND — 所有条件都必须为真
• OR — 至少一个条件必须为真
• NOT – 否定一个条件
• IF/THEN – 如果满足条件，则表示策略结果

用自然语言编写易读的规则：

• 构建布尔表达式，明确在什么条件下允许访问。
• 使用 if-then 逻辑：“如果 [条件] 为真，则允许访问。”

自然语言示例策略

策略 1：基于部门的访问

• 如果用户的部门是“HR”，且操作是“read”，则允许访问员工档案。
• 如果 user.department = ‘HR’ 且 resource.type = ‘payroll’ 且 action = ‘read’，则允许。
• 如果用户的部门是“Finance”，且资源分类是“Confidential”，则允许访问以“read”该资源。

策略 2：受时间限制的访问

• 如果用户是“Contractor”，且访问请求在上午 9 点到下午 5 点之间提出，则允许访问文件服务器。

策略 3：许可等级

• 如果用户的许可等级等于或高于文档的分类等级，则允许访问。

ALFA/XACML 示例片段

ALFA（用于授权的简写语言）

      policyset "DocumentAccess" {

  apply "permit-overrides"

  target clause resource.type == "document"

  policy "ConfidentialDocs" {

    apply "deny-overrides"

    rule "AllowFinanceRead" {

      target clause subject.department == "Finance"

                    and action.id == "read"

                    and resource.classification == "Confidential"

      permit

    }

    rule "DenyAllOthers" {

      deny

    }

  }

}
      

XACML 代码片段

      <Policy PolicyId="ConfidentialDocsPolicy" RuleCombiningAlgId="deny-overrides">

  <Target>

    <Subjects>

      <Subject>

        <AttributeValue DataType="string">Finance</AttributeValue>

        <AttributeDesignator AttributeId="subject:department" Category="subject" DataType="string"/>

      </Subject>

    </Subjects>

    <Resources>

      <Resource>

        <AttributeValue DataType="string">Confidential</AttributeValue>

        <AttributeDesignator AttributeId="resource:classification" Category="resource" DataType="string"/>

      </Resource>

    </Resources>

    <Actions>

      <Action>

        <AttributeValue DataType="string">read</AttributeValue>

        <AttributeDesignator AttributeId="action:id" Category="action" DataType="string"/>

      </Action>

    </Actions>

  </Target>

  <Rule RuleId="AllowFinanceRead" Effect="Permit"/>

</Policy>

      

JSON（JavaScript 对象表示法）

      {

  "policyId": "readPayrollPolicy",

  "effect": "permit",

  "rules": [

    {

      "subject": { "department": "HR" },

      "resource": { "type": "payroll" },

      "action": { "value": "read" }

    }

  ]

}
      

ABAC 实施框架

以下是对 ABAC 实施框架的全面说明，涵盖完整生命周期——从规划到部署，再到优化。

发现与规划：定义用例和所需属性

目标：建立对需要保护的内容、需要访问的人员以及适用条件的清晰认识。

成果：明确谁在何种条件下应访问哪些内容的完整矩阵。

属性建模与治理

目标：定义、获取并管理高质量的属性数据。换句话说，设计并管理支撑 ABAC 决策的属性基础设施。

结果：一个管理良好、可扩展的属性存储库，支持准确的策略评估。

策略建模与工具

目标：构建并管理访问策略。

结果：与业务意图一致的结构化、易维护的策略定义。

测试与仿真

目标：在实施之前验证策略行为，并防止配置错误。

结果：在上线部署之前，对策略逻辑及行为具备高度信心。

部署与实施

目标：将策略与实时系统集成，并落实执行决策。

结果：基于已评估属性的实时、动态访问控制。

监控、审计和优化

目标：改进策略、证明合规并降低风险。

结果：自适应、可问责且经过优化的 ABAC 系统。

汇总框架表

属性治理与生命周期

属性治理（Attribute governance）是指用于在其整个生命周期（从创建到删除）中管理身份与资源属性的政策和流程。在 ABAC 中，属性决定谁能够访问什么，因此治理不善可能导致严重的安全与运营风险。有效的属性治理需要：

• 明确的责任归属与文档记录
• 定期验证
• 可靠的来源与基础设施
• 与身份生命周期管理的深度集成

属性来源（HRIS、IdPs、CRM、AD/LDAP）

属性可能来自多种系统，而每个系统都必须值得信赖。

如果不同来源之间的格式不一致或信息过期，可能会导致相互矛盾或不正确的访问决策。

元数据卫生与版本管理

元数据卫生可确保属性定义、数据类型、允许的取值和上下文清晰、文档完善且实现标准化。

最佳实践：

• 维护用于属性定义的数据字典。
• 在不同系统中对数值进行标准化，例如“Manager”与“Mgr”。
• 维护带版本管理的属性架构，以跟踪随时间变化的内容，并确保向后兼容性。

不良的卫生习惯可能导致政策评估引擎误解或运行失败。

属性的信任与完整性

信任是指对某个属性来源的可信程度。完整性则是确保属性在传输或存储过程中不会被更改。为确保信任与完整性，请确保以下事项：

• 使用带签名的令牌，例如 SAML assertions、JWTs。
• 在属性提供方和使用方之间实现双向 TLS（mutual TLS）。
• 应用“单一事实来源”（source-of-truth）原则——每个属性都应只有一个权威来源。

较弱的信任模型可能导致 权限提升 攻击。

属性过期与撤销策略

属性必须反映当前的真实情况。过期的属性可能在变更之后仍然保留（例如角色变更或离职）。为了解决这个问题，请考虑：

• 撤销——当发生变更（例如员工离职/下线）时，会立即触发失效。
• 过期——强制重新验证，例如每周重新检查一次就业/雇佣状态。

为临时属性实现 TTL（生存时间），并为关键更新设置实时钩子（hook）。

ABAC 中不良属性设计的陷阱

不良的属性设计可能以多种方式破坏访问控制：

• 权限过大（Over-privilege）——基于过时或过于宽泛的属性授予访问权限。
• 拒绝访问（Access Denial）——由于属性不一致或缺失而导致错误地拒绝访问。
• 审计失败（Audit Failures）— 由于属性含糊不清或缺少文档，难以追踪用户为何拥有或缺少访问权限。
• 策略复杂性（Policy Complexity）— 过度使用细粒度或冗余的属性，可能导致规则难以管理。

示例：如果将“Department”用作访问条件，但某些系统将其标为“HR”，而另一些系统则标为“Human Resources”，那么检查“HR”的策略可能会对部分用户失效，从而导致访问不一致。

面向云端与多云环境的 ABAC

ABAC 在现代云环境中为访问控制提供了强大的灵活性，但要求严格、有纪律的落地实施。通过利用身份标签（identity tags）、会话标记（session tagging）以及动态属性，同时保持安全性和一致性，你可以在云端与 SaaS 生态系统中执行稳健且具备上下文感知能力的策略。

使用 Identity Tags 和基于属性的策略实现 ABAC

在云环境和多云环境中，ABAC 可在运行时评估 identity tags 和属性，从而实现细粒度的访问控制。

Identity Tags

标签是分配给用户、角色、资源和会话的元数据标签。例如，在 AWS 中，identity tags 可以附加到 IAM 用户或已假定的角色，并用于策略条件。

示例：Department=Finance，Project=Alpha，Clearance=High

基于属性的策略

在这种情况下，通过将策略的条件与提供的属性进行匹配评估来做出访问决策。AWS IAM、Azure RBAC 和 GCP IAM 等云原生服务可通过条件和标签支持 ABAC。

示例策略（AWS）：

      {

  "Condition": {

    "StringEquals": {

      "aws:PrincipalTag/Department": "Finance"

    }

  }

}
      

作为最佳实践，请保持属性的权威性，并在各云之间进行同步，以避免策略漂移。

在 SaaS 和云原生应用中使用 Session Tagging 和 Dynamic Attributes

Session tagging 和 dynamic attributes 可实现实时、具备上下文感知的访问决策。

Session Tagging

在创建会话时会传递标签，例如在 AWS 中进行角色假设。这样就可以把与用户或请求相关的特定数据注入到临时会话中，这对 MFA 状态、地理位置或设备姿态等临时上下文非常有用。

Dynamic Attributes

这些属性在运行时通过身份提供方、策略决策点（PDP）或元数据 API 等外部来源推导得出。此类属性的示例包括：

• 一天中的时间
• IP 地理位置
• 资源使用阈值

这些属性会在 SaaS 平台中用于诸如“仅允许在办公时间内、从公司设备进行访问”的策略。它们使策略能够适应实时上下文，而不是依赖静态角色。

分布式策略执行与跨平台一致性的安全注意事项

云端与多云环境中的 ABAC 会带来分布式和互操作性挑战。若 ABAC 实施缺乏统一，可能导致访问不一致、配置错误以及安全漏洞。以下是一些关键的安全措施。

跨平台的一致性

问题：不同平台可能以不同方式定义或标记相同的属性（dept=Finance 与 department=FIN）。

解决方案：

• 必须对属性名称和格式进行标准化。
• 应采用集中治理模型来管理 AWS、Microsoft Entra、GCP 以及 SaaS 提供商之间的属性。
• 对属性变更实施版本管理和文档记录。

跨平台的策略同步

问题：策略可能由不同服务强制执行，例如 AWS IAM 和 Microsoft Entra ID，从而导致策略不匹配。

解决方案：

• 使用联合身份（federated identity）和集中式 PDP（如 OPA/Gatekeeper 或 Axiomatics），以维持一致的逻辑。
• 结合 CI/CD 管道采用“策略即代码（policy-as-code）”，以一致地部署和审计策略。
• 保持跨平台的策略等效性测试，以确保意图与结果一致。

信任与完整性

问题：如果某个平台的属性源受到破坏或配置错误，可能会在各系统之间授予非预期的访问权限。

解决方案：

• 确保用于策略的属性已签名、加密，或以其他方式受到防篡改保护。
• 为每个属性指定权威来源（source of truth），并进行文档记录。
• 在策略执行点（PEP）实施属性校验机制。
• 审计日志必须跟踪用于每次访问决策的属性值，以确保问责。

实时属性评估与会话新鲜度

问题：在用户会话期间，属性可能会发生变化（例如部门重新分配、合同终止），但策略可能无法实时反映更新。

解决方案：

• 为敏感访问设置属性 TTL（Time to Live），或强制执行较短的会话持续时间。
• 使用“即时（JIT）”访问评估和持续身份验证机制。
• 在高风险操作期间重新验证关键属性。

延迟与可扩展性

问题：在高流量的云环境中，延迟可能会成为问题。

解决方案：

• 应针对高流量云环境优化动态属性评估和策略决策的性能。

日志记录、审计与可追溯性

问题：如果缺乏清晰的可视性，就很难理解为什么允许或拒绝了访问。

解决方案：

• 记录所有访问决策，包括所使用的精确属性以及已评估的条件。
• 使用分布式日志聚合（例如 Splunk、ELK、AWS CloudTrail、Azure Monitor）。
• 实施基于属性级别的审计，以检测异常或可疑的变更。

行业特定的 ABAC 用例

ABAC 提供灵活且精细的安全解决方案，可针对不同行业的独特需求进行定制，使组织能够基于属性实施精确的访问策略。

医疗健康：HIPAA、EHR 访问控制

HIPAA（健康保险可携带性与责任法案）合规

HIPAA 要求严格保护受保护的健康信息（Protected Health Information，PHI）。ABAC 提供一种灵活且细粒度的方式来执行这些规定。

使用场景：

EHR（电子健康记录）访问控制

ABAC 支持对 EHR 的细粒度控制，在复杂的医疗环境中同时提升安全性与可用性。

使用场景：

金融：PCI DSS、细粒度的交易权限

PCI DSS（支付卡行业数据安全标准）合规

PCI DSS 概述了为存储、处理或传输持卡人数据的组织制定的安全要求。ABAC 使这些组织能够实施与 PCI DSS 规定一致的细粒度访问控制。

使用场景：

细粒度的交易权限

ABAC 提供强大的机制，用于在金融交易中实施具备上下文感知的精细化控制，从而防止欺诈并确保符合内部控制政策。

使用场景：

政府与国防：基于许可/清查级别的控制

基于许可/清查级别的访问控制

政府和国防组织管理高度敏感的信息，这些信息需要根据安全许可、分级以及知情须遵循（need-to-know）原则实施严格的访问控制。ABAC 使这些机构能够动态执行比传统基于角色的访问控制系统更细致、更具弹性的访问策略。

使用案例：

任务关键型系统控制

除了文档访问之外，ABAC 对于保障国防环境中的运行与后勤系统安全至关重要。

使用案例：

教育：学生档案与研究数据访问

学生档案访问

教育机构会管理敏感的学生信息，包括学业记录、助学金数据、纪律处分以及健康细节。ABAC 使机构能够基于用户角色、职责和情境因素应用更细粒度的访问策略，并与 FERPA（Family Educational Rights and Privacy Act，家庭教育权利与隐私法）等法规保持一致。

使用案例：

研究数据访问

高校的研究活动往往涉及敏感、专有或受监管的数据，包括医学研究、政府资助项目或知识产权。ABAC 有助于确保数据使用安全且符合要求。

使用场景：

ABAC 的优势

组织可以利用 ABAC 的能力来提升安全性并简化访问控制。该模型提供的诸多好处如下。

细粒度的、基于上下文的访问控制

ABAC 通过评估用户属性、资源属性、操作属性和环境属性，实现高度细粒度且动态的访问决策。主要优势包括：

• 多属性逻辑——访问决策可以依赖用户角色、部门、许可等级、位置、时间等更多因素。
• 自适应访问控制——策略可以评估运行时上下文，例如访问位置、设备安全态势或威胁等级。
• 数据级权限——ABAC 可以在行、列，甚至字段级别控制访问，这对于医疗、金融或教育等场景非常理想。

提升安全性与隐私

ABAC 通过实施超越静态角色的策略来增强安全性，减少过度授权的情况，并缓解 insider threat。主要优势包括：

• 最小特权原则 – 用户仅在需要的持续时间和情境下获得所需访问权限。
• 减少攻击面——经过精细调优的策略能够降低对未授权访问或数据外传的暴露。
• 内置隐私机制——ABAC 支持以用户为中心的隐私功能，例如基于同意的访问或对敏感字段进行遮蔽。

更轻松的用户入职与离职管理

ABAC 将访问逻辑与个人身份和角色分离，从而简化用户的生命周期管理。主要优势包括：

• 无需手动分配权限——访问权限会根据用户属性（例如职位、部门）自动确定。
• 简化的配置（Provisioning）——新用户在以已定义的属性进入系统后，即刻获得适当的访问权限。
• 安全的撤销配置（Deprovisioning）——当属性发生变化时（例如岗位调动、离职），访问权限会自动撤销或调整，从而降低人为错误和滞后时间。

跨系统的策略复用

ABAC 策略可以设计为模块化、可重复使用，并能在多种平台和系统之间实现互操作性。主要优势包括：

• 集中式策略管理 – 策略只需定义一次，即可在 HR、财务、CRM、ERP 和云平台等环境中实现一致的强制执行。
• 可扩展性 – 随着组织发展或采用新应用，ABAC 可扩展，而无需从头重新定义访问规则。
• 与外部系统的互操作性 – ABAC 框架（例如 XACML、Open Policy Agent）支持与异构环境的集成。

更好的监管合规

ABAC 通过提供透明、可审计且可强制执行的控制手段，简化了对数据保护和行业法规的合规要求。主要优势包括：

• 合规的访问控制——通过强制执行基于属性的策略，支持 HIPAA、FERPA、PCI DSS、GDPR 和 NIST 等法规的要求。
• 审计就绪——对访问决策进行详细记录——包括谁在何时、出于何种原因以及在什么条件下访问了什么——从而便于开展合规报告和调查。
• 对保留、同意与披露策略的动态强制执行——确保敏感数据按照法律和合同要求进行访问、保留和共享。

常见的陷阱/限制及如何避免

尽管 ABAC 提供了细粒度且灵活的访问控制，但其效果可能会受到一些常见陷阱的阻碍。理解这些限制并主动加以应对，对于构建健壮且高效的 ABAC 实施方案至关重要。

策略冲突与复杂性

由于属性、条件以及逻辑组合的数量，ABAC 策略可能会迅速变得复杂。这可能导致策略冲突、意外的访问授权或拒绝，以及难以理解策略行为。

如何避免：

• 使用策略抽象层——实现策略模板或高层策略构造，以简化编写。
• 策略测试与验证——使用能够模拟访问场景的工具，以识别并解决冲突。
• 模块化策略——将策略拆分为可管理的模块，以降低认知负担，并让调试更轻松。
• 策略文档——维护清晰的文档，以便追踪关联关系和逻辑。

因过度使用属性而产生的性能瓶颈

ABAC 的评估可能需要从多个来源查询多个属性。对属性（尤其是来自动态或远程系统的属性）的过度依赖，可能会引入延迟并降低性能。

如何避免：

• 优化属性检索——缓存经常访问的属性，并预先获取那些不常变化的属性。
• 优先处理关键属性——关注那些会显著影响访问决策的属性。
• 限制对外部资源的实时依赖——在可能的情况下，减少对外部身份或属性提供方的运行时调用。
• 使用索引或快速查找机制——尤其是在属性存储在数据库或目录中时。

过时或不受信任的属性

过期或未验证的属性（例如旧的职位名称或停用的部门）可能导致错误的访问决策，从而增加安全风险。

如何避免：

• 自动化属性更新——使用来自权威来源的实时同步或定时更新。
• 验证属性来源——确保所有属性都来自具有严格更新策略的可信系统。
• 属性过期——实施属性 TTL（Time To Live）或有效期，以强制重新评估。

缺少审计跟踪和日志

没有详细的日志记录，就很难追踪访问决策、调查事件或证明合规性。

如何避免：

• 全面的日志记录——记录谁在何时、为何访问了什么（包括评估了哪些属性和策略）。
• 标准化的日志格式——使用结构化日志（例如 JSON），以便更轻松地解析并与 SIEM 工具集成。
• 定期审查日志——建立对访问日志的定期审查流程，以检测异常或滥用行为。

属性治理不足与元数据蔓延

组织可能会遇到“属性蔓延（attribute sprawl）”，即定义了过多属性，但命名、类型或语义不一致，导致错误和低效。

如何避免：

• 集中式属性目录 — 维护一个集中式注册表，其中包含标准定义、格式和允许值。
• 属性生命周期管理 — 定义创建、更新和停用属性的流程。
• 治理策略 — 为每个属性指定负责人，并强制执行数据质量标准。
• 培训与教育 — 确保开发人员和策略编写者理解如何正确使用和管理属性。

ABAC 可审计性与合规报告

ABAC 的可审计性和合规报告对于证明对访问决策的控制并保持监管合规至关重要。通过启用详细日志记录、策略可追溯性，并与监控及 compliance tools 集成，组织可以确保访问管理的透明度与问责性。

如何记录并追踪 ABAC 决策

要有效地记录并追踪 ABAC 决策，组织必须在每一次访问评估点都捕获全面且结构化的数据。每条日志记录都应包含决策结果（例如允许或拒绝）、用户身份、请求的资源、尝试执行的操作、已评估的属性（包括主体和环境）以及所应用的具体策略和规则。

最佳实践：

• 使用 JSON 或 XML 等格式，以确保日志结构化便于机器读取，并更容易与分析工具集成。
• 在策略评估过程中，说明哪些条件已满足、哪些条件未满足，并据此解释每项决策背后的原因。
• 记录在做出决策时所使用的策略或属性架构版本，以支持历史审计。
• 为确保审计完整性和可追溯性，记录与会话相关的详细信息，例如时间戳、会话 ID、IP 地址、设备 ID 和位置。
• 确保日志具备防篡改特性并被安全存储。
• 在测试与调试环境中启用详细日志记录，并在生产环境中应用过滤日志，以在细节与性能之间取得平衡。

通过实施详尽且一致的日志记录机制，ABAC 系统可以提供完整的透明度，支持取证调查，并确保符合监管审计要求。

与 SIEM、GRC 及合规工具的集成

将 ABAC 系统与 SIEM、GRC 平台以及其他合规工具集成，可以提升可视性、监控能力以及监管对齐程度。

与 SIEM（Security Information and Event Management）的集成

• 日志转发：将 ABAC 决策日志实时导出到 Splunk、QRadar 或 Elastic Stack 等 SIEM 工具，以监控访问模式、检测异常并响应威胁。
• 为 ABAC 日志添加安全事件类型标签，以便与更广泛的事件进行关联分析，从而检测异常或潜在泄露（例如，不寻常的属性组合或被拒绝的访问尝试）。
• 使用 SIEM 仪表板可视化访问趋势、策略违规或未经授权的尝试。

GRC（治理、风险与合规）集成

• 将 ABAC 日志与 GRC 平台（例如 RSA Archer、ServiceNow GRC）集成，用于策略执行验证、风险评分以及合规报告。
• 自动化对访问决策和属性使用的定期审查，以验证最小权限原则与策略遵循情况。
• 利用 ABAC 日志，说明谁在何时、在何种条件下访问了哪些内容，以满足审计准备要求。

合规工具

• 将策略与属性变更管理与合规系统集成，确保可追溯性和责任落实。
• 生成审计就绪的报告，重点展示谁在何种条件下、因为什么原因访问了哪些内容。
• 使用结构化的 ABAC 日志生成符合 GDPR、HIPAA、SOX 和 FedRAMP 等标准的合规报告。
• 构建自定义仪表板，以可视化访问决策、策略更改和属性使用情况。

满足 GDPR、HIPAA、SOX 和 FedRAMP 的要求

ABAC 提供了一种动态且由策略驱动的访问管理方法，有助于满足各类监管框架的严格要求。以下是 ABAC 如何支持遵循主要标准。

GDPR（General Data Protection Regulation）

• 通过审计日志证明对个人数据的合法访问。
• 记录数据主体访问请求（DSARs）以及对个人数据的操作。

HIPAA（Health Insurance Portability and Accountability Act）

• 确保对 ePHI（electronic Protected Health Information，电子受保护健康信息）的访问可追溯且得到授权，并基于与角色、责任和情境相关的 ABAC 策略。
• 按要求将审计日志保留六年。

SOX（Sarbanes-Oxley Act）

• 记录并留存对金融系统和数据的访问日志。
• 通过基于策略的控制以及对日志访问进行审查，确保职责分离。

FedRAMP（联邦风险与授权管理计划）

• 以严格的可追溯性记录对政府系统和数据的所有访问。
• 保持实时监控，并与持续诊断与缓解（CDM）工具进行集成。

ABAC 的工具和标准

让我们来了解 ABAC 的工具和标准，其中也包括与 ABAC 实施相关的 Netwrix 产品。

XACML

XACML（eXtensible Access Control Markup Language）是一种被广泛采用的 OASIS 标准，它定义了一种用于编写访问控制策略的声明式、基于 XML 的语言，以及用于评估访问请求的处理模型。主要特性包括：

• 策略语言——使用主体、资源、动作和环境的属性来表达复杂的访问控制逻辑。
• 架构支持（Architecture Support）— 定义关键组件，例如策略强制点（Policy Enforcement Point，PEP）、策略决策点（Policy Decision Point，PDP）以及策略信息点（Policy Information Point，PIP）。
• 可扩展性（Extensibility）— 允许自定义函数和数据类型。
• 互操作性（Interoperability）— 使不同架构系统之间能够基于标准进行通信。

ALFA

ALFA（Abbreviated Language for Authorization，授权简化语言）是一种高层、可供人类阅读的语言，会编译为 XACML。它通过提供更清晰的语法以及更好的开发者体验，简化了编写 XACML 策略的工作。主要特性包括：

• 可读性——使用类似 Java 或 C# 的直观语法，降低学习曲线。
• IDE 集成——由 Axiomatics Policy Editor 等工具支持，并通过用于策略建模和调试的 Eclipse 插件提供支持。
• 自动编译——自动转换为符合 XACML 3.0 的策略。

NGAC

NGAC（Next Generation Access Control，下一代访问控制）是 NIST 制定的一项标准，它提供了一种灵活的、基于图的模型，用于表达并执行访问控制策略。主要特性包括：

• 基于图的模型（Graph-Based Model）——使用有向图中的对象、属性和关系来表示策略。
• 动态且具备上下文感知（Dynamic and Context-Aware）——支持根据不断变化的关系或环境属性进行实时策略执行。
• 集成式控制（Integrated Controls）——将 DAC、MAC、RBAC 和 ABAC 组合为一个统一且连贯的框架。

NIST SP 800-162

NIST SP 800-162 定义了政府和企业系统中 ABAC 的概念、优势以及实施指南。它帮助组织理解如何设计并应用 ABAC，以实现安全且灵活的访问控制。

标题：“属性型访问控制（ABAC）定义与考虑事项指南“

发布方：美国国家标准与技术研究院（NIST）

发布日期：2014年1月

Netwrix 面向 ABAC 的工具

Netwrix 提供多种工具和解决方案，旨在提升各类 IT 环境中的安全性与合规性。尽管 Netwrix 主要关注与数据访问和用户活动相关的可视性与治理，但它也可以通过多种方式支持 ABAC 的落地实施。

• 可见性与审计 – Netwrix Auditor 提供全面的审计能力，让您能够追踪谁拥有对哪些资源的访问权限，以及这些资源是如何被使用的。该洞察对于制定和优化 ABAC 策略至关重要，因为它有助于理解用户行为与访问模式。
• 识别访问权限 – Netwrix Identity Governance 通过利用与用户角色、操作以及环境条件相关的属性，帮助识别全组织范围内的访问权限，并使其与业务目标保持一致。
• 用户与实体行为分析（UEBA）– 通过分析用户行为， Netwrix Threat Prevention 可以帮助识别异常模式或异常情况，这些可能表明您的 ABAC 策略存在配置错误，或可能存在潜在的安全威胁。
• 保持一致的策略 – Netwrix PolicyPak 使组织能够在不同平台上维持一致的访问控制策略，并能与现有系统无缝集成，从而促进向 ABAC 模型的过渡。
• 访问复核与再认证 – Netwrix 可简化定期开展访问复核的流程，帮助确保访问权限始终与业务需求和合规要求保持一致。
• 集成与自动化 — Netwrix 可以与其他 IT 管理和安全工具进行集成，从而实现对不同平台和服务上的 ABAC 策略进行更自动化、更加协调一致的管理方式。
• 合规报告 — Netwrix solutions 可以生成详细的合规报告，以证明其遵循相关策略和监管要求；这对于使用 ABAC 基于严格合规需求来实施访问控制的环境至关重要。

Netwrix Identity Manager

Netwrix Identity Manager 可让您枚举 IT 系统的 Security Policy（有关访问权限控制方面），并可自动化部署这些控制。由此，您的组织能够免受安全漏洞的影响，包括与职责分离相关的漏洞。

持续检测身份与访问风险：从冲突的权限(Entitlements)和 SoD 违规，到处于休眠状态或权限过大的账户。利用内置的风险评分和基于策略的控制，防止特权升级并落实治理——在威胁真正出现之前。

支持 ABAC 的其他工具与平台

总结与最终思考

ABAC 代表了保护敏感数据的一次范式转变：它基于用户属性、环境条件和资源特征，提供细粒度且动态的访问决策。ABAC 提升了灵活性与精确度，使其非常适合复杂且快速演进的 IT 环境。要点包括其可扩展性、与合规要求的更好匹配，以及基于上下文的安全落地——从而使其成为满足现代访问管理需求的更优解决方案。

希望实施 ABAC 网络安全的组织，可以从 Netwrix 提供的工具等解决方案中获益。我们的产品能够共同帮助企业有效落地 ABAC，在适应现代 IT 环境复杂性的同时，确保强有力的安全性。

常见问题(FAQs)

用通俗的话说，ABAC 是什么？

ABAC 是一种根据不同特征（或“属性 attributes”）来控制系统中谁可以访问哪些信息的方法。想象一个图书馆：你能否阅读某本书取决于：

• 你是谁（学生、教师）
• 这本书是什么（受限、公开）
• 现在几点（在工作时间内）
• 你想阅读它的原因（研究、娱乐）

与其仅根据你的角色授予访问权限（例如传统系统中的“admin”或“user”），ABAC 会检查以下属性：

• 用户（例如：部门、许可/清查级别）
• 资源（例如：敏感度级别、类型）
• 操作（例如：读取、写入、删除）
• 环境（例如：位置、一天中的时间）

如果满足所有正确的条件，则授予访问权限。

ABAC 与 RBAC 有什么不同？

下面是 ABAC（基于属性的访问控制）与 RBAC（基于角色的访问控制）的对比。

可以把它理解为：

• RBAC – 你被分配一个角色（如“Manager”），而该角色拥有相应权限（如“View Reports”）。
• ABAC – 访问决策取决于许多细节的组合，例如：
• 你是谁（user.department = HR）
• 你试图做什么（action = edit）
• 你想访问的内容（resource.type = record）
• 诸如时间、地点、设备等条件（environment.time < 5pm）

ABAC有哪些现实中的应用例子？

以下是来自不同行业的若干 ABAC 真实案例，帮助说明它在实践中的工作方式。

有哪些工具或标准支持 ABAC？

有多种工具、框架和标准支持 ABAC。有关更多信息，请参阅“ABAC 的工具和标准”部分。

ABAC 是否更适合用于零信任（Zero Trust）安全？

是的，通常而言，ABAC 与零信任（Zero Trust）安全原则的匹配度比 RBAC 等较早的模型更高。

零信任（Zero Trust）是一种安全模型，其运作原则是“永不信任，始终验证”（Never trust, always verify）。它要求对以下内容进行持续验证：

• 用户身份
• 设备健康状况
• 访问上下文
• 数据敏感性
• 环境（例如位置、时间）

由于以下原因，ABAC 非常适合 Zero Trust：

• 细粒度访问控制 – ABAC 使组织能够基于多种属性（例如用户身份、设备合规性、资源敏感度等）定义高度细致的访问策略。这确保只有在特定、预先定义的条件下才授予访问权限——完美契合 Zero Trust 的理念：验证每一次请求，而不是依赖宽泛的角色分配。
• 情境感知决策 – ABAC 不仅会考虑“谁在访问”，还会考虑“如何访问、何时访问以及从何处访问”。这种情境意识使 Zero Trust 系统能够做出更聪明、更安全的决策，并反映每次交互当前的风险等级。
• 最小权限强制 – ABAC 使得更容易应用最小权限原则：在特定的上下文中针对特定操作，只授予达到目的所必需的最低访问权限。
• 可扩展性与自动化 – 在云原生、多租户、基于微服务的环境中，ABAC 的可扩展性更强。它支持使用能够适应不断变化的用户属性和系统状态的策略来进行自动化决策——非常适合 Zero Trust 架构。
• 持续验证 – 基于属性的访问控制（ABAC）通过将实时检查纳入访问决策，来支持持续的风险评估，例如验证设备是否安全，或是否启用了 MFA。这样做与 Zero Trust 的核心原则保持一致：在授予或维持访问权限之前持续验证信任。