使用 InSpec 实现符合性即代码

法规符合性是每个企业必须面对的一个现实问题。同时，随着改变业界格局的新技术以及客户对数字服务的期望的出现，竞争压力也随之增加。各行业能否在快速交付新产品和服务的同时，仍然履行法规符合性义务？

回答是肯定的。解决方案就是将法规符合性嵌入软件生产线，方法与嵌入其他特性（如汽车行业中的框架劲度或银行应用程序中的往返响应时间）相似。

将符合性表示成代码时，可以让符合性成为部署流程不可或缺的一部分。如同系统配置已转向基础结构即代码（例如 PowerShell Desired State Configuration 或 Chef）一样，可以使用编程语言管理符合性。

借助 InSpec 这一开放源代码项目，可以通过人工可读和计算机可读的语言定义符合性要求。编写符合性要求代码后，可以将它们作为自动测试来运行，从而审核系统。InSpec 提供本地代理以及完整的远程测试支持。

InSpec 支持各种不同的平台（从 Windows 到 Linux）。 图 1 列出了部分较为常见的平台。（有关受支持平台的完整列表，请访问 InSpec 网站，网址为 inspec.io 。）

图 1：InSpec 支持的常见平台列表

借助广泛的平台支持，InSpec 成为在整个基础结构中管理符合性的完整解决方案。由于 InSpec 是开放源代码项目，因此一些 OS 供应商协助提供了对其自身平台的支持。例如，IBM 协助提供了对其 AIX OS 的大量支持。

InSpec 入门

InSpec 入门非常简单。InSpec 包含在 Chef Devel­opment Kit (Chef DK) 中，也可以从 Chef 下载网站 ( downloads.chef.io/inspec ) 下载适用于各种平台的程序包。下载并安装程序包后，便可以开始编写符合性规则。（请注意，安全团队经常使用的符合性规则可选名称是审核控件。）

了解格式后，就可以轻松编写 InSpec 规则。所有规则均以资源开头。资源是要测试的配置项。例如，下面展示了使用 windows_feature 资源的 InSpec 规则：

describe windows_feature('DHCP Server') do
  it { should_not be_installed }
end

windows_feature 资源声明 Windows 功能的名称，并进行测试来确定其是否与特定配置相符。在此示例中，规则测试的是 DHCP 服务器是否未安装。

网络的许多标准组成部分都有对应的资源，如文件、目录、用户、组和注册表项。有关完整列表，可以参阅 bit.ly/2n3ekZe 上的 InSpec 文档。还可以使用自己的资源轻松扩展 InSpec，从而检查可能开箱即不支持或特定应用程序专用的配置项。

添加元数据

使用 InSpec，可以添加符合性规则的相关元数据。元数据有助于关联测试与具体的法规或安全要求。符合性要求历来都会以文档、电子表格或其他一些无法执行操作的格式发布。这些官方符合性文档中的信息非常重要，因为此类信息可以为管理员提供上下文，让其了解符合性策略如此重要的原因所在，但此类信息通常不便于获取。

图 2 中的示例展示了将此类信息作为元数据包含在内的 InSpec 规则。

图 2：InSpec 示例（其中包含符合性规则的元数据）

control 'sshd-8' do
  impact 0.6
  title 'Server: Configure the service port'
  desc '
    Always specify which port the SSH server should listen to.
    Prevent unexpected settings.
  '
  tag 'ssh','sshd','openssh-server'
  tag cce: 'CCE-27072-8'
  ref 'NSA-RH6-STIG - Section 3.5.2.1',
    url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
  describe sshd_config do
    its('Port') { should eq('22') }
  end
end

此示例针对的是名为 ssh-8 的规则（或控件）。影响力、标题和说明字段定义了描述规则的重要性、用途和说明的元数据。标记字段包含可选信息，引用字段引用外部文档。

说明字段反映了包含规则的代码块的开头。测试中的资源是 sshd_config，这是 Linux 和 Unix 平台上的 OpenSSH 守护程序。规则测试的是 SSH 服务器是否侦听端口 22。

需要注意以下三个要点。首先，如果没有元数据，规则就会被孤立，并缺少上下文。其次，所有相关信息均包含在规则之中。无需与其他文档进行核对。最后，InSpec 语言非常易于阅读。虽然利益干系人（如法律人员）可能不是程序员，但可以理解规则测试的内容，并能通过元数据了解此规则存在的原因及其审核的要求。他们甚至可能想要提交自己的规则。

使用开放源代码配置文件

为了方便操作，InSpec 提供了许多开放源代码配置文件，其中已包含所有相关规则和元数据。例如，有 DevSec Linux 基线配置文件和 DevSec Apache 基线配置文件。可以从 bit.ly/2mBVXNr 下载这些配置文件。

InSpec 提供的许多开放源代码配置文件均以行业标准 Internet 安全中心 (CIS) 系统安全基准为依据。虽然 CIS 基线是不错的入手级配置文件，但可能需要对它们进行修改来满足自己特定的符合性需求。使用 InSpec，可以创建自己的配置文件，并能继承其他配置文件中的规则。InSpec 还允许忽略配置文件中的规则。这一点非常有用，因为这样便无需直接修改 InSpec 提供的开放源代码配置文件。可以通过继承所需的开放源代码配置文件创建自己的配置文件，然后忽略不适用的规则。当有新发布的开放源代码配置文件时，只需更新你的开放源代码规则，而无需修改自定义规则。

扫描主机

InSpec 使用客户端服务器模型。也就是说，可以通过集中式工作站审核远程系统。还可以视需要允许让 InSpec 扫描作为持续自动化系统（如 Chef Automate ( chef.io/automate )）的一部分运行。本文的后面部分中有关于此做法的简单示例。

必须具备目标系统（要测试的服务器）和符合性配置文件（一组用于测试目标系统的规则），才能运行符合性扫描。对于此示例，目标系统是 Windows Server，我将使用 CIS 定义的 Dev-Sec Windows 基线（存储在 GitHub 存储库中）。图 3 中的示例展示了 InSpec 运行。

图 3：InSpec 运行示例

如果查看结果，便会发现运行结果指明有许多配置设置不符合 CIS 符合性基线的要求。值得注意的是，测试的服务器是主要云服务提供商提供的默认 Windows Server 2016 映像，因此可以通过 InSpec 立即了解你的网络与公司安全策略的符合程度。

如果查看第一个未通过测试的实际 InSpec 规则 cis-­enforce-password-history-1.1.1，便可以了解如何将此规则转换成行动依据：

control 'cis-enforce-password-history-1.1.1' do
  impact 0.7
  title '1.1.1 Set Enforce password history to 24 or more passwords'
  desc 'Set Enforce password history to 24 or more passwords'
  describe security_policy do
    its('PasswordHistorySize') { should be >= 24 }
  end
end

测试未通过是因为策略要求至少有 24 个密码历史记录条目，但实际上根本就没有保留任何历史记录。显然，必须更改当前配置设置，才能符合此规则。

将 InSpec 和自动发布管道结合使用

虽然 InSpec 本身有助于管理系统符合性，但 InSpec 也可以作为一系列自动测试运行（即作为标准发布管道的一部分执行）。可以轻松添加 InSpec 测试，作为符合性质量检验关。在此部分中，我将结合使用 InSpec 和 Chef Automate。

Chef Automate 是用于管理和部署基础结构和应用程序的集成解决方案。它依赖用于基础结构自动化的开放源代码产品（包含 InSpec 和 Chef）基础。Chef Automate 提供了用于管理更改的自动化管道，所含功能可确保呈现这些更改。