使用 InSpec 实现符合性即代码

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

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

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

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

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

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

平台 版本 AIX 6.1、7.1、7.2 Mac OS X 10.9、10.10、10.11 Oracle Enterprise Linux 5、6、7 Red Hat Enterprise Linux（及变体） 5、6、7 Solaris 10、11 Windows 7、8、8.1、10、2008、2008 R2、2012、2012 R2、2016 Ubuntu Linux
SUSE Linux Enterprise Server 11、12 OpenSUSE 13.1、13.2、42.1 HP-UX 11.31

借助广泛的平台支持，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') }  endend

此示例针对的是名为 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 }  endend

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

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

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

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

借助 Chef Automate，不仅可以根据需要运行 InSpec 符合性测试，还能在仪表板上查看结果并更正问题。还可以在需要时生成审核报告。

例如，修补程序管理是 IT 安全的最重要方面之一。能够发现并升级过时系统，这一点至关重要。大多数监管框架（如支付卡行业数据安全标准 (PCI DSS)）都要求这一点。为了确保系统是最新的，可以使用 Chef Automate 管理从初始识别到更新的整个流程。

首先，可以扫描系统，以确定系统是否符合策略且软件是否是最新的。你会收到指明基础结构状态的报告。图 4 中的示例展示了此类报告。报告根据网络中服务器与符合性要求的符合程度显示了这些服务器的状态。

图 4：符合性报告示例

收到此报告后，便可以使用 Chef DK 生成更新程序，然后在将其部署到生产中之前对其进行本地测试。Chef DK 包含创建和测试代码所需的全部工具。

认为更改没有问题后，可以通过 Chef Automate 管道发送更改，从而部署更新程序。管道包含测试更改并确保更改能够生效的各个阶段。管道内有两个手动检验关。一个用于代码评审，另一个用于将代码发送到发布环境。可以在这两个检验关或其中之一嵌入符合性和安全管理人员，从而确保这两个检验关能够在发布流程中积极发挥作用。

最后，当更改通过管道中的所有阶段时，可以将这些更改发送到 Chef 服务器。然后，Chef 服务器可以开始更新节点。通过 Chef Automate，可以了解在部署这些更改后基础结构中发生的所有情况。

通过 InSpec 自动执行符合性测试

印度最大的银行之一已开始在其银行业务部门使用 InSpec，此部门负责处理银行的大部分交易。符合性对其尤为重要。此部门大约有 500 台 HP-UX 服务器，这些服务器构成了其开发、测试和生产环境。

当然，这家银行必须遵守许多法律和安全准则，相关团队每月都会进行检查，以确保其服务器合规。检查大约有 100 项，在使用 InSpec 之前，这些检查均手动执行。此流程非常难执行。相关团队必须登录每台计算机，检查配置设置，提供书面结果，然后记录在册。完成一项检查大约需要 5 分钟，因此仅审查一台服务器就需要大约 8 小时。

在相关团队开始使用 InSpec 自动执行符合性测试后，影响明显可见。只需几分钟即可生成整个扫描结果。相关团队可以了解合规和不合规的服务器台数，并能根据这些信息快速做出决策。审查一台服务器曾经需要 500 分钟，现在只需 2 分钟。

此外，使用 InSpec，还更容易满足银行审计的需求。有时，IT 审计会要求检查特定计算机的状态，而信息检索速度非常缓慢。团队成员必须手动运行脚本，然后获取输出并使其适合生成报告。现在，只需单击一下，相关团队即可立即向审计展示已执行的检查。

此外，InSpec 不仅人工可读，还简单易学。大多数安全和审计服务供应商都使用二进制格式，而且工具很难使用。在看到 InSpec 后，银行团队成员认为他们可以在几天之内轻松学会，因为其学习曲线非常短。（有关详情，请访问“Learn Chef”网站，网址为 bit.ly/2mGthmE。）

总结

InSpec 是开放源代码测试语言，可方便你实现符合性即代码。将符合性表示成代码后，规则变得明确，所有团队成员都可以理解。开发者知道自己应该符合哪些标准，审计也清楚地知道测试中的内容。借助 InSpec，可以将文档和人工核对清单替换为目标明确的程序测试。

还可以将符合性测试集成到开发管道中，然后自动执行安全策略符合性测试。按所需的频率运行测试，开始测试所有更改的符合性，然后在开发过程早期（在发布到生产环境中之前）捕获问题。

---

Michael Ducy 是 Chef 软件开放源代码产品市场营销部门的主管。他已使用、管理、推广开放源代码软件近 20 年之久。Ducy 曾担任众多技术角色，其中包括 Linux 系统工程师、IT 导师和售前工程师等。他一直热衷于与更广大的的社区进行交互，可以通过 Twitter @mfdii 与他联系。

衷心感谢以下技术专家对本文的审阅： Bakh Inamov、Adam Leff 和 Roberta Leibovitz

原文地址：https://msdn.microsoft.com/zh-cn/magazine/mt808501

---

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注