内容


使用并理解 IBM Lotus Notes/Domino 中的 Reader Names 字段

Comments

Reader Names 字段(也称为 Reader and Author Access 或 Reader Names)限制了对 IBM Lotus Notes/Domino 数据库中文档的访问。该安全特性为防止有害入侵提供了强力保护,并且能够使指定用户方便地访问其应该查看的文档。换句话说,它是用来授予数据访问权限的智能化、粒度化方法。本文提供了实现 Reader Names 字段的具体过程,并给出了很多技巧,以帮助避免在实现过程中出现的问题。

尽管理解概念和示例不需要具备一定水平的专业知识,但本文适用于 Notes/Domino 应用程序开发人员。

Lotus Notes/Domino 中的安全方法概述

Lotus Notes/Domino 提供了很多保护数据库数据的方法。下面列出了比较常用的方法的简要概述,以便了解 Reader Names 字段的适用场合:

  1. 物理访问。如果服务器位于一个没有任何电缆、网络连接或调制解调器访问的房间中,那么很自然,只要使该房间之外的任何人无法访问服务器中的数据,这些数据就可以实现某种程度的安全。尽管从理论上讲这是比较好的尝试,但是对于大多数数据来说通常不是很好的解决方案。
  2. 服务器安全。Lotus Domino 服务器根据 Server 文档中的访问列表来允许/拒绝用户,通常使用一个特性来拒绝离职员工的访问,离职员工可能仍拥有有效的 ID 文件和网络连接。
  3. 访问控制列表(Access Control List,ACL)。每个数据库有自己的 ACL,可以根据用户特有的名称、所属的组或 ID 级别来允许/拒绝该用户。
  4. Reader Names 字段。该特性可以根据 ACL 中所使用的同一个标准来允许/拒绝对单个文档的访问。另外,可以使用在 ACL 中定义的 [role]。
  5. 加密。该特性可以允许/拒绝对个别文档内部的个别字段进行访问。可以根据用户名称或密钥来进行加密,实际上用户名或密钥在 ID 文件之间是共享的。

尽管上述每个主题都很有趣,并且都值得关注,但是本文将重点讨论使用 Reader Names 字段来保护数据。

如果使用 Notes 客户机或 Web 浏览器的用户对数据库进行访问,那么假定他已获得上述列表中的第三种访问权。如果没有采取其他任何安全措施(例如 Reader Names 字段),那么从理论上讲该用户可以找到访问任何文档的方法。例如,通过在主视图中不包含数据来隐藏数据(尽管从开发角度看很容易实现)并不能阻止决心找到该数据的人发现它。

基于对 Lotus Notes/Domino 中各种可用的安全措施的多年研究、测试以及使用,我们创建了表 1 来帮助您确定不同场合中最适合的安全措施。

注意:术语 “模糊 (obfuscation)” 用于表示通过在公共视图中不显示数据来隐藏数据,或通过使用 hide-when 公式来隐藏表单上的数据。这并不是真正的安全,但该方法在某些情况下很有用。

表 1. 比较不同的安全措施
安全类型优点/缺点实现方式
模糊
  • 最适于向用户隐藏数据,并且即使用户设法找到了该数据,也不会发生任何财务或其他损失的情况。
  • 易于实现且易于更改。
  • 需要很少的开发经验。
  • 与 Notes 客户机相比,更加适合 Web 浏览器。
使用表单字段上或导航选项上的 Hide-when 属性。也可以使用 View Properties 框中的 hide-when 属性来隐藏视图。
Reader Names 字段
  • 最适于可能发生财务或其他损失的情况。
  • 拥有适当的访问权限的代理可以通过编程方式访问数据。
  • 可用于允许复制,从而选择性地将适当数据发送到不同的服务器/用户。
  • 尽管实现起来并不难,但是需要进行谨慎规划,以避免出现 “丢失的” 数据,即正确用户都无法访问的数据。
  • 如果某人获得了数据库的本地访问权限,那么他/她可以绕过 Reader 安全。
  • 使用 Full Access Administration 模式的管理员可以绕过 Reader 安全(这通常认为是好的做法,不过显而易见,就像本地访问一样,它可能成为缺点)。
借助表单上 Reader 类型的字段是实现该安全措施最常用的方法。
加密
  • 最适于可能发生财务或其他损失的情况。
  • 即便是本地访问也无法读取加密的数据。
  • 比较难于实现,更加难于更改。
  • 复制时,无法利用加密的文档来确定是否将数据复制到特定的服务器/人。
  • 无法在视图中访问数据,也无法通过代理(即使 ID 拥有正确的访问权限)以编程方式访问数据。
  • Proprietary Notes 客户机数据访问。Web 浏览器既不能加密数据,也不能解密数据,以下特殊情况除外,即采用 IBM Lotus Domino Web Access 模板的电子邮件。
对适当的字段启用加密,然后使用密钥或公钥进行加密,只有具有正确 ID 的 Notes 客户机用户才能访问该字段。

从表 1 可以看出使用 Reader Names 字段比其他安全形式更具优势。它们不但提供了真正的安全,而且如果具有适当的访问权限(无论是使用 Notes 客户机还是 Web 浏览器),还便于使用。严格地说,可以在视图中查看数据,并且代理能够以编程方式访问数据。最后,该方式易于实现,并且如果将来需要更改安全或业务,也易于修改。

实现 Reader Names 字段

若要使用 Reader Names 字段,通常在 Field Properties 框中将字段类型设置为 Readers(参见图 1)。这样即可。使用用户名称、组或角色(本文稍后将进行讨论)填写这些字段后,只有指定用户才能查看基于该表单的文档。

图 1. Field Properties 框
Field Properties 框
Field Properties 框

将该字段设置为多值(multi-value)很有好处,这样可以向字段添加多个名称。如果使用该表单保存一个文档,然后查看该字段属性,那么将看到 Field Flags 列出了 SUMMARY READ-ACCESS NAMES(参见图 1)。这表示可以在视图中查看数据 (SUMMARY),而且它是 Reader Names 字段 (READ-ACCESS NAMES)。使用 Reader Names 字段时常见的错误是忘记为该字段设置正确的类型,所以执行文档属性快速检查是个不错的方法,以便确认是否已进行正确设置(参见图 2)。

图 2. Document Properties 框
Document Properties 框
Document Properties 框

使用多个 Reader Names 字段

表单上可以有多个 Reader Names 字段。如果有一个以上该字段,那么要确定谁拥有访问权限,从所有 Reader Names 字段获取累积名称。另外,任何能够编辑文档的人都可以添加 Reader 列表(文档属性的最后一个附签),然后该列表被存储为一个名为 $Readers 的字段。如果添加了此类字段,那么在确定文档访问权限时,将该字段视为与其他所有 Reader Names 字段完全一样的字段。

使用 Author 字段

如果创建了 Author 字段,那么应具有 SUMMARY READ-WRITE ACCESS 属性。有趣地是,如果文档上只有 Author 字段,而没有 Reader Names 字段,那么任何人都可以查看该文档。但是,只有拥有数据库的 Author 访问权限的用户(该用户列在 Author 字段中)以及拥有 ACL 中 Editor 访问权限或更高级别访问权限的用户(无论其名称是否在 Author 字段中列出)才能编辑该文档。

但是,如果 Reader Names 字段也存在,那么 Author 字段既可以用作 Reader 列表,也可以用作 Editor 列表。假定某人拥有 ACL 中的 Editor 访问权限,但这两个字段中都没有列出他的名称,那么该用户不能查看文档,而且不能编辑文档,即便他拥有该数据库中所有文档的 Editor 访问权限。如果文档的任何 Reader 字段或 Author 字段(每种类型的字段可以有任意多个)中存在该用户名称,该用户就可以读取并编辑此文档。

也可以使用 LotusScript 以编程方式将此类字段添加到文档,这种情形下,代码如清单 1 所示:

清单 1. 示例 LotusScript 代码
Dim item as NotesItem
Set item = doc.ReplaceItemValue ( "RNames", NewValue )
Item.IsReaders = True
‘ Item.IsSummary = True

在这段代码中,RNames 是 Reader Names 字段的名称,NewValue 是字符串或字符串数组。在 Lotus Notes/Domino 的最新几个版本中,Item.IsSummary = True 是多余的;在早期的版本中,必须保证将新字段保存为 summary 数据。

如果尝试使用 @Formula 语言向文档添加新的 Reader Names 字段,则不会为其指定适当类型。而将其考虑为文本字段。检查文档属性,将看到 SUMMARY,而不是 SUMMARY READ ACCESS。但是如果该字段已经存在且对内容进行了更新,那么 @Formula 语言将保持正确的 Reader 属性。

格式化名称

Reader Names 字段和 Author 字段中的单个名称必须是纯文本格式或规范格式,不能是缩写的格式。例如 CN=Raphael Savir/OU=Boston/O=LSDevelopment 符合要求,Raphael Savir 也符合要求,但是 Raphael Savir/Boston/LSDevelopment 不符合要求。

这可能会造成混淆,因为 Reader Names 或 Author 字段以缩写格式来显示规范数据,以便于阅读。打开文档并读取此类字段中的名称时,将看到 Raphael Savir/Boston/LSDevelopment。但是如果使用文档属性查看底层数据,则会发现这些数据实际上是采用规范格式 CN=Raphael Savir/OU=Boston/O=LSDevelopment 存储的(参见图 3)。这种简化规范名称显示的能力适用于所有 Names 字段,但是不适用于纯文本字段。

图 3. 以规范格式存储的 Reader Names 字段
以规范格式存储的 Reader Names 字段
以规范格式存储的 Reader Names 字段

如果将纯文本名称填入 Reader Names 或 Author 字段,那么只要服务器和用户拥有相同级别就能够正常运行。例如,假定贵公司与其他公司合并,并且在不同级别的服务器之间复制了数据。假定其中一台服务器称为 Apps/NorthEast/LSDevelopment,另一台服务器称为 HQ/ACME。如果用户尝试访问每个副本中的数据,而且其数据位于 Reader Names字段,而这些字段使用了用户的纯文本名称,那么他只能在 Apps/NorthEast/LSDevelopment 服务器上实现成功操作,因为他仅与该服务器共享级别(其名称中的 /O= 部分)。他可以通过交叉认证来访问另一个服务器 HQ/ACME,但是 Reader Names 和 Author 字段没有授予他访问这些数据的权限。

从这里得到的教训是规范名称最安全。永远不要使用缩写名称,而且仅当您确信不会对数据进行跨公司或跨域复制时,才能使用纯文本名称。

使用角色

注意:在本文中讨论业务角色时,通常写作 “角色 (role)”。但是,谈及在每个 Notes 数据库的 ACL 中显示的特性时,将使用 [role] 以示区别。

首次使用 Reader Names 字段时,尝试将需要访问文档的每个单独用户的名称填入该字段中。但是,这不切实际,因为如果用户在公司内部更改业务角色时,必须在很多(也许是成百上千)文档中替换其名称。虽然肯定能够作到准确无误地进行替换,但是除非别无选择,否则您肯定不希望出现这种情形。在很多公司中,经常发生这种情况,因此您需要为此做好准备。

此外,Reader Names 字段可能涉及一大群人。例如,公司中的 30 位主管和经理都需要查看应用程序中的销售数据。为每个文档重复输入这些名称是对空间的浪费,当然,名称愈多,就需要愈频繁地更改名称列表。最后名称列表超出了字段的 32K SUMMARY 数据限制,虽然这是罕见情形,但您肯定有所耳闻。

更可取的做法是尽可能使用组或 [role]。从理论上讲两者都符合要求,不过实际上应尽可能使用 [role]。可通过以下方式来考虑组和 [role] 之间的区别:组是在 Domino Directory 中维护的。存在数以千计的组,如果贵公司与其他公司合并,那么这些组的名称可能发生更改,并且总有可能发生该目录被破坏或其他您一个人无法解决的问题。图 4 展示了将角色指定给用户 Rafael Savir/Boston/LSDevelopment 的 ACL。

图 4. 将 [role] 指定给用户的 ACL
将 [role] 指定给用户的 ACL
将 [role] 指定给用户的 ACL

另一方面,[role] 是特定于应用程序的。通过在 ACL 中执行一些单击操作,可以将 [role] 应用于一个组或多个组。可以取消一个组的 [role] 并其应用于其他组,必要时,也可以在 ACL 中将 [role] 应用于个别名称。曾出现过目录被破坏的危机情况,但是通过将用户名称临时添加到 ACL 并将相关 [role] 应用于用户名称,就能为用户授予对关键数据的访问权限。如果 Reader Names 字段使用组而不是 [role],则不可能实现上述操作。

若要以这种方式来使用 [role],请考虑需要访问安全文档的组。假定这些组如下所示:

  • 执行委员会 (Executive Committee)
  • 人力资源代表 (HR Reps)
  • 销售管理团队 (Sales Management Team)

可以用两种方式来解决如何为这些人授予权限的问题。一种方式是为每个组设置一个 [role],另一种方式对这三个组设置一个 [role]。这取决于具体情形,但是由于可以拥有多达 75 个 [role],所以通常可以自由选择如何创建并应用它们。基于多年来使用 [role] 进行应用程序开发的经验,我们编制了以下适用的指导方针。这些并不是绝对准则,但是在每种情形下,应用这些方针都能预防发生问题:

  1. 保持其简短。这将节省磁盘空间,而且便于您正确拼写代码中的 [role],随着时间的推移,这将成为必需的。
  2. 不要使用空格或其他不常用的标点符号。这也便于正确拼写,另外还能避免在执行全文搜索时发生问题,并且如果必须通过 URL 传递 [role],这也能避免 Web 应用程序中可能出现的问题。
  3. 可以模仿组名称,但是请注意随着时间的推移,组名称可能发生更改。
  4. 始终为开发人员和/或管理员至少保留一个 [role]。换而言之,如果有一个名为 Development 的组,不要简单地将 [role] 命名为 [Dev] 或 [Development],因为该 [role] 可能用于实际正在开发该应用程序的 Notes/Domino 开发人员。对于其他组,可以使用 [ProdDev] 之类的 [role]。

因此,本例子中将创建带有以下 [role] 的 Reader Names 字段:

  • [Execs]
  • [HR]
  • [SalesManagers]
  • [Dev]
  • [Admin]

请注意,由于添加了最后两个 [role],因此所有开发人员和管理员都可以访问这些数据。

Reader Names 字段在复制、代理和视图中的作用

现在了解了应该以何种方式设置 [role] 和 Reader Names 字段,下面将花费几分钟时间来考虑一下其他的数据访问方式。具体而言,我们发现在文档上应用 Reader Names 字段后,复制、代理和视图有时可能发生意外行为。本节内容将深入研究各种情形。

复制

如果跨服务器进行数据复制,那么惟一需要注意的事情是在 [Admin] 角色中包含所有服务器(如前所述)。可以通过 LocalDomainServers 组来实现,这样能保证域内的所有服务器可以查看数据库中所有受 Reader 限制的文档。

如果不希望将所有数据复制到所有服务器,那么需要更改此方法。大型销售应用程序就是这样的一个例子,其中每个地理区域仅维护本区域的数据以便简化性能。在这种情况下,可能使用例如 [Servers-APAC]、[Servers-EMEA] 等 [role],并按照地理区域将这些 [role] 应用于文档,然后应用于 ACL 中的个别服务器名称。仍然需要谨慎,以免不小心通过 LocalDomainServers 或其他一些组授予所有服务器访问所有数据的权限,因此制定此类模型之后应小心地进行测试。

更头疼的问题是对本地复制的影响。例如,假定 20,000 名销售代表每人有一台笔记本电脑,并且每晚对自己的数据进行本地复制。如果没有 Reader Names 字段,可能会担心发生复制/保存冲突,不过仅此而已。如果使用 Reader Names 字段,还可能担心本地副本与服务器副本不同步,例如同时在本地副本和服务器副本上编辑文档,而在服务器上的编辑包含从 Reader Names 字段删除该用户名称。

换句话说,如果在进行编辑时两个副本中有一个不能访问所讨论的文档,就无法解决复制冲突问题。结果是服务器、本地副本各自保留自己的编辑,而二者都没有意识到它们已经不同步。对于该问题,没有简单的解决方案,因此在设计整体架构和工作流时应特别注意这一点。

代理

Reader 安全对代理的影响其实很简单。如果代理是由用户触发的,例如通过单击按钮,那么代理在运行时就好像是用户在执行操作。如果该用户拥有文档的访问权限,则代理也拥有文档的访问权限。如果用户没有所讨论文档的访问权限,那么在代理工作时将显示错误(例如,“Entry not found in index” 或 “Unauthorized to attempt that operation”)。

如果是按照计划运行的代理,则代理在运行时就好像是代理的签名人,除非填写了代理的“Run on behalf of”字段,填写该字段后,代理在运行时就好像是用户(参见图 5)。

图 5. Agent Properties 框
Agent Properties 框
Agent Properties 框

视图

出于功能性和性能考虑,对用户影响最大的方面可能在于视图。

如果对视图进行了分类,那么用户可能会看到有点古怪的类别,但无法查看该类别内的文档。这对于用户来说是很常见的问题。一种解决方案是使用 Show single category 选项(参见图 6)来创建嵌入视图,并且让用户从其拥有访问权限的类别列表中选择要显示的类别。这样用户不会看到其他类别,所以不会出现空视图。Web 浏览器可以不着痕迹地实现该功能,并且该功能也可以用于 Notes 客户机。另一种解决方案是重新考虑划分类别,以便用户不会看到空类别。

图 6. Embedded View 下的 Show single category
Embedded View 下的 Show single category
Embedded View 下的 Show single category

与其他方式相比,Reader Names 字段会使视图执行速度慢很多,因为服务器必须检查每个文档以确保其可以被查看。必须对每个用户执行该操作,因此如果有很多并发用户以及很多带有 Reader Names 字段的文档,那么服务器/应用程序的速度可能显著减慢。当很多用户拥有对视图中一小部分文档的访问权限时(销售或 HR 应用程序中可能出现这种情况),尤其如此。最佳解决方案仍然是使用 Show single category 来创建嵌入视图。通常这比打开文档上完全没有 Reader 限制的原始视图要快。

另外,可以对视图进行分类,而且开始时折叠视图。这将提高速度,尽管可能会导致前面讨论过的问题;即用户可以看到类别,但是在该类别中看不到任何文档。在某些情况下,将数据分解到多个视图中并将用户引导到正确视图很有意义。例如,如果用户单击导航中的 Regional Sales,而您可能有一个检查 @UserRoles 的公式,就会打开适当的视图 Sales-US、Sales-APAC 等。

有关视图性能的更多信息,请参阅 developerWorks Lotus 文章 “Lotus Notes/Domino 7 应用程序性能:第 2 部分:优化数据库视图”。

故障检修

本节将解决在用户组和讨论会中频繁出现的两个故障检修主题。

多值 Reader Names 字段

如果在表单中将 Reader Names 字段设置为单个值,后来又决定添加其他值,那么可以通过编写添加这些附加值的代理来实现上述操作。到目前为止没有出现问题,但是当用户编辑并保存文档时,表单仍会将该字段作为单值处理,而不是多值,因此可能会使 Reader Names 字段变得毫无用处。

例如,假定将 [HR] 角色添加到 Reader Names 字段。一年以后,您意识到将 [ProdDev] 角色也放入该字段很有意义。您编写代理来添加该值,并对拥有 [ProdDev] 角色但不拥有 [HR] 角色的用户进行了测试,一切看起来很正常。但是如果忘记更改表单上的字段属性,那么下一次有人使用该表单保存文档时,Reader 值将类似 “[HR], [ProdDev]”,而不是 “[HR]”“[ProdDev]”。换句话说,现在 Reader Names 字段将查找名为 [HR], [ProdDev] 的人或组(其中逗号只是名称的一部分,而不是值分隔符),因此没有人或组拥有该文档的访问权限。

避免此类问题的简单方法是始终将 Reader Names/Author 字段设置为多值。

恢复隐藏的文档

如果在文档上使用 Reader Names 字段,而且不经意地使一些文档对于所有用户来说都无法访问(例如前面所述,因插入多个条目,而产生一个无效的条目),则可以使用 Full Access Administration 模式(参见图 7)来打开数据库并恢复那些文档。事前创建一个应用了适当的 Reader 值的代理,然后处于 Full Access Administration 模式中时,可以触发该代理来修复数据。

在大多数组织中,只有一组经过挑选的管理员才能使用 Full Access Administration 模式,因此用户可能需要排队等候处理完成,但是起码可能实现不必操作服务器而是使用本地 Notes 客户机来绕过 Reader 安全。

图 7. Full Access Administration 选项
Full Access Administration 选项

结束语

希望本文有助于尽可能轻松高效地计划和实现 Reader Names 字段。它是个卓越的特性,也是个很好的安全措施,并且只要提前配置好各方面内容,就很容易实现和维护。只需要记住关键的一点:提前配置各方面内容。如果这样做了,则您在使用 Lotus Notes/Domino 中的强大特性时,将获得完美体验。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus
ArticleID=224820
ArticleTitle=使用并理解 IBM Lotus Notes/Domino 中的 Reader Names 字段
publish-date=05222007