访问控制列表最佳实践 - ACL - 为攻击站点的用户设置否定角色
上下文
我刚刚阅读了有关 Zend ACL 的内容 http://framework.zend.com/manual/en/zend.acl。 html
问题
我在一台服务器上运行三个 Zend 应用程序。
- 我的前端应用程序
- 我的前端成员应用程序
- 我的后端应用程序（站点所有者的管理员）
在应用程序中，我正在考虑使用两种类型的 ACL。
- 应用程序范围 ACL -“应用程序 ACL”权限只是 -“访问”（或者可能称之为“读取”，（甚至“SendHTTPRequests”））
- 帐户范围 - 将所有其他权限留给个人“帐户 ACL”
我我认为这会更容易阻止垃圾邮件发送者和其他攻击者
if (UserActivityScoresHighProbabilityOfHacking_Specification->IsSatisfiedBy(User))
{
User->addrole(Attacker)
}
也许使用这样的规则：
我的前端应用程序访问控制
- 名称=攻击者
- 唯一权限=无
- 继承权限来自=N/A
- 名称=来宾
- 唯一权限=SendHTTPRequests
- 继承权限来自 = N/A
- 名称 = 成员
- 唯一权限 = SendHTTPRequests
- 继承权限来自 = 来宾
- 名称 = 管理员
- 唯一权限 =（所有权限）
- 继承权限来自 = N/A
其他应用程序将有更严格的规则来拒绝来宾访问
等要回答的问题是：
将“攻击者”角色（负面角色）分配给用户是否会让您觉得是明智之举？
或者这违背了一般的最佳实践？
CONTEXT
I have just been reading about Zend ACL
http://framework.zend.com/manual/en/zend.acl.html
QUESTION
I'm running three Zend applications on one server.
- My Front End App
- My Front End-Members App
- My Back End App (Site Owner's Admin)
Within the applications I'm considering having two types of ACL.
- Application Wide ACL - ''app ACL's'' permissions are just - "access" (or maybe call it "read", (or even "SendHTTPRequests"))
- Account Wide - leaving all other permissions to individual ''account ACL's''
I'm thinking this would make it easier to block spammers and other attackers
if (UserActivityScoresHighProbabilityOfHacking_Specification->IsSatisfiedBy(User))
{
User->addrole(Attacker)
}
Perhaps with rules something like this:
My Front End App Access Controls
- Name = Attacker
- Unique Permissions = NONE
- Inherit Permissions From = N/A
- Name = Guest
- Unique Permissions = SendHTTPRequests
- Inherit Permissions From = N/A
- Name = Member
- Unique Permissions = SendHTTPRequests
- Inherit Permissions From = Guest
- Name = Admin
- Unique Permissions = (ALL Permissions)
- Inherit Permissions From = N/A
The other apps would have more stringent rules to deny access to guests, etc
So the question to answer is:
Does assigning the role of 'Attacker' (a negative role) to a user strike you as being a sensible thing to do.
Or this contrary to general best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用 ACL 基本上有两种理念：
启动时拒绝所有，仅在检查黑名单/白名单/权限以及所有您想要的检查后才授予对资源的访问权限。
启动时允许所有，然后拒绝对敏感区域的访问，只有在检查后才允许访问。
我通常更喜欢第一个。
当需要保护的区域较小且主要是公共区域时，第二种方法更好。对每个调用进行检查会增加应用程序的重量。
There are basically two philosophies in using ACL:
deny all at startup and give access to resources only after checking black lists/white lists/ permission and all the check you want.
allow all at startup and then deny access to the sensitive area, where you will allow access only after checks.
I prefer to go with the first one usually.
The second one is better when you have small areas to protect and mostly public zones. Doing check for each call adds some weight to your application.
经过几天的思考......这是我对上面问题的回答：
将“攻击者”角色（负面角色）分配给用户是否会让您觉得这是明智之举。
我的回答：
不，这是一件非常愚蠢的事情。
为什么
除了 koen 和 Robert Harvey 概述的问题之外......
ACL 允许继承角色，因此拥有积极和消极的角色会导致如果两种角色同时适用于一种情况，那么复杂性和冲突的可能性就更大。
我的意思是“积极”的意思是：
而不是“消极”的意思是：
因此，如果你如果我们要添加一个角色来定义“黑客”，最好保持积极的态度（通过否定消极的方式）——即“不是黑客”。
或者改写角色名：“FriendlyUser”
全部正面：
+Role1：FriendlyUser+Role2：Guest+Role3：Member+Role4：管理员与混合相反：
-Role1：黑客+Role2：Guest+Role3：成员+Role4：Admin第二个角色列表更加混乱。
After a couple of days of pondering...here's my answer to my question above:
Does assigning the role of 'Attacker' (a negative role) to a user strike you as being a sensible thing to do.
My answer:
No, its a very silly thing to do.
Why
Aside from the issues outlined by koen and Robert Harvey..
The ACL allows for roles to be inherited and so having positive AND negative roles would cause more chance of complexity and conflict if two roles become applicable to a situation.
I mean 'positive' in the sense of :
As opposed to 'negative' in the sense of:
Therefore, if you were going to add a role to define 'a hacker', it would be better to keep it in the positive (by negating the negative) - i.e. 'NOT a hacker'.
Or to rephrase that rolename: ''FriendlyUser''
All positive :
+Role1: FriendlyUser+Role2: Guest+Role3: Member+Role4: AdminAs opposed to mixed:
-Role1: Hacker+Role2: Guest+Role3: Member+Role4: AdminThe second role list is much more confusing.
用户共享一个公共IP地址的情况并不少见，所以我不确定通过IP禁止用户是否实用。
如果是填写表格类型的内容，最好使用验证码来阻止垃圾邮件发送者。
It's not uncommon for users to share a common IP address, so I'm not sure how practical it is to ban users by IP.
If it is fill-out forms type stuff, spammers are best stopped with a Captcha.
我看到根据用户所做/拥有的事情分配角色的问题是它在代码中硬编码了规则。您的示例中的隐含规则是：
查看硬编码的一种方法是问问自己，如果您想调整它，会发生什么。假设您发现可疑行为有点过于严格并且想要容忍更多，那么您必须进入 file.php 并更改它。
我认为你最好的选择是研究规则的断言部分：
http://framework.zend.com/manual/en/zend.acl.advanced.html
根据您的具体需求，这些可能是一个很好的解决方案。
编辑：回复评论->
我很欣赏你提出的观点。我认为这说明了为什么 RBAC 将被更强大的访问控制（例如基于属性的访问控制）所取代。这将允许基于用户和对象/资源的属性的规则受到控制。
理想情况下，您希望访问控制中包含尽可能多的权限决策逻辑。当您隐式地为用户分配角色时，某些决策将超出访问控制范围（例如，哪些用户将成为管理员，主要取决于谁拥有网站等因素）。但是您希望最大限度地减少 acl 之外的决策，因为它添加了不受 acl 控制的访问层。因此，决定谁将担任特定角色通常是隐含的并且在 acl 之外。但它仍然是访问控制的领域，由某些逻辑决定，最好在负责处理该领域的程序中保留尽可能多的逻辑。
希望这个漫无目的的:-)
The problem I see with assigning a role based on what a user does/has is that it hardcodes rules in your code. The implicit rule in your example is:
A way to see this is hardcoded is to ask yourself what would happen if you wanted to adjust it. Suppose you found the suspicious behaviour a bit too strict and want to tolerate some more, then you would have to go into the file.php and change it.
I think your best bet is to look into the assertion part of the rules:
http://framework.zend.com/manual/en/zend.acl.advanced.html
Depending on your specific needs these can be a good solution.
edit: answer to comment ->
I appreciate the point you make. I think it points to why RBAC will be replaced by more powerful access controls like attribute based access control. This will allow rules based one the attributes of users and objects/resources under control.
Ideally you want the access control to have as much permission decision logic in it as possible. When you assign roles to users implicitly some of the decision making will be outside of the access control (eg what user will be administrator is mostly determined by things like who owns the website). But you want to minimize the decision making outside of the acl because it adds a layer of access that is not controled by the acl. Thus deciding who will have a particular role is often implied and outside the acl. But still it is the are of access control, determined by some logic, and it's best to keep as much logic inside the program that has the responsability to handle this domain.
Hope this rambling makes sense :-)