备注：Microsoft技术资源库很不错的，左边还有很多解决方案以及教程可以学习，慢慢欣赏吧~
本单元概要
中间层应用程序服务器最常用的用途是宿主业务逻辑和数据访问服务。这一功能通常打包在企业服务应用程序中，或者通过使用中间层 Web 服务或 Microsoft® .NET Framework 远程处理技术向前端 Web 服务器公开。
本单元将分别讨论这些技术，说明在各种情况下如何保护应用程序服务器的安全。集中讨论将 Web 服务器和应用程序服务器，以及将应用程序服务器与数据库服务器连接的相关通信信道。
在深入讨论与具体技术相关的配置之前，本单元将首先讨论针对应用程序服务器的主要威胁。这些威胁与适用于面对 Internet 的 Web 服务器的威胁有所不同，因为中间层应用程序服务器与直接的 Internet 访问是（或者说应该是）隔离开来的。
目标
使用本单元可以：
保护到应用程序服务器的通信信道。
保护中间层应用程序服务器上的 Web 服务、企业服务和远程处理解决方案。
配置内部防火墙，将 Web 服务器与应用程序服务器分隔开来。
管理 RPC 动态端口的分配。
安全地使用 .NET 远程管理。
锁定企业服务应用程序。
了解哪些对策能够应对常见的应用程序服务器威胁，包括网络侦听、未授权访问、病毒、特洛伊木马和蠕虫。
适用范围
本单元适用于下列产品和技术：
Microsoft® Windows® Server 2000 和 Windows Server™ 2003 操作系统
Microsoft .NET Framework 1.1 和 ASP.NET 1.1
Microsoft SQL Server™
如何使用本单元
要从本单元受益最多：
请阅读“威胁与对策”单元。它能使您更好地理解 Web 应用程序所面临的潜在威胁。
使用其他配套的“保护……”单元。本单元是安全解决方案的一部分，此解决方案还包括多个单元，涵盖了主机（操作系统）和网络层的安全。除本单元之外还可以结合使用以下单元：
“保护网络的安全”
“保护数据库服务器”
本页内容
本单元概要 目标 适用范围 如何使用本单元 概述 威胁与对策 方法 通信信道注意事项 防火墙注意事项 .NET远程管理安全注意事项 企业服务 (COM+) 安全注意事项 小结 其他资源
概述
为了保护应用程序服务器的安全，必须在基础操作系统和 Internet 信息服务 (IIS) Web 服务器（如果已经安装）已经锁定的前提下应用增量安全配置。
图 1 显式了本单元的重点，包括配置许多多层部署模型中都具备的内部防火墙。
图 1. 远程应用程序服务器部署模型
威胁与对策
许多针对应用程序服务器的威胁都来自单位的内部，因为应用程序服务器应该与 Internet 访问相隔离。应用程序服务器的主要威胁有：
网络侦听
未授权访问
病毒、特洛伊木马和蠕虫
图 2 显示了应用程序服务器的主要威胁。
图 2. 应用程序服务器相关的主要威胁和漏洞
网络侦听
攻击者使用网络监控软件可以侦听从 Web 服务器传递到应用程序服务器以及从应用程序服务器传递到下游系统和数据库服务器的数据。攻击者可以查看甚至可能修改这些数据。
漏洞
可能使应用程序服务器受到网络侦听攻击的漏洞包括：
应用程序以明文传递敏感数据
对数据库使用 Microsoft SQL Server 身份验证，生成明文凭据
缺乏传输层或者应用程序层加密
不安全的网络－硬件管理界面
使用 .NET 远程管理TCP 信道连接远程组件
攻击
攻击者在网络上安装数据包嗅探工具以捕捉流量。
对策
防止数据包嗅探的对策包括以下几种：
使用安全的身份验证（比如 Windows 身份验证），它不会跨网络发送密码。
加密 SQL Server 身份验证凭据。如果使用 SQL Server 身份验证，您可以通过在数据库服务器上安装服务器证书自动地加密凭据。
保护通信信道。选项包括使用安全套接字层 (SSL) 或者 Internet 协议安全 (IPSec)。
对企业服务应用程序使用远程过程调用 (RPC) 加密。
使用分段网络，将侦听与可能存在问题的网段隔离开来。
在 .NET远程管理 使用 HttpChannel 和 SSL。
未授权访问
如果您无法在外围防火墙阻塞应用程序服务器上运行的应用程序所使用的端口，外部攻击者就能够直接与应用程序服务器通信。如果您允许计算机而不是前端 Web 服务器与应用程序服务器连接，对应用程序服务器的攻击面将会增加。
漏洞
可能导致未授权访问的漏洞包括：
脆弱的外围网络和防火墙配置
内部防火墙中打开的端口过多
缺乏限制主机连接的 IPSec 策略
不必要的活动服务
不必要的协议
脆弱的帐号和密码策略
攻击
常见的能够获得未授权访问的攻击包括：
检测侦听服务的端口扫描
泄漏可用服务以及可能的软件版本的标志攫取
恶意的应用程序输入
对密码脆弱的默认帐号的密码攻击
对策
防止未授权访问的对策包括：
防火墙策略阻止除来自期望的通信端口之外的所有流量
TCP/IP 筛选或者 IPSec 策略防止未授权主机建立连接
禁用未用服务
静态 DCOM 终结点映射只允许访问已授权的主机
病毒、蠕虫和特洛伊木马
这些攻击通常只有恶意程序开始消耗系统资源时才被注意到，它们会减慢或者暂停其他应用程序的执行。宿主 IIS 的应用程序服务器很容易受到 IIS 攻击。
漏洞
未安装修补程序的服务器
运行不必要的服务
不必要的 ISAPI 筛选器和 ISAPI 扩展
对策
有助于减轻病毒、特洛伊木马和蠕虫所造成的风险的对策包括：
尽快应用最新的软件修补程序
禁用未用的功能，比如未用的 ISAPI 筛选器和扩展
以最低特权帐号运行进程，以减少出现安全事故时造成的危害范围
方法
通过保护到应用程序服务器的通信信道，防止除授权 Web 服务器之外的任何主机访问应用程序服务器，攻击者将被限制为只能利用 Web 应用程序设计和开发中出现的漏洞实施应用程序层攻击。
为了减轻这种风险，开发人员必须应用本指导第二部分和第三部分中叙述的安全设计和开发方法。
本单元中的配置解决方案是专门针对应用程序服务器的，它们不应该孤立地使用。应该将它们与“保护网络的安全”、“保护 Web 服务器的安全”和“保护数据库服务器”单元中提出的解决方案一起应用。
通信信道注意事项
发送到应用程序服务器以及从其接收的敏感应用程序数据和身份验证凭据应该进行加密，以提供私密性和完整性。这将减少与侦听和篡改相关的风险。
加密网络流量能够解决网络侦听和篡改威胁。如果您认为这种威胁在环境中无足轻重（例如，因为应用程序位于一个封闭的和物理上非常安全的网络中），那么可能无需加密流量。如果存在网络侦听问题，则可以使用 SSL，它在应用程序层提供了一个安全的通信信道，或者使用 IPSec，它提供了一种传输级解决方案。IPSec 能够加密在两个服务器之间传递的所有 IP 流量，而 SSL 则允许所有应用程序选择是否提供加密通信信道。
企业服务
企业服务（即 COM+）应用程序使用 RPC 之上的 DCOM 跨网络进行通信。RPC 使用端口 135，后者提供了终结点映射服务，允许客户端就参数进行协商，其中包括通信端口，它在默认情况下是动态指派的。
企业服务信道的保护方式有两种：
RPC 加密
您可以配置一个企业服务应用程序以使用 RPC 数据包私密性身份验证。除了身份验证之外，这还能为发送到企业服务应用程序和从企业服务应用程序接收的所有数据包提供加密。
IPSec
您可以使用 IPSec 策略在 Web 服务器和应用程序服务器之间加密通信信道。
.NET 远程管理
应用程序使用 .NET远程管理有两种可能的实现模型：
端口 80 上的 HTTP 信道
这种模型使用 ASP.NET 作为宿主服务。
任何端口上的 TCP 信道
在此模型中，应用程序宿主在自定义的可执行文件（通常是一个 Windows 服务）中。
根据应用程序的性能和安全要求，您可以使用以上两种方法中的一种保护远程处理信道。
使用 SSL 和 HttpChannel
如果您宿主在 ASP.NET 中，可以利用 IIS 提供的内置 HTTPS 功能。HTTPS 提供了身份验证和安全的数据通信。
使用 IPSec 和 TCPChannel。
在 TCP 信道中，您可以使用 IPSec 策略为所有 IP 数据提供传输层加密。请注意如果您使用 TCP 信道，就必须提供自己的身份验证机制。有关更多信息，请参阅“构建安全的远程组件”单元。
Web 服务
Web 服务是由 ASP.NET 和 IIS 宿主的，服务使用 HTTP 协议进行跨网络通信。
SSL 或者 IPSec 能够用来保护通信信道。此外，也可以通过加密消息负载或者负载的敏感部分在应用程序层进行加密。为了使用开放标准做到这一点，应该使用针对 Web 服务的 Web Services Enhancements (WSE) 。有关更多信息，请参阅“构建安全的 Web 服务”单元。
SQL Server
应用程序服务器默认情况下通过 TCP端口 1433 与 SQL Server 通信。除非进行了其他配置，否则还需要使用用 UDP端口 1434 进行协商。
为了保护从应用程序服务器到 SQL Server 的信道，应该使用 IPSec 或者 SSL。使用 SSL 时，需要在数据库服务器上安装服务器证书。
有关在 SQL Server 上使用 SSL 的更多信息，请参阅 Microsoft 知识库文章 276553，“如何：通过证书服务器为 SQL Server 2000 启用 SSL 加密”。
防火墙注意事项
安全基础结构中可能在应用程序服务器的两端都包括内部防火墙。本部分讨论了为支持应用程序的各种功能而在这些防火墙上打开的端口。
企业服务
如果您使用中间层企业服务，应该配置一个内部防火墙，将 Web 服务器和应用程序服务器隔离，以允许 DCOM 和 RPC 流量。此外，如果您使用企业服务，应用程序经常会用到分布式事务和分布式事务协调程序 (DTC) 的服务。在此时，应该打开将应用程序服务器与远程资源管理器（比如数据库服务器）隔离开的任何防火墙上的 DTC 端口。图 3 显示了典型的企业服务端口配置。
图 3. 典型的企业服务防火墙端口配置
×¢ 图 3 没有显示在客户端和企业服务应用程序之间，以及可能在企业服务应用程序和数据库服务器之间的身份验证机制必需的附加端口。通常，对于不使用 Active Directory 的网络，Windows 身份验证必需 TCP 端口 139 。有关端口需求的更多信息，请参阅 TechNet 文章“TCP 和 UDP 端口指派”，网址为：http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp ，以及“管理机构的安全注意事项”，网址为：http://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.asp 。
默认情况下，DCOM 使用 RPC 动态端口分配，随机选择大于 1024 的端口号。 此外，RPC 终结点映射服务使用端口 135。
限制内部防火墙上支持 DCOM 所需的端口有两种方式：
定义端口范围。
这种方式允许您控制 RPC 动态分配的端口。有关动态端口限制的更多信息，请参阅 Microsoft 知识库文章 300083，“如何：限制 Windows 2000 和 Windows XP 上的 TCP/IP端口”。
使用静态终结点映射。
Microsoft Windows 2000 SP3（或者 QFE 18.1 和更高版本）或者 Windows Server 2003 允许您配置企业服务应用程序以使用静态终结点。静态终结点映射意味着您只需要打开防火墙中的两个端口：端口 135 用于 RPC，以及一个命名端口用于企业服务应用程序。
有关静态终结点映射的更多信息，请参阅 Microsoft 知识库文章 312960，“无法设置 COM+ 应用程序的固定终结点”。
Web 服务
如果无法打开内部防火墙的端口，您可以在应用程序服务器上的服务组件前引入一个 Web 服务外观层。这意味着您只需为 HTTP 流量（说得具体一些，也就是 SOAP 消息）打开端口 80 以进行双向传输。
这种方法不允许您从客户端到服务器传输事务上下文，虽然许多情况下，部署体系结构中包括一个中间层应用程序服务器，那样的话，在应用程序服务器上的远程服务组件中启动事务比较合适。
有关服务代理和服务接口（比如 Web 服务外观层）物理部署需求的信息，请参阅“物理部署和操作需求”，在 MSDN 文章“.NET 应用程序结构：设计应用程序和服务”中的参考部分里，网址是： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp 。
DTC 需求
如果应用程序使用 COM+ 分布式事务，而且是跨越被内部防火墙分隔的远程服务器来使用的，那么防火墙必须打开必要的端口以支持 DTC 流量。DTC 使用 RPC 动态端口分配。除了用于 RPC 的端口 135 之外，DTC 通信还至少要求一个额外的端口。
如果部署体系结构中包括一个远程应用程序层，企业服务应用程序中的事务通常从这里启动，并传播到数据库服务器中。如果没有应用程序服务器，Web 服务器上的企业服务应用程序将启动事务并将其传播到 SQL Server 资源管理器。
有关配置防火墙以支持 DTC 流量的信息，请参阅：
COM+ 平台 SDK 中的“DTC 安全注意事项”，网址是： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgdtc_admin_9dkj.asp
Microsoft 知识库文章 250367，“信息：”配置 Microsoft 分布式事务协调程序 (DTC) 以透过防火墙工作”。
Microsoft 知识库文章 306843，“如何：解决 MS DTC 防火墙疑难问题。”
.NET 远程管理
如果您使用 HTTP 信道并在 ASP.NET 中宿主远程组件，只能在内部防火墙上打开端口 80 以允许 HTTP 流量通过。如果您的应用程序还要使用 SSL，则应该打开端口 443。
如果您使用 TCP 信道并宿主在 Windows 服务中，需要打开特定的 TCP端口或者远程处理应用程序已经配置使用的端口。应用程序可能需要另一个端口以支持回调。
图 4 显示了一个典型的 .NET 沿程管理防火墙端口配置。请注意所显示的端口号对应的是使用 TCP 信道的情况（5555 和 5557），这只是为了说明的方便。实际的端口号是在客户端和服务器机器上的 web.config 配置文件中指定的。有关更多信息，请参阅“构建安全的远程组件”单元。
图 4. HTTP 信道和TCP 信道情况下典型的远程处理防火墙端口配置
Web 服务
Web 服务使用 HTTP 之上的 SOAP 进行通信，因此只需在内部防火墙上打开端口 80 即可。
SQL Server
如果防火墙将应用程序服务器与数据库服务器分隔开来，那么通过防火墙与 SQL Server 连接，要求您使用 SQL Server 客户端网络实用工具配置客户端，并且使用服务器网络实用工具来配置数据库服务器。默认情况下，SQL Server 侦听 TCP端口 1433，当然这种情况也会变化。必须在防火墙上打开所选择的端口。
根据所选择的 SQL Server 身份验证模式和应用程序使用的分布式事务，还可能需要在防火墙上打开几个其他端口：
如果您的应用程序使用 Windows 身份验证与 SQL Server 连接，应该打开必要的端口以支持 Kerberos 协议或者 NTLM 身份验证。
如果应用程序使用分布式事务，例如自动化 COM+ 事务，需要将防火墙配置为允许 DTC 流量以在不同的 DTC 实例之间以及 DTC 与资源管理器（比如 SQL Server）之间传递。
有关 SQL Server 端口需求的更多信息，请参阅“保护数据库服务器”单元。
.NET远程管理安全注意事项
.NET远程管理基础结构使同一台机器上的应用程序或者网络中不同机器上的应用程序能够互相通信。远程处理基础结构能够使用 HTTP 或者 TCP 传输进行通信，可以以许多格式发送消息，其中最常见的是 SOAP 或者二进制格式。
宿主在 Windows 服务（TCP 信道）中
因为远程处理基础结构没有默认的身份验证和授权机制，所以不推荐在面向 Internet 的应用程序中使用。远程处理是为运行在可信环境中的应用程序而设计的，非常适于 Web 服务器与远程应用程序服务器的通信，如图 5 所示。
图 5. 使用 TCP 信道的远程处理和 Windows 服务宿主
在这种情况下，Windows 服务宿主远程处理对象，通信是通过 TCP 信道进行的。这种方法提供了很好的性能，但是未必能解决安全问题。为了增加安全性，可以在 Web 服务器和应用程序服务器之间使用 IPSec，并且只允许 Web 服务器与应用程序服务器建立连接。
宿主在 IIS （HTTP 信道）中
为了利用 ASP.NET 和 IIS 提供的安全功能，将远程组件宿主在 ASP.NET 中，使用 HTTP 信道进行通信，如图 6 所示。
图 6. 使用 HTTP 信道的远程处理和 ASP.NET 宿主
在这种情况下，您可以使用 Windows 集成身份验证对 ASP.NET Web 应用程序进程的身份进行验证。您还可以使用 SSL 进行安全的通信，使用 IIS 和 ASP.NET 提供的网关守卫进行授权。
企业服务 (COM+) 安全注意事项
COM+ 为企业服务提供了基础结构，因此，如果您在中间层应用程序服务器上使用 COM+ ，就需要保护 COM+ 的安全。保护使用企业服务的应用程序服务器，需要涉及两个主要步骤：
保护组件服务基础结构。
您必须保护基础操作系统和企业服务基础结构。这包括许多基本安全措施，比如应用修补程序和更新，禁用未用服务，阻塞未用端口，等等。
配置企业服务应用程序安全。
您必须保护部署在服务器上的企业服务应用程序，充分考虑应用程序特定的安全需要。
开发人员可以使用嵌入在部署程序集中的元数据，指定许多应用程序级和组件级安全配置设置。这些设置管理最初的目录安全设置，在应用程序向企业服务注册时，这些设置将应用于应用程序。然后，如果必要的话，管理员可以通过使用组件服务工具查看和修改这些设置。
保护组件服务基础结构
企业服务不是可选组件，它是作为 Windows 2000 不可分割的一部分安装的。从安全的角度来看，了解哪些操作系统组件是为了支持企业服务而安装的，有助于您采取适当的安全措施。
操作系统已经安装了哪些组件？
下表列出了随标准操作系统安装而安装的核心组件服务元素。
表 1 企业服务组件
项 | 详细信息 |
|---|---|
管理 | 组件服务资源管理器 |
系统应用程序 | 系统应用程序 |
服务 | COM+ 事件系统 |
帐户 | 企业服务不创建任何帐户。库应用程序以它们运行所在进程的身份运行。服务器应用程序可以配置为以交互用户或者特定的用户运行。（您可以在组件服务中 COM+ 应用程序 Properties 对话框的 Identity 选项卡上配置用户帐户）。 |
日志文件 | DTC 日志文件：%windir%\system32\DTCLog |
注册表项 | HKEY_CLASSES_ROOT\CLSID |
.NET Framework 安装了哪些组件？
当您安装 .NET Framework 时，将安装以下与企业服务相关的组件。
表 2 .NET Framework 企业服务工具和配置设置
项 | 说明 |
|---|---|
Regsvcs.exe | 命令行工具，用于向 COM+ 注册企业服务组件 |
库 | System.EnterpriseServices.dll |
Machine.config | 如果您从 ASP.NET 调用企业服务，Machine.config 中的以下项将与此有关： |
为了保护组件服务基础结构，需要考虑以下几项：
修补程序和更新
服务
端口
COM+ 目录
修补程序和更新
用最新的服务包和修补程序更新应用程序服务器，以降低病毒、蠕虫和特洛伊木马带来的风险。需要定期更新的软件包括操作系统、IIS 和 .NET Framework。
COM+ 运行库的更新有时是以 QFE 版本的形式发布的。使用以下资源有助于管理修补程序和更新：
Windows 更新和修补程序
使用 Microsoft 基准安全分析程序 (MBSA) 检测应用程序服务器上遗漏的安全更新。有关如何在一台计算机上使用 MBSA 以及保持一组服务器最新的更多信息，请参阅本指导的“如何……”部分中的“如何使用 MBSA ”。
有关要求许多服务器从一个集中管理点更新的环境方面的信息，请参阅本指导的“如何……”部分中的“如何实现修补程序管理”。
.NET Framework 更新和修补程序
在撰写本单元的时候（2003 年 5 月），MBSA 还没有能力检测 .NET Framework 。所以，您必须手工更新 .NET Framework。
手工更新 .NET Framework
确定要在 Web 服务器上安装的 .NET Framework 服务包。
为此，请参阅 Microsoft 知识库文章 318785，“INFO: Determining Whether Service Packs Are Installed on .NET Framework ”。
比较当前服务包与 .NET Framework 的安装版本。
为了此，使用 Microsoft 知识库文章 318836，“INFO: How to Obtain the Latest .NET Framework Service Pack ”中列出的 .NET Framework 版本。
COM+ 更新和修补程序
最新的 Windows 服务包包括对 COM+ 的当前修补。但是，对 COM+ 运行库的更新有时是以 QFE 版本的形式发布的。COM+ 更新自动通知服务现在还没有，因此需要不断关注 Microsoft 知识库，网址是：http://support.microsoft.com 。使用“kbQFE”作为搜索关键字以改善搜索结果。
服务
为了减少受攻击面，应该禁用任何不需要的服务。必需的服务包括：Microsoft DTC 和 COM+ 事件系统服务，这是支持 LCE COM+ 功能所需的。
为了保护应用程序服务器上的服务，如果不需要它的话，应该禁用 MS DTC。
如果不需要就禁用 Microsoft DTC
DTC 服务是与 COM+ 紧密结合的。它负责协调跨越两个或者多个数据库、消息队列、文件系统或者其他资源管理器分布的事务。如果您的应用程序不使用 COM+ 自动事务服务，那么应该通过使用服务 MMC 管理单元禁用 DTC。
端口
服务组件使用 DCOM 进行通信，DCOM 继而又使用 RPC 传输通信。
默认情况下，DCOM 动态分配端口，这从安全和防火墙配置的角度来看是不可取的。对 DCOM 端口应该进行限制，以减少受攻击面，并保证无需打开内部防火墙上不必要的端口。要限制 DCOM 使用的端口有两种选择：
使用端口范围。
使用静态终结点映射。
端口范围
对于传入的通信，可以配置 RPC 动态端口分配，从而在大于 1024 的有限范围中选择端口。然后配置防火墙以限制传入的外部通信只通过这些端口和端口 135，后者是 RPC 终结点映射器端口。
控制 RPC 动态端口分配
启动组件服务工具。
单击以打开 Component Services 和Computers 节点，右键单击 My Computer，然后单击 Properties。
单击 Default Protocols 选项卡，然后选择 DCOM Protocols 列表框中的 Connection-oriented TCP/IP。
单击 Properties。
在 Properties for COM Internet Services 对话框中，单击 Add。
在 Port range 文本框中，添加端口范围，例如 5000–5020，然后单击 OK。
将 Port range assignment 和 Default dynamic port allocation 选项设置为 Internet range。
单击 OK 两次，关闭对话框。
重启计算机，使更改生效。
静态终结点映射
Windows 2000（SP3 或者 QFE 18.1）或者 Windows Server 2003 允许您配置企业服务应用程序，以使用静态终结点。如果防火墙将客户端与服务器分隔开来，只需要打开防火墙的两个端口。具体来说，您必须为 RPC 打开端口 135，并为企业服务应用程序打开一个端口。
为 DCOM 配置静态终结点
从 COM+ 目录获取企业服务应用程序的应用程序 ID。步骤如下：
启动组件服务工具。
显示应用程序的 Properties 对话框，并从 General 页检索应用程序 ID。
启动注册表编辑器 (Regedt32.exe)。
选择以下注册表项：
HKEY_CLASSES_ROOT\AppID
从 Edit 菜单中，单击 Add Value，然后添加以下注册表值，其中 {your AppID} 是第 1 步中获取的 COM+ 应用程序的应用程序 ID：
Key name: {Your AppID} Value name: Endpoints Data type: REG_MULTI_SZ Value data: ncacn_ip_tcp,0,在 Value data 文本框中指定的端口号必须大于 1024，不能与计算机上其他应用程序使用的已知端口冲突。不能修改此项中的 ncacn_ip_tcp,0 部分。
关闭注册表编辑器。
COM+ 目录
企业服务应用程序配置设置保存在 COM+ 目录中。大多数配置项保存在注册数据库 (RegDB) 中，由位于以下目录中的文件组成：
%windir%\registration默认情况下，Everyone 组有读取此数据库的权限。修改此目录的访问控制列表 (ACL)，以限制对管理员和本地系统帐号的读/写访问权限。还要授予对于帐户的读访问权限，用来运行企业服务应用程序。以下是必需的 ACL：
Administrators: Read, Write
System: Read, Write
Enterprise Services Run-As Account(s): Read保护企业服务应用程序
单独的应用程序配置设置是保存在 COM+ 目录中的，可以使用组件服务工具或者使用脚本进行配置。下面讨论的许多设置也可以由应用程序开发人员通过在服务组件程序集中使用正确的程序集级元数据来指定。在注册服务组件时，例如通过使用 Regsvcs.exe 时，COM+ 目录自动地使用此元数据进行配置，但是应用程序的运行方式 (run-as) 身份必须通过管理手段进行配置。
为了保护企业服务应用程序，必须配置以下项：
身份 (run as)
身份验证级
COM+ 基于角色的安全
模拟
CRM 日志文件
应用程序程序集
身份 (Run As)
配置企业服务服务器应用程序，以最低特权帐户运行。当服务器进程遇到攻击者使用其安全上下文执行代码的攻击时，这将减少因此造成的潜在危害。
如果企业服务应用程序中的服务组件并不模拟调用方的安全上下文，那么通过 run-as 帐户指定的进程级身份将用于下游的本地资源和远程资源的访问。为了支持对远程数据库服务器的网络身份验证，您可以创建一个“镜像的”本地帐户，后者是一个具有匹配用户名和密码的远程服务器上的本地帐户。
×¢ 当您将企业服务设置为 run-as 身份时，将自动授予该帐户所必需的“Logon as a batch job”特权。
身份验证级
企业服务应用程序使用 RPC 对调用方进行身份验证，而调用方继而又会使用通过安全服务提供程序接口 (SSPI) 层提供的操作系统基础身份验证服务。这意味着应用程序将使用 Windows 身份验证，即 Kerberos 或者 NTLM 对调用方进行身份验证。
RPC 定义了多个身份验证级，用于决定何时进行身份验证，以及已经过身份验证的通信是否还应该检查完整性或者进行加密。至少，您应该使用调用级身份验证确保每个对服务组件方法的方法调用都要进行身份验证。
×¢ 调用级身份验证并不会导致消息数据的加密。因此，如果网络侦听问题很严重的话，可以使用数据包私密性身份验证级，如果是在一个用 IPSec 保护的信道上，则可以使用调用级身份验证。
表 3 显示了各种身份验证级：
表 3：企业服务应用程序身份验证级
身份验证级 | 说明 |
|---|---|
默认值 | 使用正常的协商规则选择身份验证级 |
无 | 无身份验证 |
连接 | 当客户端最初连接服务器时只有身份验证凭据 |
调用 | 在每次远程过程调用的开始进行身份验证 |
数据包 | 对从客户端接收到的所有数据进行身份验证 |
数据包完整性 | 对所有数据进行身份验证，并验证已传输的所有数据都没有被修改 |
数据包私密性 | 对所有数据进行身份验证，并使用 RPC 加密机制加密所有传输的数据包 |
设置调用级身份验证
启动组件服务，并显示应用程序的 Properties 对话框。
单击 Security 选项卡。
从 Authentication level for calls 下拉列表中选择 Call。
COM+ 基于角色的安全
企业服务应用程序中的授权是由企业服务 (COM+) 角色提供的。COM+ 角色包含 Windows 用户和组帐户，用于限制对应用程序、组件、接口和方法的访问。理想情况下，企业服务应用程序应该配置为组件级授权，这样可以授权调用方访问单独服务组件方法。
配置基于角色的安全：
启用基于角色的安全。
启用组件级访问检查。
强制组件级访问检查。
启用基于角色的安全
默认情况下，基于角色的安全性在 Windows 2000 上是禁用的。而对于 Windows Server 2003 则正好相反。
启用基于角色的安全
启用组件服务工具，显示应用程序的 Properties 对话框。
单击 Security 选项卡。
选择 Enforce access checks for this application。
图 7. 启用基于角色的安全
启用组件级访问检查
在没有组件级访问检查的情况下，如果用来连接任何应用程序组件的任何帐户是应用程序中任何角色的成员，都将被授予访问权限。组件级访问检查允许单独的组件应用自己的授权。这是推荐的粒度级别。
启用组件级访问检查
启动组件服务工具，并显示应用程序的 Properties 对话框。
单击 Security 选项卡。
单击 Perform access checks at process and component level。
图 8. 启用组件级访问检查
强制组件级访问检查
为了允许企业服务应用程序中的单独组件执行访问检查和对调用方进行授权，您必须在组件级启用组件级访问检查。
强制组件级访问检查
启动组件服务工具，并在树控件中展开应用程序。
选择 Components 文件夹，右键单击它，然后单击 Properties。
单击 Security 选项卡。
单击 Enforce component level access checks。
×¢ 此设置只在您已经启用了应用程序级访问检查之后而且配置了进程和组件级访问检查时是有效的，这一点前面已经叙述过。
模拟
DCOM 客户端设置模拟级以决定与其通信的服务器的模拟能力。当配置中间层应用程序服务器上的企业服务应用程序时，已配置的模拟级将影响对下游组件（包括数据库服务器）的任何远程调用。模拟级是在组件服务中应用程序 Properties 对话框的 Security 页设置的，如图 9 所示。
图 9. DCOM 模拟级
合适的级别取决于所需的应用程序级的功能，虽然您应该使用以下指导确定合适的级别：
避免使用 Anonymous 模拟。下游组件不能标识应用程序以用于身份验证或者授权目的。
使用 Identify 以允许下游组件对您的应用程序进行身份验证和授权。但是，它将无法使用应用程序模拟的安全上下文访问本地或者远程资源。
使用 Impersonate 如果您想允许下游组件模拟应用程序的身份，这样使其能够访问下游服务器上的本地资源。
使用 Delegate 如果你想允许下游组件模拟应用程序的身份，这样使其能够访问本地或者远程资源。这需要帐户为在 Active Directory 中的委托进行配置。
所有下游资源的访问都是由中间层应用程序服务器上的服务组件执行的，通常使用服务器应用程序的身份。但是，如果服务组件执行编程模拟，而客户端应用程序（通常是一个 ASP.NET Web 应用程序或者 Web 服务器上的 Web 服务）已经配置为支持 Kerberos 委托，那么将使用客户端的身份。
有关更多信息，请参阅“如何：在 Windows 2000 中启用 Kerberos 委托”，在“Microsoft patterns & practices 第 I 卷，构建安全的 ASP.NET Web 应用程序：身份验证、授权和安全通讯”的“如何……”部分，网址是：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp。
CRM 日志文件
如果您的企业服务应用程序使用 CRM，应该确保 CRM 日志文件得到保护，避免潜在的信息泄漏。根据应用程序的性质，文件可能包含敏感的应用程序数据。CRM 日志文件是在以下目录创建的：
%windir%\system32\dtclogCRM 日志文件名是从企业服务应用程序 ID 派生而来的，文件扩展名为 .crmlog。当企业服务创建 CRM 日志文件，且该文件通过一个 ACL（授予应用程序 run-as 帐户 Full Control）进行配置时，该文件将得到保护。没有其他帐户拥有访问权限。
如果您在日志文件创建后改变应用程序的身份，则必须手动改变文件的 ACL。确保应用程序新的 run-as 身份具有 Full Control 权限。
应用程序程序集
为了保护包含应用程序服务组件的已部署应用程序程序集，应该加固与程序集 .dll 文件相关联的ACL，以确保它们不会被未授权的用户替换或者删除。
对应用程序的 DLL 文件夹应用以下 ACL：
Users: Execute
Application Run as account: Execute
Administrators: Read, Write and Execute应用程序程序集 DLL 的位置是在部署时指定的，因此可能因不同的安装而异。组件服务工具中的 Properties 对话框并不显示程序集 DLL 的位置。相反，它指向 %windir%\System32\mscoree.dll，这为组件提供了侦听服务。
检查应用程序 DLL 的位置
启动组件服务工具，并在树控件中展开应用程序。
展开 Components 文件夹，选择一个组件，右键单击它，然后单击 Properties。
在 Properties 对话框中，检索组件的类 ID (CLSID)。
启动 Regedt32.exe，并在 HKEY_CLASSES_ROOT\CLSID 下找到已检索的 CLSID。
单击 InprocServer32 项。
DLL 的位置由 CodeBase 命名值所指示。
小结
当具备足够的外围网络防护时，影响中间层应用程序服务器的许多威胁都来自单位的内部。安全基础结构是由多个 IPSec 策略组成的，这些策略限制只能从选定的 Web 服务器对应用程序服务器进行访问，它们还提供了安全的通信信道。这种安全基础结构是有效降低风险的策略。
本单元还列举了更多安全措施。这些措施会根据应用程序服务器所用技术的不同而不同。
在应用程序服务器两端的内部防火墙带来了另一些问题。必须打开的端口具体取决于应用程序实现的选择，比如传输协议和是否使用分布式事务。
如果你看到了最后：
在贴几个与简要内容相关的：组件服务管理及其安全配置
身份验证、授权安全配置： http://technet.microsoft.com/zh-cn/library/dd145616.aspx
管理安全性配置：http://technet.microsoft.com/zh-cn/library/cc755073.aspx
其他资源
有关本单元所讨论问题的更多信息，请参阅以下 Microsoft 知识库文章，网址是：http://support.microsoft.com：
扫一扫
284
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
