第 6 章 - Extranet 安全性

保护 Extranet .NET 应用程序的安全

了解以下情形下的相关安全问题和建议的解决方案：

确定在基于 Extranet 的分布式 Web 应用程序中实现身份验证、授权和安全通信的最佳方法。

Windows XP 或 Windows 2000 Server (Service Pack 3) 和更高版本的操作系统

Microsoft Internet 信息服务 (IIS) 5.0 和更高版本

Microsoft Active Directory

.NET Framework 版本 1.0 (Service Pack 2) 和更高版本

SQL Server 2000 (Service Pack 2) 和更高版本

您必须具有开发和配置 ASP.NET、SQL Server 和 IIS 的经验。

您必须具有配置 Windows 安全性和 Active Directory 的经验。

您必须具有配置企业服务 (COM+) 应用程序的经验。

阅读第 1 章简介。这一章说明了身份验证、授权和安全通信对于分布式 Web 应用程序的重要性。

阅读第 2 章 ASP.NET 应用程序的安全模型。这一章简要介绍了创建分布式 ASP.NET Web 应用程序所采用的体系结构和技术，并重点说明了身份验证、授权和安全通信在此体系结构中的作用。

请结合以下章节学习本章，这些章节将举例说明本章所述的技术：

与 Internet 方案相比，您可以更严格地控制用户帐户。

与涉及 Internet 用户的应用程序相比，您可以给用户帐户授予更高的信任级别。

公开 Web 服务

公开 Web 应用程序

出版公司通过 Internet 公开 Web 服务。

出版公司对合作伙伴公司（不是个别用户）凭据（X.509 客户端证书）进行验证以授予访问资源的权限。出版公司不必了解合作伙伴公司的个别用户登录情况。

将客户端证书映射到出版公司内部的 Active Directory® 目录服务帐户。

Extranet 包含一个来自（内部）公司 Active Directory 的单独 Active Directory。Extranet Active Directory 是一个单独的目录林，它提供了一种单独的信任边界。

Web 服务授权基于映射的 Active Directory 帐户。您可以根据合作伙伴公司的标识（每个公司由不同的 Active Directory 帐户表示），使用不同的授权决策。

数据库由单个受信任的连接访问，该连接对应于 ASP.NET Web 服务进程标识。

从 Web 服务中检索的数据是机密数据，必须在传送过程中（对内在出版公司内部传送，对外在 Internet 上传送时）加以保护。

创建自定义 ASP.NET 帐户（请参见本指南中的如何创建自定义帐户来运行 ASP.NET）

创建一个权限最少的数据库帐户（请参见第 12 章数据访问安全性）

在 Web 服务器上配置 SSL（请参见本指南中的如何在 Web 服务器上设置 SSL）

配置 IPSec（请参见本指南中的如何使用 IPSec 在两个服务器之间进行安全通信）

配置 IPSec 以通过防火墙，请参见 Microsoft® 知识库文章 Q233256 How to Enable IPSec Traffic Through a Firewall（如何使 IPSec 通讯能够通过防火墙）

使用 SSL 调用 Web 服务（请参见本指南中的如何使用 SSL 调用 Web 服务）；在合作伙伴公司内部需要使用此解决方案技术

有关证书管理和基础结构的讨论已超出了本主题的范围。有关详细信息，请在 Microsoft TechNet 上查找 Certificates and Authenticode（证书和验证码）。

合作伙伴公司的 Web 应用程序可以选择一个身份验证机制，以便对内部用户进行身份验证和授权。不会将这些用户传递到 Web 服务以进一步进行身份验证。

合作伙伴公司的 Web 应用程序代表其用户来调用 Web 服务。用户不能直接调用 Web 服务。

合作伙伴公司的 Web 应用程序使用客户端证书向 Web 服务证明其身份。

如果合作伙伴应用程序是一个 ASP.NET Web 应用程序，那么它必须使用一个中间的进程外组件（企业服务应用程序或 Windows 服务）来加载证书并将其转发给 Web 服务。
有关这样做的必要性和具体实现步骤的详细信息，请参见本指南中的如何使用来自 ASP.NET 的客户端证书调用 Web 服务。

Web 服务器上的 ASP.NET 作为一个权限最少的本地帐户（默认的 ASPNET 帐户）运行，因此减轻了潜在的安全危险。

合作伙伴公司内部的 ASP.NET Web 应用程序使用 Windows 集成身份验证并进行授权，以确定哪些用户可以访问 Web 服务。

合作伙伴公司内的 ASP.NET Web 应用程序使用一个中间的企业服务应用程序来检索客户端证书并调用 Web 服务。

出版公司使用合作伙伴单位的名称（包含在证书中）在 IIS 中执行证书映射。

Web 服务使用映射的 Active Directory 帐户来进行授权（通过 PrincipalPermission 请求和 .NET 角色检查）。

对 SQL Server 的 Windows 身份验证意味着您可以避免在 Web 服务器上存储凭据，也意味着不必通过内部网络将凭据发送到 SQL Server 计算机。如果您使用 SQL 身份验证，则一定要在应用程序内部和网络传送过程中保证连接字符串（包含用户名和密码）的安全。使用 DPAPI 或第 12 章数据访问安全性中讨论的其他安全存储策略之一来存储连接字符串，并使用 IPSec 保护在 Web 服务和数据库之间传送的连接字符串（和机密的应用程序数据）。

合作伙伴公司和 Web 服务之间的 SSL 保护在 Internet 上传送的数据。

Web 服务和数据库之间的 IPSec 保护在公司网络上数据库来回传送的数据。在某些方案中，合作伙伴和出版公司通过专用网络进行通信，IPSec 除了可以用于保证通信安全外，还可以用于机器身份验证。

在数据库服务器上使用重复的本地 Windows 帐户（一个与本地到 IIS 的 ASP.NET 进程帐户匹配的帐户）会导致增大管理负担。密码必须定期手动更新和同步。

因为基于 .NET 角色的安全性以 Windows 组成员为基础，所以此解决方案需要根据相应层次的 Windows 组来匹配那些将要访问该应用程序的用户类别（共享相同的安全特权）。在此方案中，Active Directory 帐户必须是某个合作伙伴组的成员。

数据库不知道谁是原始调用方，我如何创建一条审核记录？
审核 Web 服务中的最终用户（合作伙伴公司）活动。在应用程序级别，使用存储过程参数将合作伙伴公司的标识传递到数据库。

合作伙伴 Web 应用程序通过使用窗体登录页面接受凭据，或者在 IIS 中使用基本身份验证以提供登录对话框。

针对 Extranet 周边网络（也称为 DMZ、网络隔离区和屏蔽子网）内的单独 Active Directory 来验证凭据。Extranet Active Directory 是一个单独的目录林，它提供了一种单独的信任边界。

数据库由单个受信任的连接访问，该连接对应于 ASP.NET Web 应用程序进程标识。

Web 应用程序授权基于 GenericPrincipal 对象（作为窗体身份验证过程的一部分创建的）或 WindowsPrincipal 对象（如果使用基本身份验证的话）。

从 Web 应用程序中检索的数据是机密数据，必须在传送过程中（对内在出版公司内部传送，对外在 Internet 上传送时）加以保护。

Web 服务器上的 ASP.NET 作为一个权限最少的本地帐户（默认的 ASPNET 帐户）运行，因此减轻了潜在的安全危险。

在浏览器和 Web 应用程序之间使用 SSL 保护窗体身份验证或基本身份验证凭据（都以明文形式传递，但基本身份验证使用 Base64 编码）。SSL 还保护从 Web 应用程序返回的应用程序特定的数据。

对于窗体身份验证，在所有页面（而不仅仅是登录页）上，使用 SSL 保护在初始身份验证后的所有后续 Web 请求中传递的身份验证 Cookie。

如果仅在初始登录页上使用 SSL 加密传递的身份验证凭据，则应该确保保护窗体身份验证票证（包含在 Cookie 中），因为每个后续 Web 请求均在客户端和服务器之间传递该票证。若要加密窗体身份验证票证，请按如下所示配置 <forms> 元素的 protection 属性，并使用 FormsAuthentication 类的 Encrypt 方法加密该票证。

<authentication mode="Forms">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="All"
       timeout="20" 
       path="/" >
  </forms>
</authentication>

protection="All" 属性指定，当应用程序调用 FormsAuthentication.Encrypt 时，应该验证（检查完整性）并加密票证。当您创建身份验证票证时，通常在该应用程序的“登录”按钮事件处理程序中调用此方法。

string encryptedTicket = FormsAuthentication.Encrypt(authTicket);

有关窗体身份验证和票证加密的详细信息，请参见第 8 章 ASP.NET 安全性。

同样，对于基本身份验证，在所有页面上都使用 SSL，因为在所有 Web 页面请求中都要传递基本凭据，而不仅仅是在用户提供基本凭据的初始页面上。

对于基本身份验证，ASP.NET 自动创建一个 WindowsPrincipal 对象来表示已验证身份的调用方，并将它与当前的 Web 请求 (HttpContext.User) 关联起来，.NET 授权在 Web 请求中使用该对象（包括 PrincipalPermission 请求和 .NET 角色在内）。

对于窗体身份验证，您必须开发代码以针对 Active Directory 验证提供的凭据，并构造一个 GenericPrincipal 来表示已验证身份的用户。

对 SQL Server 的 Windows 身份验证意味着您可以避免在 Web 服务器上存储凭据，也意味着不必通过内部网络将凭据发送到 SQL Server 计算机。

Web 服务和数据库之间的 IPSec 保护在公司网络上数据库来回传送的数据。

在数据库服务器上使用重复的本地 Windows 帐户（一个与本地到 IIS 的 ASP.NET 进程帐户匹配的帐户）会导致增大管理负担。密码必须定期手动更新和同步。

基本身份验证在浏览器中产生一个弹出式对话框。若要提供更加无缝的登录体验，请使用窗体身份验证。

Extranet 中有一个单独的 SQL Server 数据库，并且在内部数据库和 Extranet 数据库之间进行数据复制。

使用路由器拒绝从 Extranet 到公司网络的连接。可以使用特定的高端口以其他方式建立连接。

应该始终通过一个专用服务器建立从公司网络到 Extranet 的连接，该服务器具有强大的审核和记录功能，用户在访问 Extranet 前必须通过它来验证身份。

请参见以下 Microsoft TechNet 文章：

有关在 Active Directory 中使用窗体身份验证的详细信息，请参见本指南中的如何将窗体身份验证用于 Active Directory。