其他资源
除了上面的概述中介绍的内容外，还有许多其他内容可供选择。以下主题更详细地讨论了代码访问安全性：

Introduction to Code Access Security（英文）
Code Access Security（英文）
Security Namespaces in Visual Studio（英文）
Web 应用程序
解决 Web 应用程序的安全问题，可以保护您的服务器免受恶意代码的攻击，并保护数据不被破坏。您可以使用多种方法来保护服务器。

通过禁用 XML Web services 的动态发现功能来禁止用户查找和运行您的 XML Web services。
在允许用户访问服务器之前，通过身份验证来验证用户的标识。
通过使用 ASPNET 进程标识，可以更好地调整用户可以使用的资源。
下面将详细讨论每一种方法。

动态发现
动态发现是 .NET 框架的一项功能，它允许 Web 浏览器查找在服务器上运行的 XML Web services。找到 XML Web service 后，用户就可以调用该 XML Web services 的方法。动态发现虽然为用户提供了强大的功能，但同时也给服务器带来潜在的安全危险。多数情况下，您不需要启用动态发现功能。安装 .NET 框架时，动态发现在默认情况下处于禁用状态。这并不表示 XML Web services 不可用，而只表示服务器将不提供可用服务的目录。客户端仍然可以使用 XML Web services，但您需要向其提供该服务的确切位置。

警告：禁用动态发现后，您需要将 XML Web services 的位置发送给客户端。
在部署服务器上，有两个项可以控制 XML Web services 的发现功能。第一项（machine.config 文件）控制服务器的整体发现功能。machine.config 文件是一个包含控制服务器上 Web 应用程序的设置的 XML 文件，它位于 \%windows%\Microsoft.NET\Framework\Version\Config 文件夹。此文件包含一个默认情况下被注释掉的元素。要启用发现功能，您需要删除这些注释字符。还需要使用 ASPNET 帐户来运行应用程序，如下一节“ASPNET 进程标识”中所述。

<!--<add verb="*" path="*.vsdisco"
type="System.Web.Services.Discovery.DiscoveryRequestHandler,
System.Web.Services, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>-->
第二项是一个发现文件。发现文件可以是默认的发现文件 (default.vsdisco)，也可以是 XML Web services 特定的发现文件。它是一个 XML 文件，包含有关 XML Web services 文件位置的信息。

要客户端能够发现特定的 XML Web services，您需要在 machine.config 文件中启用发现功能，并创建和部署应用程序的发现文件。发现文件是一个仅列出不包含 XML Web services 的路径的 XML 文件。下面提供了一个示例。有关创建和部署此文件的完整说明，请参阅 Deploying XML Web Services in Managed Code（英文）。

<?xml version="1.0" encoding="utf-8" ?>
<dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17">
 <exclude path="_vti_cnf" />
 <exclude path="_vti_pvt" />
 <exclude path="_vti_log" />
 <exclude path="_vti_script" />
 <exclude path="_vti_txt" />
 <exclude path="Web References" />
</dynamicDiscovery>
如果您的部署服务器安装有 Visual Studio .NET，则 Web 根文件夹将包含默认的发现文件 (default.vsdisco)，该文件是在 Visual Studio .NET 的安装过程中创建的。如果服务器中包含此文件并且在 machine.config 文件中启用了发现功能，则可以发现服务器上的所有 XML Web services。如果要禁止发现 XML Web services，则需要删除此文件。

警告：如果部署服务器安装了 Visual Studio .NET，则在服务器投入使用之前应该删除 default.vsdisco 文件。
建议您不要在已安装 Visual Studio .NET 的服务器上部署 XML Web services。Visual Studio .NET 安装程序会将可以使用的文件和用户都添加到您的系统上。您可以保护已安装 Visual Studio .NET 的系统的安全，但是，如果不需要在部署服务器上安装 Visual Studio .NET，建议您不要安装。
有关启用动态发现的详细信息，请参阅 Enabling Discovery for an XML Web services（英文）和 Fine-Tuning Discovery Mechanisms（英文）。

身份验证、模拟和委托
默认情况下，Web 应用程序将以匿名模式运行，也就是说，应用程序不需要任何有关用户标识的信息。这对于那些包含公共信息的站点非常适用。如果要对访问应用程序或其他资源的用户进行控制，则需要向应用程序添加身份验证。身份验证是识别应用程序的用户并验证该用户是否有权访问此应用程序的过程。ASP.NET 支持多种身份验证方法。其中最常用的方法有：

匿名 无需用户提供任何标识信息。此方法适用于包含公共内容的 Web 站点。如果需要个性化站点，则可以使用 cookie。有关在 ASP.NET 应用程序中使用 cookie 的详细信息，请参阅 Introduction to Web Forms State Management（英文）。
窗体 应用程序向用户提供一个登录窗体，要求用户提供登录信息（如姓名和密码）。窗体将被发送回服务器，服务器将该信息与数据仓库进行比较。
基本 基本身份验证是使用 Internet 信息服务 (IIS) 配置的，大部分浏览器都支持基本身份验证。如果启用，浏览器将提示用户输入姓名和密码，然后用 Base64 编码（此编码易于解密）将信息传回 ASP.NET 应用程序。此方法要求用户拥有 Windows 帐户。如果在基本身份验证之外再使用安全套接字层 (SSL)，则可以确保此身份验证方法的安全性。有关 ASP.NET 中的 SSL 支持的信息，请参阅 Using Secure Sockets Layer（英文）。
简要 简要身份验证是使用 IIS 配置的，可用于运行 Microsoft Windows® 2000 或 Windows XP 的服务器。简要身份验证提供了比基本身份验证更高的密码加密级别。此方法要求用户拥有存储在 Microsoft Active Directory® 中的 Windows 帐户。
集成 Windows 集成 Windows 身份验证类似于基本身份验证和简要身份验证，唯一区别是用户的姓名和密码不传回 Web 应用程序。此方法尤其适用于 Intranet 环境。它要求用户拥有 Windows 帐户，并且只有 Internet Explorer 浏览器支持该方法。
证书 证书是安装在计算机中的数字密钥。当用户试图访问服务器时，需要提供此密钥。然后服务器在域或 Active Directory 中对该证书进行验证。此方法适用于那些需要高度安全性而不惜付出管理证书成本的应用程序。
Passport Microsoft 提供了这种集中的身份验证服务。Passport 身份验证适用于以下情况：当您的 Web 站点与其他 Passport 站点一起使用时，使用户只需登录一次就能够访问所有站点；或者您不想维护用户数据库。
身份验证允许您为应用程序的用户授权，但这并不足以使用户能够访问资源，例如文件和数据库。您可以对资源进行配置，使其对特定的用户（而不是 Web 应用程序本身）可用。在这种情况下，可以使用模拟来允许用户访问这些资源。使用模拟时，服务器进程以通过身份验证的用户标识来运行。当应用程序使用模拟并查询数据库时，数据库应用程序在处理查询时会认为查询来自用户，而不是服务器。如下例所示，可以通过在应用程序的 Web.config 文件中设置 identity 元素的 impersonate 属性来启用模拟。Web.config 文件作为每个 Web 应用程序项目的一部分而创建。

<identity impersonate="true">
比模拟更进一步的是委托，委托在访问远程资源（其他计算机）时使用用户标识。如下表所示，并非所有的身份验证方法都支持委托。

支持委托 不支持委托
基本 匿名
集成 Windows 简要
证书 Passport
窗体

有关选择和实施身份验证方法的详细论述，请参阅 Authentication in ASP.NET:.NET Security Guidance（英文）。有关 Web 应用程序安全性的详细信息，请参阅 Web Application Security at Run Time（英文）。

ASPNET 进程标识
当 Web 应用程序开始在服务器上运行时，它并不是像以您（Web 应用程序的作者）的身份登录那样运行。而是像使用服务器上定义的一个 Windows 用户帐户登录那样运行。该帐户（也称作标识）可以是以下三个帐户之一：ASPNET 标识、SYSTEM 标识或自定义标识。该标识是在 machine.config XML 文件（位于服务器的 \%windows%\Microsoft.NET\Framework\Version\Config 文件夹中）中指定的。以下所示是该元素三种配置方法的简化示例。文件中的元素具有若干个属性，此示例中并未显示出来。

<!-- 选择 ASPNET 标识 -->
<system.web>
<processModel enable="true" username="MACHINE" password="AutoGenerate"/>
</system.web>

<!-- 选择 SYSTEM 标识 -->
<system.web>
<processModel enable="true" username="SYSTEM" password="AutoGenerate"/>
</system.web>

<!-- 选择自定义标识 -->
<system.web>
<processModel enable="true" username="domain\user" password="pwd"/>
</system.web>
ASPNET 是在随 .NET 框架安装 machine.config 文件时所选择的默认标识。ASPNET 帐户是 Users 组的成员，默认情况下，Users 组只拥有最小的权限。ASPNET 帐户还拥有其他几个权限，其中包括对 ASP.NET 和 Windows 临时目录的全部权限。

如果将标识更改为 SYSTEM，则应用程序将在 SYSTEM 标识下运行，该标识拥有 Administrators 组的权限。SYSTEM 帐户几乎可以访问服务器上的所有资源。

警告：如果服务器在 SYSTEM 标识下运行，受恶意代码攻击和数据遭到破坏的危险非常大。
要使用自定义标识，必须创建帐户并按特定方式配置其权限。有关创建自定义标识的详细信息，请参阅 Authentication in ASP.NET:.NET Security Guidelines（英文）。

默认情况下，有几种系统资源对 ASPNET 帐户不可用。下面概要介绍了常见的限制和解决方案。建议您使用 ASPNET 帐户和所介绍的解决方案，而不要在 SYSTEM 标识下运行应用程序。

文件资源 可以通过 Windows 资源管理器访问各个文件和文件夹的访问控制列表 (ACL)，来调整授予 ASPNET 帐户的文件和文件夹权限。对 ASPNET 的 ACL 的更改不会自动通过部署传播。例如，您可能允许 ASPNET 帐户对开发计算机上的 c:\picture.bmp 文件拥有写入权限。当部署应用程序时，应用程序将在另一台计算机上运行，该计算机也具有 ASPNET 帐户。您需要在部署计算机上为 ASPNET 帐户添加对部署计算机上 c:\picture.bmp 文件的写入权限。幸运的是，您可以在部署项目中使用自定义操作对 ACL 进行更改，但必须对所要做的更改进行跟踪。
事件日志 ASPNET 帐户可以向现有日志添加条目，但不能创建新的事件日志类别。这时您可以在使用 ASPNET 帐户时启用模拟，以便创建新的事件日志类别。模拟标识必须具有足够的权限才能创建事件日志类别。如果应用程序需要的事件日志可以在投入使用前指定，则可以由部署项目来创建这些日志。
目录服务和 Active Directory 要对它们进行访问，需要使用模拟和委托，或者将特定的安全凭据传递给 DirectoryEntry 对象。如果选择将特定安全凭据传递给 DirectoryEntry 对象，则需要确保已正确存储此信息。
性能计数器 ASPNET 帐户只能写入而不能读取性能计数器，并且不能创建新的性能计数器类别。这时您可以在使用 ASPNET 帐户时启用模拟，以便创建新的性能计数器类别。模拟标识必须具有足够的权限才能创建性能计数器类别。如果应用程序需要的性能计数器可以在投入使用前指定，则可以由部署项目来创建这些性能计数器。
在 ASPNET 标识下运行时保护文件资源的安全
注意：本节中的说明适用于运行 NTFS 文件系统的系统。如果您的服务器运行的是 FAT32 文件系统，请参阅文件系统说明文件，了解有关保护文件安全的信息。
默认情况下，ASPNET 帐户只拥有 Users 组的读取和执行权限。如果 Web 应用程序需要写入或创建新文件，则可以通过修改访问控制列表 (ACL) 为特定文件和文件夹授权。要访问某个文件的 ACL，可以在 Windows 资源管理器中右击该文件，然后依次选择“属性”和“安全”选项卡。最好是修改特定文件的 ACL，而不是向 ASPNET 帐户添加通用权限。最常使用的权限包括：

读取 - 数据文件和可执行文件需要读取权限。
写入 - 由应用程序更新的数据文件需要写入权限。
执行 - 在 Web 应用程序中，.asmx 文件为可执行文件。
创建 - 要创建文件，需要为要在其中创建文件的文件夹添加创建权限。
这些权限适用于：

文件
文件夹
警告：应避免允许对同一文件或目录同时拥有执行权限和写入或创建权限。在这种情况下，用户可能会设法在文件中写入恶意代码，然后再执行。
以下是有关简化授权过程的一些技巧：

根据应用程序中文件所需的权限，将文件分别放入不同的目录。例如，如果在一个目录中只存放读取/执行文件，则只需要为一个目录设置这些权限，而不必单独为每个文件设置权限。请考虑在应用程序中为读取/执行、读取/写入和读取/创建权限分别创建目录。
应用程序可以包含在部署时为空的数据文件，还可以包含首次运行应用程序时创建文件所需的代码。这需要为目录添加创建权限，这是一种较高的安全设置。为了避免添加代码来创建新的空文件，请考虑在部署时即给应用程序提供一个空文件。这样，您只需给该文件添加写入权限，而不必给目录添加创建权限。
在开发应用程序时，您将为开发计算机上的文件和目录添加权限，以便精确调整应用程序的安全级别。不幸的是，ACL 不会被传递到部署计算机上的相应文件。要规划传递这些 ACL，请记住以下几点：

可以在部署程序包中使用自定义操作来更改 ACL。有关详细信息，请参阅 Custom Actions（英文）。
可以使用第三方工具来跟踪和查找所做的更改。
可能需要同系统管理员确认每一个设置。您需要记录进行更改的原因，以及为什么必须通过更改设置来达到目的。
使用 ASPNET 标识进行调试
调试 XML Web services 时，如果在 machine.config 文件中定义了 ASPNET 标识，将使用该标识来调用此 XML Web services。默认情况下，ASPNET 标识不是 Debugger Users 组的成员（请参见下一节“Visual Studio .NET 开发环境中的安全机制”），因此不能在调试过程中访问 XML Web services 代码。要调试 XML Web services，请打开 XML Web services 的代码并设置一个断点。

建议您在测试计算机（而不是部署计算机）上进行调试。这将在下一节“Visual Studio .NET 开发环境中的安全机制”中讨论。

有关配置进程标识的详细信息，请参阅 ASP.NET Process Identity（英文）和 ASP.NET Impersonation（英文）。

Visual Studio .NET 开发环境中的安全机制
除了保护服务器的安全外，还要保护开发计算机免受恶意代码的攻击和数据破坏。您可以利用开发环境中的多种机制来保护开发服务器的安全：

VS Developers 和 Debuggers 安装 Visual Studio .NET 时将添加这两个帐户组。VS Developers 组具有在服务器上创建和开发 Web 应用程序的必要文件、共享和 IIS 权限。Debuggers 组可以在特定计算机（本地或远程）上调试进程。这两个组都是服务器上具有很大权限的用户，可以访问大多数资源。有关详细信息，请参阅 Web Application Security at Design Time in Visual Studio（英文）。

调试 建议您在测试计算机（而不是部署计算机）上进行调试。如果必须在部署服务器上调试，请仅安装远程调试组件，并在完成调试后卸载该组件。请在脱机状态下调试服务器。有关详细信息，请参阅 Introduction to Web Application Debugging（英文）。

部署 对于大多数应用程序，只需要在服务器上安装 .NET 框架就足够了。如果在部署计算机上安装了 Visual Studio .NET 或 Visual Studio .NET 服务器组件，则 VS Developers 组和 Debuggers 组都将出现在部署计算机上。您需要对 VS Developers 的成员和 Debugger 用户加以限制。此外，可能还需要禁用动态发现。

警告：强烈建议您不要在部署服务器上安装 Visual Studio。
Visual Studio .NET 的“复制项目”功能包括使用配置文件 (Web.config) 部署应用程序的选项，该配置文件不同于开发中所使用的配置文件。开发文件可能启用了调试，在部署后，将允许用户在引发异常时检查调用堆栈。建议您使用不允许调试的配置文件进行部署。

总结
保护资源的安全是一个涉及多种技术和整个开发周期的过程。通过对应用程序进行周密的设计、实现、测试和部署，您可以创建非常安全的应用程序。可以使用由 ASP.NET、操作系统和 Web 浏览器提供的安全技术来保护应用程序的安全。