问题描述
Amazon QLDB 允许通过其 ID 查询特定对象的版本历史记录。但是，它也允许删除对象。似乎可以通过删除和创建新对象而不是更新对象来绕过版本控制。
例如，假设我们需要通过 VIN 跟踪车辆注册。
INSERT INTO VehicleRegistration
<< {
'VIN' : '1N4AL11D75C109151','LicensePlateNumber' : 'LEWISR261LL'
} >>
然后我们的应用程序可以通过查询获取 VIN 的所有 LicensePlateNumber 分配的历史记录：
SELECT * FROM _ql_committed_VehicleRegistration AS r
WHERE r.data.VIN = '1N4AL11D75C109151';
这将返回所有未删除的文档修订，为我们提供不可伪造的历史记录。如果您记得插入中的文档 ID，则可以类似地使用 history 函数。但是，如果我想恶意绕过历史记录，我只需删除对象并重新插入即可：
DELETE FROM VehicleRegistration AS r WHERE VIN = '1N4AL11D75C109151';
INSERT INTO VehicleRegistration
<< {
'VIN' : '1N4AL11D75C109151','LicensePlateNumber' : 'ABC123'
} >>
现在没有任何记录表明我修改了这个车辆登记，违背了 QLDB 的全部目的。新记录的文档 ID 将与旧记录不同，但 QLDB 将无法告诉我们它已更改。我们可以使用一个单独的系统来跟踪文档 ID，但现在另一个系统将成为权威系统，而不是 QLDB。我们应该使用 QLDB 来构建这些类型的权威记录，但其他系统也会有完全相同的问题！
如何使用 QLDB 来可靠地检测对数据的修改？
解决方法
会记录原始记录及其在分类帐中的删除，正如您所指出的，可以通过 history() 函数获得。所以没有办法隐藏不良行为。这是一个希望没有人知道去寻找它的问题。同样，正如你所指出的。
这里有几个选项。首先，QLDB 上周推出了细粒度访问控制 (announcement here)。例如，这将允许您禁止对给定表进行删除操作。见the documentation。
您可以做的另一件事是使用 streaming 实时查找删除或其他可疑活动。您可以将分类帐与 Kinesis Data Stream 相关联。 QLDB 会将每个提交的事务推送到流中，您可以在其中使用 Lambda 函数对其做出反应。
如果您不需要实时检测，您可以使用 QLDB 的 export feature 做一些事情。此功能将分类帐块转储到 S3 中，您可以在其中提取和处理数据。这些块不仅包含您的修订数据，还包含用于创建事务的 PartiQL 语句。您可以设置 EventBridge 调度程序来启动定期导出（例如，当天的交易），然后通过它来查找可疑删除等。This lab 可能对此有所帮助。
我认为最好的方法是使用权限来管理它。让开发人员停止生产或让他们担任临时角色以获得有限的访问权限。