Excel Services 最佳做法
本主题包含一个有关处理 Excel Services 的最佳做法建议的列表。
减轻威胁
匿名访问和信息泄漏
在下面的设置组合中，匿名用户将具有对进程帐户可访问的共享中的任何文件的访问权。建议不要使用下面的设置组合，原因是可能导致信息泄漏：
已打开对 Windows SharePoint Services 3.0 的匿名访问。
具有一个 UNC 信任的位置并且已打开“进程帐户”。
备注
“进程帐户”是一个 Excel Services 的全局设置，它会影响所有受信任的位置。
查看“进程帐户”选项：
在“启动”菜单上单击“所有程序”。
指向“Microsoft Office Server”，并单击“SharePoint 3.0 管理中心”。
在“快速启动”上，单击共享服务提供程序 (SSP) 链接（例如，“SharedServices1”）以查看此特定 SSP 的共享服务主页。
在共享服务主页上，在“Excel Services 设置”节中，单击“编辑 Excel Services 设置”。
在“Excel Services 设置”页上，在“安全”节中，查看“文件访问方式”下的“进程帐户”选项。
拒绝服务攻击
在针对 Web 服务的拒绝服务攻击中，攻击者将生成针对 Web 服务的非常大的单独请求。目的在于试图利用一个或多个 Web 服务输入值的限制。
建议您使用 Microsoft Internet Information Services (IIS) 设置来设置 Web 服务的最大请求大小。
使用 system.web 元素中的 httpRuntime 元素中的 maxRequestLength 属性可阻止由于用户将大型文件张贴到服务器上而引起的拒绝服务攻击。默认大小为 4096 KB (4 MB)。
有关详细信息，请参阅 <httpRuntime> 元素(https://msdn.microsoft.com/zh-cn/library/e1f13641(VS.71).aspx)（该链接可能指向英文页面） 和 <maxRequestLength> 元素(https://msdn.microsoft.com/zh-cn/library/ms827741.aspx)（该链接可能指向英文页面）。
调用应用程序和 Web 服务计算机之间的探查
如果调用应用程序和 Excel Web Services 部署到不同的计算机，则攻击者可以侦听调用应用程序和 Web 服务之间的数据传输的网络通信。此威胁也称作“探查”或“偷听”。
若要减轻此威胁，建议您：
使用安全套接字层 (SSL) 来设置安全通道以保护客户端和服务器之间的数据传输。SSL 协议有助于保护数据不受具有网络的物理访问权的任何人的封装探查。
如果使用 Excel Web Services 的自定义应用程序正在受限制的网络中运行（例如，如果将 Excel Web Services 部署到企业内部的 Web 前端计算机上），则将物理保护相关网络。
有关详细信息，请参阅保护网络(https://msdn.microsoft.com/zh-cn/library/aa302431.aspx) 和 SOAP 安全(https://msdn.microsoft.com/zh-cn/library/ms545631(office.14).aspx)（该链接可能指向英文页面）。
有关 Excel Services 拓扑、可伸缩性、性能和安全的信息，请参阅 Office SharePoint Server 2007 TechCenter 或 Office Online(https://office.microsoft.com/zh-cn/default.aspx)。
欺骗
建议您使用 SSL 来减轻 Web 服务 Internet 协议 (IP) 地址和端口被劫所构成的威胁，并阻止攻击者接收请求和代表 Web 服务作出答复。
将 SSL 证书与少数属性进行匹配，这些属性中的一个属性是从其中传入消息的 IP 地址。如果攻击者不具有 Web 服务 SSL 证书，则无法欺骗 IP 地址。
有关详细信息，请参阅保护网络(https://msdn.microsoft.com/zh-cn/library/aa302431.aspx)。
Excel Services 用户定义的函数 (UDF)
强名称依赖项
在某些情况下，UDF 程序集依赖于使用它来部署的其他程序集。如果这些从属 DLL 位于全局程序集缓存中或位于与 UDF 程序集相同的文件夹中，则它们将加载成功。
不过，在后一种情况下，加载可能会失败。如果 Excel Calculation Services 已加载具有相同名称的另一个程序集（由于未强命名程序集或已部署并加载具有相同名称的另一个版本），则加载将失败。
考虑下面的方案，其中的目录结构如下所示：
C:\Udfs\Udf01
Udf01 文件夹包含：
Udf01.dll
dependent.dll（未强命名）
Udf01.dll 依赖 dependent.dll。
C:\Udfs\Udf02
Udf02 文件夹包含：
Udf02.dll（与 Interop.dll 有关）
dependent.dll（未强命名）
Udf02.dll 具有一个与 dependent.dll 有关的依赖项。Udf01.dll 的依赖项和 Udf02.dll 的依赖项共享同一个名称。但 Udf02.dll 的 dependent.dll 与 Udf01.dll 的 dependent.dll 不同。
假定下面的流程：
Udf01.dll 是要加载的第一个 DLL。Excel Calculation Services 将查找 dependent.dll 并加载 Udf01.dll 的依赖项（在此示例中为 dependent.dll）。
Udf02.dll 在 Udf01.dll 之后加载。Excel Calculation Services 将查看 Udf02.dll 是否依赖于 dependent.dll。但是，已加载名为“dependent.dll”的 DLL。因此，将不会加载 Udf02.dll 的 dependent.dll，并且当前已加载的 dependent.dll 将用作依赖项。
因此，不会将对象（在此示例下，为 Udf02.dll 所需的 dependent.dll）加载到内存中。
为了避免发生名称冲突，建议您对依赖项进行强命名，并尽可能对它们进行唯一命名。
常规
为托管代码的 DLL 命名
若要确保程序集名称是唯一的，请按照命名空间命名指南(https://msdn.microsoft.com/zh-cn/library/893ke618(VS.71).aspx)（该链接可能指向英文页面） 使用完全限定类名称。
例如，使用 CompanyName.Hierarchichal.Namespace.ClassName 而不是 Namespace.ClassName。