使用细化权限的最佳实践

1、.wd.wd.wd.使用细化权限的最正确实践本文档按“原样提供。本文表达的信息和观点包括 URL 和其他 Internet 网站引用随时可能发生更改，恕不另行通知。使用本文档的风险由您自行承担。此处所述的某些例如仅供演示之用，纯属虚构。无意进展真实的关联或联系，请勿据此妄加推测。本文并不为您提供对任何 Microsoft 产品中任何知识产权的任何法律权利。您可以出于内部参考目的复制和使用本文档。 2010 Microsoft Corporation。保存所有权利。使用细化权限的最正确实践Sean Livingston，SharePoint 产品组的产品经理发布时间：2010 年 9 月摘要：本

2、白皮书介绍了细化权限 (FGP) 的最正确实践，以及如何在使用 SharePoint产品和技术或 Microsoft SharePoint 2010 产品时在您的组织内部使用它们。目录 TOC o 1-3 h z u HYPERLINK l _Toc286743793 目录 PAGEREF _Toc286743793 h 3 HYPERLINK l _Toc286743794 使用细化权限概述 PAGEREF _Toc286743794 h 4 HYPERLINK l _Toc286743795 SharePoint 权限系统概述 PAGEREF _Toc286743795 h 5 HYPER

3、LINK l _Toc286743796 权限级别 PAGEREF _Toc286743796 h 5 HYPERLINK l _Toc286743797 SharePoint 组 PAGEREF _Toc286743797 h 5 HYPERLINK l _Toc286743798 作用域 PAGEREF _Toc286743798 h 5 HYPERLINK l _Toc286743799 安全对象 PAGEREF _Toc286743799 h 6 HYPERLINK l _Toc286743800 继承 PAGEREF _Toc286743800 h 6 HYPERLINK l _To

4、c286743801 受限访问 PAGEREF _Toc286743801 h 7 HYPERLINK l _Toc286743802 二进制 ACL PAGEREF _Toc286743802 h 8 HYPERLINK l _Toc286743803 防止常见 FGP 限制问题的最正确实践 PAGEREF _Toc286743803 h 8 HYPERLINK l _Toc286743804 列表中的作用域过多 PAGEREF _Toc286743804 h 8 HYPERLINK l _Toc286743805 作用域中的成员过多 PAGEREF _Toc286743805 h 9 HY

5、PERLINK l _Toc286743806 很深的作用域层次构造 PAGEREF _Toc286743806 h 9 HYPERLINK l _Toc286743807 为常见 FGP 性能问题建议的解决方案 PAGEREF _Toc286743807 h 10 HYPERLINK l _Toc286743808 解决方案 1：移除 FGP 并仅在 Web 级别使用安全强制 PAGEREF _Toc286743808 h 10 HYPERLINK l _Toc286743809 环境安全清理 PAGEREF _Toc286743809 h 10 HYPERLINK l _Toc286743

6、810 环境安全体系构造重新设计 PAGEREF _Toc286743810 h 11 HYPERLINK l _Toc286743811 解决方案 2：根据分层构造更改使用细化权限 PAGEREF _Toc286743811 h 12 HYPERLINK l _Toc286743812 环境层次构造重新设计 PAGEREF _Toc286743812 h 12 HYPERLINK l _Toc286743813 解决方案 3：根据范围构造更改使用细化权限仅仅 2010 PAGEREF _Toc286743813 h 13 HYPERLINK l _Toc286743814 动态安全更改代码重

7、新设计 PAGEREF _Toc286743814 h 13 HYPERLINK l _Toc286743815 环境体系构造例如 PAGEREF _Toc286743815 h 14 HYPERLINK l _Toc286743816 环境概述 PAGEREF _Toc286743816 h 15 HYPERLINK l _Toc286743817 工作流设计 PAGEREF _Toc286743817 h 16 HYPERLINK l _Toc286743818 细化权限问题 PAGEREF _Toc286743818 h 16 HYPERLINK l _Toc286743819 FGP

8、问题的解决方法 PAGEREF _Toc286743819 h 17 HYPERLINK l _Toc286743820 摘要 PAGEREF _Toc286743820 h 19使用细化权限概述本文描述了 SharePoint 2010 产品Microsoft SharePoint Server 2010 和 Microsoft SharePoint Foundation 2010与 SharePoint Products 和技术Office SharePoint Server 2007 和 Windows SharePoint Services 3.0 版的细化权限 (FGP) 的使用；与

9、 FGP 相关的性能问题；配置包含 FGP 的解决方案的最正确实践。注意：建议您只对需要 FGP 的业务案例使用 FGP。就操作监视和性能而言，FGP 的成本很高。可通过采取以下措施来防止使用 FGP：尽可能少地中断权限继承。使用基于目录成员资格的组分配权限。注意：建议您不使用 SharePoint 组向网站分配权限，因为在使用 SharePoint 组分配权限时，将对索引进展完全爬网。相反，建议您使用 Domain 组。在可能的最高级别分配权限。作为此策略的一局部，请考虑以下技术：将需要细化权限的文档隔离到为支持每组权限而定义的文档库中，并将文档库保存到隔离的网站集或网站中。有关分层更改的其

10、他信息，请参阅 HYPERLINK l _Solution_2:_Use 解决方案 2：根据分层构造更改使用细化权限。注意：在本文档中，术语Web和网站等同于SPWeb对象，而网站集等同于SPSite对象。使用不同的文档发布级别来控制访问。在发布文档之前，可以为只能批准文档库中的工程的用户设置高级权限和版本控制设置。对于非文档库列表，请使用 ReadSecurity 和 WriteSecurity 权限级别。在创立列表时，所有者可将工程级权限设置为“读取访问权限或“创立和编辑访问权限。如果您必须使用细化权限，请考虑以下建议的实践：确保文档库中的层次构造的同一级别上没有过多的工程，因为在视图中处

11、理工程所需的时间会增加。使用事件处理程序控制编辑权限。可以包含一个使用SPEventReceiverType.ItemUpdating和SPEventReceiverType.ItemUpdated方法注册事件的事件处理程序，然后使用代码来控制是否应允许更新。这样做很有用，因为您可基于列表或工程的任意元数据做出安全性决策，而不会影响视图呈现性能。有关事件处理程序的其他信息，请参阅 HYPERLINK l _Resolution_of_FGP FGP 问题的解决方法。使用AddToCurrentScopeOnly方法可在 SharePoint 组中分配“受限访问成员资格。此原那么的关键要素在于，

12、重新设计体系构造以使作用域成员资格不会导致在父文档库和 Web 中重新计算 ACL。有关作用域更改的其他信息，请参阅 HYPERLINK l _Solution_3:_Use 解决方案 3：根据作用域构造更改使用细化权限仅 2010。SharePoint 权限系统概述本节描述了 SharePoint 权限作用域系统。有关规划网站安全性的详细信息，请参阅： HYPERLINK :/technet.microsoft /zh-cn/library/cc262778.aspx 规划网站权限 (SharePoint Server 2010) ( :/technet.microsoft /zh-cn/l

13、ibrary/cc262778.aspx) HYPERLINK :/technet.microsoft /zh-cn/library/cc287752.aspx 规划网站权限 (SharePoint Foundation 2010) ( :/technet.microsoft /zh-cn/library/cc287752.aspx) HYPERLINK :/technet.microsoft /zh-cn/library/cc262778(office.12).aspx 规划网站安全性 (Office SharePoint Server) ( :/technet.microsoft /zh-

14、cn/library/cc262778(office.12).aspx)规划网站安全性 (Windows SharePoint Services) HYPERLINK :/technet.microsoft /zh-cn/library/cc287752(office.12).aspx :/technet.microsoft /zh-cn/library/cc287752(office.12).aspx ( :/technet.microsoft /zh-cn/library/cc287752(office.12).aspx)权限级别权限级别包含一组单个权限，例如，“查看工程或“创立通知。用户

15、可预定义或创立权限级别。甚至可在预定义的权限级别中修改权限集。SharePoint 组SharePoint 组是一个可保存其他安全主体的网站集范围的对象，包括 Windows 用户帐户、非 Windows 用户例如，基于表单的帐户和 Active Directory 组。作用域作用域是未定义单独的安全边界的安全对象及其任意子级的安全边界。作用域包含一个访问控制列表 (ACL)，但与 NTFS ACL 不同，作用域可包含特定于 SharePoint 的安全主体。作用域的 ACL 成员可包含 Windows 用户，非 Windows 用户例如，SharePoint 产品和技术中基于表单的帐户或 S

16、harePoint 2010 产品中基于声明的帐户、Active Directory 组或 SharePoint 组。可在父作用域内创立的作用域的最大数目不存在。但对于 SharePoint 产品和技术，在创立完 1,000 个作用域后，将使用一个代码路径，此路径需要 Microsoft SQL Server 往返以便在呈现视图之前分析这些作用域。当作用域数小于或等于 1,000 时，只需一次往返即可。在 SharePoint 2010 产品中，在切换到其他算法之前所返回的作用域数的限制将基于查询限制，其默认值为 5,000；但即使该值是默认值，它也是一个很大的值，足以显著降低性能。在 Sha

17、rePoint 2010 产品中，有一个名为SPRoleAssignmentCollection.AddToCurrentScopeOnly的新方法，可通过此方法进展角色分配。有关角色分配的其他信息，请参阅 HYPERLINK :/msdn.microsoft /zh-cn/library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx SPRoleAssignmentCollection.AddToCurrentScopeOnly该链接可能指向英文页面( :/msdn.microsoft /

18、zh-cn/library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx)。安全对象安全对象是一个可为其分配 ACL 的对象。在 SharePoint 产品和技术中，可使用ISecurableObject接口，而在 SharePoint 2010 产品中，应使用SPSecurableObject类。有关安全对象的其他信息，请参阅 HYPERLINK :/msdn.microsoft /zh-cn/library/microsoft.sharepoint.isecurableobject.as

19、px ISecurableObject 接口该链接可能指向英文页面( :/msdn.microsoft /zh-cn/library/microsoft.sharepoint.isecurableobject.aspx或 HYPERLINK :/msdn.microsoft /zh-cn/library/microsoft.sharepoint.spsecurableobject.aspx SPSecurableObject 类该链接可能指向英文页面( :/msdn.microsoft /zh-cn/library/microsoft.sharepoint.spsecurableobject.

20、aspx)。继承如果一个安全对象不具有唯一作用域，那么该对象将继承其父级的作用域。当某个对象从其父级继承时，不会为该对象创立作用域。相反，只要进展安全检查，它就会针对父对象进展验证。在最简单的环境中，此作用域位于包含该工程的网站集的根网站中。在更改某个工程或容器使其具有唯一成员资格时，其继承将中断，这意味着将为该工程默认情况下，将为继承其权限作用域的任意子级创立新作用域。以以下图演示了文档库的对象层次构造，其中，所有对象除一个对象外将继承其父级的作用域。每个编号的金色六边形均表示一个权限作用域。除非容器内的所有子对象都有自己的唯一权限作用域，否那么它们都将从该父作用域继承。受限访问在向一个具有

21、唯一权限的工程的作用域中添加某个安全主体时，此安全主体将与受限访问权限级别一起添加到在层次构造中位于该工程上方的每个唯一权限作用域，直至找到具有唯一权限的父 Web。之所以向具有受限访问的作用域中添加用户，是为了允许对在层次构造中位于具有唯一权限的工程上方的对象进展足够访问，以便在用户尝试导航到该工程时能呈现对象模型 (OM)、母版页和导航。没有父作用域中的受限访问权限，用户将无法成功导航到或翻开具有唯一权限的工程。以以下图演示了作用域的分层深度将如何影响向父作用域添加受限访问用户所需的工作量。工程上方的唯一作用域直至包含具有唯一权限的 Web的数目越多，必须进展的添加的次数就越多。该图演示了

22、具有在每个级别从 Web 到单个工程上定义的唯一作用域的物理构造的简化表示。如上图所示，每个具有不同编号的金色六边形均代表一个唯一权限作用域，除非容器内的所有子对象具有自己的唯一权限作用域，否那么它们将从该作用域继承。红色箭头显示受限访问升级链。此图还包括一组唯一作用域和必须在每个父作用域由作业域内单独的框表示上进展的受限访问成员资格添加。只要将安全主体添加到具有唯一权限的对象作用域位于具有唯一权限的 Web 下方中，就无需额外编程即可添加唯一作用域。在将具有受限访问权限级别的安全主体添加到父作用域中时，无需进展任何检查即可查看安全主体是否已在父作用域中。再次将可访问父作用域的安全主体与受限访

23、问权限一起添加，而不管其父作用域上的现有权限如何。当从父作用域上的受限访问权限级别中移除一个安全主体时，将从受限访问权限级别中移除该安全主体在每个子作用域内对应的所有实例，而不管该安全主体在子作用域上是具有受限访问权限还是具有一组更大的权限。二进制 ACL二进制 ACL 执行用户令牌快速比照，以确定用户是否应具有对作用域覆盖的对象的访问权。只要作用域的成员资格发生更改，就会计算二进制 ACL包括在添加新的受限访问成员时。随着成员资格的提升，计算二进制 ACL 所需的时间也会增加，并将阻止访问对象，直到可以重新计算 ACL。虽然除了 SQL Server 中设定的最大图像列大小之外，二进制 AC

24、L 没有明确的大小限制，但有些服务无法承受大于 64KB 的 ACL。在此情况下，二进制 ACL 中安全主体的数目也许能变得非常大，但出于性能和互操作性方面的考虑，还是应限制该数目。有关 SQL Server 中图像列大小限制的信息，请参阅 HYPERLINK :/msdn.microsoft /zh-cn/library/ms187993.aspx ntext、text 和 image (Transact-SQL) ( :/msdn.microsoft /zh-cn/library/ms187993.aspx)。防止常见 FGP 限制问题的最正确实践在使用细化权限时，很容易意外碰到阻止解析权

25、限的限制。列表中的作用域过多每个列表或文档库均存在 50,000 个作用域的内置限制。在到达 50,000 个作用域后，将制止向给定列表或文档库内添加新的作用域。在 SharePoint 2010 产品中，可使用 Windows PowerShell 脚本修改内置作用域限制。将内置作用域限制修改为少于 50,000 个作用域确保您满足以下最低要求：请参阅 HYPERLINK :/technet.microsoft /zh-cn/library/ff607596.aspx Add-SPShellAdmin ( :/technet.microsoft /zh-cn/library/ff607596

26、.aspx)。在“开场菜单上单击“所有程序。单击“Microsoft SharePoint 2010 产品。单击“SharePoint 2010 Management Shell。在 Windows PowerShell 命令提示符处，键入以下语法：$webapp = Get-SPWebApplication HYPERLINK :/serverName :/serverName$webapp.MaxUniquePermScopesPerList$webapp.MaxUniquePermScopesPerList = 但通常来说，如果同一个层次级别上存在多个作用域，那么有效限制会比 50,00

27、0 小得多。这是因为，必须针对位于该层次级别下的工程上方的所有作用域检查这些工程的显示情况。此限制会导致特定查询中允许的有效作用域数降至 1,000 到 2,000。最正确实践：仅在父对象上设置唯一作用域，例如文件夹。不要在具有多个作用域的对象下方创立包含多个具有唯一权限的对象的系统。如果您的企业要求文档或文档库中包含 50,000 个以上具有唯一权限的工程，那么您必须将一些工程移动到不同的列表或文档库。作用域中的成员过多如上所述，只要作用域的成员资格发生更改包括在添加新的受限访问成员时，就会计算二进制 ACL。随着作用域成员资格数的增多，重新计算二进制 ACL 所需的时间也会增多。但是，由于

28、在子对象的唯一作用域上添加用户会导致使用新的受限访问成员来更新其父作用域，因此这个问题将变得更为严重，即使这样做最终不会导致父作用域成员资格发生任何更改。假设发生此情况，还必须重新计算父作用域的二进制 ACL，但这样做会花费更多的处理时间，即使它最终会生成同一 ACL 也是如此。最正确实践：依赖于组成员资格而非作用域中的单个用户成员资格。例如，如果可使用一个组来代替 1,000 个用户，那么对于将使用该单一组的受限访问权限而不是具有受限访问权限的所有 1,000 个单一用户更新的作用域及其任何父作用域而言，作用域将会减少 999 个成员资格条目。另外，这有助于加快父作用域对象上的受限访问权限的

29、推进速度和重新计算 ACL 的速度。重要说明：使用 SharePoint 组将促使对索引进展完全爬网。如果可能，请使用 domain 组。很深的作用域层次构造如上所示，作用域的分层深度会影响向父作用域添加受限访问用户所需的工作量。工程上方的唯一作用域直至包含具有唯一权限的 Web的数目越多，必须进展的添加的次数就越多。如果作用域层次构造很深，那么更改作用域成员资格需要花费很长时间，由于最深的作用域中每个成员资格发生了更改，工程必须反复添加了成员资格身的父作用域，以明确添加具有受限访问权限的用户或组。另外，这将增加需要重新计算的二进制 ACl 的数目，并产生相应的性能影响。最正确实践：减少具有唯

30、一权限的父对象的数目，从而减少在任意子对象作用域发生更改时需要与受限访问成员一起更新的作用域的数目。为常见 FGP 性能问题建议的解决方案以下解决方案可帮助缓解专门针对细化权限的广泛应用的性能问题。这些解决方案都包含对将影响 FGP 相关性能问题的环境安全性、对象层次构造或自定义代码所做的更改。每个解决方案从以下例如环境开场，在该环境中，单一 Web 包含多个文档库，而每个文档库都包含大量具有唯一权限的子对象。解决方案 1：移除 FGP 并仅在 Web 级别使用安全强制假设要重新构建环境，使其不再需要细化权限，那么可执行环境清理过程，然后可调整限定了作用域的工程的数量以提高环境的长期可伸缩性。

31、以下建议介绍了实现此解决方案所需的环境清理和体系构造安全更改。环境安全清理从 Web 级别作用域中移除某个用户时，内部 OM 必须从 Web 级别下的每个作用域中移除该用户。但是，移除单一用户来清理现有权限这个过程相当耗时。相反，先移除每个单一工程级别的唯一作用域，以便将工程设置为继承其父对象的权限。与尝试先移除用户相比，这样做花费的时间相对少一些，因为仅对该工程的单一作用域进展此操作。重要说明：如果当前 Web 未位于网站集的根中，并且如果稍后将其设置为继承其父 Web 的权限，那么将移除其下方的所有唯一作用域，并且一旦在单一 SQL Server 往返中使用它，就会覆盖所有受限访问成员资格

32、。在移除所有工程级别作用域后，可将 Web 级别作用域上的单个作用域成员资格替换为一个或多个组成员资格以允许访问。环境安全体系构造重新设计在移除现有细化权限和作用域后，长期体系构造规划应仅保存 Web 级别的唯一作用域。以以下图演示如何设计此构造以仅保存 Web 级别的作用域。体系构造中的核心要求是，文档库中的层次构造的同一级别上没有过多的工程，因为在视图中处理工程所需的时间会增加。作为最正确实践，层次构造中任意级别中的工程或文件夹的最大数应约为 2,000。如果需要对体系构造进展其他更改，请考虑将文档库移动到其他 Web 或网站集。还应更改文档库的数目以更严密地支持业务需求，并调整基于存储内

33、容的分类或受众的建议的范围。解决方案 2：根据分层构造更改使用细化权限假设要重新构建环境，使其仍使用细化权限而不会导致过量更新或调整单一 Web 作用域的大小，请考虑将受到不同程度的保护的文档库移动到不同的 Web。环境层次构造重新设计在以以下图中，已对物理体系构造进展了修改，以便每个文档库均位于具有唯一权限的 Web 中。另外，如果必须保存工程级别的 FGP，作为最正确实践，应将授予了访问权的安全主体的累积数限制为 2,000，不过此限制是不固定的。就这点而论，每个 Web 的有效成员资格包括所有受限访问成员用户应不超过 2,000 个用户，以防止每个 Web 级别作用域变得过大。具有唯一作

34、用域的子级的数目不会成为一个大的问题，可将此数目扩大到一个较大的数字，但作为受限访问添加到作用域链上首个具有唯一权限的 Web 的主体的数目将成为一个限制因素。最后尽管不是专门的 FGP 问题，文件夹构造应确保文档库的单一层次级别上的工程数不超过 2,000。此限制可帮助确保用户请求的视图具有良好性能。解决方案 3：根据范围构造更改使用细化权限仅仅 2010假设要重新构建环境，使其仍使用细化权限而不会导致过量更新或调整单一 Web 作用域的大小，请考虑使用不同的过程来保护工程。这在唯一作用域的数目过多是因自动化过程例如，动态修改对象权限的事件处理程序或工作流造成的情况下适用。在此情况下，建议更

35、改用于创立唯一安全作用域的过程的代码。动态安全更改代码重新设计在以以下图中，已修改作用域体系构造以使作用域成员资格不会导致在父文档库和 Web 中重新计算 ACL。如前所述，Web 的有效成员资格包括所有受限访问成员的数目应不超过 2,000，以防止 Web 级别作用域变得过大。但在此情况下，将通过实现新的 SharePoint 组来保存所有应具有受限访问权限的成员，这样作用域将不会变得过大。假设通过使用新的 SharePoint 2010 产品的SPRoleAssignmentCollection.AddToCurrentScopeOnly方法将用户添加到 Web 级别下的单一作用域，那么可

36、在稍后通过其他代码将它们添加到已创立的具有 Web 和文档库级别的受限访问权限的新组。如前所述，如果必须保存工程级别的 FGP，作为最正确实践，应将授予了访问权的安全主体的累积数限制为 2,000，不过此限制是不固定的。就这点而论，随着此数目的增多，重新计算二进制 ACL 所需的时间也会增多。如果作用域的成员资格发生更改，那么必须重新计算二进制 ACL。但是，在子工程的唯一作用域上添加用户会导致使用新的受限访问成员来更新其父作用域，因此这个问题将变得更为严重，即使这样做最终不会导致父作用域成员资格发生任何更改。在发生此情况时，还必须重新计算父作用域的二进制 ACL。如上一个解决方案所述，具有唯

37、一作用域的子级的数目不会成为一个大的问题，可将此数目扩大到一个较大的数字，但作为受限访问添加到作用域链上首个具有唯一权限的 Web 的主体的数目将成为一个限制因素。环境体系构造例如本节描述了一个例如环境，该环境中反映了与细化权限相关的问题所聚集而成的重要问题，并且本文还包含了用于解决这些问题的解决方案组合。环境概述基于 SharePoint Server 2007 的知识管理系统包含两个网站集，每个网站集都具有单一 Web、Contoso-Draft 和 Contoso-Production。可以在 Contoso-Draft 中发布初稿，并且工作流可在其中与文档进展交互。Contoso-Pr

38、oduction 是每个已批准文档的最终位置，也是所有已批准内容的存储库。可将文档分配给用于传达文档主旨的多个内容类型之一例如，工程规划或疑难解答指南。此外，已根据技术领域包含上百种或更多的专一性和专业领域例如，工程管理或运营对文档进展了分类。草稿发布网站集为每个专业领域包含了一个对应的文档库，每个文档库都具有一个由针对每个技术领域的不断增长的特定文件夹构成的层次构造，在创立新文档时，用户应先从专业领域库和特定技术领域文件夹中进展选择。以以下图演示了 Web 的原始物理构造的简化表示，其中每个具有唯一编号的金色六边形均表示一个唯一权限作用域，并且该容器内的所有子对象具有自己的唯一权限作用域，否

39、那么都将从一样的作用域继承。可以为内容类型、技术领域和专业领域的每个组合指定一名非重叠的审阅者，该审阅者是技术领域或专业领域的专家。文档库应在经历可动态更改指定的审阅者和工程的安全性的工作流操作时保存大量工程。在对文档进展最终审阅后，会在稍后将文档复制到与基于 Contoso-Production 的匹配位置，文档将在该位置保持不变与已发布版本一致并对公司的所有员工可用。有关内容类型和工作流规划的信息，请参见： HYPERLINK :/technet.microsoft /zh-cn/library/cc262735.aspx 内容类型和工作流规划 (SharePoint Server 201

40、0) ( :/technet.microsoft /zh-cn/library/cc262735.aspx) HYPERLINK :/technet.microsoft /zh-cn/library/ff607870.aspx 内容类型规划 (SharePoint Foundation 2010) ( :/technet.microsoft /zh-cn/library/ff607870.aspx) HYPERLINK :/technet.microsoft /zh-cn/library/cc262735(office.12).aspx 内容类型规划 (Office SharePoint Se

41、rver) ( :/technet.microsoft /zh-cn/library/cc262735(office.12).aspx) HYPERLINK :/technet.microsoft /zh-cn/library/cc287765(office.12).aspx 规划内容类型 (Windows SharePoint Services) ( :/technet.microsoft /zh-cn/library/cc287765(office.12).aspx)工作流设计一旦工作流程开场，就将阻止文档作者访问工作流程，以便其他人能够在作者未更改文档的情况下审阅文档。对于工作流的每个成

42、功步骤，之前可访问文档的用户的访问将被拒绝，而向工作流的下一阶段的审阅者授予访问权。工作流程将编码工作流与自定义事件处理程序配合使用。在文档库中更改某个工程时，更改最初是由能够更改权限并启动新的工作流实例的自定义事件处理程序来执行的。工作流和事件处理程序都更改了要更新的特定文件的权限，以便为每个工程授予唯一权限作用域。此权限更改意味着，一次只能有一个用户或几个用户即该步骤的审阅者访问工程。工作流中的最后一步一旦已完全批准文档是，使用继承自父 Web 的权限将文档复制到等效的 Contoso-Production 位置作为新的发布版本。细化权限问题虽然已在开发期间对环境和工作流设计进展了很好的测

43、试，但现在仍遇到了严重的性能问题，即，任务需在用户体验延迟一到几十分钟后才能完成。测试仅使用了几百个测试帐户，但在设计发布并将其指定为整个公司的强制性知识捕获工具后，使用率得到快速增长，有 15,000 个用户累计在使用 30,000 个文档。报告的性能问题会导致公司的大局部员工无法使用应支持 60,000 个用户的新知识管理系统。当工作流中发生权限更改时，将为每个单一工程创立一个权限作用域。遵循前面描述的受限访问权限级别的要求，使用受限访问将每个唯一安全主体添加到层次构造中位于工程上方的各种唯一权限作用域，直至找到具有唯一权限的 Web。因此，位于具有唯一权限的工程上方和具有唯一权限的 Web 下方的唯一作用域越多，使用受限访问将安全主体添加到的作用域就越多。此处需注意的一个关键事项是，导致出现该问题的原因不是网站集根网站中创立的唯一作用域的数量过多，而是 Web 级别作用域内的唯一安全主体的有效数目已超过 15,000 个唯一用户。此外，还会将添加到 Web 下方的任意唯一权限作用域的每个用户添加到 Web 自己的作用域，这将导致每进展一次添加就会重新计算二进制 ACL 一次。由于与二进制 ACL 重新计算的频率组合的 Web