我们的客户(银行)需要发布一个web服务API,供第三方应用程序使用。安全性将涉及OAuth2和JWT (JSON令牌)。问题是,客户害怕第三方滥用他们不完全信任的发布的API(请不要对此发表评论)。一个基本的场景如下:
公共API包含一个操作IsOurCustomer(),如果此人在银行中有产品,该操作将返回true/false。随后的操作是CreateNewCustomer(),并在IsOurCustomer()返回false时调用。
银行担心第三方可能会通过顺序调用IsOurCustomer()来检查谁是或不是他们的客户,从而扫描他们的客户群(例如从公共州注册中心)。(我无法判断假定的损害是真实的,还是仅仅是偏执。)
我们提出了一些局部的解决方案,但没有一个完全缓解这个问题:
发布于 2016-11-15 17:08:21
对我来说这听起来是合理的考虑。
您不会详细介绍第三方使用api的目的。
让api的每个“租户”创建自己的客户,并在需要报告时将客户与银行客户私下联系起来。
也许您有一个更复杂的场景。
在这些数据保护的日子里,这是相当普遍的。世行需要认识到,这是一个人的问题,而不是一个技术问题。
但是,也许你有一个更微妙的情况!
发布于 2016-11-15 18:44:49
您可以考虑合并这两个操作。让CreateNewCustomer检查现有客户,并返回一条消息,说明它是现有的客户,并包含现有的客户id。这样,你就不能在没有创建新客户的情况下扫描一个大型数据库,这可能需要某种形式的电子邮件验证步骤,或者其他会引起注意的东西。
发布于 2016-11-15 21:54:30
这是一个严重的风险,我认为,但有一个方法可以让你信任某些人。
我假设第三方有一个合法的需要知道某人是否是您的客户。
我会给每个第三方一个他们负责的标识符,该标识符将他们标识为API。然后,此标识符链接到一个非规范化表,该表引用客户的唯一id。如果非正规化组合不在表中,那么对于所有意图和目的,第三方都不知道客户的存在。
因此,您有与第三方1有关系的客户A,而不是第三方2。很自然,您只想让第三方1看到这个客户,所以当第三方2打电话给客户A的信息,但是他们的id,他们会得到这个客户不存在的回复(或者你想给出的任何错误)。然而,第三方1可以安全地调用相同的API,并获得有关客户的信息。
编辑:我还假设您正在对这些端点进行适当的安全保护,这样只有您信任的第三方才能访问它们,而不是街上的某个随机的家伙。由于这些数据可能是FINRA规范的,所以您有义务保护它。
https://softwareengineering.stackexchange.com/questions/336110
复制相似问题