Microsoft Corporation
内容简介

基于 Intranet Web 应用程序的安全性并不是不重要，因为它存在于许多控制网络中，并且对一个限制集合中的用户是可以访问的。不同个体和部门可能需要对应用程序提供的功能和数据有不同的访问等级，所以在传输过程中仍然必须保护机密数据的安全性。为了使问题复杂化，应用程序的安全性结构必须补偿任何安全性相关的问题，这些问题源于存在的基础和要配置应用程序的 Intranet 的操作特点。

通过关注某些常用分布式应用程序结构的要求，本章介绍了基于 Intranet Web 应用程序的身份验证、授权、安全通信的推荐解决方法。

目标

使用本章的目的：

• 保护 Intranet .NET 应用程序

• 理解安全问题和下面方案中推荐的与使用 ASP.NET Web 应用程序和 SQL Server 2000通信相关的解决方案：

• 直接通信

• 使用 Enterprise Services 作为中介

• 使用 Web 服务作为中介

• 使用 .NET Remoting 作为中介


• 在基于 Intranet 分布式 Web 应用程序中决定实现身份验证、授权、安全通信的最好方法。


适用于：

本章适用于下面的产品和技术：

• Microsoft Windows_ XP 或者 Windows 2000 Server (带有 service pack 3) 和更高版本操作系统

• Microsoft Internet Information Services (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 的经验。

• 您必须有配置 Enterprise Services (COM+) 应用程序的经验。

• 请参阅本指南中的“构建安全 ASP.NET 应用程序介绍”。这部分定义了分布式 Web 应用程序身份验证、授权、安全通信的重要性。

• 请参阅本指南中的“ASP.NET 应用程序安全性模型”。这部分概括阐述在创建分布式 ASP.NET Web 应用程序中使用的结构和技术，并强调身份验证、授权、安全通信适合本结构中的哪些部分。

• 结合下面的章节使用本章，它们阐明了本章中讨论的技术：

• “How To Create a Custom Account to Run ASP.NET”。

• “How To Implement Kerberos Delegation for Windows 2000”。

• “How To Create a DPAPI Library”。

• “How To Use DPAPI (Machine Store) from ASP.NET”。

• “How To Use DPAPI (User Store) from ASP.NET with Enterprise Services”。

• “How To Use Role-based Security with Enterprise Services”。

• “How To Set Up SSL on a Web Server”。

• “How To Use IPSec to Provide Secure Communication Between Two Servers”。

• “How To Use SSL to Secure Communication with SQL Server 2000”。





本页内容
预备知识
ASP.NET 到 SQL Server
ASP.NET 到 Enterprise Services 到 SQL Server
ASP.NET 到 Web Services 到 SQL Server
ASP.NET 到 Remoting 到 SQL Server
将原调用方传递到数据库
小结

预备知识
对 Intranet 应用程序的访问被限制到一组有限的授权用户（例如，属于某个域的雇员）。虽然 Intranet 设置限制了应用程序的公开，但是当您制定身份验证、授权和安全通信策略时，可能仍要面临一些难题。例如，您可能包含非信任域，因此很难将调用方的安全性上下文和标识传递到系统内的后端资源。另外，您的运行环境可能是具有混合浏览器类型的异类环境。因此，更加不便使用通用身份验证机制。

如果同类 Intranet 中的所有计算机均运行 Microsoft Windows 2000 或更高版本的操作系统，并且在域中信任用户使用委派，则可以选择将原调用方的安全性上下文委派到后端。

您还必须考虑安全通信问题。尽管您的应用程序运行在 Intranet 环境中，也不能认为在网络中传送的数据是安全的。除了需要保护应用程序服务器和数据库之间传送的数据外，可能还需要保护浏览器和 Web 服务器之间传送的数据。

本章使用以下常见的 Intranet 方案来阐释主要的身份验证、授权和安全通信技术：

• ASP.NET 到 SQL Server

• ASP.NET 到 Enterprise Services 到 SQL Server

• ASP.NET 到 Web Services到SQL Server

• ASP.NET到Remoting到SQL Server


此外，本章还介绍了一个 Windows 2000 委派方案（“将原调用方传递到数据库”）。在此方案中，使用中间 Web 服务器和应用程序服务器，在操作系统级别将原调用方的安全性上下文和标识从浏览器传递到数据库。

注本章中描述的几个方案或者替换用于运行 ASP.NET 应用程序的默认 ASPNET 帐户，或者更改其密码以允许在远程计算机上创建重复的帐户。这些方案要求更新 Machine.config 中的 <processModel> 元素。<processModel> 凭据不应该以明文形式存储在 machine.config 中。而应该使用 ASPnet_setreg.exe 工具以加密凭据的形式存储在注册表中。有关详细信息请参见本指南中的“ASP.NET安全性”和 Microsoft 知识库文章 Q329290 “HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings”（如何做：