Axon Framework vs GDPR（从域事件条目表中删除物理个人数据）答案

【问题标题】：Axon Framewok vs GDPR (delete phisically personal data from Domain Event Entry table)Axon Framework vs GDPR（从域事件条目表中删除物理个人数据）
【发布时间】：2020-09-01 14:18:48
【问题描述】：

让我们来看看当今通用数据保护条例 (GDPR) 中这个非常有趣的观点。让我们弄清楚 Axon 对以下问题的最佳答案是什么。（我正在使用带有 Spring Boot 的 Axon 4.1）我向你介绍我的问题：

用户来了，例如他想预约，他必须在其中输入他的电子邮件、电话号码等大量个人数据。在用户点击 Enter 之前，他必须接受一份隐私声明，其中包括我们存储他的个人信息的时间。因此，当用户单击 Enter 时，后端将事件源用户输入的所有信息。他的所有隐私数据都将存储到 Axon 的域事件条目表中，用于创建事件的聚合。用户的个人数据可以在有效载荷中找到。因此，当存储时间到期时，我必须从所有表中删除所有个人数据，包括 Axon 的域事件条目表。

所以我的问题是如何从域事件条目中物理删除聚合。

我试过这个解决方案：

    @EventSourcingHandler
    public void on(CampaignDeletedEvent event) {
        markDeleted();
    }

但它没有做任何事情，API 说：“将此聚合标记为已删除，指示存储库在适当的时间删除该聚合。” - 它应该物理删除？它不这样做，我等了 30 分钟，聚合仍在表中，那是什么意思“适当的时间”？

在我尝试删除失败后，我阅读了这个 stackoverflow 问题 (Axon Framework: Delete Aggregate Root)，Allard 在评论部分说：“这是正确的。使用事件溯源，“删除”并不真正存在。它只是一种状态任何其他，除了在“已删除”状态下，所有命令都被拒绝。”

好的。所以这意味着我的聚合已死，但用户的个人数据仍然存在于聚合的域事件条目表的有效负载字段中？

所以我必须以某种方式创建一个存储库并将其删除或使用 SQL 脚本，你是怎么做到的？关于新功能，我可能是错误的和过时的，但如果权威来了，罚款是 $$$$$$$$$$$$$$$

谢谢，马特

【问题讨论】：

GDPR 用例确实与事件溯源原则相冲突。那么：不要将事件溯源用于用户可识别数据？不确定这在实践中会如何发挥作用。
这是一个选项，但我不需要 Axon 框架
markDeleted 不会物理删除数据，它只会关闭此聚合流，因此不会在其上应用更多事件。请在下面阅读我的详细答案。最好的，伊万。

标签： java spring-boot event-sourcing axon

【解决方案1】：

事件溯源要求应用程序的状态更改不作为新状态（覆盖以前的状态）显式存储在数据库中，而是作为不可变系列事件。您不应删除这些事件和/或更改内容。这样您就不会丢失任何数据/信息。系统中发生的一切都被存储。这些天信息远比存储的价格更有价值，不要扔掉;)

但是，事件的某些属性不应该被所有消费者读取，我们应该能够delete它们，而无需触及事件存储（一系列事件）。此问题的常见解决方案之一是加密敏感属性，为每个资源使用不同的加密密钥。仅将密钥提供给需要它的消费者。当需要删除敏感信息时，请删除加密密钥，以确保信息永远不会被再次访问。这有效地使敏感数据的所有副本和备份不可用。这种模式被称为加密粉碎。 Crypto-Shredding 模式当然只与您的加密和密钥管理实践一样好，并且在我看来比仅在 SQL 表上运行删除更好的选择（您是否真的删除了所有数据 - 日志呢？）

Axon 为此提供了一个商业模块Axon Data Protection module (https://axoniq.io/product-overview/axon-data-protection)。

【讨论】：