第4节
持续审计基石

提要

·　持续审计的应用需要自上而下的驱动和自下而上的实施。

·　通过持续审计确定的控制结构的管理，可以通过制定路线图来优化，将改进点纳入技术负债的待办事项列表中进行有序处理。

·　持续审计的设计应从一个能够表达其必要性的愿景开始。

·　对持续审计的有用性和必要性达成共识十分重要，这可以避免在设计过程中产生过多争论，并为统一的工作方法奠定基础。

·　变更模式不仅有助于建立共同愿景，而且有助于引入持续审计金字塔并遵循这一方法。

·　如果没有设计权力平衡步骤，就无法开始实施持续审计的最佳实践（组织设计）。

·　持续审计强化了一个追求快速反馈的左移组织的形成。

·　每个组织都必须为持续审计的变更模式提供实质性的内容。

阅读指南

本节首先讨论可以应用于实现DevOps持续审计的变更模式。该变更模式包括4个步骤，从反映持续审计愿景和实施持续审计的业务案例开始，然后阐述权力平衡，其中既要关注持续审计的所有权，也要关注任务、职责和权限；接下来是组织和资源两个步骤，组织是实现持续审计的最佳实践，资源用于描述人员和工具方面。

一、变更模式

图1.4.1所示的变更模式为结构化设计持续审计提供了指导，从持续审计所需实现的愿景入手，可防止我们在毫无意义的争论中浪费时间。

在此基础上，我们可以确定权力关系层面的责任和权限划分。这听起来似乎是一个老生常谈的词，不适合DevOps的世界，但是猴王现象（Monkey Rock Phenomenon，猴王现象可以指代人们盲目地模仿他人的行为、观点或习惯，而不考虑其真实的价值或合理性）也适用于现代世界，这就是记录权力平衡的重要性所在。随后，工作方式（Way of Working, WoW）才能得到细化和落实，最终明确资源和人员的配置。

图1.4.1右侧的箭头表示持续审计的理想设计路径。左侧的箭头表示在箭头所在的层发生争议时回溯到的层级。因此，有关应该使用何种工具（资源）的讨论不应该在这一层进行，而应该作为一个问题提交给持续审计的所有者。如果对如何设计持续审计价值流存在分歧，则应重提持续审计的愿景。以下各部分将详细讨论这些层级的内容。

二、愿景

图1.4.2展示了持续审计的变更模式的步骤图解。图中左侧部分（我们想要什么？）列出了实施持续审计的愿景所包含的各个方面，以避免发生图中右侧部分的负面现象（我们不想要什么？）。也就是说，图中右侧的部分是持续审计的反模式。下面是与愿景相关的持续审计指导原则。

1．我们想要什么？

持续审计的愿景通常包括包括以下几点。

（1）有效控制

控制的价值在于其有效性。为此，持续审计金字塔的步骤必须从TOM及其衍生的目标开始执行。

（2）快速反馈

持续审计的目的是获得持续、高频率的证据，以证明已识别的风险得到控制。所以必须进行自动化监控。这些监控结果可以为进一步的监控提供依据，也可以用来分析哪些控制措施需要调整。

（3）增长模型

为了达到设定的目标，如GDPR、税法、AFM规定、档案法、医疗保健标准框架等，需要实施一些控制措施，这些控制措施需要花费时间和金钱。其中一部分可以通过购买标准软件或云服务来实现。然而，大部分必须通过定制软件来实现。实现这些控制措施需要时间。因此，需要制定增长模型。

（4）可追踪性

审计的一个重要要求是变更的可追踪性，即谁授权了对控制的哪项变更。广义上讲，可追踪性是指追踪获取证据所依据目标的能力。有些证据的来源易于辨认，有些则不然。

例如，从解雇员工处及时撤销权限的证据的可追踪性，可以很容易与信息安全标准框架中的保密性要求相关联。但反过来，也必须能够建立这种追踪性，即哪些控制措施赋予这些目标实际内容。为了提高追踪性，目标、风险、控制措施、测量和证据都必须附加元数据。

2．我们不想要什么？

确定持续审计的愿景不包含什么通常有助于加深我们对愿景的理解，虽然从相反的角度思考之前讨论过的话题，在行文上有些冗余，但为了便于阅读理解，所以分开讨论。持续审计典型的反模式方面包括以下各点。

（1）有效控制

当在信息系统中自下而上地寻找控制措施时，它们会呈现出各种不同的形态和规模。这些控制措施可以分为不同的类别。一些控制措施是有用的，比如通过多重身份认证来保护信息。但也有过时的控制措施，因为它们所控制的风险已经不存在了，比如应用程序中那些不再使用的代码（Dead Wood）。另外，还有一些控制措施是有效的，但不符合最新的法律和法规。如果自下而上盘点这些控制措施，往往很难将它们与标准框架联系起来。因此，其有效性是未知的。

相反，人们往往不知道这些信息系统必须满足哪些目标。例如，不知道适用哪些法律和法规，以及适用哪些服务水平协议（Service Level Agreement, SLA）规范。这也导致了在这些目标发生变化时，控制措施不能及时更新。

（2）滞后的反馈

一般，每年会进行一次或两次对于控制措施的度量。在这种反馈频率下，存在滞后的反馈，因为只有在事后才知道所取得的成果是否符合期望。在瞬息万变的现代信息世界中，数字化消除了越来越多的人工任务，因此需要快速反馈。例如，程序员现在可以在几个小时内实现外部信息链接，如果不符合内部或外部目标，则需要重新调整。

（3）增长模式

实施一套像ISO 27001:2013这样的控制措施可能需要大量的工作。这项工作部分是一次性的，部分是重复性的。一次性的工作必须进行规划和实现，这将占用开发新功能或者调整现有功能的时间。部分重复性的工作也必须进行，如定期进行人工测量以获得证据。设置这些测量也需要时间。

（4）可追踪性

缺乏可追踪性不仅在控制措施的维护方面有困难，而且对于外部审计师定期提出的问题也会面临不能充分回答的风险。

三、权力

图1.4.3显示了持续审计变更模式的权力平衡，它的结构与愿景部分相同。

1．我们想要什么？

持续审计的权力平衡通常包括以下几点。

（1）所有权

在DevOps中，我们经常讨论所有权。这里我们讨论的是持续审计的所有权。对于传统的审计流程，答案很简单，因为这是内部或外部审计师的工作领域，但持续审计不同。持续的调整和高频监控由DevOps团队负责。那么问题就是，谁拥有持续审计金字塔的这一部分？答案就藏在敏捷Scrum的基本原则中。肯·施瓦伯（Ken Schwaber）在其著作《敏捷项目管理与Scrum》（2015年版）中写道，敏捷教练（Scrum Master）是敏捷Scrum框架内开发过程的所有者。敏捷教练必须让开发团队觉得是他们自己塑造了敏捷Scrum的流程和控制措施，而不是这个流程只有一个负责人。

在SoE中，这是一个很好的状态。SoE是一种有人机交互界面的信息系统。SoE的一个典型应用领域是电子商务，其中松耦合的前端应用程序允许用户自主完成交易或提供信息。鉴于这个前端（界面逻辑）与后端（交易处理）的松耦合，DevOps团队在更改前端控件方面也相当自主。DevOps团队也可以选择涵盖了许多控制措施的CI/CD安全流水线，从而自主确定和控制DevOps和持续审计的成熟度。

如果几十个DevOps团队都在开发前端应用，那么将DevOps的工作方式与持续审计相结合就会更有效和更高效。这点在SoR的背景下会更加显著。SoR是一种处理交易的信息系统，典型例子包括企业资源规划（Enterprise Resource Planning, ERP）或财务报告系统。这些信息系统通常被包括在信息处理系统链中。因此，SoR通常由按业务或技术划分的多个DevOps团队设计。

在这两种情况下，这些DevOps团队都是相互依赖的，共同应对持续审计的问题。因此，在多个DevOps团队中，正确的做法是集中分配持续审计的所有权。这样也可以制定适用于所有DevOps团队的持续审计路线图。然而，改进的优先顺序和解决方案的选择最终还是由DevOps工程师共同决定。

因为持续审计金字塔被划分为多个层级，我们就可以选择在一个或多个层级上划分所有权。这样可以更容易地在适当的层级上分配所有权。理想情况下，持续审计的所有权在组织中被分配得越低越好，这也符合加尔布莱斯（Galbraith）的不确定性降低原则。这个原则意味着DevOps团队应该能够在设计持续审计时尽可能地独立工作，而不依赖外部治理机构。

持续审计实施的一个具体方面是治理。它不一定要委托给持续审计的所有者，而是应该尽可能地分配给组织的低层。同样，金字塔的层级结构使得区分批准持续审计实施成为可能。

（2）目标

持续审计的所有者确保制定了一份持续审计路线图，明确了DevOps成熟度提升的方向。路线图可以包含一些目标，例如持续审计控制措施的部署时间表、监控工具的使用等。在已建立的持续审计能力和尚待完善的持续审计最佳实践的基础上，路线图为DevOps的工作方式设定了改进目标。因此，这些目标包括对持续审计理念的调整和对发现的缺陷的改进。

所有涉及的DevOps团队必须致力于实现这些目标，实现目标的方式可以是多种多样的。在Spotify模式中，使用了“委员会”这个术语，委员会是一个临时的组织形式，旨在深入探索某个主题。例如，可以为持续审计建立一个委员会，每个DevOps团队派出一名代表参与其中。在Safe ^® 内部也有一些标准机制，如实践社区（Communities of Practice, CoP）。此外，还可以通过敏捷发布火车在项目增量（Program Increment, PI）规划中确定持续审计的改进措施。

（3）RASCI模型

RASCI代表了责任（Responsibility）、问责（Accountability）、支持（Supportive）、咨询（Consulted）和告知（Informed）。担任“R”角色的人负责监控结果（持续审计目标）的实现并向持续审计所有者（“A”）报告。所有的DevOps团队共同致力于为持续审计的目标做出贡献。敏捷教练可以通过指导DevOps团队塑造持续审计和实现目标来扮演“R”的角色。“S”是执行者，也就是DevOps团队。“C”可以分配给委员会或CoP中的主题专家（Subject Matter Expert, SME）。“I”主要是产品负责人，他们必须了解质量评估和测试。

RASCI优于RACI的原因是，在RACI中“S”被合并到了“R”。这意味着责任和实施之间没有区别。RASCI通常可以更快地确定和更好地了解每个人的职责。随着DevOps的到来，整个控制系统已经发生改变，使用RASCI通常被认为是一种过时的治理方式。

基于对目标的讨论，很显然，当需要扩大DevOps团队的规模时，肯定需要有更多的职能和角色来决定事情的安排。因此，这就是敏捷Scrum框架与Spotify、SAFe框架之间的主要区别。

（4）治理

持续审计的良好实践在于识别改进点并将其放入产品待办事项列表中。然后，DevOps工程师可以将10%的开发速度用于解决每个迭代的技术债务。为此，他们选择一个或多个改进点，并以与其他产品待办事项相同的方式处理。唯一的区别是，在这种情况下，DevOps工程师会优先考虑这些改进。此外，改进必须在一个步骤中实施，使得其他DevOps团队从变革中获益。

（5）业务需求

获得控制权需要时间和金钱。这些资金来自业务部门，并且应该被视为提高竞争地位的控制措施的投资。控制也可以用来预防或限制损失。在这种情况下，这种投资就像是保险费。无论商业案例是什么，业务人员的参与都非常重要。毕竟，这直接或间接地改善了业务结果，同时意味着缩短上市时间并提高了服务质量。

（6）价值链

目标、风险、控制、监控设施、证据对象的生命周期是基于价值流完成的。这些价值流共同构成价值链。通过这种方式，治理可以控制持续审计的概念。

2．我们不想要什么？

以下几点是关于权力平衡的持续审计的典型反模式。

（1）所有权

持续审计所有权的反模式之一是每个DevOps团队各自为政，采用各自的方法。这种做法导致精力分散，浪费宝贵资源。否认标准化的必要性也是无法取得改进的原因。自下而上形成链条的Devops团队不是一个健康的模式。随着DevOps团队的扩大，他们也不太愿意在持续审计方面标准化工作方式。

（2）目标

如果组织单纯理解持续审计的重要性，只关注其商业利益，例如持续审计在认证或投标中发挥作用，则很容易为持续审计的应用和成果设定过高的目标。然后，这些目标直接压在DevOps工程师身上。在最坏的情况下，组织还会提供应对独立审计师测试的培训。这种做法往往适得其反，因为成熟度主要是DevOps工程师的一种行为效应。强迫工程师反而引发抵触情绪，导致绩效下降。持续审计的目标以及间接影响到的DevOps工程师的成熟度必须是自下而上确立的。

（3）RASCI模型

RASCI最重要的是确保DevOps团队主动参与，这需要在组织中设计持续审计层。反模式是由质量保障（Quality Assurance，QA）部门来进行单独评估，然后将其强加给DevOps团队。为了避免这种情况，评估结果应由DevOps团队自行呈现，即自我评估并加以认可。

（4）治理

缺乏对改进点的协调会导致工作方式的多样化，例如控制措施的定义和构建方式的不统一。这正是我们需要避免的，因此必须对改进实施进行治理，通过投入改进和相互学习，节省其他DevOps团队的时间和精力。

（5）业务需求

由信息技术驱动的持续审计是无效的，必须建立起持续审计与业务价值流的结果改进之间的桥梁。业务价值流是持续审计目标设定的组成部分。将持续审计孤立化会大大降低实现结果改进的可能性。

（6）价值链

风险管理需要对作为价值链一部分的价值流进行调整。如果不定义以控制措施有效性为核心的持续审计价值链，就会造成对这些控制措施的治理分散，降低其整体效能。

四、组织

图1.4.4显示了持续审计的变更模式的组织步骤，其结构与愿景和权力关系的结构相同。

1．我们想要什么？

持续审计的组织层面通常包括以下几点。

（1）简单的控制

最好以模块化的方式定义控制措施。这不仅简化了设计和实施，而且也更容易调整和监控。在出现偏差的情况下，也能更快找到原因。小型控制措施也更容易进行规划并被纳入敏捷Scrum的迭代中。

（2）基于风险的控制

如果控制措施为风险管理提供了实质内容，那么它们就会产生结果。因此，将风险作为一个对象来定义，并定义控制风险的控制措施就显得尤为重要。

（3）受监控的控制

控制措施的状态应自动进行监控，这就需要一个监控功能。

（4）证据信息

在监控控制措施时提供的证据必须有固定的结构，例如XML文件或JSON格式。

（5）测量说明

为了获得证据信息，控制的定义必须包含控制的测量规则。

（6）维护控制

如果TOM、目标、监控设施和证据结构要求变更，控制措施就可能需要更新。

2．我们不想要什么？

以下几点是关于组织层面的持续审计的典型反模式。

（1）简单的控制

以通用计算机控制（General Computer Control, GCC）为代表的一些控制框架包含复合控制。这意味着只有当一系列的控制措施符合要求时，才能达到合规要求。不过我们并不推荐这种方法，因为它会夸大合规程度，低估实际风险。

（2）基于风险的控制

为了消除或减轻风险，ISO 27001:2013标准定义了114项控制措施。重要的是找出哪些风险受这些控制措施的控制。另外，ISO 27001:2013并不禁止遗漏控制措施。但我们并不建议这样做，因为为这种遗漏辩护的成本可能比实施控制的成本更高。

（3）未经监控的控制

未设定监控机制的检查是不完整的，它会导致无法确定是否达到质量标准。

（4）证据信息

对证据的单独定义会使证据处理过程变得过于复杂。对于证据的元数据，例如涉及的控制措施、测量对象和控制状态等，标准化这些特征可以更轻松、更快速地绘制信息系统受控程度的整体概况。

（5）测量说明

测量控制以获得证据很重要，但是如果采取了错误的测量方法，就会对控制程度产生错误的印象。例如，即使确定一台服务器正在执行活动，也不意味着用户可以正常访问服务器上的信息系统，因为有可能数据库已经满了或者网络出现了中断。

（6）维护控制

大多数组织对信息系统适用的合规义务缺乏清晰的认识，更难以判断控制措施是否得到有效维护。在这种情况下，审计往往沦为寻找证据并解释其缺失的过程，难以发挥应有的作用。

五、资源

图1.4.5显示了持续审计变更模式的手段和人员（资源）步骤，它的结构与愿景、权力关系和组织的结构相同。

1．我们想要什么？

持续审计在资源和人员层面通常包括以下几点。

（1）整合人力资源管理

DevOps工程师的发展通常由组织内部的某个人负责，例如部门经理或者人力资源管理经理负责。重要的是，要根据任务明确DevOps工程师在持续审计中所扮演的角色，并制定他们的岗位描述。持续审计的角色可以包括特定的业务分析角色到E类型的DevOps工程师不等。通过将持续审计映射到现有的岗位描述，可以确定岗位描述中存在的差距，并有意识地选择谁做什么。

（2）技能矩阵

技能矩阵描述了职能、角色、任务与所需技能之间的关系。通过定义持续审计所需的技能，可以丰富现有的技能矩阵，还可以测试员工是否具备这些技能以及他们的掌握程度。

（3）个人教育计划（Personal Education Plan, PEP）

基于人力资源管理和技能矩阵的整合，可以制定个人教育计划。

（4）监控设施

设计持续审计的重要条件是拥有可以监控多种对象的监控系统。

2．我们不想要什么？

以下几点是关于人员和资源层面的持续审计的典型反模式。

（1）整合人力资源管理

人力资源管理的反模式是无法针对能力发展进行引导。这会使得培训难以跟进，个人提升只能在工作岗位上靠自己的主动性来实现。

（2）技能矩阵

没有技能矩阵往往会导致技能差距，这些差距不会被明确识别。但后果会很明显。解决方案通常是多次应用次优方案，但这并没有有效、高效地弥补技能差距。

（3）个人教育计划

缺乏个人教育计划会很快导致员工失去动力并离职，低培训预算的个人教育计划也是一个降低士气的因素。

（4）监控设施

如果监控设施存在漏洞，就无法证明控制到位。在最糟糕的情况下，已识别的风险将会发生。 1JHc0LxvYeh7ozHAzJj/IjMf/dE7ZFRpDHF7vWT1YFWmdjsSWxH8poJjQq1gGku9