abac2011：2011年系统构架师考试，案例分析试题详解与共勉，及复习权限系统设计模型分析（DAC，MAC，RBAC，ABAC，XACML）

前言

2011年系统构架师考试，案例分析试题详解与共勉。

案例分析题考试首先要知道以下几点：

• 案例分析题一共5道题，第一题必做，后面4选2.
• 后面四题中必有一道嵌入式题，非嵌入式专业的请直接放弃。所有实际上是3选2.
• 考试时间90分钟，基本上每道题平均30分钟。时间还是很紧的
• 答题写字一定要清晰，答题内容关键要切中要点，在时间允许的范围内，尽可能多写点。说不定就答中关键点了。但是如果自己清晰知道已经答中要点了，就不要多写废话了，节约时间。

今年，我押宝--->系统的安全性和保密性设计,其知识点，包括系统的访问控制技术，数据的完整性，数据与文件的加密，通信的安全性，系统的安全性设计。

依靠不断考证，来促进自己学习新的知识，是一个不错的手段，其中权限系统设计模型分析（DAC，MAC，RBAC，ABAC，XACML），时软件开发中常用到的知识点！

试题一

【说明】某网上购物电子商务公司拟升级正在使用的在线交易系统，以提高用户网上购物在线支付环节的效率和安全性。

在系统的需求分析与架构设计阶段，公司提出的需求和关键质量属性场景如下：

(a) 正常负载情况下，系统必须在0.5秒内对用户的交易请求进行响应；

(b) 信用卡支付必须保证99.999%的安全性；

(c) 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；

(d) 网络失效后，系统需要在1.5分钟内发现错误并启用备用系统；

(e) 需要在20人月内为系统添加一个新的CORBA中间件；

(f) 交易过程中涉及到的产品介绍视频传输必须保证画面具有600*480的分辨率，20帧/秒的速率；

(g) 更改加密的级别将对安全性和性能产生影响；

(h) 主站点断电后，需要在3秒内将访问请求重定向到备用站点；

(i) 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的；

(j)用户信息数据库授权必须保证99.999%可用；

(k)目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；

(l)更改Web界面接口必须在4人周内完成；

(m)系统需要提供远程调试接口，并支持系统的远程调试。在对系统需求和质量属性场景进行分析的基础上，系统的架构师给出了三个候选的架构设计方案。公司目前正在组织系统开发的相关人员对系统架构进行评估。

【问题1】

在架构评估过程中，质量属性效用树（utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性，填入图1-1中（1)、(2)空白处；并选择题干描述的（a)〜（m)，填入（3)〜（6)空白处，完成该系统的效用树。

【问题2】

在架构评估过程中，需要正确识别系统的架构风险、敏感点和权衡点，并进行合理的架构决策。请用300字以内的文字给出系统架构风险、敏感点和权衡点的意义，并从题干（a)〜（m)中各选出1个对系统架构风险、敏感点和权衡点最为恰当的描述。

• 系统架构风险，是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
• 敏感点，是指为了实现某种特定的质量属性，一个或多个系统组件所具有的特性。
• 权衡点是指影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。

题干描述中，（k)描述的是系统架构风险；（c)描述的是敏感点；（g)描述的是权衡点。

试题二

【说明】某软件公司成立项目组为某高校开发一套教职工信息管理系统。与教职工信息相关的数据需求和处理需求如下：

(1) 数据需求：在教职工信息中能够存储学校所有在职的教工和职工信息，包括姓名、所属部门、出生年月、工资编号、工资额和缴税信息；部门信息中包括部门编号、部门名称、部门人数和办公地点信息。

(2) 处理需求：能够根据编制内或外聘教职工的工资编号分别查询其相关信息；每个月的月底统一核发工资，要求系统能够以最快速度査询出教工或者职工所在部门名称、实发工资金额；由于学校人员相对稳定，所以数据变化及维护工作量很少。

项目组王工和李工针对上述应用需求分别给出了所设计的数据模型（如图2-1和图 2-2所示)。王工遵循数据库设计过程，按照第三范式对数据进行优化和调整，所设计的数据模型简单且基本没有数据冗余；而李工设计的数据模型中存在大量数据冗余。项目组经过分析和讨论，特别是针对数据处理中对数据访问效率的需求，最终选择了李工给出的数据模型设计方案。

王工	李工

【问题1】

请用300字以内的文字，说明什么是数据库建模中的反规范化技术，指出采用反规范化技术能获得哪些益处，可能带来哪些问题。

• 规范化设计后，数据库设计者希望牺牲部分规范化来提髙性能，这种从规范化设计的回退方法叫做反规范化技术。
• 反规范化设计允许保留或者新增一些冗余数据，从而减少数据查询中表连接的数目或简化计算过程，提高数据访问效率。
• 采用反规范化技术的益处：能够减少数据库查询时SQL连接的数目，从而减少磁盘I/O数据量，提高查询效率。
• 可能带来的问题：数据的重复存储，浪费了磁盘空间；为了保障数据的一致性，增加了数据维护的复杂性。

【问题2】

请简要叙述常见的反规范化技术有哪些。 常见的反规范化技术包括： 

增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作；

增加派生列：在表中增加可以由本表或其他表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数；

表水平分割：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用；

 表垂直分割：对表进行分割，将主键与部分列放到一个表中，主键与其他列放到另一个表中，在查询时减少I/O次数。

【问题3】

请分析李工是如何应用反规范化技术来满足教职工信息管理需求的。

在教职工信息管理系统的需求中，（1)能够根据编制内或外聘教职工的工资编号分别查询其相关信息；（2)数据查询要求有很高的处理效率。

李工所设计的数据模型中采用了三种反规范化技术：

增加冗余列：增加“部门名称”列，消除了数据查询中“教职工信息”表和“部门信息”表之间的连接；

增加派生列：增加“实发工资”列，消除了实发工资的计算过程；

表水平分割：将教职工信息表分割为“编制内教职工信息”表和“外聘教职工信息”表，减少了数据查询的范围。

试题三

【说明】某公司承接了某机载嵌入式系统的研制任务。该机载嵌入式系统由数据处理模块、大容量模块、信号处理模块、数据交换模块和电源模块等组成。

数据处理模块有2个， 分别完成数据融合和导航通讯任务；

大容量模块主要功能是存储系统数据，同时要记录信号处理模块、数据处理模块的自检测、维护数据，向数据处理模块提供地图数据；

信号处理模块的处理器为专用的DSP，接收红外、雷达等前端传感器数据并进行处理，将处理后的有效数据（数据带宽较大）发送给数据处理模块；

数据交换模块主要负责系统的数据交换；

电源模块主要负责给其他模块供电，电源模块上没有软件。

要求该机载嵌入式系统符合综合化、模块化的设计思想，并考虑系统在生命周期中的可靠性和安全性，以及硬件的可扩展性和软件可升级性，还要求系统通讯延迟小，支持多模块上的应用任务同步。

【问题1】

在设计系统架构时，李工提出了如图3-1所示的系统架构，即模块间的网络通信采用光纤通信(Fiber Channel,FC)技术，而王工认为应采用VME总线架构，如图3-2所示。王工的理由是公司多年来基于VME总线技术设计了多个产品，技术成熟，且费用较小。但公司经过评审后，决定采用图3-1所示的基于Fd的系统结构。
请用500字以内的文字，说明VME和FC各自的特点，并针对机载嵌入式系统的要求指出公司采用李工方案的理由。

 VME总线采用存储映射方式，多主仲裁机制，同一时刻由单一主机控制，同时仲裁机制为菊花链方式。 针对本系统要求，采用VME方案存在如下问题：

当多主机设备仲裁时，按菊花链的连接次序一个主机处理完成后，才能将控制权交给另一主机控制总线，导致任务执行延时大，不能满足“系统通讯延迟小”以及“支持多模块上的应用任务同步”的要求；

与FC相比，VME总线实时性差，带宽低；

VME总线方式限制了可扩展性。

FC采用消息包交换机制，支持广播和组播。 针对本系统要求，采用FC方案有以下优点：

 由于釆用消息包交换机制，支持广播和组播，任务执行并发性好，能满足“系统通讯延迟小”以及“支持多模块上的应用任务同步”的要求。

与VME比较，FC实时性好，带宽高；

FC的误码率低，所以可靠性高；

允许在同一接口上传输多种不同的协议，对上层应用实现提供了便利；

FC采用消息机制，FC可扩展性好，如模块较多可采用多个FC网络交换模块级联；

传输距离远，当与外部其他设备相连时，比较方便；

系统采用统一的FC网络代替了VME底板总线，降低总线驱动的功耗，简化了底板。

【问题2】

公司依据ARINC653标准，设计了满足ARINC653标准的操作系统，该操作系统对系统中可能发生的模块级、分区级和进程级的错误进行处理，实现了如图3-3所示的系统健康监控机制，请分别将备选答案中的各种错误和健康监控部件填入图3-3中的2011年(1)

备选答案：分区健康监控、分区初始化阶段出现的分区配置错误、分区切换时出现的错误、应用进程错误、进程健康监控。

注：ARINC653 标准（Avionics Application Software StandardInterface)是美国航空电子工程协会AEEC于1997年为航空民用飞机的模块化综合航空电子系统定义的应用程序接口标准，该标准提出了分区（Partition)的概念以及健康监控（healthmonitoringY机制。分区是应用的一种功能划分，也是操作系统调度的基本单位，严格按预先分配的时间片调度。分区间具有时空隔离特点。分区内的每一执行单元称为进程。

【问题3】

为了实现满足ARINC653标准的操作系统的时空分区隔离机制，项目组选择了PowerPC作为数据处理模块的处理器（CPU)。这样，当一个分区出现故障时，不会蔓延到模块中同一处理器的其他分区。请用500字以内的文字，说明如何采用PowerPC实现应用与内核以及诸应用之间的隔离和保护。

采用PowerPC实现系统隔离和保护的两种机制是：

第一种是内存管理机制（MMU)»MMU能够实现逻辑地址到物理地址的转化，并且对访问权进行控制，既可以保护系统内核不受应用软件有意或无意的破坏，也可有效防止各软件之间的互相破坏。

第二种是TRAP系统调用机制。操作系统为实现对内核以及应用之间的保护，提供了用户态和系统态两种运行形态。操作系统内核在系统态运行，因此用户态的应用不能直接调用系统内核提供的功能接口，必须通过TRAP系统调用的方式进行。因此可以实现应用与内核之间的隔离与保护。

试题四

【说明】某公司拟开发一个市场策略跟踪与分析系统，根据互联网上用户对公司产品信息的访问情况，和产品实际销售情况来追踪各种市场策略的效果。其中互联网上用户对公司产品信息的访问情况，借助两种不同的第三方Web分析软件进行数据采集与统计，并生成不同格式的数据报表；公司产品的实际销售情况,则需要通过各个分公司的产品销售电子表格或数据库进行采集与汇总。得到相关数据后，还要对数据进行分析与统计，并通过浏览器以在线的方式向市场策略制定者展示最终的市场策略效果。

架构师王工提出采用面向服务的系统架构，首先将各种待集成的第三方软件和异构数据源统一进行包装，然后将数据访问功能以标准Web服务接口的形式对外暴露，从而支持系统进行数据的分析与处理，前端则采用CSS等技术实现浏览器数据的渲染与展示。

架构师李工则认为该系统的核心在于数据的定位、汇聚与转换，更适合采用面向资源的架构，即首先为每种数据元素确定地址，然后将各种数据格式统一转换为JSON格式，通过对JSON数据的组合支 持数据的分析与处理任务，处理结果经过渲染后在浏览器的环境中进行展示。在架构评估会议上，专家对这两种方案进行综合评价，最终采用了李工的方案。

【问题1】

请根据题干描述，对市场策略跟踪与分析系统的数据源特征与数据操作方式进行分析，完成表4-1中的（1)〜（3)，并用200字以内的文字说明李工方案的优点。

通过对系统的数据源特征和数据操作方式进行分析可以看出，待集成的数据均为持久型数据（文件或数据库），系统对数据的访问均为只读非实时性的。针对上述应用特征，李工提出的面向资源的架构方式，以对数据资源的只读访问为核心，通过数据唯一标识，直接对各种数据进行访问与获取，系统架构清晰、实现简单、效率较高。

【问题2】

请从数据获取方式、数据交互方式和数据访问的上下文无关性三个方面对王工和李工的方案进行比较，并用500字以内的文字说明为什么没有采用王工的方案。

从数据获取方式看：

• 王工的方案，需要将现有的多个系统和异构的数据源包装为服务，采用Web服务暴露数据接口，客户端需要通过服务调用获取数据，这种方法工作量大，复杂度较高。
• 李工的方案则绕开了复杂的功能封装，只需要明确数据的位置与标识，通过特定的网络协议直接使用标识定位并获取数据，与王工的方案相比工作量小，实现简单。

从数据交互方式看：

• 王工的方案采用远程过程调用和异步XML消息等模式实现数据交互，这种方式适合于系统之间功能调用时，进行的少量数据传输，而在进行单纯的数据访问时效率不高，稳定性也较差。
• 李工的方案则以数据资源为核心，在对数据资源进行标识的基础上，通过标识符直接对数据资源进行访问与交互，实现简单且效率较高。

从数据访问的上下文无关性看：

• 王工的方案中数据访问是与上下文有关的，具体表现在每次客户端进行数据请求，都需要附加唯一的请求标识，并且服务端需要区分不同的客户端请求，效率较低。
• 李工的方案中数据访问是与上下文无关的，客户端通过全局唯一的统一资源标识符（URI)请求对应的数据资源，服务端不需要区分不同的客户端请求。

【问题3】

表现层状态转换（REST)是面向资源架构的核心思想，请用200字以内的文字解释什么是REST,并指出在REST中将哪三种关注点进行分离？

REST从资源的角度来定义整个网络系统结构，分布在各处的资源由统一资源标识符（URI)确定，客户端应用程序通过URI获取资源的表现，并通过获得资源表现使得其状态发生改变。

REST中将资源、资源的表现和获取资源的动作三者进行分离。

试题五

【说明】某大型跨国企业的IT部门一年前基于SOA (Service-Oriented Architecture)对企业原有的多个信息系统进行了集成，实现了原有各系统之间的互连互通，搭建了支撑企业完整业务流程运作的统一信息系统平台。随着集成后系统的投入运行，IT部门发现在满 足企业正常业务运作要求的同时，系统也暴露出明显的安全性缺陷，并在近期出现了企业敏感业务数据泄漏及系统核心业务功能非授权访问等严重安全事件。针对这一情况， 企业决定由IT部门成立专门的项目组负责提髙现有系统的安全性。项目组在仔细调研和分析了系统现有安全性问题的基础上，决定首先为在网络中传输的数据提供机密性（Confidentiality)与完整性（Integrity)保障，同时为系统核心业务 功能的访问提供访问控制机制，以保证只有授权用户才能使用特定功能。经过分析和讨论，项目组决定采用加密技术为网络中传输的数据提供机密性与完整性保障。但在确定具体访问控制机制时，张工认为应该采用传统的强制访问控制 (Mandatory Access Control)机制，而王工则建议采用基于角色的访问控制（Role-Based Access Control)与可扩展访问控制标记语言(extensible Access Control Markup Language, XACML)相结合的机制。项目组经过集体讨论，最终采用了王工的方案。

【问题1】

请用400字以内的文字，分别针对采用对称加密策略与公钥加密策略，说明如何利用加密技术为在网络中传输的数据提供机密性与完整性保障。

对称加密策略：

• 机密性：发送者利用对称密钥对要发送的数据进行加密，只有拥有正确相同密钥的接收者才能将数据正确解密，从而提供机密性。
• 完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用对称密钥对消息认证码进行加密并附加到数据上发送；接收者使用相同密钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。

公钥加密策略：

• 机密性：发送者利用接收者的公钥对要发送的数据进行加密，只有拥有对应私钥的接收者才能将数据正确解密，从而提供机密性。
• 完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用自己的私钥对消息认证码进行加密并附加到数据上发送；接收者利用对方的公钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。

【问题2】

请用300字以内的文字，从授权的可管理性、细粒度访问控制的支持和对分布式环境的支持，三个方面指出项目组采用王工方案的原因。

采用王工方案是因为基于角色的访问控制与XACML相结合的机制具有以下优势：

• 授权的可管理性：RBAC将用户与权限分离，相比MAC减小了授权管理的复杂性, 更适合于大型企业级系统的安全管理：
• 细粒度访问控制的支持：XACML提供了统一的访问控制策略描述语言，策略表达能力强，可用来描述各种复杂的和细粒度的访问控制安全需求，更适合企业复杂业务功能的访问控制要求；
• 分布式环境的支持：XACML的标准性便于各子系统的协作交互，各子系统或企业业务部门可以分布管理访问控制权限，而MAC则通常需要对访问控制权限集中管理，不太适合企业基于SOA集成后的分布式系统。

【问题3】

图5-1给出了基于XACML的授权决策中心的基本结构以及一次典型授权决策的执行过程，请分别将备选答案填入图中的（1)〜（4)。

                                

备选答案：策略管理点（PAP)、策略执行点（PEP)、策略信息点（PIP)、策略决策点（PDP)

答案：

权限系统设计模型分析（DAC，MAC，RBAC，ABAC，XACML）

基于目前世面上现有的一些权限系统设计来解析，权限系统设计模型分析（DAC，MAC，RBAC，ABAC，XACML）

术语

用户	对象（Subject）	权限控制表 (ACL: Access Control List)	权限 (Permission)	权限标识
发起操作的主体。	指操作所针对的客体对象，比如订单数据或图片文件。	用来描述权限规则或用户和权限之间关系的数据表。	用来指代对某种对象的某一种操作，例如“添加文章的操作”。	权限的代号，例如用“ARTICLE_ADD”来指代“添加文章的操作”权限。

自主访问控制（DAC: Discretionary Access Control）

系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息，来决定用户的是否能对其进行哪些操作，例如读取或修改。

而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为“自主（Discretionary）”控制。

这种设计最常见的应用就是文件系统的权限设计，如微软的NTFS。

DAC最大缺陷就是对权限控制比较分散，不便于管理，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户，比如：Windows的文件权限。

强制访问控制（MAC: Mandatory Access Control）

MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象，进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。

比如在影视作品中，我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。

MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用，具体参考RedHat MLS。

基于角色的访问控制（RBAC: Role-Based Access Control)

因为DAC和MAC的诸多限制，于是诞生了RBAC，并且成为了迄今为止最为普及的权限设计模型。
RBAC在用户和权限之间引入了“角色（Role）”的概念（暂时忽略Session这个概念）：

如图所示，每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而可以实现了非常灵活的权限管理。

角色可以根据实际业务需求灵活创建，这样就省去了每新增一个用户，就要关联一遍所有权限的麻烦。

简单来说RBAC就是：用户关联角色，角色关联权限。

另外，RBAC是可以模拟出DAC和MAC的效果的。

例如数据库软件MongoDB便是采用RBAC模型，对数据库的操作都划分成了权限（MongoDB权限文档）：

权限标识	说明
find	具有此权限的用户可以运行所有和查询有关的命令，如：aggregate、checkShardingIndex、count等。
insert	具有此权限的用户可以运行所有和新建数据有关的命令：insert和create等。
collStats	具有此权限的用户可以对指定database或collection执行collStats命令。
viewRole	具有此权限的用户可以查看指定database的角色信息。
…

基于这些权限，MongoDB提供了一些预定义的角色（MongoDB预定义角色文档，用户也可以自己定义角色）：

角色	find	insert	collStats	viewRole	…
read	✔		✔		…
readWrite	✔	✔	✔		…
dbAdmin	✔		✔		…
userAdmin				✔	…

最后授予用户不同的角色，就可以实现不同粒度的权限分配了。

目前市面上绝大部分系统在设计权限系统时都采用RBAC模型。然而也有的系统错误地实现了RBAC，他们采用的是，判断用户是否具有某个角色而不是判断权限，例如以下代码：

<?phpif ($user->hasRole('hr')) {    // 执行某种只有“HR”角色才能做的功能，例如给员工涨薪…    // ...}

如果后期，公司规定部门经理也可以给员工涨薪，这时就不得不修改代码了。

以上基本就是RBAC的核心设计（RBAC Core）。而基于核心概念之上，RBAC规范还提供了扩展模式。

角色继承(Hierarchical Role)--->带有角色继承的RBAC

顾名思义，角色继承就是指角色可以继承于其他角色，在拥有其他角色权限的同时，自己还可以关联额外的权限。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

职责分离(Separation of Duty)

为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限（看一眼就给你判犯规狠不狠？），另一种职责分离扩展版的RBAC被提出。
职责分离有两种模式：

• 静态职责分离(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。

• 动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中，不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。

讲了这么多RBAC，都还只是在用户和权限之间进行设计，并没有涉及到用户和对象之间的权限判断，而在实际业务系统中，限制用户能够使用的对象是很常见的需求。例如华中区域的销售，没有权限查询华南区域的客户数据，虽然他们都具有销售的角色，而销售的角色拥有查询客户信息的权限。

那么我们应该怎么办呢？

用户和对象的权限控制

在RBAC标准中并没有涉及到这个内容（RBAC基本只能做到对一类对象的控制），但是这里讲几种基于RBAC的实现方式。
首先我们看看PHP框架Yii 1.X的解决方案（2.X中代码更为优雅，但1.X的示例代码更容易看明白）：

<?php$auth=Yii::app()->authManager;$auth->createOperation('createPost','create a post');$auth->createOperation('readPost','read a post');$auth->createOperation('updatePost','update a post');$auth->createOperation('deletePost','delete a post');// 主要看这里。// 这里创建了一个名为`updateOwnPost`的权限，并且写了一段代码用来检验用户是否为该帖子的作者$bizRule='return Yii::app()->user->id==$params["post"]->authID;';$task=$auth->createTask('updateOwnPost','update a post by author himself',$bizRule);$task->addChild('updatePost');$role=$auth->createRole('reader');$role->addChild('readPost');$role=$auth->createRole('author');$role->addChild('reader');$role->addChild('createPost');$role->addChild('updateOwnPost');$role=$auth->createRole('editor');$role->addChild('reader');$role->addChild('updatePost');$role=$auth->createRole('admin');$role->addChild('editor');$role->addChild('author');$role->addChild('deletePost');

实现效果：

在这个Yii的官方例子中，updateOwnPost在判断用户是否具有updatePost权限的基础上，更进一步判断了用户是否有权限操作这个特定的对象，并且这个判断逻辑是通过代码设置的，非常灵活。

不过大部分时候我们并不需要这样的灵活程度，会带来额外的开发和维护成本，而另一种基于模式匹配规则的对象权限控制可能更适合。例如判断用户是否对Id为123的文章具有编辑的权限，代码可能是这样的：

<?php// 假设articleId是动态获取的$articleId = 123;if ($user->can("article:edit:{$articleId}")) {    // ...}

而给用户授权则有多种方式可以选择：

<?php// 允许用户编辑Id为123的文章$user->grant('article:edit:123');// 使用通配符，允许用户编辑所有文章$user->grant('article:edit:*');

虽然不及Yii方案的灵活，但某些场景下这样就够用了。

基于属性的权限验证（ABAC: Attribute-Based Access Control）

ABAC被一些人称为是权限系统设计的未来。

不同于常见的，将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性，来是否满足某种条件来进行授权判断（可以编写简单的逻辑）。

属性通常来说分为四类：用户属性（如用户年龄），环境属性（如当前时间），操作属性（如读取）和对象属性（如一篇文章，又称资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。

例如规则：“允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。

为了实现便捷的规则设置和规则判断执行，ABAC通常有配置文件（XML、YAML等）或DSL配合规则解析引擎使用。

XACML（eXtensible Access Control Markup Language）是ABAC的一个实现。

 ABAC授权的实现步骤

用户访问资源，发送原始请求。

请求发送到策略实施点（PEP），PEP构建xacml格式请求。

PEP将xacml请求发送到策略决策点（PDP）。

PDP根据xacml请求，查找策略管理点（PAP）中的策略文件。

PDP从策略信息点（PIP）查找策略文件中需要的属性值（主体、资源、环境属性）。

PDP将决策结果（permit、deny、不确定、不适用）返回给PEP。

PEP发送请求到资源，并把资源返回给用户。

ABAC策略文件组成

然后就是策略文件的构成，策略文件是非常重要的文件，所有的决策都是根据策略文件来判断的

策略文件的组成包括几部分，及目标、规则。

总结ABAC有如下特点：

• 集中化管理
• 可以按需实现不同颗粒度的权限控制
• 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中
• 定义权限时，不能直观看出用户和对象间的关系
• 规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦
• 权限判断需要实时执行，规则过多会导致性能问题

Kubernetes的系统对权限控制引入了ABAC，同时兼顾RBAC的方案，ABAC有时也被称为PBAC（Policy-Based Access Control）或CBAC（Claims-Based Access Control）。