搜索

2.3. 执行站点问卷调查

download PDF
站点调查是发现并标记目录中内容的正式方法。执行站点调查的时间预算低下,因为准备是目录架构的关键。站点调查由若干任务组成:
  • 识别使用目录的应用程序。
    确定跨企业部署的目录应用程序及其数据需求。
  • 识别数据源。
    调查企业并识别数据来源,如 Active Directory、其他 LDAP 服务器、PBX 系统、人工资源数据库和电子邮件系统。
  • 对目录需要包含的数据进行定性。
    确定目录中应包括哪些对象(例如,人员或组)以及这些对象在目录中要维护哪些属性(如用户名和密码)。
  • 确定要提供的服务级别。
    决定目录数据可用如何成为客户端应用程序,并相应地设计架构。要如何复制数据,以及将链策略配置为连接存储在远程服务器上的数据,从而如何影响复制数据。
    有关复制的信息,请参阅 第 7 章 设计复制过程,有关链的信息,请参阅 第 6.1 节 “拓扑概述”
  • 识别数据供应商.
    数据供应商包含目录数据的主源。此数据可能会镜像到其他服务器,以进行负载平衡和恢复。对于每个数据,确定其数据的来源。
  • 确定数据所有权。
    对于每个数据,确定负责确保数据最新状态的人员。
  • 确定数据访问。
    如果数据从其他来源导入,为批量导入和增量更新制订相关策略。作为此策略的一部分,尝试在单个位置管理数据,并且限制可以更改数据的应用程序数量。另外,限制写入任何给定数据的人员数量。较小的组可确保数据完整性,同时减少管理开销。
  • 记录网站调查。
由于目录可能会影响到多个机构,组成一个目录部署团队可能会是一个好的选择。这个团队可以包括来自受影响团队的人员,以执行站点调查。
公司通常都会拥有人工资源部门、会计部门或客户收帐部门、制造企业、销售组织和开发组织。包括这些机构中的代表可帮助调查流程。此外,直接涉及所有受影响的机构可以帮助构建接受从本地数据存储迁移到中央目录的接受操作。

2.3.1. 确定使用目录的应用程序

通常,访问目录的应用程序以及这些应用程序的数据需求会驱动对目录内容的规划。许多常见应用程序都使用目录:
  • 目录浏览器应用程序,如在线笔记本电脑。确定用户需要哪些信息(如电子邮件地址、电话号码和员工名称),并将其包含在目录中。
  • 电子邮件应用程序,特别是电子邮件服务器.所有电子邮件服务器都需要在目录中提供电子邮件地址、用户名和一些路由信息。其他系统可能还需要更高级的信息,如存储用户的邮箱数据、假期通知信息和协议信息(例如,IMAP 和 POP)等在磁盘中的位置。
  • 启用目录的人工资源应用程序.这需要更多个人信息,如政府身份标识号、家地址、家电话号码、出生日期、短文和职务。
  • Microsoft Active Directory.通过 Windows User Sync,Windows 目录服务可以集成以与 Directory Server 配合使用。这两个目录都可以存储用户信息(用户名和密码、电子邮件地址、电话号码)和组信息(成员)。在现有 Windows 服务器部署后(反之亦然),使目录服务器数据可以平稳同步。
在检查要使用 目录的应用程序时,请查看每个应用所使用的信息类型。下表提供了应用程序示例以及每个应用程序所使用的信息:
表 2.1. 应用程序数据需要示例
Application(应用程序) 数据类别 data
电话 人员 名称、电子邮件地址、电话号码、用户 ID、密码、部门号码、经理、邮件停止.
Web 服务器 人员、组 用户 ID、密码、组名称、组成员、组所有者。
日历服务器 人员、会议室 名称、用户 ID、已用数字、会议室名称。
识别每个应用程序使用的应用程序和信息后,显然有些类型的数据会被多个应用程序使用。在数据规划阶段执行这种练习有助于避免目录中的数据冗余问题,并更清楚地显示数据与目录相关的应用程序需要的内容。
关于目录中维护的数据类型以及迁移到目录中的信息会受到这些因素影响的最终决定:
  • 各种传统应用程序和用户所需的数据
  • 传统应用程序与 LDAP 目录通信的功能

2.3.2. 识别数据源

要识别需要包括在目录中的所有数据,请执行对现有数据存储的调查。该调查应包括以下内容:
  • 识别提供信息的机构。
    找到管理企业信息的所有组织。通常,这包括信息服务、人类资源、注册和会计部门。
  • 识别作为信息源的工具和流程。
    某些信息的常见来源包括网络操作系统(Windows、Novell Netware、UNIX NIS)、电子邮件系统、安全系统、PBX(交换)系统和人类资源应用程序。
  • 确定对数据进行中央化如何影响数据管理。
    集中式数据管理可能需要新的工具和新流程。对于一些机构,中央化可能需要增加员工,而对于其他一些机构,则可能会减少员工。
在调查期间,请考虑开发一个列表来标识企业中的所有信息源,类似于 表 2.2 “ 信息源示例”
表 2.2.  信息源示例
数据源 数据类别 data
人员资源数据库 人员 名称、地址、电话号码、部门号码、经理。
电子邮件系统 人员、组 名称、电子邮件地址、用户 ID、密码、电子邮件首选项.
设施系统 设施 构建名称、指纹、现有数字、访问代码。

2.3.3. 为目录数据定性

目录中标识的所有数据都可以根据以下通用点进行特征:
  • 格式
  • 大小
  • 各种应用程序中发生次数
  • 数据所有者
  • 与其它目录数据的关系
研究目录中每个要包含的数据,以确定它与另一部分数据共享哪些特征。这有助于在 schema 设计阶段节省时间,详情请参阅 第 3 章 设计目录架构
最好使用表,类似于 表 2.3 “目录数据特征”,它特征是目录数据。
表 2.3. 目录数据特征
data 格式 大小 所有者 相关
员工名称 文本字符串 128 个字符 人员资源 用户条目
传真号 电话号码 14 个数字 设施 用户条目
电子邮件地址 文本 多个字符 IS 部门 用户条目

2.3.4. 确定的服务质量等级

提供的服务级别取决于依赖支持目录的应用程序的用户的预期。要确定每个应用程序所需的服务级别,首先确定如何使用应用程序。
随着目录的演进,可能需要支持从生产到关键任务的各种服务级别。部署 目录后,可能会难以提高服务质量,因此请确保初始设计能够满足未来需求。
例如,如果必须消除总故障风险,请使用多层次配置,同一数据存在多个供应商。

2.3.5. 考虑数据供应商

数据供应商 是供应商数据源的服务器。任何相同的信息都存储在多个位置,都可能会降级数据完整性。数据供应商确保存储在多个位置的所有信息都是一致的且准确。有几个需要数据供应商的场景:
  • 在目录服务器间复制
  • Directory 服务器和 Active Directory 之间的同步
  • 用于访问目录服务器数据的独立客户端应用程序
如果有应用程序与目录间接通信,请考虑数据的供应商源。保留更改数据的流程,以及可以更改数据的位置,尽可能简单。在决定单一站点管理数据后,使用相同的网站来管理该数据的所有数据。如果数据库在企业之间丢失同步,则单个站点简化了故障排除。
实现数据提供的方法有多种:
  • 管理目录以及不使用目录的所有应用程序中的数据。
    维护多个数据供应商不需要自定义脚本在目录和其他应用程序中移动数据。但是,如果数据在一个位置更改,则人员必须在所有其他站点上进行更改。在目录中维护供应商数据以及所有不使用目录的应用程序都可能会导致数据在整个企业中无同步(这是应该阻止的目录是什么)。
  • 在目录以外的一些应用程序中管理数据,然后编写脚本、程序或网关来将该数据导入到目录中。
    在非目录应用程序中管理数据时,如果两个应用程序已经用于管理数据,并且目录将仅用于查找(例如,在线企业电话书)。
数据的主副本是如何被维护的,这取决于特定目录的需求。但是,无论数据供应商如何维护,都保持简单且一致。例如,不要尝试管理多个站点中的数据,然后在竞争应用程序之间自动交换数据。这样做会导致"上次更改优先"情况,并增加了管理开销。
例如,该目录将管理员工的主页电话号码。LDAP 目录和人工资源数据库都存储此信息。人工资源应用程序是启用了 LDAP 的,因此应用程序可以编写它,自动将数据从 LDAP 目录传输到人工资源数据库,反之亦然。
试图管理该员工在 LDAP 目录和人力资源数据中的修改,但这意味着,在其他数据库中,电话号更改的最后一处将会覆盖信息。只要写入数据的最后应用程序都有正确的信息,这只可以接受。
如果该信息过期,或许因为从备份重新加载了人工资源数据,那么将删除 LDAP 目录中的正确电话号码。
通过多supplier 复制,目录服务器可以包含供应商信息源有关多个服务器的信息。多个供应商保持 changelogs,可以更加安全地解决冲突。有限数量的目录服务器被视为供应商,它们可以接受更改;然后,它们会将数据复制到复制服务器或消费者服务器。[1] 如果服务器脱机,则有超过数据供应商服务器提供安全故障转移。有关复制和多层复制的更多信息,请参阅 第 7 章 设计复制过程
同步允许 Directory 服务器用户、组、属性和密码与 Microsoft Active Directory 用户、组、属性和密码集成。使用两个目录服务,决定他们是否处理相同的信息,这些信息量将共享,哪些服务将是该信息的数据供应商。最好的课程是选择单一应用程序来管理数据,并允许同步进程在其他服务上添加、更新或删除条目。

2.3.6. 确定数据所有权

数据所有权指的是负责确保数据最新状态的人员或组织。在数据设计阶段,决定谁可以向目录写入数据。以下是决定数据所有权的一些常见策略:
  • 允许任何人对该目录的只读访问,但一组小的目录内容管理器除外。
  • 允许个人用户自己管理某些战略性信息子集。
    此信息子集可能包括他们的密码、描述自身及其在机构内的角色信息、其自主权许可证的数量以及联系信息,如电话号码或办公室号码。
  • 允许个人经理写入该人员信息的一些战略性子集,如联系信息或职位。
  • 允许机构管理员创建和管理该组织的条目。
    这种方法允许组织管理员作为目录内容管理器运行。
  • 创建赋予用户读取或写入访问权限组的角色。
    例如,可以为人工资源、财务或核算创建角色。允许这些角色具有读取访问权限、写入访问权限或这两个角色对组需要的数据具有读访问权限。这可包括工资信息、政府标识号以及主页电话号码和地址。
    有关角色和分组条目的更多信息,请参阅 第 4.3 节 “分组目录条目”
可能有多个需要对相同信息进行写入访问权限的个人。例如,信息系统(IS)或目录管理组可能需要对员工密码进行写入访问权限。这可能要求员工本身具有他们自己的密码的写权限。虽然通常,多个人对同一信息具有写入权限,但尽量使该组保持小且易于识别。使组 small 有助于确保数据完整性。
有关为目录设置访问控制的详情请参考 第 9 章 设计安全目录

2.3.7. 确定数据访问

确定数据所有权后,决定谁可以读取每个数据。例如,员工的主页电话号码可以存储在 目录中。这些数据对于许多组织(包括员工的经理和人力资源)非常有用。员工应该能够读取该信息以进行验证。但是,家联系信息可被视为敏感性,因此企业可能不能广泛使用。
对于目录中存储的每个信息,决定以下内容:
  • 数据是否匿名读取?
    LDAP 协议支持匿名访问,并允许轻松查找常见信息,如办公室站点、电子邮件地址和业务电话号码。但是,匿名访问可让任何人访问目录访问通用信息。因此,请小心使用匿名访问。
  • 数据是否可以跨企业广泛读取?
    可以设置访问控制,使客户端必须登录(或绑定到)目录才能读取特定信息。与匿名访问不同,这种形式的访问控制可确保只有机构的成员可以查看目录信息。它还捕获目录访问日志中的登录信息,因此有记录谁访问信息。
    有关访问控制的更多信息,请参阅 第 9.7 节 “设计访问控制”
  • 是否存在一组需要读取数据的人员或应用程序的可识别组?
    对数据具有写入权限的用户通常需要读访问权限(具有密码的写入访问权限除外)。还可能有特定于特定组织或项目组的数据。识别这些访问权限需要有助于确定哪些组、角色和访问控制。
    有关组和主机的详情,请参考 第 4 章 设计目录树。有关访问控制的详情请参考 第 9.7 节 “设计访问控制”
对每个目录数据进行这些决策会定义目录的安全策略。这些决策取决于站点的性质以及已在站点所提供的各种安全类型。例如,允许防火墙或无法直接访问互联网意味着,如果目录直接放置在互联网上,就很难支持匿名访问。此外,某些信息可能只需要访问控制和验证措施来限制访问被正确;可能需要在数据库中加密其他敏感信息,因为它存储在数据库中。
在很多国家/地区,数据保护法律规定企业必须如何维护个人信息,并限制谁有权访问个人信息。例如,法律可能会禁止匿名地址和电话号码访问,或者可能要求用户能够查看和纠正代表它们的条目中的信息。请务必与机构的法律部门进行检查,以确保目录部署遵循企业运营的国家/地区的必要法律。
第 9 章 设计安全目录 中详细介绍创建安全策略及其实现方式。


[1] 在复制中,使用者 服务器或副本 服务器是一个从供应商服务器或 hub 服务器接收更新的服务器。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.