| 编辑推荐: |
本文还以一个非常经典的安全模式PBAC（基于策略的访问控制模式）为例，演示了如何运用安全模式来解决现实安全问题。
本文来自于互联网安全内参，由火龙果软件Alice编辑、推荐。 |
|
有人认为安全很简单，但安全从来都不简单。安全问题频出的重要原因是相同错误被一再重犯。通过抽象反复遇到的安全问题，可以发现新的安全模式。将安全知识以安全模式的形式进行陈述，是避免错误被重复的有效途径。
本文介绍了使用模式创建安全系统的方法论。安全模式的最终目标是建立安全的系统。模式的重要作用是引导我们进行系统级的思考。一个系统不仅仅只是各个部分的组合，还包括各个部分之间的关联关系。只有进行系统级而非组件级的思考，才能设计出安全的系统。
安全模式本质上也是一种架构模式，安全模式将安全性与应用系统架构联系起来。安全模式的方法是一种工程方法。
本文还以一个非常经典的安全模式PBAC（基于策略的访问控制模式）为例，演示了如何运用安全模式来解决现实安全问题。
本文主要整编自译著《安全模式最佳实践》（Securisty Patterns
In Practice）。
一、为什么需要安全模式
现代应用系统越来越复杂，系统自身的复杂性导致了错误增多以及漏洞难以发现。而安全加固一直是以修修补补的方式进行的，系统各部分虽然都采用了特定的安全措施，却鲜有针对完整系统的整体安全分析。
想要阻断所有可能的攻击，在安全上就必须采用一种全面详尽的方法。安全组件再安全，如果没能覆盖到系统的每个角落，或者各组件间不协调同步，也无法保障系统整体的安全。威胁分析通常针对系统的各个部分单独进行，但很多威胁只在系统各部分连通时才会出现。
建设安全的系统应采用系统化的方式，即安全性应当如系统的可靠性和其他系统特性那样，成为软件生命周期中一个不可或缺的组成部分。如果在应用软件开发时能够将中间件、操作系统及网络等因素进行整体考虑，我们就能抵御来自内/外部全系列攻击。为了开发安全的应用系统，将底层平台和应用软件隔离开、先分别单独进行安全设计、而后再拼接的方式并不奏效；而应该将应用软件和底层平台一起设计，并使得底层平台和应用软件相匹配。
体系架构中较低层级的安全保证来自于上层应用遵循约束条件，换句话说，保证无法绕过这些约束条件。想要统一提供这种保证，唯一的选择是使用抽象。我们可以通过使用“模式”提供这种抽象。
模式封装了反复出现的系统问题的解决方案，同时精确地表述了系统要求和解决方案，也为设计人员提供了相互交流的工具。采用模式的系统架构描述比较容易让人看懂，也为设计和分析提供了指南，还定义了使架构更安全的方法。安全模式使得不具备专业安全知识的应用开发人员也可以使用安全措施。
模式意味着隐式地应用了原则。模式本身不提供可证明的安全性，但对日益复杂的系统来说，安全模式确实很实用。
二、安全模式是什么
安全模式是在给定的场景中，为控制、阻止或消减一组特定的威胁而采取的通用解决方案。在信息系统和软件设计中使用安全模式，可以有效地增强信息系统和软件的架构安全性，降低其安全风险。
对于每一个安全模式实例，均应描述其应用场景，并针对应用场景所面临的威胁和亟需解决的问题，提出对应的解决方案（即模式），再通过直观的UML图说明模式的具体实现、优点和已知应用。
安全模式将安全性与软件体系结构联系起来。由于采用了“提出问题→分析问题→解决问题→总结”的思路，即使读者对安全模式知之甚少，只要有一定的架构设计和信息安全基础，都能很快理解某一安全模式并加以应用。
安全模式的最终目标是建立安全的系统。为了这个目标，国外安全专家研究了使用模式创建安全系统的方法论。严格意义上来说，安全模式的方法是一种工程方法。
三、安全模式的性质
有多种视角看待安全模式：
?作为一种架构模式。可将安全模式看作一类架构模式，因为它们经常用来描述全局性的软件架构概念；例如，“在两个分离的功能单元之间是否需要认证功能？”我们倾向于这种解释，因为安全是全局属性。
?作为一种设计模式。安全是软件系统的组成部分，所以有些人把安全看作一种设计模式。我们认为设计模式是面向代码的，而安全则是一个架构属性。不过这种视角对于分析代码结构对安全的影响是有用的。
?作为一种分析模式。安全约束条件应该尽可能定义在系统的最高层，也就是说，在应用系统的概念模型层上。例如，我们定义哪些用户拥有什么样的角色，以及他们为了完成任务所需要的权限。一个概念上的、无关实现细节的安全机制，实际上就是分析模式。
需要注意的是，模式通常不宜用来描述安全原则，因为安全原则（例如分权原则）通常过于宽泛。模式应该做的是：把一个确定的解决方案描述好。
四、安全模式的描述
模式通常采用预先定义好内容的模式模板进行描述。我们的安全模式采用了POSA（面向模式的软件架构）的模板。
描述模式时，解决方案的内容应该详细到设计人员可以直接拿来使用的程度。我们倾向于用图这样一种非正规化的描述方式，即使用UML类图来描述静态的信息结构，用时序图来描述主要用例中的动态交互。UML模型非常直观并且可以方便地描述结构化性质。
采用UML方式表示模式，可以方便地使用Java、Smalltalk、C++、XML或C#等语言来实现。把解决方案搞得特别精确或者正式，有悖模式的内在精神：模式应该是建议而非直接可用的解决方案；模式应该根据实际应用的需求进行裁剪和定制。
如果采用一个非常正式的解决方案，就难以知道裁剪定制是否影响到了解决方案的模型。在需要正式解决方案的场合，我们更愿意采用在类图中加入对象约束语言（Object
Constraint Language，简称OCL）注释的方式。
五、安全模式的应用
安全模式最常见的使用场景是帮助（那些不是安全专家的）软件开发人员，增加他们设计的安全性。
安全模式可以作为对系统安全需求的良好描述。需求不应该包含任何实现细节，并且抽象模式定义了概念上的所需要的安全，而不需要关心特定的实现。
抽象安全模式的另一个重要应用是作为安全机制设计者定义产品目标和特性的指南。比如，一个新的XML防火墙的设计者，能够在相关模式中找到设备中与之对应的基本功能，并使用描述安全标准的模式来定义产品对标准的支持。
再一个应用是对现有系统进行评估。这类应用是安全模式在实际中最多的应用。
让复杂的标准可以被理解是另外一个有价值的应用。
安全模式还是讲授安全概念的有用的工具。
六、安全模式的原则
任何方法都应该以基本的原则作为出发点，其中最重要的两条原则是：
安全约束应该定义在具有清晰语义的系统顶层，并向下层传播、由下层实施。
体系架构的所有层次都必须是安全的。
安全模式方法背后的基本思想是基于生命周期的方法：必须将安全原则应用到开发的每一个阶段，并且每个阶段都可以测试是否符合安全原则。当今已经就此观点达成了共识，即安全必须应用在整个软件开发生命周期中：开发进入最后阶段再加入安全的做法，已经被证明是不够的。这意味着，任何开发安全系统的方法，不管是否使用模式，都必须考虑到生命周期的每个阶段。
安全模式必须遵循“安全须从最顶层开始”的安全原则。安全依赖于每个层次，因此必须一开始就加以考虑。我们所理解的生命周期是包含平台的，而不仅仅是应用层的。我们正是在上述原则的指导下使用模式。我们能在系统的各个层次定义模式，这允许设计人员能够确保每个层次都经过安全加固，并使得安全约束从高至低向下传递更加容易。
七、安全模式的示例：基于策略的访问控制
访问控制是网络安全领域广泛应用的重要手段。我们将以一个非常经典的安全模式PBAC（基于策略的访问控制模式，Policy-Based
Access Control）为例，来演示如何运用安全模式来解决现实安全问题。
基于策略的访问控制模式（PBAC）描述了如何依据一个集中的策略池来确定某个主体是否有权限访问某个对象。
01 示例
想象一家为客户提供服务的财务公司。他们的客户可以通过电子邮件或网站来访问公司的计算机系统，进行商品的买卖（如股票、债券、不动产、艺术品等）。该公司雇用的操盘手，根据客户的指令向各类市场发出请求，或者向财务新闻网站咨询相关信息。一个政府审计官员定期造访，检查他们的行为是否符合相关法律法规。
上述全部的活动都由公司内的各类策略进行规范。比如：
支付部门可以有这样的规则“只有状态处于良好的注册用户，才可以发送订单”；
技术部门可以决定“电子邮件的附件如果超过XX兆大小，则不会被发送”；
公司的安全策略可能申明“只有操盘手可以访问市场的Web服务”和“只有操盘手或委托人可以访问他们的交易信息”；
法务部门可以指定如下规则“审计官员可以访问全部的交易信息”；
凡此种种，不一而足。
所有这些策略，都是通过公司计算机系统的不同组件（电子邮件服务器、文件服务器、Web服务访问控制组件、财务应用系统等）进行控制的。
这种方法带来几个问题：策略可能由多种语法所描述，而且很难形成在什么情况下应用什么策略的全局观点。更糟的是，两个策略可能是冲突的，没有方法能够清楚地将它们组合起来。总之，这种方法容易出错，并且难以管理。
02 场景抽象
我们针对上述示例，抽象出这样的场景：
设想一个拥有大量资源（对象）的集中式或分布式系统；
大量的主体可能会访问这些对象；
为了控制访问，制定了相关规则；
规则通常是由不同的成员（技术的、组织的、法律的等）来制定的；
不同策略制定者所制定的规则之间可能会有重叠。
03 问题
在一次特定的访问请求中执行如此多的规则是非常复杂的，因此容易产生错误，因为没有一个清楚的视角来说明哪些规则将被应用到此次请求中。
我们如何才能按照预先定义好的规则，前后一致地来执行访问控制呢？这个问题的解决方案要满足以下条件：
可能会频繁地添加或删除对象。
解决方案要能实现多种访问控制模型，比如访问矩阵、基于角色的访问控制（RBAC）等。
怀有恶意的用户，可能会在没有授权的情况下尝试访问对象。
不应该直接访问对象，每个请求都应该是经过中转处理的。
04 解决方案
大多数访问控制系统都是基于授权模式的，在该模式中主体对对象的访问仅依赖于是否存在一条适用的正向规则。如果没有这样的规则存在，则访问被拒绝。
在我们的场景中，情况就更加复杂了：具有适用的正向规则，并不一定就意味着有访问的权限。所有规则都应该考虑在内，最终的决策应该基于所有适用的规则集和元信息的组合。部分元信息就位于策略对象中。策略对象汇集一组规则，并且指明了这些规则怎样组合在一起。为了更灵活地对规则进行组合，一个复合对象重新将规则分组并打包为策略集。策略集集合了策略，并且包含了如何将不同策略中的规则进行组合的信息。为了能够轻松地选择所有适用的规则，它们应该统一存储在组织中，并能够集中化管理。
在访问时，所有的请求都由策略执行点（PEP）截获，策略执行点属于一种特殊类型的引用监控器。策略池由唯一的、负责计算访问决策的策略决策点（PDP）进行访问。策略决策点和能够提供关于主体或客体的访问信息的策略信息点（PIP）进行协调。规则和策略通过唯一的策略管理点（PAP）进行管理。
最后，因为规则和策略由不同的团队设计，针对的却可能是相同的对象和主体，这样一来就不能保证不同的策略组件之间不发生冲突。在这种情况下，策略决策点可以用动态策略冲突化解器去解决冲突，这可能需要用到元规则。一个互补的静态策略冲突检测可以是策略管理点的一部分，而且可以在规则进入策略池时进行检测。
05 方案结构（静态视图）
下图说明了这个解决方案。图中的符号含义可参见本文附录（UML类图和时序图）。
图1-PBAC（基于策略的访问控制）安全模式的类图
“主体”（Subject）对特定对象的访问请求被“策略执行点”（PEP）截获。“策略执行点”是安全架构的组成部分，负责在本次访问中执行组织的“策略”。
“策略执行点”请求安全架构的另一个部分“策略决策点”（PDP），由“策略决策点”来负责生成访问决策。
为了计算出决策，“策略决策点”使用“策略信息点”（PIP）提供的信息，并从系统中唯一的“策略池”（PolicyRepository）取回一个适用的“策略”。
“策略池”中包含了全部的“策略规则”（PolicyRule）。“策略池”也负责获取适用的规则，获取原则主要是选择“主体描述符”（Subject-Descriptor）、“对象描述符”（ObjectDescriptor）、“环境描述符”（Environment
Descriptor）与“策略信息点”提供的主体、对象、环境信息相匹配，并且其“访问类型”（accesstype）和请求的“访问类型”一致的规则。
“策略管理点”（PAP）是唯一管理这些规则的地方。如果“策略”的评价和适用规则之间有冲突，“策略决策点”的一部分——“动态策略冲突化解器”负责做出唯一的访问决策。类似地，“静态策略冲突化解器”可以作为“策略管理点”的一个补充，负责检查规则在加入“策略池”时是否有冲突。
06 交互流程（动态视图）
下图展示了一幅时序图，其中描述了最常见的使用实例“请求访问某对象”。图中的符号含义可参见本文附录（UML类图和时序图）。
图2-用例“请求访问某对象”的时序图
“主体”（Subject）访问一个“对象”（Object）的请求被“策略执行点”（PEP）截获，然后“策略执行点”将其转发到“策略决策点”（PDP）。“策略决策点”可以从“策略信息点”（PIP）获取到“主体”、“对象”和当前的环境信息。这些信息用来从“策略池”（PolicyRepository）中获取可以适用的规则。
“策略决策点”把规则组合成适用的“策略”，计算组合后的访问决策，并最终将决策返回给“策略执行点”。如果“策略决策点”授权允许访问，“策略执行点”将这个请求转发给“对象”。
07 示例问题的解决
使用PBAC（基于策略的访问控制）安全模式，可以让公司集中地管理规则。
现在，支付部门、技术部门、法务部门、公司管理部门能够将他们的规则以同样的格式，放进同一个策略池中。计算机系统中用来直接执行策略的不同组件（比如电子邮件服务器、文件服务器、Web服务访问控制组件、财务应用）仅需要截获这个请求，并将它们重定向到集中的策略决策点。为了做到这点，这些系统有各自的策略执行点，这些执行点再通过接口与主策略决策点相连。
规则可以按照下述方式进行分组：唯一的公司策略集可能包含所有其他的策略并且遵守下述事实：所有来自公司管理层的策略应该高于其他策略。每个部门都有各自的策略，策略由部门的规则构成，根据各部门的要求组合在一起。
最后，一个简单的动态冲突化解器可以在发生冲突时用来发布一个最终策略。现在可以比较容易地管理规则，因为它们被放在同一个策略池中，冲突也得到化解，并且公司的安全策略也有了一个清晰的视角。
08 小结
基于策略的访问控制（PBAC）安全模式产生了以下效益：
因为访问请求是用标准格式提出的，制定访问决策可以独立于执行访问决策。能支持多种执行机制，并独立于策略决策点，所以可以单独完善改进各执行机制。
该模式可以支持访问矩阵、基于角色的访问控制（RBAC）、访问控制的多级模型等。
因为任何访问都是间接的，因而减少了非法的访问。
PBAC安全模式也面临下述潜在的问题：
可能影响受保护系统的性能，因为集中的策略决策点/策略池/策略信息点子系统可能成为系统的瓶颈。
导致复杂性。
我们要保护访问控制信息。
09 已知应用
PBAC安全模式的已知应用包括：
由OASIS定义的XACML（扩展的访问控制标记语言），使用XML来表达授权规则和采用该模式后的访问决策。
Symlabs的联合身份访问管理系统（Federated Indentity Access Manager
Federation）是一个实现了身份联合管理的身份管理系统。其组件中包含了策略执行点和策略决策点。
基于策略的准入控制组件框架（Components Framework for Policy-Based
Admission Control）作为Internet 2项目的组成部分，是一个用于认证网络组件的框架。它基于5个主要的组成部分：“访问请求”（AR）、“策略执行点”（PEP）、“策略决策点”（PDP）、“策略池”（PR）、“网络检测点”（NDP）。
XML和应用层防火墙也使用这个策略模式。
SAML（安全断言标记语言）是OASIS定义的XML语言标准，用于安全域之间认证和授权数据的交换。SAML可以用来传递授权决策。
10 画图工具
安全模式方法论中使用的两种工具UML类图和时序图，在软件架构设计中广泛使用。图中的符号含义可参见本文附录（UML类图和时序图）。
Visio中的UML类图和UML序列模块，就分别可以绘制这两种图形。
图3-Visio中的UML类图和UML序列模块
八、安全模式有多少
目前为止，业界已经总结了不下两百多种的细分安全模式。
安全模式的分类包括：身份管理模式、身份认证模式、访问控制模式、安全进程管理模式、文件管理模式、安全操作系统架构模式、网络安全模式、Web服务安全模式、Web服务密码学模式、安全中间件模式、云计算架构模式等。
具体的安全模式包括：访问控制列表、包过滤防火墙、应用防火墙、XML防火墙、SAML断言、抽象入侵检测系统、抽象虚拟专用网、对称加密、非对称加密、身份联合、安全经纪人、安全管道、安全黑板、安全企业服务总线、RBAC（基于角色的访问控制）、PBAC（基于策略的访问控制）、ABAC（基于属性的访问控制）、IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）等。
|
