（注意：本系列文章的所有链接列表可以在本文的结尾找到。）
这是我们系列博客文章的第一部分，展示了组织和云服务提供商在努力实现持续合规性时面临的挑战。该系列将介绍通往一种操作性强、可扩展且有效的端到端解决方案的关键概念、技术和行业标准。
我们将首先介绍合规性人物角色及其在合规性过程中的角色和行为。了解这些人物角色、他们的角色和需求对于设计和架构决策以实现治理、风险和合规性（GRC）自动化非常重要，详细信息将在我们后续的博客文章中介绍。
在本系列的第二篇博客文章中，我们将回顾企业范围内合规性流程中处理的合规性文档以及为人类使用的各种人物角色和编程实现的设计。
后续的博客文章将涵盖我们的分层治理、风险和合规性（GRC）解决方案，其中包括各种类型的策略协调器和策略验证协调器，用于在策略验证工具和协调器之间实现互操作性的标准化交换协议，用于策略协调器的基于人工智能的法规交叉支持以及一些特定的策略验证自动化技术。敬请关注。
持续合规性的重要性
如今，合规性对于企业来说是一种业务责任。企业界正在从零星审计转向持续合规领域，其中系统的状况可以通过仪表板轻松获得。为了实现持续合规性，我们需要自动化和标准化。实现自动化是一项具有挑战性的任务，原因是治理流程孤立、组织政策与相应技术实施之间的脱节，以及合规性实施和评估的复杂性。
需要注意的是，我们越接近系统、API和程序化数据表示，推动数字化和自动化就越容易。与此同时，我们越接近手动流程和人工格式化数据表示，推动数字化和转型就越困难。合规性属于第二类，具有PDF和Word文档的法规、指南和解释，以及收集样本证据和生成电子表格报告的手动程序。因此，要参与合规性自动化之旅，我们需要了解这些手动、半自动和孤立的程序及其促进者的需求。
在本博客文章中，我们调查了治理、风险和合规性（GRC）管理框架中的利益相关者及其在其中的角色和行为，从法规撰写到证据收集再到审计报告。由于我们在本系列中的重点是合规性，风险方面将在稍后进行包含。然后，我们介绍与这些人物角色相关的合规性文档，并举例说明它们作为合规性代码和策略代码的表示形式以实现自动化。更全面地介绍合规性文档将在我们下一篇博客文章中进行。
合规性人物角色
图1：治理、风险和合规性管理框架中的合规性人物角色行为
如图1所示，参与治理、风险和合规性（GRC）管理框架的主要合规性利益相关者及其行为流程如下：
- 监管机构将法规、法律和标准定义为带有控制和参数的目录。他们还将预定义的合规性要求制定为基线或配置文件。
- CISO企业架构师、安全工程师和合规性官员负责解释法规、定义、定制并将指导与选定的配置文件和控制关联起来，适用于其环境和参考架构。
- 控制提供商（如产品供应商、服务提供商和OSS项目维护人员）根据CISO和合规性官员的解释和指导，在其产品（如硬件、软件、服务、流程）中实施法规目录中的控制，以反映控制指南，需要将每个控制转化为应用于产品配置参数和行为的技术规则。这种转化是通过说明控制和技术规则之间的映射来完成的。控制提供商还可以公开与每个规则相关的证据的性质（如模式、模板、API有效载荷）。
- 需要测试或执行技术规则，以检查或确保受监管环境或参考架构根据法规、基线或预定义配置文件进行配置和行为。评估工具供应商、服务提供商、OSS项目维护人员和合规性工程师等控制评估员实施检查或托管检查的产品，以测试受监管环境或参考架构是否符合预期的合规性要求。他们的检查基于控制提供商声明的证据格式，并具有“失败”、“通过”、“错误”和“无法执行”等检查的输出状态。
- 系统所有者和CIO负责企业平台、系统、操作系统、网络、数据库和应用程序的整体采购、开发、集成、修改、运维、维护和处置。他们负责确保符合CISO安全工程师所选的配置文件。
- CISO企业架构师、安全工程师和合规性工程师还负责为其受监管的企业和参考架构创建新的技术规则，通过跨产品组合能力和行为来覆盖其他控制。这些新规则将导致新的检查，进一步测试受监管环境和参考架构是否符合CISO安全工程师所选的配置文件。这些检查基于控制提供商声明的证据格式（或在自定义工具和流程的情况下由CISO声明），并具有“失败”、“通过”、“错误”和“无法执行”等输出状态。
- CISO还是系统所有者与审计官员之间的纽带，他们需要为授权运行（ATO）准备包（即系统安全计划（SSP）和系统评估结果（SAR））。
- 基于CISO所选的配置文件、SSP或系统评估计划（SAP），控制评估员测试所有适用的技术规则并生成包含受监管环境或参考架构中系统合规状况的系统评估结果（SAR）。SAR与CISO、系统所有者和/或运维团队共享。
- CISO和/或系统所有者可能会根据SAR的状态失败生成行动计划。系统所有者负责确保符合CISO所选的配置文件。他们从控制评估员那里获取SAR，并必须采取纠正措施以减少或消除失败风险。他们与运维团队合作进行系统修复（以消除风险），并与CISO合作调整配置文件或SSP安全计划（以降低风险）。
- 运维人员、管理员和开发人员需要专注于其各自工作的日常任务，并尽量减少参与法规和审计。他们需要了解他们所专长的系统的技术控制如何影响其环境、参考架构和应用程序的合规性，并在不符合合规性时进行整改。他们会受
在下表中，我们总结了参与企业范围合规流程及其操作的角色：
表格1：企业范围合规流程中的角色及其操作
关键合规工件
图2：各种合规工件及其编程表示的示例。以PDF格式表示的法规（顶部）与以合规作为代码表示的控制和规则（中部）与用于测试系统的检查脚本作为策略的代码（底部）。
图2描述了关键合规工件的具体示例及其在人类语言中的表现形式以及合规作为代码或策略作为代码的表示形式。它说明了合规工件的以下关键方面：
- 治理方面的法规和法规控制以人类语言中的广义陈述形式表达（例如，“SC-28信息系统保护[静息状态下]的[机密性；完整性]。”），而技术方面的技术规则则以实施控制的产品和过程的具体陈述形式表达（例如，“确保云对象存储使用KYOK进行加密”）。在大多数情况下，技术规则中的措辞间接反映了控制的声明，需要产品专家生成规则，并使非专家或AI难以评估控制陈述的覆盖范围。我们将在未来的博客中展示人工智能（AI）如何通过交叉对照支持合规专家浏览法规陈述。
- 这些合规工件的表示格式从PDF、自由文本和电子表格逐渐演变为合规作为代码（例如，NIST OSCAL）和策略作为代码（例如，OPA – 开放策略代理）以实现自动化。一方面，虽然我们仍然需要PDF、自由文本和电子表格来促进用户创建和使用目录、配置文件和供应商产品规则和参数描述，但我们需要转向合规作为代码，以使合规工具和服务能够在环境中持续交换、应用和控制这些合规工件。另一方面，我们还需要将手动证据评估过程转向策略作为代码，例如Python、JavaScript或OPA Rego中的脚本，以持续测试在受管制环境中部署的产品的技术规则。在下一篇博客中，我们将展示NIST OSCAL框架及其标准语言如何用于将典型的GRC工件表示为代码。
- 实现合规自动化和持续合规的关键在于将人类语言中的广义控制陈述与具体的技术规则及其相关参数和检查的编程表示进行映射。生成此关键工件、将其注册到GRC框架并使用它提供合规状况的多步骤过程将成为我们在GRC交换协议的博客文章中探讨的主题。
结论
在这个多博客系列的第一篇博客文章中，我们介绍了治理、风险和合规（GRC）管理框架中的主要角色。正如您无疑注意到的那样，我们定义了一组特定的行动，重点是每个角色的理论分工。然而，在一个真实的组织中，一个人可能会担任多个角色，这种情况下，她将执行与所有这些角色相关联的操作。
接下来会有什么？
在我们的下一篇博客文章中，我们计划详细介绍端到端合规流程中处理的合规工件，从法规表示到合规状况到审计报告。我们还将使用NIST OSCAL标准提供它们的代码表示，提供实际可用于连续合规实施的示例，这些示例表示标准（例如NIST 800-53）、基线配置文件、评估结果等的目录，以及它们在治理、风险和合规框架中的相互依赖关系和与角色和操作的关系。
以下是本系列其他文章的链接：
- 自动合规标准解决方案（COMPASS），第2部分：Trestle SDK
- 自动合规标准解决方案（COMPASS），第3部分：工件和角色
- 自动合规标准解决方案（COMPASS），第4部分：合规策略管理中心的拓扑结构
- 自动合规标准解决方案（COMPASS），第5部分：缺乏网络边界导致合规缺失
- 自动合规标准解决方案（COMPASS），第6部分：多个Kubernetes集群的策略合规