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

【问题标题】：Access Control List Best Practices - ACL - Setting Negative Roles for Users who Attack a Site访问控制列表最佳实践 - ACL - 为攻击站点的用户设置负面角色
【发布时间】：2009-11-09 22:10:59
【问题描述】：

上下文

我刚刚阅读了有关 Zend ACL 的内容 http://framework.zend.com/manual/en/zend.acl.html

问题

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

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

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

应用范围的 ACL - ''app ACL'' 权限只是 - “访问”（或者可能称之为“读取”，（甚至是“SendHTTPRequests”））
帐户范围 - 将所有其他权限留给各个“帐户 ACL”

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

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

也许有这样的规则：

我的前端应用访问控制

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

姓名 = 客人
唯一权限 = SendHTTPRequests
继承权限 = N/A

姓名 = 成员
唯一权限 = SendHTTPRequests
从 = 来宾继承权限

姓名 = 管理员
唯一权限 =（所有权限）
继承权限 = N/A

其他应用将有更严格的规则来拒绝访客等

所以要回答的问题是：

将“攻击者”角色（负面角色）分配给用户是否让您觉得这样做是明智之举。

或者这与一般最佳实践相反？

【问题讨论】：

标签： security acl zend-acl

【解决方案1】：

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

在启动时全部拒绝，仅在检查黑名单/白名单/权限以及所有您想要的检查后才授予对资源的访问权限。
启动时全部允许，然后拒绝访问敏感区域，只有在检查后才允许访问。

我通常更喜欢第一个。当您需要保护的区域较小且主要是公共区域时，第二个效果会更好。对每个调用进行检查会增加您的应用程序的权重。

【讨论】：

【解决方案2】：

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

将“攻击者”角色（负面角色）分配给用户是否让您觉得这样做是明智之举。

我的回答：

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

为什么

除了 koen 和 Robert Harvey 概述的问题。

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

我的意思是“积极的”：

'只有当某人是这个角色时才允许他们做某事'

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

'只让不是这个角色的人做某事'

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

全部正面：

+ Role1：FriendlyUser
+ Role2：嘉宾
+Role3：会员
+ Role4：管理员

相对于混合：

- Role1：黑客
+ Role2：嘉宾
+ Role3：会员
+ Role4：管理员

第二个角色列表更加混乱。

【讨论】：

我不熟悉 Zend 的 ACL，但这个想法的智慧/愚蠢确实取决于您的角色成员资格如何工作 - 如果用户可以拥有多个角色，则需要某种权限积累。如果您将通过用户的各种角色获得的权限相加，那么定义一个角色以消除某些权限确实有意义。 Windows NT/2000 ACL 遵循这条路线（我想他们的继任者仍然如此），它提供了一些有用的灵活性。

【解决方案3】：

用户共享一个公共 IP 地址并不少见，所以我不确定通过 IP 禁止用户是否实用。

如果是填写表格类型的东西，垃圾邮件发送者最好使用验证码来阻止。

【讨论】：

是的。我看到你的观点-IP 地址是一个不好的例子。我会相应地改变问题
将条件规范从：isInBlockedIpList(UserIP) 更改为 UserActivityScoresHighProbabilityOfHacking_Specification
您是否通过他的帐户识别用户？如果你屏蔽他，他可以创建一个新帐户吗？
在示例中，“用户”的使用是最宽松的。也许只能通过 IP + 缺少会话 ID + 其他因素（如使用签名）来识别。我真的很想知道为用户分配像“垃圾邮件发送者”或“黑客”这样的角色是否有意义。自从写下我的问题以来，我已经阅读到 Zend ACL 文档的末尾，它谈到了实现一个非常相似的概念。但是附加一个“断言到规则”，而不是附加一个“角色到用户”。我真的很想知道将“垃圾邮件发送者”或“黑客”等角色分配给用户是否有意义。

【解决方案4】：

我看到根据用户所做/拥有的角色分配角色的问题是它在代码中硬编码规则。您示例中的隐含规则是：

deny user access when user has property/behavior X

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

我认为你最好的办法是研究规则的断言部分：

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

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

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

【讨论】：

感谢您的回答。不过，我现在有点困惑。如果您不根据用户所做/拥有的内容分配角色。角色基于什么？我猜用户是什么。但是，这似乎源于某人所做或拥有的东西。我想，哲学家们也花了几年时间来思考这个问题。因此，我是... [由于字符限制，消息被截断] :o)
@JW 在我的回答中添加了响应也是由于字符限制
我明白你的意思。将所有内容保存在一个地方可以更轻松地进行管理。我对“负面”角色的想法做了一些额外的思考，并意识到无论如何这是一个愚蠢的想法。我将在“答案帖”中回答这个问题。不过，您的 cmets 非常有用。所以，谢谢。