安全acl 策略acl_使用ACL的ABC

安全acl 策略acl

[编者注：多年来，对访问控制列表（ACL）的记录已久。 但是，由于ACL影响了如此众多的Notes活动，因此本文解释了ACL为何“演变为”现在的形式。 通过了解其不同组件之间的交互方式，您可以利用ACL来满足安全性和应用程序开发要求。]

Notes访问控制列表（ACL）是Domino内核体系结构的高度集成的组件。 从一开始就出现在Notes中，其设计经受了时间和使用的考验。 （有关Notes架构的更多信息，请参见《 今日鸢尾》文章“ Notes：可持续的平台架构” 。）

同时，ACL已经发展为可以处理遍历整个Notes环境的大量任务。 用户有时会很难理解ACL为何能（甚至如何）正常工作。

由于我们不想重复已记录的项目，因此我们将重点介绍使用ACL设计的技巧。 每个Notes用户都可以从本文中受益。 熟悉ACL的核心结构后，您可以轻松理解和应用ACL：七个访问级别（经理，设计者，编辑者，作者，读者，存款者和无访问权限），五个用户类型（人，服务器，混合组，人组和服务器组）和数据库角色。 您可以使用ACL对话框的“基本”面板中的所有这些功能来控制用户和服务器对数据库的访问。

始终牢记这一要点：永远不会给用户授予比“ ACL”对话框的“基本”面板中分配给他们的访问权限更多的访问权限。 作为数据库管理员，您首先为每个用户选择属于某个级别的核心权限（其中一些默认情况下已启用），然后根据需要通过修改访问级别中的其他选项来增强或限制用户的级别。 用户的访问级别以及该级别内选项的状态决定了用户的数据库权限。

我们将依次浏览ACL对话框的四个面板：基础，角色，日志和高级。

ACL的“基本”面板

ACL的核心功能包含在“基本”面板中。 由于本文不尝试复制现有文档，因此我们仅简要概述对话框的结构：

图1.基本面板

在“人员，服务器，组”字段中选择“全部显示”，将为所有七个访问级别显示为给定数据库注册的每个用户。 或者，您可以请求仅管理员，仅设计师等的视图。 您可以在ACL对话框中添加，重命名和删除用户。

选择用户名时，对话框将显示用户类型和访问级别，以及适用于访问级别的详细访问增强或限制选项。 访问级别和用户类型共同指定了给定数据库的任何用户所允许的最大访问权限。

七个访问级别

ACL描述了七个访问级别（管理员，设计者，编辑者，作者，读者，存款者和无访问权限）。 了解访问级别是所有ACL工作的基础。 尽管稍后我们将讨论添加其他级别的可能性，但这七个级别可以满足您所有应用程序的需求。 依次通过一系列开关（基本上是“ on”和“ off”位）来限定访问级别，这些开关可以微调在给定级别内分配的权限。

下图显示了每个访问级别的默认权限，从每个级别开始，直到可以访问所有内容的Manager都获得了更多权限。 （每个级别都具有其下面所有级别的权限。）

图2.七个访问级别，显示默认权限

不可访问

此级别是不言自明的。 没有访问权限意味着没有访问权限。

储户和读者

存款人可以将文件插入数据库，但不能读取这些文件。 另一方面，读者可以阅读文档，但不能保存它们。 尽管它们在功能上相反，但是它们在概念上是互补的，因为它们都是专用于单个目的的。 （读者的另一项权利是他们可以运行代理。）

s

作者可以创建和编辑自己的文档。 由于可以使用多种子选择，因此ACL设计在作者级别变得越来越具有挑战性。

例如，您还可以允许作者删除文档。 但是，他们不能只删除数据库中的任何文档。 他们只能删除名称中包含“作者”字段的文档。 作者字段是其类型指定为“作者”的字段。 如果已通过ACL授予了“作者”权限，则在文档的“作者”字段中指定的用户，组或角色将被视为文档的“所有者”。 这仅适用于那些授予作者权利的人； 具有比作者更多或更少权限的任何人都不会被视为文档所有者，无论其名称是否在字段中指定。

人们有时会感到困惑，因为默认情况下Authors无法创建文档。 （他们想知道为什么要取消为作者的“创建文档”权限？）。 实际上，作者权是由于您自己创建的，并根据定义赋予您这些权利（假设您在创建文档时在文档上有一个Authors字段）而分配的，或者您的姓名出现在该文档的Authors字段中。

如果您的姓名不是文档的“作者”字段的成员，则只能阅读该文档，否则无法对其进行编辑或其他任何操作。 如果您单击该文档中的“编辑文档”按钮，则即使您创建了文档，也不会发生任何事情。

创建文档后，有什么保证可以编辑文档？ 数据库设计者必须在创建文档时在文档中放置一个Authors字段，以获取您的姓名。 或者，您的名字可以随后添加到您未创建的文档的“作者”字段中。

编者

大多数访问选项在编辑器级别可用（不会变灰）。 同样，您可以限制的是删除文档的自由。 启用删除功能后，编辑者可以删除任何文档，无论其名称是否出现在文档的“作者”字段中。

实际上，删除权限仅扩展到物理文档本身的删除。 编辑者始终可以删除文档的全部内容（从逻辑上讲，删除文档中的所有内容），但不能删除文档本身。

编辑者可以创建个人代理，创建个人文件夹/视图以及创建共享文件夹/视图。 在版本3.0中，创建共享文件夹和视图的功能仅限于Designers和更高版本。 版本4.0将此功能扩展到了编辑器，从而使邮件文件中具有编辑器访问权限的用户不仅限于创建个人文件夹和视图。 他们的文件夹和视图可以与其余共享文件夹和视图位于相同的层次结构中，并且它们不需要具有Designer访问权限（这将允许他们修改现有的表单和视图）。

除了能够运行公式和简单代理之外，还可以使编辑器能够创建LotusScript和Java代理。

设计者

在设计器级别，您可以允许用户删除文档并创建LotusScript / Java代理。 同样，删除权限仅指物理文档本身。 设计人员当然可以修改所有内容的设计，以及删除文档的内容。

对于代理，设计人员除了可以创建个人代理外，还可以创建共享代理。 如果您不允许设计人员创建LotusScript或Java代理，则限制他们不能对数据库进行任何LotusScript或Java更改。 否则，他们的权利将近完整。

管理人员

管理人员具有做所有事情的能力。 这包括向自己分配（或不授予）物理删除文档的权利。 默认情况下，删除功能受到限制，以方便检查，以确保防止意外删除。 相同的推理和对话框行为适用于设计者和编辑者。

创建代理和文件夹：何时何地

由于代理和文件夹会影响多个访问级别，因此我们将在这里专门讨论它们。 个人代理的创建在编辑器级别及更高级别起作用。 （读者只能运行代理，不能创建代理。）

个人代理可以在服务器以及本地工作站的后台运行。 顾名思义，私人代理意味着您是唯一可以运行它们的人。 例如，您可以创建一个代理来自动为数据库中的文档分类。 如果您在特定数据库的ACL中，则代理可以在该数据库上运行。

个人文件夹和视图的概念带来了Notes早期版本的变化。 在R3中，每个用户都可以创建私有视图。 专用视图位于您的桌面文件中，而不是数据库中。 因此，“创建个人文件夹/视图”选项引起了一些误会。 如果选中此框，则您创建的任何视图或文件夹都存储在服务器上的数据库内部，并占用服务器资源。 如果未选中该框，则仍可以创建私有视图。 它们像在R3中一样驻留在桌面中。 取消选中该框并不意味着用户无法创建视图，而只是保留了该视图。

LotusScript和Java代理程序的创建与个人代理程序的概念有关。 它们的使用超出了使用公式或简单动作的范围，从而增强了个人行为能力。

读写公共文件

版本4.5引入了读写公共文档的概念。 提供公共文档用于日历和日程安排，作为用户搜索其他用户邮件文件中的日历条目的一种方式。

每个日历条目都包括一个“不公开显示”选项，而不是依靠“读者”字段来限制访问。 创建日历条目并选择此选项时，具有“读取公共文档”权限的用户将看不到该条目。 （默认情况下，具有“作者”访问权限或更高权限的任何人都具有“读取公共文档”的权限。）例如，这将允许您的管理助手管理日历，创建日历项或应用日历项。

您可以为“禁止访问”和“存款人”级别设置“读取公共文档”和“写入公共文档”选项。 只能为读者和作者设置“写公共文档”。

五个用户类型

版本4引入了在ACL中指定用户类型的概念。 为名称分配用户类型时，实际上是在指定使用该名称访问数据库所需的ID类型。 提供了五种类型：人员，服务器，混合组，人员组和服务器组。 （未指定是默认值。）

人员和人员组类型

在对服务器进行身份验证时，Domino会生成一个名称列表。 此列表显示了打开数据库时所有已知的名称。 该列表将您的公用名和该服务器所属的所有组合并在一起。

当您打开数据库时，服务器可以检测何时使用自己的名称以及何时使用组名称。 如果您错误地将用户分配为“个人”组，则该用户将无法获得访问权限，因为该用户未将其作为一个组进行访问。 实际上，任何人都不能假装成群。 如果您是用户（约翰·史密斯），并且有一个也称为“约翰·史密斯”的组，那么如果您尝试使用约翰·史密斯的个人ID而不是约翰的身份访问该数据库，则将无法访问该数据库。史密斯组ID。 （请注意，这仅在您在ACL中分配了用户类型时才有效。如果John Smith在ACL中为“未指定”类型，则属于John Smith组的用户将获得访问权限）。

服务器和服务器组类型

将条目分配为服务器或服务器组等效于声明用户无法在Notes客户端中访问此数据库。 用户被限制通过服务器访问它。

对于用户类型，您可以规定用户必须从服务器ID切换到其个人用户ID。 任何数据库访问都取决于它们自己的ID。 这样可以提供更好的审核访问权限，从而确保用于打开或修改数据库（客户端或服务器）的ID行为符合预期。

其背后的原因是，相当多的管理员可能没有数据库管理员权限。 但是，管理员坐在服务器上，可以在服务器上运行客户端。 因此，如果他们能够通过带有服务器ID的用户界面打开数据库（它可能获得作为管理者的访问数据库的权限），则管理员拥有的权限比数据库管理者可能希望授予的权限更多。

当您将ACL条目指定为服务器组时，您声明组成员列表仅包含服务器。 这限制了数据库对服务器（即后端进程）的访问。 访问是通过组进行的，而不是通过服务器的名称进行的。 例如，这适用于LocalDomainServers组。

混合组类型

Domino还提供了可以同时包含服务器和客户机的混合组类型。 服务器实际上是在说：“如果这是您获得访问权限的方式，那么我不在乎您是服务器还是通过客户端软件进入。无论哪种方式，您都可以进入如果您是该组的成员。”

此选项带来重要的行为含义。 缺省情况下，所有Domino模板都带有未指定的客户端-服务器访问权限。 这赋予了用户Manager权限，以便他们可以根据需要更改该模板及其ACL。 如果将用户作为服务器组输入，则该用户将永远无法修改该模板，更不用说对其进行访问了。 结果，您不应该认为无类型的项目仅仅是缺少规范。 如上所述，模板起着至关重要的作用。 另一方面，通常应键入数据库。

另外，调试ACL问题时，请首先检查类型。 错误分配的类型会产生意想不到的效果。 如果不确定要分配哪种类型，请从默认的未指定类型开始。

由于用户类型相对较新，因此R3格式的数据库无法识别它们。 您应该将其余的R3数据库转换为R4格式。 否则，未经授权的用户可以获取数据库的物理副本，将其移至R3系统，然后使用伪造的名称（例如ACL中列出的组名称）在其中打开它。

ACL的“角色”面板

角色为ACL提供了另一个关键增强。 角色一开始可能很难理解，因为您可以将角色分配给ACL中的任何条目。 角色为将ACL中的条目分组提供了一种有效的方法。 它们仅适用于与该列表关联的特定数据库。 从某种意义上说，您是通过分配角色来创建特定于数据库的组的。

每当您想控制数据库中的访问时，请使用角色。 这包括ACL； 作者字段； 读者领域； 用于创建读取访问控制的表单（转换为“读者”字段）； 或在隐藏式公式中显示“除非此人是（或不是）此角色的成员，否则此内容不会显示”。

假设某个用户同时在销售和市场部门工作，但是您没有一个涵盖这两个功能的小组。 您可以添加两个数据库角色，例如[Sales]和[Marketing]。 同样，您现在可以将一个用户分配给[销售]，将另一个用户分配给[营销]。 您无需进入公共通讯簿，而是为每个条目创建了一个子组。

图3.角色面板

角色经常与“读者”字段相关联，因此，如果您不是合格的角色成员，则文档将完全隐藏。 或者，除非您被分配了适当的角色，否则您无权编辑文档。 这扩展了其他ACL对话框的选择，并为程序员提供了更大的灵活性。

假定您正在使用的文档未定义为组文档。 通过为用户分配[销售]角色，您可以将[销售]插入到“作者”字段中（例如），而不是特定的个人或组名。 Domino将条目标识为角色，并识别出具有该角色的任何人都有权访问文档。 您可以在任何“作者”字段，“读者”字段或“隐藏时间”公式中使用该角色名称。 您也可以将用户移入和移出[销售]角色，而无需修改任何显式命名用户的文档。

图4. Basics面板，为用户选择了角色

这也使管理更接近给定的应用程序。 管理员不必更新公共通讯簿即可将John Smith从“销售”组中删除或将其明确分配给“市场”组。 数据库管理器在数据库本身内进行这些更改。

角色背景

角色是R2中特权功能的后代（角色本身首先包含在R3中）。 添加了角色是因为R2中最多可以定义五个特权。 然后，R3添加了分配75个角色的功能。 随着客户要求更大的灵活性，角色的使用也在增长。

但是，尽管特权和角色具有共同的血统，但它们基于不同的使用模型。 特权实际上是文档中的一个选项。 特权选项确定为该特定文档分配了哪些特权。 您仍然必须在ACL中分配特权，但是特权不那么灵活，因为必须选择该选项。 事后您不能添加它。

角色的行为更像一个组，在其名称内赋予您成员资格。 您可以在定义角色后以编程方式使用角色。 您可以将它们分配给字段以产生效果，这是特权所不能实现的，因为它们在结构上是文件头中文档的一部分，而不是字段中的属性。

在Domino随附的模板中大量使用角色。 例如，预订数据库将角色分配给允许创建资源的人员类型。 如果未分配创建资源的能力，则只能创建保留。 需要角色来产生这种效果。

如果您将角色视为访问限制机制，则可能会感到困惑。 通过给某人一个角色，您只是通过不同的名称来标识他们。 那是唯一的区别。

ACL的“日志”面板

ACL日志会为您在当前会话期间所做的所有操作拍摄快照。 它提供一般审核功能，显示您已在ACL中添加，更新或删除的元素。 它不会显示具体对每个元素所做的操作。 但是，日志非常有用。 如果服务器更新了ACL，则日志记录其活动。

图5.日志面板

ACL也可以进行数字签名。 请求者的签名显示在ACL对话框的底部。 签名描述了上次更改ACL的时间以及使用哪种证书。 日志提供高级审核，而日志和签名的组合则支持更细粒度的问题解决。

目前尚无具体计划在不久的将来增强Log，但是由于Notes环境跟踪每个操作，因此可以提供更详细的ACL Log信息。

ACL的“高级”面板

虽然ACL对话框的“高级”面板被恰当地命名，但它不是高级的，因为它需要高级的用户技能，而是因为它可以优化，调整和指定“基本”面板中选择的访问级别。

图6.高级面板

管理服务器

通过在“ ACL”对话框的“高级”面板上标识管理服务器，可以使“管理进程”自动对给定的数据库进行更改。 此过程在服务器级别运行，并通过对公共通讯簿的更改使数据库保持最新状态。

例如，管理员必须经常从公共通讯簿中重命名或删除用户，因为这些用户不再在公司工作。 设置管理服务器使系统能够保持ACL为最新。 如果您指定了管理服务器，则管理进程将根据通讯簿中的更改自动执行ACL删除和重命名。

管理员可以指示管理服务器修改（或不修改）作者和读者字段，以与新名称相对应。 重命名非常重要，因为通常有成千上万的活动文档带有“作者”字段。 数据库管理员可以手动找到它们并使用修改后的用户名对其进行更新的可能性很小。 即使他们可以，他们也可能在此过程中失去理智。 但是，如果不对其进行修改，应被授予文档权限的用户将被拒之门外。

您可以将现有服务器分配为管理服务器，也可以命名新服务器。 在这里，我们添加了“ Flubar”作为管理服务器：

图7.高级面板，指定管理服务器

返回到ACL对话框的“基本”面板时，请注意Flubar会自动以具有Manager访问权限和服务器类型的形式出现在ACL中。 （您不能在此处添加组。）

图8. Basics面板，列出了管理服务器

通过为管理服务器定义Manager访问权限，复制器可确保数据库的任何副本都将接受来自服务器的更改。 您还正在将管理服务器标识为管理者，作为他们应从中对ACL进行持续更改的服务器。 这样可以确保更改向外（由于管理者级别的访问）流向外部，并减少复制冲突的机会。

跨副本实施一致的ACL

当数据库是本地数据库时，默认情况下会授予您Manager权限，因为不需要强制执行安全性。 但是，如果选择了“强制执行一致的访问控制列表”选项，则您的本地权限将永远不会超过服务器上已分配的权限。 如果已为您分配了“作者”访问权限并且启用了该选项，则您将在本地拥有“作者”访问权限，而不是“管理员”访问权限。

如果您通过在本地分配比在服务器ACL上更高的访问权限来尝试超出这些权限，则将阻止服务器数据库与本地副本之间的所有复制尝试。

这样可以保护数据库免受可能有意或无意进行设计更改并尝试将这些更改传播到服务器的用户的攻击。 例如，假设选择此选项，并且您在服务器上具有“读者”访问权限。 当然，您仍然可以制作本地副本，但是您只能在本地副本上拥有“读者”访问权限。 如果设置了此选项，则ACL限制在本地适用。

此选项适用于选定的服务器以及客户端。 服务器可能也想交换数据。 但是，两个服务器可能具有具有不同访问权限的副本的不同副本。 例如，一个公司部门可以控制其创建的数据库的访问和设计。 由于此数据库对另一个部门很有用，因此第二个部门拥有设计者对此数据库的访问权限，并有权管理其自己的ACL组。 任何一个部门都不希望管理另一个部门的内务处理。 但是，如果在ACL的“高级”面板上选择了此选项，则它们将无法相互复制。

总结起来，此复选框只是一项便捷功能，因为用户可以绕过“强制执行一致的ACL”选项。 目的不是要防止恶意攻击（以其他方式实现的有价值的目标），而是要防止善意的同事犯下致命的错误。

请记住，选中此选项不会减少服务器上的ACL权限。 反之亦然。 您要确保复制活动与服务器上分配的用户权限完全匹配。 这是ACL设计中的关键公理。 没有一个ACL设计功能会为用户分配比其在“基本”面板上分配的更多的权限（即，作为“经理”，“设计者”，“编辑器”等）。

最多Internet名称和密码访问

无论您在ACL中具有何种访问级别（即使您是给定数据库的管理器），基本的Web身份验证（名称和密码）也可能不足以安全地对您或您的用户进行身份验证。 由于很少有编程和设计任务可以直接通过Internet执行到Notes数据库，因此为什么要将这些访问级别公开给Internet？

因此，此选择默认情况下设置了“编辑者”访问权限。 即使这样，您仍可能希望进一步减少默认Internet访问。 例如，您应该将公共通讯簿的Internet访问减少为“无访问权限”。 原因是，即使用户无法闯入公共通讯簿并破坏数据，他们仍然可以使用“个人”文档信息（即用户名）对站点上的其他数据库进行轻松的字典攻击。

正如本文反复强调的那样，ACL永远不会给您比“基本”面板上分配的权限更多的权限，但是它可以限制这些权限。 例如，即使您在通过Internet访问数据库时获得了“管理员”权限，但是如果您仅在ACL的“基本”面板上具有“编辑者”访问权限，也不会获得这些权限。

但是，如果您在“基本”面板上确实具有“管理者”权限，并且默认的Internet访问权限是“读者”，则仅当您通过Internet访问数据库时，才会获得“读者”权限。 当然，当您从Notes客户端访问数据库时，您将获得Manager访问权限。

自动添加用户类型

尽管Lotus强烈建议您在ACL中使用用户类型，但是这些类型不是必需的。 直接将用户添加到ACL时，不会预先选择用户类型。 但是，当使用版本4.0或更高版本创建数据库时，将键入所有默认ACL条目，“默认”除外。 希望用户在添加单个条目时将键入单个条目。

为已经包含庞大的ACL的现有数据库输入正确的类型将非常繁琐。 为了使生活更轻松，Release 4.0在ACL对话框的“高级”面板上添加了一个按钮，使Notes可以查找未指定用户的用户类型。

例如，假设您有三个未指定的条目。 客户端搜索“公共通讯簿”，以尽可能确定条目是用户还是组。 如果推断出该条目是组，则始终将条目指定为“混合组”。 从性能的角度来看，这样做过于昂贵且笨拙，无法遍历成员列表来确定列表是否仅包含服务器。

通常，将条目定义为混合组是令人满意的。 以后始终可以将条目细化为Server或Person组。 根据最佳猜测，客户端可以有效，正确地识别服务器与人员之间的差异，因为这些是地址簿中可以分析的不同条目。

微调管理员和经理的权利

Notes通过检查“服务器”文档中特定服务器的“管理员”字段来确定您是否是管理员。 授予管理员访问权限后，将包括在数据库上创建，删除或更新全文索引之类的活动。

您希望其中某些活动仅保留给经理。 但是，管理员（以及经理）应该可以增强对当今隐藏的某些数据库对象的可见性。 这些包括个人代理和私人意见。

考虑到管理员自然希望清除属于现在已经离开公司的用户的资源。 不幸的是，该用户本可以堆积大量资源而不会留下明显的痕迹。 有多种查找私人代理的方法，但是Notes故意使访问用户的个人代理变得困难。

有趣的是，“读者”领域引起了另一场争议，尤其是对于那些认为管理者应该对所有事物都具有可见性的企业文化。 “读者”字段授予该人查看文档的权利。 如果某个人的名字没有出现在该字段中，则他们将无法查看该文档。 由于可以在每个文档和每个作者的基础上进行设置，因此即使管理员也可以被锁定。 尽管这可以通过命名和访问策略来克服，但它说明了文档访问的精妙之处。

从历史上看，此争议被视为Notes的功能，而不是bug。 明智地分配隐私权是一项固有的个人权利。 确定何时应该授予和何时应该限制隐私是公司ACL策略的关键方面。

可视化ACL的工作方式

当我们结束ACL对话框的浏览时，我们再次回顾了基础知识。 对ACL的掌握始于对七个访问级别（经理，设计者，编辑者，作者，读者，存放者和无访问权限）的深刻理解以及切换与每个级别相关联的选项的效果。

尽管这些功能是基本的，但与这些功能的机械知识相比，这种理解必须更深入。 我们需要为关卡本身吸收用户模型。 谁执行经理任务，为什么？ 谁是设计师，设计师在您的组织中从事哪些工作？ 作者和编辑之间有何不同？

例如，编辑器可以接收数据库中任意内容的自由范围。 在这种程度上，编辑者不受限制。 它们本身是否已在文档的“作者”字段中注册并不重要。 一旦他们看到数据，就可以编辑数据。 这听起来可能令人震惊，但事实并非如此。 它仅描述“成为编辑者”的含义。

相反，如果您是作者，则访问限制将自动应用。 您必须是正在查看的特定数据的作者才能编辑该数据。

因此，在为用户分配级别以及需要了解这些级别之间的相互关系时，始终要采取面向任务的立场。 考虑每个用户执行实际任务所需的访问权限。 这不仅会导致您始终进入正确的访问级别，而且还会意识到应该选择该访问级别中的哪个选项来简化任务。

期货？

用户有时会争论是否需要添加全新的访问级别。 当然，访问级别之间会发生重叠或接近冲突，尤其是随着信息产业及其专业活动的发展。

例如，赋予编辑者创建共享文件夹和视图的权利，可以将编辑者的设计特权授予编辑者。 再举一个例子，为什么要限制设计者创建LotusScript和Java代理？ 从不同的角度来看，有人建议使用“ Designer-仅视图”访问级别或“ Designer-仅表单”访问级别。

Given both the evident stability of the ACL design and the impact of an additional type on existing Notes applications (although a type will certainly be added if customers need it), the traditional response has been to add options within existing levels.

Even here, adding an option may exert a surprising (and sometimes unintended) impact on the entire structure of the Notes environment. For example, database creation usually includes both forms and views. Restricting a Designer to one or the other would add a complex and unwarranted management layer. If you argue that a particular Designer should be restricted from creating forms after a database is deployed, you may achieve this by reducing their level to Editor, while giving them the ability to create shared views and folders.

The Web's impact on the ACL

The Web is the only serious "gotcha" that has arisen since the original design of the ACL. Notes developers couldn't have foreseen both the opportunities and the limitations posed by its more primitive security model. If qualitatively different control capabilities are ever added to the ACL at this stage in its design, it will most likely be due to requirements stemming from the Internet.

This said, there doesn't appear to be anything within the Notes infrastructure itself that would require substantive change to the ACL. This is a tribute to the stability of its design. Interoperability with earlier releases of Notes would be compromised if major changes were made.

---

翻译自: https://www.ibm.com/developerworks/lotus/library/ls-Using_the_ACL/index.html

安全acl 策略acl