4

语境

我刚刚阅读了有关 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

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

所以要回答的问题是：

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

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

4

4 回答 4

4

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

  1. 在启动时拒绝所有，仅在检查黑名单/白名单/权限和您想要的所有检查后才授予对资源的访问权限。

  2. 启动时全部允许，然后拒绝访问敏感区域，只有在检查后才允许访问。

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

于 2009-12-17T16:26:50.260 回答
2

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

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

我的答案：

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

为什么

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

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

我的意思是“积极的”：

  • “只有当他们是这个角色时才让某人做某事”

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

  • “只让不是这个角色的人做某事”

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

所有积极的：

  • +角色1：友好用户
  • +角色2：客人
  • +角色3：成员
  • +角色 4：管理员

与混合相反：

  • -角色1：黑客
  • +角色2：客人
  • +角色3：成员
  • +角色 4：管理员

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

于 2009-11-12T01:28:23.833 回答
1

用户共享一个公共 IP 地址并不少见，所以我不确定按 IP 禁止用户有多实用。

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

于 2009-11-09T22:16:12.910 回答
1

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

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 之外的。但它仍然是访问控制的领域，由一些逻辑决定，并且最好在负责处理该域的程序中保留尽可能多的逻辑。希望这种漫无边际是有道理的:-)

于 2009-11-10T20:32:01.547 回答