security - 如何在我的新 API 中保护数据访问？

Question

我正在设计一个 API，我想问几个关于如何最好地保护数据访问的问题。

假设 API 允许访问艺术家。艺术家有专辑，有歌曲。

API 的用户可以访问所有艺术家的子集。如果用户调用 API 请求某个艺术家，很容易检查用户是否被允许这样做。

接下来，如果用户请求专辑，API 必须检查专辑是否属于允许用户访问的艺术家。访问歌曲意味着 API 必须先检查专辑，然后检查艺术家，然后才能授予访问权限。

在数据库方面，我正在观察为添加的每个附加层增加表之间的连接数。我不想做所有这些连接，我也不想为了限制连接数而到处存储用户 ID。

为了解决这个问题，我想到了以下方法。

API 为用户提供对象的引用，例如艺术家对象。然后用户可以向该艺术家对象询问专辑，该对象返回一个列表对象。可以遍历列表对象，从中获取相册对象。同样，可以从专辑对象中获取歌曲列表对象，并从中获取单个歌曲对象。

由于 API 信任艺术家对象，因此它也信任用户从中获取的任何对象(在本例中为专辑)，无需进一步检查。对于所有其他对象，依此类推。所以我将安全/信任委托(delegate)给链下的对象。

我想问问你对它的看法，它的好坏，当然还有你会如何解决这个“问题”。

第二，如果 API 应该是 RESTful，您将如何处理这个问题？我的方法似乎不太适用于那种情况。

Answer 1

这是一个真实的程序还是一个用来说明问题的示例？因为不清楚为什么您要限制对艺术家和专辑的访问，而不仅仅是对单个媒体项目甚至轨道的访问。

我不认为连接应该花费你那么多，当你在多个表上进行相当简单的条件匹配时，任何半智能数据库系统都会以足够低的成本完成它们。

恕我直言，将那么多安全逻辑放入查询中的问题在于它限制了您处理肯定会绑定(bind)的更复杂的 DRM 问题的能力。例如，如果专辑是多位艺术家的合集怎么办？如果专辑包含一首二重唱轨道而我只能访问一位艺术家怎么办？等等等等

我的观点是，在这些情况下，具有合理异常的便捷编程模型比单个查询的性能重要得多，您可以在将来缓存或优化单个查询。您尝试对查询执行的操作听起来像是过早的优化。

尽可能灵活地设计您的编程模型。定义合理的扩展，然后在分析真实系统后着手实现数据库和优化查询。