科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道增强 SharePoint 安全性的 7 项新功能

增强 SharePoint 安全性的 7 项新功能

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

基于表单的 MOSS 身份验证利用可插入身份验证和角色提供程序,可提供 Internet 风格的安全机制,该机制不限制客户使用老式的 NT 登录提示。

来源:微软 2007年10月31日

关键字: 微软 功能 安全 SharePoint Office

  • 评论
  • 分享微博
  • 分享邮件

为您的 Microsoft Office SharePoint Server (MOSS) 2007 环境实施有效安全措施可以显著降低日常管理费用,同时允许团队
在安全的环境中协作并共享业务数据。MOSS 2007 内置创新的身份验证功能,使您能够通过自定义身份验证提供程序、基于表单的 Internet 风格身份验证和 Web 单一登录 (SSO),充分利用基于 Web 的安全标准。而且,MOSS 还提供对公司资产(例如 2007 Microsoft® Office 系统文件)的详细权限管理、本机加密功能和简化的客户端身份验证义务。

   以下是 MOSS 2007 提供的七项安全功能,您可以快速投入使用。

1. 可插入身份验证提供程序
    身份验证提供程序是检验用户凭据的组件。在设置 Internet 风格的 SharePoint® 身份验证时,为 MOSS 环境配置身份验证提供程序是一项重要的安全决策。MOSS 继续支持 SharePoint 之前版本可用的、基于 Windows® 的身份验证方法,包括识别用户确切 Windows 身份的集成和基本身份验证(后来加入摘要式身份验证)。但是,识别 Windows 身份不再是唯一的选择。您可以利用多个身份验证提供程序,举例来说,内部用户通过 Windows 身份验证登录,而外部用户通过独立、可插入的提供程序来登录。

    MOSS 是基于 ASP.NET 2.0 构建的,而 ASP.NET 2.0 允许使用可插入身份验证提供程序。这样,您就可以使用可配置的目录来存储用户信息,只要存在对应成员数据存储的 ASP.NET 2.0 成员身份提供程序(和可选角色提供程序)。根据存储在对应的成员身份提供程序 machine.config 文件中的节点值,可插入提供程序的凭据可被散列、加密或以纯文本存储。一些成员身份提供程序可用于 MOSS,其中一些包括 LDAP V3 成员身份提供程序(随 MOSS 一同发售),加上 SQL Server™ 成员身份提供程序和随 ASP.NET 2.0 提供的 Active Directory® 成员身份提供程序。

    可实施的成员身份和角色提供程序不仅限于已发售的提供程序。使用 ASP.NET 2.0 成员身份体系结构,可以创建一些使用 Microsoft Access™、Oracle 数据库、XML 文件甚至纯文本文件来存储成员身份的自定义提供程序。自定义身份验证提供程序继承 ASP.NET MembershipProvider 接口,而后者又继承 ProviderBase 类(参见图 1)。


图 1 .NET 成员身份类层次结构

    要随 MOSS 使用 ASP.NET 2.0 身份验证(与 Windows 身份验证对照),有几点建议应该加以考虑。MOSS 和 Office 客户端之间的 Web 服务通讯原本设计为与 Windows 身份一起使用,这给许多用户带来的最明显的优势就是 Microsoft Office 客户端简化的互操作性。

    另外,某些 MOSS 服务(特别是那些与爬网和索引内容相关的),即使在使用可插入提供程序时也必须使用 Windows 帐户。要使用不能识别为 Windows 身份的验证类型来完成此任务,需要创建采用 Windows 身份验证的另外的 MOSS 区域。(本文稍后将讨论区域。)

    如果您拥有基于某种安全机制(例如智能卡)的委托 PKI 基础结构,而该安全机制的公钥或证书是由客户端携带,则通常需要根据实现方法的不同,识别 Windows 身份,以正确接受和授权客户端证书。这可能反而需要创建另外的 MOSS 区域或其他身份验证配置。

2. 基于表单的身份验证和 Web 单一登录

    MOSS 2007 可用的另一个令人兴奋的身份验证机制,就是以 ASP.NET 2.0 为基础的基于表单的身份验证。在 SharePoint 以前的版本中,这只能通过自定义 Internet 服务器应用程序编程接口 (ISAPI) 扩展或利用 IIS 6.0 工具包中的 CustomAuth ISAPI 扩展来实现。而即使有这些解决方案,SharePoint 仍然需要将帐户识别成 Windows 用户身份,这样就限制了基于外围网络的部署。

    基于表单的 MOSS 身份验证利用可插入身份验证和角色提供程序,可提供 Internet 风格的安全机制,该机制不限制客户使用老式的 NT 登录提示。您可以构建一个面向用户需求的自定义登录过程。为进一步保护身份验证过程,表单身份验证 Cookie 和身份验证票证都是加密和防篡改的。

    表单身份提供程序不必驻留本地,实际上可以插入到外部身份管理系统,而该系统转而提供用户凭据的验证功能。此功能被称为 Web 单一登录,它利用 HTTP 模块完成外部身份验证。在此类方案中,您可以在贵组织与业务合作伙伴之间进行身份联合,借此,它们便够使用各自的组织登录名向您所实现的 MOSS 进行验证。

3. 加密 MOSS 应用程序连接字符串

    把重要的连接字符串信息以纯文本保存在 web.config 文件中,是很不好的安全习惯。泄漏的信息可使用户创建到 SQL 数据库服务器的对象实例并操作重要数据。但是,使用固有的 ASP.NET 2.0 功能,您可以利用以下两种可行技术的一种来加密数据:Windows 数据保护 API (DPAPI) 或 RSA 加密。DPAPI 利用 Windows 内置的加密功能,使用 MOSS 服务器计算机密钥来执行加密和解密。RSA 加密可让您使用公钥算法,但会带来额外的日常费用,因为需要适当的容器存放加密密钥。

    对于 MOSS 2007 - 尤其是对于可插入 ASP.NET 2.0 SQL Server 身份验证提供程序 - 您将希望把 <connectionStrings> 节点加密成密文,因为在这里可能发生最严重的安全违规:

<connectionStrings>
<add name="MembershipConnectionString"
connectionString="connectionString"/>
</connectionStrings>

相对而言,使用 DPAPI 加密比较直接,而且是最容易实现的,因为它使用本机计算机密钥对虚拟目录或物理目录进行加密。有其他方法以编程方式执行该任务,但是在命令提示符下使用以下命令是最轻松的:

aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider

aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider

   因为您仅仅主要关心对连接字符串节点进行加密,所以可通过指定段参数仅将特定的段加密即可:

aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"

aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"

   执行后,敏感信息节点将被格式正确的 XML 密码值代替:

<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>


   如同整个 MOSS 体系结构,此模块是可插入的,因为您可以创建自己的加密提供程序来管理相关 MOSS 配置文件(例如 web.config 或 machine.config)的密文,而且不仅是局限于 RSA 或 DPAPI 加密。 

   使用加密会产生一些后果,需要引起注意。因为您是使用本地计算机密钥来加密,所以只能在创建配置节点的 MOSS 服务器上使用它。否则,加密过程会失败。如果入侵者获得了服务器的访问权,他们可以取得计算机密钥并将连接字符串解密。解密过程也会导致应用程序性能的轻微损失。

4. 备用访问映射和区域

   备用访问映射 (AAM) 至关重要,特别是为您的 SharePoint 环境设置一个以上的入口位置时。AAM 让您能够指定不同的 URL,通过这些 URL,用户可访问单一物理站点(参见图 2 中的图表)。AAM 可将用户引导到相同的 MOSS 站点物理路径,但使用不同的身份验证提供程序和 Web 应用程序安全策略。AAM 也能适应使用不同域、还原代理和其他 URL 重定向机制。默认情况下,MOSS 所使用的 URL 已经为您映射好了,但可以扩展到 SharePoint 体系结构设计者明确创建的其他 URL,用于处理不同登录方法。需要 AAM 来保证正确的内部和公共 URL 映射正常工作。


图 2 URL 映射和区域 (单击该图像获得较小视图) 

    MOSS 中,区域是一项新功能,允许对 AAM 提供的站点映射进行更强的控制。根据用户连接到内容所用的 AAM URL 映射,区域允许您将不同身份验证提供程序映射到相同的物理路径和 MOSS 内容。指定 AAM URL 映射时,虽然将区域绑定到身份验证机制不是必须的,但这是推荐的做法。如果 AAM URL 映射到的区域在身份验证提供程序页面没有定义,则它会使用默认区域的安全设置。

   区域需要进行计划,因为它们将对人们如何进行身份验证,如何从多个 URL 登录点进入您的门户产生重大影响。当扩展新的 Web 应用程序时,您可以在设置的“负载平衡 URL”部分(参见图 3)中指定想要使用的区域。建议您将访问的公开程度最高的 URL(例如,计划发布到 Internet 的 URL)放到“默认”区域中,因为这是 SharePoint 在无法完全确定您位于哪个区域时将会使用的 URL。


图 3 配置 MOSS 区域 (单击该图像获得较小视图)

    在每个区域内,您都可以为全局 Web 应用程序绑定安全策略,这些安全策略定义了此区域内的用户权限设置。这可让您集中管理大量的权限修改。Web 应用程序通常包括许多站点集合中的几个站点,而当应用程序变得大而复杂时,这些站点的权限管理可能会成为一个问题。MOSS 2007 允许设置全局安全策略,用以将策略设置(例如完全访问、完全读取访问、拒绝写入访问或拒绝全部访问)绑定到应用程序的特定用户或用户组。这些策略可以覆盖 MOSS 提供的、从“SharePoint 管理中心”界面管理的详细权限设置,所以您应该仔细计划您的配置。

    综上所述,根据 AAM 设置中的定义,面向外部的站点可能有两个 URL:一个用于您的公司用户,另一个用于外部用户。两类用户都有唯一的 URL,例如,内部用户使用 contoso,而受信任的外部合作伙伴使用 extranet.contoso.com。这两个 URL 将映射到相同的内容,每个都能通过它自己的区域、以其自己的身份验证提供程序和自己的应用程序安全策略来访问站点。配置 Intranet 区域使用内部 URL,使内部用户识别为他们的域验证 Windows 身份,而外部合作伙伴通过 Extranet 区域的 Web 单一登录身份验证进行登录,外部网允许他们使用自己组织的用户凭据。通过发挥将 Web 应用程序安全策略绑定到区域的优势,就可以赋予所有信任的外部用户完全读取访问权限,这与在逐个对象的基础上手动设置形成鲜明的对比。

5. 安全协作的目标内容

   锁定您的 SharePoint 站点集合意味着用户将只能处理您授权他们访问的信息。全新灵活的权限机制允许您对存储在 MOSS 环境中不同类型的业务信息进行更强的控制。

    使用 MOSS 2007,您可以选择将身份绑定到某个特定对象,此特定对象可以是站点集合、单个站点、文档库、子文件夹、列表或单个文档或列表项。同时采用拒绝访问和调整用户界面的方法,使得用户不知道他们无权访问的项目,这加强了详细访问控制,并强制要求该对象所属的明确成员身份。MOSS 的这项功能称为项目级别安全 (ILS) 或安全对象 (SO)。MOSS 对象权限会自然继承,使权限能从单个对象(例如列表项)扩展到更大的对象(例如列表或文档库)。权限继承也可执行,使低层子对象可有选择地从高层父对象继承权限。一共有 33 个唯一的默认权限,可赋予到用户或 SharePoint 组,每个权限也可绑定到对象。您也可创建新权限级别。

    例如,在项目管理站点内,您可以仅允许开发者和项目经理访问敏感的开发材料(例如存储在文档库 Microsoft Word 文档中的设计规格和编码技术)。默认情况下,库的权限从站点权限继承,但可以修改权限,以只赋予开发者和项目经理访问权,或者甚至可以使每个 Word 文档仅能由相应的项目经理和开发团队查看和访问。相反,不敏感的材料可完全公开,无论是在项目、文件夹还是文档库级别。
 
    甚至可以对事件项目指定权限,例如“事件”列表中的项目到期日,这样可以确保仅特定成员可以查看特定事件。另外,ILS 功能可以扩展到返回的搜索结果,也就是仅返回能映射回搜索者的安全上下文的对象。所有这些有效的权限控制措施,会将用户界面“修剪”到专有的用户上下文范围以内。

   权限管理体系结构在 MOSS 2007 中已经得到了极大的改进。可为 SharePoint 组和域组设置权限,也可在单独级别进行设置。有几个组已经进行了默认设置,特别是“所有者”(拥有完全控制权)、“访问者”(拥有参与人权限)和“成员”(拥有读取权限)。单独站点或域组可分配到这些默认组,或分配到您在站点集合级别创建和管理的自定义组,后者可拥有多种唯一的权限级别。 

   当创建基于角色的组时,您可创建“开发者”和“项目经理”组。您可以分配详细权限,例如,使开发者上载相关编码文档,和赋予项目经理读取和批准权限以便他们评估和签署那些文档。组成员身份在整个站点集合内保持一致,以便创建的组可在许多不同项目站点之间重用。

6. 集成可插入单一登录

    在典型计算环境中,用户可对任何数量的第三方应用程序拥有访问权,每个应用程序都有自己的身份验证条件,这会导致多种安全问题和密码记忆难题。MOSS SSO 服务通过提供加密的用户凭据后端缓存,用以映射到与之相连的商业流程系统,从而缓解了这个问题。这有助于检索重要商业信息并通过 MOSS 机制(例如业务数据目录 (BDC) 或 SharePoint DataView Web 部件 (DVWP))显示。

   与所讨论的其中几个其他应用程序体系结构功能一样,MOSS SSO 提供程序也是可插入的;您可在随 MOSS 发售的提供程序 (SpsSsoProvider) 以外指定唯一的 SSO 提供程序,虽然环境中的每个商业流程系统每次仅能注册一个 SSO 提供程序。

7. 信息权限管理 (IRM)

   对于经常处理敏感数据的公司而言,在客户端级别保护信息(甚至当商业信息脱机时)是一个不容忽视的问题,对于那些必须遵循相关法律(例如“加利福尼亚参议院议案第 1386 号”、“萨班斯 - 奥克斯利法案”(SOX 法规)和“医疗保险和责任法案”(HIPAA))的公司尤为如此。与 MOSS 知识库集成的服务器端信息权限管理 (IRM) 提供了基于 Windows 权限管理 (WRM) 框架的通用解决方案。IRM 通过在文档级别强加访问限制,而不管文档储存在哪里或谁在尝试打开它,提供了对商业数据的严格控制。通用 IRM 的实施使您能够:仅允许授权的查看或打印,但这可以扩展到其他方案(例如在特定时间段后要求验证用户凭据);不允许用户上载未采用 IRM 的资产;设定将丢弃限制策略的计划到期标签;以及绑定到全局组织 IRM 权限策略。

   IRM 功能是由保护程序提供的,一些功能已随 MOSS 2007 安装。保护程序可管理文件类型的加密过程;通常情况下,存储在 MOSS 内的所有文件已创建好保护程序。(Microsoft Office 系统文件以及 OpenXML 文件格式得到本机支持。)然而,像其他 MOSS 内的提供程序一样,应用程序体系结构是可插入的,因此您可以为其他文件类型安装自定义保护程序。

   实施 IRM 的第一步是确保在您的 MOSS 环境中满足全部要求。您需要在每个 MOSS 前端 Web 服务器上安装 WRM 服务客户端,且“Microsoft 权益管理服务”(RMS) 必须与 MOSS 前端 Web 服务器连通。然后,您必须通过“SharePoint 管理中心”指定 MOSS 吸收的 RMS 服务器,不管是使用 Active Directory 的默认值还是指定位置。

   IRM 直接与 SharePoint 数据存储结构(例如文档库)协同工作以维护权限。当用户导航到启用 IRM 的文档库并尝试下载文档时,MOSS 会将权限(为文档库配置)绑定到文档上(参见图 4)。因此,MOSS 和文档权限之间存在 1:1 的映射,将文档相关的 SharePoint 角色转换成文档本身的 IRM 权限级别。



图 4 从文档库到 IRM 权限的转换

   文档进行了本地加密以进行脱机保护,并且在被上载回文档库之前都会维持加密状态。当文档上载时,它维持在未加密格式,因此 SharePoint Gatherer 可为全文搜索而编录其内容的索引(但是没有用户帐户能够访问未加密格式的内容)。

   MOSS 2007 提供了许多新功能,可帮助您在组织中实施有效的安全措施,而无需增加大量日常管理费用。这些功能还非常灵活,允许进行大量自定义,确保用户仅访问他们需要的信息。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章