当使用请求/重放通信时，很容易实施数据安全策略，因为拥有数据的服务可以对每个请求执行检查 - 当然这会破坏自治，因为它引入了时间耦合，服务SLA依赖于其他服务。
如果使用自治服务，则与权威服务相关的数据子集将存储在订阅相关事件的多个其他自治服务中。
如何确保服务使用并随后发布其原始权威服务的安全策略中的数据子集和/或转换？
我想到的一个解决方案是创建一个策略服务，但是：
在实施安全政策时，是否有关于实体数据汇总的最佳做法/建议？
非常感谢！
更新 为了澄清，我的问题是即使服务边界是正确的，UI组合也会出现问题，因为它需要一个聚合数据存储，以便能够提供性能排序和过滤 - 就像Udi Dahan所称的IT / Ops服务。 这样做的原因是每个服务的每个组件只知道字段的子集，因此除非聚合数据，否则无法有效地处理排序和过滤。 如果不需要排序，每个服务组件将强制执行它自己的策略。然而，即便如此，在某些情况下，我们可能会发现自己处于选择n + 1状态，没有聚合存储 - 我正好看了Arnon Rotem-Gal-Oz所描述的Aggregated Reporting Pattern。它没有讨论安全问题，我认为这意味着聚合报告服务中的安全策略重复......
此外，发布/分发敏感信息是否可行？此外，你发布的内容是合同的一部分，但如果政策要改变，你就不会再发布这些信息了 - 这会改变合同......正如我所说，req / reply很容易解决这个问题......
我很可能在所有帐户上都错了，所以我很感激任何想法！ ： - ）
答案 0 :(得分：0)
我解决的解决方案是使用策略服务，该服务将充当消费者与权威服务和聚合服务之间的中介。这样，安全策略就在一个地方实现：既不在权威服务中，也不在聚合服务中，而是在策略服务中。
UI组合将以请求/回复方式运行，并由策略服务调解。此外，对权威服务的订阅将基于角色，因此只有授权的消费者才能直接使用敏感消息。规则是，如果暴露数据，那些消费者将需要通过相同的政策服务进行访问，这样他们就不会成为安全漏洞。