第1章

动机与目标

徒劳地追求安全，只会把我们自己拖垮。

—Dwigbt D.Eisenbower

1.1 为什么需要安全模式

现代应用系统大都是分布式且联网的—通过互联网、局域网或其他专用网络相连，并支持Web界面、Web 服务以及。这类系统的复杂性不仅带来了对其理解、设计和维护上的困难，也导致了漏洞的产生，以及由此所引发的安全攻击。功能强大的移动设备和感应设备的日益广泛使用，使得安全问题愈发突出。全世界每天都有网站或数据库遭受攻击的报道，而由这些攻击造成的直接或间接经济损失高达数百万美元。各类系统持续不断地遭受攻击和入侵，也引发了人们对国家的基础设施可能遭受敌人攻击破坏的担忧。

为何对这些系统的安全加固失败了？一个重要原因是：系统自身的复杂性导致了错误增多以及漏洞难以发现。另一个重要原因是：安全加固是以修修补补的方式进行的，系统各部分虽然都采用了特定的安全措施，却鲜有针对完整系统的整体安全分析。就算有，分析系统各部分所采用的安全模型也不相同，比如数据库用一个模型，无线设备用另一个模型。遗憾的是，想要阻断所有可能的攻击，在安全上就必需采用一种详尽的方法。安全组件再安全，如果没能覆盖到系统的每个角落或者各组件间不协调同步，也无法保障系统整体的安全。威胁分析通常针对系统的各个部分进行，但很多威胁只在系统各部分连通时才会出现。此外，建设安全系统的方法多是针对新建系统的，而大多数在用的系统都是处在不断维护状态中的旧有系统。就算是精心建设的系统也可能遭受"软件架构侵蚀"，即由于产品实现与架构设计出现偏差，从而导致安全防护措施失效或削弱。

我们需要以某种方式应对新系统的复杂性，并以系统性、整体性的方式确保安全。对于旧有系统的安全改造，需要跟踪代码的更改，检测并修正其对安全机制的影响。软件开发人员通常都熟悉特定的开发语言和环境，但对安全知之甚少，这就导致他们的系统中存在大量可被攻击者利用的漏洞。此外他们还面临尽早交付产品的压力。

建设安全的系统应采用系统化的方式，即安全性应当如系统的性和其他系统特性那样，成为软件生命周期中一个不可或缺的组成部分[Fer04b][How06][McG06]。如果在应用软件开发时能够将中间件、操作系统及网络等因素进行整体考虑，我们就能抵御来自内/外部全系列攻击。我们认为，为了开发安全的应用软件，将底层平台和应用软件隔离开分别进行安全设计、而后拼接的方式并不奏效；而应该将应用软件和底层平台一起设计，并使得底层平台和应用软件相匹配。此外，所有安全性和性的约束条件都应在其语义能够被理解的应用层级定义，而后再向体系架构较低的层级传递[Fer99b][Fer06b][Sum97]。

体系架构中较低层级的安全保障来自于上层应用遵循约束条件，换句话说，保障无法绕过这些约束条件。在由众多不同部分所组成的系统中，想要统一提供这种保障，的选择是使用抽象。进一步说，我们可以通过使用"模式"提供这种抽象。模式封装了反复出现的系统问题的解决方案，同时地表述了系统要求和解决方案，也为设计人员提供了相互交流的工具。[Bus96][Gam94]。采用模式的系统架构描述比较容易让人看懂，也为设计和分析提供了指南，还定义了使架构更安全的方法。安全模式使得不具备专业安全知识的应用开发人员也可以使用安全措施。我们还可以通过分析现有系统看它们是否包含特定的模式，进而评估它们的安全性。此外，我们可以在改造旧有系统时，利用模式来添加系统中缺失的安全特性。(下面我会把基于模式的安全建设方法和其他方法做个比较。)

我们需要将一个系统横向、纵向的架构统一起来，具体说就是将系统开发的各个阶段(横向)以及系统架构的各层级(纵向)[Fer11a]统一起来，以运用系统安全建设的整体性方法。本书为读者呈现了一种基于模式的构建安全系统的方法，涵盖纯信息系统和嵌入式系统。我在[Fer06b]中阐述过本书的主要观点，并不断地完善和扩充直至现在。我的长远目标是推广这样的概念："模式可为建立安全、的系统提供行之有效的方法"。Neumann基于坚实的概念方法，提出了"有原则的"系统概念[Neu04]：模式意味着隐式地应用了原则。我已经为达到这个目标做了大量工作，但还需要进一步加以巩固和扩展。[Uzu12c]对基于模式的安全建设方法和其他方法进行了综述。

为了设计一个安全的系统，我们首先需要搞清楚这个系统可能会面临的威胁。我们在[Bra08a]和[Fer06c]中提出了一种识别威胁的方法，即通过分析每个使用案例中的活动来识别威胁。这一方法能够找到来自系统架构较低层级产生的威胁(攻击者的目标)。我们要弄明白体系架构的各特定的组成部分，是如何被攻破的，或者如何被攻击者利用来达到其攻击目标。我们用"滥用"(攻击)模式为系统中真实的滥用建模。

对于标准和规范，需要用一种方法来定义和落实；对此，我们提出的基于模式的方法非常有价值。事实上，一些标准和规范(如HIPAA、FEMA和Sarbanes-Oxley)要么十分复杂，要么有歧义；而采用模式可以地描述它们，使其更容易理解、更易使用。此外，利用模式可以很好地满足Web服务和云计算提出的服务认证需求[Dam09]。

我们所说的"建模"，不是一种新的授权访问模型，而是整合计算机系统里不同设备和单元的安全控制的模型，对于复杂的系统来说这是重要的基础。通过添加各种模式以涵盖系统各层面的威胁，才能获得更的防护，使安全系统整体更接近。我们认为这也是防御可能出现的网络战争的好方法。模式本身不提供可证明的安全性，但对日益复杂的系统来说，安全模式确实很实用。

1.2 基本定义

在开始正式讨论之前，我们先来定义一些基本的术语。安全是指针对下述威胁所进行的防护：

未经授权的数据泄露(机密性或秘密性)

未经授权的数据篡改(完整性)。未经授权的数据篡改会导致产生不一致性或错误数据。数据破坏则会导致各种各样的损失。

拒绝服务：用户或其他系统可能会阻止合法用户使用系统。拒绝服务是针对系统可用性的攻击。

缺乏稽核：用户应对其自身的行为后果负责，并且不能够对他们的所作所为进行抵赖(不可抵赖性)。

上述定义将安全描述为针对某种类型的攻击所采取的防护措施。一般意义上的防护(或称之为反制措施)则包括：

身份标识与认证(I&A)。身份标识指某个用户访问系统时所提供的身份。身份认证指的是提供证据来证明，一个用户或系统与其所声称身份相符。身份认证的结果可能是一组凭据，随后被用作身份的证明，或描述被认证实体的某些属性。身份管理模式和身份认证的模式将分别在第4、5章中进行阐述。

授权与访问控制(A&A)。授权定义了针对某项资源的合法访问，判断合法与否的依据是基于访问者(用户、运行的进程)、被访问的资源以及访问资源的目的。访问控制是保障授权生效所采用的机制。访问控制模式将在第6章进行阐述。

日志与审计。日志和审计指的是记录和安全相关的行为，以供日后进行分析。这可以用来收集用于指控的证据(取证)，并通过分析某次攻击缘何能够成功，进而改进系统的安全性。日志和审计也在第6章进行阐述。

信息隐藏。信息隐藏一般通过密码学实现，使用隐写术则是另一种选择(见第12章)。主要思想是通过隐藏信息来达到保护信息的目的。

入侵检测。入侵检测系统(IDS)在系统遭受攻击时实时地发出警告。第10章讨论有关网络的模式。

本书的目标是建设复杂的应用系统，如医疗系统、财务应用、法律应用、操作系统等。这类应用在实现时，通常选用的系统都会优先考虑一些非功能性的需求，如性容错性等。这些系统往往由多种软硬件单元组成，其中有些是定制的，有些是购买的，有些则是外包的。在这样的系统中，应用软件的安全性与系统其他部分的安全性密不可分。

另一方面，此类系统必须时常与相关的安全监管标准相符。系统中可能包含一些数据库，并且通常有互联网和无线接入。数据通常通过集成了Web和数据库应用软件的Web应用服务器(WAS)进行访问。Web应用服务器通常采用全局企业模型，并使用J2EE或.NET(对企业和任何类型的机构都十分重要)组件实现。在建设这类系统时，要求采用某种系统化的方法来使其达到特定的安全性级别。我们之所以聚焦这类应用，是因为它们代表了我们的模式方法论里最糟糕的应用场景。

[Sum97]及时次以系统化的视角研究了安全，之后出现了衡量安全性的相关标准[cc][DoD83]。再后来，重心转向了软件安全；无数论文强调软件安全的重要性，并给我们造成这样一种印象：我们只需做好软件安全就能建设安全的系统[How03]；现在有大量关于改进代码安全的工作[DeW09]。然而事情没那么简单：整个系统都必须安全，包括硬件和系统配置。为了建设安全的系统，我们需要一种全局的、整体的视角。在讨论特定的题目时一些教科书如[Gol06][Sta12]很有用，但是没有提供全局的视角。多数论文针对特定机制而非系统整体开展研究。在以随机性系统视角研究安全方面，也有人做了大量工作[Nic04]，虽然这种评估方法很有趣，但却没有提供针对系统安全的建设性解决方案。

本书中，我们采取了一种系统化的安全视角，以软件架构作为其重要的基石[Bus07][Tay10]。软件架构提供了对系统的全局视角，但是到目前为止多数研究要么还没有考虑到软件生命周期中的早期阶段，要么就是对安全谈的太多[Fer12a]。不管怎样，从软件架构视角来看待安全十分重要。为了把方法应用起来，我们需要一个好的模式目录：这也是本书的主旨之一。

一个相关的方面是如何利用系统化的方法应用这些模式。我们已经成功地将本书介绍的模式贯穿应用于安全系统的开发方法中，此方法基于对安全机制的分层架构，而架构中的层次定义了每个安全机制适用的范围[Fer04b][Fer06b]。我们将在第3章讨论此方法。