From Audit Requirements to Computable Software Architecture: A Rule-Engine and Evidence-Indexing Method for Trusted Digital Infrastructure
本文提出了一种规则引擎与证据索引方法论，通过构建分类模型、映射矩阵和验证算法，在设计阶段早期嵌入可执行控制，从而弥合审计需求与软件架构之间的语义鸿沟，进而降低修复成本并实现审计就绪的数字化基础设施。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在建造一个规模宏大、高度安全的银行金库。在旧有的模式下，你会先建造整个金库，安装好门和摄像头，然后在完成之后，才聘请一名检查员并听他说：“噢，顺便提一下，我们需要在后门加一把第二把锁，而且摄像头需要连接到不同的服务器。”这会导致拆墙、重新布线以及昂贵的修复成本。
这篇论文提出了一种不同的方法：从第一天起，就将安全规则直接构建进蓝图之中。
以下是作者 Jinyuan Li、Ruijie Ma 和 Yicheng Gu 针对数字系统（例如用于管理数字资产的系统）所建议的方法的简单分解。
1. 核心问题：“翻译官”的鸿沟
作者指出存在一种语言障碍。
- 审计员使用的是类似于“我们需要证明只有经理批准了这笔交易”之类的规则。
- 软件架构师使用的是类似于“我们需要一个数据库表和一个 API 端点”之类的代码。
通常情况下，这两组人直到软件已经构建完成后才会进行沟通。其结果是，安全性和合规性变成了后期添加的“补丁”，这既混乱又昂贵。
2. 解决方案：“规则引擎”与“证据索引”
作者创建了一种方法，可以在编写第一行代码之前，直接将审计规则转化为软件的 DNA。他们使用了三个主要工具：
A. “翻译矩阵”（配方书）
可以将其想象成一本巨大的配方书，能将模糊的规则转化为具体的原料。
- 规则： “我们需要知道谁更改了这些数据。”
- 翻译： 系统会自动识别出它需要创建一个“版本锁”（Version Lock）、保存一个“变更日志”（Change Log），并生成数据的“数字指纹”（哈希值）。
- 结果： 与其让人类去猜测如何编写代码，不如让系统明确知道需要开启哪些“功能模块”（例如登录服务或日志服务）。
B. “规则引擎”（保镖）
一旦规则被翻译完成，它们就会被加载到“规则引擎”中。想象一下这是一个在俱乐部门口检查名单的保镖。
- 如果你试图在没有第二个人签名的前提下批准一笔交易，保镖（软件）会立即阻止你。
- 如果你试图访问你不被允许访问的文件，保镖会拦截你。
- 这一切都是作为正常流程的一部分自动发生的，而不是事后才补救。
C. “证据索引”（数字档案柜）
在过去，证明你遵守了规则意味着要在杂乱的纸质记录或分散的计算机日志中苦苦搜寻。
- 作者提出了一种系统，其中每一次操作都会自动生成一份“收据”（证据）。
- 这些收据会被盖上唯一的 ID、时间戳和数字签名。
- 它们会被立即归档到一个特殊的“证据库”中。
- 类比： 这就像是一个智能档案柜，在你签署文件的瞬间，它会自动为文件拍照，盖上日期戳，然后将其放入一个只有审计员才能打开的锁定抽屉里。你不需要事后去寻找纸质文件；它们已经整齐地准备好了。
3. 他们是如何测试的：数字资产平台
团队在一个“数字资产管理平台”（一个用于管理数字货币或代币等的系统）上测试了这种方法。他们对比了两种场景：
- 场景 A（旧方法）： 先构建系统，然后再尝试添加安全规则。
- 场景 B（新方法）： 从设计之初就将安全规则构建进去。
结果如下：
- 更少的修复： “旧方法”需要对系统的接口（例如改变门的形状）进行 24 次更改。而“新方法”仅需 7 次。
- 更少的重写： “旧方法”需要修补 16 个数据结构（例如重新布线管道）。而“新方法”仅需 3 个。
- 更快的测试： 测试“新方法”仅耗费了 58 小时的工作量；而“旧方法”则耗费了 143 小时。
- 更好的证明： “新方法”能够自动准备好 95% 的所需证据，而“旧方法”仅为 70%。
4. 底线结论
这篇论文认为，通过将审计要求视为可计算指令（类似于代码）而非仅仅是文本文档，你可以构建出默认即具备“审计就绪”能力的系统。
与其盖好房子后才发现忘了设计逃生通道，不如直接在蓝图中画出逃生通道。当房子建成时，逃生通道已经存在，且完美集成，随时可以接受检查。这节省了成本，减轻了压力，并使数字基础设施更加值得信赖。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。