IBM Security Verify Governance (ISVG) 与LDAP设计-CSDN博客

本文链接：https://blog.csdn.net/m0_50657013/article/details/149037741

一、组织架构信息

BM Security Verify Governance (ISVG) 支持将 HR 系统中的组织架构和人员信息导入到其系统中。 这实际上是 ISVG 作为身份治理和管理 (IGA) 解决方案的核心功能之一，被称为“身份生命周期管理 (Identity Lifecycle Management)”。

1、为什么需要导入 HR 数据？

HR 系统（如 Workday, SAP SuccessFactors, Oracle HCM 等）通常被认为是企业中最权威的身份数据源。它包含了员工的：

基本信息： 姓名、员工ID、联系方式等。
组织架构信息： 部门、职位、经理关系、汇报层级等。
雇佣状态： 入职、离职、调岗、休假等。

将这些数据导入到 ISVG 中，可以实现：

自动化用户生命周期管理：
- 入职 (Joiner)： 当新员工在 HR 系统中创建时，ISVG 可以自动创建其在各种 IT 系统（如 Active Directory、电子邮件系统、业务应用程序）中的账户和基本权限。
- 调岗 (Mover)： 当员工调岗或部门变更时，ISVG 可以根据新的组织架构和角色，自动调整其在各个系统中的访问权限，并撤销不再需要的权限。
- 离职 (Leaver)： 当员工离职时，ISVG 可以自动禁用或删除其在所有相关系统中的账户和权限，大大降低了安全风险。
构建准确的身份视图： ISVG 需要一个准确、实时的用户身份数据，才能正确地管理访问权限、进行职责分离 (SoD) 分析、执行访问认证等。HR 数据是构建这个“单一身份真理源”的基础。
支持访问请求和审批： 用户的访问请求和审批流程通常需要基于其组织角色、部门和经理关系。导入 HR 数据可以为这些流程提供必要上下文。

2、如何导入 HR 数据到 ISVG？

ISVG 通常通过以下方式与 HR 系统集成：

1.HR Feed 适配器 (HR Feed Adapters)：

ISVG 提供了专门的 HR Feed 适配器（例如，针对 SAP HR 的适配器），用于从 HR 系统中定期拉取 (pull) 或接收 (receive) 人员和组织架构数据。
这些适配器通常基于 IBM Security Directory Integrator (SDI) 构建，SDI 是一个强大的数据集成工具，能够处理各种数据格式（如 CSV、XML、数据库连接）和转换逻辑。
通过配置适配器，你可以定义从 HR 系统中获取哪些属性（例如，员工ID、姓名、部门、经理、雇佣状态等），以及这些属性如何映射到 ISVG 中的“人员 (Person)”或“业务人员 (Business Person)”实体。

2.文件导入 (File Import)：

如果无法建立实时或定期的适配器连接，你也可以通过定期导出 HR 数据为 CSV 或其他格式的文件，然后将这些文件导入到 ISVG 中。
ISVG 提供了导入功能，允许你映射文件中的列到 ISVG 中的用户属性。

3.API 集成 (API Integration)：

对于一些现代的 HR 系统，它们可能提供 RESTful API。ISVG 也可以通过自定义的连接器或 Assembly Lines (在 SDI 中) 调用这些 API 来实时或准实时地同步数据。

4.配置服务 (Service Configuration)：

在 ISVG 的管理控制台中，你需要为 HR 系统创建一个“服务”，并配置相应的 HR Feed 适配器或数据源。
这个服务会定期运行，将 HR 系统中的变更同步到 ISVG 的身份存储库中。

总结

将 HR 系统中的组织架构和人员信息导入到 ISVG 是实现自动化身份管理和有效访问治理的基石。ISVG 提供了多种机制（主要是通过 HR Feed 适配器和数据同步）来实现这一关键集成。

二、应用程序如何读取组织架构、账户信息

应用程序如何读取 ISVG 中的组织架构信息，以及是否需要特殊配置，这取决于应用程序的集成方式和其自身的设计。ISVG 不会直接将其内部的组织架构数据暴露给所有应用程序，而是通过特定的集成点和机制。

以下是应用程序读取 ISVG 中组织架构信息的几种主要方式，以及是否需要特殊配置的说明：

1、通过集中式目录服务（如 LDAP）

这是最常见且推荐的方式。

ISVG 的作用： ISVG 通常会将从 HR 系统导入的组织架构和人员信息同步到企业级的集中式目录服务中（例如，Active Directory、IBM Security Directory Server、OpenLDAP 等）。ISVG 自身可以作为这些目录的“更新者”，确保目录中的数据与 HR 系统保持一致。
应用程序如何读取： 应用程序会直接连接到这个集中式目录服务（LDAP），并查询所需的用户属性和组织结构信息（例如，用户的部门、经理、所属组织单位 OU 等）。
是否需要特殊配置：
- 应用程序侧： 需要配置应用程序以连接到 LDAP 服务器，并指定查询用户的 DN 路径、过滤器以及需要读取的属性。这对于任何需要从 LDAP 获取用户信息的应用程序都是标准配置。
- ISVG 侧： 需要配置 ISVG 的适配器或连接器，确保它能将 HR 系统中的组织架构数据正确地同步到目标 LDAP 目录中。这通常涉及到属性映射和同步规则的配置。

优点： 应用程序不需要直接与 ISVG 交互，而是依赖于一个标准化的、高性能的目录服务。这简化了应用程序的集成，并利用了 LDAP 广泛的兼容性。

2、通过 ISVG 的 REST API

ISVG 提供了丰富的 RESTful API，允许外部应用程序以编程方式访问其内部数据。

ISVG 的作用： ISVG 维护着其内部的组织单元 (Organizational Units)、用户 (Users) 等数据模型。
应用程序如何读取： 应用程序可以通过调用 ISVG 提供的 REST API 来查询特定的用户、组织单元或其之间的关系。例如，可以查询某个用户的经理是谁，或者某个部门下有哪些用户。
是否需要特殊配置：
- 应用程序侧： 应用程序需要开发相应的代码来调用 ISVG 的 REST API，包括处理认证（例如 OAuth2 令牌）、构建请求、解析响应（通常是 JSON 格式）。
- ISVG 侧： 需要确保 ISVG 的 REST API 接口已启用，并且为调用应用程序提供了适当的权限。可能还需要配置 API 网关或反向代理以确保安全访问。

优点： 提供了更灵活、更直接的访问 ISVG 内部数据的方式，适用于需要实时或按需获取特定治理数据的场景。

3、通过 ISVG 的报告或数据导出

对于不需要实时同步，或者只需要定期获取组织结构快照的场景。

ISVG 的作用： ISVG 可以生成包含组织架构和人员信息的报告或数据导出文件（例如 CSV、XML）。
应用程序如何读取： 应用程序或脚本可以定期获取这些报告文件，然后解析文件以提取所需信息。
是否需要特殊配置：
- 应用程序侧： 需要开发脚本或程序来自动化报告的下载和解析过程。
- ISVG 侧： 需要配置 ISVG 的报告功能，定义报告的生成内容、格式和调度。

优点： 简单易实现，适用于非实时的数据分析或审计需求。

总结

最常见和推荐的方式是让 ISVG 将组织架构信息同步到企业级的 LDAP 目录中，然后应用程序从 LDAP 中读取。 这种方式下，应用程序的配置是标准的 LDAP 连接配置。
如果应用程序需要更直接、更实时的访问 ISVG 内部的治理数据（例如，用于复杂的工作流或审计），则可以通过 ISVG 的 REST API 进行集成，这需要应用程序进行更具体的编程开发。
对于非实时的数据需求，也可以通过 ISVG 的报告或数据导出功能。

无论哪种方式，都需要在 ISVG 端进行配置，以确保数据的正确导入、同步和对外暴露（通过 LDAP 或 API）。

三、LDAP设计

1、应用程序如何与组织结构信息关联

1.应用程序仅需用户基本信息和直接权限：

大多数应用程序，特别是那些不涉及复杂工作流或需要深度了解组织层级的应用（例如，一个普通的内部网站、一个简单的文件共享系统），它们通常只需要用户的基本账户信息（如用户名、电子邮件、直接分配的角色或组）来进行认证和授权。
在这种情况下，这些应用程序只需在它们配置的特定 DN 路径下找到用户对象，并读取用户的基本属性和组成员资格即可。它们不需要从这个 DN 下“存储”或查询整个组织的层级关系（例如，谁是我的经理，我的部门属于哪个上级部门）。

2.应用程序需要访问组织结构信息：

对于那些需要经理审批、基于部门或团队动态授权、或提供组织内人员查找功能的应用程序（例如，报销系统、CRM 系统、内部通信工具），它们才需要能够查询到组织结构信息。
在这种情况下，应用程序通常会连接到整个企业级 LDAP 目录的根部或一个更宽泛的搜索基准 (Search Base)，并执行查询来获取用户的部门、经理、或者其他组织单位 (OU) 信息。这些组织单位本身（OU 对象）可能在 LDAP 目录中以树状结构被表示，反映了企业的层级关系。
LDAP 目录的通用设计原则是： 人员对象（inetOrgPerson 或 user 类）通常会包含指向其所属组织单元（OU）或其经理的用户对象的引用属性（例如 manager 属性），而不是在每个用户对象或每个应用程序特定 DN 下重复存储整个组织树。组织结构本身通常通过 LDAP 目录中的 organizationalUnit (OU) 对象 的层级关系来构建。

2、LDAP 目录的组织方式与应用程序查询

设想一个标准的 LDAP 目录结构：

dc=yourcompany,dc=com
  ├── ou=Users  (所有企业用户都可能在这里，或者按部门再细分)
  │    ├── cn=Alice,ou=HR,ou=Users,dc=yourcompany,dc=com
  │    └── cn=Bob,ou=Sales,ou=Users,dc=yourcompany,dc=com
  ├── ou=Groups (所有企业组都可能在这里)
  │    ├── cn=HR_Team,ou=Groups,dc=yourcompany,dc=com
  │    └── cn=Sales_Team,ou=Groups,dc=yourcompany,dc=com
  └── ou=OrganizationUnits (如果需要明确表示组织层级)
       ├── ou=CEO Office
       ├── ou=HR (包含 hr = Alice)
       └── ou=Sales (包含 sales = Bob)

在这种结构下：

应用程序A（只看用户自身属性）： 配置为在 ou=Users,dc=yourcompany,dc=com 下查找用户。它只需要用户 Alice 的 cn、mail、uid 等属性。
应用程序B（需要经理审批）： 配置为在 dc=yourcompany,dc=com 下进行更宽泛的搜索，或者它会查询 Alice 的 manager 属性（这个属性通常存储经理的 DN），然后根据这个 DN 再去 LDAP 中查找经理的用户对象。
组织结构信息本身，通常通过 ou 对象的嵌套关系以及用户对象上的引用属性（如 manager）来体现，而不是在每个用户的特定 DN 下复制整个组织图。

总结

每个应用程序对应的 DN 下，通常只存储该应用程序用户自身的特定属性和直接权限。
完整的组织结构信息（如部门层级、汇报关系）通常存储在 LDAP 目录的更上层结构中（通过 ou 对象的层级和用户对象上的引用属性），并且可供所有授权的应用程序查询。
ISVG 在这里扮演了关键角色，它负责从 HR 系统获取这些完整的组织结构数据，并将其同步到企业级的 LDAP 目录中，确保目录的权威性和准确性。应用程序再从这个统一的 LDAP 目录中获取所需信息。

所以，核心在于“访问”而非“存储”。应用程序需要能访问到组织结构信息，但这些信息并非分散存储在每个应用程序的特定 DN 下，而是集中在企业目录的逻辑结构中。

四、复杂的LDAP设计

如何设计一个单一的 LDAP 目录，能够同时满足不同应用程序（A、B、C）对用户身份和组织架构信息的不同需求？

1、统一 LDAP 目录设计核心理念

在企业环境中，我们的目标是建立一个统一、权威且集中管理的 LDAP 目录。这个目录将包含所有用户的身份信息，以及反映企业层级的组织结构。

应用程序不会拥有独立的 LDAP 存储。相反，所有应用程序都会作为“消费者”，从这个统一的 LDAP 目录中获取它们所需的用户和（如果需要）组织信息。

这个统一的 LDAP 目录是 ISVG 从 HR 系统同步数据的地方，也是所有应用程序查询数据的地方。

2、LDAP 目录结构设计示例

让我们采用一个标准且灵活的 LDAP 目录结构。dc=yourcompany,dc=com 是你的根域。

dc=yourcompany,dc=com
  ├── ou=People           <-- 核心用户对象存储（可以是任何名称，如 Users）
  │    ├── ou=Active
  │    │    ├── ou=Sales        <-- 销售部活跃用户
  │    │    │    └── cn=Alice,ou=Sales,ou=Active,ou=People,dc=yourcompany,dc=com
  │    │    │                     (属性: uid, mail, userPassword, givenName, sn, employeeType=Full-Time, manager=cn=Bob,ou=Managers,ou=People,...等)
  │    │    └── ou=Marketing    <-- 市场部活跃用户
  │    │         └── cn=Charlie,ou=Marketing,ou=Active,ou=People,dc=yourcompany,dc=com
  │    └── ou=Inactive        <-- 离职/非活跃用户
  │         └── cn=Dianne,ou=Inactive,ou=People,dc=yourcompany,dc=com
  │
  ├── ou=Managers         <-- 存储经理的用户对象（如果需要单独的经理列表）
  │    └── cn=Bob,ou=Managers,ou=People,dc=yourcompany,dc=com
  │                     (Bob也是一个用户，可能也在ou=Active下有对应的条目，这里只是示例区分)
  │
  ├── ou=Groups           <-- 所有安全组和分发组
  │    ├── cn=AppA_Admins,ou=Groups,dc=yourcompany,dc=com
  │    ├── cn=Sales_Team,ou=Groups,dc=yourcompany,dc=com
  │    ├── cn=Marketing_Team,ou=Groups,dc=yourcompany,dc=com
  │    └── cn=AppC_Users,ou=Groups,dc=yourcompany,dc=com
  │
  └── ou=OrgUnits         <-- 明确的组织单位层级（如果应用程序需要查询部门结构）
       ├── ou=CEO_Office
       ├── ou=Sales_Dept   <-- 代表销售部门
       └── ou=Marketing_Dept <-- 代表市场部门

关键点说明：

所有用户都在 ou=People 下（或其子 OU），这是所有应用程序查询用户的入口。
组织结构信息：
- 隐式体现： 通过用户对象所在的 OU 路径（例如 cn=Alice,ou=Sales,ou=Active,ou=People,... 已经表明 Alice 属于销售部）。
- 显式体现： 通过专门的 ou=OrgUnits 分支，存储各个部门的 OU 对象，这些 OU 对象可以有自己的属性（如部门描述、部门主管）。
- 经理关系： 用户对象上会有 manager 属性，其值通常是指向经理用户对象的 DN（例如 manager: cn=Bob,ou=Managers,ou=People,...），而不是存储经理的姓名。

3、应用程序如何集成和查询

现在，我们看看应用程序A、B、C如何从这个统一的 LDAP 目录中获取它们所需的信息，而无需修改 LDAP 结构或在不同 DN 下复制信息。它们只是使用不同的搜索基准 (Search Base) 和过滤器 (Filter)。

1. 应用程序 A (复杂授权，可能看角色和一些用户属性)

需求： 需要用户的基本信息，以及用户所属的组/角色信息，以进行细粒度授权。
LDAP 配置：
- 搜索基准 (Search Base)： ou=People,dc=yourcompany,dc=com (因为它需要找到所有用户)
- 用户过滤器 (User Filter)： (&(uid={0})(objectClass=inetOrgPerson))
- 要读取的属性： uid, mail, cn, memberOf (如果组信息存储在用户对象的这个属性中), 或 isMemberOf (如果通过虚拟属性查询组成员) 等。
如何满足： 应用程序A会查询用户对象，并读取其 memberOf 属性（指示用户是哪些组的成员）。这些组（如 cn=AppA_Admins）定义在 ou=Groups 下。应用程序A根据这些组成员资格进行授权。

2. 应用程序 B (需要经理审批，需要组织架构信息)

需求： 需要用户的基本信息，以及用户的经理信息（进行审批流程）。可能还需要了解用户所在的部门。
LDAP 配置：
- 搜索基准 (Search Base)： dc=yourcompany,dc=com (因为它可能需要向上查找经理的 DN，或跨多个 OU 搜索)
- 用户过滤器 (User Filter)： (&(uid={0})(objectClass=inetOrgPerson))
- 要读取的属性： uid, mail, cn, manager (指向经理 DN 的属性), departmentNumber (如果部门号存储在用户属性中), 或用户所属的 OU 信息（通过解析用户 DN）。
如何满足：
- 应用程序B通过 uid 找到用户 Alice 的 DN。
- 读取 Alice 用户对象上的 manager 属性（例如，cn=Bob,ou=Managers,ou=People,dc=yourcompany,dc=com）。
- 应用程序B再执行第二次 LDAP 查询，查找 manager 属性中 DN 对应的用户对象 Bob，从而获取经理 Bob 的信息（如姓名、电子邮件）。
- 如果需要部门名称，可以读取用户对象上的 ou 属性，或者通过 departmentNumber 属性，甚至解析用户 DN 的路径。

3. 应用程序 C (只看用户自身属性，如是否活跃)

需求： 只需要用户的基本认证信息（用户名、密码）和一个表示账户是否活跃的标志。
LDAP 配置：
- 搜索基准 (Search Base)： ou=People,dc=yourcompany,dc=com (或者更精确的 ou=Active,ou=People,dc=yourcompany,dc=com)
- 用户过滤器 (User Filter)： (&(uid={0})(objectClass=inetOrgPerson))
- 要读取的属性： uid, userPassword, mail, cn, accountStatus (假设我们添加了一个自定义属性表示账户状态)。
如何满足：
- 应用程序C会向 LDAP 查询用户（例如 Alice）。
- 它读取 userPassword 进行认证。
- 它读取自定义的 accountStatus 属性（或判断用户对象是否在 ou=Active 下）来确定用户账户是否启用。

4、ISVG 在此统一设计中的角色

IBM Security Verify Governance (ISVG) 在这个统一的 LDAP 目录设计中扮演了核心的“身份权威和同步”角色：

HR 数据源： ISVG 连接到你的 HR 系统，作为企业人员信息的权威来源。
LDAP 数据写入： ISVG 将从 HR 系统获取的所有人员信息（包括基本属性、部门、经理关系、雇佣状态等）同步写入到这个统一的 LDAP 目录中，并根据员工生命周期事件（入职、调动、离职）更新 LDAP 中的用户对象。例如，ISVG 会确保：
- 新员工在 ou=People 下创建账户。
- 员工调岗时，其用户对象可能在 LDAP 中移动到新的 OU 下，并更新 manager、departmentNumber 等属性。
- 员工离职时，账户被禁用并可能移动到 ou=Inactive。
统一治理： ISVG 利用这个统一的 LDAP 目录中的数据来执行复杂的职责分离分析、访问认证和审计。
权限供应： ISVG 还会根据这些身份信息和策略，将具体的权限（如 AppA 的管理权限、AppB 的审批权限）供应给各个应用程序， 而应用程序只需“消费”这些由 ISVG 管理和供应的权限。

总结

最终的设计是：

一个统一且结构合理的 LDAP 目录，作为企业身份和组织架构的唯一权威来源。
所有用户账户和必要的组织结构信息都存储在这个目录中。
应用程序A、B、C 都连接到这个同一个 LDAP 目录。
它们之间的区别在于： 它们各自的 LDAP 搜索基准、过滤器以及它们需要从用户对象上读取哪些属性。

这种设计避免了数据冗余、简化了管理，并为 ISVG 提供了进行全面身份治理所需的所有上下文信息。

五、更好的实践：一个统一的 LDAP，通过组和权限实现隔离

对于大多数企业场景，更推荐和更符合 ISVG 理念的做法是：维护一个统一的 LDAP 目录，所有用户（无论属于哪个应用程序）都在一个共享的 ou=People 或其逻辑子 OU 下，并通过 LDAP 中的组 (Groups)** 和权限委派来实现应用程序间的隔离和授权。

示例：

dc=yourcompany,dc=com
  ├── ou=People           <-- 所有用户都在这里
  │    ├── cn=Alice,ou=People,...  (Alice需要访问AppA和AppC)
  │    └── cn=Bob,ou=People,...    (Bob只需要访问AppC)
  │
  └── ou=Groups           <-- 所有组都在这里
       ├── cn=AppA_Users,ou=Groups,... (Alice是这个组的成员)
       └── cn=AppC_Users,ou=Groups,... (Alice和Bob都是这个组的成员)

如何实现隔离和授权：

1.LDAP 权限：

应用程序 A 的服务账户只被授权读取 ou=People 下的用户，但其授权逻辑只检查用户是否属于 cn=AppA_Users 组。
应用程序 C 的服务账户只被授权读取 ou=People 下的用户，但其授权逻辑只检查用户是否属于 cn=AppC_Users 组。
关键是： 应用程序读取用户后，会根据用户的组成员资格来判断其是否有权访问。

2.ISVG 的管理：

ISVG 从 HR 系统同步用户到统一的 ou=People DN 下。
ISVG 负责管理用户在各个应用程序特定组中的成员资格。例如，ISVG 可以根据 Alice 的业务角色，自动将其添加到 cn=AppA_Users 和 cn=AppC_Users 组。
ISVG 可以定义策略，如果用户不在 cn=AppA_Users 组中，即使他能被应用程序 A 的服务账户读取到，应用程序 A 的授权逻辑也会拒绝其访问。

这种方法的优势：

无用户数据冗余： 每个用户在 LDAP 中只有一个条目。
简化同步： ISVG 到 LDAP 的同步逻辑更简单、更可靠。
易于 SSO： 用户只需一套凭据即可访问所有应用程序。
集中管理： 统一的用户视图，便于全局审计和管理。
灵活性： 通过调整组成员资格，可以非常灵活地控制用户对不同应用程序的访问。

结论

更好推荐的做法是： 采用一个统一的 LDAP 目录来存储所有用户，并通过 LDAP 组、应用程序授权逻辑和 ISVG 的组管理能力来隔离和控制用户对不同应用程序的访问。这样可以在不牺牲管理效率和用户体验的前提下，实现安全和隔离。

六、总结

也就是说，通常考虑两种情形：1，应用程序只需要访问账户信息；2，应用程序需要访问组织架构信息和账户信息。

1、两种主要的应用需求情景

1.应用程序只需要访问账户信息

场景： 这是最常见的需求。应用程序需要验证用户身份（认证）并根据用户的基本属性或直接的组成员资格来授权（例如，用户是否是某个特定应用角色的成员）。这类应用不关心用户的经理是谁、属于哪个部门层级，或者用户在组织架构中的位置。
LDAP 集成： 应用程序会配置 LDAP 连接，指定一个较窄的搜索基准 (Search Base)（比如 ou=People,dc=yourcompany,dc=com），然后通过过滤器 (Filter) 查找用户，并读取其基本的账户属性（uid、mail、userPassword、cn 等）以及组成员资格（通过 memberOf 或类似属性）。
ISVG 作用： ISVG 负责将 HR 系统中的用户基本信息同步到 LDAP，并根据用户的业务角色，管理其在 LDAP 中对应的应用程序特定组的成员资格。

2.应用程序需要访问组织架构信息和账户信息

场景： 这类应用程序需要更深层次的身份上下文，通常用于实现复杂的业务逻辑。例如，审批工作流需要查找用户的直接经理或部门主管；报表系统可能需要按部门聚合数据；某些协作工具需要展示用户的组织层级信息。
LDAP 集成： 应用程序的 LDAP 配置会使用一个更宽泛的搜索基准（例如，dc=yourcompany,dc=com），以便能够查询整个目录树中的用户和组织单元 (OU) 对象。它们会读取用户对象上的特定属性，如 manager（指向经理的 DN）、departmentNumber、ou（用户所属的组织单位）。如果需要更详细的组织层级，应用程序可能需要多次查询来遍历 OU 树。
ISVG 作用： ISVG 从 HR 系统导入完整的组织架构（包括部门、经理关系），并将其精确地同步到 LDAP 目录中。它确保用户对象上的 manager 属性是准确的，并且 LDAP 目录中的 OU 结构反映了企业的实际组织层级。这样，需要这些信息的应用程序就能从 LDAP 中获取权威的、最新的组织上下文。

2、统一 LDAP 目录的优势

无论哪种情景，关键都在于一个统一且权威的 LDAP 目录。

集中管理： 所有用户数据和核心组织结构都存储在一个地方。
消除冗余： 每个用户只有一个账户条目，避免了数据不一致和同步复杂性。
提高效率： ISVG 自动化了从 HR 到 LDAP 的数据同步，以及从 LDAP 到应用程序的账户和权限供应。
强化安全与合规： 统一的目录是实现单点登录、细粒度授权、职责分离 (SoD) 和审计的基础。

通过这种方式，你的 LDAP 目录可以满足各种应用程序的不同需求，而 ISVG 则作为强大的身份治理引擎，确保目录数据的准确性、一致性和安全性。

总结一下核心要点：

我们确立了一个关于 IBM Security Verify Governance (ISVG) 与 LDAP 目录设计 的最佳实践路径：

统一的 LDAP 目录： 这是基石。企业应该拥有一个单一、权威且集中的 LDAP 目录，作为所有用户身份和核心组织结构信息的“真相之源”。
ISVG 的核心作用： ISVG 作为强大的身份治理引擎，负责从 HR 系统（作为最权威的人员数据来源）获取所有人员和组织架构信息，并将其准确、及时地同步到统一的 LDAP 目录中。它还管理用户的身份生命周期（入职、调动、离职）以及在各个应用中的权限供应。
应用程序的“按需”访问：
- 需要账户信息（多数应用）： 大多数应用程序只需要用户的基本账户信息和组成员资格进行认证和授权。它们会配置 LDAP 搜索基准和过滤器，只读取所需的属性。
- 需要组织架构信息（少数应用）： 只有那些确实需要经理审批、部门报告或基于组织层级进行操作的应用程序，才会被授权和配置为查询 LDAP 中更广泛的组织架构信息（如用户的经理 DN、部门 OU 路径）。
最小权限原则： 这是最重要的安全考量。即使所有数据都在同一个 LDAP 目录中，也要确保每个应用程序的服务账户只被授予访问其完成功能所需的最小权限。这大大降低了安全风险和信息泄露的攻击面。