作用网站安全性

使用细化权限的最佳实践本文档按"原样"提供.
本文表达的信息和观点(包括URL和其他Internet网站引用)随时可能发生更改,恕不另行通知.
使用本文档的风险由您自行承担.
此处所述的某些示例仅供演示之用,纯属虚构.
无意进行真实的关联或联系,请勿据此妄加推测.
本文并不为您提供对任何Microsoft产品中任何知识产权的任何法律权利.
您可以出于内部参考目的复制和使用本文档.
2010MicrosoftCorporation.
保留所有权利.
页码2使用细化权限的最佳实践作者:SeanLivingston,SharePoint产品组的产品经理发布时间:2010年9月摘要:本白皮书介绍了细化权限(FGP)的最佳实践,以及如何在使用SharePoint产品和技术或MicrosoftSharePoint2010产品时在您的组织内部使用它们.
页码3目录目录3使用细化权限概述.
4SharePoint权限系统概述.
5权限级别.
5SharePoint组5作用域.
5安全对象.
6继承.
6受限访问.
7二进制ACL.
8避免常见FGP限制问题的最佳实践8列表中的作用域过多.
8作用域中的成员过多.
9很深的作用域层次结构.
9为常见FGP性能问题建议的解决方案10解决方案1:移除FGP并仅在Web级别使用安全强制.
10环境安全清理10环境安全体系结构重新设计.
11解决方案2:根据分层结构更改使用细化权限12环境层次结构重新设计.
12解决方案3:根据范围结构更改使用细化权限(仅仅2010)13动态安全更改代码重新设计.
13环境体系结构示例.
14环境概述.
15工作流设计.
16细化权限问题.
16FGP问题的解决方法.
17摘要19页码4使用细化权限概述本文描述了SharePoint2010产品(MicrosoftSharePointServer2010和MicrosoftSharePointFoundation2010)与SharePointProducts和技术(OfficeSharePointServer2007和WindowsSharePointServices3.
0版)的细化权限(FGP)的使用;与FGP相关的性能问题;配置包含FGP的解决方案的最佳实践.
注意:建议您只对需要FGP的业务案例使用FGP.
就操作监督和性能而言,FGP的成本很高.
可通过采取以下措施来避免使用FGP:尽可能少地中断权限继承.
使用基于目录成员资格的组分配权限.
注意:建议您不使用SharePoint组向网站分配权限,因为在使用SharePoint组分配权限时,将对索引进行完全爬网.
相反,建议您使用Domain组.
在可能的最高级别分配权限.
作为此策略的一部分,请考虑以下技术:o将需要细化权限的文档隔离到为支持每组权限而定义的文档库中,并将文档库保存到隔离的网站集或网站中.
有关分层更改的其他信息,请参阅解决方案2:根据分层结构更改使用细化权限.
注意:在本文档中,术语Web和网站等同于SPWeb对象,而网站集等同于SPSite对象.
o使用不同的文档发布级别来控制访问.
在发布文档之前,可以为只能批准文档库中的项目的用户设置高级权限和版本控制设置.
o对于非文档库(列表),请使用ReadSecurity和WriteSecurity权限级别.
在创建列表时,所有者可将项目级权限设置为"读取"访问权限或"创建和编辑"访问权限.
如果您必须使用细化权限,请考虑以下建议的实践:确保文档库中的层次结构的同一级别上没有过多的项目,因为在视图中处理项目所需的时间会增加.
使用事件处理程序控制编辑权限.
可以包含一个使用SPEventReceiverType.
ItemUpdating和SPEventReceiverType.
ItemUpdated方法注册事件的事件处理程序,然后使用代码来控制是否应允许更新.
这样做很有用,因为您可基于列表或项目的任意元数据做出安全性决策,而不会影响视图呈现性能.
有关事件处理程序的其他信息,请参阅FGP问题的解决方法.
使用AddToCurrentScopeOnly方法可在SharePoint组中分配"受限访问"成员资格.
此原则的关键要素在于,重新设计体系结构以使作用域成员资格不会导致在父文档库和Web中重新计算ACL.
有关作用域更改的其他信息,请参阅解决方案3:根据作用域结构更改使用细化权限(仅2010).
页码5SharePoint权限系统概述本节描述了SharePoint权限作用域系统.
有关规划网站安全性的详细信息,请参阅:规划网站权限(SharePointServer2010)(http://technet.
microsoft.
com/zh-cn/library/cc262778.
aspx)规划网站权限(SharePointFoundation2010)(http://technet.
microsoft.
com/zh-cn/library/cc287752.
aspx)规划网站安全性(OfficeSharePointServer)(http://technet.
microsoft.
com/zh-cn/library/cc262778(office.
12).
aspx)规划网站安全性(WindowsSharePointServices)http://technet.
microsoft.
com/zh-cn/library/cc287752(office.
12).
aspx(http://technet.
microsoft.
com/zh-cn/library/cc287752(office.
12).
aspx)权限级别权限级别包含一组单个权限,例如,"查看项目"或"创建通知".
用户可预定义或创建权限级别.
甚至可在预定义的权限级别中修改权限集.
SharePoint组SharePoint组是一个可保留其他安全主体的网站集范围的对象,包括Windows用户帐户、非Windows用户(例如,基于表单的帐户)和ActiveDirectory组.
作用域作用域是未定义单独的安全边界的安全对象及其任意子级的安全边界.
作用域包含一个访问控制列表(ACL),但与NTFSACL不同,作用域可包含特定于SharePoint的安全主体.
作用域的ACL成员可包含Windows用户,非Windows用户(例如,SharePoint产品和技术中基于表单的帐户或SharePoint2010产品中基于声明的帐户)、ActiveDirectory组或SharePoint组.
可在父作用域内创建的作用域的最大数目不存在.
但对于SharePoint产品和技术,在创建完1,000个作用域后,将使用一个代码路径,此路径需要MicrosoftSQLServer往返以便在呈现视图之前分析这些作用域.
当作用域数小于或等于1,000时,只需一次往返即可.
在SharePoint2010产品中,在切换到其他算法之前所返回的作用域数的限制将基于查询限制,其默认值为5,000;但即使该值是默认值,它也是一个很大的值,足以显著降低性能.
在SharePoint2010产品中,有一个名为SPRoleAssignmentCollection.
AddToCurrentScopeOnly的新方法,可通过此方法进行角色分配.
有关角色分配的其他信息,请参阅SPRoleAssignmentCollection.
AddToCurrentScopeOnly(该链接可能指向英文页面)(http://msdn.
microsoft.
com/zh-cn/library/microsoft.
sharepoint.
sproleassignmentcollection.
addtocurrentscopeonly.
aspx).
页码6安全对象安全对象是一个可为其分配ACL的对象.
在SharePoint产品和技术中,可使用ISecurableObject接口,而在SharePoint2010产品中,应使用SPSecurableObject类.
有关安全对象的其他信息,请参阅ISecurableObject接口(该链接可能指向英文页面)(http://msdn.
microsoft.
com/zh-cn/library/microsoft.
sharepoint.
isecurableobject.
aspx或SPSecurableObject类(该链接可能指向英文页面)(http://msdn.
microsoft.
com/zh-cn/library/microsoft.
sharepoint.
spsecurableobject.
aspx).
继承如果一个安全对象不具有唯一作用域,则该对象将继承其父级的作用域.
当某个对象从其父级继承时,不会为该对象创建作用域.
相反,只要进行安全检查,它就会针对父对象进行验证.
在最简单的环境中,此作用域位于包含该项目的网站集的根网站中.
在更改某个项目或容器使其具有唯一成员资格时,其继承将中断,这意味着将为该项目(默认情况下,将为继承其权限作用域的任意子级)创建新作用域.
下图演示了文档库的对象层次结构,其中,所有对象(除一个对象外)将继承其父级的作用域.
每个编号的金色六边形均表示一个权限作用域.
除非容器内的所有子对象都有自己的唯一权限作用域,否则它们都将从该父作用域继承.
页码7受限访问在向一个具有唯一权限的项目的作用域中添加某个安全主体时,此安全主体将与受限访问权限级别一起添加到在层次结构中位于该项目上方的每个唯一权限作用域,直至找到具有唯一权限的父Web.
之所以向具有受限访问的作用域中添加用户,是为了允许对在层次结构中位于具有唯一权限的项目上方的对象进行足够访问,以便在用户尝试导航到该项目时能呈现对象模型(OM)、母版页和导航.
没有父作用域中的受限访问权限,用户将无法成功导航到或打开具有唯一权限的项目.
下图演示了作用域的分层深度将如何影响向父作用域添加受限访问用户所需的工作量.
项目上方的唯一作用域(直至包含具有唯一权限的Web)的数目越多,必须进行的添加的次数就越多.
该图演示了具有在每个级别(从Web到单个项目)上定义的唯一作用域的物理结构的简化表示.
如上图所示,每个具有不同编号的金色六边形均代表一个唯一权限作用域,除非容器内的所有子对象具有自己的唯一权限作用域,否则它们将从该作用域继承.
红色箭头显示受限访问升级链.
此图还包括一组唯一作用域和必须在每个父作用域(由作业域内单独的框表示)上进行的受限访问成员资格添加.
只要将安全主体添加到具有唯一权限的对象作用域(位于具有唯一权限的Web下方)中,就无需额外编程即可添加唯一作用域.
页码8在将具有受限访问权限级别的安全主体添加到父作用域中时,无需进行任何检查即可查看安全主体是否已在父作用域中.
再次将可访问父作用域的安全主体与受限访问权限一起添加,而不管其父作用域上的现有权限如何.
当从父作用域上的受限访问权限级别中移除一个安全主体时,将从受限访问权限级别中移除该安全主体在每个子作用域内对应的所有实例,而不管该安全主体在子作用域上是具有受限访问权限还是具有一组更大的权限.
二进制ACL二进制ACL执行用户令牌快速对比,以确定用户是否应具有对作用域覆盖的对象的访问权.
只要作用域的成员资格发生更改,就会计算二进制ACL(包括在添加新的受限访问成员时).
随着成员资格的提升,计算二进制ACL所需的时间也会增加,并将阻止访问对象,直到可以重新计算ACL.
虽然除了SQLServer中设定的最大图像列大小之外,二进制ACL没有明确的大小限制,但有些服务无法接受大于64KB的ACL.
在此情况下,二进制ACL中安全主体的数目也许能变得非常大,但出于性能和互操作性方面的考虑,还是应限制该数目.
有关SQLServer中图像列大小限制的信息,请参阅ntext、text和image(Transact-SQL)(http://msdn.
microsoft.
com/zh-cn/library/ms187993.
aspx).
避免常见FGP限制问题的最佳实践在使用细化权限时,很容易意外碰到阻止解析权限的限制.
列表中的作用域过多每个列表或文档库均存在50,000个作用域的内置限制.
在达到50,000个作用域后,将禁止向给定列表或文档库内添加新的作用域.
在SharePoint2010产品中,可使用WindowsPowerShell脚本修改内置作用域限制.
将内置作用域限制修改为少于50,000个作用域1.
确保您满足以下最低要求:请参阅Add-SPShellAdmin(http://technet.
microsoft.
com/zh-cn/library/ff607596.
aspx).
2.
在"开始"菜单上单击"所有程序".
3.
单击"MicrosoftSharePoint2010产品".
4.
单击"SharePoint2010ManagementShell".
5.
在WindowsPowerShell命令提示符处,键入以下语法:$webapp=Get-SPWebApplicationhttp://serverName页码9$webapp.
MaxUniquePermScopesPerList$webapp.
MaxUniquePermScopesPerList=但通常来说,如果同一个层次级别上存在多个作用域,则有效限制会比50,000小得多.
这是因为,必须针对位于该层次级别下的项目上方的所有作用域检查这些项目的显示情况.
此限制会导致特定查询中允许的有效作用域数降至1,000到2,000.
最佳实践:仅在父对象上设置唯一作用域,例如文件夹.
不要在具有多个作用域的对象下方创建包含多个具有唯一权限的对象的系统.
如果您的企业要求文档或文档库中包含50,000个以上具有唯一权限的项目,则您必须将一些项目移动到不同的列表或文档库.
作用域中的成员过多如上所述,只要作用域的成员资格发生更改(包括在添加新的受限访问成员时),就会计算二进制ACL.
随着作用域成员资格数的增多,重新计算二进制ACL所需的时间也会增多.
但是,由于在子对象的唯一作用域上添加用户会导致使用新的受限访问成员来更新其父作用域,因此这个问题将变得更为严重,即使这样做最终不会导致父作用域成员资格发生任何更改.
若发生此情况,还必须重新计算父作用域的二进制ACL,但这样做会花费更多的处理时间,即使它最终会生成同一ACL也是如此.
最佳实践:依赖于组成员资格而非作用域中的单个用户成员资格.
例如,如果可使用一个组来代替1,000个用户,则对于将使用该单一组的受限访问权限(而不是具有受限访问权限的所有1,000个单一用户)更新的作用域及其任何父作用域而言,作用域将会减少999个成员资格条目.
另外,这有助于加快父作用域对象上的受限访问权限的推进速度和重新计算ACL的速度.
重要说明:使用SharePoint组将促使对索引进行完全爬网.
如果可能,请使用domain组.
很深的作用域层次结构如上所示,作用域的分层深度会影响向父作用域添加受限访问用户所需的工作量.
项目上方的唯一作用域(直至包含具有唯一权限的Web)的数目越多,必须进行的添加的次数就越多.
如果作用域层次结构很深,则更改作用域成员资格需要花费很长时间,由于最深的作用域中每个成员资格发生了更改,项目必须反复添加了成员资格身的父作用域,以明确添加具有受限访问权限的用户或组.
另外,这将增加需要重新计算的二进制ACl的数目,并产生相应的性能影响.
页码10最佳实践:减少具有唯一权限的父对象的数目,从而减少在任意子对象作用域发生更改时需要与受限访问成员一起更新的作用域的数目.
为常见FGP性能问题建议的解决方案以下解决方案可帮助缓解专门针对细化权限的广泛应用的性能问题.
这些解决方案都包含对将影响FGP相关性能问题的环境安全性、对象层次结构或自定义代码所做的更改.
每个解决方案从以下示例环境开始,在该环境中,单一Web包含多个文档库,而每个文档库都包含大量具有唯一权限的子对象.
解决方案1:移除FGP并仅在Web级别使用安全强制若要重新构建环境,使其不再需要细化权限,则可执行环境清理过程,然后可调整限定了作用域的项目的数量以提高环境的长期可伸缩性.
以下建议介绍了实现此解决方案所需的环境清理和体系结构安全更改.
环境安全清理从Web级别作用域中移除某个用户时,内部OM必须从Web级别下的每个作用域中移除该用户.
但是,移除单一用户来清理现有权限这个过程相当耗时.
相反,先移除每个单一项目级别的唯一作用域,以便将项目设置为继承其父对象的权限.
与尝试先移除用户相比,这样做花费的时间相对少一些,因为仅对该项目的单一作用域进行此操作.
重要说明:如果当前Web未位于网站集的根中,并且如果稍后将其设置为继承其父Web的权限,则将移除其下方的所有唯一作用域,并且一旦在单一SQLServer往返中使用它,就会覆盖所有受限访问成员资格.
页码11在移除所有项目级别作用域后,可将Web级别作用域上的单个作用域成员资格替换为一个或多个组成员资格以允许访问.
环境安全体系结构重新设计在移除现有细化权限和作用域后,长期体系结构规划应仅保留Web级别的唯一作用域.
下图演示如何设计此结构以仅保留Web级别的作用域.
体系结构中的核心要求是,文档库中的层次结构的同一级别上没有过多的项目,因为在视图中处理项目所需的时间会增加.
作为最佳实践,层次结构中任意级别中的项目或文件夹的最大数应约为2,000.
页码12如果需要对体系结构进行其他更改,请考虑将文档库移动到其他Web或网站集.
还应更改文档库的数目以更紧密地支持业务需求,并调整基于存储内容的分类或受众的建议的范围.
解决方案2:根据分层结构更改使用细化权限若要重新构建环境,使其仍使用细化权限而不会导致过量更新或调整单一Web作用域的大小,请考虑将受到不同程度的保护的文档库移动到不同的Web.
环境层次结构重新设计在下图中,已对物理体系结构进行了修改,以便每个文档库均位于具有唯一权限的Web中.
另外,如果必须保留项目级别的FGP,作为最佳实践,应将授予了访问权的安全主体的累积数限制为2,000,不过此限制是不固定的.
就这点而论,每个Web的有效成员资格(包括所有受限访问成员用户)应不超过2,000个用户,以避免每个Web级别作用域变得过大.
页码13具有唯一作用域的子级的数目不会成为一个大的问题,可将此数目扩大到一个较大的数字,但作为受限访问添加到作用域链上首个具有唯一权限的Web的主体的数目将成为一个限制因素.
最后(尽管不是专门的FGP问题),文件夹结构应确保文档库的单一层次级别上的项目数不超过2,000.
此限制可帮助确保用户请求的视图具有良好性能.
解决方案3:根据范围结构更改使用细化权限(仅仅2010)若要重新构建环境,使其仍使用细化权限而不会导致过量更新或调整单一Web作用域的大小,请考虑使用不同的过程来保护项目.
这在唯一作用域的数目过多是因自动化过程(例如,动态修改对象权限的事件处理程序或工作流)造成的情况下适用.
在此情况下,建议更改用于创建唯一安全作用域的过程的代码.
动态安全更改代码重新设计在下图中,已修改作用域体系结构以使作用域成员资格不会导致在父文档库和Web中重新计算ACL.
如前所述,Web的有效成员资格(包括所有受限访问成员)的数目应不超过2,000,以避免Web级别作用域变得过大.
但在此情况下,将通过实现新的SharePoint组来保留所有应具有受限访问权限的成员,这样作用域将不会变得过大.
若通过使用新的SharePoint2010产品的SPRoleAssignmentCollection.
AddToCurrentScopeOnly方法将用户添加到Web级别下的单一作用域,则可在稍后通过其他代码将它们添加到已创建的具有Web和文档库级别的受限访问权限的新组.
页码14如前所述,如果必须保留项目级别的FGP,作为最佳实践,应将授予了访问权的安全主体的累积数限制为2,000,不过此限制是不固定的.
就这点而论,随着此数目的增多,重新计算二进制ACL所需的时间也会增多.
如果作用域的成员资格发生更改,则必须重新计算二进制ACL.
但是,在子项目的唯一作用域上添加用户会导致使用新的受限访问成员来更新其父作用域,因此这个问题将变得更为严重,即使这样做最终不会导致父作用域成员资格发生任何更改.
在发生此情况时,还必须重新计算父作用域的二进制ACL.
如上一个解决方案所述,具有唯一作用域的子级的数目不会成为一个大的问题,可将此数目扩大到一个较大的数字,但作为受限访问添加到作用域链上首个具有唯一权限的Web的主体的数目将成为一个限制因素.
环境体系结构示例本节描述了一个示例环境,该环境中反映了与细化权限相关的问题所汇集而成的重要问题,并且本文还包含了用于解决这些问题的解决方案组合.
页码15环境概述基于SharePointServer2007的知识管理系统包含两个网站集,每个网站集都具有单一Web、Contoso-Draft和Contoso-Production.
可以在Contoso-Draft中发布初稿,并且工作流可在其中与文档进行交互.
Contoso-Production是每个已批准文档的最终位置,也是所有已批准内容的存储库.
可将文档分配给用于传达文档主旨的多个内容类型之一(例如,项目规划或疑难解答指南).
此外,已根据技术领域(包含上百种或更多的专一性)和专业领域(例如,项目管理或运营)对文档进行了分类.
草稿发布网站集为每个专业领域包含了一个对应的文档库,每个文档库都具有一个由针对每个技术领域的不断增长的特定文件夹构成的层次结构,在创建新文档时,用户应先从专业领域库和特定技术领域文件夹中进行选择.
下图演示了Web的原始物理结构的简化表示,其中每个具有唯一编号的金色六边形均表示一个唯一权限作用域,并且该容器内的所有子对象具有自己的唯一权限作用域,否则都将从相同的作用域继承.
可以为内容类型、技术领域和专业领域的每个组合指定一名非重叠的审阅者,该审阅者是技术领域或专业领域的专家.
文档库应在经历可动态更改指定的审阅者和项目的安全性的工作流操作时保留大量项目.
在对文档进行最终审阅后,会在稍后将文档复制到与基于Contoso-Production的匹配位置,文档将在该位置保持不变(与已发布版本一致)并对公司的所有员工可用.
有关内容类型和工作流规划的信息,请参见:内容类型和工作流规划(SharePointServer2010)(http://technet.
microsoft.
com/zh-cn/library/cc262735.
aspx)内容类型规划(SharePointFoundation2010)(http://technet.
microsoft.
com/zh-cn/library/ff607870.
aspx)页码16内容类型规划(OfficeSharePointServer)(http://technet.
microsoft.
com/zh-cn/library/cc262735(office.
12).
aspx)规划内容类型(WindowsSharePointServices)(http://technet.
microsoft.
com/zh-cn/library/cc287765(office.
12).
aspx)工作流设计一旦工作流程开始,就将阻止文档作者访问工作流程,以便其他人能够在作者未更改文档的情况下审阅文档.
对于工作流的每个成功步骤,之前可访问文档的用户的访问将被拒绝,而向工作流的下一阶段的审阅者授予访问权.
工作流程将编码工作流与自定义事件处理程序配合使用.
在文档库中更改某个项目时,更改最初是由能够更改权限并启动新的工作流实例的自定义事件处理程序来执行的.
工作流和事件处理程序都更改了要更新的特定文件的权限,以便为每个项目授予唯一权限作用域.
此权限更改意味着,一次只能有一个用户或几个用户(即该步骤的审阅者)访问项目.
工作流中的最后一步(一旦已完全批准文档)是,使用继承自父Web的权限将文档复制到等效的Contoso-Production位置作为新的发布版本.
细化权限问题虽然已在开发期间对环境和工作流设计进行了很好的测试,但现在仍遇到了严重的性能问题,即,任务需在用户体验延迟一到几十分钟后才能完成.
测试仅使用了几百个测试帐户,但在设计发布并将其指定为整个公司的强制性知识捕获工具后,使用率得到快速增长,有15,000个用户累计在使用30,000个文档.
报告的性能问题会导致公司的大部分员工无法使用应支持60,000个用户的新知识管理系统.
当工作流中发生权限更改时,将为每个单一项目创建一个权限作用域.
遵循前面描述的受限访问权限级别的要求,使用受限访问将每个唯一安全主体添加到层次结构中位于项目上方的各种唯一权限作用域,直至找到具有唯一权限的Web.
因此,位于具有唯一权限的项目上方和具有唯一权限的Web下方的唯一作用域越多,使用受限访问将安全主体添加到的作用域就越多.
页码17此处需注意的一个关键事项是,导致出现该问题的原因不是网站集根网站中创建的唯一作用域的数量过多,而是Web级别作用域内的唯一安全主体的有效数目已超过15,000个唯一用户.
此外,还会将添加到Web下方的任意唯一权限作用域的每个用户添加到Web自己的作用域,这将导致每进行一次添加就会重新计算二进制ACL一次.
由于与二进制ACL重新计算的频率组合的Web级别作用域的大小过大,从而导致阻止多个SQLServer存储过程.
每当更改已中断继承的项目的成员资格作用域时,就会导致将作用域的每个成员作为具有Web级别作用域上的受限访问用户成员资格的成员添加.
另外,每当使用现有成员或新成员更新Web作用域的成员资格(包括受限访问)时,就会导致对Web级别作用域二进制ACL进行重新计算.
由于Web级别作用域包含15,000个以上的安全主体,因此重新计算需要花费很长时间.
在执行重新计算时,无法访问该对象,并且最终用户会遇到间歇性登录困难.
FGP问题的解决方法前面提及的解决方案将视为用于缓解遇到的FGP相关性能问题的过程的一部分,包括已制定的短期规划和长期规划.
短期决策旨在将工作流重构为不再按项目FGP进行设置,并且环境结构的层次性保持不变.
之后,将移除单个FGP作用域,首先会尝试从Web作用域或项目级别作用域中移除每个用户,但由于性能不理想,已通过让项目继承其父级的权限来为每个项目作用域制定移除过程.
另外,已通过再次权衡某些内容来阻止在层次结构的特定级别上显示过多项目.
已修改事件处理程序以通过阻止对文档或工作流进行修改,为当前未指定为审阅者的人员强制实施表单或读取访问权.
此方法不会限制可查看项目的人员,因为除了使用作用域之外,无法通过其他方法进行安全严格地查看,但可用来阻止对文档或工作流进行修改,例如,当文档处于审阅阶段时,错误地允许作者对文档进行修改.
在移除单个项目安全作用域并安装更新的工作流和事件处理程序后,用户可以使用环境并去除单个项目级别安全强制,而不会出现其他性能问题.
下图演示了移除安全作用域后的Web的原始物理结构的简化表示,其中每个具有唯一编号的金色六边形均表示一个唯一权限作用域,并且该容器内的所有子对象具有自己的唯一权限作用域,否则都将从相同的作用域继承.
页码18SharePoint产品和技术中的规划的长期解决方案将内容分成了多个Web,以便能继续使用FGP,但整体影响仅限于较少的更改.
下图演示了在将内容划分成多个Web后的内容物理结构的简化表示,其中每个具有唯一编号的金色六边形均表示一个唯一权限作用域,并且该容器内的所有子对象具有自己的唯一权限作用域,否则都将从相同的作用域继承.
下图演示了逻辑作用域设计,并突出显示了在移动到不同的Web后重新启用FGP的情况下,可添加到每个Web作用域的唯一安全主体的数目的限制.
请注意,尽管仍将保留大量具有唯一权限的项目,但解决了作用域中的安全主体的数目过多这一关键问题.
页码19最后,就最终切换到SharePoint2010产品能够为工作流设计引入新功能这一点进行了考虑,具体而言,通过使用SPRoleAssignmentCollection.
AddToCurrentScopeOnly方法仅向单个作用域中的每个项目分配成员资格,然后向SharePoint组(包括成员资格)授予父Web上的受限访问权限来动态分配FGP.
利用此过程,可通过工作流和/或事件处理程序实现FGP,而不会影响性能.
摘要本白皮书介绍了有关您的组织如何使用细化权限以及可能会发生的性能问题的最佳实践.
另外,它还包含了一些策略和过程,如果环境正因使用不当或细化权限的范围而遇到问题,则可使用这些策略和过程来缓解这些问题.
最后,本白皮书还包含了一个示例环境,该环境正因细化权限使用不当而导致遇到问题,并包含了用于纠正已发现的问题的过程.