Microsoft BHOLD 套件概念指南

  • 项目

Microsoft Identity Manager 2016 (MIM) 使组织可以管理用户标识和相关凭据的整个生命周期。 可以将它配置为同步标识、集中管理证书和密码以及跨异构系统预配用户。 IT 组织可以使用 MIM 定义从创建到停用期间用来管理标识的进程，并使这些进程实现自动化。

Microsoft BHOLD 套件通过添加基于角色的访问控制扩展 MIM 的这些功能。 BHOLD 使组织可以定义用户角色并控制对敏感数据和应用程序的访问。 访问以适合这这些角色的内容为基础。 BHOLD 套件包括简化组织内角色关系建模的服务和工具。 BHOLD 将角色映射到权限，验证角色定义和相关权限是否正确应用到用户。 这些功能与 MIM 完全集成，为最终用户和 IT 员工提供无缝体验。

本指南帮助你了解 BHOLD 套件如何与 MIM 一同工作，并包含以下话题：

  • 基于角色的访问控制
  • 证明
  • 报表
  • 访问管理连接器

不建议将 BHOLD 用于新部署。 Microsoft Entra ID 现在提供访问评审（取代 BHOLD 证明市场活动功能）和权利管理（取代访问分配功能）。

基于角色的访问控制

控制用户对数据和应用程序的访问最常见的方法是自定义访问控制 (DAC)。 在最常见的实现中，每个重要的对象都有标识的所有者。 所有者能够基于单个标识或组成员身份，允许或拒绝对对象或其他内容的访问。 实际上，DAC 常导致大量安全组，其中有的反映组织结构，有的表示功能分组（如作业类型或项目分配），还有的由出于临时目的而链接的用户和设备临时集合组成。 随着组织的发展，这些组内的成员身份变得越来越难管理。 例如，如果一个员工从一个项目转到另一个，则须手动更新用于控制对项目资产的访问的组。 在这种情况下，妨碍项目安全性或生产率的错误常常发生。

MIM 包括通过提供对组和通讯组列表成员身份的自动化控制帮助缓解此问题的功能。 但是，这尚未解决增扩的组的内在复杂性，这些组不一定有结构地相互关联。

显著减少增扩的一种方法是部署基于角色的访问控制 (RBAC)。 RBAC 并不取代 DAC。 RBAC 提供用于将用户和 IT 资源分类的框架，从而建立在 DAC 之上。 这便可以明确这二者的关系以及就该分类而言适当的访问权限。 例如，通过向用户分配指定用户职务和项目分配的属性，可以向用户授予访问工作所需工具和参与特定项目所需数据的权限。 用户处理不同的作业和不同的项目分配时，更改指定用户职务和项目的属性将自动阻止对仅用户前一职位所需资源的访问。

角色可采用分层方式包含在其他角色中（例如，销售经理和销售代表角色可包含在更广泛的销售角色中），因此，向特定角色分配适当权限并向共同承担更广泛的角色的每一个人提供适当权限非常容易。 例如，在医院，可以向所有医务人员提供查看患者记录的权限，但只向授予医生（医疗角色的子角色）为患者输入处方的权限。 同样，可拒绝属于文员角色的用户访问患者记录，帐务员（文员角色的子角色）除外，帐务员可获权访问患者记录中对医院为患者提供的服务计费所需的部分。

RBAC 的另一个优势是定义和强制职责分离 (SoD) 的能力。 这使组织可以定义授予不应由同一用户拥有的权限的角色组合，从而不能向特定用户分配允许该用户发起支付和授权支付的角色。 RBAC 提供自动强制此类策略的能力，而不是基于每个用户评估策略的有效实现的能力。

BHOLD 角色模型对象

可以通过 BHOLD 套件在组织内指定并组织角色、将用户映射到角色以及将适当权限映射到角色。 此结构称为角色模型，它包含并连接五种对象类型：

  • 组织单位
  • 用户
  • 角色
  • 权限
  • 应用程序

组织单位

组织单位 (OrgUnit) 是在 BHOLD 角色模型中组织用户的主要方式。 每个用户必须属于至少一个 OrgUnit。 （事实上，从 BHOLD 中最后的组织单位中删除用户时，也将从 BHOLD 数据库中删除用户的数据记录。）

重要

不应将 BHOLD 角色模型中的组织单位与 Active Directory 域服务 (AD DS) 中的组织单位混淆。 通常情况下，BHOLD 中的组织单位结构基于公司的组织和策略，而不是网络基础结构的要求。

虽然不是必需的，但在大多数情况下，在 BHOLD 中将组织单位组织起来，用于表示实际组织的分层结构，与下图相似：

示例组织结构图

在此示例中，角色模型用顶层组织单位表示整个公司（由总裁表示，因为总裁不是下层组织单位的一部分），或者可以将 BHOLD 根组织单位（始终存在）用于该用途。 将表示副总裁分管的公司部门的 OrgUnit 放在公司组织单位中。 接下来，将对应市场和销售总监的组织单位添加到市场和销售组织单位，将表示区域销售经理的组织单位放到东区销售经理的组织单位中。 不管理其他用户的销售人员将作为表示东区销售经理的组织单位的成员。 请注意，用户可以是任意级别的组织单位的成员。 例如，不是经理且上级为副总裁的行政助理将是副总裁组织单位的成员。

组织单位除了表示组织结构，还可以依照功能标准（例如项目或分工）对组用户和其他组织单位分组。 下图显示将如何使用组织单位根据客户类型对组销售助理分组：

示例项目组织

在此示例中，每个销售助理都属于两个组织单位：一个表示该助理在组织管理结构中的位置，另一个该助理表示的客户群（零售或企业）。 可以向每个组织单位分配不同的角色，接下来，可以向角色分配访问组织 IT 资源的不同权限。 此外，角色可以从父组织单位继承，简化向用户传播角色的过程。 另一方面，可以阻止继承特定角色，确保特定角色仅与适当的组织单位相关联。

可以使用 BHOLD Core Web 门户在 BHOLD Suite 中创建 OrgUnits。

用户

如上所述，每个用户必须属于至少一个组织单位 (OrgUnit)。 因为组织单位是关联用户和角色的主要机制，所以在大多数组织中，某个给定用户属于多个 OrgUnit 更易于将角色与该用户相关联。 但是，在某些情况下，可能必须将角色与用户关联，而不关联用户所属的任何 OrgUnit。 因此，可以直接向角色分配用户，并且从用户所属的 OrgUnit 获取角色。

用户在组织内不活跃时（例如请病假时），可将用户暂停，即撤回用户的所有权限，而不将用户从角色模型中删除。 返回岗位时，可重新激活用户，这将还原用户角色授权的所有权限。

可以通过 BHOLD Core Web 门户在 BHOLD 中单独创建用户对象，也可以使用访问管理连接器和 FIM 同步服务从Active Directory 域服务或人力资源应用程序等源导入用户信息。

可以不使用 FIM 同步服务，直接在 BHOLD 中创建用户。 在预生产或测试环境中进行角色建模时，这很有用。 还可以允许向外部用户（如承包商的员工）分配角色，从而允许他们在未添加到员工数据库的情况下访问 IT 资源；但是，这些用户不能使用 BHOLD 自助服务功能。

角色

如上所述，在基于角色的访问控制 (RBAC) 模型下，权限与角色关联，而不是与单个用户关联。 这使通过更改用户角色（而不是单独授权或拒绝用户权限）为每个用户提供执行职责所需的权限成为可能。 因此，权限分配不再要求 IT 部门参与，而是可以作为管理业务的一部分执行。 角色可以直接或通过使用子角色，聚合访问不同系统的权限，进一步减少 IT 参与管理用户权限的必要。

务必注意，角色是 RBAC 模型本身的一种功能；通常并未预配到目标应用程序。 这得 RBAC 可以与现有应用程序一起使用，现有应用程序的设计目的并不是使用角色或更改角色定义，在不必修改应用程序本身的情况下，满足不断变化的业务模型的需求。 如果目标应用程序设计为使用角色，那么将特定于应用程序的角色视为权限，即可将 BHOLD 角色模型中的角色与相应的应用程序角色相关联。

BHOLD 中，可以主要通过两种机制向用户分配角色：

  • 将角色分配给用户为成员的组织单位
  • 将角色直接分配给用户

可选择由成员组织单位继承分配到父级组织单位的角色。 将角色分配给组织单位或由组织单位继承角色时，可以将它指定为有效角色或建议角色。 如果是有效角色，那么组织单位中的所有用户都分配到该角色。 如果是建议角色，则必须为每个用户或成员组织单位激活它，它才能对该用户或组织单位的成员生效。 这样就可以向用户分配与组织单位关联的角色子集，而不是向所有成员自动分配组织单位的所有角色。 此外，可以给角色提供开始日期和结束日期，并设置组织单位内角色可生效的用户的百分比。

下图说明在 BHOLD 中如何给一个用户分配角色：

角色分配

在此图中，角色 A 作为可继承角色分配给组织单位，继而被其成员组织单位和这些组织单位内的所有用户继承。 角色 B 作为组织单位的建议角色分配。 必须先激活它，然后才能向组织单位内的用户授予该角色的权限。 角色 C 是有效角色，所以它的权限立即应用于组织单位内的所有用户。 角色 D 直接链接到用户，所以其权限立即应用于该用户。

此外，可以根据用户的属性为其激活角色。 有关详细信息，请参阅基于属性的授权。

权限

BHOLD 中的一个权限相当于从目标应用程序导入的一个授权。 也就是说，当 BHOLD 配置为与应用程序一起工作时，它接收 BHOLD 可以链接到角色的授权列表。 例如，Active Directory 域服务 (AD DS) 作为应用程序添加到 BHOLD 时，它作接收为 BHOLD 权限、可以链接到 BHOLD 中的角色的安全组列表。

权限特定于应用程序。 BHOLD 提供一个统一的权限视图，使权限可以与角色相关联，而无需角色管理器了解权限的实现详细信息。 实际上，不同系统可能用不同的方法强制执行权限。 从 FIM 同步服务到应用程序，特定于应用程序的连接器确定如何为该应用程序提供针对某个用户的权限更改。

应用程序

BHOLD 实现一种向外部应用程序应用基于角色的访问控制 (RBAC) 的方法。 换言之，当 BHOLD 预配有用户和应用程序中的权限时，它可以向用户分配角色，再将权限到角色，通过这种方式将权限与用户关联起来。 然后，应用程序的后台进程可以基于 BHOLD 中的角色/权限映射，向其用户映射正确的权限。

开发 BHOLD 套件角色模型

BHOLD 套件提供模型生成器（一种易用的综合工具）帮助开发角色模型。

使用模型生成器之前，必须创建一系列文件，这些文件定义模型生成用来构造角色模型的对象。 有关如何创建这些文件的信息，请参阅 Microsoft BHOLD 套件技术参考。

使用 BHOLD 模型生成器的第一步是导入这些文件，从而将基本构建基块加载到模型生成器中。 文件成功加载时，可以指定模型生成器用语创建角色的几个类的条件：

  • 基于用户所属的 OrgUnit（组织单位）分配给用户的成员角色
  • 基于用户在 BHOLD 数据库中的属性分配给用户的属性角色
  • 链接到组织单位但必须为特定用户激活的建议角色
  • 所有者角色，它允许用户控制组织单位和导入的文件中未指定所有者的角色

重要

上传文件时，只在测试环境中选择“保留现有模型”复选框。 在生产环境中，必须使用模型生成器创建初始角色模型。 不能用它在 BHOLD 数据库中修改现有角色模型。

模型生成器在角色模型中创建角色后，可以使用 XML 文件格式将角色模型导出到 BHOLD 数据库。

高级 BHOLD 功能

前面几部分描述 BHOLD 中基于角色的访问控制 (RBAC) 的基础功能。 本部分概述 BHOLD 的其他功能，这些功能可以为组织实现 RBAC 增强安全性、提高灵活性。 本部分提供以下 BHOLD 功能的概述：

  • 基数
  • 职责分离
  • 上下文自适应权限
  • 基于属性的授权
  • 灵活的属性类型

基数

基数是指业务规则的实现，其中业务规则旨在限制两个实体相互关联的次数。 就 BHOLD 而言，可为角色、权限和用户建立基数规则。

可以配置角色，设定以下限制：

  • 建议角色可以激活的最大用户数
  • 可链接到角色的最大子角色数
  • 可链接到角色的最大权限数

可以配置权限，设定以下限制：

  • 可链接到权限的最大角色数
  • 可授予权限的最大用户数

可以配置用户，设定以下限制：

  • 可链接到用户的最大角色数
  • 可通过角色分配分配给用户的最大权限数

职责分离

职责分离 (SoD) 是一条商业原则，旨在防止个人获得能力执行不应向一个人提供的操作。 例如，一名员工应不能请求付款并授权付款。 SoD 原则使组织可以实现一个检查和平衡系统，尽量降低因员工错误或不当行为而面临风险的几率。

BHOLD 通过使你定义不兼容权限来实现 SoD。 定义这些权限后，BHOLD 通过以下两种方式强制执行 SoD：阻止创建链接到不兼容的权限的角色（无论链接方式是直接链接，还是通过继承链接）；防止向用户分配多个角色，通过直接分配或继承将这些角色结合起来将授予不兼容的权限。 可视需要覆盖冲突。

上下文自适应权限

通过创建可基于对象属性自动修改的权限，可以减少需要管理的权限总数。 通过上下文自适应权限 (CAP) 可以定义一个公式作为权限属性，它修改与权限关联的应用程序应用权限的方式。 例如，可以根据用户是否属于含全职员工或合同工的组织单位，创建一个更改对文件夹的访问权限的公式（通过与文件夹访问控制列表相关联的安全组）。 如果员工从一个组织单位移到另一个，将自动应用新权限并停用旧权限。

CAP 公式可以查询已应用到应用程序、权限、组织单位和用户的属性值。

基于属性的授权

控制是否为组织单位中的特定用户激活了链接到组织单位的角色的一种方法是使用基于属性的授权 (ABA)。 通过使用 ABA，可以只在满足基于用户属性的某些规则时才自动激活角色。 例如，仅当用户的职务与 ABA 规则中的职位匹配时，可以将角色链接到为角色激活的组织单位。 这样就不需要为用户手动激活建议角色。 相反，可以为组织单位中具有满足角色 ABA 规则的属性值的所有用户激活角色。 规则可以合并，所以仅在用户属性满足所有为该角色指定的 ABA 规则时才激活角色。

请务必注意，基数设置限制 ABA 规则测试的结果。 例如，如果一个规则的基数设置指定仅可以向两个用户分配角色，并且如果 ABA 规则另外为四个用户激活角色，那么只为前两个通过 ABA 测试的用户激活角色。

灵活的属性类型

BHOLD 中属性系统的可扩展性很高。 可以为此类对象将新属性类型定义为用户、组织单位和角色。 可以将属性定义为具有以下值：整数、布尔值（是/否）、字母数字、日期、时间和电子邮件地址。 可以将属性指定为单一值或值列表。

证明

BHOLD 套件提供工具，可使用这些工具验证是否已向单个用户授予完成业务任务的适当权限。 管理员可以使用 BHOLD 证明模块提供的门户来设计和管理证明过程。

证明进程通过市场活动实施，其中市场活动专员有机会和方法证明他们负责的用户拥有访问 BHOLD 托管应用程序的适当权限以及这些应用程序内的正确权限。 指定市场活动所有者监督市场活动并确保市场活动正确执行。 可以将市场活动创建为发生一次或重复发生。

市场活动专员通常一名经理，他将证明属于由其负责的一个或多个组织单位的用户的访问权限。 可以根据用户属性，为在市场活动中进行证明的用户自动选择专员，也可通过以下方式定义市场活动专员：在文件中列出专员，该文件将在市场活动中进行证明的每个用户映射为专员。

市场活动开始时，BHOLD 向市场活动专员和所有者发送电子邮件通知消息，然后发送定期提醒帮助他们保持市场活动进展。 将专员定向到市场活动门户，在该门户中他们可以看见其负责的用户的列表和分配给那些用户的角色。 然后，他们可以确认自己是否对列出的每个用户负责，并批准或拒绝列出的每个用户的访问权限。

市场活动所有者也使用该门户监视市场活动进程和记录各项活动，从而可以分析市场活动期间采取的措施。

报表

BHOLD 报表模块提供通过多种报表在角色模型中查看信息的能力。 它提供内置报表的扩展集，并且包括可以用来创建基础和高级自定义报表的向导。 运行报表时，可以立即显示结果或将结果保存到 Microsoft Excel (.xlsx) 文件中。 要使用 Microsoft Excel 2000、Microsoft Excel 2002 或 Microsoft Excel 2003 查看此文件，可以下载并安装适用于 Word、Excel 和 PowerPoint 文件格式的 Microsoft Office 兼容包。

BHOLD 报表模块的主要用途是生成基于当前角色信息的报表。 对于生成的报表（用于审核对标识信息的更改），Forefront Identity Manager 2010 R2 具有在 System Center Service Manager 数据仓库中实现的 FIM 服务的报表功能。 有关 FIM 报表的详细信息，请参阅 Forefront Identity Management 技术库中的 Forefront Identity Manager 2010 和 Forefront Identity Manager 2010 R2 文档。

内置报表涵盖的分类包括以下类别：

  • 管理
  • 证明
  • 控件
  • 向内访问控制
  • 日志记录
  • 型号
  • 统计信息
  • 工作流

可以创建报表并将其添加到这些类别，或者可以定义自己用来防止自定义和内置报表的类别。

生成报表时，向导引导用户按步骤提供以下参数：

  • 识别信息，包括名称、描述、类别、使用情况和受众
  • 要在报表中显示的字段
  • 指定分析项目的查询
  • 对行进行排序的顺序
  • 用于将报表分段的字段
  • 优化在报表中返回的元素的筛选器

在向导的每一阶段都可以预览目前已定义的报表，并可以在不需要指定其他参数时保存报表。 还可以返回上一步骤，更改之前在向导中指定的参数。

访问管理连接器

BHOLD 套件访问管理连接器模块支持向 BHOLD 中进行数据的初始同步和正在进行的同步。 访问管理连接器和 FIM 同步服务一同在 BHOLD 核心数据库、MIM Metaverse、目标应用程序和标识存储中移动数据。

BHOLD 的早期版本需要多个 MA 来控制 MIM 和中间 BHOLD 数据库表之间的数据流。 在 BHOLD 套件 SP1 中，可通过访问管理连接器在直接在 BHOLD 和 MIM 之间提供数据传输的 MIM 中定义管理代理 (MA)。

后续步骤