实例的安全服务¶

实例的熵¶

我们认为熵是指实例可用的随机数据的质量和来源。加密技术通常严重依赖随机性，需要从高质量的熵池中获取随机数。虚拟机通常很难获得足够的熵来支持这些操作，这被称为熵耗尽。熵耗尽在实例中可能表现为看似无关的问题。例如，缓慢的启动时间可能是由于实例正在等待 ssh 密钥生成。熵耗尽也可能促使用户在实例内部采用质量较差的熵源，从而使云中的应用程序整体安全性降低。

幸运的是，云架构师可以通过向云实例提供高质量的熵源来解决这些问题。这可以通过在云中拥有足够的硬件随机数生成器 (HRNG) 来支持实例来实现。在这种情况下，“足够”在某种程度上取决于特定领域。对于日常操作，现代 HRNG 可能足以支持 50-100 个计算节点。具有更高带宽的 HRNG，例如 Intel Ivy Bridge 及更新处理器中提供的 RdRand 指令，可能能够处理更多的节点。对于给定的云，架构师需要了解应用程序的要求，以确保提供足够的熵。

Virtio RNG 是一种随机数生成器，默认情况下使用 /dev/random 作为熵源，但可以配置为使用硬件 RNG 或熵收集守护程序（EGD）来提供一种公平且安全地通过分布式系统分配熵的方式。Virtio RNG 使用用于创建实例的元数据中的 hw_rng 属性启用。

将实例调度到节点¶

在创建实例之前，必须选择用于镜像实例化的主机。此选择由 nova-scheduler 执行，它确定如何分派计算和卷请求。

FilterScheduler 是 OpenStack Compute 的默认调度器，尽管也存在其他调度器（请参阅调度在 OpenStack 配置参考中）。它与“过滤器提示”协作，以决定应在何处启动实例。此主机选择过程允许管理员满足许多不同的安全和合规性要求。例如，根据云部署类型，如果数据隔离是主要问题，可以选择尽可能将租户实例放在同一主机上。相反，可以尝试将租户的实例放在尽可能多的不同主机上，以提高可用性或容错性。

过滤器调度器分为四大类

基于资源的过滤器: 这些过滤器将基于超visor 主机集的利用率创建实例，并可以在空闲或已用属性（如 RAM、IO 或 CPU 利用率）上触发。
基于镜像的过滤器: 这会将实例创建委托给使用的镜像，例如 VM 的操作系统或使用的镜像类型。
基于环境的过滤器: 此过滤器将基于外部细节创建实例，例如在特定 IP 范围内、跨可用区或与另一个实例相同的宿主机上。
自定义标准: 此过滤器将根据用户或管理员提供的标准（例如信任或元数据解析）委托实例创建。

可以同时应用多个过滤器，例如 ServerGroupAffinity 过滤器，以确保实例在特定主机集的一个成员上创建，以及 ServerGroupAntiAffinity 过滤器，以确保同一实例不在另一个特定主机集上创建。应仔细分析这些过滤器，以确保它们不会相互冲突并导致阻止实例创建的规则。

GroupAffinity 和 GroupAntiAffinity 过滤器冲突，不应同时启用两者。

DiskFilter 过滤器能够过度订阅磁盘空间。虽然通常不是问题，但这可能在采用稀疏配置的存储设备上成为一个问题，因此应结合经过良好测试的配额使用此过滤器。

我们建议禁用解析由用户提供或能够被操作的事物（例如元数据）的过滤器。

可信镜像¶

在云环境中，用户使用预安装的镜像或自己上传的镜像。在两种情况下，用户都应该能够确保他们使用的镜像未被篡改。验证镜像的能力是安全的基本要求。需要从镜像的来源到其使用目的地建立信任链。可以通过对来自可信来源的镜像进行签名并在使用前验证签名来实现这一点。下面将讨论获取和创建经过验证的镜像的各种方法，然后介绍镜像签名验证功能。

镜像创建过程¶

OpenStack 文档提供了有关如何创建和上传镜像到镜像服务的指导。此外，我们假设您有一个安装和加固操作系统的过程。因此，以下项目将提供有关如何确保您的镜像安全传输到 OpenStack 的更多指导。获取镜像有多种选择。每种选择都有特定的步骤来帮助验证镜像的来源。

第一个选项是从可信来源获取启动介质。

$ mkdir -p /tmp/download_directorycd /tmp/download_directory
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS
$ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
$ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep OK

第二个选项是使用 OpenStack 虚拟机镜像指南。在这种情况下，您需要遵循组织的操作系统的加固指南或受信任的第三方（例如 Linux STIGs）提供的指南。

最终选项是使用自动镜像生成器。以下示例使用 Oz 镜像生成器。OpenStack 社区最近创建了一个值得研究的新工具：disk-image-builder。我们尚未从安全角度评估此工具。

RHEL 6 CCE-26976-1 的示例，这将有助于在 Oz 中实施 NIST 800-53 第 AC-19(d) 部分。

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  rm -rf /var/log/yum
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

我们建议避免手动构建镜像过程，因为它复杂且容易出错。此外，使用像 Oz 这样的自动镜像构建系统或像 Ansible 或 Puppet 这样的配置管理实用程序进行启动后镜像加固，可以使您能够生成一致的镜像，并随着时间的推移跟踪基本镜像与其各自加固指南的合规性。

如果订阅公共云服务，您应该与云提供商核实其用于生成默认镜像的过程的概述。如果提供商允许您上传自己的镜像，您需要确保在将其用于创建实例之前，能够验证您的镜像未被修改。为此，请参阅以下镜像签名验证部分，或者如果无法使用签名，请参阅以下段落。

镜像从镜像服务传输到 Compute 服务的节点。此传输应通过 TLS 运行来保护。一旦镜像位于节点上，它将使用基本的校验和进行验证，然后其磁盘将根据正在启动的实例的大小进行扩展。如果稍后在同一节点上使用相同实例大小启动相同的镜像，则它将从相同的扩展镜像启动。由于默认情况下，在启动之前不会重新验证此扩展镜像，因此可能已经发生了篡改。用户不会意识到篡改，除非对结果镜像中的文件进行手动检查。

镜像签名验证¶

OpenStack 中现在可用一些与镜像签名相关的特性。从 Mitaka 版本开始，镜像服务可以验证这些签名镜像，并且为了提供完整的信任链，Compute 服务可以选择在镜像启动之前执行镜像签名验证。在镜像启动前成功验证签名可确保签名镜像未被更改。启用此功能后，可以检测到对镜像的未经授权的修改（例如，修改镜像以包含恶意软件或 rootkit）。

管理员可以通过将 verify_glance_signatures 标志设置为 True 在 /etc/nova/nova.conf 文件中来启用实例签名验证。启用后，Compute 服务在从镜像服务检索时会自动验证签名实例。如果此验证失败，则启动将不会发生。OpenStack 操作指南提供了有关如何创建和上传签名镜像以及如何使用此功能的指导。有关更多信息，请参阅操作指南中的添加签名镜像。

实例迁移¶

OpenStack 和底层的虚拟化层允许在 OpenStack 节点之间实时迁移镜像，从而使您能够无缝执行 OpenStack 计算节点的滚动升级，而不会导致实例停机。但是，实时迁移也存在重大风险。为了了解所涉及的风险，以下是实时迁移过程中执行的高级步骤

在目标主机上启动实例
传输内存
停止客户机并同步磁盘
传输状态
启动客户机

实时迁移风险¶

在实时迁移过程的各个阶段，实例运行时内存和磁盘的内容都会以明文形式通过网络传输。因此，在使用实时迁移时需要解决一些风险。以下是不完全列表，详细说明了其中一些风险

拒绝服务 (DoS)：如果迁移过程中出现任何故障，则实例可能会丢失。
数据泄露：必须安全地处理内存或磁盘传输。
数据操纵：如果内存或磁盘传输未得到安全处理，则攻击者可能会在迁移过程中操纵用户数据。
代码注入：如果内存或磁盘传输未得到安全处理，则攻击者可能会在迁移过程中操纵磁盘或内存中的可执行文件。

实时迁移缓解措施¶

有几种方法可以缓解与实时迁移相关的某些风险，以下列表详细说明了其中一些

禁用实时迁移
隔离的迁移网络
加密的实时迁移

禁用实时迁移¶

目前，OpenStack 中默认情况下启用了实时迁移。可以通过将以下行添加到 nova policy.json 文件来禁用实时迁移

{
    "compute_extension:admin_actions:migrate": "!",
    "compute_extension:admin_actions:migrateLive": "!",
}

迁移网络¶

作为一般做法，应将实时迁移流量限制到管理安全域，请参阅安全边界和威胁。由于实时迁移流量的明文性质以及您正在传输运行实例的磁盘和内存的内容，因此建议您将实时迁移流量进一步分离到专用网络上。将流量隔离到专用网络可以降低暴露风险。

加密的实时迁移¶

如果启用实时迁移有足够的业务理由，那么 libvirtd 可以为实时迁移提供加密隧道。但是，此功能当前未在 OpenStack Dashboard 或 nova-client 命令中公开，只能通过手动配置 libvirtd 访问。然后，实时迁移过程将更改为以下高级步骤

实例数据从 hypervisor 复制到 libvirtd。
在源主机和目标主机上的 libvirtd 进程之间创建加密隧道。
目标 libvirtd 主机将实例复制回基础 hypervisor。

监控、告警和报告¶

由于 OpenStack 虚拟机是一种可以跨主机复制的服务器镜像，因此最佳日志记录实践同样适用于物理和虚拟主机。应记录操作系统级别和应用程序级别的事件，包括对主机和数据的访问事件、用户添加和删除、权限更改以及环境所要求的其他事件。理想情况下，您可以将这些日志配置为导出到日志聚合器，该聚合器收集日志事件，将它们关联起来进行分析，并将其存储以供参考或进一步操作。一个常见的工具是 ELK 堆栈，或 Elasticsearch、Logstash 和 Kibana。

应定期审查这些日志，例如由网络运营中心 (NOC) 进行实时查看，或者如果环境不够大，不需要 NOC，则日志应经过定期的日志审查过程。

很多时候，有趣的事件会触发发送给响应者的警报。通常，此警报采用电子邮件的形式，其中包含感兴趣的消息。一个有趣的事件可能是重大故障，或即将发生的故障的已知健康指标。两个常用的警报管理实用程序是 Nagios 和 Zabbix。

更新和补丁¶

hypervisor 运行独立的虚拟机。此 hypervisor 可以在操作系统中运行，也可以直接在硬件上运行（称为 baremetal）。hypervisor 的更新不会传播到虚拟机。例如，如果部署正在使用 XenServer 并且有一组 Debian 虚拟机，则对 XenServer 的更新不会更新 Debian 虚拟机上运行的任何内容。

因此，我们建议明确分配虚拟机的所有权，并要求这些所有者负责虚拟机的加固、部署和持续功能。我们还建议按照定期计划部署更新。应在尽可能接近生产的环境中测试这些补丁，以确保稳定性和解决补丁背后的问题。

防火墙和其他基于主机的安全控制¶

大多数常见的操作系统都包含基于主机的防火墙以提供额外的安全性。虽然我们建议虚拟机运行尽可能少的应用程序（最好达到单用途实例的程度），但所有在虚拟机上运行的应用程序都应进行分析，以确定该应用程序需要访问哪些系统资源、运行所需的最低权限级别，以及进出虚拟机的预期网络流量。此预期流量应添加到基于主机的防火墙中作为允许的流量（或白名单），以及任何必要的日志记录和管理通信，例如 SSH 或 RDP。防火墙配置中应明确拒绝所有其他流量。

在 Linux 虚拟机上，上述应用程序分析结果可以与像 audit2allow 这样的工具结合使用，以构建 SELinux 策略，从而进一步保护大多数 Linux 发行版上的敏感系统信息。SELinux 使用用户、策略和安全上下文的组合来隔离应用程序运行所需的资源，并将其与其他不需要的系统资源隔离。

OpenStack 为主机和网络提供安全组，为给定项目的虚拟机增加纵深防御。这些类似于基于主机的防火墙，它们允许或拒绝基于端口、协议和地址的入站流量，但是安全组规则仅适用于入站流量，而基于主机的防火墙规则可以应用于入站和出站流量。主机和网络安全组规则也可能发生冲突并拒绝合法流量。我们建议确保安全组已针对所使用的网络正确配置。有关更多详细信息，请参阅本指南中的安全组。

实例安全服务