第20章软件开发安全

HeLLo_a119

已于 2023-12-29 16:07:56 修改

阅读量1.4k

点赞数 1

分类专栏： # OSG8 文章标签：安全网络

于 2023-01-30 13:47:21 首次发布

本文链接：https://blog.csdn.net/HeLLo_a119/article/details/128800913

版权

OSG8 专栏收录该内容

21 篇文章 2 订阅

订阅专栏

20.1 系统开发控制概述

20.1.1 软件开发

在系统开发的每个阶段都应当考虑安全性。

在软件开发项目的初期，给系统构建安全性往往比向现有系统中添加安全性容易得多，所以在初期就考虑安全性非常重要。

1. 编程语言

• 机器语言：

计算机接受的指令由一长串二进制数字组成，这种使用二进制数字的语言被称为机器语言。

每种CPU芯片都有自己的机器语言，事实上，如果不借助专门软件，人们可能连最简单的机器语言都无法理解。

• 汇编语言：

汇编语言是一种使用助记符来表示CPU指令的语言，但仍然要求人们了解硬件专用的、相对模糊的汇编指令。

此外，汇编语言还要求进行大量乏味的编程工作，将两个数字相加这样简单的任务需要5行或6行汇编代码才能完成。

• 编译型语言：

例如，C、Java和FORTRAN

使用编译型语言时，编程人员使用称为编译器的工具将高级语言转换成在特定操作系统中使用的可执行文件。

可执行文件随后分发给最终用户，最终用户在合适时使用这些文件。一般而言，不能查看或更改可执行文件中的指令。

反编译：

逆向工程领域的专家可以借助反编译器来逆向编译过程。

这在试图确定可执行文件在执行恶意软件分析或竞争情报时如何工作，尤其是在你无法访问底层源代码时特别有用。

• 解释型语言：

例如，Python、R、JavaScript 和VBScript

使用这些语言时，编程人员会分发源代码，源代码中包含用高级语言编写的指令。

最终用户在系统中用解释器来执行这些代码。用户能够查看编程人员编写的原始指令。

每种方式的安全性优点和缺点：

编译型语言：

优点——编译后的代码通常不易被第三方操纵。

缺点——最终用户也无法查看原始指令，所以恶意的（或不熟练的）编程人员很容易在编译后的代码中嵌入后门和其他安全缺陷并绕过检测。

解释型语言：

优点——编程人员不易在解释型代码中插入恶意代码，因为最终用户可以查看源代码并检查代码的准确性。

缺点——接触软件的任何人都能修改原始指令，并可能在解释型软件中嵌入恶意代码。

编译代码的安全风险比解释代码的安全风险要高，因为恶意代码可以嵌入在编译代码中并且很难被检测到。

解释代码源代码直接看得到。

JAVA是（）

1.架构独立的

2.分布式的

3.多线程的

4.面向对象的

2. 面向对象编程（Object Oriented Programming，OOP）

许多现代编程语言（例如，C++、Java 和.NET 语言）都支持面向对象编程(OOP)的概念。

较早的编程风格（例如，函数式编程）关注程序流本身，并且试图将希望的行为设计为一系列步骤。

面向对象编程则关注交互所涉及的对象。可将这些对象视为被请求执行特定操作或显示特定行为的一组对象。

对象一起工作，从而提供系统的功能或能力。

OOP可能更可靠，也一定程度上减少程序变化错误的传播。

作为一种编程方法，OOP更适合建模或模拟现实生活。

例如，某个银行业务程序可能有三个对象类，这三个对象类分别对应于账户、账户所有人和员工。

在系统中添加一个新账户时，就会创建适当对象的一个新实例或副本，这个实例或副本包含新账户的详细信息。

在OOP 模型中，每个对象都有对应其特定操作的方法。例如，账户对象可以包括增加资金、扣除资金、关闭账户和转移所有权的方法。

对象也可以是其他对象的子类，并且继承父类的方法。例如，账户对象可能有相关特定账户类型的子类，如储蓄、检查、抵押和汽车贷款。

子类可使用父类的方法，也可拥有自己的方法。比如，检查对象可能有一个方法名叫write_ check(），而其他子类则没有。

从安全的角度看，面向对象编桯提供了一个抽象的黑盒。

用户只需要知道对象的接口细节（通常关于每个对象方法的输入、输出和动作），但不一定需要知道对象内部如何有效地使用它们来工作。

为提供面向对象系统要求的特性，对象会被封装（独立的），只能通过特定消息访问（换句话说就是输入）它们。

对象也可表现出替换的属性，允许不同对象提供兼容操作来彼此替换。

常见的面向对象编程术语：

消息，是对象的通信或输入。

方法，是定义对象执行响应消息操作的内部代码。

行为，由对象呈现的结果或输出是一种行为。行为是通过方法处理消息的结果。

类，定义对象行为的一组对象的公共方法的集合就是类。

实例，对象是包含对象方法的类的实例或例子。

继承，某个类（父类或超类）的方法被另一个子类继承时就会出现继承性。

委托，某个对象将请求转发给另一个对象或委托对象。如果某个对象没有处理特定消息的方法，就需要委托。

多态性，当外部条件变化时允许以不同的行为响应相同的消息或方法。

内聚，内聚描述相同类中方法目的之间关系的强度。

耦合，耦合是对象之间的交互级别。低耦合意味着较少的交互。

好的编程实践：高内聚、低耦合

低耦合：因为对象更独立，所以低耦合提供了更优的软件设计。低耦合更易于检测故障和更新。

高内聚：内聚程度较低的对象需要大量来自其他对象的帮助才能完成任务，并且具有高耦合的特点。

3. 保证

确保在新应用程序中构建的安全控制机制在系统的整个生命周期内能正确地实现安全策略。

保证过程只是据此在系统生命周期内构建信任的正规过程。

通用标准(CC)，提供了一种标准化的方法，用于为政府采购提供保证。

4. 避免和缓解系统故障

避免故障的方法：极限检查和创建故障防护或应急开放过程。

（1）输入验证

输入验证核实用户输入的值是否匹配程序员的期望，之后才允许进一步处理。

这种类型的输入验证，通过代码检测确保数字落在一个可接受的范围，被称为限制检测。

1.输入验证也可检测异常字符，如文本字段中的引号，这可能是攻击的前兆。

2.换码输入：输入验证程序可改变输入，移除风险特征序列，并用安全的值来替换。

（2）身份验证与会话管理

许多应用程序，特别是Web 应用，要求用户在访问敏感信息或修改应用程序中的数据之前进行身份验证。

开发人员面临的一个核心安全任务就是确保这些用户通过身份验证，只执行经授权的操作，并自始至终安全地跟踪会话。

应用程序所需的身份验证级别应直接与该应用程序的敏感程度联系起来。

例如，如果应用程序为用户提供对敏感信息的访问或允许用户执行关键业务，则它需要使用多因素身份验证。

大多数情况下，开发人员应设法在应用程序中集成组织现有的身份验证系统。

使用现有的、经过加固的身份验证系统通常比尝试开发用于特定应用的身份验证系统更安全。

如果做不到，也可考虑使用外部开发和验证的身份验证库。

会话管理：

用于Web 会话管理的cookie仅在安全的、加密的信道上传输，并且这些cookie 使用的标识符应该足够长并且随机生成。

会话令牌应在指定的时间段后过期，并要求用户重新认证。

开发人员应禁止任何可公开访问的服务器和应用程序提供详细的错误消息（禁止调试模式）。

应用程序应该被配置成将错误和其他安全事件的详细日志记录发送到集中日志存储库。

OWASP 安全编码准则建议记录以下事件：

• 输入验证失败

• 认证尝试，尤其是失败的

• 访问控制失败

• 篡改尝试

• 使用无效或过期的会话令牌

• 操作系统或应用程序引发的异常

• 管理特权的使用

• 传输层安全(TLS)故障

• 加密错误

为系统故障做计划时有两个基本选择：

• 故障防护(fail-secure)状态，将系统置入高级别安全性（甚至可能完全禁用），直至管理员诊断问题并将系统还原至正常操作状态。

• 应急开放(fail-open)状态，允许用户绕过失败的安全控制，此时用户获得的特权过高。

大多数环境中，因为能够防止对信息和资源的未授权访问，所以故障防护是恰当的故障状态。

软件应当恢复故障防护状况，这意味着只关闭应用程序或停止整个主机系统的操作。

Windows 操作系统中出现的蓝屏(BSOD)就是这种故障响应方式的一个例子，不过实际上它被称为STOP 错误。

尽管操作系统努力防止出现STOP 错误，但是在出现不安全的和非法的活动时仍然会发生STOP 错误。

不安全的和非法的活动可能包括：应用程序直接访问硬件，企图绕过安全控制检查，或者一个进程擅自使用其他进程的内存空间。

一旦出现非法操作，系统环境就不再可信。因此，此时OS 不会继续支持不可靠和不安全的操作环境，而是启动作为安全防护响应的STOP 错误。

一旦出现安全防护操作，编程人员就应当考虑接下来发生的活动。此时，可能的选项是：停留在安全防护状态，或者自动重启系统。

停留在安全防护状态：要求管理员人工重启系统并监督这个过程，通过使用启动密码就可以实施这个动作。

自动重启系统：并不要求人工干预，系统能够自己还原至正常运作状态，但仍存在自身特有的问题。

例如，必须约束系统重启至非特权状态。换句话说，系统重启不应当执行自动登录操作，而是提示用户提供授权的访问凭据。

即使正确设计了安全性并将之嵌入软件，但为了支持更简单安装，所设计的安全性往往会被禁用。

因此IT 管理员负责打开和配置与特定环境需求匹配的安全性是非常普遍的。

如图20.1所示，维护安全性常需要权衡用户友好性与功能性。

此外，如果添加或增加安全性，也会相应地增加成本、增加行政管理开销并降低生产率／吞吐量。

20.1.2 系统开发生命周期

如果在系统或应用程序的整个生命周期内都进行计划和管理，那么安全性是最有效的。

管理员利用项目管理使项目的开发遵循目标，并且逐步实现整个产品的目的。

通常，项目管理使用生命周期模型进行组织，以便指导开发过程。

使用正规化的生命周期模型有助于确保良好的编程实践以及在产品开发的每个阶段都嵌入安全性。

所有系统开发过程都包含一些活动。

虽然可能名称不尽相同，但是这些核心活动对于开发健全、安全的系统来说都是必不可少的。

下面列出这些活动：

• 概念定义

• 功能需求确定

• 控制规范的开发

• 设计评审

• 代码审查走查

• 用户验收测试

• 维护和变更管理

1. 概念定义

系统开发的概念定义阶段涉及为系统创建基本的概念声明。

概念声明，是由所有利益相关方（开发人员、客户和管理人员）协商的简单声明，规定了项目用途以及系统大体需求。

概念定义是一份非常高级的用途声明，仅包括寥寥几段话。

如果阅读项目的详细总结，那么会看到摘要或简介这种形式的概念声明，它使外行可在短时间内对项目具有高度概括性理解。

在系统开发过程的所有阶段参考概念声明是很有帮助的。

开发过程错综复杂的细节常使项目的最高目标变得模糊不清。

定期阅读概念声明能够帮助开发团队回归初心。

2. 功能需求确定

一旦利益相关方都同意概念声明，那么开发团队就该着手开始功能需求确定过程。

在这个阶段，会列出具体的系统功能，开发人员开始考虑系统的组成部分应当如何互相协作，以便满足功能需求。

这个阶段输出的是功能需求文档，它们列出具体的系统需求。

应该以软件开发人员可理解的方式表达这些需求。

以下是功能需求的三个主要特征：

输入，提供给函数的数据

行为，逻辑描述系统应该采取什么行动作为响应不同的输入

输出，函数提供的数据

与概念声明一样，在进入下一阶段前，确保所有利益相关方都同意功能需求文档是十分重要的。

当功能需求确定过程最终完成时，功能需求文档不应束之高阁，

开发团队在所有阶段都应该不断地参考这份文档，以确保项目正常进行。

在最后的测试和评估阶段，项目管理者应当使用这份文档作为审核清单，确保所有功能需求都得到满足。

3. 控制规范的开发

具有安全意识的组织还会确保从开发伊始就在系统中设计了恰当的控制。

在生命周期模型中，具有控制规范的开发阶段常常是非常有用的。

这个阶段在功能需求开发阶段后不久开始，并往往在设计和审核阶段继续进行。

在控制规范开发过程中，从多个安全角度对系统进行分析是很重要的。

首先，必须在系统中设计恰当的访问控制，确保只有授权用户才能访问系统，并且不允许他们超出授权级别。

其次，系统必须通过使用正确的加密和数据保护技术来保护关键数据的保密性。

再次，系统不仅应当提供审计踪迹来强制实施个人的问责性，还应当提供对非法活动的检测机制。

最后，根据系统的重要程度，必须解决可用性和容错问题。

需要记住，将安全性设计到系统中不是一次性过程，必须主动进行。

系统经常在设计时缺乏安全性计划，之后开发人员试图利用正确的安全机制更新系统。

遗憾的是，这些机制慢了一拍，并且没有完全与系统设计集成在一起，这就造成了裂口性安全漏洞。

此外，在每次对设计规范进行重大改动时应当再次参考安全需求。

如果系统的主要组件发生了变化，那么可能也要对安全性需求进行改动。

4. 设计评审

一旦完成功能需求确定和控制规范开发，系统设计人员就可以开始工作了！

在这个漫长过程中，设计人员要确定系统的不同部分如何相互操作以及如何布置模块化的系统结构。

此外，在这个阶段设计管理团队通常为不同的团队设置具体任务，并且布置编码里程碑的初步完成时间。

设计团队完成正式的设计文档后应当与利益相关方召开评审会议，

确保每个人都同意此过程在按部就班地进行，在向着成功开发具有所期望功能的系统的方向迈进。

5. 代码审查走查

一旦利益相关方为软件设计提供了支持，软件开发人员就可开始编写代码。

在编码过程的不同里程碑，项目经理应该安排几次代码审查走查会议。

这些技术性会议通常只涉及开发人员，他们根据特定模块的代码副本进行走查，寻找逻辑问题或其他设计／安全性缺陷。

这些会议有助于确保不同的开发团队都依据规范开发代码。

6. 用户验收测试

在经过多次代码审查和漫长时间之后，就会到达代码编写完成阶段。

经验丰富的软件工程师都知道，系统永远都不可能完成。

现在要进入的是系统测试复审阶段。

最初，大多数组织由开发人员执行系统的初始测试，从而找出一些明显错误。

一旦这个阶段完成代码可能会转到部署。

与任何关键的开发过程一样，保存一份书面测试计划和测试结果是非常重要的，可供将来审查。

7. 维护和变更管理

一旦系统可操作，面对操作、数据处理、存储和环境需求的改变，为确保持续运作，有必要进行多样的维护工作。

拥有一支经验丰富、能处理常规或意外维护任务的支持队伍是必不可少的。

同样重要的是，任何代码的变更都要通过正式的变更管理流程来进行，如第1 章所述。

20.1.3 生命周期模型

1. 瀑布模型（The waterfall model）

瀑布模型最初是由Winston Royce 在1970 年开发的，它试图将系统开发生命周期看作一系列反复活动。

如图20.2 所示，传统的瀑布模型分7 个阶段。

在一个阶段完成后，项目才进入下一个阶段。

瀑布模型的反馈环特征(feedback loop characteristic) ：允许开发者返回到之前的阶段，从而纠正后续阶段发现的错误。

瀑布模型是在考虑返回先前阶段以纠正系统错误的必要性的情况下，建立软件开发过程的模型的第一次全面尝试。

然而，这个模型受到的一个主要批评是：只允许开发人员后退一个阶段。

瀑布模型并没有对开发周期后期发现错误如何处理做出相应规定。

问题：Bob 正在选择一个软件开发生命周期模型，用于他领导的一个项目，以开发一个新的业务应用程序。

他有明确定义的需求，他希望选择一种方法，一开始就强调开发全面的文档。他不需要快速原型或迭代改进。哪种模型最适合这种情况？（瀑布模型）

解析：瀑布模型使用顺序开发软件的方法，在需求和设计的开发和文档编制上花费大量时间。

螺旋和敏捷模型侧重于迭代开发，适用于需求未被很好理解或迭代开发更受青睐的情况。

DevOps 是一种集成开发和运营活动的方法，而不是 SDLC 模型。

2. 螺旋模型（The spiral model）

1988 年，TRW 的Barry Boehm提出了一种替代的生命周期模型，允许瀑布类型处理过程多次反复。

包含了大量开发模型的元模型。因为螺旋模型封装了许多迭代的其他模型（也就是瀑布模型），所以也被称为元模型或“模型的模型”。

图20.3 说明了这种模型。

可以注意到螺旋的每次“回路”都导致新系统原型的开发（在图20.3 中用P1、P2和P3表示）。

理论上，系统开发人员为每个原型的开发应用完整的瀑布处理过程，由此逐渐得到满足所有功能要求（经过全面验证）的成熟系统。

Boehm 的螺旋模型为瀑布模型受到的主要批评提供了一个解决方案，

也就是说，如果技术需求和客户需求发生变化，需要改进系统，允许开发人员回到计划编制阶段。

3. 敏捷软件开发

最近，软件开发的敏捷模型在软件工程界越来越受欢迎。

从20 世纪90 年代中期开始，开发者越来越接受避开过去僵化模式的软件开发方法，喜欢采用替代的、强调客户需求的和快速开发的新功能，并以迭代方式满足这些需求。

我们正在发现更好的方法以开发软件，我们在这样做，也在帮助他人这样做。

通过这项工作，可获得以下价值：

• 个体与交互重于过程和工具

• 有效的软件重于完整的文档

• 客户合作重于合同谈判

• 响应变更重于遵循计划

“敏捷宣言”中所说的12 条原则如下：

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

• 欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程将掌控变化。（欢迎在整个开发过程中不断变化的需求）

• 经常性交付可工作的软件，相隔几星期或一两个月，倾向于采用较短的周期。

• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（围绕有动力的个人构建项目）

• 不论团队内外，传递信息最高效的方式是面对面交谈。

• 可工作的软件是进度的首要度量标准。（最大化未完成的工作量是必不可少的）

• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 以简洁为本，它是极力减少不必要工作量的艺术。

• 最好的架构、需求和设计出自自组织团队。

• 团队定期反思如何能提高成效，并依此调整自身的举止表现。

敏捷开发方法在软件圈里快速发展，并且出现很多变种，包括：

• Scrum（迭代式增量软件开发过程）

• 敏捷统一过程(Agile Unified Process, AUP)

• 动态系统开发模型(Dynamic System Development Model, DSDM)

• 极限编程(Extreme Programming, XP)

4. 软件能力成熟度模型(Software Capability Maturity Model, 缩写为SW-CMM 、CMM 或SCMM)

Carnegie Mellon 大学的软件工程学院(SEI)提出了软件能力成熟度模型, 模型主张所有从事软件开发的组织都依次会经历不同的成熟阶段。

SW-CMM 描述了支持软件过程成熟度的原则与惯例，目的是通过实现从特别混乱的过程到成熟的、有纪律的软件过程的发展路径，帮助软件组织改善软件过程的成熟度和质量。

SW-CMM 背后的思想是软件的质量依赖于其开发过程的质量。

SW-CMM 具有下列阶段：

第1 阶段：初始级，

在这个阶段，常可发现在无组织的工作模式中有很多努力工作的人。

通常，这个阶段几乎或完全没有定义软件开发过程。

第2 阶段：可重复级，

在这个阶段，出现基本的生命周期管理过程。

开始有组织地重用代码，而且类似的项目可以预期具有可重复的结果。

SEI 将用于这个级别的主要处理范围定义为：需求管理、软件项目计划编制、软件项目跟踪和监督、软件转包合同管理、软件质量保证和软件配置管理。

第3 阶段：定义级，

在这个阶段，软件开发人员依照一系列正式的、文档化的软件开发过程进行操作。

所有开发项目都在新的标准化管理模型的制约下进行。

SEI 将用于这个级别的主要处理范围定义为：组织处理中心、组织处理定义、培训计划、综合的软件管理、软件产品工程、团体之间的协调和对等评审。

第4 阶段：管理级，

在这个阶段，软件处理过程的管理进入下一级别。定量衡量用来获得对开发过程的详细了解。

SEI 将用于这个级别的主要处理范围定义为：定量处理管理和软件质量管理。

第5 阶段：优化级，

在优化级的组织中，会采用一个持续改进的过程。成熟的软件开发过程已经确立，

可以确保为了改善未来的结果将一个阶段的反馈返回给前一个阶段。

SEI 将用于这个级别的主要处理范围定义为：缺陷预防、技术更改管理和过程更改管理。

5. IDEAL 模型

SEI 还为软件开发确立了IDEAL 模型，这种模型实现了多个SW-CMM 属性。

IDEAL 模型包括下列5 个阶段：

(1) 启动

在IDEAL 模型的启动阶段，概述更改的业务原因，为举措提供支持，以及准备好恰当的基础设施。

(2) 诊断

在诊断阶段，工程师分析组织的当前状态，并为更改给出一般性建议。

(3) 建立

在建立阶段，组织采用诊断阶段的一般建议，并且开发帮助实现这些更改的具体动作计划。

(4) 行动

在行动阶段，停止“讨论”开始“执行“。组织开发解决方案，随后测试、改进和实现解决方案。

(5) 学习

与任何质量改进过程一样，组织必须不断分析其努力的结果，从而确定是否已实现期望的目标，必要时建议采取新的行动，使组织重返正轨。

IDEAL 模型如图20.4 所示。

20.1.4 甘特图与PERT

甘特图是一种显示不同时间项目和调度之间相互关系的条形图，提供了帮助计划、协调和跟踪项目中特定任务的调度图表。

图20.5 是一个甘特图的示例。

计划评审技术(Program Evaluation Review Technique, PERT)是一种项目调度工具，这种工具被用于在开发中判断软件产品的大小并为风险评估计符标准偏差(Standard Deviation, SD) 。

PERT 将估计的每个组件的最小可能大小、最可能的大小以及最大可能大小联系在一起。

PERT被用于直接改进项目管理和软件编码，从而开发更有效的软件。

随着编程和管理能力得到改善，软件的实际大小应当更小。

20.1.5 变更和配置管理

一旦软件发布到生产环境，必然面临用户要求增加新功能、修正bug 以及对代码的其他更改。

正像组织开发软件的严密过程一样，同样必须以有组织的方式管理所要求的更改。

这些变更必须被集中记录，以支持将来的审计、调直和分析需求。

变更管理流程有三个基本组件：

（1）请求控制

请求控制过程提供了一个有组织的框架，在这个框架内，用户可以请求变更，管理者可以进行成本／效益分析，开发人员可以优化任务。

（2）变更控制

开发人员使用变更控制过程来重新创建用户遭遇的特定情况并分析能进行弥补的适当变更。

变更控制过程也提供了一个有组织的框架。在这个框架内，多个开发人员可在部署到生产环境之前创建和测试某个解决方案。

变更控制包括：遵守质量控制约束，开发用于更新或更改部署的工具，正确记录任何编码变化，以及最小化新代码对安全性的负面影响。

（3）发布控制

一旦完成变更，它们就必须通过发布控制过程进行发布。

发布控制过程中一个必不可少的步骤是：复核并确保更改过程中作为编程辅助设计插入的任何代码（例如，调试代码和／或后门）在软件发布前已被删除。

发布控制还应当包括验收测试，从而确保对终端用户工作任务的任何更改都是可理解的和有用的。

除了更改控制过程之外，安全管理员还应当意识到配置管理的重要性。

配置管理过程用于控制整个组织范围内使用的软件版本，并且正式跟踪和控制对软件配置的更改。

配置管理过程包括下列4 个主要组件：

（1）配置标识

在配置标识过程中，管理员记录整个组织范围内的软件产品的配置。

（2）配置控制

配置控制确保对软件版本的更改要与更改控制和配置管理策略一致。

只有符合这些策略的授权分发才能执行更新操作。

（3）配置状态

统计用于跟踪所有发生的授权更改的正规过程。

（4）配置审计

定期的配置审计能够确保实际的生产环境与统计记录一致，以及确保没有发生未授权的配置变更。

变更控制与配置管理技术一起构成了软件工程体系的重要部分，并且能够防止组织遭遇与开发相关的安全性问题。

20.1.6 DevOps 方法

最近，许多技术专业人士意识到，在软件开发、质量保证和技术操作这些主要的IT 职能之间存在脱节的情况。

这些职能通常配备给不同的人，他们位于组织中不同的单元，通常彼此冲突。

这种冲突导致在创建代码、测试和部署到生产环境中的长时间延迟。

当问题出现时，团队不是一起合作解决问题，而是经常“踢皮球“，这导致官僚作风。

DevOps 方法通过将三种职能集中在一个操作模型中来解决这些问题。

DevOps 这个词是开发(Development)和操作(Operations)的组合，表示这些功能必须合并和合作才能满足业务需求。

图20.6 中的模型说明了软件开发、质量保证和IT操作之间的重叠。

DevOps 模型与敏捷开发方法紧密配合，旨在大幅缩短开发、测试和部署软件所需的时间。

传统方法常常导致主要软件很少部署，或许以年计，但是使用DevOps 模型的组织通常每天可以多次部署代码。

一些组织甚至努力实现连续部署的目标，每天部署几十甚至多达几百次。

DevOps 方法，旨在将软件开发、运营和质量保证整合到一个有凝聚力的努力中。

它特别试图通过在IT团队成员之间建立协作关系来消除“把问题抛给别人”的问题。

DevOps 方法旨在将软件开发、运营和质量保证以一种无缝的方法集成，从而在三个学科之间建立协作。

20.1.7 应用编程接口（API）

尽管早期的Web 应用程序通常是处理用户请求和提供输出的独立系统但现代Web 应用越来越复杂，它们通常包括多个Web 服务之间的交互。

例如，一个零售网站可能利用一个外部信用卡处理服务，允许用户在社交媒体上分享他们的购买信息，与运输供应网站集成，并在其他网站上提供推广计划。

为使这些跨站点功能正确工作，网站必须相互交互。许多组织为了这个目标提供应用编程接口(API) 。

API 允许应用程序开发人员绕过传统的网页，并通过函数调用直接与底层服务进行交互。

例如，一个社交媒体API 可能包括以下一些API 函数调用：

• 发布状态

• 关注用户

• 取消关注的用户

• 喜欢／喜爱的发布

提供和使用API 为服务提供商创造了巨大机会，但也带来了一些安全风险。

开发人员必须意识到这些挑战，并在创建和使用API 时解决这些挑战。

首先，开发人员必须考虑身份验证要求。

一些API，比如允许检查天气预报或产品库存的API，可以向公众提供，不需要任何身份验证就可使用。

其他API，例如那些允许修改信息、下订单或访问敏感信息的API，则只限于特定用户并且依赖安全身份验证。

API 开发人员必须知道何时需要身份验证，并确保验证每个API 调用的凭据和授权。

这种身份验证通常通过为授权的API 用户提供一个复杂API 密钥来完成。

后端系统在处理请求之前验证此密钥，确保进行请求的系统被授权进行特定的API 调用。

API 也必须彻底测试安全缺陷，就像任何Web 应用程序一样。

20.1.8 软件测试

作为开发过程的一部分，组织在内部分发（或市场发布）软件前应当对其进行彻底测试。

进行测试的最佳时间是设计模块时。

换句话说，用于测试某个产品的机制和用于测试该产品的数据集应当与产品本身同时进行设计。

开发团队应当开发特殊的数据测试组以及预先知道正确的输出结果，通过这些数据测试组能够测试软件所有可能的执行路径。

合理性检查：确保匹配的符合指定指标的返回值在合理范围内。

例如，一个程序计算一个人的最佳体重，返回612 磅，这肯定是一次失败的合理性检查！

此外，在进行软件测试时，应该测试软件产品如何处理正常和有效的输入数据、不正确的类型、越界值以及其他界限和／或条件。

实际工作量可能提供最佳的压力测试。

但是，因为一个缺陷或错误会导致违背测试数据的完整性或保密性，

所以不应该使用真实的或实际的生产数据进行测试，在早期开发阶段尤其如此。

测试软件时，应当指定开发人员以外的人员进行软件测试，从而避免利益冲突，并能保证最后的产品更成功。

在第三方测试软件时，必须确保第三方执行客观的和无偏见的检查。

三种软件测试方法：

（1）白盒测试

白盒测试检查程序的内部逻辑结构并逐行执行代码，从而分析程序是否存在潜在的错误。

（2）黑盒测试

通过提供广泛的输入场景并查看输出，黑盒测试从用户的角度检查程序。

黑盒测试人员并不访问内部的代码。在提交系统之前进行的最终验收测试就是黑盒测试的常见示例。

（3）灰盒测试

灰盒测试组合上白盒测试和黑盒测试，是一种流行的软件验证方式。

在这种测试方式中，测试人员着手从用户的角度处理软件，分析输入和输出。

测试人员也会访问源代码，并使用源代码来帮助设计测试。

不过，测试人员在测试期间并不分析程序的内部工作原理。

除了评估软件的质量，程序员和安全专业人员应仔细评估软件的安全性，以确保它满足组织的安全要求。

这对于暴露给公众的Web 应用程序尤为关键。

评估应用程序安全性的测试：

（1）静态测试

静态测试通过分析源代码或编译的应用程序来评估软件的安全性，而不必运行软件。

静态分析通常涉及使用自动化工具来检测常见的软件缺陷，如缓冲区溢出。

在成熟的开发环境中，应用程序开发人员可以访问静态分析工具，并在整个设计／构建／测试过程中使用它们。

（2）动态测试

动态测试在运行时(runtime)环境中评估软件的安全性，并且通常是部署由其他人编写的应用程序的组织的唯一选择。

这种情况下，测试人员通常无法访问软件的源代码。

动态测试的常见示例是使用Web 应用程序扫描工具来检测是否存在跨站脚本、SQL 注入或Web 应用中的其他缺陷。

在生产环境下进行动态测试应仔细考虑以避免意外中断服务。

正确实施软件测试是项目开发过程中的一个要素。

通常在商业和内部软件中发现的许多常见错误和疏忽都可以消除。

把测试计划和结果作为系统永久性文档的一部分。

20.1.9 代码仓库

软件开发需要各方共同努力，大型软件项目需要开发团队可以同时承担代码的不同部分。

使情况进一步复杂化的事实是，这些开发者可能分散在世界各地。

代码仓库提供了支持这些协作的几个重要功能。

首先，它们作为开发人员存放源代码的中心存储点。

此外，代码仓库（如GitHub 、Bitbucket 和SomceForge)还提供版本控制、错误跟踪、Web 托管、发布管理和可支持软件开发的通信功能。

代码仓库安全风险：

首先，必须适当控制开发人员对仓库的访问。一些仓库，如支持开源软件开发的仓库，可能允许公众访问。

其他仓库，如托管含有商业机密信息的代码，可能受到更多限制，并限制对授权开发者的访问。

仓库所有者必须仔细设计访问控制，仅允许适当的用户读取和／或写入权限。

20.1.10 服务水平协议(SLA)

服务水平协议是服务提供商和服务供应商都认同的确保组织向内部和／或外部客户提供服务，并保持适当服务水平的一种方法。

对于组织的持续生存能力，把所有的数字电路，应用程序、信息处理系统、数据库或其他关键组件置入SLA 是明智的，也是至关重要的。

SLA中通常涉及以下问题：

• 系统正常运行时间（如总工作时间的百分比）

• 最大连续停机时间（以秒、分钟等为单位）

• 高峰负荷

• 平均负荷

• 责任诊断

• 故障切换时间（若冗余到位）

如果不能维持协议，服务水平协议通常还包括财务和其他合约商讨好的补救措施。

例如，如果关键电路停机超过15分钟，服务提供商免收一周的费用。

20.1.11 软件采购

企业使用的大多数软件都不是自己开发的，而是从供应商那里采购的。

这些软件中的一些被购买并运行在组织管理的服务器上，无论是在内部还是在IaaS（基础设施即服务）环境中。

其他软件是以SaaS（软件即服务）的方式通过Web 浏览器从互联网购买和提供的。

大多数组织根据业务需求和软件可用性，结合使用这些方法。

例如，组织可能以两种方式使用电子邮件服务。

他们可能购买物理或虚拟服务器，然后在上面安装电子邮件软件，如Microsoft Exchange。

这种情况下，组织从Microsoft 购买Exchange许可证，然后安装、配置和管理电子邮件环境。

作为一种替代方案，组织可能会选择把电子邮件完全外包给Google 、Microsoft 或其他供应商。

然后，用户通过他们的Web浏览器或其他工具访问电子邮件，直接与供应商管理的电子邮件服务器进行交互。

这种情况下，组织只负责创建账号和管理某些应用程序级的设置。

任何情况下，都应该关注安全。

当组织购买和配置软件时，安全专业人员必须正确配置软件以满足安全目标。

他们还必须关注安全公告和补丁，及时修复新发现的漏洞。不履行这些义务可能导致不安全的环境。

在SaaS 环境中，大多数安全责任由供应商承担，但组织的安全人员也不能逃脱责任。

虽然他们可能不负责同样多的配置，但他们现在负责监控供应商的安全。

这可能包括审计、评估、漏洞扫描和旨在验证供应商是否保持适当控制的其他措施。

组织可能还保留全部或部分法律责任，这取决于法规的性质以及与服务提供者的协议。

20.2 创建数据库和数据仓储

现在的公司几乎都有一些数据库，它们包含运营的关键信息，例如用户的联系信息、订单跟踪数据、人事和福利信息或一些敏感的商业秘密。

这样的数据库一般都包含属于用户隐私的个人信息，如信用卡使用记录、旅行习惯、购物和电话记录。

由于对数据库系统依赖程度日益增加，信息安全专家必须确保其具备适当的安全控制，从而保护数据免受未授权的访问、篡改或破坏。

20.2.1 数据库管理系统的体系结构

尽管目前存在多种数据库管理系统(DBMS) ，但大多数系统都使用一种称为关系型数据库管理系统(RDBMS)的技术。

因此，下面的内容主要关注关系数据库。

两个重要的DBMS 体系结构：层次式数据库和分布式数据库。

关系型数据库基础的数据表为二维表

在关系型数据库中，数据表又被称为：关系（relation），列：字段或属性，行：记录或元组

主键（primary key）：在数据表中用于唯一标识一行记录的属性。

外键(foreign key)：用于定义数据表中的某个属性，它的值与另外一张数据表中的主键相关联。

参考完整性对（外键）进行了约束。

实体完整性：要求每一个表中的主键字段都不能为空或者重复的值。

参照完整性：外键值可以是空值，如果不是空值，就必须在相应的外部表中找到主键的对应记录（不能是“悬浮元组”）

范式化(Normalization)：数据库设计的重要组成部分，能提高数据库的完整性。（范式化——去冗余，提高完整性）

范式化程度越高，完整性越好。

第一范式：所有属性都是不可分的基本数据项，简单的说，就是每一个列（属性），不能再分割成多个列（属性）

第二范式：每个表必须有且仅有一个数据元素为主关键字(Primary key),其他数据元素与主关键字一一对应。通常称这种关系为函数依赖(Functional dependence)关系。

去范式化——增加冗余，提高读取速度，但容易破坏完整性（增加处理效率）

1. 层次式和分布式数据库

•层次式数据模型将关联的记录和字段组合为一个逻辑树结构。

这会导致一个“一对多“数据模型，其中的每个节点可能没有子节点，也可能有一个或多个子节点，但每个节点都只有一个父节点。

图20.7说明了一个层次式数据模型。

图20.7 中的层次式数据模型是一家公司的组织结构图。注意，这个示例适用“一对多“数据模型。

某些员工有一名部下，某些员工有多名部下，另外一些员工则没有部下。

然而，每位员工都只有一位经理。层次式数据模型的其他模型包括NCAA的“三月疯“对垒系统以及在互联网上使用的域名系统(DNS)记录的层次化分布。

层次数据库以分层方式存储数据，并且对于适合该模型的专用应用程序是有用的。

•分布式数据模型将数据存储在多个数据库中，不过这些数据库是逻辑连接的。

即使数据库是由通过互联网相互连接的多个部分组成的，用户也仍将数据库理解为单个实体。

每个字段都具有许多子字段和父字段。因此，分布式数据库的数据映射关系是多对多。

2. 关系数据库

关系数据库是由行和列组成的平面二维表。实际上，每个表看起来类似一个电子表格。

行列结构提供一对一数据映射关系。关系数据库的主要构件是表（也被称为关系）。

每个表都包含一组相关的记录。

例如，某个销售数据库可能包含下列表：

• Customers 表，包含组织中所有客户的联系信息。

• Sales Reps 表，包含组织中销售人员的身份信息。

• Orders 表，包含每个用户所下订单的记录。

上述每个数据表都包含多个属性或字段(field) 。

每个属性都对应表中的某个列；如Customers表包含多个列。

每个用户都有自己的记录或元组(Tuple) ，这些记录或元组由表中的某行表示。

关系中行的数量被视为基数(cardinality) ，列的数量被视为度(degree) 。

关系的域(domain)是一组属性可用的允许值。

图20.8 说明了某个关系数据库中Customers 表的示例。

在这个例子中， Customers 表的基数为3（对应于表中的3 行），度为8（对应于表中的8 列）。

在正常业务过程中，例如当销售代表添加新客户时，表的基数会发生变化。

表的度通常不会频繁改变，通常由数据库管理员操作。

定义表之间的关系以标识相关记录。在此例中， Cust9mers 表和Sales Rep 表之间存在关系，

因为每个客户都被分配了一名销售代表，而每个销售代表被分配给一个或多个客户。

此关系由Customers 表中的Sales Rep 字段／列反映，如图20.8 所示。

此列中的值指的是Sales Rep 表中包含的SalesRep ID 字段（未显示）。

此外， Customers 表和Orders 表之间也可能存在关系，因为每个订单必须与客户相关联，并且每个客户与一个或多个产品订单相关联。

Orders 表（未显示）可能包含一个包含客户ID 值的客户字段。

记录可使用多种键进行标识，键是表中字段的子集，可用于唯一标识记录。

在希望相互引用这些信息时，它们还用于连接表。

你应当熟悉下列三种键：

•候选键

可用于唯一标识表中记录的属性子集。

在同一个表中，对于组成一个候选键的所有属性而言，任何两条记录的这些属性值都不完全相同。

每个表都可能有一个或多个候选键，它们从列的头部选出。

•主键

从表候选键中选出的用来唯一标识表中记录的键被称为主键。

每个表只有一个主键，由数据库设计者从候选键中选出。

通过不允许利用相同主键插入多个记录， RDBMS 强制实施了主键的唯一性。

•外键

外键用于强制在两个表之间建立关系（也称为参照完整性）。

参照完整性确保：如果一个表包含一个外键，那么它对应于关系中另一个表内仍然存在的主键。

需要弄清楚的是，没有任何记录／元组／行包含对不存在的记录／元组／行的主键的引用。

图20.8 中的Sales Rep 字段是参照Sales Reps表中主键的外键。

所有关系数据库都使用一种标准语言，即结构化查询语言(SQL) ，从而为用户存储、检索和更改数据，以及管理控制DBMS 提供了一致的接口。

每个DBMS 供应商实现的SQL 版本都会略有不同（如Microsoft 公司的Transact-SQL 和Oracle 公司的PL/SQL) ，但都支持一个核心特性集。

SQL的主要安全特性是其授权的粒度。

SQL允许为每个极细的级别设置许可，可以通过表、行、列，某些情况下甚至用单独的单元来限制用户访问。

SQL为管理员、开发人员和终端用户与数据库交互提供了必需的功能。

事实上，目前流行的图形数据库界面只不过是对DBMS的标准SQL接口进行了修饰。

SQL本身分成两个截然不同的组件：

数据定义语言(DDL) ，允许创建和更改数据库的结构（数据库的结构被称为模式）；

数据操纵语言(DML) ，允许用户与模式内包含的数据交互。

20.2.2 数据库事务

关系数据库支持事务的显式和隐式使用，从而确保数据的完整性。

每个事务都是SQL 指令的离散集，作为一组SQL 指令要么执行成功，要么失败。

事务的一部分成功而另一部分失败的情况不可能出现。

以银行内两个账户之间的转账为例。

使用下面的SQL 代码，可以先在账户1001 中增加250 美元，然后在账户2002 中减少250 美元：

BEGIN TRANSACTION

UPDATE accounts

SET balance= balance+ 250

WHERE account_number = 1001;

UPDATE accounts

SET balance= balance - 250

WHERE account number= 2002

END TRANSACTION

设想一下这两条语句未作为事务的部分被执行而是被分别执行的清况。

如果数据库在第一个事务完成和在第二个事务完成之间的某个时间点出现失败，

那么账户1001 中增加了250 美元，但账户2002 中的资金却没有被减少。

1001 中的250 美元就是凭空多出来的！这个简单例子强调了面向事务操作的重要性。

一个事务成功完成时，这个事务提交给数据库，并且不能取消。

事务的提交可以是显式的，也就是使用SQL 的COMMIT 命令；

也可以是隐式的，也就是成功到达事务结束进行提交。

如果必须中止事务，可显式地使用ROLLBACK 命令进行回滚，也可以是硬件或软件故障引起的隐式回滚。

当一个事务被回滚时，数据库将把自身还原至这个事务开始前的状态。

所有数据库事务都具有4 个必需的特征： ACID 模型

•原子性（Atomicity）

数据库事务必须是原子的，也就是说，必须是“要么全有，要么全无＂的事务。

如果事务的任何一部分失败，整个事务都会被回滚，就像什么也没发生一样。

•一致性(Consistency)

所有事务都必须在与数据库所有规则（例如所有记录都具有唯一的主键）一致的环境中开始操作。

事务结束时，无论事务本身操作期间是否违反了数据库的规则，数据库都必须再次与这些规则保持一致。

其他任何事务都不能利用某个事务执行期间可能产生的任何不一致数据。

•隔离性（Isolation）

隔离性原则要求事务之间彼此独立操作。

如果数据库接收到两个更改同一数据的SQL 事务，那么在允许一个事务更改数据前，另一个事务必须完全结束。

隔离性能够防止一个事务处理另一个事务中途生成的无效数据。

•持久性（Durability）

数据库事务必须是持久的，也就是说一旦被提交给数据库，就会被保留下来。

数据库通过使用备份机制（例如事务日志）确保持久性。

20.2.3 多级数据库的安全性

多级安全性数据库包含大量不同分类级别的信息，它们必须对分配给用户的标签进行验证，并且根据用户的请求提供适当的信息。

要求多级安全性时，管理员和开发人员致力于使数据满足不同安全需求是必不可少的。

将分类级别和”知其所需“需求不同的数据混合在一起被称为数据库污染，这是一个重大的安全风险。

通常，管理员会通过部署可信前端为旧式的或不安全的DBMS 添加多级安全性。

1. 并发性

并发性或编辑控制是一种预防性安全机制，它努力确保存储在数据库中的信息总是正确的，或者至少保护其完整性和可用性。

不论数据库是多级的还是单级的，我们都可使用这个特性。

未能正确实现并发的数据库可能遇到以下问题：

• 当两个不同的进程更新数据库时，如果不知道对方的活动，就会丢失更新。

例如，假设一家商店的库存数据库有多个接收站。该商店目前可能有10 份CISSP 学习指南。

如果两个不同的接收站同时接收CISSP 学习指南的副本，它们都会检查当前的库存水平，

发现它是10, 将其增加1, 更新表后读取的数是11, 但实际值应该为12 。

• 当进程从没有成功提交的事务中读取记录时，会出现脏读取。

返回到我们的商店例子中，如果接收站开始向数据库写入新的库存记录，

但在更新的过程中崩溃，如果事务未完全回滚，则可能会在数据库中留下部分不正确的信息。

并发性使用“锁定”功能允许已授权用户更改数据，并同时拒绝其他用户查看或更改数据元素。

更改完成后，”解锁”功能才允许其他用户执行自己所需的操作。

在某些实例中，管理员会使用具有审计的并发性机制来跟踪文档和／或字段的变化。

检查已记录的数据时，并发性就成为一种检测性控制。

2. 其他安全机制

语义完整性相关的机制，是DBMS 的一种常见安全特性。

语义完整性确保用户的动作不会违反任何结构上的规则。

还会检查存储的所有数据类型都在有效的域范围内，确保只存在逻辑值，并且确认系统遵守所有的唯一性约束。

时间和日期标记，用来维护数据的完整性和可用性。

时间和日期标记常出现在分布式数据库系统中。

在所有更改事务上添加时间标记，然后将这些更改分发或复制至其他数据库成员时，

这些变化会应用于所有成员，但需要按正确的时间顺序实现变化。

细粒度对象控制，改善了安全控制。

内容相关的访问控制就是细粒度对象控制的一个例子。

内容相关的访问控制重点基于要访问对象的内容或有效载荷进行控制。

因为必须在逐个访问对象的基础上做决定，所以内容相关的访问控制增加了处理开销。

细粒度控制的另一种形式是单元抑制。

单元抑制的概念是对单独的数据库字段或单元隐藏或强加更安全的约束。

上下文相关的访问控制，通过宏观评估来制定访问控制决策。

上下文相关的访问控制的重要因素是每个对象、数据包或字段如何与总体的活动或通信相联系。

任何单个元素本身看上去无关紧要，但是在较大的上下文环境中就会表露出是有益的还是有害的。

数据库分区技术，用来防止聚合、推理和污染漏洞。

数据库分区是将单个数据库分解为多个部分的过程，其中每个部分都具有唯一的和不同的安全级别或内容类型。

多实例，常用作针对某些推理攻击的防范措施。

在同一个关系数据库表中，两行或多行具有相同的主键元素，

但若包含在不同分类级别使用的不同数据，就会出现多实例(polyinstantiation)（在数据库的上下文中）。

多实例（Polyinstantiation）：允许一个关系表中存在相同主键的多行记录，用于隐藏数据库中的信息。

相同的主键，通过不同的安全级别去区分。

例子：允许数据库的一张表对未授权用户进行数据隐藏，在这个数据库中，同一张数据表的多行记录可以拥有同样的主键，但每行记录可以通过安全级别进行区分。

问题：
下列哪个选项不是针对 DBMS 安全性的？（C）

A. Perturbation 扰动（插入伪造信息，多实例）

B. Cell suppression 单元抑制（隐藏）

C. Padded cells 填充单元

D. Partitioning 分隔（划分成不同的部分）

例如，一个数据库表中包含正在执行巡逻任务的海军舰艇的位置。

正常清况下，这个数据库包含每艘舰艇的准确位置，这属于秘密级信息。

然而，一艘特殊的舰艇UpToNoGood 正在暗中执行前往绝密位置的任务。

海军指挥官不希望任何人知道这艘舰艇未处于正常的巡逻状态。

如果数据库管理员简单地将UpToNoGood 的位置分类改为绝密，

那么属于秘密级的用户在查不到这艘舰艇的位置时就知道发生了一些不同寻常的事情。

然而，如果采用多实例方法，会在表中插入两条记录。

第一条属于绝密级分类，反映这艘舰艇的实际位置，只对属于绝密安全级的用户可见。

第二条记录属于秘密级，将指出舰艇正在进行例行巡逻，并且向属于秘密安全级的用户显示这一内容。

最后，管理员可利用噪声和干扰在DBMS 中插入错误的或欺骗性的数据，从而重定向或阻挠信息保密性攻击。

这是一个被称为噪声和扰动的概念。使用此技术时必须非常小心，确保插入数据库中的噪声不会影响业务操作。

扰动perturbation：插入伪造信息（多实例）

单元抑制cell suppression：隐藏

分隔partitioning：划分成不同的部分

20.2.4 ODBC

开放数据库互连(ODBC)是一种数据库特性，在不必分别针对交互的每种数据库类型直接进行编程的情况下，允许应用程序与不同类型的数据库通信。

ODBC 扮演了应用程序和后端数据库驱动程序之间代理的角色，使应用程序编程人员能够自由创建解决方案，而不必考虑后端具体的数据库系统。

图20.9 说明了ODBC 与DBMS 之间的关系。

20.2.5 NoSQL

随着数据库技术的发展，许多组织正在远离关系模型，因为他们需要提高速度，又或者他们的数据并不能很好地适应表格形式。

NoSQL 数据库是使用关系模型以外的模型来存储数据的一类数据库。

NoSQL 数据库有三大类：

• 键／值存储可能是最简单的数据库形式。

它们在键／值对中存储信息，其中键本质上是用于唯一标识记录的索引，该索引由数值组成。

键／值存储对于高速应用和非常大的数据集是有用的。

• 图数据库存储图形格式的数据，用节点表示对象，边缘表示关系。

它们可用于表示任何类型的网络，例如社交网络、地理位置和其他可用于图形表示的数据集。

• 文档存储类似于键／值存储，因为它们使用键存储信息，但是它们存储的信息类型通常比键／值存储更复杂，并以文档形式存在。

文档存储中常用的文档类型包括可扩展标记语言(XML)和JavaScript 对象标记(JSON) 。

NoSQL 数据库所使用的安全模型与关系数据库的明显不同。

使用该技术的组织中的安全专业人员应该熟悉它们的安全特性，并在设计适当的安全控制时与数据库团队协商。

20.3 存储数据和信息

数据库管理系统加强了数据的力量，并且获得了对可以访问数据的人员和可以对数据执行的操作所进行的少量控制。

然而，安全专家必须记住的是， DBMS安全性只适用于通过传统的“前门”来访问信息的渠道。

此外，数据在处理时还会经过计算机的存储资源（内存和物理介质），为了确保这些基本资源免受安全漏洞的威胁，必须采取预防措施。

毕竟，我们永远都不会将大量的时间和金钱花费在只保护前门而令后门大开，是吗？

20.3.1 存储器的类型

现代计算机系统使用几种存储器来保存系统和用户的数据。

为满足组织对计算的要求，系统要在各种存储类型间进行平衡。

目前常用的存储类型包括：

• 主（或实际）存储器

主（或实际）存储器由系统的CPU可直接访问的主要存储资源组成。

主存储器通常由易失性的随机访问存储器（RAM）组成，并且一般是系统可以使用的性能最高的存储资源。

• 辅助存储器

辅助存储器由许多较廉价的、非易失性的、可供系统长期使用的存储资源组成。

典型的辅助存储资源包括磁性的和光学的介质，如磁带、磁盘、硬盘和CD/DVD 。

• 虚拟内存

虚拟内存允许系统利用辅助存储器模拟额外的主存储器资源。

例如，系统缺少昂贵的RAM时，可能将硬盘的一部分作为直接CPU寻址使用。

• 虚拟存储器

虚拟存储器允许系统利用主存储器模拟辅助存储器的资源。

虚拟存储器的最常见例子是作为辅助存储器提供给操作系统的“RAM 磁盘”（但实际上在易失性RAM 中实现）。

这为许多应用程序的使用提供了极快的文件系统，但没有提供恢复能力。

• 随机访问存储器

随机访问存储器准许操作系统请求介质上任意位置的内容。

RAM 和硬盘都是随机访问存储器的例子。

• 顺序访问存储器

顺序访问存储器需要从头到指定地址对整个介质进行扫描。

磁带是常见的顺序访问存储器的例子。

• 易失性存储器

易失性存储器在资源断电时会丢失上面的存储内容。

RAM 是最常见的易失性存储器类型。

• 非易失性存储器不依赖于电源的供电来维待存储内容。

磁性的I光学的介质和非易失性RAM(NVRAM)都是非易失性存储器的例子。

20.3.2 存储器威胁

两种针对数据存储系统的威胁：

第一种威胁，对存储器资源的非法访问

如果管理员不实行恰当的文件系统访问控制，那么入侵者就可能通过浏览文件系统偶然发现敏感数据。

在更敏感的环境中，管理员还应当防止绕过操作系统控制直接访问物理存储介质以检索数据的攻击行为。

使用加密文件系统是最好的办法，只有通过主操作系统才可访问。

此外，在多级安全性环境中运作的系统应当通过提供恰当的控制来确保共享内存和存储器资源时提供故障安全(fail-safe)控制，从而使某个分类级别的数据对于较低分类级别的使用者来说是不可读取的。

第二种主要威胁，隐蔽通道攻击

隐蔽存储通道准许通过直接或间接地操纵共享存储介质，在两个分类级别之间传输敏感的数据。

这可能与向不经意间共享的内存或物理存储器的一部分写入敏感数据一样简单。

更复杂的隐蔽存储通道可能操纵磁盘的可用空间或文件大小，在安全级别之间偷偷地传送信息。

20.4 理解基于知识的系统

两种类型的以知识为基础的人工智能系统：专家系统和神经网络

20.4.1 专家系统

专家系统试图把人类在某个特殊学科累积的知识具体化，并以一致方式将它们应用于未来的决策。

一些研究表明：在正确开发和实现专家系统后，专家系统常能做出比人类的常规决策更好的决定。

每个专家系统都有两个主要组件：知识库和推理引擎。

（1）知识库包含专家系统已知的规则。

知识库试图以一系列if/then语句对人类专家的知识进行编码。

让我们考虑一个简单的专家系统，它被设计用于帮助房主们决定在面临飓风的威胁时是否应该撤离某区域。

知识库可能包含下列一些语句（这些语句只是一些例子）：

• 如果飓风是 4 级或更高等级的风暴，那么洪水一般会达到海拔 20 英尺高。

• 如果飓风的风速超过了每小时120 英里，那么木质结构的建筑物将被毁坏。

• 如果是在飓风季节末期，那么飓风在到达海岸时会变得更强。

在实际的专家系统中，知识库将包合成百上于个如上所示的断言。

（2）推理引擎对知识库中的信息进行分析，从而得到正确的决策。

专家系统用户使用一些用户接口将当前环境的具体内容提供给推理引擎，

推理引擎使用逻辑推理和模糊逻辑技术的组合，基于过去的经验做出结论。

仍然以飓风为例，用户通知专家系统4 级飓风已经接近海岸，风速为平均每小时140 英里。

推理系统随后将分析知识库中的信息，并且基于以前的知识做出撤离的建议。

专家系统并非万无一失，它们的优劣完全取决于知识库中的数据和推理引擎实施的决策制订算法。

不过，专家系统在紧迫的情况下有一个主要优点，它们的决策不受情绪影响。

专家系统可能在一些情况中扮演重要的角色，例如紧急事件、股票交易和其他有时因情绪因素妨碍做出合理决策的情况。

由于这些原因，很多贷款机构现在采用专家系统来做信用决策，而不是相信贷款主管所说的“好，虽然Jim 一直没有准时付账，但是他看起来是个相当不错的人“。

20.4.2 机器学习

机器学习技术使用分析能力从数据集中发现知识，而不直接应用人类洞察力。

机器学习的核心方法是允许计算机直接从数据中分析和学习，开发和更新活动模型。

机器学习技术分为两大类。

• 监督学习技术，使用标记数据进行训练。

创建机器学习模型的分析者提供一个数据集以及正确的答案并允许尊法开发一个模型，然后该模型可以应用于未来的情况。

例如，如果分析员想要开发恶意系统登录的模型，分析员将在一段时间内将包含登录信息的数据集提供给系统，

并指出哪些是恶意的。该算法将使用这些信息来开发恶意登录的模型。

• 无监督学习技术，使用未标记的数据进行训练。

提供给算法的数据集不包含“正确“答案，而要求算法独立地开发模型。

在登录的情况下，该算法可能会被要求识别类似的登录组。

然后分析员可以查看由算法开发的组，并试图识别可能是恶意的组。

20.4.3 神经网络

在神经网络中，计算单元链用来尝试模仿人脑的生物学推理过程。

在专家系统中，一系列规则被存储在知识库中，

而在神经网络中则建立了互相插入和最终合计生成预期输出结果的计算决策长链。

神经网络是机器学习技术的延伸，通常也被称为深度学习或认知系统。

需要记住，所设计出的神经系统要想达到实际的人类推理能力尚需时日。

尽管如此，神经网络仍在推动人工智能领域超越当前的状态，在这方面显示出巨大潜力。

神经网络的优点包括：线型、输入-输出映射和自适应性。

在用于语音识别、脸部识别、天气预报以及关于意识与思考模型研究的神经网络实现中，这些优点十分明显。

典型的神经网络涉及很多层次的合计，每一层的合计都需要加权信息以反映在整个决策制定过程中计算的相对重要性。

针对期待神经网络做出的每种决策，这些权值必须是被定制的。

这可在训练阶段实现，在这个阶段，为网络提供正确决策已知的输入信息。

这个算法随后进行这些决策的逆向工作，从而为计算链中的每个节点确定正确的权值。

这种活动被称为Delta规则或学习规则。通过使用Delta 规则，神经网络就能从经验中学习知识。

20.4.4 安全性应用

基于知识的分析技术：主要优点是它们快速做出一致决策的能力。

计算机安全性方面的一个主要问题是，系统管理员没有能力为了寻找异常而对大量的日志记录和审计踪迹数据进行一致的、彻底的分析。

这似乎是天生的一对矛盾！

变更请求（RFC，request for change ），每个变更都应该是经过审查和批准的变更请求 (RFC) 的结果。

这些 RFC 可能会得到变更咨询委员会 (CAB) 的批准。

问题：Bob 是一名内部审计员，负责检查其组织的变更管理实践。他想审查对软件包所做的一系列更改，以确定它们是否被正确记录。他应该从哪里获得对每个提议变更的描述？（RFC，request for change ）

使用商业现货 (COTS) 软件时，客户通常无法访问源代码，必须依赖供应商发布修复漏洞的安全补丁。

原型法的优点：更好的沟通用户需求。

软件定义安全（Software Defined Security，SDS），

例子：Bob 最近完成了一个软件开发项目，他将组织的网络操作堆栈与他们的开发流程集成在一起。

因此，开发人员可以根据需要从他们的代码中修改防火墙规则。哪个术语最能描述这种能力？（SDS）

解析：

这是软件定义安全 (SDS) 的一个示例，其中安全基础设施可以很容易地被代码操控。回答这个问题很棘手，因为其他几个术语密切相关。

SDS是基础架构即代码 (IaC) 的一个示例，此题中SDS是描述得更清楚的答案，是最佳答案。 SDS 通常在敏捷开发框架中使用。

DevOps 方法将开发和运营联系在一起，但当它还包括 SDS 时，通常称为 DevSecOps。

SDS是从软件定义网络（Software Defined Network，SDN）引申而来，原理是将物理及虚拟的网络安全设备与其接入模式、部署方式、实现功能进行了解耦，底层抽象为安全资源池里的资源，顶层统一通过软件编程的方式进行智能化、自动化的业务编排和管理，以完成相应的安全功能，从而实现一种灵活的安全防护。

IaC，Infrastructure as Code，基础设施即代码，是通过代码而非手动定义的基础设施的配置和管理过程。 IaC从开发人员那里拿走了大部分资源调配工作，开发人员可以执行脚本以准备好基础设施。这样一来，应用程序部署就不会因为等待基础设施而受阻，系统管理员也无需管理耗时的手动流程。

静态应用安全测试（SAST），效率低，误报率高。

认可（Accreditation）：由管理层对系统的整体安全进行正式接受。

问题：关联数据项的持久集合又被定义为（数据库）

数据库管理系统 (DBMS)：定义了维护和提供数据库访问的软件。

面向对象数据库 / Object-Oriented Databases (OODB)，最适合用于支持涉及多媒体、视频、地图、计算机辅助设计和专家系统的复杂应用系统。

NoSQL 数据库：键值存储是 NoSQL 数据库的一个示例，它不像传统数据库那样遵循关系或层次模型。

图数据库是 NoSQL 数据库的另一个示例，但它使用节点和边来存储数据，而不是键和值。

解释器(An interpreter)，在计算机上翻译一个源码命令并执行一次。

功能点方法(Function Point)，

测量开发信息系统工作量的方法，该方法会考虑到系统输入、输出、用户交互文件的数量与复杂度。

Database views 数据库视图：不能实现参照完整性。

用来限制用户可以访问的数据库中的数据，动态生成的一个逻辑的或者虚拟的表。