第8章 安全模型、设计和能力的原则

8.1 安全设计原则

系统开发的每个阶段都应该考虑安全问题。

编程人员、开发人员、工程师等应该致力于为自己开发的每个应用构建完备的安全体系，使关键应用和处理敏感信息的应用得到强度更高的安全保护。

重要的是自开发项目早期阶段就周密考虑安全的影响，因为与其给已在运行的系统添加安全措施，不如在系统开发之时就把它们部署进去，这样要容易得多。

开发人员应该根据安全设计原则研究、实施和管理工程进程。

—————————————————————————————————————————

注意：

除了CISSP目标3.1列出的安全设计原则外，还有此类原则的其他常用列表，包括US-CERT列表。

—————————————————————————————————————————

8.1.1 客体和主体

对安全系统中任何资源的访问控制都涉及两个实体。

其中，主体(subject)是发出资源访问请求的主动实体。主体通常是一个用户，但也可能是一个进程、程序、计算机或机构。

客体(object)是主体想要访问的被动实体。客体通常是一个资源，例如一份文件或一台打印机，但也可能是一个用户、进程、程序、计算机或机构。

你要了解主体和客体涉及的各种词语，而不是只知道用户和文件。

访问是主体与客体之间的一种关系，它可能包括读、写、更改、删除、打印、移动、备份以及许多其他操作或活动。

请记住，主体和客体指代的实际实体会因具体访问请求而异。

在一次访问事件中充当客体的实体，到了另一次访问事件中可能会变成主体。

例如，进程A向进程B请求数据。为了满足进程A的请求，进程B必须向进程C请求数据。

在这个例子（见表8.1) 中，进程B是第一个请求的客体，同时是第二个请求的主体。

表8.1 主体和客体

这也是信任传递的一个例子。

信任传递(transitive trust)的概念是：如果A信任B且B信任C, 那么A通过传递属性继承C的信任（见图8.1) 。

这与数学方程类似：如果a=b 且b=c,那么a=c 。

在上例中，当A向B请求数据而B向C请求数据时，A收到的数据其实来自C。

信任传递是一种严重的安全问题，因为它可以使人绕过A与C之间的约束或限制，尤其是当A和C都支持与B交互的时候。

例如，假设一家机构为提高员工工作效率而拦截其对Facebook或YouTube的访问。

因此，员工(A)无法访问某些互联网站点(C)。但是，如果员工能访问Web代理、虚拟专用网(VPN)或匿名服务，就可通过这些手段绕过本地网络限制。

也就是说，如果员工(A)正在访问VPN服务(B)，并且VPN服务(B)可访问被屏蔽的互联网服务(C), A就能利用信任传递漏洞通过B访问C。

图8.1 信任传递

8.1.2 封闭系统和开放系统

系统是根据两种不同的理念设计和构建的。

封闭系统(closed system)经设计只与小范围的其他系统协作，这些系统通常来自同一家制造商。

封闭系统的标准一般是专有的，且通常不会公开。

另一方面，开放系统(open system)在设计上使用公认的行业标准。

开放系统更容易与来自支持相同标准或使用兼容应用编程接口(application programming interface, API)的不同厂商的系统集成。

API是允许在计算元素（如应用程序、服务、网络、固件、硬件等）之间进行的一组定义明确的交互。

API定义了可以提出的请求类型、提出请求的确切方法、交换的数据形式以及其他相关要求（如身份认证和会话加密）。

API使计算元素之间的互操作成为可能。

如果没有API，各计算组件之间将无法直接交互，信息共享也将难以实现。

现代计算和互联网的形成离不开API。

你的智能手机上的应用要靠API与手机的操作系统对话手机的操作系统则要靠API通过电信或Wi-Fi网连接云服务的API，以提交请求和接收回应。

封闭系统更难与相异的系统集成，但这一“特性”会使它们更安全。

封闭系统往往由不符合行业标准的专用硬件和软件组成。

易集成性的缺乏意味若许多针对通用系统组件的攻击要么不起作用，要么必须进行自定义式改变才能成功。

在许多情况下，攻击封闭系统比攻击开放系统更难，因为利用独有的漏洞时必须依靠独有的手段。

要知道，封闭系统中缺乏已知的脆弱组件，此外，攻击者往往还需要更深入地了解特定目标系统才能成功发起攻击。

而开放系统和其他开放系统的集成往往要容易得多。

例如，使用Microsoft Windows Server机、Linux机和Macintosh机很容易就能创建一个局减网(LAN)。

尽管这三种计算机使用不同的操作系统并且可代表三种不同的硬件架构，但是每种架构都支持行业标准和开放API ，因而可以轻松实现联网或（其他）通信。

然而这种互操作性是伴随着代价的。

因为这三种开放系统都采用了标准通信组件，因此存在更多可预见入口点和攻击手段。

一般来说，开放系统的开放性使它们面对攻击时更脆弱，并且它们的广泛存在使攻击者更有可能找到大量潜在目标。

此外，与封闭系统相比，开放系统更受欢迎，且得到了更广泛的部署。

掌握了基本攻击技能的攻击者可找到的开放系统目标远多于封闭系统。

在攻击方式和技巧方面，与开放系统相关的共享经验和知识显然远多于封闭系统。

因此，开放系统的安全性更依赖于安全和防御性编码实践规范，也更依赖于周密的深度防御部署战略（参见第1章）。

—————————————————————————————————————————

开源与闭源

同样重要的一点是记住开源(open source)系统和闭源(closed source)系统之间的区别。

开源解决方案是指源代码和其他内部逻辑向公众公开的解决方案。

闭源解决方案则是指源代码和其他内部逻辑对公众保密的解决方案。

开源解决方案往往依靠公开审查和评议来不断改进产品，而闭源解决方案则更多地依靠供应商/编程人员来不断修改产品。

开源和闭源解决方案都可有价出售或免费提供，但“商用“一词通常意味着闭源。

然而，闭源系统源代码的外泄有时是厂家遭到攻击或有人进行了反编译或拆解的结果。

前者永远涉及违背道德乃至违法的行为，而后者则是道德的逆向工程或系统分析的标准构件。

此外还应注意：

一个闭源程序既可以是开放系统，也可以是封闭系统；

一个开源程序既可以是开放系统，也可以是封闭系统。

这几个词如此近似，因此考试时必须仔细审题。第20章将详细论述开源和其他软件问题。

—————————————————————————————————————————

—————————————————————————————————————————

提示：

CISSP目标3.1列出了11项安全设计原则。

本章涵盖了其中的6个（即默认安全配置、失效安全、保持简单、零信任、通过设计保护隐私、信任但要验证）；

另外5项原则将在其他章节介绍，这些章节更广泛地涵盖了类似的主题，能更好地与这5项原则整合在一起。

有关威胁建模和深度防御，请见第1章；有关最小特权和职责分离，请见笫16章；有关共担责任，请见笫9章。

—————————————————————————————————————————

8.1.3 默认安全配置

你或许听过“默认暴政”(the tyranny of the default)的说法。但是你知道它的真实含义吗？

暴政有好几个定义，但适用于这里的定义是，”由某些外部机构或力量强加的严格条件”（引自美国历史学家Dixon Wecter) 。

许多人认为，初装软件或硬件产品时的设定是最佳设定。

这个结论基于这样的假设：产品的设计者和开发者对产品最了解，因此他们作出的设定可能是最好的。

然而这种假设忽略了这样一个事实：设计者和开发者之所以为产品选择默认安全配置，其实是为了尽量减少安装问题，以免增加技术支持服务的负担。

以大多数设备都有的默认口令为例，这样做可以最大限度地降低首次安装或使用产品时的支持成本。

然而不幸的是，默认设定往往会让攻击者不费吹灰之力就发现并恶意利用设备。

永远都不要假设任何产品的默认安全配置是安全的。

它们往往并不安全，因为默认安全配置可能会妨碍现有业务任务或系统操作。

在任何情况下都要安排系统管理员和公司安全人员依照本机构的安全策略更改产品的默认设定。

除非你的机构聘用了产品的开发人员，否则开发人员是不会专门为机构的产品用途设计代码或选择设定的。

不妨假设产品的默认安全配置对于你的机构来说可能是最糟糕的选择。

因此，你需要逐个检查每项设定，确定各项设定的作用以及需要对设定进行哪些配置，以便在支持业务运行的同时优化系统安全。

幸运的是，目前的默认安全配置正朝着积极的方向发展。

如第1章所述，微软的安全开发生命周期(SDL)有一个名为SD3+C的座右铭，其中包含了“默认安全配置”。

现在的一些产品，尤其是安全产品，可能会在设计上默认启用其最安全的设定。

但是，这种被锁定的产品可启用的功能较少，用户友好度也较低。

因此，它们虽然比较安全，但是对于那些只期望系统正常运行的人来说，默认安全配置可能会成为一个障碍。

如果你本身就是开发人员，那么你有责任为产品的每个配置选项提供详细说明。

你不能假设客户了解产品的一切，尤其是配置设定究竟涉及什么以及每个选项会怎样改变产品的功能、操作、通信等。

你可能必须通过默认安全配置来使产品尽可能易于安装，但是你可以以书面说明书或文件的形式提供一个或多个可以导入或使用的配置选项。

这将于客户从你的产品中获得最大优势，同时把安全风险降至最低。

8.1.4 失效安全

系统故障可由多种原因引起。故障事件发生后，系统或环境对故障的处理方式显得非常重要。

最理想的结果是应用程序安全失效(fail securely)。

故障管理的第一类措施是程序错误处理，也叫异常处理(exception handling)。

这是程序员在预测和防范错误的机制中通过编码来避免程序执行中断的过程。

错误处理包含在代码中，可在错误刚刚出现但并未造成伤害或使执行中断之时尝试纠正错误。

例如，一个得到许多语言支持的机制是“try... catch" 语句。

这个逻辑块语句用于把有可能导致错误的代码放到“try”分支上，然后把发生错误时将被执行的代码放到“catch”分支上。

这类似于“if…then...else" 语句，但“try…catch" 语句的目的是迅速处理错误。

其他机制是为了避免或防止错误，尤其是与用户输入相关的错误。

输入清理、输入过滤或输入验证是用于指代这一概念的部分词语。

这往往包括检查输入的长度，根据有害输入块列表进行过滤和转义元字符。

有关安全编码实践规范的详细论述请见第9章、第15章和第20章。

有几个近似的词语可能会令人困惑，需要你花一些时间去理解。

它们是：软失效(fail-soft)、失效安全(fail-secure)、失效保障(fail-safe)、失效打开（fail-open)和失效关闭(fail-closed)。

我们如果不清楚使用这些词语的语境，则难免会把它们混为一谈。

这里主要涉及两个语境：物理世界和数字环境。

在物理世界，实体主要优先考虑保护人。但在一些情况下，资产却是优先于人得到保护的。

而在数字世界，实体专注于保护资产，但是保护的类型会因CIA三元素而异。

程序之所以可以安全失效，仅仅是因为其设计和编程过程使其能这样。

设计人员在把失效安全性能集成到系统中时，必须针对故障事件的后果做出一些艰难的选择。

首先需要解决的问题是系统是否可以在软失效模式下运行。

软失效(fail-soft) 是指允许系统在一个组件发生故障后继续运行。

该方案不会令一个故障导致整个系统失效。支持大量应用程序同时运行的典型多任务操作系统便是一个例子。

如果一个应用程序发生故障，其他程序通常可以继续运行。

如果软失效这个选项不可行，则设计人员需要从产品类型、部署场景以及故障响应优先级的角度进行考虑。

换句话说，如果产品没有做软失效设计，它发生的故障就是整体故障。

设计/开发人员需要决定：可以接受什么类型的整体故障，以及为了达到预计的失效结果，要保护或者牺牲哪些要素。

必须考虑的因素很多。设计/开发人员需要进行初步判断：产品究竟是影响物理世界的物品（如门锁机制），还是主要针对数字资产的产品（如防火墙）。

如果产品会影响物理世界，则人的生命和安全是需要优先考虑的因素。

这种人类保护优先的设计思路被称为失效保障(fail-safe)。

其背后的理念是，发生故障时，系统、设备或产品将还原到一种保护人员健康和安全的状态。

例如，失效保障太平门在发生紧急情况时会变得很容易打开，以便人员逃离建筑物。

但是这也意味着为了人员安全而牺牲资产保护。

然而，在物理世界的某些情况下，产品在设计上可能会使资产保护优先于人员保护，如银行金库、医学实验室乃至数据中心。

失效安全(fail-secure)系统将资产的物理安全置于任何其他考虑因素之上。

举例来说，银行大楼发生紧急情况时，金库门可能会自动关闭并落锁。

这种资产保护优先的设计会以伤害可能被困在金库里的人员为代价。

显然，物理世界产品的这种优先级设计需要经过慎重考虑才能确定下来。

在物理世界语境下，失效打开与失效保障是同义词，失效关闭与失效安全是同义词。

如果产品主要是数字式的，则安全的焦点将完全在数字资产上。

这意味着设计人员必须从安全三要素（即可用性、保密性和完整性）的角度决定优先保护哪个方面。

如果需要优先考虑保持可用性，那么当产品发生故障时，应当允许继续保持连接或通信。

这就是所谓的失效打开(fail-open)。

如果需要优先考虑保持保密性和完整性，则产品发生故障时，必须切断连接或通信。

这就是所谓的失效安全、失效关闭和失效保障（同样都在数字环境语境下）。

(请注意：IETF建议在讨论纯数字问题时，应避免使用失效保障一词，因为它引入了人类安全的概念，而人类安全在数字语境下不仅不是问题，而且会造成不必要的混淆。）

需要注意的是，当语境从物理世界切换到数字世界时，失效保障的定义会发生变化。

防火墙就是一个例子。防火墙如果被设计成失效打开，发生故障时就会允许通信不经过滤全部通过；

而防火墙如果执行的是失效安全、失效关闭或失效保障设计方案，则发生故障时会切断通信。

失效打开状态以牺牲保密性和完整性为代价来保护可用性，而失效关闭状态则以牺牲可用性来保护保密性和完整性。

遵循失效安全、失效关闭和失效保障规程的数字环境事件的另一个示例是，操作系统遇到处理或内存隔离违规时，会终止所有执行，然后发起重启。

这种机制在Windows中被称为停止错误或蓝屏死机(BSoD) 。

表8.2 归纳了这些词语的使用语境和优先保护对象。

8.1.5 保持简单(keep it simple)

保持简单(keep it simple)是“简单点儿，笨蛋”这句经典话语的缩略转义说法，有时也叫KISS原则。

在安全领域，这个概念鼓励开发人员避免把环境、机构或产品设计得过于复杂。

系统越复杂，保护起来就越难。代码行数越多，全面测试的难度就越大。

零件越多，出错的地方也越多。特性和功能越多，受攻击面就越宽。

许多其他概念也具有相似或相关的侧重点，例如：

"不自我重复"(DRY)

这一理念主张不在多处重复相同的代码，从而消除软件中的冗余，否则在需要更改代码的时候，会增加难度。

计算极简主义

编写代码时使其尽可能少用硬件和软件资源；这也是计划评审技术(PERT)的目的——第20章将讨论这一点。

最低耗能规则

使用适合所需解决方案的最低耗能编程语言。

"更坏的就是更好的"（也叫新泽西风格）

软件的质量不一定随着能力和功能的提高而提升；

比较差的软件状态（即功能较少）往往反而是更好的选项（即更合意的可能更安全）。

"你不需要它" (YAGNI)

程序员应该在真正需要的时候添加能力和功能，所以，与其想起什么就创建什么，不如在真正需要的时候才把它创建出来。

无论系统是指软件程序还是机构的IT安全结构，都很容易陷入越来越复杂的困境。

KISS原则鼓励我们所有人避免过于复杂的方案，而支持简洁、优化的解决方案。

如果解决方案更简单，将更易于保护，更易于排除故障，也更易于验证。

8.1.6 零信任(zero trust)

零信任(zero trust)这一安全概念是指不对机构内部的任何东西自动予以信任。

长期以来，人们一直认为内部的一切都值得信任，而外部的东西不可信。

这导致人们把安全保护的重点放到了端点设备（即用户与公司资源交互的位置）上。

端点设备可能是用户的工作站、平板电脑、智能手机、物联网(IoT)设备、工业控制系统(ICS)、边缘计算传感器或屏蔽子网或外联网中面向公众的任何服务器。

切勿认为在安全的内部与有害的外部之间存在着一条安全边界，这样的想法是不可取的。

内部人员像外部黑客那样破坏安全的事例实在太多，而破坏分子一旦突破安全屏障，就可以在机构内部自由横向移动。

安全边界的概念因移动设备、云和端点设备的激增而变得更加复杂。

就大多数机构而言，内部与外部之间不再有定义明确的界线。

零信任是一种替代性安全方法，是指没有什么东西值得自动信任。

对于每个活动或访问请求，在以其他方式对它们进行验证之前，都要假设它们来自未知和不可信的位置。

这里的理念是“永不信任，始终验证”。任何人和任何事情都有可能是恶意的，因此每个交易都应该接受验证，然后才可以进行。

零信任模型基于“假设违规“，这意味着你永远都应假设已经发生了违反安全规定的情况，并且提出请求的任何人或任何实体都有可能是恶意的。

这样做的目的是在授予资源或资产访问权之前，对每个访问请求进行身份认证、授权和加密。

零信任架构的实施确实涉及传统安全管理概念的重大转变。

这种转变通常要求执行内部微分网段和严格落实最小特权原则。

这种方认可以防止横向移动，因此，即便安全遭到破坏或是有了心怀恶意内部人员，他们在环境内移动的能力也将受到极大的限制。

—————————————————————————————————————————

提示：

微分网段（microsegmentation)把内部网络划分成多个子区域。

每个子区域都用内部分段防火墙(ISFW)、子网或VLAN和其他子区域隔开。

子区域可以小到一台设备，例如高价值服务器，它甚至可以是一台客户端或端点设备。

子区域之间的所有通信都要经过过滤，可能要进行身份认证，通常还会要求给会话加密，并且可能执行允许列表和拦截列表控制。

—————————————————————————————————————————

零信任被用于各种不同的安全解决方案，包括内部分段防火墙(ISFW) 、多因子身份认证(MFA) 、身份和访问管理（IAM）以及下一代端点安全（参见第9章）。

只有执行了持续验证和监控用户活动的措施，安全管理的零信任方法才能取得成功。

如果你采用的是一次性验证机制，则滥用系统的机会依然存在，因为威胁、用户和连接特征始终都在变化。

因此，零信任网络只有在保持对用户活动的实时审查和监控的前提条件下才能发挥效力。

—————————————————————————————————————————

提示：

在有些情况下，可能需要用完全隔离取代控制和过滤交互。

这种隔离可通过气隙实现。

气隙(air gap)是一种网络安全措施，用于确保一个安全系统己和其他系统物理隔离。

气隙意味着有线和无线网络链接都不可用。

—————————————————————————————————————————

为了执行零信任系统机构必须能够并且愿意放弃长期以来已经形成惯性思维的一些安全假设。

首先，我们必须明白，可信来源这种东西是根本不存在的。

默认情况下，任何实体、资产或主体（无论是内部的还是外部的）都是不可信任的。

相反，我们必须假设攻击者就在我们内部，存在于每个系统。

从这个新的“无假设信任“立场看，传统的默认访问控制显然是不充分的。

每一个主体、每一次请求，都需要经过身份认证、授权和加密。

由此可见，我们需要建立一个持续的实时监控系统来查找违规和可疑事件。

当然，即便我们把零信任理念融入IT架构，它也只是集成到整个机构管理流程中的整体安全策略的一个要素而已。

零信任已被NIST SP 800-207“零信任架构“正式确认。

若想了解有关这场安全设计革命的更多信息，请参阅这份文件。

8.1.7 通过设计保护隐私(Privacy by Design, PbD)

通过设计保护隐私(Privacy by Design，PbD)是指这样一条指导原则：

在产品的早期设计阶段就把隐私保护机制集成到产品之中，而不是在产品开发结束之后再尝试添加。

它实际上与“通过设计实现安全”或“集成安全”理念如出一辙（后者是说，安全是产品设计和架构的不可分割元素，自开发启动之初，贯穿整个软件开发生命周期，始终都要保持），它们都属于一种整体概念。

正如Ann Cavoukian在她的论文《通过设计保护隐私——七项基本原则：公平信息处理条例的落实和对照》里所指出的那样，PbD框架基于七大基本原则：

•主动而非被动，预防而非修补

•以默认方式保护隐私

•隐私嵌入式设计

•所有功能——正和而非零和

•端到端安全——全生命周期保护

•可见性和透明性

•尊重用户隐私

PbD的目的是让开发人员把隐私保护集成到他们的解决方案之中，这样可以在初始阶段就避免侵犯个人隐私。

总体概念侧重于预防，而不是事后对违规行为进行补救。

PbD也促使组织把隐私保护融进涵盖整个机构（而不是仅仅针对开发人员）的方案。

业务运营和系统设计还可以把隐私保护集成到核心功能中。

而这反过来又催生了“全球隐私标准”(GPS)，该标准的出台旨在建立一套通用且协调一致的隐私原则。

GPS将被各国用作制定隐私法的指南，被机构用于把隐私保护纳入它们的运营，并被开发人员用于把隐私保护集成进他们开发的产品。

欧盟的《通用数据保护条例》(GDPR)也采用了部分PbD原则（请参见第4章）。

若想了解有关PbD和GPS的详细信息，可查阅前面提到的Cavoukian的论文以及她的另一篇论文《有关通过设计保护隐私的法律、政策和实践》。

有关隐私的更多信息，请参见第4章；有关软件开发安全的更多信息，请参见第20章。

8.1.8 信任但要验证

“信任但要验证“原本是一个谚语，这里关注的是这句话在安全领域的实际应用。

那种自动信任公司安全边界内的主体和设备（即内部实体）的传统安全保护方法就是“信任但要验证“。

这种安全保护方法不仅使组织容易遭受内部人员攻击，而且会使入侵者能在机构的内部系统之间轻松横向移动。

“信任但要验证”的方法往往首先根据初始身份认证流程授予内部“安全“环境访问权，然后依靠各种访问控制方法。

由于现代威胁增长快速且变化无穷，“信任但要验证“安全模型已不能满足要求。

如今，大多数安全专家都建议依照零信任模型设计机构的安全防护。

8.2 用于确保保密性、完整性和可用性的技术

为保证数据的保密性、完整性和可用性(CIA) ，必须确保可访问数据的所有组件都是安全的且行为端正。

软件设计人员采用各种技术来确保程序只能执行被要求的操作而不做其他事情。

尽管以下各节讨论的概念全都与软件程序相关，但它们也常用于各个安全领域。

例如，物理限定可保证对硬件的所有物理访问都会受到控制。

8.2.1 限定(confinement)

软件设计者借助”进程限定“约束程序的动作。

简单来说，进程限定(confinement)使进程只能对某些内存位置和资源进行读和写。

这也就是所谓的沙箱(sandboxing)，即对进程执行最小特权原则。

限定的目的是防止数据被泄露给未经授权的程序、用户或系统。

操作系统或某些其他安全组件不接受非法读/写请求。

如果进程尝试执行超出其授权的操作，该操作将被拒绝。

此外，操作系统还会采取后续行动，例如把违规尝试写进日志。

一般来说，违规的进程会被终止运行。

限定可由操作系统本身执行（例如通过进程隔离和内存保护执行），也可借助一个限定应用程序或服务（如Sandboxie)或者通过虚拟化或管理程序方案（如VMware或Oracle 的VirtualBox)执行。

8.2.2 界限(bound)

系统上运行的每个进程都被分配了一个授权级别。

授权级别告知操作系统该进程可以执行哪些操作。

简单系统中可能只有两个授权级别：用户和内核。

授权级别还告知操作系统应该为一个进程设定怎样的界限。

进程的界限(bound)由一些限制组成，这些限制规定了进程可以访问的内存地址和资源。

界限将进程的活动限定或制约在特定的区域内。

在大多数系统中，这些界限划分出了每个进程使用的内存逻辑区。

而操作系统有责任执行这些逻辑界限并禁止其他进程访问。

更安全的系统可能会要求组织在物理上为进程设置界限。

物理界限要求每个受限进程只能在一个和其他受限进程物理隔离（而不仅仅是逻辑隔离）的内存区域内运行。

给内存划分物理界限时需要付出高昂成本，但是它比逻辑界限更安全。

界限可以充当执行限定的手段。

8.2.3 隔离(isolation)

当一个进程因访问界限的执行而被限定时，它就是在隔离状态下运行。

进程隔离可确保被隔离进程的任何行为只影响与之关联的内存和资源。

隔离(isolation)是用来保护操作环境、操作系统内核以及其他独立应用程序的。

隔离是稳定的操作系统的重要组成部分。

隔离能阻止一个应用访问另一应用的内存或资源，不论访问是善意的还是恶意的。

隔离使软失效环境得以实现，被隔离的进程无论是正常运行还是失效/崩溃，都不会干扰或影响其他进程。

隔离的实现依赖于限制的执行（以设置界限的方式）。第9章将讨论硬件和软件的隔离执行。

限定、界限和隔离这三个概念增加了设计安全程序和操作系统的难度，但它们也使组织有可能实现更安全的系统。

限定 确保活跃进程只能访问特定资源（如内存）。

界限 是对进程的授权限制，使进程只能与规定的资源交互，且只被允许进行特定类型的交互。

隔离 则是通过界限执行限定的手段。

这些概念旨在确保进程不违反预定的资源访问范围，同时确保进程发生任何故障或遭到任何破坏时只会对任何其他进程产生最小影响乃至根本没有影响。

8.2.4 访问控制

为确保系统安全，你应当只允许主体访问得到授权的客体。

访问控制限制主体对客体的访问。访问规则规定了每个主体可以合法访问的客体。

此外，对一个客体而言，一种访问可能合法，但是另一种访问可能就非法了。

访问控制有许多远项可供选择，如自主访问控制、基于角色的访问控制、强制性访问控制等。

有关访问控制的深入讨论，请见第14章。

8.2.5 信任与保证

可信系统(trusted system)是指所有保护机制协同工作，可为许多类型的用户处理敏感数据，同时使计算环境保持稳定、安全的系统。

换句话说，信任是安全机制、功能或能力的体现。

保证(assurance)是指满足安全需求的可信程度。

换句话说保证体现了安全机制在提供安全保护方面有多可靠。

保证必须持续保持、即时更新和反复验证。

如果可信系统经历了已知的变化（好的或坏的例如打上了厂家提供的补丁，或者发生了恶意利用事件）或者系统投入使用已久，则更应该如此。

无论在哪种情况下，都会有某种程度的变化出现。变化是安全的对立面，往往会降低安全性。

因此，变更管理、补丁管理和配置管理对于安全管理至关重要。

保证会因系统的不同而异，往往必须针对单个系统逐一建立。

不过，有些等级或级别的保证适用于类型相同、支持的服务相同或部署的地理位置相同的许多系统。

因此，信任可通过执行特定的安全性能以融入系统，而保证则是对这些安全性能在现实中表现出来的可靠性和实用性做出的评价。

8.3 理解安全模型的基本概念

在信息安全中，模型提供了一种把安全策略形式化的手段。

这些模型可以是抽象的，也可以是直观的，但全都是为了提出一套可供计算机遵守，用于执行构成安全策略的基本安全

概念、进程和规程的明确规则。

安全模型(security model)使设计人员得以把抽象陈述投射到为构建硬件和软件规定了必要算法和数据结构的安全策略中。

因此可以说，安全模型为软件设计人员提供了用来衡量自己的设计和执行方案的参照物。

—————————————————————————————————————————

令牌、能力和标签

有几种不同的方法可用来描述客体的必要安全属性。

安全令牌(token) 是与资源关联的独立客体，描述了资源的安全属性。

令牌可在主体请求访问实际客体之前传达有关客体的安全信息。

在其他执行方案中，各种列表被用来存储多个客体的安全信息。

能力列表(capability list) 为每个受控客体各保存一列安全属性信息。

能力列表尽管没有令牌方式灵活，但通常也能在主体请求访问客体时提供比较快捷的查找。

安全标签(security label)，通常是附着在客体上的一个永久部分。

安全标签一旦设定，往往无法更改。

这种永久性提供了另外一种防篡改保护措施，而这是令牌和能力列表都没有提供的。

—————————————————————————————————————————

你将在以下各节学习几种安全模型；所有模型都阐明了如何把安全保护措施纳入计算机架构和操作系统设计：

•可信计算基

•状态机模型

•信息流模型

•无干扰模型

•获取授予模型

•访问控制矩阵

•Bell-LaPadula 模型

•Biba 模型

•Clark-Wilson 模型

•Brewer and Nash 模型

•Goguen-Meseguer 模型

•Sutherland 模型

•Graham-Denning 模型

•Harrison-Ruzzo-Ullman 模型

—————————————————————————————————————————

如果你正式地学习计算机安全、系统设计或应用程序开发，你可能还会见到更多安全模型，包括：

对象能力模型、Lipner模型、Boebert and Kain完整性模型、两室分隔交换(Karger)模型、Gong的JDK安全模型、Lee-Shockley模型、Jueneman模型等。

不过，本章扩展介绍的模型对于你备考CISSP来说，应该绰绰有余了。

—————————————————————————————————————————

8.3.1 可信计算基(trusted computing base, TCB)

可信计算基(trusted computing base, TCB)设计原则是硬件、软件和控制的集合体，它们协同工作，构成了执行安全策略的可信根基。

TCB是完整信息系统的子集。

它应该尽可能小，以便通过详细分析合理地确保系统符合设计规范和要求。

在安全策略的遵守和执行方面，TCB是系统中唯一一个可以信任的部分。

确保系统在所有情况下都行为恰当，且无论遇到什么事情都遵守安全策略，是TCB组件的责任。

1. 安全边界(security perimeter)

系统的安全边界(security perimeter)是一个假想的边界，可将TCB与系统的其余部分分隔开来（见图8.2) 。

这个边界确保TCB不与计算机系统其余部分发生不安全通信或交互。

TCB若要与系统的其余部分通信，则必须创建安全信道，也叫可信路径(trusted path)。

可信路径是按严格标准建立的一条信道，可在进行必要通信时不将TCB暴露给对安全漏洞的恶意利用。

安全边界还允许使用可信壳(trusted shell)。

可信壳可使主体在不给TCB或主体带来风险的情况下进行命令行操作。

可信壳可防止主体打破隔离影响TCB, 进而防止其他进程闯入可信壳以影响主体。

2. 参考监视器和内核

如图8.2所示，TCB中负责在授权访问请求之前验证对每个资源的访问的部分被称作参考监视器(reference monitor)。

参考监视器位于每个主体和客体之间，在允许任何请求继续进行之前，验证请求主体的凭证是否符合客体访问要求。

参考监视器其实是TCB的访问控制执行者。

无论访问控制是自主的、强制性的、基于角色的或其他什么形式的，参考监视器都根据预期安全模型执行访问控制或授权。

TCB中用于执行参考监视器功能的组件集合被称为安全内核(security kernel)。

所谓参考监视器，是通过在软件和硬件中执行安全内核而被付诸实践的一种概念或理论。

安全内核的目的是启动相关组件来执行参考监视器功能并抵御所有已知攻击。

安全内核协调对资源的所有访问请求，只对那些符合相关系统所用访问规则的请求授权。

8.3.2 状态机模型(state machine model)

状态机模型(state machine model)描述了一个无论处于什么状态都始终安全的系统。

它基于有限状态机(finite state machine, FSM)的计算机科学定义。

FSM将外部输入与内部机器状态结合在一起，为各种复杂系统建模，包括解析器、解码器和解释器。

FSM会在给定一个输入和一个状态的情况下转换到另一个状态并可能产生一个输出。

从数学角度看，下一个状态是当前状态和输入的函数，即，下一个状态＝F（输入，当前状态）。

同样，输出也是输入和当前状态的函数，即，输出＝F（输入，当前状态）。

根据状态机模型，状态(state)是特定时刻的系统快照。

如果一个状态的所有方面都达到安全策略的要求，则可认为这个状态是安全的。

接受输入或产生输出时会发生转换。转换总会产生新的状态，因此也叫状态转换(state transition)。

所有状态转换都必须接受评估。

如果每个可能的状态转换都产生了另一个安全状态，则这个系统可被称为安全状态机(secure state machine)。

安全状态机模型系统总是以一种安全状态启动，在所有转换中保持一种安全状态，并且只允许主体以符合安全策略的安全方式访问资源。

安全状态机模型是许多其他安全模型的基础。

8.3.3 信息流模型(information flow model)

信息流模型(information flow model)专注于控制信息的流动。

信息流模型基于状态机模型。信息流模型不一定只处理信息流动的方向，还可处理信息流动的类型。

信息流模型的设计往往可以在不同安全级别之间防止未经授权、不安全或受限制的信息流（通常被称为多级模型）。

信息可以在相同或不同涉密级别的主体和客体之间流动。

信息流模型允许所有得到授权的信息流通过，同时阻止所有未经授权的信息流。

信息流模型还有另外一个有趣的方面：

当同一对象的两个版本或状态存在于不同时间点的时候，信息流模型可被用来在它们之间建立关系。

因此可以说，信息流表明了一个对象从一个时间点的一种状态到另一时间点的另一状态的转换。

信息流模型还可通过明确排除所有非定义流动路径来解决隐蔽信道问题。

8.3.4 无干扰模型(noninterference model)

无干扰模型(noninterference model)大致基于信息流模型。

不过，无干扰模型关注的并不是信息流，而是较高安全级别主体的动作会对系统状态或较低安全级别主体的动作产生的影响。

从根本上说，主体A（高级别）的动作不应影响主体B（低级别）的动作，甚至不应引起主体B的注意。

如果真的产生了影响，则可能会把主体B置于一种不安全的状态，或者会让人推断出更高涉密级的信息。

这是一种信息泄露，并且暗中创建了隐蔽信道。

因此，无干扰模型的使用可以提供一种防止木马、后门、rootkit等恶意程序造成损害的保护手段。

—————————————————————————————————————————

真实场景-组合理论

同属信息流类的其他几个模型建立在多系统间输入输出关系的概念之上，这就是所谓的组合理论(composition theories)，因为它们解释了一个系统的输出与另一系统的输入有怎样的关系。

组合理论分三种。

•级联(cascading)：一个系统的输入来自另一系统的输出。

•反馈(feedback)：一个系统向另一系统提供输入，由后者进行角色互换（即系统A首先为系统B提供输入，然后系统B 向系统A提供输入）。

•连接(hookup)：一个系统在把输入发送给另一系统的同时还将其发送给了外部实体。

—————————————————————————————————————————

8.3.5 获取－授予模型(take-grant model)

获取-授予模型(take-grant model)用一个定向图（见图8.3)规定应该怎样把权限从一个主体传递给另一个主体或者从一个主体传递给一个客体。

简单来说，拥有授予权的主体(X)可把自已拥有的任何权限授予另一主体(Y)或另一客体(Z)。

同样，拥有获取权的主体(X)可从另一主体(N)处获取权限。

除了这两条主要规则外，获取-授予模型还有一条创建规则和一条移除规则，以便生成或删除权限。

这个模型的要点在于，使用这些规则后，你将能确定何时可以更改系统相关权限，以及什么位置发生了泄露（指无意间分配了权限）。

图8.3 获取授予模型的有向图

获取-授予模型基本上有4条规则。

•获取规则：允许主体获取客体的权限。

•授予规则：允许主体向客体授予权限。

•创建规则：允许主体创建新权限。

•移除规则：允许主体移除自己拥有的权限。

有趣的是，获取和授予规则实际上是一种复制功能。

这一点可以在现代操作系统的继承进程中看出来，例如从一个组继承权限的主体或从一个父文件夹继承ACL值的文件。

两条并非由定向图定义的附加规则（创建和移除）也普遍存在于现代操作系统中。

例如，想要获得一个客体的权限时，不必从已拥有这一权限的用户账户把权限复制出来，而只需要用一个具有创建或分配权限的账户创建——这个账户可以是一个对象的拥有者，也可以是对对象有完全控制权或管理权的主体。

8.3.6 访问问控制矩阵(access control matrix)

访问控制矩阵(access control matrix)是一个由主体和客体组成的表格，标明了每个主体可对每个客体执行的操作或功能。

矩阵的每一列都是依照客体排列的访问控制列表(ACL)。

定密分类排列完毕后，矩阵的每一行都是每个被列主体的能力列表。

ACL与客体关联，列出了每个主体可执行的有效操作。

能力列表则与主体关联，列出了可对矩阵包含的每个客体执行的有效操作。

从管理角度看，如果只用能力列表进行访问控制，无疑会导致一场管理恶梦。

可把主体对每个客体具有的权限的列表保存到每个主体上，从而实现能力列表访问控制法。

能力表可以有效地给每个用户发一个钥匙环，环上串有用户针对安全域内客体所具有的访问权和其他权限。

移除对特定客体的访问权时，必须对每个有权访问该客体的用户（主体）单独进行操作。

因此，管理每个用户账户的访问权，比管理对每个客体的访问权（换言之，通过ACL)要困难得多。

旋转一个访问控制矩阵，便可创建一个能力列表；结果是，列成了主体，行则是来自客体的ACL。

表8.3 所示的访问控制矩阵涉及一个自主访问控制系统。

仅用涉密级别或角色替换主体名称，便可形成一个强制性或基于角色的矩阵。

系统可通过访问控制矩阵快速确定主体请求对客体进行的操作是否得到授权。

表8.3 访问控制矩阵

8.3.7 Bell-LaPadula 模型

美国国防部于20世纪70年代根据其多级安全政策开发了Bell-LaPadula模型。

多级安全政策规定，具有任何级别许可权的主体可以访问该许可权级别或低于该级别的资源。

然而在许可权级别内，也只能按因需可知(need-to-know)原则授予对分隔开的客体的访问权。

Bell-LaPadula 模型在设计上可以防止涉密信息泄露或者被转移到安全性较低的许可权级别。

这一点是通过拦截较低涉密级主体对较高涉密级客体的访问实现的。

Bell-LaPadula模型着重于借助这些限制来保持客体的保密性，但并不涉及客体安全的任何其他方面。

—————————————————————————————————————————

提示：

基于格子的访问控制这类非自主访问控制将由笫13章详细论述。

这里先针对这个主题提供快速预见，因为它是大多数访问控制安全模型的基础。

基于格子的访问控制(lattice-based access control)除在格子中给主体分配一个位置。

所谓格子，即一个多层级安全结构或多级别安全域。

主体只能访问位于最小上界（高于主体格子位置的最近安全标签或定密分类）与最大（即最高）下界（低于主体格子位置的最近安全标答或定密分类）之间的客体。

—————————————————————————————————————————

Bell-LaPadula模型建立在状态机概念和信息流模型之上，还采用了强制性访问控制和基于格子的访问控制概念。

格子的层级由机构的安全策略定义。

这种状态机有三个基本属性。

•简单安全属性(Simple Security Property) 规定主体不可读取更高敏感度级别的信息（不可向上读）。

•*安全属性(*Security Property) 规定主体不可把信息写进较低敏感度级别的客体（不可向下写）。这也被称为限定属性(Confinement Property)。

•自主安全属性(Discretionary Security Property) 规定系统通过一个访问矩阵执行自主访问控制。

头两个属性定义了系统可以转换到哪些状态。其他状态转换是不被允许的。

所有可通过这两条规则访问的状态都是安全状态。

因此，基于Bell-LaPadula模型的系统可以提供状态机模型的安全性（参见图8.4) 。

Bell-LaPadula属性适用于保护数据的保密性。

主体不能读取涉密级别高于主体授权级别的客体。

一个级别上客体的数据在敏感度和涉密级别上高于较低级别客体的数据，因此主体（即不可信的主体）不能把数据从一个级别写进较低级别的客体。

这种操作类似于把一份绝密备忘录粘贴到非涉密文档文件中。

第三个属性执行了主体基于其工作或角色按需访问客体的规则。

图8.4 Bell-LaPadula 模型

—————————————————————————————————————————

注意：

Bell-LaPadula模型有一个例外规定——“可信主体”不受*安全属性约束。

可信主体是指“保证即便可能，也不会违反安全规则传输信息的主体”。

这意味着允许可信主体违反*安全属性执行向下写操作；当需要给有效客体移除安全分类或重新定密时，这个机制是必要的。

—————————————————————————————————————————

Bell-LaPadula模型是在20世纪70年代被设计出来的，因此它不支持目前常见的许多操作，如文件共享和网络连接。

这个模型还假设各安全层之间的转换是安全的，而且没有涉及隐蔽信道的问题（参见第9章）。

8.3.8 Biba模型

Biba模型是在Bell-LaPadula模型之后被设计出来的，但它侧重的是完整性问题。

Biba模型也建立在状态机概念上，基于信息流，而且是一个多级模型。

实际上，Biba模型是一个反向Bell-LaPadula模型。

以下是Biba模型的属性。

•简单完整性属性(Simple Integrity Property)规定主体不能读取较低完整性级别的客体（不可向下读）。

•＊完整性属性(*Integrity Property)规定主体不能修改较高完整性级别的对象（不可向上写）。

—————————————————————————————————————————

注意：

在Biba和Bell-LaPadula模型中，有两个属性是相反的：简单属性和＊（星）属性。

但是它们也可以贴上公理、原则或规则的标签。你要着重掌握简单属性和星属性的具体指向。

请注意，简单属性总是涉及读，而星属性总是涉及写。

在这两种模型下，规则都定义了什么不可做或什么不应该做。

多数情况下，未被阻止或禁止的就是被允许的。

因此，只要规则没有明确规定，就表明方向相反的操作是隐含被允许的。

在考试中，有关属性定义或含义的考题的最佳答案是否定陈述，但如果考题中没有这样的选项，那么相反的隐含操作将是次好的答案。

—————————————————————————————————————————

图8.5 说明了Biba 模型的这些属性。

下面来看一下Biba模型的属性。

Biba模型的第二个属性简明易懂。

主体不能对位于较高完整性级别的客体进行写操作。

这一点言之有理。但是第一个属性呢？为什么主体不能读位于较低完整性级别的客体？对于这个问题，我们要作一番思考。

不妨把完整性级别看作空气纯度级别。

你当然不会把吸烟区的空气泵入环境清新的房间。这同样适用于数据。

当完整性是重要要求时，你不会打算把未经验证的数据读入经过验证的文档。

数据被污染的可能且极大，因此这种访问不被允许。

Biba模型在设计上解决了三个完整性问题：

•防止未经授权的主体修改客体。

•防止授权主体对客体进行未经授权的修改。

•保护内部和外部客体的一致性。

Biba模型要求所有主体和客体都被贴上定密分类标签（它始终是美国国防部推导的一个安全模型）。

因此，数据完整性保护由数据定密分类决定。

Biba模型受到的批评揭示了它的几个缺点：

•它只解决了完整性问题，而不涉及保密性或可用性。

•它专注于使客体免受外部威胁侵扰，但是假定内部威胁会以程序化方式被处理。

•它没有涉及访问控制管理，也没有提供分配或更改客体或主体定密级别的方式。

•它不能阻止隐蔽信道。

Bell-LaPadula和Biba模型的属性确实很难记忆，但是这里有一条捷径。

如果你能记住图8.6中虚线以上部分的图形布局也就不难弄清其余部分了。

请注意，图中左边是Bell-LaPadula模型，右边是Biba模型，每个模型的安全优势被列在模型名称下方。

此图上半部分只列出了Bell-LaPadula模型的简单属性。

这个属性是“不可向上读“，由向上的箭头表示，这个箭头被画了一个叉并用“S”代表简单，用“R" 代表读。

从这里开始，所有其他规则都是“S-R"对的相反元素或反转元素。

记住最上面的这部分图形后，当你参加考试时，可在考场提供的擦写板上把它画出来。

接下来，你便可以快速创建其他规则了。

首先，在Bell-LaPadula下画一个向下的箭头，给它画一个叉，然后做出标记，用“*”代表星，用“W" 代表写。

于是，你就有了“不可向下写“星属性。接着，你可以给这两个方向相反的属性画上虚线箭头，表明被隐含允许的相反方向。

然后，你把Bell-LaPadula的这4个箭头底朝上完全翻转过来，便可创建Biba的规则了。

结果应该如图8.6虚线以下的那部分图形所示。

图8.6 辅助记忆Bell-LaPadula和Biba模型

8.3.9 Clark-Wilson 模型

Clark-Wilson模型通过一种涉及诸多方面的方法实现数据的完整性。

Clark-Wilson模型没有定义正式状态机，而是定义了每个数据项并且只允许通过一个受限或受控中间程序或接口进行修改。

Clark-Wilson模型不要求使用格子结构，而是采用一个名为三元组或访问控制三元组(access control triplet) 的主体/程序/客体（或主体/交易/客体）的三方关系。

主体无法直接访问客体，只能通过程序访问客体。

Clark-Wilson模型借助组织完善的事务和职责分离两项原则提供了保护完整性的有效手段。

组织完善的事务采用程序形式。

主体只能通过程序、接口或访问门户访问客体（见图8.7) 。

每个程序对客体（如数据库或其他资源）可以做什么和不能做什么都有具体限制。

这有效地限制了主体的能力，称为受约束或受限制接口。

如果程序设计合理，这种三元组关系就能提供保护客体完整性的方法。

图8.7 Clark-Wilson 模型

Clark-Wilson模型定义了以下数据项和规程：

·受约束数据项(constrained data item, CDI) 指完整性受安全模型保护的任何数据项。

•无约束数据项(unconstrained data item, UDI) 指不受安全模型控制的任何数据项。

任何输入但未经验证的数据或任何输出，都属于无约束数据项。

•完整性验证规程(integrity verification procedme, IVP) 指扫描数据项并确认其完整性的规程。

•转换规程(transformation procedure, TP) 指玻允许修改CDI的唯一规程。

通过TP限制对CDI的访问，这一方法构成了Clark-Wilson完整性模型的支柱。

Clark-Wilson模型根据安全标签授予对客体的访问权，但仅通过转换规程和受限接口模型(restricted interface model)授予。

受限接口模型根据基于定密分类的限制提供只涉及主体的授权信息和功能。

一个处于某一涉密级别的主体将只能看到一组数据并只能访问一组功能，而处于不同涉密级别的另一主体将只能看到一组不同的数据并只能访问一组不同的功能。

为了向不同级别或不同类别用户提供不同功能可向所有用户显示所有功能但是禁用未被授权给特定用户的功能，或者只显示授权给特定用户的功能。

通过这些机制，Clark-Wilson模型可确保数据不会被任何未经授权的用户更改。

实际上，Clark-Wilson模型执行了职责分离。Clark-Wilson模型的设计使其成为商业应用的一种通用模型。

—————————————————————————————————————————

提示：

Clark-Wilson模型在设计上通过访问控制三元组来保护数据的完整性。

然而，尽管中间接口经编程可以限制主体对客体的操作，但是接口也可以很容易地通过编程来限制或约束可向主体显示的客体。因此，这个概念本身也适用于保护保密性。在许多情况下，主体和客体之间存在一个中间程序。

如果这个中间程序专注于保护完整性，那它就是在执行Clark-Wilson模型。

如果它专注于保护保密性，则中间程序的这种备选用法将今人受益匪浅。

不过，用访问控制三元组保护保密性的做法似乎还没有自己的模型名称。

—————————————————————————————————————————

8.3.10 Brewer and Nash 模型

创建Brewer and Nash模型是为了让访问控制可以根据用户先前的活动动态地作出改变（这也使其成为一种状态机模型）。

这个模型适用于单个集成的数据库，它寻求创建对利益冲突概念敏感的安全域（例如，如果A和B两家公司互相竞争，那么在C公司工作且有权访问A公司专有数据的人员不应该被允许访问B公司的类似数据）。

该模型创建了一类数据，定义了哪些安全域存在潜在冲突，并阻止有权访问属于特定冲突类别的安全域的任何主体访问属于相同冲突类别的任何其他安全域。

这就好比在任何冲突类别中围绕所有其他信息建起一道墙。

因此，该模型还在每个冲突类别内使用数据隔离原则，从而使用户远离潜在的利益冲突情况（例如公司数据集的管理）。

各公司之间的关系随时都可能发生变化，因此必须动态更新冲突类的成员和定义。

另外，也可从管理员的角度分析或研究Brewer and Nash模型，管理员根据被分配的工作职责和工作任务对系统中涉及面极广的数据拥有完全访问控制权。

然而，在针对任何数据项执行操作的时刻，管理员对任何冲突数据项的访问都会被临时拦截。

在操作过程中，只能访问与初始数据项相关的数据项。任务完成后，管理员的访问权将恢复为完全控制。

8.3.11 Goguen-Meseguer 模型

Goguen-Meseguer模型是一个完整性模型，但不像Biba等其他模型那样有名。

事实上，这个模型被认为是非干涉性概念理论的基础。

通常，当有人说起非干涉性模型时，他们其实指的是Goguen-Meseguer模型。

Goguen-Meseguer模型以主体可访问的预先确定的客体集或域（即一个列表）为基础。

这一模型的根基是自动控制理论和域隔离。这意味着只允许主体对预定客体执行预定操作。

当相似的用户被划分到各自的域（即集合），一个主体域的成员将不能干扰另一个主体域的成员。

因此，主体不能干扰彼此的活动。

8.3.12 Sutherland 模型

Sutherland模型是一个完整性模型，专注于通过防止干扰来支持完整性。

它在形式上基于状态机模型和信息流模型。但是它并没有直接指明保护完整性的具体机制。

相反，这一模型依据的是一种理念：对一组系统状态、初始状态和状态转换给出明确定义。

该模型通过只使用这些被预先定义的安全状态来保持完整性和阻止干扰。

使用Sutherland模型的一个常见例子是：防止隐蔽信道被用来影响进程或活动的结果。

有关隐蔽信道的讨论，请见第9章。

8.3.13 Graham-Denning模型

Graham-Delllling模型专注于主体和客体的安全创建与删除。

Graham-Delllling模型是八条主要保护规则或操作的集合，用于定义某些安全操作的边界。

•安全创建客体。

•安全创建主体。

•安全删除客体。

•安全删除主体。

•安全提供读取访问权。

•安全提供授权访问权。

•安全提供删除访问权。

•安全提供传输访问权。

主体在一组客体上执行某些操作的具体能力或权限通常被定义在一个访问矩阵（也叫访问控制矩阵）中。

8.3.14 Harrison-Ruzzo-Ullman 模型

Harrison-Ruzzo-Ullman(HRU)模型专注于给主体分配客体的访问权限以及这些被分配权限的韧性。

它是Graham-Denning模型的扩展。它以建立一个有限规程集（或访问权限集）为中心利用这些规程编辑或更改主体对客体的访问权限。

HRU下的访问权限状态可用一个矩阵表示，其中行是主体，列是客体（里面还会包含主体，因为主体也可以是客体）。

每行和每列的交集将包含允许每个主体针对每个客体执行的具体规程。

此外，模型还定义了一个有限命令或基元(primitive)集，以便控制授权主体修改矩阵的方式。

这些基元包括给矩阵添加或删除访问权限、主体和客体。

这里还有完整性规则，例如：

给矩阵创建或添加的主体或客体必须是原来并不存在的；

从矩阵中删除的主体或客体必须是已经存在的；

如果一次执行多条命令，则它们必须全部都能成功运行，否则其中任何一条命令都将无法运行。

—————————————————————————————————————————

消除模型中“星”这个词的歧义

当我们论及安全模型时，＂星"(star)这个词会带来一些歧义。

一方面，名为“星模型”的正式安全模型是不存在的。

但是，Bell-LaPadula模型和Biba模型确实具有星形属性，这在本章的相关小节有过讨论。

云安全联盟(CSA)提出了一个与模型无关的“星”计划，即“ 安全信任保障和风险”计划其简称恰恰是STAR。

该计划致力于通过审计、透明度和标准集成来提高云服务提供商(CSP) 的安全性。

此外还有一个与安全无关的Galbraith“ 星模型“，可用来帮助企业组织下属部们和分支机构完成业务任务和实现业务目标，并随着时间的推移不断进行调整，以获得长期生存的能力。

这个模型针对的是企业管理中需要为机构的任务和目标进行管理、平衡和整合的5个主要领域，即战略、结构、流程、奖励和人员。

了解“星”这个词在Bell-LaPadula和Biba模型、CSA的“星”计划以及Galbraith的“星模型”语境下的使用方式，有助于你在不同上下文中见到这个词时辨明它的含义。

—————————————————————————————————————————

8.4 根据系统安全要求挑选控制

为某些类型的应用购买信息系统的用户——例如持有极具价值（或落入坏人之手会非常危险）的敏感信息的国家安全机构，或者持有一些价值数十亿美元的数据的中央银行或证券交易商——在达成交易之前往往要先了解信息系统的安全优势和弱点。

这些买家通常只愿意考虑那些事先经过正式评估并已得到某种安全评级的系统。

安全评估常常由可信的第三方负责进行；

这种测试的最重要结果是表明系统达到所有基本标准的“批准印章“。

8.4.1 通用准则(Common Criteria, CC)

“通用准则”(Common Criteria, CC)定义了测试和确认系统安全能力的各种级别，级别上标注的数字表示执行了哪种测试和确认。

然而，即使是最高CC评级，也不能保证这些系统绝对安全，或者说它们完全不存在可被恶意利用的漏洞或脆弱点——只有认识到这一点，才称得上明智。

“通用准则”被设计成一个动态主观性产品评估模型，用于取代以前的静态系统，例如美国国防部的“可信计算机系统评估准则”(TCSEC)和欧盟的“信息技术安全评估准则”(ITSEC) 。

1998年，来自加拿大、法国、德国、英国和美国的政府机构代表签署了“IT 安全领域通用准则证书认可协议”，使“通用准则”成为一个国际标准。

自那以后，又有23个国家签署了这份协议。

原始协议文件已被正式采纳为一个标准，作为ISO/IEC15408-1、-2、-3发布，主标签为“信息技术——信息安全——IT安全评估准则”。

—————————————————————————————————————————

注意：

IS0/IEC15408目前正在修订（截至2020年秋季，它被标记为ISO/lED 15408-1(-2 or-3):2020)，可能会在本书出版时发布。

—————————————————————————————————————————

“通用准则”指南的目标如下：

•提升购买者对已评估和已评级的IT产品安全性的信心。

•消除重复评估（除了其他方面，这还意味着如果一个国家/地区、一家机构或一个验证组织在评定具体系统和配置时遵循了CC，则其他机构在其他国家/地区就不必重复此项工作）。

•提高安全评估的效率和效果。

•确保IT产品的评估符合一致的高标准。

•推广评估并提高已评估和评级IT产品的可用性。

•评估受评估对象(TOE) 的功能（即系统能够做什么）和保证（即系统的可信程度）。

“通用准则“进程基千两个要素：保护轮廓和安全目标。

保护轮廓(protection profile, PP) 为将接受评估的产品（即受评估对象）规定了安全要求和保护措施，我们可以把这些要求和保护措施视为客户的安全期望或客户“想要的东西”。

安全目标(security targets, ST) 规定了应被供应商纳入受评估对象的安全性能。

我们可以把安全目标视为已经执行的安全措施或供应商“将提供的东西＂。

除了安全目标性能外，供应商还可提供其他安全性能包。

安全性能包是“安全要求”成分的中间分组，既可被添加到受评估对象中，也可从受评估对象中移除（就像购买新车时的选项包）。

这套由保护轮廓和安全目标组成的系统使机构的具体安全功能和保证要求具有灵活性、主观性和可定制性，可应对随时间的推移而发生的变化。

可将机构的保护轮廓与被选中供应商的受评估对象的各种安全目标进行比较。

客户购买的往往是PP与ST最接近或匹配度最好的产品。

客户可以根据已公布或已面市的评估保证级别(evaluation assurance level, EAL)为现有系统初步选出一家供应商。

依照“通用准则“挑选供应商客户将能确切提出产品性能要求，而不必被迫接受静态的固定安全级别。

“通用准则”还许供应商在设计和创建产品时更加灵活。

一套明确定义的“通用准则＂支持主观性和多用性，可以自动适应不断变化的技术和威胁环境。

此外，EAL还提供了一种更加标准化的方法，可用来对供应商的系统进行比较（就像旧的TCSEC那样）。

表8.4 对EAL1~EAL7进行了归纳。有关EAL的元整描述，可参阅CC的标准文件。

表8.4 “通用准则”评估保证级别

尽管“通用准则”指南非常灵活，可以满足大多数安全需要和要求，但它绝非完美。

与其他评估标准一样，CC指南并不能确保用户对数据的操作方式也是安全的。

CC指南也没有解决特定安全范围以外的管理问题。

和其他评估标准一样，CC指南也不包括现场安全评估，也就是说，它们不涉及与人员、机构实践规范和规程或物理安全相关的控制。

同样，CC指南不涉及对电磁辐射的控制，也没有明确规定对密码算法强度进行评级的标准。

尽管如此，CC指南依旧代表了可对系统进行安全评级的部分最佳技术。

—————————————————————————————————————————

提示：

国际标准化组织(ISO)是一个全球标准制定组织。

ISO定义了工业和商业设备、软件、协议和管理等标准。

它有六种主要产物：国际标准、技术报告、技术规范、公开可用规范、技术勘误表和指南。

ISO标准已被许多行业广泛接受，甚至被各国政府用作要求或法律。

—————————————————————————————————————————

8.4.2 操作授权

就许多环境而言，必须得到正式批准才能将有安全保障的设备用于IT操作目的。

这常常被称为操作授权(Authorization To Operate, ATO)。

操作授权是风险管理框架(RMF)定义的一个概念的当前说法（参见第2章），取代了以前使用的“认证”一词。

操作授权是一种正式授权，用于把有安全保证的IT/IS系统集合体投入使用，执行业务任务并接受已识别风险。

操作授权的评估和分配由授权官员(Authorizing Official, AO)负责执行。

授权官员是一个得到授权的实体，可对IT/IS系统、其运行和风险进行评估并可能签发操作授权。

有关授权官员的其他词语还包括：被指定的批准机构(DAA)、批准机构(AA)、安全控制评估员(SCA)和推荐官(RO)。

—————————————————————————————————————————

注意：

NIST有一个不错的词语表可供参考，可登录NIST官网并搜索该表。

—————————————————————————————————————————

操作授权的有效期通常为5年（不过分配的时间期限各异，即便在操作授权签发之后，授权官员还是可以调整时间期限），并且一旦出现以下任意一种情况，就必须重新申请。

•操作授权的时间期限到期。

•系统遭遇严重安全事件。

•系统发生重大安全变化。

授权官员可自主确定哪些安全事件或安全变化会导致操作授权丧失。

一次中度入侵事件或一个重要安全补丁的使用都有可能导致操作授权失效。

授权官员可以作出4种授权决定。

操作授权

当组织对风险的管理达到可接受水平时，授权官员可作出这种决定。

通用控制授权

当安全控制继承自另外一家供应商，而且与通用控制相关的风险处于可接受水平并已从同一位授权官员处得到了操作授权时，授权官员可作出这种决定。

使用授权

当一家第三方供应商（如云服务提供商）提供的IT/IS服务器被认为达到可接受风险水平时，授权官员可作出这种决定；

这一决定还可以用来接受另一授权官员的操作授权。

拒绝授权

当风险不可接受时，授权官员可作出这种决定。

有关风险管理框架和授权的更多信息，请见NIST SP 800-37 Rev.2。

—————————————————————————————————————————

提示：

风险管理框架的操作授权概念取代了以前的认证和认可(C&A)流程。

但是NIST文件依然在一些地方提及C&A, 不过该术语主要出现在比较旧的出版物中，或被标记为C.F.D, 意为＂待删除“。

—————————————————————————————————————————

8.5 理解信息系统的安全能力

信息系统的安全能力包括内存保护、虚拟化、可信平台模块(TPM)、加密/解密、接口和容错。

必须认真评价基础设施的各个方面，以确保基础设施充分支撑安全性。

如果不了解信息系统的安全能力，就无法对它们进行评估，更无法恰当执行它们。

8.5.1 内存保护

内存保护是一个核心安全成分，必须通过设计纳入操作系统并在其中执行。

无沦系统中运行了什么程序，都必须执行内存保护，否则有可能出现系统不稳定、破坏完整性、拒绝服务、数据泄露等诸多情况。

内存保护旨在防止活动进程与并非专门指派或分配给它的内存区域交互。

第9章将专门讨论内存保护，所涉主题包括隔离、虚拟内存、分段、内存管理、保护环以及缓冲区（即内存）溢出保护。

—————————————————————————————————————————

Meltdown 和Spectre（熔毁和幽灵）

2017年底，业界发现了两个重要的内存错误，将它们分别称为Meltdown（熔毁）和Spectre(幽灵）。

这两个问题源自被现代CPU用来预测未来指令以优化性能的方法。

这种方法使处理器似乎可以在实际请求被提出之前对将被检索或处理的代码做出可靠预测。

然而，当预测执行错误时，这个进程不会被完全回退（也就是说，并非每个不正确的预测步骤都会被撤销）。

这可能会导致一些数据残留在内存中并且处于不受保护状态。

未经授权的进程可以利用Meltdown漏洞读取系统内核内存中的隐私数据。

而Spectre漏洞可以让人从其他正在运行的应用程序中批量窃取内存数据。

受这两个漏洞或其中之一影响的处理器多得令人吃惊。

这两个漏洞虽然分属不同问题，但它们几乎是被同时发现和公布的。

现在已有补丁被发布出来，可广泛用于解决现有硬件中的这些问题，未来的处理器应该有内置的机制来防范此类恶意利用。

但是，这些补丁往往会降低系统性能，因此使用补丁时应该格外小心。

有关这些问题的详尽讨论，可收听播客Security Now或观看专题节目第645集(The Speculation Meltdown)、第646集(InSpectre)、第648集(Post Spectre?）和第662集(Spectre NextGen)。

—————————————————————————————————————————

8.5.2 虚拟化

虚拟化技术用于在一台主机的内存中运行一个或多个操作系统，或运行与主机操作系统不兼容的应用程序。

虚拟化是隔离操作系统，测试可疑软件或执行其他安全保护机制的一种工具。有关虚拟化的更多信息，请见第9章。

8.5.3 可信平台模块(Trusted Platform Module, TPM)

可信平台模块(Trusted Platform Module, TPM)既是主板上密码处理器芯片的规范，也是此规范执行方案的称谓。

TPM可用于执行涉及范围很广的基于密码的安全保护机制。

TPM芯片通常用于为硬件支持的或操作系统执行的本地存储设备加密系统存储和处理密码密钥。

硬件安全模块(HSM)就是TPM的一个例子。

HSM是一种密码处理器，用于管理/存储数字加密密钥，提升密码运算的速度，支持速度更快的数字签名以及改进身份认证。

HSM可以是主板上的一块芯片，也可以是一张扩展卡（插在路由器、防火墙或机架式刀片服务器上使用）。

HSM包含防篡改保护机制，即便HSM被攻击者物理访问，也不可能被他们滥用。

8.5.4 接口

受约束或受限制接口(constrained or restricted interface)在应用程序内执行，旨在使用户只能按自己的权限执行操作或查看数据。

拥有完全权限的用户可以访问应用程序的所有功能，而只拥有有限权限的用户只能进行有限的访问。

应用程序可借助多种方法约束接口，其中一种常用方法是把用户无权使用的功能隐藏起来。

管理员可通过菜单或右键点击某一项目来使用命令，但对于没有权限的普通用户，命令不会显示出来。

有时命令虽然也会被显示出来，但却是灰色或被禁用的。普通用户可以看到但无法使用。

受约束接口旨在限制或制约得到授权和未经授权用户的操作。

这种接口的使用是Clark-Wilson安全模型的一种实际执行方式。

8.5.5 容错(fault tolerance)

容错(fault tolerance)是指系统虽然发生故障，但仍能继续运行的能力。

为了实现容错，需要添加冗余组件，例如给廉价磁盘冗余阵列(RAID)添加硬盘，或给故障转移集群配置添加服务器。

容错是安全设计的基本要素，也被认为是避免单点故障和执行冗余的部分措施。

有关容错、冗余服务器、RAID和容灾切换解决方案的详细信息，请参见第18章。

8.5.6 加密/解密

加密是指把明文转换成密文的过程，而解密是加密过程的反向过程。

加密和解密的对称和非对称方法可用来支持涉及面很广的保护保密性和完整性的安全解决方案。

有关密码学的完整论述，请见第6章和第7章。