译-BMC Remedy Action Request System权限控制概述

说明：

BMC Remedy Action Request System是BMC ITSM产品平台，简称AR 或者Remedy，可实现基于ITIL标准的整个IT管理流程的实施定制。该平台可实现多种权限级别的管理，包括人员、组、角色，以及表、字段、行级别等。本文可以用作其他对权限要求比较精细的系统参考。

为了便于理解，部分名词翻译如下：

Server:服务器
Form (or table)：表单
Field (or column)：字段
Active link and active link guide：Remedy平台的工作流，一个ActiveLink类似于一个固定操作，比如点击按钮、提交表单、刷新页面等，active link guide代表一串ActiveLink

Request (or row)：表中的一条数据，或者一个记录
User:用户
Group:组
Role:角色

正文：

本节介绍用户和组访问控制、基于role的访问控制、多层访问控制，并说明license如何影响访问控制

用户和组的访问控制概述
基于role的访问控制概述
多层访问控制模型
license如何影响访问控制

BMC Remedy AR System 提供丰富的功能用于保护您的数据避免未授权的访问。此外，它有一个逻辑的、多层的权限控制架构，便于维护和用户使用。

在客户端/服务器环境保证信息安全是主要的任务。它有时是管理员的一种平衡。一方面想要对数据访问进行严格控制，另一方面你不希望太复杂的安全管理会扰乱日常用户，否则很难实现和维护。

BMC Remedy AR System能满足这些看似对立的安全目标。它能够控制哪些用户可以访问数据、执行规定操作，比如修改一个request或者触发一个active link。

用户访问控制由如下条件决定：

用户所属的组
用户分配的license

BMC Remedy AR System使用多层方法在如下层面进行访问控制：

Server
Form(or table)
Field (or column)
Active link and active link guide
Request (or row)

这个方法提供了一个广泛的对数据访问的控制，使你既可以在高层次（server和表单）也可以在request和field层次的访问控制。因此你可以精确的细化你的数据权限标准，你可以使用同一张表单用于不同目的，只需要设置合适的权限即可。

当用户打开Remedy客户端时，它们必须输入用户名和密码，客户端和服务器初次连接时需要认证。连接一旦建立，当前用户的每一个客户端和服务器的请求都会验证连接状态是否仍然有效。

一台服务器上除了唯一的用户名和密码外，每一个用户都属于0个或多个组。组使用group from进行定义和维护，group 表单中的每一条记录都是一个不同的组定义。比如：有“一线支持”、“二线支持”、“支持管理”组，用于对表单、requests、和active links/guides进行访问控制。通常，大多数设置的是公共（Public）组权限。

你可以使用组控制对表单的访问；一个特定表单对“支持管理”可见，但对“一线支持”和“二线支持”隐藏。对于一个特定表单，管理员可以决定某个组的用户可以执行某些请求，而另一个组的人不能。

此外，表单上的每个字段也都有访问控制。使用Developer Studio对每个字段的权限属性进行定义，某一个字段可以允许一部分组查看和插入数据，部分或者全部组具有查看权限并同时具有修改权限，以便它们可以插入并修改数据。当一个用户打开表单时，它所属的组对部分字段没有查看权限，那么这些字段将不在表单上显示。只有通过工作流（workflow）才可以使某个字段再次对某个用户隐藏或者可见。

最后，每一个active link和active link guide在创建时都分配了权限。一个拥有active link权限的用户不会自动获取该active link关联字段的权限。类似的，一个拥有active link guide权限的用户也不会自动获取guide内其他active link的权限

访问控制在Remedy中是后加的，也就是说，每个用户开始都是没有访问权限的，管理员根据需要添加权限。这样Remedy实现了严格的访问控制。管理员必须有意识的根据情况给特定的组分配权限。然而，如果需要，默认权限也是可以修改的。

只有BMC Remedy AR System administrators或者subadministrators可以修改security parameters。

1. 用户和组的访问控制概述

管理员为需要访问remedy系统的用户进行注册，并为用户指派所属权限组。

每一个权限组都是为特定的服务器定义的。一个权限组决定着组内用户访问应用组件的权限，比如forms、requests、, fields、 active links和active link guides。（管理员也可以为每类组件设置默认权限，一旦创建该组件，则指定的组默认就拥有了默认权限）

根据用户需要的权限给用户指定组。例如，你创建了一个HR组，并分配了查看和更改部分薪酬信息表的权限。然后又创建了另外一个薪酬管理组，并分配了查看和更改所有薪酬信息表的权限，包括工资信息。你还可以配置组之间的层次关系，允许子组继承父组的权限。

Remedy系统预定义好的组可以拥有特定的功能（参看权限组的类型节）。此外，你可以创建任意数量的组来进行访问控制。你也可以允许未注册的用户作为访客访问Remedy系统。访客实际是预定义的公共（Public）组。

1.1 权限组的类型

这个表列出了权限组的类型。Remedy系统提供预定义好的组，但你必须在你系统中添加自定义的组。

权限组的类型

权限组的类型	描述	预定义的组	自定义组
显式组	必须分配用户的组	1 Administrator 2 Sub Administrator 3 Customize	任何你创建的常规（regular）组和组合（computed）组。常规组的用户需要你进行指定。组合组的用户需要根据组合组的关系确定。例如：组合组的定义为(A AND B) OR C AND NOT D,这个组合组则包括组A、B或者组C，但不包括组D
隐式组	用户由于数据中某些字段的内容而自动（隐式的）属于的组。不能为用户指定隐式组。所有Remedy用户都属于Public组。使用其他隐式组实现对请求的（或者行级数据的）访问控制。	1 Public 2 Submitter 3 Assignee 4 Assignee Group	任何你创建的动态（dynamic）组。动态组根据特殊字段的内容来确定组成员。例如：每条数据都有提交者，那么这条数据则对该提交者默认拥有Submitter的权限。而其他用户也许只能查看该条数据，但Submitter可以默认具有修改的权限。

1.2 加式访问控制

Remedy的权限是不断追加的。也就是说初始用户没有任何权限，管理员根据需要为用户添加相应权限。

服务器核验对授权对象的访问权限。如果在决策树的任何阶段进行了授权，如图“授权”所示，则用户即可获取访问对象的权限。当你对多种remedy对象添加了权限，如果用户属于任何一个有权限的角色或组，则用户就可以访问它。

在这个例子中，Lydia属于两个组：Engineering组和EngineeringManager组。Engineering组无权访问Form1，但EngineeringManager组可以访问。因此，尽管Lydia在Engineering组没有权限访问Form1，但另一个组有，那么她就可以访问Form1。

授权

你必须为每个需要设置访问控制的应用、form、field、active link\ active link guide、packing
list以及WebService分配权限。首先需要对应用和form规划权限。然后为了节省时间并减少错误，你需要在创建objects和fields前定义默认权限。当然你也可以使用批量编辑对话框和分配权限对话框集中对多个对象修改权限。更多信息参见Assigning
permissions.

1.3 用户隶属多个组

一个组织中用户通常属于多个组，用户继承每个所属组的权限。如果一个组对某个form、field、request、active link或者active
link guide拥有访问权限，那么组内的用户可以访问这些对象，即使用户所属的其他组对这些对象没有权限。

权限是如何工作的

因为Erin属于一个可以修改（change）Short Description字段的组，所以不论她其他的属组是否对该字段有change权限，她都可以change这个字段

2.
基于role的访问控制概述

在可部署的应用中，系统是基于角色进行访问控制的。和组类似，角色对form、field、active link等也有访问控制。与组不同的是，角色是为应用定义的，并关联到组上。

使用角色可以使在不同服务器上部署应用更简单。首先为组指定用户，然后为组关联对应的角色。这使你在服务器安装应用时，不必再重新定义应用中对象的各种权限。实际上角色就是针对某个应用的权限组合，是已经配置好了的权限，只要关联到组上就行，不用再针对应用中的对象逐一进行麻烦的配置。

说明：

简单讲，用户权限通常依照组的权限进行定义。在开发好的可以部署的应用中，使用的是角色权限，用户的权限最终是由用户所属组关联的角色来决定的。更多信息参见 Creating and mapping roles.

3.
多层级访问控制模型

Remedy系统使用多层级模型控制数据访问。在每个级别用户的权限都被检查，一旦通过，则进入下一级。除去active
link和active link guides（俗称工作流），如果在任何一点被拒绝，则用户都不能继续。如果是在workflow（工作流）中被拒绝，用户可以继续，但对数据的访问能力将受限制。

例如：如果用户没有访问表单的权限，那么他不能看到表单上的任何字段。再比如：一个用户能否访问一条数据，取决于他所在的组对这个表单有权限，并且对相应的字段也有权限，并且他有对应Request ID内容的隐式权限。
Remedy中的访问控制

3.1 访问控制层级

访问控制模型包含以下层级:

访问级别	描述
BMC Remedy AR System server 服务器级	当用户打开客户端，比如浏览器时，必须通过一个初始化校验。此时，用户必须输入用户名和密码，以及一个可选的验证码选项。Remedy服务器在客户端的每次请求事务中都会校验账户信息，比如打开表单、修改字段等。如果你的Remedy系统允许访客用户，那么这些用户可以不需要账号校验。参见User form access
Form 表单级	作为管理员，你需要根据表单是否对组可见或者可修改来给组分配权限。可见权限允许用户从对象列表中访问表单。隐藏权限使表单只能通过工作流才可访问。静态权限和动态权限从父组继承对表单的访问控制，如果一个组没有权限访问一个表单，那么组成员则无权查看表单或者修改表单含有的数据
Field 字段级	你可以对每个字段进行访问控制，包括不存数据的字段，如：trim fields（只用于显示提示）、 table fields（表区域）和active link control field（例如按钮）。你可以显示或隐藏字段，从而使字段只能通过工作流来修改访问权限。对于存数据的字段，你同样可以指定哪些组可以查看，哪些组可以修改。如果一个组无权访问某个字段，则该组的所有人都不能看到该字段
Active link 工作流级	Active link可以触发一系列工作流动作，除了可以控制对表单和字段的访问，你也可以控制对active link的访问。例如：你可以允许支持人员触发一系列active link，但不允许其他用户触发这些active link。组不会自动获取关联了active link字段的访问权限，你必须为组分配对active link和字段的权限。当用户点击按钮或者选择菜单时会触发active link，能触发的前提是：用户必须对按钮或者菜单，以及active link都有权限。
Active link guide 组合工作流级	Active link guide（组合工作流）是由一串active link组合而成，便于执行组合动作，并且里面的active link是有执行次序的。当你创建active link guide时，你需要指定可访问它的组。如果想访问一个active link guide，用户必须对active link guide和active link guide中的每个active link都有访问权限。如果用户可以访问active link guide中所有的active link，但没有active link guide的权限，那么这个active link guide将对此用户不可见
Request 行级	你可以严格控制谁可以访问表单中的数据。例如，你可能希望只有领导才能查看表里面部分秘密员工信息。或者你是一个外包公司，你的remedy作为总服务台为多个公司服务，你希望某个公司只能看到自己的数据。

4.
license如何影响访问控制

除了需要给服务器和应用组件license（授权）外，你必须为每个remedy的用户授予不同类型的license

尽管license并不是访问控制体系的一个组件，但license会影响一个用户可执行操作的能力，虽然你已给该用户赋予相应权限。例如：如果用户所属的组对某个字段有修改权限，但你没有给该用户可写的license，那么该用户依旧不能修改该字段。