安全指南

第 7 章 –Internet 安全性

更新日期： 2004年04月20日
本页内容
本章内容本章内容
目标目标
适用范围适用范围
如何使用本章内容如何使用本章内容
开始之前开始之前
ASP.NET 到 SQL ServerASP.NET 到 SQL Server
ASP.NET 到远程企业服务到 SQL ServerASP.NET 到远程企业服务到 SQL Server
总结 总结

本章内容

Internet 应用程序的特点是：用户群庞大、潜在用途众多以及安全要求多种多样。它们包括不要求进行用户身份验证的门户应用程序、为注册用户提供内容的 Web 应用程序以及大型电子商务应用程序（要求进行完全身份验证、授权、信用卡验证，并确保通过公共和内部网络传递的机密数据的安全）。

本章将通过重点介绍两种常用分布式应用程序体系结构的要求，说明解决基于 Internet 的 Web 应用程序的身份验证、授权以及安全通信的建议方法。

返回页首返回页首

目标

本章的目标是：

•

保护面向 .NET 应用程序的 Internet

•

了解与在下列方案中使用 ASP.NET Web 应用程序与 SQL Server 2000 进行通信有关的安全问题和建议解决方案：

•

直接通信

•

使用企业服务作为媒介

•

决定在基于 Internet 的分布式 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 安全性的经验。

•

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

•

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

•

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

•

请将本章与以下各章结合起来使用，因为这些章节将说明本章所讨论的技术：

•

如何创建自定义帐户来运行 ASP.NET。

•

如何在 Web 服务器上设置 SSL。

•

如何使用 IPSec 在两个服务器之间进行安全通信。

•

如何将窗体身份验证用于 SQL Server 2000。

•

如何将窗体身份验证用于 Active Directory。

•

如何利用身份验证创建 GenericPrincipal 对象。

•

如何将基于角色的安全性用于企业服务。

•

如何使用 SSL 调用 Web 服务。

•

如何使用 SSL 来确保与 SQL Server 2000 安全通信。

返回页首返回页首

开始之前

作为 Internet 应用程序开发人员，您面临着艰巨的挑战，就是要确保应用程序使用适当的防御机制并在设计上体现出可伸缩性、高性能和安全性。您所面对的一些挑战包括：

•

选择适当的用户凭据存储，例如，自定义数据库或 Microsoft Active Directory® 目录服务。

•

使应用程序通过防火墙工作。

•

在应用程序的多个层之间传递安全凭据。

•

执行授权。

•

在公共和内部网络中传递数据时，确保数据的完整性和保密性。

•

确保应用程序状态与数据库的安全。

•

确保应用程序数据的完整性。

•

实现可根据潜在的大量用户进行伸缩的解决方案。

本章介绍两个常见的 Internet 应用程序方案，它们用于阐释建议的身份验证、授权和安全通信技术：

•

ASP.NET 到 SQL Server

•

ASP.NET 到远程企业服务到 SQL Server

注意：在本章介绍的一些方案中将更改默认 ASPNET 帐户的密码，以便在远程计算机上建立用于网络身份验证的重复帐户。这要求更新 Machine.config 的 <processModel> 元素。不应将 <processModel> 凭据以纯文本形式存储在 machine.config 中，而是应使用 aspnet_setreg.exe 实用程序将加密后的凭据存储在注册表中。有关详细信息，请参见第 8 章 ASP.NET 安全性和 Microsoft 知识库文章 Q329290 HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（HOWTO：使用 ASP.NET 工具加密凭据和会话状态连接字符串）。

返回页首返回页首

ASP.NET 到 SQL Server

此方案有两个物理层，注册用户可以使用 Web 浏览器安全地登录到基于 Web 的应用程序。基于 ASP.NET 的 Web 应用程序安全地连接到 Microsoft® SQL Server™ 数据库，以便主要管理数据检索任务。例如，向注册订户提供新闻内容的门户应用程序。图 7.1 中显示了这种情况。

ASP.NET Web 应用程序到 SQL Server Internet 方案

图 7.1
ASP.NET Web 应用程序到 SQL Server Internet 方案

特点

此方案具有以下特点：

•

用户有许多不同的浏览器类型。

•

匿名用户可以浏览该应用程序的不受限制的页面。

•

用户必须注册或登录（通过 HTML 窗体）才能有权限访问受限页面。

•

根据 SQL Server 数据库验证用户凭据。

•

验证在数据库查询中使用的所有用户输入（如用户凭据）以减轻 SQL 注入攻击的威胁。

•

前端 Web 应用程序位于周边网络（也称作 DMZ、网络隔离区和屏蔽子网）中，防火墙将它与 Internet 和公司内部网络（以及 SQL Server 数据库）隔离开。

•

该应用程序要求强大的安全性、高度的可伸缩性和详细的审核。

•

数据库委托该应用程序对用户进行正确的身份验证（即应用程序代表用户对数据库进行调用）。

•

Web 应用程序使用 ASP.NET 进程帐户连接到数据库。

•

在 SQL Server 中使用单个用户定义的数据库角色进行数据库授权。

保护方案

在此方案中，Web 应用程序提供一个登录页面以接受凭据。验证成功的用户可以继续操作，所有其他用户则被拒绝访问。数据库对 ASP.NET 默认的进程标识（它是权限最少的帐户）进行身份验证（即，数据库信任 ASP.NET 应用程序）。

表 7.1： 安全摘要

类别明细

身份验证

•

将 IIS 配置为允许匿名访问；ASP.NET Web 应用程序使用窗体身份验证对用户进行身份验证以获取凭据。根据 SQL Server 数据库进行验证。

•

数据库中不存储用户密码，而是存储带有 Salt 值的密码哈希值。Salt 减轻了与字典攻击相关的威胁。

•

Windows® 身份验证使用权限最少的 Windows 帐户连接到数据库，该帐户用于运行 ASP.NET Web 应用程序。

授权

•

ASP.NET 进程帐户被授权访问 Web 服务器上的系统资源。这些资源是使用 Windows ACL 保护的。

•

使用 ASP.NET 应用程序标识授予对数据库的访问权限。

安全通信

•

通过使用 SSL 保护用户和 Web 应用程序之间传送的机密数据。

•

通过使用 IPSec 保护在 Web 服务器和数据库服务器之间传送的机密数据。

结果

图 7.2 显示了此方案的建议安全配置。

ASP.NET 到 SQL Server Internet 方案的建议安全配置

图 7.2
ASP.NET 到 SQL Server Internet 方案的建议安全配置

安全配置步骤

在您开始之前，需要查看以下内容：

•

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

•

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

•

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

•

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

配置 Web 服务器

配置 IIS
步骤更多信息

启用对 Web 应用程序的虚拟根目录的匿名访问

若要使用 IIS 身份验证设置，请使用 IIS MMC 管理单元。右键单击应用程序的虚拟目录，然后单击“属性”。
单击“目录安全性”选项卡，然后在“匿名访问和身份验证控制”组中单击“编辑”。

配置 ASP.NET
步骤更多信息

将 ASPNET 帐户的密码（用于运行 ASP.NET）重置为一个已知的强密码

这样您就可以在数据库服务器上创建一个重复的本地帐户（具有相同的用户名和密码）。这是 ASPNET 帐户所必需的，这样该帐户在使用 Windows 身份验证进行连接时，才能响应来自数据库服务器的网络身份验证质询。

此处的替代方法是使用一个权限最少的域帐户（如果允许 Windows 身份验证通过防火墙）。
有关详细信息，请参见第 8 章 ASP.NET 安全性中的 ASP.NET 的进程标识。

编辑位于 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG 中的 Machine.config

在 <processModel> 元素上设置自定义帐户的用户名和密码属性。

默认

<!-- userName="machine" password="AutoGenerate"
 -->

成为

<!--
userName="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,password" -->

请注意，已经使用 aspnet_setreg.exe 实用程序将加密密码存储在注册表中。

将基于 Web 的应用程序配置为使用窗体身份验证（使用 SSL）

编辑应用程序的虚拟根目录下的 Web.config，将 <authentication> 元素设置为：

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

有关根据 SQL Server 数据库使用窗体身份验证的详细信息，请参见本指南中的如何将窗体身份验证用于 SQL Server 2000。

配置 SQL Server

步骤更多信息

在 SQL Server 计算机上创建一个与 ASP.NET 进程帐户匹配的 Windows 帐户

用户名和密码必须与自定义 ASP.NET 应用程序帐户匹配；如果使用的是默认帐户，则用户名和密码必须是 ASPNET。

配置 SQL Server 以便进行 Windows 身份验证

 

为自定义 ASP.NET 应用程序帐户创建一个 SQL Server 登录

这将授予对 SQL Server 的访问权限。

创建一个新数据库用户，并将登录名映射到数据库用户

这将授予对指定数据库的访问权限。

在该数据库内建一个新的用户定义的数据库角色，并将数据库用户置于该角色内

 

建立该数据库角色的数据库权限

授予最少的权限。
有关详细信息，请参见第 12 章数据访问安全性。

配置安全通信

步骤更多信息

配置 Web 站点的 SSL

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

配置应用程序服务器和数据库服务器之间的 IPSec

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

分析

•

窗体身份验证是这种方案下的理想验证方法，因为用户没有 Windows 帐户。“窗体”登录页用于获取用户凭据。凭据验证必须由应用程序代码执行。可以使用任何数据存储。SQL Server 数据库是最常用的解决方案，尽管 Active Directory 也提供了一种备用凭据存储。

•

在窗体身份验证中，必须使用 SSL 保护初始登录凭据。还必须保护窗体身份验证票证（它在已进行身份验证的客户端的后续 Web 请求中作为 Cookie 传递）。可以对所有页面使用 SSL 以保护该票证，也可以将 <forms> 元素的 protection 属性配置为 All 或 Encrypt 以对窗体身份验证票证进行加密，以及使用 FormsAuthentication 类的 Encrypt 方法对该票证进行加密。
protection="All" 属性指定，当应用程序调用 FormsAuthentication.Encrypt 时，应该验证（检查完整性）并加密票证。当您创建身份验证票证时，通常在该应用程序的“登录”按钮事件处理程序中调用此方法。

string encryptedTicket = FormsAuthentication.Encrypt(authTicket);

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

•

ASP.NET 作为权限最少的本地 ASPNET 帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。

•

Web 服务器上的 URL 授权使得未经身份验证的用户能够浏览不受限制的 Web 页，并对受限页面强制进行身份验证。

•

由于没有启用模拟，所以基于 Web 的应用程序所执行的任何本地或远程资源访问均通过 ASPNET 帐户安全性上下文执行。应该相应地设置安全资源的 Windows ACL。

•

根据自定义 SQL Server 数据库进行用户凭据验证。密码哈希值（带有 salt）存储在数据库内。有关详细信息，请参见第 12 章数据访问安全性中的为数据库验证用户身份。

•

通过对 SQL Server 使用 Windows 身份验证，可以避免将凭据存储在 Web 服务器上的文件中，也可以避免通过网络传递它们。

•

如果应用程序当前使用 SQL 身份验证，则必须安全地存储数据库连接字符串，因为它包含用户名和密码。请考虑使用 DPAPI。有关详细信息，请参见第 12 章数据访问安全性中的安全存储数据库连接字符串。

•

在数据库服务器上使用重复的 Windows 帐户（一个与 ASP.NET 进程帐户匹配的帐户）会导致加重管理负担。如果一台计算机上的密码发生更改，则必须在所有计算机上同步并更新它。在某些方案中，您可能能够使用权限最少的域帐户进行更简单的管理。

•

Web 服务器和数据库服务器之间的 IPSec 确保传递到和来自数据库的数据的保密性。

•

浏览器和 Web 服务器之间的 SSL 保护凭据以及其他机密数据，如信用卡号码。

•

如果您使用 Web 场，则确保在场中的所有服务器中将加密密钥保持一致（例如，用于加密窗体身份验证票证的加密密钥以及 Machine.config 中 <machineKey> 元素所指定的加密密钥）。有关在 Web 场方案中使用 ASP.NET 的详细信息，请参见第 8 章 ASP.NET 安全性。

缺陷

应用程序必须将原调用方的标识传送到数据库以支持审核要求。调用方标识可以使用存储过程参数传递。

相关方案

根据 Active Directory 进行窗体身份验证

从“窗体”登录页接受的用户凭据可以根据各种存储进行身份验证。Active Directory 是使用 SQL Server 数据库的一种替代方法。

更多信息

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

用于授权的 .NET 角色

前一个方案没有考虑访问应用程序的不同用户类型。例如，门户服务器可能具有不同的订阅级别，如标准、高级和企业。

如果在用户存储（SQL Server 数据库）中保存角色信息，则应用程序可以创建一个 GenericPrincipal 对象来存储角色和标识信息。在创建 GenericPrincipal 并将其添加到 Web 请求上下文（使用 HttpContext.User）后，可以将编程角色检查添加到方法代码中，也可以使用 PrincipalPermission 属性修饰方法和页以请求角色成员身份。

更多信息

•

有关创建包含角色列表的 GenericPrincipal 对象的详细信息，请参见本指南中的如何利用窗体身份验证创建 GenericPrincipal 对象。

•

有关 PrincipalPermission 请求和编程角色检查的详细信息，请参见第 8 章 ASP.NET 安全性。

在 Web 服务器上使用域匿名帐户

在这个经过修改的方案中，将默认的匿名 Internet 用户帐户（名为 IUSR_MACHINE 的本地帐户）替换为域帐户。给此域帐户配置运行应用程序所需的最少权限（开始时没有配置权限，然后逐渐增加权限）。如果您拥有多个基于 Web 的应用程序，则可以使用不同的域帐户（每个基于 Web 的应用程序或虚拟目录使用一个帐户）。

为了将匿名域帐户的安全性上下文从 IIS 传递到 ASP.NET，请使用下面的 web.config 文件设置对基于 Web 的应用程序启用模拟 

<identity impersonate="true" />

如果基于 Web 的应用程序与远程资源（如数据库）进行通信，则必须给域帐户授予访问此资源所需的权限。例如，如果应用程序访问远程文件系统，则必须相应地配置 ACL 以便（至少）给域帐户授予读访问权限。如果应用程序访问 SQL Server 数据库，则必须使用 SQL 登录将域帐户映射到数据库登录。

由于在应用程序中传递的安全性上下文是匿名帐户的安全性上下文，因此必须在应用程序级别的各层之间传递原调用方的标识（通过窗体身份验证捕获）；例如通过方法和存储过程参数。

更多信息

•

有关此方法的详细信息，请参见第 8 章 ASP.NET 安全性的访问网络资源一节中的“使用匿名 Internet 用户帐户”。

•

在实现此方案之前，请参见 Microsoft 知识库文章 Q259353 Must Enter Password Manually After You Set Password Synchronization（在设置密码同步后必须手动输入密码）。

返回页首返回页首

ASP.NET 到远程企业服务到 SQL Server

在此方案中，运行 ASP.NET 页的 Web 服务器安全地连接到服务组件，这些组件位于远程应用程序服务器上（后者又连接到 SQL Server 数据库上）。与许多 Internet 应用程序基础结构相同，Web 服务器和应用程序服务器也被防火墙隔开（并且 Web 服务器位于周边网络中）。服务组件安全地连接到 SQL Server。

例如，请看一个为用户提供机密数据（如私人财务明细）的 Internet 银行交易应用程序。必须保证从客户端到数据库的所有银行交易的安全，并且数据的完整性至关重要。不仅需要保护与用户之间的通信，而且还需要保护与数据库之间的通信。图 7.3 中显示了这种情况。

ASP.NET 到远程企业服务到 SQL Server Internet 方案

图 7.3
ASP.NET 到远程企业服务到 SQL Server Internet 方案

特点

•

用户有许多不同的浏览器类型。

•

匿名用户可以浏览该应用程序的不受限制的页面。

•

用户必须注册或登录（通过 HTML 窗体）后才有权限查看受限页面。

•

基于 Web 的前端应用程序位于周边网络中，并使用防火墙将它与 Internet 和公司内部网络（以及应用程序服务器）隔开。

•

应用程序要求强大的安全性、高度的可伸缩性和详细的审核。

•

基于 Web 的应用程序使用 SOAP 连接到 Web 服务层，此服务层提供到服务组件（在应用程序服务器上的企业服务应用程序中运行）的接口。由于防火墙的限制，应首选 SOAP 而不是 DCOM。

•

SQL Server 使用单个用户定义的数据库角色进行授权。

•

数据是机密的，并且必须确保网络上和所有永久性数据存储中的完整性和保密性。

•

使用企业服务 (COM+) 事务强制实施数据完整性。

保护方案

在此方案中，Web 服务接受来自窗体登录页的凭据，然后根据 SQL Server 数据库对调用方进行身份验证。登录页使用 SSL 保护在 Internet 上传递的用户凭据。

基于 Web 的应用程序与 Web 服务进行通信，Web 服务提供与服务组件中实现的业务服务的接口。Web 服务信任基于 Web 的应用程序（在周边网络中），并对 ASP.NET 进程标识进行身份验证。使用方法和存储过程参数在应用程序级别的各层之间传递用户标识。此信息用于在各层中审核用户的操作。

表 7.2： 安全措施

类别明细

身份验证

•

在 Web 服务器上提供增强身份验证。

•

在数据库中对企业服务应用程序标识进行身份验证。

•

将 IIS 配置为使用匿名访问，并且基于 Web 的应用程序使用窗体身份验证对用户进行身份验证（根据 SQL Server 数据库）。

•

将 Web 服务的虚拟目录配置为使用集成 Windows 身份验证。Web 服务对基于 Web 的应用程序的进程标识进行身份验证。

•

使用 Windows 身份验证连接到数据库。数据库对运行企业服务应用程序使用的权限最少的 Windows 帐户进行身份验证。

授权

•

使用受信任的子系统模型，并且只在 Web 应用程序中对每个用户进行授权。

•

使用 URL 授权控制用户对 Web 服务器上页面的访问。

•

ASP.NET 进程帐户被授权访问 Web 服务器上的系统资源。这些资源是使用 ACL 保护的。

•

数据库中的权限是由用户定义的角色控制的。企业服务应用程序标识是角色的成员。

•

给企业服务进程帐户授予访问应用程序服务器上系统资源的权限。这些资源是使用 ACL 保护的。

安全通信

•

使用 SSL 保护在用户和基于 Web 的应用程序之间传送的机密数据。

•

使用 SSL 保护在 Web 服务器和 Web 服务之间传送的机密数据。

•

使用 IPSec 保护在服务组件和数据库之间传送的机密数据。

结果

图 7.4 显示了此方案的建议安全配置。

ASP.NET 到远程企业服务到 SQL Server Internet 方案的建议安全配置

图 7.4
ASP.NET 到远程企业服务到 SQL Server Internet 方案的建议安全配置

安全配置步骤

在开始之前，您需要查看以下内容：

•

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

•

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

•

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

•

配置企业服务安全性（请参见本指南中的如何将基于角色的安全性用于企业服务）

配置 Web 服务器

配置 IIS
步骤更多信息

启用对基于 Web 的应用程序的虚拟根目录的匿名访问

 

配置 ASP.NET
步骤更多信息

将 ASPNET 帐户的密码（用于运行 ASP.NET）重置为一个已知的强密码

这样，您就可以在该数据库服务器上创建一个重复的本地帐户（具有相同的用户名和密码）。这是 ASPNET 帐户所必需的，这样该帐户在使用 Windows 身份验证进行连接时，才能响应来自数据库服务器网络身份验证的质询。

另一种方法是使用权限最少的域帐户（如果允许 Windows 身份验证通过防火墙）。

有关详细信息，请参见第 8 章 ASP.NET 安全性中的 ASP.NET 的进程标识。

编辑位于 %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG 中的 Machine.config

在 <processModel> 元素上设置自定义帐户的用户名和密码属性

默认

<!-- userName="machine" password="AutoGenerate" 
-->

成为

<!--
userName="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,userName" 
password="registry:HKLM\SOFTWARE\YourSecureApp\
processModel\ASPNET_SETREG,password" -->

注意，已经使用 aspnet_setreg.exe 实用程序将加密的密码存储在注册表中。

将 ASP.NET Web 应用程序配置为使用窗体身份验证（使用 SSL）

编辑应用程序的虚拟根目录下的 Web.config，将 <authentication> 元素设置为：

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

有关根据 SQL Server 数据库使用窗体身份验证的详细信息，请参见本指南中的如何将窗体身份验证用于 SQL Server 2000。

配置应用程序服务器

配置 IIS
步骤更多信息

禁用匿名访问

 

配置集成 Windows 身份验证

IIS 对 Web 服务器上来自基于 Web 的应用程序的 ASP.NET 进程标识进行身份验证。

配置 ASP.NET
步骤更多信息

使用 Windows 身份验证

编辑 Web 服务的虚拟根目录下的 Web.config。将 <authentication> 元素设置为：

<authentication mode="Windows" />
配置企业服务
步骤更多信息

创建一个权限最少的自定义帐户以运行企业服务服务器应用程序

注意：如果使用的是本地帐户，则还必须在数据库服务器计算机上创建一个重复的帐户。

配置企业服务应用程序以使用自定义帐户

请参见第 9 章企业服务安全性中的配置安全性。

启用基于角色的访问检查

请参见第 9 章企业服务安全性中的配置安全性。

将单个企业服务 (COM+) 角色添加到被调用的应用程序（例如，受信任的 Web 服务）中

完全最终用户授权是由基于 Web 的应用程序执行的。Web 服务（以及服务组件）只允许访问受信任的 Web 服务角色的成员。

将本地 ASPNET 帐户添加到受信任的 Web 服务角色中

请参见第 9 章企业服务安全性中的配置安全性。

配置 SQL Server

步骤更多信息

在 SQL Server 计算机上创建一个与企业服务应用程序帐户匹配的 Windows 帐户

用户名和密码必须匹配自定义企业服务帐户。

配置 SQL Server 以便进行 Windows 身份验证

 

为自定义企业服务帐户创建一个 SQL Server 登录

这将授予对 SQL Server 的访问权限。

创建一个新数据库用户，并将登录名映射到数据库用户

这将授予对指定数据库的访问权限。

创建一个新的用户定义的数据库角色，并将数据库用户添加到该角色

 

建立该数据库角色的数据库权限

授予最少的权限。有关详细信息，请参见第 12 章数据访问安全性。

配置安全通信

步骤更多信息

配置 Web 站点的 SSL

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

在 Web 服务器和应用程序服务器之间配置 SSL。

请参见本指南中的如何使用 SSL 调用 Web 服务。

配置应用程序服务器和数据库服务器之间的 IPSec

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

分析

•

窗体身份验证是这种方案下的理想验证方法，因为用户没有 Windows 帐户。“窗体”登录页用于获取用户凭据。凭据验证必须由应用程序代码执行。可以使用任何数据存储。SQL Server 数据库是最常用的解决方案，尽管 Active Directory 也提供了一种备用凭据存储。

•

基于 Web 的应用程序作为权限最少的本地 ASPNET 帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。

•

Web 服务器上的 URL 授权使得未经身份验证的用户能够浏览不受限制的 Web 页，并对受限页面强制进行身份验证。

•

由于没有启用模拟，所以基于 Web 的应用程序所执行的任何本地或远程资源访问均通过 ASPNET 帐户安全性上下文执行。应该相应地配置 ACL。

•

根据自定义 SQL Server 数据库进行用户凭据验证。密码哈希值（带有 salt）存储在数据库内。有关详细信息，请参见第 12 章数据访问安全性中的为数据库验证用户身份。

•

对 SQL Server 使用 Windows 身份验证意味着，可以避免将凭据存储在应用程序服务器上的文件中，也可以避免通过网络传递它们。

•

在数据库服务器上使用重复的 Windows 帐户（一个与企业服务进程帐户匹配的帐户）会导致增大管理负担。如果一台计算机上的密码发生更改，则必须在所有计算机上同步并更新它。在某些方案中，您可能能够使用权限最少的域帐户进行更简单的管理。

•

当 Web 应用程序调用 Web 服务时，它必须使用 DefaultCredentials（即，ASP.NET 进程帐户 ASPNET）来配置 Web 服务代理。

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

有关详细信息，请参见第 10 章 Web 服务安全性”中的将身份验证的凭据传递给 Web 服务。

•

Web 服务器和 Web 服务层（在应用程序服务器上服务组件的前面）之间的 SSL 确保在两个服务器之间传送的数据的保密性。

•

将企业服务应用程序配置为保证应用程序级别的基于角色的安全性。此配置只允许本地 ASPNET 帐户（用于运行 Web 服务）访问服务组件。

•

应用程序服务器和数据库服务器之间的 IPSec 确保往来于数据库的数据的保密性。

•

浏览器和 Web 服务器之间的 SSL 保护凭据和银行帐户明细。

缺陷

应用程序必须将原调用方的标识传送到数据库以支持审核要求。调用方标识可以使用存储过程参数传递。

相关方案

根据 Active Directory 进行窗体身份验证

从“窗体”登录页接受的用户凭据可以根据各种存储进行身份验证。Active Directory 是使用 SQL Server 数据库的一种替代方法。

更多信息

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

使用 DCOM

借助于 Windows 2000（带有 QFE 18.1 的 SP3 或 SP2）或 Windows .NET Server，您可以配置企业服务应用程序以使用静态终结点。如果防火墙将客户端与服务器隔开，这意味着您只需要打开防火墙中的两个端口。具体而言，您必须为 RPC 打开端口 135，并为企业服务应用程序打开一个端口。

由于 DCOM 的这一增强功能，可以选择它作为 Web 服务器和应用程序服务器之间的正确通信协议，并消除了对 Web 服务层的需要。

重要说明：如果应用程序要求在两台服务器之间传递分布式事务，则必须使用 DCOM。不能通过 SOAP 传递事务。在 SOAP 方案中，必须由应用程序服务器上的服务组件启动事务。

更多信息

有关详细信息，请参见第 9 章企业服务安全性。

使用 .NET Remoting

当您不需要企业服务所提供的服务（如事务、队列组件和对象池等）时，则可以选择远程处理。.NET Remoting 解决方案还支持中间层的网络负载平衡功能。在使用 .NET Remoting 时，请注意以下几点：

•

要获得最佳的性能，请在 Windows 服务中使用 TCP 通道和主机。请注意，此通道默认情况下不提供身份验证和授权机制。TCP 通道用于受信任的子系统方案。您可以使用 IPSec 策略建立安全的通道，并确保只有 Web 服务器与应用程序服务器进行通信。

•

如果需要使用 IPrincipal 对象进行身份验证和授权检查，则应该在 ASP.NET 中驻留远程对象并使用 HTTP 通道。这样，您就可以使用 IIS 和 ASP.NET 安全功能了。

•

远程对象可以使用 Windows 身份验证连接到数据库，并且可以使用主机进程标识（ASP.NET 或 Windows 服务标识）。

更多信息

有关 .NET Remoting 安全性的详细信息，请参见第 11 章 .NET Remoting 安全性。

返回页首返回页首

总结

本章介绍如何保护一套常见 Internet 应用程序方案的安全。

有关 Intranet 和 Extranet 应用程序方案，请参见第 5 章 Intranet 安全性和第 6 章 Extranet 安全性。


返回页首返回页首