Question

CONTEXT

我刚读过有关Zend ACL的文章 http://framework.zend.com/manual/en/zend.acl.html

问题

我在一台服务器上运行三个Zend应用程序。

我的前端应用
我的前端会员应用
我的后端应用程序（站点所有者的管理员）

在应用程序中，我正在考虑使用两种类型的ACL。

Application Wide ACL - ''app ACL'''权限只是 - “访问”（或者称之为“读取”，（甚至称为“SendHTTPRequests”））
帐户范围 - 将所有其他权限保留给个人“帐户ACL”<'li>

我认为这样可以更容易阻止垃圾邮件发送者和其他攻击者

if (UserActivityScoresHighProbabilityOfHacking_Specification->IsSatisfiedBy(User))
 {
 User->addrole(Attacker)
 }

也许有这样的规则：

我的前端应用访问控制

姓名=攻击者
唯一权限=无
从= N / A

姓名=来宾
唯一权限= SendHTTPRequests
从= N / A

姓名=会员
唯一权限= SendHTTPRequests
从= Guest

名称=管理员
唯一权限=（所有权限）
从= N / A

其他应用程序将有更严格的规则拒绝访问客人等

所以要回答的问题是：

将“攻击者”（负面角色）角色分配给用户会将您视为明智之举。

或者这与一般的最佳做法相反？

Answer 1

使用ACL基本上有两种理念：

在启动时拒绝全部，并且只有在检查了黑名单/白名单/权限以及您想要的所有支票后才能访问资源。
允许所有人在启动，然后拒绝访问敏感区域，只有在检查后才允许访问。

我更喜欢和第一个一起去。当你有小区域需要保护并且大多数是公共区域时，第二个更好。检查每个电话会给你的应用增加一些分量。

Answer 2

经过几天的思考......这是我对上述问题的回答：

将“攻击者”（负面角色）角色分配给用户会使您觉得这是一件明智的事情。

我的回答：

不，这是一件非常愚蠢的事情。

为什么

除了koen和Robert Harvey概述的问题之外......

ACL允许角色被继承，因此如果两个角色适用于某种情况，那么具有正面和负面角色会导致更多的复杂性和冲突。

我的意思是'积极的'：

'只有让某人做某事，如果他们是这个角色'

与以下意义上的“消极”相反：

'只有让某人做某事，如果他们不是这个角色'

因此，如果您要添加一个角色来定义“黑客”，那么最好将其保持在正面（通过否定否定） - 即“不是黑客”。或者改写那个角色名：''FriendlyUser''

所有积极的：

+角色1：FriendlyUser
+角色2：访客
+角色3：会员
+角色4：管理员

与混合相反：

-角色1：黑客
+角色2：访客
+角色3：会员
+角色4：管理员

第二个角色列表更令人困惑。

Answer 3

用户共享一个共同的IP地址并不少见，因此我不确定通过IP禁止用户是多么实际。

如果它是填写表单类型的东西，垃圾邮件发送者最好用Captcha停止。

Answer 4

我看到的问题是根据用户执行的操作分配角色是在代码中硬编码规则。您的示例中的隐式规则是：

deny user access when user has property/behavior X

一种看待硬编码的方法是问问自己，如果你想调整它会发生什么。假设您发现可疑行为有点过于严格并且想要容忍更多，那么您将不得不进入file.php并进行更改。

我认为最好的办法是调查规则的断言部分：

http://framework.zend.com/manual/en/zend.acl.advanced.html

根据您的具体需求，这些可能是一个很好的解决方案。

编辑：回答评论 - ＆gt; 我很欣赏你的观点。我认为它指出为什么RBAC将被更强大的访问控制所取代，例如基于属性的访问控制。这将允许基于规则的用户和受控对象/资源的属性。理想情况下，您希望访问控制尽可能多地拥有权限决策逻辑。当您向用户隐式分配角色时，某些决策将在访问控制之外（例如，管理员的用户主要取决于谁拥有该网站）。但是您希望最小化在acl之外的决策，因为它添加了一个不受acl控制的访问层。因此，决定谁将具有特定角色通常是隐含的并且在acl之外。但仍然是由某些逻辑决定的访问控制，并且最好在程序中保留尽可能多的逻辑来负责处理该域。希望这种散漫有道理： - ）

访问控制列表最佳实践 - ACL - 为攻击站点的用户设置负角色

CONTEXT

问题

我的前端应用访问控制

所以要回答的问题是：

4 个答案:

我的回答：

为什么