当你启用一台Web服务器的时候，你就把你公司的一部分完全展现给了公众，任凭他人摆布。Web服务器上的那些可以被远程利用的漏洞可能会成为你的梦魇。一个显著的例子就是：微软Internet信息服务（IIS）5.0曾经就留下了丧失生产力和效益的不光彩记录。在那之后，微软对IIS进行了彻底的重新设计，这一次，他们把安全性放在了第一位。成果体现在IIS 6.0上，它被广泛认为是市场上安全性最高的商业Web服务器产品（这一点通过Secunia给出的为数仅5条的安全建议可见一斑，见secunia.com/product/1438）。
IIS 7.0构建在IIS 6.0的安全基础上，并且实现了模块化设计，单个功能可以被彻底移除，从而有效降低了你的Web服务器的受攻击面。IIS 6.0引进了“应用程序池”的概念，用于在应用程序之间（以及应用程序与Web服务器进程之间）实现隔离，现在，这个功能被进行了更有效的“沙箱化”处理。新的委派功能可以让站点所有者在不提升权限的情况下管理他们的站点。请求过滤（即：URLscan）功能现在也集成到了服务器中。管理员可以在IIS 7.0里直接定义策略，控制什么用户可以访问什么URL。
以上所提到的这些功能都属于IIS 7.0在安全性方面的改进。它们值得你更深入地研究，同时，它们甚至会改变你管理和配置Web站点的思路。
应用程序沙箱
试想一家市场调查公司既提供一些面向大众的调查报告，又需要向那些互为竞争对手的公司提供一些敏感的市场数据。或者试想一台服务器既安装了供一小部分人使用的财务应用程序，同时又被作为一个公司门户供全体用户访问。对于以上两种情况而言，将运行在同一台服务器上的不同应用程序隔离开来是至关重要的。Web应用程序运行在工作者进程（worker processes）下。应用程序池把Web应用程序映射到工作者进程。一个特定的工作者进程只用于运行作为相同应用程序池的一部分的应用程序。在IIS 6.0和IIS 7.0中，工作者进程是“w3wp.exe”。
在IIS 6.0中，新的Web站点和应用程序被放置在相同的应用程序池里。这个默认的应用程序池运行在“NetworkService”账号下。作为一名管理员，你可以手动创建新的应用程序池并且把Web应用程序指派给这些池。默认情况下，这些应用程序池也将运行在“NetworkService”账号下，这就会导致一个令人不快的运行时场景：所有的Web应用程序都运行在相同的权限下。一个在应用程序池A中的应用程序可以读取应用程序池B的配置信息，甚至有权访问属于应用程序池B的应用程序的内容文件。虽然创建新的应用程序池以及为它们配置自定义账号的任务足够简单，但是随着时间的推移，管理这些账号却并不那么轻松。在IIS 7.0里，系统自动为各Web站点新建一个应用程序池。默认情况下，应用程序池被配置为以“NetworkService”账号运行。而当工作者进程被创建时，I I S 7 . 0 会向“NetworkService”安全令牌注入一个特殊的唯一标识该应用程序池的SID。IIS 7.0还会为工作者进程创建一个配置文件，并且将文件的ACL设置为仅允许应用程序池唯一的SID访问。这么做的结果就是：一个应用程序池的配置将无法被别的应用程序池读取。顺便提醒一下，你可以更改内容文件的ACL，从而允许应用程序池唯一的SID进行访问而不是“NetworkService”账号。这可以阻止应用程序池A中的某个应用程序读取应用程序池B中某应用程序的内容文件。
IUSR和IIS_IUSRS
服务器使用哪个账号作为匿名访问的身分凭证是关联进程身份的重要问题。前一版IIS 依赖于一个本地账号——IUSR_servername，将其作为匿名用户登录的身份凭证。IIS 7.0则使用了一个全新的内置账号，叫做“IUSR”。你不能使用IUSR账号进行本地登录，所以它没有密码（也就是说那些猜密码攻击对它都不起作用）。由于IUSR账号总是拥有相同的SID，所以它的相关ACL在Windows Server 2008（以及WindowsVista）机器之间是可传递的。而如果IUSR账号不适合你的应用场景的话（也就是说，如果匿名请求需要经身份验证的网络访问的话），你可以关闭匿名用户账号，IIS 7.0将为匿名请求使用工作者进程身份。同样全新的还有内置的IIS_IUSRS组。这个用户组取代了原先的IIS_WPG组。在IIS 6.0里，IIS_WPG组提供了运行一个工作者进程所需的最小权限，而且你必须手动地将账号添加到该组，从而为一个工作者进程提供自定制的身份凭证。IIS_IUSRS组为IIS 7.0提供了类似的角色，但是你不必特意将账号添加到该组。取而代之的是，当账号被指派为某一应用程序池的身份凭证时，IIS 7.0 会自动将这些账号收入到IIS_IUSRS组。并且和IUSR账号一样，IIS_IUSRS组也是内置的，所以在所有的Windows Server 2008机器上，它总是具有相同的名称和SID，这就让ACL以及其它配置在Windows Server2008（以及Windows Vista）机器之间是完全可迁移的。
功能委派
并非所有的Web服务器设置都需要管理员权限的保护。有些设置只是简单的应用程序级别的内容，完全可以让开发人员或者产品经理来定夺。例如，在IIS 6.0里，你需要管理员权限才能更改Web应用程序的默认文档。而一般情况下，仅仅把“default.aspx”改成“profile.aspx”就真的有必要动用管理员权限吗？在IIS 7.0里，配置任务现在可以被委派给站点或者应用程序所有者。IIS 7.0使用了一个由ASP.NET支持的全新的基于XML的配置系统。在站点和应用程序的级别上，IIS 7.0和ASP.NET的设置可以在相同的“web.config”文件中被找到。诸如默认文档之类的委派设置可以在Web站点或应用程序的级别上进行更改，方法是直接编辑“web.config”文件或者使用IIS Manager GU（I 如图1所示），它会为你更新“web.config”文件。在“web.config”文件里，“system.webServer”段落包含了IIS 7.0的配置设置，如图2所示。
其中有效的段落被定义在一个叫做“applicationHost.config”的特殊配置文件里。在“applicationHost.config”文件里，各段落都有一个默认的委派模式。在图3的例子中，默认文档和目录浏览设置都可以被覆盖，但是“asp”、“caching”或“cgi”段落却不可以。
图1：使用功能委派在Web站点级别上配置默认文档
然而，如果我想阻止一个Web站点所有者更改默认文档呢？没问题：IIS 7.0可以让你锁定配置元素，从而无法设置或覆盖“web.config”里的配置。如果是默认的配置文档的话，你可以全局地把默认覆盖模式更改为“Deny”，或者也可以明确地把特定位置的覆盖模式设成“Deny”（使用“location”标签）。IIS团队建议在location标签中声明这些更改，如列表1所示。功能委派对于一名繁忙的管理员来说绝对是一个好帮手，因为它可以安全地授予Web站点和应用程序所有者某些配置权限，而这些配置只会影响他们自己的站点和应用程序。
管理委派
许多管理员为了图方便，在有人需要对某站点或应用程序应用更改的时候就把管理员权限给他。这当然会带来巨大的安全风险。不幸的是，你面临的是一个两难境地：要么不加限制地分派管理员权限，要么把所有管理权限都集中到一点，限制任何其他人对设置进行更新。在IIS 7.0里，服务器管理员可以把一个特定Web站点或应用程序的管理权限授予一名或多名用户，并且无需提升他们的用户权限。在IIS Manager里，如图4所示，用户既可以使用Windows身份凭证也可以使用IISManager专用的身份凭证连接到一台IIS 7.0服务器。IIS Manager专用身份凭证的好处就在于你提供给用户的权限是具有专门用途和有所限制的，即：IIS Web站点管理权限。该身份凭证在IIS Manager以外是毫无用途的。如果是远程使用的话，一个独立的IIS Manager版本现在可以安装在Windows Vista、Windows Server 2003和WindowsXP上。在你远程连接到IIS Manager之前，你必须明确启用Web服务器上的远程管理功能，具体操作是：
1. 安装Web管理服务（WMSVC）；
2.在Web服务器上通过IIS Manager（或通过注册表）开启远程管理功能；
3.启动Web管理服务。
防火墙规则或远程访问策略有可能会给远程管理工具的使用造成麻烦。出于这个原因，IIS Manager走的是HTTPS协议，因此既安全又不与防火墙冲突。默认情况下，Web管理服务使用一个自我分配的证书并且在8172端口上监听。微软在以下地址提供了用于远程管理的IIS 7.0 Manager：www.iis.net/go/1524。如果还需要更多资源（包括详细的配置内置的请求过滤)
图4：IIS Manager
如果你曾经管理过IIS服务器的话，你大概不会对UrlScan感到陌生，它是一个可供IIS 4.0及以上版本下载的工具，可用于限制IIS可以接受的请求类型。请求过滤的目的主要是保护你的Web服务器免遭恶意请求的攻击。在IIS 7.0的请求过滤模块里，UrlScan得到了增强，并且与Web服务器进行了绑定。请求过滤模块会根据可配置的标准来过滤请求。例如，它可以拒绝双重编码的请求或者不符合常规大小的请求（例如：超大的POST载荷或者太长的URL）。请求过滤模块还可以拒绝针对特定文件类型、路径或你的站点所不支持的HTTP动作的请求。在IIS 7.0里，请求过滤配置也可以进行委派，它允许站点管理员在“web.config”文件里定义自己的请求过滤规则，而这在IIS 6.0的UrlScan里是无法实现的。有关IIS 7.0请求过滤的更多信息，请看本刊2008年1月文章“释放微软IIS 7.0的安全力量”。
URL授权
Web应用程序通常都有一些受限制的区域，只允许特定的用户访问。比方说，只有经理才有权访问HR系统里的业绩报告内容。这些受限制的页面通常被归并到名叫“Administration”、“Reporting”或“Moderation”的目录中。在旧版的IIS里，保护这些目录不被未经授权者访问可不是一个简单的任务。即使ASP.NET里内置了URL授权的功能，你也还是需要处理一些非ASP.NET的内容，例如：PDF或Excel文件，它们同样需要保护。而且ASP.NET URL授权规则是通过编辑XML来管理的，这同样也是一项乏味的工作。在IIS 7.0里，ASP.NET URL授权功能依然保留，但是除此以外，Web服务器本身现在也提供一个URL授权功能。现在，对所有类型的内容（例如：静态的、PHP、ASP）的访问可以根据用户、组或URL来加以控制。举例来说，你可以轻松地限制对任何位于“Reporting”路径下的内容的访问，只允许“Managers”组的成员访问，同时无需修改ACL。图5显示了IIS Manager里的URL授权规则配置。URL 授权规则在“web.config”文件的“system.webServer”段落中得到保持，其语法与ASP .NET的授权规则略有不同，如列表2所示。由于授权规则完全包含在你的配置文件里（本地“web.config”），所以它们很容易在应用程序和服务器之间迁移。并且IIS 7.0里的URL授权与Windows用户和组，以及ASP.NET的用户和角色可以很好地配合。
基于IIS
IIS 7.0是在IIS 6.0的安全基础上构建的，它保留了IIS 6.0的应用程序池/工作者进程隔离模型的核心结构，这一结构被证明是非常有效的。尽管在讨论IIS 7.0的安全性的时候，新的模块结构受到了很多关注，但是自动化的应用程序沙箱、功能委派以及URL授权这些特性也不容忽视，它们让保护Web服务器的任务变得比以往更轻松了。您可以在本刊网站下载提到的列表文件。
图5：在IIS Manager中配置URL授权规则
Derek Hatchard，是一名网站创办者、咨询师和培训师。他同时也是一名Microsoft Regional Director、Microsoft MVP、作者以及演讲者。你可以在derekh.com和ardentdev.com上看到他的博客，同时他也与别人在devcasting.com 合作开办开发人员播客。您可以通过derek@ardentdev.com与他取得联系。