确保应用程序服务器的安全
本页内容
 |
本模块内容 |
|
目标 |
|
适用范围 |
|
如何使用本模块 |
|
概述 |
|
威胁与对策 |
|
方法 |
|
通信通道考虑事项 |
|
防火墙考虑事项 |
|
.NET 远程处理安全考虑事项 |
|
企业服务 (COM+) 安全注意事项 |
|
小结 |
|
其他资源 |
本模块内容
中间层应用程序服务器通常用来驻留业务逻辑和数据访问服务。该功能通常被打包在企业服务应用程序中，或通过使用中间层 Web Services 或 Microsoft® .NET Framework 远程处理技术显露给前端 Web 服务器。
本模块将对每项技术分别进行讨论，并介绍如何在每种情况下确保应用程序服务器的安全。重点讨论用来将 Web 服务器连接到应用程序服务器、以及将应用程序服务器连接到数据库服务器的关联的通信通道。
在深入研究特定于技术的设置之前，本模块先识别应用程序服务器所面临的主要威胁。这些威胁与面向 Internet 的 Web 服务器所面临的威胁稍有不同，因为中间层应用程序服务器与直接的 Internet 访问是（或者应该是）相互隔绝的。
目标
使用本模块可以实现：
| • | 确保应用程序服务器的通信通道的安全。 |
| • | 确保中间层应用程序服务器上的 Web Service、企业服务和远程解决方案的安全。 |
| • | 配置用来分隔 Web 服务器和应用程序服务器的内部防火墙。 |
| • | 管理 RPC 动态端口分配。 |
| • | 安全地使用 .NET 远程处理。 |
| • | 锁定企业服务应用程序。 |
| • | 了解哪些对策用于解决常见的应用程序服务器威胁，包括网络窃听、未经授权的访问、病毒、特洛伊木马和蠕虫。 |
适用范围
本模块适用于下列产品和技术：
| • | Microsoft Windows Server 2000 和 2003 |
| • | Microsoft .NET Framework 1.1 和 ASP.NET 1.1 |
| • | Microsoft SQL Server |
如何使用本模块
要充分理解本模块：
| • | 请查阅模块 2 威胁与对策。它将帮助您更多地了解对 Web 应用程序的潜在威胁。 |
||||||
| • | 使用其他安全模块。本模块是一个安全解决方案的一部分，该方案所包括的模块涵盖了主机（操作系统）和网络层的安全。请将本模块与下面的模块一起使用：
|
概述
要确保应用程序服务器的安全，必须在已锁定基础操作系统和 Internet 信息服务 (IIS) Web 服务器（如果已安装）后应用增量安全配置。
图 17.1 展示了本模块的关注内容，这包括配置在很多多层部署模型中起重要作用的内部防火墙。
图 17.1
远程应用程序服务器部署模型
威胁与对策
应用程序服务器面临的许多威胁来自于组织内部，因为应用程序服务器应当与 Internet 访问隔离开来。应用程序服务器面临的主要威胁包括：
| • | 网络窃听 |
| • | 未经授权的访问 |
| • | 病毒、特洛伊木马和蠕虫 |
图 17.2 显示了应用程序服务器面临的主要威胁。
图 17.2
与应用程序服务器相关的主要威胁和漏洞
网络窃听
使用网络监视软件的攻击者能够截获从 Web 服务器流向应用程序服务器、以及从应用程序服务器流向下游系统和数据库服务器的数据。攻击者能查看数据，并有可能修改这些数据。
漏洞
能够导致应用程序服务器被网络窃听的漏洞包括：
| • | 应用程序以明文传送的敏感数据 |
| • | 对数据库使用 Microsoft SQL Server 身份验证，从而产生纯文本凭据 |
| • | 传输层或应用程序层没有加密 |
| • | 不安全的网络硬件管理接口 |
| • | 对远程组件使用 .NET 远程处理 TCP 通道 |
攻击
攻击者在网络上放置数据包侦听工具以捕获通信。
对策
防止数据包侦听的对策包括以下几种：
| • | 使用不在网络上传送帐户密码的安全的身份验证，如 Windows 身份验证。 |
| • | 对 SQL Server 身份验证凭据进行加密。如果使用 SQL Server 身份验证，可以采用在数据库服务器上安装服务器证书的方式，来加密身份验证凭据。 |
| • | 确保通信通道的安全。可以选择的措施包括采用安全套接字层 (SSL) 或 IPSec。 |
| • | 对 Enterprise Servises 应用程序使用远程过程调用 (RPC) 加密。 |
| • | 使用分段网络，这样可以将窃听隔离在已被攻破的网段内。 |
| • | 对 .NET 远程处理使用 HttpChannel 和 SSL。 |
未经授权的访问
如果未能阻塞位于外围防火墙的应用程序服务器上运行的程序所使用的端口，则外部攻击者能够直接与应用程序服务器通信。如果允许前端 Web 服务器以外的计算机连接到应用程序服务器，那么该应用程序服务器的受攻击面就会增加。
漏洞
可能导致未授权访问的漏洞包括：
| • | 薄弱的外围网络和防火墙配置 |
| • | 内部防火墙上多余的开放端口 |
| • | 未使用 IPSec 策略限制主机连接 |
| • | 不需要的活动服务 |
| • | 不需要的协议 |
| • | 弱帐户和密码策略 |
攻击
进行未授权访问的常见攻击包括：
| • | 用来检测监听服务的端口扫描 |
| • | 获取会泄漏可用的服务并可能会泄漏软件版本的标题信息 |
| • | 恶意应用程序输入 |
| • | 对使用弱密码的默认帐户进行密码攻击 |
对策
防止未授权访问的对策包括：
| • | 用来阻塞除所需要的端口以外的所有通信的防火墙策略 |
| • | 用来防止未经授权主机建立连接的 TCP/IP 筛选或 IPSec 策略 |
| • | 禁用未使用的服务 |
| • | 只允许访问授权主机的静态 DCOM 端点映射 |
病毒、蠕虫和特洛伊木马
这些攻击通常不被注意，直到它们开始耗费系统资源，而这将减慢或阻止其他应用程序的执行。驻留 IIS 的应用程序服务器易受 IIS 攻击。
漏洞
| • | 未经修补的服务器 |
| • | 运行不需要的服务 |
| • | 不需要的 ISAPI 筛选器和扩展 |
对策
帮助减少由病毒、特洛伊木马和蠕虫引起的风险的对策包括：
| • | 及时安装最新的软件修补程序 |
| • | 禁用未使用的功能，如未使用的 ISAPI 过滤器和扩展 |
| • | 使用最少权限帐户运行进程，以便在遭到入侵的情况下缩小受损范围 |
方法
通过保护应用程序服务器的通信通道、防止除授权 Web 服务器以外的任何主机访问应用服务器，使攻击者只能利用 Web 应用程序设计和开发中的漏洞进行应用程序层的攻击。
要减少该风险，开发人员必须使用本指南第二部分和第三部分中描述的安全的设计和开发方法。
本模块的配置解决方案针对的是应用程序服务器，该解决方案不应孤立使用。请与以下模块提供的解决方案一起应用本解决方案：模块 15 保护您的网络、模块 16 保护 Web 服务器和模块 18 保证数据库服务器的安全。
通信通道考虑事项
出入应用程序服务器的敏感应用程序数据和身份验证凭据应该经过加密，以保护其隐私和完整性。这样做能够减少与窃听和篡改相关的风险。
对网络通信进行加密可减少网络窃听和篡改威胁。如果您认为这种威胁在您所处的环境中是可以忽略的（例如，因为应用程序所在位置是一个封闭的并且物理上安全的网络），那么就不需要对网络通信进行加密。如果网络窃听是一个应该考虑的问题，那么，可以使用 SSL（在应用层提供安全的通信通道）或 IPSec（提供传输层解决方案）。IPSec 对两台服务器之间流动的所有 IP 通信进行加密，而 SSL 允许每个应用程序选择是否提供加密的通信通道。
企业服务
企业服务（即 COM+）应用程序在网络上使用 DCOM over RPC 进行通信。RPC 使用 135 端口，该端口提供终结点映射服务，以允许客户端协商参数，包括默认情况下自动分配的通信端口。
有两种保护企业服务通道的方法：
| • | RPC 加密 |
| • | IPSec |
.NET 远程处理
对于使用 .NET 远程处理的应用程序，有两个可能的实现模型：
| • | 在端口 80 上使用 HTTP 通道 |
| • | 在任意端口上使用 TCP 通道 |
可以使用两种方法中的一种来确保远程处理通道的安全，具体的选择取决于应用程序的性能和安全需求。
| • | 对 HTTPChannel 使用 SSL |
| • | 对 TCPChannel 使用 IPSec |
Web Services
Web Services 驻留在 ASP.NET 和 IIS 上，这些服务使用 HTTP 协议进行网络通信。
可使用 SSL 或 IPSec 来确保通信通道的安全。另外，通过对消息的有效负载和有效负载的敏感部分进行加密，也可以在应用程序层处理加密。要使用开放式标准确保通信安全，请使用对 Web Services 可用的 Web Services Enhancements (WSE) 下载。有关详细信息，请查阅模块 12 构建安全的 Web Services。
SQL Server
默认情况下，应用程序服务器与 SQL Server 服务器之间使用 TCP 端口 1433 通信。除非进行了相反的设置，否则 UDP 端口 1434 也可用于协商。
要确保应用程序服务器和 SQL Server 之间通道的安全，请使用 IPSec 或 SSL。SSL 需要在数据库服务器上安装服务器证书。
有关在 SQL Server 上使用 SSL 的详细信息，请参阅 Microsoft 知识库中的文章 276553 How To:Enable SSL Encryption for SQL Server 2000 with Certificate Server（英文）。
防火墙考虑事项
安全基础结构可包括位于应用程序服务器任何一端的内部防火墙。本节讨论这些防火墙上打开的、支持应用程序功能的端口。
企业服务
如果使用中间层企业服务，请配置一个内部防火墙，用来分隔 Web 服务器和应用程序服务器，以允许 DCOM 和 RPC 通信。另外，如果使用企业服务，应用程序通常采用分布式事务和 Distributed Transaction Coordinator (DTC) 服务。在此情形下，请打开将应用程序服务器与远程资源管理器（如数据库服务器）分隔开的任何防火墙上的 DTC 端口。图 Figure 17.3 显示一个典型的企业服务端口配置。
图 17.3
典型企业服务防火墙端口配置
注意 图 17.3 未显示在客户端与企业服务应用程序之间、以及可能在企业服务应用程序与数据库服务器之间的身份验证机制所需要的其他端口。通常，对于未使用 Active Directory 的网络，Windows 身份验证需要 TCP 端口 139。有关端口需求的详细信息，请参阅 TechNet 网站上的文章“TCP and UDP Port Assignments”，其网址为 http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp（英文），并参阅“Security Considerations for Administrative Authority”，其网址为 http://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.asp（英文）。
默认情况下，DCOM 使用 RPC 动态端口分配方式，该方式随机选择 1024 以上的端口号。另外，RPC 终结点映射服务使用端口 135。
要在内部防火墙上限制需要用来支持 DCOM 的端口，有两种方法：
| • | 定义端口范围。 |
| • | 使用静态终结点映射。 有关静态终结点映射的详细信息，请参阅 Microsoft 知识库中的文章 312960 Cannot Set a Fixed Endpoint for a COM+ Application（英文）。 |
Web Services
如果不能打开内部防火墙上的端口，则可以在应用程序服务器上，在所服务的组件的前面引入一个 Web 服务的正面层。这意味着只需为 HTTP 通信（尤其是 SOAP 消息）打开端口 80 以使其双向流动。
该方法不允许从客户端传送事务上下文到服务器，尽管许多情况下部署体系结构包含中间层应用程序服务器，但启动在应用程序服务器上的远程服务组件中的事务是合适的。
有关服务代理和服务接口（如 Web 服务的正面层）的物理部署需求的信息，请参阅“ Physical Deployment and Operational Requirements ”，该文章在 MSDN 的 Reference 部分：“ Application Architecture for .NET:Designing Applications and Services ”，其网址为 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+ platform SDK 中的“DTC Security Considerations”，其网址是 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgdtc_admin_9dkj.asp（英文）。 |
| • | Microsoft 知识库中的文章 250367 INFO:Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall（英文）。 |
| • | Microsoft 知识库中的文章 306843 How To:Troubleshoot MS DTC Firewall Issues（英文）。 |
.NET 远程处理
如果使用 HTTP 通道并在 ASP.NET 中驻留远程组件，那么只需在防火墙上打开端口 80 以允许 HTTP 通信。如果应用程序还使用 SSL，那么打开端口 443。
如果使用 TCP 通道，并在 Windows 服务中驻留远程组件，请打开已在配置中要让远程处理应用程序使用的具体 TCP 端口。应用程序可能需要额外的端口以支持回拨。
图 17.4 显示一个典型的 .NET 远程处理防火墙端口配置。注意，列出的 TCP 通道方案的端口号（5555 和 5557）是示例。实际端口号要在客户端和服务器上的 web.config 配置文件中指定。有关详细信息，请参阅模块 13 构建安全的远程组件。
图 17.4
典型 HTTP 和 TCP 通道方案的远程处理防火墙端口配置
Web Services
Web services 使用 SOAP over HTTP 进行通信； 因此，只需打开防火墙上的端口 80。
SQL Server
如果防火墙将应用程序服务器与数据库服务器分隔开，那么，如果要通过防火墙与 SQL Server 连接，则需要使用 SQL Server Client Network Utility 来配置客户端，并使用 Server Network Utility 来配置数据库服务器。默认情况下，SQL Server 在 TCP 端口 1433 进行监听，但这是可以更改的。所选端口在防火墙上必须是打开的。
可能需要在防火墙上打开几个额外的端口，这取决于所选择的 SQL Server 身份验证模式和应用程序所使用的分布式事务。
| • | 如果应用程序使用 Windows 身份验证连接 SQL Server，请打开支持 Kerberos 协议或 NTLM 身份验证的必要的端口。 |
| • | 如果应用程序使用分布式事务（比如自动 COM+ 事务），请配置防火墙以允许 DTC 通信在不同的 DTC 实例之间以及在 DTC 与资源管理器（如 SQL Server 之间）流动。 |
有关 SQL Server 端口需求的详细信息，请参阅模块 18 保证数据库服务器的安全。
.NET 远程处理安全考虑事项
.NET 远程处理基础结构允许同一台计算机上或网络中不同计算机上的应用程序之间相互通信。远程处理基础结构能使用 HTTP 或 TCP 传输进行通信，并能以很多格式发送消息，最常用的是 SOAP 或二进制格式。
驻留在 Windows 服务中（TCP 通道）
因为远程处理基础结构没有提供默认的身份验证与授权机制，因此不推荐在面向 Internet 的应用程序中使用它。它是为在受信任环境中运行的应用程序而设计的，并且很适合用于 Web 服务器与远程应用程序服务器之间的通信，图 17.5 显示了这一点。
图 17.5
通过 TCP 通道进行远程处理与 Windows 服务驻留
在该方案中，Windows 服务驻留远程处理对象，并通过 TCP 通道进行通信。这种方法提供了好的性能，但没有解决必要的安全问题。要获得额外的安全保证，请在 Web 服务器与应用程序服务器之间使用 IPSec，并只允许 Web 服务器建立与应用程序服务器的连接。
驻留在 IIS 中（HTTP 通道）
要从 ASP.NET 和 IIS 提供的安全功能受益，应在 ASP.NET 中驻留远程组件，并使用 HTTP 通道进行通信，如图 17.6 所示。
图 17.6
使用 HTTP 通道进行远程处理与 ASP.NET 驻留
在该方案中，可以使用 Windows 集成验证机制来验证 ASP.NET Web 应用程序进程身份。还可以使用 SSL 来确保通信的安全，并使用 IIS 和 ASP.NET 所提供的网关守卫进行身份验证。
企业服务 (COM+) 安全注意事项
COM+ 为企业服务提供基础结构；因此，如果在中间层应用程序服务器上使用 COM+，请确保 COM+ 的安全。在确保使用企业服务的应用程序的安全方面，涉及两个主要步骤：
| • | 确保组件服务基础结构的安全。 |
| • | 配置企业服务应用程序安全性。 |
开发人员能够使用嵌入在已部署的程序集中的元数据，来指定许多应用程序和组件级别的安全配置设置。这些设置用于控制在将应用程序注册到企业服务时应用于这些程序的初始目录安全设置。这样，必要时管理员能够使用“组件服务”工具查看和修改这些设置。
确保组件服务基础结构的安全
企业服务不是可选的组件，它作为 Windows 2000 系统不可或缺部分安装。从安全角度出发，通过了解安装哪些操作系统组件以支持企业服务，将帮助您采取恰当的安全措施。
操作系统安装什么项目？
以下表格显示标准操作系统安装时所安装的核心组件服务元素。
表 17.1：企业服务组件
| 项目 | 详细信息 |
| Administration |
Component Services Explorer |
| System Application |
System Application |
| 服务 |
COM+ Event System |
| 帐户 |
企业服务不创建任何帐户。库应用程序在运行时采用它在其中运行的进程的标识。服务器应用程序能够配置成以交互式用户或特定用户运行。（在 COM+ 应用程序的组件服务“属性”对话框中，可以在“标识”选项卡上配置用户帐户。） |
| 日志文件 |
DTC 日志文件：%windir%\system32\DTCLog |
| 注册表项 |
HKEY_CLASSES_ROOT\CLSID |
.NET Framework 安装哪些项目？
安装 .NET Framework 时，将同时安装与企业服务相关的以下组件。
表 17.2：NET Framework 企业服务工具和配置设置
| 项目 | 说明 |
| Regsvcs.exe |
命令行工具，用来向 COM+ 注册企业服务组件 |
| 库 |
System.EnterpriseServices.dll |
| Machine.config |
如果从 ASP.NET 调用企业服务，以下 Machine.config 项是相关的： |
要确保组件服务基础结构的安全，请考虑以下项目：
| • | 修补程序和更新 |
| • | 服务 |
| • | 端口 |
| • | COM+ 目录 |
修补程序和更新
使用最新的 Service Pack 和修补程序更新应用程序服务器，以降低由病毒、蠕虫和特洛伊木马造成的风险。需要定期更新的软件包括操作系统，其中包含 IIS 和 .NET Framework。
COM+ 运行时环境的更新有时作为 QFE 版本发行。使用以下资源可以帮助您管理修补程序和更新：
| • | Windows 更新和修补程序 有关需要多台服务器通过集中的管理点进行升级的环境的信息，请参阅如何：实施修补程序管理，它在本指南的“如何”部分。 |
| • | .NET Framework 更新和修补程序 |
| • | 手动更新 .NET Framework
|
服务
要减少攻击面，应禁用所有不需要的服务。需要的服务包括 Microsoft DTC 和 COM+ Event System 服务（该服务用来支持 LCE COM+ 功能）。
要确保应用程序服务器上服务的安全，如果不需要 MS DTC，应将其禁用。
如果不需要 Microsoft DTC 则将其禁用
DTC 服务与 COM+ 紧密地集成在一起。它协调分布在两个或多个数据库、消息队列、文件系统或其他资源管理器上的事务。如果应用程序不使用 COM+ 自动事务服务，那么应使用 Services MMC 管理单元将 DTC 禁用。
端口
Serviced components 使用 DCOM 进行通信，反过来 DCOM 使用 RPC 传输进行通信。
默认情况下，DCOM 动态分配端口，从安全及防火墙配置角度考虑，这种分配方式是不可取的。应限制 DCOM 端口以减少攻击面，并确保在内部防火墙上不要打开不必要的端口。有两种方法可以限制 DCOM 所使用的端口：
| • | 使用端口范围 |
| • | 使用静态终结点映射 |
端口范围
对于传入通信，可以在 1024 以上的受限范围内配置 RPC 动态端口分配。然后配置防火墙以限制传入的外部通信只使用这些端口和端口 135，端口 135 是 RPC 终结点映射端口。
| • | 控制 RPC 动态端口分配
|
静态终结点映射
Windows 2000（SP3 或 QFE 18.1）或 Windows Server 2003 允许配置企业服务应用程序以使用静态终结点。如果防火墙将客户端与服务器分隔开，只需打开防火墙上的两个端口。具体来说，必须打开 RPC 端口 135 和企业服务应用程序的端口。
| • | 为 DCOM 配置静态终结点
|
COM+ 目录
企业服务应用程序配置设置是在 COM+ 目录中维护的。大多数配置项包含在注册数据库 (RegDB) 中，该数据库由位于以下目录的文件组成：
%windir%\registration
默认情况下，Everyone 组拥有读取该数据库的权限。请修改该目录的访问控制列表 (ACL)，以使读/写访问权仅被管理员和本地系统帐户拥有。同时，将读取访问权授予用来运行企业服务应用程序的帐户。下面是必需的 ACL：
Administrators：读取，写入 System：读取，写入 企业服务运行方式帐户：读取
确保企业服务应用程序的安全
在 COM+ 目录中可以分别维护各个应用程序配置设置，并使用“组件服务”工具或脚本对这些设置进行配置。下面讨论的许多设置也可以由应用程序开发者在所服务的组件程序集中使用正确的程序集级元数据来指定。当注册服务组件时（例如使用 Regsvcs.exe 注册），系统将使用该元数据自动配置 COM+ 目录，尽管应用程序的运行方式标识必须手动配置。
要确保企业服务应用程序的安全，必须配置以下项目：
| • | 标识（运行方式） |
| • | 身份验证级别 |
| • | 基于 COM+ 角色的安全性 |
| • | 模拟 |
| • | CRM 日志文件 |
| • | 应用程序程序集 |
标识（运行方式）
将企业服务服务器应用程序配置为使用权限最少的帐户运行。这样可以减少当服务器进程被设法使用其安全上下文执行代码的攻击者攻陷时，可能出现的潜在损坏。
如果企业服务应用程序中的服务组件不模拟调用者的安全上下文，那么，将使用通过运行方式帐户所指定的进程级别标识来访问下游的本地和远程资源。要支持远程数据库服务器的网络身份验证，可以创建一个“镜像”本地帐户，它是位于远程服务器上具有相匹配的用户名和密码的本地帐户。
注意 当设置企业服务的运行方式标识时，会自动赋予该帐户必需的“作为批作业登录”特权。
身份验证级别
企业服务应用程序的调用方使用 RPC，反过来，RPC 使用操作系统通过安全服务提供程序接口 (SSPI) 层提供的基本身份验证服务。这意味着应用程序身份验证对调用方使用 Windows 身份验证：Kerberos 或 NTLM。
RPC 定义了身份验证级别，该级别确定何时进行身份验证，以及是否应该检查已验证的通信完整性和已加密。至少，应使用调用级别身份验证来确保每个对服务组件方法的方法调用是经过身份验证的。
注意 调用级别身份验证不会导致对消息数据加密。因此，如果网络窃听的确是个需要注意的问题，请使用数据包隐私身份验证级别，或在 IPSec 安全通道上使用调用级别的身份验证。
表 17.3 显示不同的身份验证级别：
表 17.3：企业服务应用程序身份验证级别
| 身份验证级别 | 说明 |
| 默认值 |
使用标准的协商规则选择身份验证级别 |
| 无 |
没有身份验证 |
| 连接 |
只在客户端开始连接服务器时验证凭据 |
| 调用 |
每次开始远程过程调用时进行身份验证 |
| 数据包 |
对所有来自客户端的数据进行身份验证 |
| 数据包的完整性 |
对所有数据进行验证并验证传输的数据未被修改 |
| 数据包隐私 |
对所有数据进行验证并使用 RPC 加密对所有传输的数据包进行加密 |
| • | 要设置调用方身份验证
|
COM+ 基于角色的安全性
企业服务应用程序的身份验证是由企业服务 (COM+) 角色提供的。COM+ 角色包含 Windows 用户和组帐户，用于限制对应用程序、组件、接口和方法的访问。理想状态下，应配置组件级别身份验证的企业服务应用程序，它允许对单个服务组件方法的调用者进行验证。
配置基于角色的安全性：
| • | 启用基于角色的安全性。 |
| • | 启用组件级别访问权限检查。 |
| • | 实施组件级别访问权限检查。 |
启用基于角色的安全性
默认情况下，Windows 2000 禁用了基于角色的安全性。Windows Server 2003 的默认设置相反。
| • | 启用基于角色的安全性
|
图 17.7
启用基于角色的安全性
启用组件级别访问权检查
如果没有组件级别访问权检查，那么，如果用任何帐户连接到任何应用程序组件，只要该帐户是应用程序内任意一个角色的成员，则该帐户就会获得访问权。组件级别访问权检查允许每个组件应用自己的身份验证。这是推荐的粒度级别。
| • | 启用组件级别访问权检查
|
图 17.8
启用组件级别访问权检查
强制进行组件级别访问权检查
要允许企业服务应用程序内单个组件执行访问权检查并对调用者进行授权，必须在组件级启用组件级别访问权检查。
| • | 强制进行组件级别访问权检查
|
注意 如前所述，只有启用了应用级别访问权检查，并配置了进程和组件级别的访问权检查，该设置才能生效。
模拟
DCOM 客户端设置了模拟级别，以确定与之通信的服务器的模拟功能。在配置位于中间层应用程序服务器的企业服务应用程序时，所配置的模拟级别会影响对下游组件（包括数据库服务器）的任何远程调用。要设置模拟级别，请访问“组件服务”中应用程序的“属性”对话框的“安全设置”页面，如图 17.9 所示。
图 17.9
DCOM 模拟级别
尽管您应当使用以下指南来确定适当的级别，但适当的级别取决于您想要的应用程序级别的功能：
| • | 避免“匿名”模拟。下游组件将不能对应用程序进行验证或授权。 |
| • | 使用“标识”以允许下游组件对应用程序进行验证和授权。然而，它将不能使用模拟的应用程序安全上下文来访问本地或远程资源。 |
| • | 如果想允许下游组件模拟应用程序的标识，以便它能够访问下游服务器上的本地资源，请使用“模拟”。 |
| • | 如果想允许下游组件模拟应用程序的标识，以便它能访问本地或远程的资源，请使用“委派”。这需要在 Active Directory 配置委派帐户。 |
由中间层应用程序服务器上的服务组件所执行的所有下游资源访问通常使用服务器应用程序的标识。然而，如果服务组件执行程序模拟，并且客户端应用程序（通常是 ASP.NET Web 应用程序或 Web 服务器上的 Web service）已配置为支持 Kerberos 委派，那么将使用客户端标识。
有关详细信息，请参阅“How To:Enable Kerberos Delegation in Windows 2000”，该内容在“Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications:Authentication, Authorization, and Secure Communication”的“How to”部分，其网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp（英文）。
CRM 日志文件
如果企业服务应用程序使用 CRM，应该确保 CRM 日志文件得到了安全的保护，以防止潜在的信息泄漏。该文件可能包括敏感的应用程序数据，这取决于应用程序的性质。CRM 日志文件创建在以下目录中：
%windir%\system32\dtclog
CRM 日志文件名称从企业服务应用程序 ID 派生而来，并带有扩展名 .crmlog。企业服务创建 CRM 日志文件时，该日志文件得到保护，而且该文件配置的 ACL 对应用程序的运行方式帐户授予了完全控制权。没有其他帐户有访问权。
如果在创建了日志文件以后更改应用程序标识，必须手动更改该日志文件的 ACL。确定应用程序的新的运行方式标识具有完全控制权。
应用程序程序集
要保护已部署的应用程序程序集（其中包含应用程序的服务组件），应该强化与该程序集的 .dll 文件相关联的 ACL，以确保它们不会被替代或被未经授权的用户删除。
对应用程序的 DLL 文件夹应用以下 ACL：
用户：执行 应用程序的运行方式帐户：执行 Administrators：读取，写入和执行
应用程序的程序集 DLL 的位置是在程序部署时指定的，因此可能会因安装的不同而不同。“组件服务”工具中的“属性”对话框没有显示程序集 DLL 的位置。它指向 %windir%\System32\mscoree.dll，该程序为组件提供侦听服务。
| • | 检查应用程序 DLL 的位置
|
小结
当充分的外围网络防御措施就位时，许多影响到中间层应用程序服务器的威胁因素都来自组织内部。一个安全的基础结构应当由 IPSec 策略组成，以便只能从选定的 Web 服务器访问应用程序服务器，并同时提供安全的通信通道，这样的基础结构才是能够有效降低风险的策略。
本模块已提供了其他安全措施。这些措施各不相同，这取决于应用程序服务器所使用的技术。
应用程序服务器两端的内部防火墙会带来一些其他问题。必须打开的端口取决于所选择的应用程序的具体实现，比如：使用什么传输协议，以及是否使用了分布式事务。
其他资源
有关本模块所讨论的问题的详细信息，请参阅微软帮助和支持上的以下 Microsoft 知识库文章：
| • | 文章 233256 How to:Enable IPSec Traffic Through a Firewall（英文） |
| • | 文章 312960 Cannot Set a Fixed Endpoint for a COM+ Application（英文） |
| • | 文章 259011 SAMPLE:A Simple DCOM Client Server Test Application（英文） |
| • | 文章 248809 PRB:DCOM Does Not Work over Network Addressed Translation – Based Firewall（英文） |
| • | 文章 250367 INFO:Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall（英文） |
| • | 文章 154596 How To:Configure RPC Dynamic Port Allocation to Work with Firewall（英文） |