【问题标题】:How to avoid abusing roles and permissions for user interface?如何避免滥用用户界面的角色和权限?
【发布时间】:2016-10-08 14:07:53
【问题描述】:

是否有任何方法或架构设计模式来实现安全、干净的基于角色/权限的访问控制和 UI 便利性,而无需将它们耦合在一起?

说来话长。

我在许多 Web 应用程序中看到了对角色和权限的模棱两可的使用,并且我经常经历这些模棱两可如何导致误解和实施困难。

这是一个简化的例子。

业务需求表明,为某些特定角色设置的权限应拒绝访问系统中显示完整地址列表的某些部分。但与此同时,该角色的用户需要阅读其他网页上自动完成列表的地址。

我看到鲁莽的开发人员如何创建一个权限条目来禁用对地址的访问,后来他们发现用户实际上需要从系统的其他部分读取地址。然后他们为可以读取地址的特殊情况发明了另一种特定的权限。

但对我来说,这似乎是模棱两可且具有潜在风险的情况。如果用户无权访问某些特定数据,那么他/她应该根本无法访问它。时期。仅为下拉列表添加特殊权限似乎是一个故意的安全漏洞。如果用户通过异步请求加载列表并且服务器正在使用相同的控制器操作来返回列表(并且应该 - 以避免代码重复),那么服务器将如何知道它何时不应该返回地址,如果它们是有时禁止?

这种情况提出了一个问题:“如果某些特定角色的用户可以通过其他方式访问列表,为什么他们不应该首先看到完整的地址列表?”我经常从业务分析师那里得到的答案是“嗯,地址列表不是出于数据安全原因而被禁止的,只是因为这个特定角色的用户不应该对地址列表做任何事情,这将是多余的项目在他们的工作区”。

所以,现在问题对我来说似乎很清楚:某些权限仅用于控制 UI,而不是严格控制对某些数据的访问。这种(ab)使用权限对我来说是错误的。因此一开始就提出的问题。

【问题讨论】:

    标签: user-interface architecture permissions access-control


    【解决方案1】:

    文笔不错!感觉你已经有了答案。

    IMO 用户分析和用户访问不是一回事。访问权限应尽可能低级别处理(例如,用户是否具有对特定 SQL 表的读取访问权限),在这种情况下,分析应仅适用于 UI 级别(“用户实际想要或需要什么见")。

    当我们谈论具有某种访问权限控制的应用程序时,几乎总是在 UI 后面有某种“引擎”来实际保存所有数据。你能做的最糟糕的事情就是在引擎本身之外的任何地方实现安全性。除了通过该引擎自己的访问控制之外,绝不能以任何其他方式访问数据,否则它不是访问控制 - 它是 UI 限制。

    但这是一个完美的世界:/ 实际上,就像在所有工作领域一样,软件开发也已朝着越来越具有成本效益、敏捷和响应客户的方向发展。毫不奇怪,这会引导人们做出快速而廉价的决策……比如“地狱,让我们创建另一个以管理员身份提取数据的 SQL 过程”而不是“我们需要重新评估用户访问权限,和/或可能重新设计我们的表格以保持与访问权限的一致性”。当它完成时,它总是一个短期(坏)的解决方案,但有些解决方案肯定比其他解决方案更多。

    作为指导方针,我会说,如果你不是 110% 确定自己在做什么,那就是最大的 NO-NO。

    TL;DR:如果某些数据即使在一个地方也可以访问,则不受访问控制的限制。如果不需要在某处显示可访问的数据,请使用用户/应用程序分析来过滤它。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-10-20
      • 1970-01-01
      • 2014-08-08
      • 1970-01-01
      • 2015-05-28
      • 2017-10-13
      • 2020-10-18
      • 2015-11-26
      相关资源
      最近更新 更多