审计与检查点

审计：谁、做了什么、何时、在哪

前几节管「能不能」，这一节管「做了什么、为什么」。审计日志是平台对每一步操作的精简记录，要回答四件事：谁做的（用户、会话或服务账号），做了什么，什么时候，在哪个资源上。它是提炼过的记录：太啰嗦的日志信息更多，却没人读得懂。

官方按「发生了什么」给事件分类，而不是按产品：查数据、导出数据、登录各是一类。想知道「有没有人把数据带走」，只看导出这一类，不必先弄懂每个产品的事件名；新功能也会落进已有的类别，监控规则不用跟着改。日志量很大，分析之前先按时间过滤。

检查点：动手之前问一句为什么

审计是事后的账，检查点是事前的一问。用户要做一件敏感的事，比如导出数据、给别人加权限、提交 Action，界面先拦一下，要一句理由。理由被记下来，供数据保护的人事后复核。

• 确认：勾选一个复选框，表示知道规矩。
• 文字：自由填写，可以用正则校验格式。
• 下拉：从预设的理由里选一个或几个，还可以补一段文字。
• 重新认证：让用户重新登录一次。

一条记录包含：谁、何时、检查点类型、当时的提示文字、理由，以及涉及的资源或对象。提示文字是快照，之后改了配置也不变；标题少于 45 个字符才显示得完整。官方在 60 多种交互上接入了检查点。

在 AIDC 里：账在哪里

AIDC 今天有四本账，都不用你另外接：

aidc semantic objects log.approve-purchase-order --page-size 20
aidc semantic edits-history purchaseOrder --pk <poNo>
aidc resources roles <rid>
aidc workflow runs <slug> --limit 20

四条命令依次是：看批准采购订单的日志，看某张订单的改动历史，看一个类型上的授予，看某个工作流最近的运行（运行记录保留 180 天）。

检查点的位置，现在用一个办法补：把理由做成 Action 的必填参数。在 approve-purchase-order 的 parameters 里再加一项：

{ "name": "reason", "type": "string", "required": true, "maxLength": 200 }

追一条：谁批准的、为什么

星期一早上有人问：这张采购订单是谁批准的？按下面四步，账能对上：

1. 谁

   打开 log.approve-purchase-order，找到这张订单，读「执行人」。

2. 为什么

   同一条记录的参数里有 reason。

3. 前后改过什么

   aidc semantic edits-history purchaseOrder --pk PO-1001 看每一次改动。

4. 有没有越权

   提交条件已经拦住「创建人批准自己的订单」；再用 aidc resources roles RID 看他当时有什么角色。

四步里有一步答不出，就是账本上的缺口：补参数、开日志，或者收紧授予。下一节换一个方向：怎样安全地改本体（Ontology）本身，从分支开始。