25、提升基于属性的访问控制策略的复用性-优快云博客

本文链接：https://blog.youkuaiyun.com/go5gopher/article/details/154277655

提升基于属性的访问控制策略的复用性

1. 背景与问题提出

在医院的安全管理中，医院的安全专家会为特定规则和属性定义模式，例如护士的轮班安排和医院的科室划分等。这些模式可在医院使用的任何应用策略中复用。然而，现有的 XACML 技术并不支持此类模式。具体来说，上述模式包含五种类型的定义：
1. 可直接包含在其他策略中无需修改的规则，如检查患者同意的规则。
2. 稍作修改即可包含在其他策略中的规则，如检查主体是否在轮班的规则，其中轮班时间需由医院指定。
3. 这些规则所需的属性，如资源所有者或当前时间。
4. 可被其他规则后续使用的属性，如主体的角色或患者的状态。
5. 某个属性的可能取值，如医院的科室和员工的角色。

XACML 仅允许第一种情况，即通过策略引用直接包含其他策略。更高级的用于生成 XACML 策略的 ALFA 语言虽然支持属性定义，但仍局限于无需修改地包含策略。

2. STAPL 策略语言介绍

为解决这些限制，引入了一种名为 STAPL 的新型策略语言，它支持基于属性的树状结构策略中的策略模板。STAPL 支持以下几种类型：
1. 简单策略引用
2. 简单策略模板
3. 包含属性定义的策略模板模块
4. 带有专门属性类型扩展的策略模板

2.1 STAPL 基础

STAPL 是一种旨在轻松指定基于属性的树状结构策略的策略语言。它采用了与 XACML 类似的策略模型，但设计得更易于指定。以下是一个 STAPL 策略定义的示例：

1 action.id = SimpleAttribute ( String )
2 resource.owner = SimpleAttribute ( String )
3 subject.treating = ListAttribute ( String )
4 subject.roles = ListAttribute ( String )
5 environment.now = SimpleAttribute (Time)
6 ...
7 Policy := when ( action.id == ”view” and resource.type ==
8 ”patientstatus ”)
apply FirstApplicable
to
(
9 Rule := deny
iff
(not ”nurse ” in
subject.roles ) ,
10 Policy := apply PermitOverrides to
(
11 Rule := deny
iff
( subject.id
in
12 resource.owner withdrawn consents ) ,
13 Rule := permit
iff
( resource.patientstatus == ”bad ”) ,
14 Rule := permit
iff
( subject.triggered breaking glass )
15 performing
( log ( subject.id + ” broke
the
glass ”))
16 ) ,
17 Rule := deny
iff
(not
( environment.now >= 08:00 and
18 environment.now <= 17:00 ) ) ,
19 Rule := permit
iff
( resource.owner in
subject.treating ) ,
20 Rule := permit
iff
( subject.department == ”emergency ”) ,
21 Rule := deny
22 )

从上述代码可以看出，首先定义了策略中要使用的属性，这些属性有类型，可为单值或多值。然后根据这些属性定义策略。STAPL 使用由策略和规则组成的策略树，规则是 STAPL 策略的基本元素，策略是多个规则或其他策略的集合。每个策略通过基于属性的目标指定适用于哪些请求，并通过组合算法（如 PermitOverrides 或 FirstApplicable）指定如何组合其子规则的结果。

2.2 简单策略引用

策略引用是 STAPL 提供的最简单的策略模板类型。类似于 XACML，策略引用允许策略在不修改的情况下复用，且不包含属性定义。以下是定义和使用策略引用的示例：

1 // example
definitions
2 def
defaultDeny = Rule := deny
3 def
denyIfNotOnShift = Rule := deny
iff
(
4 not ( environment.now >= 08:00 and environment.now <= 17:00 ))
5 def
permitIfTreating = Rule := permit
iff
(
6 resource.owner in
subject.treating )
7 // example
usage
8 action.id = SimpleAttribute ( String )
9 ...
10 Policy := when
( ... )
apply
FirstApplicable
to
(
11 ...
12 denyIfNotOnShift ,
13 permitIfTreating ,
14 ...
15 defaultDeny
16 )

策略引用是不要求参数并返回 STAPL 规则或策略的 Scala 函数。

2.3 简单策略模板

策略模板在策略引用的基础上扩展了未绑定变量。这些未绑定变量可以是文字值、属性引用、基于属性的表达式，甚至是其他规则或策略。以下是定义和使用策略模板的示例：

1 // example
definitions
2 def
denyIfNotOnShift ( start:
Time ,
stop:
Time) =
3 Rule := deny iff
(not ( environment.now >= start
4 and environment.now <= stop ))
5 def
denyUnless ( condition: Expr) =
6 Policy := apply PermitOverrides to (
7 Rule := permit
iff
( condition ) ,
8 defaultDeny
//
see
Listing
1.3
9 )
10 // example
usage
11 action.id = SimpleAttribute ( String )
12 ...
13 Policy := when
( ... )
apply PermitOverrides to (
14 ...
15 denyIfNotOnShift (08:00 ,
17:00 ) ,
16 ...
17 denyUnless ( subject.department == ”emergency ”)
18 )

策略模板是要求参数并返回 STAPL 规则或策略的 Scala 函数。

2.4 包含属性定义的策略模板模块

STAPL 支持将策略模板与这些模板所需的属性定义封装在一起。这降低了属性定义错误的可能性，并将策略模式完全封装为可复用的自包含模块。以下是定义和使用此类策略模块的示例：

1 // example
definitions
2 trait
Shifts
extends
BasicPolicy
{
3 environment.now = SimpleAttribute (Time)
4 def
denyIfNotOnShift ( ... ) = ...
//
see
Listing
1.4
5 }
6 trait
Ownership extends
BasicPolicy
{
7 resource.owner = SimpleAttribute ( String )
8 }
9 trait
Treating
extends Ownership {
10 subject.treating = ListAttribute ( String )
11 def
permitIfTreating = ...
//
see
Listing
1.3
12 }
13 // example
usage
14 object
example
extends
BasicPolicy
with
Shifts
with Treating
{
15 //
notice:
no
attribute
definitions
here
16 Policy := when
( ... )
apply PermitOverrides to
(
17 ...
18 denyIfNotOnShift (08:00 ,
17:00 ) ,
19 permitIfTreating ,
20 ...
21 )
22 }

策略模块是扩展了 BasicPolicy 特征的 Scala 特征。Scala 特征类似于类，但允许多重继承。BasicPolicy 特征定义了主体、资源、动作和环境变量，以便策略模块可以为它们分配属性。

2.5 带有专门属性的策略模板

策略模块可以通过专门的属性类型和对这些属性进行推理的函数扩展 STAPL 的核心功能。例如，可以使用此功能来表达层次角色。以下是一个使用层次角色专门属性类型的示例：

1 ...
//
definition
of
the
role
attribute
omitted
2 // example
definition
of
the
role
hierarchy
3 val employee = new Role ()
4 val
nurse = new Role ( employee )
5 val headNurse = new Role ( nurse )
6 ...
7 // example
usage
8 Policy := when
( ... )
apply PermitOverrides to (
9 //
this
applies
to
all
types
of
nurses
10 Rule := deny iff
(not subject.hasRole ( nurse ))
11 )

带有专门属性的策略模块是 STAPL 提供的最具表现力但也是最复杂的策略模式类型。

3. 策略模板的验证

为验证策略模板的潜力，将其应用于现有策略，通过将规则和属性定义分解为策略模块，然后验证每个生成的策略模块是否在单个利益相关者的专业范围内，以及每个模块是否可在其各自的领域中复用。

3.1 验证方法

选择一个应用于患者监测系统查看患者状态的现有策略，该策略最初用 XACML 指定，先将其逐字转换为 STAPL 以进行公平评估。此策略包含 23 条规则（加上 7 条默认拒绝规则），分布在 12 个策略中，形成深度为 5 的策略树，需要 30 个不同的属性，包括 17 个主体属性、11 个资源属性、1 个动作属性和 1 个环境属性。

3.2 模块化结果

通过模块化策略，得到以下有趣的观察结果：
1. 关注点分离 ：可以应用策略模板，使每个策略模块都能由一位专家精确指定。不同专家的角色得到了适当分离：
- 访问控制专家指定通用策略模块，如 Roles、Time、Ownership、Location 和 GeneralTemplates。
- 领域专家指定适用于电子健康领域的策略模块，如 Consent 和 BreakingGlass。
- 应用程序提供商指定特定于应用程序的策略模块，如 PatientMonitoringSystem。
- 医院安全专家定义特定于医院的策略模块，包括员工的角色层次结构、科室定义等。
- 应用程序安全专家仅指定适用于医院使用的患者监测系统的特定策略。
2. 可复用性 ：不同专家定义的模块确实适用于各自的领域，因此可以在这些领域中复用。
3. 策略模块数量 ：从包含 23 条规则的策略中提取了不少于 14 个模块，显示了访问控制策略中常见的可复用模式以及策略模板简化策略指定的潜力。
4. 细粒度模块层次结构 ：大多数 14 个模块仅定义了少量模板和属性。通过使用模块依赖关系，可以将这些细粒度模板构建为逐渐增大的模块层次结构，以便仅包含最终策略中所需的特定功能。

3.3 模块分析

对这 14 个模块中使用的不同类型的模板进行分析，得到以下观察结果：
|模板类型|数量|
| ---- | ---- |
|策略引用|2（defaultDeny 和 defaultPermit）|
|策略模板|6（如 DenyUnless() 和 denyIfNotOnShift()）|
|标准属性定义|30|
|专门属性定义|3（角色、层次资源类型和患者状态）|
|使用专门属性的函数|3|

最终策略未定义任何其他属性，实例化了 0 个策略引用、9 个策略模板和 9 个使用专门属性的函数。这些数字表明：
1. 除了 defaultDeny 和 defaultPermit，所有其他模板都需要未绑定变量才能复用，验证了策略引用本身不足以提供复用性的原始主张。
2. 模板实例化的数量明显高于模板定义的数量，主要是由于策略中频繁使用角色（7 次）和 DenyUnless()（6 次）。
3. 最终应用策略所需的所有属性都在模块中定义，策略本身未定义任何属性，符合现实情况。

3.4 模板对策略大小的影响

通过表格比较了使用策略模板前后策略所需的代码行数等指标，具体表格内容虽未给出，但可推测策略模板在一定程度上优化了策略的表达。

综上所述，STAPL 中的策略模板在提升基于属性的访问控制策略的复用性、分离利益相关者的职责以及简化策略指定方面具有显著优势。

提升基于属性的访问控制策略的复用性

4. 实际应用中的优势与操作流程

4.1 优势总结

在实际应用中，STAPL 的策略模板展现出了多方面的优势，这些优势可以通过以下列表详细呈现：
- 复用性增强 ：不同专家定义的策略模块可在各自领域复用，如应用程序提供商的模板可被使用其应用的任何组织复用，访问控制专家的模板可用于其他访问控制策略。
- 职责分离 ：不同类型的专家能够专注于自己擅长的领域进行策略模块的定义，实现了关注点的有效分离。例如，访问控制专家负责通用策略模块，医院安全专家负责医院特定的策略模块等。
- 简化策略指定 ：从包含 23 条规则的策略中能提取 14 个模块，体现了访问控制策略中存在大量可复用模式，策略模板能够有效简化策略的指定过程。
- 灵活性高 ：策略模板支持未绑定变量，可根据不同需求进行灵活配置，如策略模板 denyIfNotOnShift 可根据不同的轮班时间进行参数设置。

4.2 操作流程

下面以构建一个基于 STAPL 的患者监测系统访问控制策略为例，详细说明操作步骤：
1. 定义属性 ：根据系统需求，定义策略中要使用的属性，例如：

action.id = SimpleAttribute ( String )
resource.owner = SimpleAttribute ( String )
subject.treating = ListAttribute ( String )
subject.roles = ListAttribute ( String )
environment.now = SimpleAttribute (Time)

创建策略模板 ：根据常见的访问控制规则，创建策略模板。例如：

def denyIfNotOnShift ( start: Time, stop: Time) =
  Rule := deny iff (not ( environment.now >= start and environment.now <= stop ))
def denyUnless ( condition: Expr) =
  Policy := apply PermitOverrides to (
    Rule := permit iff ( condition ),
    defaultDeny
  )

封装策略模块 ：将策略模板与所需的属性定义封装在一起，形成可复用的策略模块。例如：

trait Shifts extends BasicPolicy {
  environment.now = SimpleAttribute (Time)
  def denyIfNotOnShift ( ... ) = ...
}
trait Ownership extends BasicPolicy {
  resource.owner = SimpleAttribute ( String )
}
trait Treating extends Ownership {
  subject.treating = ListAttribute ( String )
  def permitIfTreating = ...
}

实例化策略模板 ：在最终的策略中，根据具体需求实例化策略模板。例如：

object example extends BasicPolicy with Shifts with Treating {
  Policy := when ( ... ) apply PermitOverrides to (
    denyIfNotOnShift (08:00, 17:00 ),
    permitIfTreating,
    denyUnless ( subject.department == ”emergency ”)
  )
}

5. 策略模板应用的流程图

下面是一个 mermaid 格式的流程图，展示了使用 STAPL 策略模板构建访问控制策略的整体流程：

graph LR
    A[定义属性] --> B[创建策略模板]
    B --> C[封装策略模块]
    C --> D[实例化策略模板]
    D --> E[生成最终策略]

6. 总结与展望

通过上述分析可知，STAPL 的策略模板在提升基于属性的访问控制策略复用性方面具有显著效果。它不仅实现了不同利益相关者职责的分离，还简化了策略的指定过程，提高了策略的可维护性和灵活性。

在未来的发展中，随着信息技术的不断进步和应用场景的日益复杂，对访问控制策略的要求也会越来越高。STAPL 的策略模板有望在更多领域得到应用，并且可以进一步扩展其功能，例如支持更多类型的专门属性和复杂的规则推理。同时，还可以探索如何更好地与其他安全技术和系统进行集成，以提供更全面的安全保障。

总之，STAPL 的策略模板为基于属性的访问控制策略的设计和管理提供了一种有效的解决方案，具有广阔的应用前景和发展潜力。