大中型企业有相当大部分都在使用Windows Server以及.Net架构来构建企业Web服务和应用，因此Web服务和Web应用程序通常被ASP.NET和IIS主管。保护Web服务和Web应 用程序是一个配置环境的问题而不是编程问题。例如，使用SSL/TLS通过加密来确保保密性是最好的实现方式。为你的应用程序激活它，简单的方式是对 IIS进行恰当的配置，然后使用前缀为https的URL进行访问。
ASP.NET安全性的配置主要涉及到编辑一个分级的XML文档集合。在这棵树的顶部是machine.config，其中运行在这台机器上的用于所有 ASP.NET应用程序的全局设置被制定好。在全局配置文件的下面是web.config文件，它包含了每个单独的ASP.NET应用程序的设置。本文将 讨论如何在这些文件中配置CAS、身份认证、假冒以及授权等方面，来保证Web服务安全运行。
1、为ASP.NET配置CAS
尽管CAS主要作为保护系统客户端免受恶意移动代码侵扰的一种方式，但它与Web服务和Web应用程序在服务器端的部署仍有一些关联。例如，一台服务器可 能主管不止一个的个体，团体和组织授权的ASP.NET应用程序；在这种情况下，CAS有助于减少由一个实体拥有的应用程序被另外一个实体拥有的应用程序 干扰的风险，也有助于被服务器操作系统干扰的风险。
但是，你应该注意到：在默认情况下，CAS策略授予ASP.NET应用程序一套完整的程序集。因为他们从本地机器上运行。很显然，当配置你的应用程序时， 你应该修正这一点。.NET框架定义了许多不同的信任级别：Full, High, Medium, Low和 Minimal，你可以用他们来确定ASP.NET应用程序的特权授予。除了这些策略中的第一种在配置文件 web_hightrust.config, web_mediumtrust.config等中被指定，其他所有策略位于.NET框架根目录下的配置子目录。为了给一个特殊的ASP.NET应用程序 授权一个medium信任等级，你必须给它的web.config文件如下的结构：
<configuration>
<system.web>
<trust level="Medium"/>
</system.web>
</configuration>
2、以最小特权运行
处理单个ASP.NET请求的“工作进程”运行在账户为ASPNET的Windows环境中。这个特殊的账户有一个受限的Windows 特权集，为了控制这种损害，应该让给ASP.NET应用程序。但是，对于工作进程来说，在与IIS相同的账户——SYSTEM账户下执行是可能的。如果你 想要这种情况发生，你编写的machine.config文件应该像这样：
<configuration>
<processModel userName="System" password="AutoGenerate"/>
</configuration>
为了让这样的更改生效，必须重启IIS管理服务和WWW发布服务。
这样做的一个原因可能是：为了获得Windows用户用于假冒目的的访问令牌，允许你的ASP.NET代码从Win32 API中调用LogonUser。但是，这违反了最低权限（least privilege）的基本安全原则，以及显著增加了成功攻击所引起的损害。因此在那样做之前你应该仔细斟酌。
|
