2016-06-08 67 views
3

是否有任何方法或体系结构设计模式实现安全,干净的基于角色/权限的访问控制和UI方便,而无需将它们耦合在一起?如何避免滥用用户界面的角色和权限?

长话短说。

我在许多Web应用程序中看到了对角色和权限的模糊使用,并且我经常体验到这些歧义是如何引起误解和实现困难的。

这里是一个简化的例子。

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

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

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

这种情况提出了一个问题:“为什么不应该在某些特定角色的用户看到摆在首位地址的完整列表,如果他们通过一些其他途径访问列表?”而答案我经常从业务分析师那里得到这样的信息:“好的,地址列表并不是出于数据安全的原因而被禁止的,而仅仅是因为这个特定角色的用户不希望对地址列表做任何事情,并且这将是他们工作区中的冗余项目” 。

所以,现在这个问题在我看来很清楚:存在一些权限只是为了控制UI而不是严格控制对某些数据的访问。这种(ab)使用权限对我来说是错误的。因此,这是最初提出的问题。

回答

2

好写!几乎觉得你已经有了答案。

IMO用户分析和用户访问不是同一回事。应该尽可能低地处理访问权限(例如,如果用户是否具有对特定SQL表的读取访问权限),并且此情况下的配置文件应该仅应用于UI级别(“用户实际上想要或需要的内容看到”)。

当我们谈论具有某种访问权限控制的应用程序时,UI背后几乎总是有某种“引擎”实际上存放着所有数据。你可以做的最糟糕的事情是在发动机本身以外的任何地方实施安全。除了通过引擎自己的访问控制,否则数据不能以任何其他方式访问,否则不能访问控制 - 这是UI限制。

但是,这是完美世界:/在现实中,像在工作的各个领域,软件开发也已行驶torwards被越来越多的成本效益,灵活性和响应到客户端。毫不奇怪,这引导人们做快速和廉价的决定......像“地狱,我们只是使拉动数据的另一个SQL程序出来作为管理员”,而不是“我们需要重新评估用户的访问权限,和/或可能重新设计我们的表,以保持一致性的访问权限”。当它完成时,它始终是一个短期(坏)解决方案,但有些解决方案肯定比其他解决方案更多。

作为指导我会说,如果你不是110%肯定,你在做什么,这是一个最大的NO-NO存在。

TL; DR:如果有些数据甚至应该在一个地方进行访问,它不是由访问控制限制。如果不需要在某处显示可访问的数据,请使用用户/应用程序分析进行过滤。