第1节
持续审计简介

阅读指南

本节介绍“持续审计”这一章的目的、定位和结构。

一、目标

本章的目标是讲述持续审计的基本知识以及应用持续万物这一领域的技巧和窍门。

二、定位

持续审计是持续万物概念的一个方面。本章包含了持续实施合规性的各种技术，这些技术可以在开发过程中不断提高信息系统的质量。“持续”一词指的是采用增量和迭代的方式开发软件，形成一个代码流，并通过CI/CD安全流水线持续过渡到生产环境。这个代码流就如同一条价值流，需要不断优化。

持续审计是一种敏捷方法，我们可以在设计信息系统的过程中定义它的行为、功能和质量，用来实现所需要的控制，从而减轻或消除已识别的风险。持续审计与DevOps 8字环的所有方面有直接或间接的关系，因为它是整体设计的。这意味着持续审计涵盖了信息系统（技术）、生产过程（流程）以及知识和技能（人员）等多个方面。因此，持续审计提供PPT（People, Process, Technology，人员、流程和技术）层面的设计。

信息系统的设计是确保系统控制安全的重要基础。近年来，许多组织质疑信息系统的设计。将信息系统的信息捆绑起来并让所有利益相关方参与进来的传统做法被敏捷的工作方式和三人组开发策略视为已经过时的理念。这个做法意味着要从业务、开发和测试三个方面提前考虑一个要构建的增量，这样就能更好地解决“怎么做”和“做什么”的问题，并能就增量的完成定义（Definition of Done, DoD）达成共识。但是，这忽略了设计另一个重要的功能：控制功能。该功能旨在通过实施适当的对策来防止因缺乏措施而导致的风险，包括但不限于违反法律和监管义务的风险。信息安全也是至关重要的控制要素，它涵盖信息的保密性、完整性和可用性。

从持续审计角度来看，DevOps领域的发展至关重要。目前，一些组织仍在采用瀑布式项目的工作方式，这种工作方式需要进行大量的设计工作；而另一些组织则发现仅仅使用用户故事并不是最佳方案，某种形式的设计仍然是必要的。因此，系统开发领域再次趋于平衡，为持续审计提供了坚实的基础。

当然，问题在于是否所有类型的信息系统都应该采用同样的工作结构。随着Gartner的商业智能（Business Intelligence, BI）模型的出现，区分记录型系统（System of Records, SoR）和交互型系统（System of Engagement, SoE）变得至关重要。除了SoE，现在人们还谈论智能型系统（System of Intelligence, SoI）。图1.1.1概述了这三种类型的信息系统（SoR、SoE和SoI）之间的关系。

（1）SoR

SoR是后台办公室的信息系统，完成财务、物流、库存和人力资源管理（Human Resource Management, HRM）任务。这些系统由政府监管，必须满足多种法律和监管要求，例如税务机关、荷兰中央银行（De Nederlandse Bank, DNB）和荷兰金融市场管理局（Anthority for the Financial Markets, AFM）的规定。此外，《萨班斯-奥克斯利法案》（ Sarbanes Oxley , SoX）和《通用数据保护条例》（ General Data Protection Regulation , GDPR）也是证明信息系统设计合法化的依据。

财务信息系统还必须满足会计师的要求，以便在年度账户获得签名。这意味着，除了其他事项外，还需要设计方案来表明财务数据是如何产生的，以及不同相关信息系统的接口是什么。这些系统通常是信息系统链的一部分，需要经过深思熟虑，因此合规性在设计中发挥着重要作用。

（2）SoE

销售渠道，特别是网络商店和智能手机应用程序，是面向消费者的SoE的主要目标。这些应用程序可以轻松地提供新版本、补丁和更新。这些信息系统通常不是信息系统链的组成部分，而是链条的终点。在敏捷开发和运维一体化（DevOps）的相关出版物中，它们也经常被用作案例。对于这些信息系统而言，显然事先经过考虑的设计（前置设计）是不太必要的，通常它们可以用成长式设计（新兴设计）来满足需求。

然而，实践证明对于这些SoE来说，仅仅具有一系列用户故事是不够的。更重要的是，用户故事通常会被放置在迭代的待办事项列表中，并在迭代完成后进行归档。这会导致单独的用户故事并不能形成对信息系统的可访问描述。因此，仍然需要一种能够提供对系统功能、质量和运行状况的概览和洞察的设计方案。尤其重要的是，用户界面和数据源接口是安全和持续审计的重要方面。

（3）SoI

除了上述系统，还存在BI解决方案，具体指各种报告、数据分析工具等。与SoE类似，BI能基于SoR的信息进行呈现，并且更易于修改。然而，数据泄露始终是一项潜在风险。风险的高低取决于所提供信息的价值。因此，必须准确评估信息风险并采取相应的防范措施。

（4）持续审计的必要性

对于三种类型的信息系统（SoR、SoE和SoI），都需要一定程度的控制，因此我们需要进行持续审计。

单靠一组用户故事并不能全面了解和监控信息系统所承受的控制要求，也难以及时、准确地识别出适应和扩展信息系统所带来的风险和影响。然而，必须避免风险应对措施（控制）的实施破坏生产过程的敏捷性。这意味着，不仅控制的设计和监控要增量迭代地进行（持续审计），而且控制也必须基于加权风险进行选择，控制措施既不能太多，也不能太少。控制设计定义的程度可随信息系统类型而变化，从SoR的详细定义到SoE的精简定义，再到SoI的近乎无定义。即使对于SoR，控制设计也可以分为前置定义（提前）和新兴出现（迭代）的两个层面。

三、结构

本章介绍了如何使用持续审计金字塔模型来塑造持续审计。在讨论该模型之前，首先将讨论持续审计的基本概念和基本术语、定义、基石和架构。接下来的几节所介绍的内容是对该模型的讨论。

1．基本概念和基本术语

本书的这部分阐述了持续审计涉及的基本概念和基本术语。

2．持续审计定义

有一个关于持续审计的共同定义是很重要的。因此，本书的这部分界定了这个概念，并讨论了信息系统设计和管理不当所造成的潜在问题及其成因。

3．持续审计基石

本书的这部分讨论了如何通过变更模式来定位持续审计，在此我们将得到以下问题的答案：

·　持续审计的愿景是什么（愿景）？

·　职责和权限是什么（权力）？

·　如何应用持续审计（组织）？

·　需要哪些人员和资源（资源）？

4．持续审计架构

本书的这部分介绍了持续审计的架构原则和模型。架构模型包括持续审计金字塔模型和持续控制模型。

5．持续审计设计

持续审计的设计定义了持续审计价值流和用例图。

6．持续审计最佳实践

本书的这部分介绍了如何构建控制框架，并讨论了一些持续审计最佳实践。

7．持续审计实施

第8、9、10节（持续审计概念、CA工具设计、持续审计实施）讨论了如何将持续审计应用于实际操作。 Vuq71/7TClraYxbBlf90Ad4NiShfmJVv5LpsuA9LtAJItemw26J+j25l2noun0G+