2

我正在尝试决定为项目做哪些授权技术/方法，而 XACML 有很多有趣的功能。不过，我无法理解的一件事是需要组合算法。是否存在需要它们的复杂场景？

说，相反，对资源类型（或其他）的访问默认是允许或拒绝。规则定义了允许或拒绝（从不同时）的条件。

如果有任何拒绝，它就会被拒绝（立即）。如果它是“默认拒绝”并且没有许可，它也被拒绝。规则可以具有优先级，并且任何更高级别的允许/拒绝将覆盖低于它的那些。

规则将是更零碎的允许/拒绝，而不是具有高级组合算法的一条大规则。

我是否错过了这种方法无法涵盖的一些主要场景（可能）？也许是一个很难回答的问题 :) 希望有很多 XACML 经验和/或访问控制的人可以对设计思维和他们对此类政策的经验有所了解。

提前致谢！

编辑：（作为对乔治的回复，因为太长了）

非常感谢您回答大卫！读了很多你的帖子和文章，好东西。

我听到你在说什么，并且有很多错综复杂的东西（阅读一些设计决策和评估逻辑的电子邮件列表，哇，毛茸茸的东西:) 但似乎层次结构增加了很多复杂性，我不太明白为什么需要它。

根据我写的逻辑，我可以只有这两个规则（如果我正确理解 XACML）

PERMIT: unit = "bu1" 

DENY: unit = "bu1" AND apiPath == "/finance" AND objectType== "trade" AND trade.amount > user.allowedAmount
  • 如果用户在单元中，则授予访问权限
  • 在一组特定情况下否认
  • 如果它是全公司范围的规则，甚至可以取消 DENY 规则的业务部门限制，这似乎应该是

单独定制规则似乎比将它们作为一条大规则的一部分更容易，如果你这样编写它们，真的需要将它们视为一条规则吗？我想你会有一种允许一般情况并否认例外的一般心态。

所以第二个示例，这就是为什么我认为您实际上需要“优先级”来解决某些问题。

Priority 1:

PERMIT:  megaemergency = true 

Priority 2:

PERMIT:  emergency = true AND u.approvalLimit >= c.amount.

Priority 3:

PERMIT: u.region = c.region AND u.approvalLimit >= c.amount.

由于它在任何“优先级”上的 PERMIT 或 DENY 上短路，并且按顺序对其进行评估，结果不一样吗？编写低优先级规则的人实际上并不需要了解具有更高优先级的规则。

最后一个例子是：

PERMIT: u.citizenship == "U.S" AND u.enteringFrom == "Canada" 
DENY: u.citizenship != "U.S" AND u.enteringFrom == "Canada"

（我的意思是也必须有其他规则：）

由于 DENY 会覆盖 Permit，因此任何 DENY 都会拒绝您的设置。

我想我很难看到这种方法无法处理的边缘情况......也许我有一个头放屁:)

再次抱歉，问题的范围有点宽。

4

1 回答 1

3

默认情况下拒绝绝对是一种好方法，但有时具有更大的灵活性和定义以及如何组合规则（或策略）是有意义的。

这是标准所说的：

适用于特定决策请求的完整策略可能由许多单独的规则或策略组成。例如，在个人隐私应用程序中，个人信息的所有者可以定义披露政策的某些方面，而作为信息保管人的企业可以定义某些其他方面。为了做出授权决定，必须可以将两个单独的策略组合成适用于请求的单一策略。资源

  1. 请记住，XACML 不只是返回许可或拒绝。它可以返回Permit、Deny、NotApplicable和Indeterminate。
  2. XACML 策略不是您通常在网络访问控制/防火墙规则中看到的检查列表。XACML 策略是一棵（或几棵）策略树，越深越好，越窄越好。一旦你开始构建树，你就需要一个冲突解决机制，也就是组合算法。

编写 XACML 策略时的常见模式是定义策略的层次结构。您这样做是因为您希望您的策略易于管理。因此，让我们假设您是 Acme Inc.，您有 5 个业务部门，您有 5 个 API，而这些 API 又具有 5 个方法。

您的策略可能类似于以下存根（在中）：

policyset acme{
    apply firstApplicable
    policyset bu1{
        target clause unit == "bu1"
        apply firstApplicable
        policyset financeApi{
            target clause apiPath == "/finance"
            apply firstApplicable
            policy buyTrade{
                target clause objectType == "trade"
                apply firstApplicable
                rule denyIfAmountTooLarge{
                    deny
                    condition trade.amount > user.allowedAmount
                    on deny{
                        obligation notify {
                            message = "You cannot approve this transaction because..."
                        }
                    }
                }
            }
        }
    }
}

如果默认拒绝并首先拒绝，那么我将无法并行拥有多个策略（对于 BU1、BU2 ...）。我不能那么容易地嵌套策略。我也有可能错误地拒绝或允许访问。我需要在每个级别控制结果可能是什么，以及如果我们得到NotApplicable或Indeterminate返回该怎么办。

高效的策略结构……适用于运行时和设计时

访问控制列表或 NAC 样式规则的主要缺点之一是您最终可能会得到太多规则，并且很难理解哪些规则描述了哪些访问。例如，在 NAC 中，您如何知道给定端口上的 UDP 是允许还是不允许。从哪个 IP 范围？

XACML 和 ALFA 等更高级的策略语言使您能够创建策略树。这意味着您可以以树状结构组织您的策略：

  1. 可以更快地评估 - 只需剪掉不适用的分支
  2. 可以更容易地（由人类）管理和理解。滚动浏览 1000 多个规则的列表是无法管理的。但是，打开分支并折叠其他分支可以更轻松地找到您要查找的部分。
  3. 可以重复使用。想象一下 8080 端口 UDP 和 8080 端口 TCP 的规则是一样的。您不再需要重写它们两次。您可以简单地将一项政策/规则链接到另一项政策/规则并累积收益。

不同的政策有不同的目标

想象一下，您是一家处理索赔的保险公司。您的基准政策是：理赔代理只能查看其所在地区的理赔，并且只能批准最高限额的赔付。因此，如果 u.region = c.region 且 u.approvalLimit >= c.amount，则在您的脑海中您拥有 Permit。

但是，如果这是紧急情况，您希望您的所有员工为所有地区提供服务。所以现在您需要一个可以覆盖区域限制的策略。你不能在一个单一的列表、拒绝获胜的结构中真正做到这一点。这就是 XACML/ALFA 派上用场的地方，因为语法和结构足够丰富，可以解决这些场景。

这里还有一些有意义的

找出拒绝访问的所有原因

有时，您不想尽快否认。您想告诉最终用户拒绝访问的所有原因。例如，索赔处理人无法批准索赔，因为 (a) 金额过多，(b) 地区与员工所在地区不同，以及 (c) 存在利益冲突。如果你告诉用户零碎的信息，你会强迫你的用户重试批准 3 次并被拒绝 3 次。

找到拒绝访问的第一个原因

这与前面的说法相反，也是最常见的模式：您希望尽可能少地透露并尽快否认。你的模型可以在这里工作。

仅当所有检查都允许时才允许

这也称为伯格模式。而不是说：

  • 如果区域错误则拒绝
  • 如果金额过多，则拒绝
  • 允许索赔批准

如果 - 区域正确 - 数量低于限制，您可以说允许

在这种情况下，您希望收集所有的许可决定，然后在需要时翻转它们。这需要permit-overrides 和deny-unless-permit。仅使用拒绝策略是无法做到这一点的。

警告

小心拒绝政策。如果你写的政策说：

  • 如果公民身份不是美国，则拒绝从加拿大进入美国。

在 XACML 中，如果由于某种原因不存在公民身份的价值，则不会拒绝访问。我们不知道用户是不是美国人。所以你也必须考虑价值存在。

延伸阅读

Axiomatics 有一篇关于组合算法的精彩文章。我建议你检查一下。

于 2020-05-06T17:21:14.967 回答