完整性生命周期¶
我们定义完整性生命周期为一个有意的过程，它保证我们在整个云环境中始终运行预期的软件和配置。此过程从安全引导开始，并通过配置管理和安全监控来维护。本章提供了关于如何处理完整性生命周期过程的建议。
安全引导¶
云中的节点——包括计算、存储、网络、服务和混合节点——应该具有自动配置过程。这确保了节点被一致且正确地配置。这也有助于安全补丁、升级、错误修复和其他关键更改。由于此过程安装了在云中以最高权限运行的新软件，因此验证安装的软件是否正确非常重要。这包括启动过程的早期阶段。
有多种技术可以验证这些早期启动阶段。这些通常需要硬件支持，例如可信平台模块 (TPM)、Intel Trusted Execution Technology (TXT)、动态信任根测量 (DRTM) 和 Unified Extensible Firmware Interface (UEFI) 安全引导。在本书中，我们将集体将所有这些称为安全引导技术。我们建议使用安全引导，同时承认部署这些技术中的许多部分需要高级技术技能才能为每个环境定制工具。利用安全引导将比本指南中的许多其他建议需要更深入的集成和定制。TPM 技术虽然在过去几年中在大多数商用笔记本电脑和台式机中很常见，但现在也开始在服务器中可用，并支持 BIOS。成功的安全引导部署需要周密的计划。
关于安全引导部署的完整教程超出了本书的范围。相反，我们在这里提供一个框架，说明如何将安全引导技术与典型的节点配置过程集成。有关更多详细信息，云架构师应参考相关的规范和软件配置手册。
节点配置¶
节点应使用 Preboot eXecution Environment (PXE) 进行配置。这大大减少了重新部署节点所需的工作量。典型的过程涉及节点从服务器接收各种启动阶段——即逐步更复杂的软件来执行——。
我们建议在管理安全域内使用一个单独的、隔离的网络进行配置。该网络将处理所有 PXE 流量，以及上述描绘的后续启动阶段下载。请注意，节点启动过程从两个不安全的操作开始：DHCP 和 TFTP。然后，启动过程使用 TLS 下载部署节点所需的剩余信息。这可能是一个操作系统安装程序，一个由 Ansible 或 Puppet 管理的基本安装，甚至直接写入磁盘的完整文件系统镜像。
虽然在 PXE 启动过程中使用 TLS 具有一定的挑战性，但常见的 PXE 固件项目，例如 iPXE，提供了对此的支持。通常，这涉及使用允许的 TLS 证书链的知识构建 PXE 固件，以便它可以正确验证服务器证书。这提高了对攻击者的门槛，限制了不安全、明文网络操作的数量。
验证启动¶
通常，有两种不同的策略可以验证启动过程。传统的安全引导将验证过程中每个步骤中运行的代码，并在代码不正确时停止启动。启动证明将记录在每个步骤中运行的代码，并将此信息提供给另一台机器，作为启动过程按预期完成的证明。在两种情况下，第一步是在运行之前测量每一段代码。在这种情况下，测量实际上是代码的 SHA-1 哈希值，在执行之前获取。哈希值存储在 TPM 中的平台配置寄存器 (PCR) 中。
注意
SHA-1 在这里使用是因为这是 TPM 芯片支持的。
每个 TPM 至少有 24 个 PCR。TCG Generic Server Specification, v1.0, March 2005 定义了启动时完整性测量的 PCR 分配。下表显示了一个典型的 PCR 配置。上下文指示值是基于节点硬件（固件）还是配置到节点上的软件确定的。一些值受固件版本、磁盘大小和其他低级信息影响。因此，在配置管理方面采取良好的实践非常重要，以确保部署的每个系统都配置为所需的确切状态。
寄存器 |
测量内容 |
Context |
|---|---|---|
PCR-00 |
核心信任根测量 (CRTM)、BIOS 代码、主机平台扩展 |
硬件 |
PCR-01 |
主机平台配置 |
硬件 |
PCR-02 |
Option ROM 代码 |
硬件 |
PCR-03 |
Option ROM 配置和数据 |
硬件 |
PCR-04 |
初始程序加载器 (IPL) 代码。例如，主引导记录。 |
软件 |
PCR-05 |
IPL 代码配置和数据 |
软件 |
PCR-06 |
状态转换和唤醒事件 |
软件 |
PCR-07 |
主机平台制造商控制 |
软件 |
PCR-08 |
平台特定，通常是内核、内核扩展和驱动程序 |
软件 |
PCR-09 |
平台特定，通常是 Initramfs |
软件 |
PCR-10 到 PCR-23 |
平台特定 |
软件 |
安全引导可能是构建云的一个选项，但需要仔细规划硬件选择。例如，确保您拥有 TPM 和 Intel TXT 支持。然后，验证节点硬件供应商如何填充 PCR 值。例如，哪些值可用于验证。通常，上表中软件上下文下的 PCR 值是云架构师可以直接控制的。但即使这些值也可能随着云中的软件升级而变化。应将配置管理链接到 PCR 策略引擎，以确保验证始终是最新的。
每个制造商必须提供其服务器的 BIOS 和固件代码。不同的服务器、虚拟机监控程序和操作系统将选择填充不同的 PCR。在大多数实际部署中，将每个 PCR 与已知良好的数量（“黄金测量”）进行验证是不可能的。经验表明，即使在单个供应商的产品线中，给定 PCR 的测量过程可能也不一致。我们建议为每个服务器建立基线，并监控 PCR 值是否有意外更改。根据您选择的虚拟机监控程序解决方案，可能有第三方软件可用于协助 TPM 配置和监控过程。
初始程序加载器 (IPL) 代码很可能是 PXE 固件，假设使用上述的节点部署策略。因此，安全引导或启动证明过程可以测量所有早期阶段的启动代码，例如 BIOS、固件、PXE 固件和内核镜像。确保每个节点都安装了这些组件的正确版本，为构建其余节点软件堆栈提供了坚实的基础。
根据选择的策略，如果发生故障，节点将无法启动，或者它可以将故障报告回云中的另一个实体。对于安全引导，节点将无法启动，并且管理安全域内的配置服务必须识别此情况并记录事件。对于启动证明，节点将在检测到故障时已经运行。在这种情况下，应立即通过禁用其网络访问来隔离节点。然后，应分析事件以确定根本原因。在任何一种情况下，策略都应规定故障发生后的处理方式。云可以自动尝试重新配置节点一定次数。或者，它可能会立即通知云管理员调查问题。正确的策略将取决于部署和故障模式。
节点加固¶
此时，我们知道节点已经使用正确的内核和底层组件启动。下一步是加固操作系统，它从一组行业认可的加固控制开始。以下指南是很好的例子
- 安全技术实施指南 (STIG)
美国国防部 (DISA)（美国国防部的一部分）为各种操作系统、应用程序和硬件发布 STIG 内容。这些控制的发布不附带任何许可。
- 互联网安全中心 (CIS) 基准
CIS 定期发布安全基准以及可以自动应用这些安全控制的自动化工具。这些基准根据 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可 发布，该许可有一些限制。
最好通过自动化方法应用这些安全控制。自动化可确保每次对每个系统应用控制的方式相同，并提供快速审核现有系统的方法。有多种自动化选项
- OpenSCAP
OpenSCAP 是一个开源工具，它采用 SCAP 内容（描述安全控制的 XML 文件）并将该内容应用于各种系统。当今可用的内容大多是针对 Red Hat Enterprise Linux 和 CentOS 的，但这些工具可以在任何 Linux 或 Windows 系统上工作。
- ansible-hardening
ansible-hardening 项目提供了一个 Ansible 角色，该角色将安全控制应用于各种 Linux 操作系统。它还可以用于审核现有系统。仔细审查每个控制，以确定它是否可能对生产系统造成损害。这些控制基于 Red Hat Enterprise Linux 7 STIG。
完全加固系统是一个具有挑战性的过程，可能需要对某些系统进行大量更改。其中一些更改可能会影响生产工作负载。如果无法完全加固系统，强烈建议进行以下两个更改以提高安全性，而不会造成重大中断
- 强制访问控制 (MAC)
强制访问控制会影响系统上的所有用户，包括 root，并且内核的工作是根据当前的安全性策略检查活动。如果活动不在允许的策略范围内，即使对于 root 用户也会被阻止。有关更多详细信息，请参阅下面有关 sVirt、SELinux 和 AppArmor 的讨论。
- 删除软件包并停止服务
确保系统安装的软件包最少，并且运行的服务最少。删除不必要的软件包可以简化补丁程序，并减少系统中可能导致漏洞的项目数量。停止不必要的服务缩小了系统的攻击面，使其更难攻击。
我们还建议对生产节点采取以下其他步骤
- 只读文件系统
尽可能使用只读文件系统。确保可写文件系统不允许执行。这可以通过在
/etc/fstab中使用noexec、nosuid和nodev安装选项来处理。- 系统验证
最后，节点内核应该具有一种机制来验证节点的其余部分是否以已知良好的状态启动。这提供了从启动验证过程到验证整个系统的必要链接。执行此操作的步骤将取决于部署。例如，内核模块可以在使用 dm-verity 挂载文件系统之前，验证组成文件系统的块的哈希值。
运行时验证¶
一旦节点运行，我们需要确保它随着时间的推移保持良好的状态。广义地说，这包括配置管理和安全监控。这两个领域的的目标不同。通过检查两者，我们可以获得更高的系统按预期运行的保证。我们将在管理部分讨论配置管理，并在下面讨论安全监控。
入侵检测系统¶
基于主机的入侵检测工具也适用于云内部的自动化验证。有各种基于主机的入侵检测工具可用。有些是免费提供的开源项目，而另一些是商业的。通常，这些工具会分析来自各种来源的数据，并根据规则集和/或培训生成安全警报。典型功能包括日志分析、文件完整性检查、策略监控和 rootkit 检测。更高级的——通常是定制的——工具可以验证内存中的进程镜像是否与磁盘上的可执行文件匹配，并验证正在运行的进程的执行状态。
云架构师的一个关键策略决策是应该如何处理安全监控工具的输出。实际上有两种选择。第一种是向人类发出警报以进行调查和/或采取纠正措施。这可以通过将安全警报包含在云管理员的日志或事件源中来完成。第二种选择是让云自动采取某种形式的补救措施，除了记录事件之外。补救措施可以包括从重新安装节点到执行小的服务配置等任何事情。但是，由于误报的可能性，自动补救措施可能具有挑战性。
误报是指安全监控工具为良性事件生成安全警报。由于安全监控工具的性质，误报肯定会不时发生。通常，云管理员可以调整安全监控工具以减少误报，但这也可能同时降低整体检测率。必须理解并考虑这些经典的权衡，并在云中设置安全监控系统时进行考虑。
基于主机的入侵检测工具的选择和配置高度依赖于部署。我们建议从探索以下开源项目开始，这些项目实现了各种基于主机的入侵检测和文件监控功能。
网络入侵检测工具补充了基于主机的工具。OpenStack 没有内置特定的网络 IDS，但 OpenStack Networking 提供了通过 Networking API 启用不同技术的插件机制。此插件架构将允许租户开发 API 扩展以插入和配置他们自己的高级网络服务，例如防火墙、入侵检测系统或虚拟机之间的 VPN。
与基于主机的工具类似，基于网络的入侵检测工具的选择和配置高度依赖于部署。Snort 是领先的开源网络入侵检测工具，是了解更多信息的良好起点。
对于网络和主机入侵检测系统，存在一些重要的安全注意事项。
重要的是要考虑网络入侵检测系统在云中的部署位置（例如，将其添加到网络边界和/或敏感网络周围）。部署位置取决于您的网络环境，但请确保监控IDS可能对您的服务产生的影响，具体取决于您选择添加的位置。网络IDS通常无法检查加密流量（例如TLS）的内容。但是，网络IDS仍然可以通过识别网络上的异常未加密流量来提供一些好处。
在某些部署中，可能需要在安全域桥接上的敏感组件上添加主机入侵检测系统。主机入侵检测系统可以通过检测被破坏或未经授权的组件上的异常活动来检测异常活动。IDS应通过管理网络传输警报和日志信息。
服务器加固¶
云中的服务器，包括底层云和上层云基础设施，应实施加固的最佳实践。由于操作系统和服务器加固很常见，适用的最佳实践包括但不限于日志记录、用户帐户限制和定期更新，此处将不赘述，但应将其应用于所有基础设施。
文件完整性管理 (FIM)¶
文件完整性管理 (FIM) 是一种确保敏感系统或应用程序配置文件等文件不被损坏或更改，从而允许未经授权的访问或恶意行为的方法。这可以通过诸如Samhain之类的实用程序来完成，该实用程序将创建指定资源的校验和哈希，然后在定期间隔验证该哈希，或者通过诸如DMVerity之类的工具来完成，该工具可以获取块设备的哈希，并在系统访问它们之前验证这些哈希，然后将其呈现给用户。
应将其部署到位，以监控和报告对系统、虚拟机监控程序和应用程序配置文件（例如 /etc/pam.d/system-auth 和 /etc/keystone/keystone.conf）以及内核模块（例如virtio）的更改。最佳实践是使用 lsmod 命令来显示系统中定期加载的内容，以帮助确定应将哪些内容包含在FIM检查中，哪些内容不应包含在FIM检查中。
