保护应用服务器的安全

时间 2019-11-07

原文原文链接

备注：Microsoft技术资源库很不错的，左边还有不少解决方案以及教程能够学习，慢慢欣赏吧~html

本单元概要前端

中间层应用程序服务器最经常使用的用途是宿主业务逻辑和数据访问服务。这一功能一般打包在企业服务应用程序中，或者经过使用中间层 Web 服务或 Microsoft® .NET Framework 远程处理技术向前端 Web 服务器公开。web

本单元将分别讨论这些技术，说明在各类状况下如何保护应用程序服务器的安全。集中讨论将 Web 服务器和应用程序服务器，以及将应用程序服务器与数据库服务器链接的相关通讯信道。数据库

在深刻讨论与具体技术相关的配置以前，本单元将首先讨论针对应用程序服务器的主要威胁。这些威胁与适用于面对 Internet 的 Web 服务器的威胁有所不一样，由于中间层应用程序服务器与直接的 Internet 访问是（或者说应该是）隔离开来的。编程

返回页首
windows

目标

使用本单元能够：api

保护到应用程序服务器的通讯信道。安全
保护中间层应用程序服务器上的 Web 服务、企业服务和远程处理解决方案。服务器
配置内部防火墙，将 Web 服务器与应用程序服务器分隔开来。网络
管理 RPC 动态端口的分配。
安全地使用 .NET 远程管理。
锁定企业服务应用程序。
了解哪些对策可以应对常见的应用程序服务器威胁，包括网络侦听、未受权访问、病毒、特洛伊木马和蠕虫。

返回页首

适用范围

本单元适用于下列产品和技术：

Microsoft® Windows® Server 2000 和 Windows Server™ 2003 操做系统
Microsoft .NET Framework 1.1 和 ASP.NET 1.1
Microsoft SQL Server™

返回页首

如何使用本单元

要从本单元受益最多：

请阅读“威胁与对策”单元。它能使您更好地理解 Web 应用程序所面临的潜在威胁。
使用其余配套的“保护……”单元。本单元是安全解决方案的一部分，此解决方案还包括多个单元，涵盖了主机（操做系统）和网络层的安全。除本单元以外还能够结合使用如下单元：

“保护网络的安全”
“保护 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+ 应用程序的可配置管理，位于 \WINNT\system32\Com\comexp.msc。 COM+ 目录 COM+ 目录保存每一个 COM+ 应用程序的配置信息。
系统应用程序（一个 COM+ 服务器应用程序）	系统应用程序这个应用程序管理配置并跟踪 COM+ 组件。它能够从组件服务 Microsoft 管理控制台 (MMC) 查看。它还有两个相关联的角色： Administrator 和 Reader。默认状况下，管理员属于 Administrator 角色的一部分，该角色可以修改 COM+ 目录，而 Everyone 属于 Reader 角色，该角色只能读取 COM+ 目录值。
服务	COM+ 事件系统此服务须要支持 COM+ 松耦合事件 (LCE) 系统。操做系统服务（好比系统事件通知服务 (SENS) 服务）和应用程序均可能使用 LCE 系统。分布式事务协调程序 (DTC) 若是您的企业服务解决方案使用 COM+ 自动事务，则须要用到此服务。
账户	企业服务不建立任何账户。库应用程序以它们运行所在进程的身份运行。服务器应用程序能够配置为以交互用户或者特定的用户运行。（您能够在组件服务中 COM+ 应用程序 Properties 对话框的 Identity 选项卡上配置用户账户）。
日志文件	DTC 日志文件：%windir%\system32\DTCLog CRM 日志文件：%windir%\registration
注册表项	HKEY_CLASSES_ROOT\CLSID HKEY_CLASSES_ROOT\AppID

.NET Framework 安装了哪些组件？

当您安装 .NET Framework 时，将安装如下与企业服务相关的组件。

表 2 .NET Framework 企业服务工具和配置设置

项	说明
Regsvcs.exe	命令行工具，用于向 COM+ 注册企业服务组件
库	System.EnterpriseServices.dll System.EnterpriseServices.Thunk.dll System.EnterpriseServices.tlb
Machine.config 配置元素	若是您从 ASP.NET 调用企业服务，Machine.config 中的如下项将与此有关： <assemblies> 为 ASP.NET 加载 System.EnterpriseServices 程序集。 <processModel> comAuthentication 属性用于配置 ASP.NET 身份验证级。DCOM 身份验证级是在客户端（例如，Web 应用程序）和服务器（企业服务应用程序）之间协商的。使用两个安全设置中较高的一个。 comImpersonationLevel 属性配置了 ASP.NET 模拟级（对于全部输出的 DCOM 调用）。客户端决定了授予服务器的模拟功能。

为了保护组件服务基础结构，须要考虑如下几项：

修补程序和更新
服务
端口
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\dtclog

CRM 日志文件名是从企业服务应用程序 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：