在 SharePoint Server 中使用细化权限的最佳做法

  • 项目

适用于：yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

细化权限可能影响 SharePoint 场的安全。 使用细化权限时可能会出现潜在的性能问题。 当环境中遇到细分权限的错误使用或错误规模所可能导致的问题时，可以使用下面的信息来帮助您解决问题。

您可以通过执行以下操作来避免细分权限：

  • 尽可能减少取消权限继承。

  • 使用基于文件夹成员资格来分配权限的组。

  • 由于 SharePoint Server 搜索连续爬网功能进行了更改，现在添加了安全信息，我们不再建议避免使用 SharePoint 组来管理动态用户和组成员身份。 在 SharePoint Server 之前，使用 SharePoint 组中的动态成员资格可能导致在成员资格更改后，搜索结果无法在进行完全爬网之前正确显示给所有成员。 现在，通过包含安全信息的连续爬网功能，动态成员资格或其他安全更改将得到更快的选取（默认值为 15 分钟），并用于搜索查询结果修整。

  • 在尽可能高的级别分配权限。 作为此策略的一部分，请考虑以下技巧：

    • 将需要细分权限的文档置于文档库中，该文档库定义为支持每个权限组“将文档库保留在单独网站集或网站中”。

    • 使用不同文档发布级别来控制访问权限。 在发布文档之前，可以为只能批准文档库中项目的用户设置高级权限和版本控制设置。

    • 对于非文档库（列表），使用 ReadSecurity 和 WriteSecurity 权限级别。 创建列表后，所有者可以将项级权限设置为读取权限或创建和编辑权限。

开始之前

开始此操作之前，请查看有关先决条件的以下信息：

避免细分权限常见限制问题的最佳实践

如果您的业务需求必须使用细分权限，请考虑以下建议的最佳实践：

  • 请确保文档库中的同一层次结构级别上没有太多项，因为处理视图中的项目所需的时间会增加。

  • 使用事件处理程序来控制编辑权限。 您可以获取使用 SPEventReceiverType.ItemUpdating 和 SPEventReceiverType.ItemUpdated 方法注册事件的事件处理程序，然后使用代码来控制是否应允许更新。 该功能非常强大，因为您可以根据列表或项目的任何元数据作出安全决策，而不会影响视图呈现性能。

  • 使用 AddToCurrentScopeOnly 方法在 SharePoint 组中分配"受限访问"成员资格。 此原则中的关键元素是重新设计体系结构，以便范围成员身份不会导致访问控制列表 (ACL) 父文档库和 Web 上的重新计算。 有关范围更改的其他信息，请参阅“问题 3：按范围结构更改使用细分权限（仅限 2010）”。

使用细化权限时，很容易无意中遇到阻止权限解析的限制。 本部分介绍了一些相关限制，以及如何设置这些限制以实现正确解析权限的最佳实践。

列表中包含过多范围

每个列表或文档库的内置限制为 50，000 个范围。 达到 50,000 个范围后，禁止在给定列表或文档库中添加新范围。

最佳实践：

  • 仅对文件夹之类的父对象设置独特范围。

  • 不要在具有多个作用域的对象下创建具有许多唯一权限对象的系统。

  • 如果您的业务需要在列表或文档库中包含超过 50,000 个具有独特权限的项目，那么您必须将一些项目移动到其他列表或文档库。

更改内置范围限制

通过使用 Microsoft PowerShell 脚本更改内置范围限制。

使用 Windows PowerShell 更改内置作用域限制的具体步骤

  1. 确认您具有以下成员身份：

  • SQL Server 实例上的 securityadmin 固定服务器角色。

  • 要更新的所有数据库上的 db_owner 固定数据库角色。

  • 运行 PowerShell cmdlet 的服务器上的管理员组。

  • 添加至少具有以上最小权限的成员。

    管理员可使用 Add-SPShellAdmin cmdlet 来授予使用 SharePoint Server 2016 cmdlet 的权限。

    注意

    [!注意] 如果您不具有这些权限，请联系您的安装管理员或 SQL Server 管理员来请求权限。 有关 PowerShell 权限的详细信息，请参阅 Add-SPShellAdmin。

  1. 启动 SharePoint Management Shell 。

  2. 在 PowerShell 命令提示符处，键入以下命令：

    $webapp = Get-SPWebApplication http://<serverName>
$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Number of scope limit>

    其中：

    • 其中 <serverName> 是 SharePoint 场中应用程序服务器的名称。

    • 其中 <，范围数限制> 是希望每个 SharePoint 列表允许的唯一权限范围的最大数目。 通常情况下，如果相同层次结构级别中存在多个范围，则有效限制远小于 50,000。 这是因为，该层次结构级别下项目的显示检查必须针对项目上的所有范围进行。 该限制会导致特定查询中允许的有效范围数量减少到 1,000 至 2,000。

注意

[!注意] 我们建议您在执行命令行管理任务时使用 Windows PowerShell。 Stsadm 命令行工具已被弃用，仍然包含该工具是为了支持与之前产品版本的兼容性。

权限范围中包含过多成员

如前面所述，当相关权限范围的成员资格更改时，将会计算二进制 ACL。 此处的更改包括添加新的受限访问成员的情况。 随着范围成员资格数增加，重新计算二进制 ACL 所需的时间也会增加。

这个问题可能会变得更糟，因为在子对象的独特范围添加用户会导致为父范围更新新的受限访问成员，即使这最终不会导致父范围成员资格产生任何变化。 当出现这种情况时，必须花费更多处理时间对父范围的二进制 ACL 进行重新计算，即使该过程最终产生相同 ACL。

最佳实践：

在权限范围中利用组成员身份，而不是个人用户成员身份。 例如，如果可以使用单个组，而不是 1,000 位个人用户，则权限范围及其任何父范围会减少 999 个成员资格条目。 此外，可以对单个组更新受限访问权限，而不是更新具有受限访问权限的每个用户。 这也有助于提高父范围对象上的受限访问权限推送和 ACL 重新计算速度。

重要

使用 SharePoint 组会导致对索引完全爬网。 如果可能，请使用域组。

很深的范围层次结构

如前所述，权限范围的层次深度会影响向父范围添加受限访问用户所需的工作。 项目上的独特范围数越大（直至并包括具有独特权限的 Web），必须进行的添加次数就越多。 如果范围层次结构很深，将需要很长时间才能进行范围成员资格更改，因为最深范围项目中的每个成员资格更改必须以迭代方式对父范围进行更新，更新内容为明确添加的具有受限访问权限的用户或组的成员资格添加。 此外，这将根据性能影响，增加需要重新计算的二进制 ACL 的数量。

最佳实践：

减少具有独特权限的父对象的数量。 这会减少任何子对象的范围发生变化时，需要更新受限访问成员的范围数量。