IEC 10181-3-00 / CAN/CSA-ISO/IEC 10181-3-00 信息技术－开放系统互连－开放系统安全框架－访问控制框架

标准概况与适用范围

IEC 10181-3-00（对应加拿大采纳版本 CAN/CSA-ISO/IEC 10181-3-00）是国际标准化组织与电工委员会联合制定的“开放系统互连安全框架”系列标准的第三部分，全称为“信息技术－开放系统互连－开放系统安全框架：访问控制框架”（Information technology – Open Systems Interconnection – Security frameworks for open systems: Access control framework）。该标准最早于1996年正式发布，经多次复审后仍作为开放系统安全体系的基本参考文件，2026年依然广泛应用于安全架构设计领域。

本标准的适用范围涵盖所有采用开放系统互连（OSI）体系或类似分层网络模型的系统，包括但不限于企业内网、跨域协作系统、分布式服务架构以及物联网平台。它为访问控制安全服务与机制提供了一个通用的概念性框架，定义了访问控制必须包含的实体、操作流程以及策略表达方式。标准并不规定具体的实现技术或算法，而是聚焦于通过统一术语与抽象模型促进不同系统之间的互操作和安全组件集成。

实用提示：尽管本框架源于OSI参考模型，但其核心概念（如判决功能、实施功能、访问控制信息）可以映射到任何基于策略的访问控制场景中，包括Web权限管理、数据库安全、云服务授权等现代环境。理解本框架有助于设计出可迁移、可审计的安全体系。

主要技术内容与要求

核心组件与相互作用

标准明确定义了访问控制中的关键实体及其交互关系。下表列出了框架的六大基础元素，所有访问控制行为均围绕这些元素展开。

元素	英文名称	定义与作用
发起者（Initiator）	Initiator	发起访问请求的主动实体，可以是用户、进程或设备。发起者必须提供其身份凭证或相关属性供判决。
目标（Target）	Target	被访问的资源，包括数据对象、服务、功能接口等。目标通常关联访问控制信息（ACI）或安全标签。
访问控制判决功能	Access Control Decision Function (ADF)	负责根据预定义的访问控制策略和执行时上下文（如时间、位置、风险等级）对访问请求作出“允许”或“拒绝”判断的逻辑单元。
访问控制实施功能	Access Control Enforcement Function (AEF)	位于发起者与目标之间，实际拦截访问请求并从ADF获取判决结果，根据结果决定是否执行操作。AEF确保判决的强制性执行。
访问控制信息	Access Control Information (ACI)	用于支持判决功能的所有数据实体，包括发起者凭证、目标属性、操作类型、环境条件以及策略规则本身。标准将ACI细化为发起者ACI、目标ACI、请求ACI和上下文ACI。
访问控制策略	Access Control Policy (ACP)	规范访问行为的高级规则集合，定义了在何种条件下允许哪些操作。框架不限定策略类型（如基于身份、基于角色、基于规则），但要求策略必须能够被ADF理解并执行。

框架运行机制

当发起者向目标发出操作请求时，AEF拦截该请求并提取相关ACI，然后将其传递给ADF。ADF依据ACP和当前上下文进行推理，返回“允许”或“拒绝”的判决。AEF最终执行该判决，同时可能进行审计记录。整个流程中，框架强调判决功能与实施功能的严格分离，这一隔离设计便于安全审计与策略独立更新。

实施与应用要点

在将本框架落地到具体系统时，需要重点关注以下几个方面：

策略定义与维护：应用方必须根据安全需求制定正式的访问控制策略，并将策略转换为ADF可理解的规则语言。策略应覆盖常态环境与异常情况（如紧急访问、权限撤销）。
ACI管理：发起者身份凭证、目标分类等信息的真实性和完整性直接影响判决质量。建议采用基于公钥基础设施（PKI）或联邦身份机制来管理ACI的生命周期。
判决与实施分离：在系统架构中，ADF和AEF可以是物理或逻辑上的独立组件（如策略决策点PDP、策略执行点PEP），这种分离有利于策略的统一变更与分布式部署。
环境感知能力：现代系统需要支持动态上下文（如登录位置、设备健康度、访问频率），ADF应具备从环境获取实时ACI的能力，并支持基于风险的访问控制决策。

重要注意事项：常见误区包括（1）将ADF和AEF合并导致策略与执行逻辑耦合，难以审计；（2）忽略上下文ACI的实时性，导致使用过期属性做出错误判决；（3）认为框架提供了完整的实现规范。事实上，本标准仅提供概念框架，具体密码算法、协议报文、接口定义需结合其他标准（如XACML、RBAC配置）。

标准实施的益处：遵循IEC 10181-3-00的框架进行访问控制设计，可以实现安全组件的模块化替换，降低安全维护成本，并满足合规审计对“判决与实施分离”的典型要求。统一的概念体系也有助于团队跨项目沟通安全架构。

与其他标准的关系

IEC 10181-3-00 属于庞大的“开放系统互连安全框架”系列（ISO/IEC 10181系列），该系列还包括认证框架（Part 1）、完整性框架（Part 2）、保密性框架（Part 4）、不可否认性框架（Part 5）、审计框架（Part 6）以及密钥管理框架（Part 7）。访问控制作为安全服务中最基础的一环，通常需要与认证框架结合使用：只有通过认证的发起者才能被赋予可信身份进行后续访问控制判决。

此外，本框架与ITU-T X.800系列安全体系结构紧密对应。X.800定义的访问控制安全服务可直接映射到本框架中的AEF/ADF模型。实际项目中常将ISO/IEC 10181-3作为指导性概念，而将X.500系列、OAuth 2.0、XACML等作为具体实现参考。在安全评估方面，ISO/IEC 15408（通用评估准则，CC）的功能组件要求（如FDP_ACC、FDP_ACF）也采纳了本框架的术语和结构。

安全关键要求：在涉及跨域或关键基础设施系统时，必须确保所有访问请求都经过ADF的显式判决，任何“默认放行”路径都可能成为攻击入口。同时，ACI的缓存、传输与存储应使用与机密等级匹配的加密保护，防止攻击者伪造或重放ACI。这些要求源于本框架对“强制判决”与“信息机密性”的隐含前提。

常见问题（FAQ）

问：IEC 10181-3-00 与具体的访问控制机制（如访问控制列表、基于角色的访问控制）有何关系？
答：标准提供的是抽象框架，不指定特定机制。访问控制列表（ACL）可以看作访问控制信息中的“目标ACI”；基于角色的访问控制（RBAC）则是在策略层面将角色转化为规则。框架为不同类型机制提供了统一的描述语言，方便进行机制之间的映射与互操作。

问：该标准是否规定访问控制策略必须采用的类型（如自主、强制、基于角色）？
答：不强制。框架支持任意策略模型，只要策略能够被ADF正确解析。实际系统可以混合使用自主访问控制（DAC）与强制访问控制（MAC），只要在ADF内部实现相应的策略引擎。标准强调策略的清晰定义与强制执行，而非策略的内容。

问：在云环境或微服务架构中，如何应用本框架？
答：可将API网关、服务网格中的授权组件视为AEF；将集中策略引擎（如XACML PDP）视为ADF。ACI通过JWT Token、OAuth Scope等承载。框架的概念能够很好地适配分布式策略决策点与执行点分离的架构模式。建议结合零信任模型，将每个服务间的调用都视为一次需要判决的访问请求。

问：IEC 10181-3-00 与 ISO/IEC 27001 等信息安全管理标准如何协同？
答：ISO/IEC 27001 要求组织建立访问控制策略，但未提供技术结构。IEC 10181-3-00 为策略的技术实现提供了明确的组件分解和交互流程，使得安全管理体系的“开发与实施”阶段有了可操作的工程框架。二者配合可以实现从治理到实现层的完整覆盖。

📥 标准文件下载

🔒

请等待 10 秒，广告加载完成后将自动显示下载链接