如何保护新 API 中的数据访问？答案

【问题标题】：How do I secure data access in my new API?如何保护新 API 中的数据访问？
【发布时间】：2010-10-15 13:48:28
【问题描述】：

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

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

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

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

在数据库方面，我正在查看每个添加的附加层的表之间的连接数量不断增加。我不想进行所有这些连接，也不想到处存储用户 ID 以限制连接的数量。

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

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

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

我想问你对它的看法，它的优点或缺点，当然还有你将如何解决这个“问题”。

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

【问题讨论】：

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

执行连接可能比您的对象方法快得多（尽管它更优雅）。对于连接，您只有一个数据库请求，而您有很多对象。（或者您必须在第一个请求中检索所有“可能的”数据，这也可能会减慢速度）

我建议进行连接。如果有关于 sql 的问题，您可以在 stackoverflow 询问：D

另一个想法：

如果你制作像“/beatles/whitealbum/happinesisawarmgun”这样的网址

那么您会在请求开始时就知道艺术家，并且无需遍历即可立即获得许可 - 因为 url 包含遍历信息。只是一个想法。

【讨论】：

【解决方案3】：

最好为每个资源添加一个安全描述符，而不仅仅是顶级资源。在您的示例中，安全描述符只是艺术家 ID 或艺术家 ID 列表，如果您支持二重奏等。所以我会考虑将 ID 列表添加到艺术家和歌曲表中。您可以添加一个字符串字段，其中资源的艺术家 ID 将以逗号分隔的方式写入。

这样的解决方案可以很好地扩展，您可以添加更多层而不增加安全检查所需的时间。添加新资源也不需要任何额外的惩罚，除了要插入一个更多字段（基于资源的父字段）。当然，此解决方案支持上述特殊情况（如多个艺术家等）。

这种解决方案也不违反 RESTful 架构。

并且每个资源都包含自己的安全描述符这一事实概括了资源的访问权限，使得将来可以实现一些完全不同的安全策略（例如，使访问权限更加精细，基于专辑，而不仅仅是艺术家） .

【讨论】：