Microsoft Corporation
内容简介
基于 Intranet Web 应用程序的安全性并不是不重要，因为它存在于许多控制网络中，并且对一个限制集合中的用户是可以访问的。不同个体和部门可能需要对应用程序提供的功能和数据有不同的访问等级，所以在传输过程中仍然必须保护机密数据的安全性。为了使问题复杂化，应用程序的安全性结构必须补偿任何安全性相关的问题，这些问题源于存在的基础和要配置应用程序的 Intranet 的操作特点。
通过关注某些常用分布式应用程序结构的要求，本章介绍了基于 Intranet Web 应用程序的身份验证、授权、安全通信的推荐解决方法。
目标
使用本章的目的：
• |
保护 Intranet .NET 应用程序
---|---
• |
理解安全问题和下面方案中推荐的与使用 ASP.NET Web 应用程序和 SQL Server 2000通信相关的解决方案：
| • |
直接通信
---|---
• |
使用 Enterprise Services 作为中介
• |
使用 Web 服务作为中介
• |
使用 .NET Remoting 作为中介
• |
在基于 Intranet 分布式 Web 应用程序中决定实现身份验证、授权、安全通信的最好方法。
适用于：
本章适用于下面的产品和技术：
• |
Microsoft Windows_ XP 或者 Windows 2000 Server (带有 service pack 3) 和更高版本操作系统
---|---
• |
Microsoft Internet Information Services (IIS) 5.0 和更高版本操作系统
• |
Microsoft Active Directory_ 目录服务
• |
.NET Framework 1.0 版本(带有 service pack 2) 和更高版本
• |
SQL Server 2000 (带有 service pack 2) 和更高版本
如何使用本章
为了从本章中获得最大的益处：
• |
您必须有开发和配置 ASP.NET、SQL Server、IIS 的经验。
---|---
• |
您必须有配置 Windows 安全性和 Active Directory 的经验。
• |
您必须有配置 Enterprise Services (COM+) 应用程序的经验。
• |
请参阅本指南中的“ 构建安全 ASP.NET 应用程序介绍 ”。这部分定义了分布式 Web 应用程序身份验证、授权、安全通信的重要性。
• |
请参阅本指南中的“ ASP.NET 应用程序安全性模型 ”。这部分概括阐述在创建分布式 ASP.NET Web 应用程序中使用的结构和技术，并强调身份验证、授权、安全通信适合本结构中的哪些部分。
• |
结合下面的章节使用本章，它们阐明了本章中讨论的技术：
| • |
“ How To Create a Custom Account to Run ASP.NET ”。
---|---
• |
“ How To Implement Kerberos Delegation for Windows 2000 ”。
• |
“ How To Create a DPAPI Library ”。
• |
“ How To Use DPAPI (Machine Store) from ASP.NET ”。
• |
“ How To Use DPAPI (User Store) from ASP.NET with Enterprise Services ”。
• |
“ How To Use Role-based Security with Enterprise Services ”。
• |
“ How To Set Up SSL on a Web Server ”。
• |
“ How To Use IPSec to Provide Secure Communication Between Two Servers ”。
• |
“ How To Use SSL to Secure Communication with SQL Server 2000 ”。
本页内容
 | 预备知识 |
|---|---|
| ASP.NET 到 SQL Server |
| ASP.NET 到 Enterprise Services 到 SQL Server |
| ASP.NET 到 Web Services 到 SQL Server |
| ASP.NET 到 Remoting 到 SQL Server |
| 将原调用方传递到数据库 |
| 小结 |
预备知识
对 Intranet 应用程序的访问被限制到一组有限的授权用户（例如，属于某个域的雇员）。虽然 Intranet 设置限制了应用程序的公开，但是当您制定身份验证、授权和安全通信策略时，可能仍要面临一些难题。例如，您可能包含非信任域，因此很难将调用方的安全性上下文和标识传递到系统内的后端资源。另外，您的运行环境可能是具有混合浏览器类型的异类环境。因此，更加不便使用通用身份验证机制。
如果同类 Intranet 中的所有计算机均运行 Microsoft Windows 2000 或更高版本的操作系统，并且在域中信任用户使用委派，则可以选择将原调用方的安全性上下文委派到后端。
您还必须考虑安全通信问题。尽管您的应用程序运行在 Intranet 环境中，也不能认为在网络中传送的数据是安全的。除了需要保护应用程序服务器和数据库之间传送的数据外，可能还需要保护浏览器和 Web 服务器之间传送的数据。
本章使用以下常见的 Intranet 方案来阐释主要的身份验证、授权和安全通信技术：
• |
ASP.NET 到 SQL Server
---|---
• |
ASP.NET 到 Enterprise Services 到 SQL Server
• |
ASP.NET 到 Web Services到SQL Server
• |
ASP.NET到Remoting到SQL Server
此外，本章还介绍了一个 Windows 2000 委派方案（“将原调用方传递到数据库”）。在此方案中，使用中间 Web 服务器和应用程序服务器，在操作系统级别将原调用方的安全性上下文和标识从浏览器传递到数据库。
注本章中描述的几个方案或者替换用于运行 ASP.NET 应用程序的默认 ASPNET 帐户，或者更改其密码以允许在远程计算机上创建重复的帐户。这些方案要求更新 Machine.config 中的 **
1<processmodel **=""> 元素。< **processModel** > 凭据不应该以明文形式存储在 machine.config 中。而应该使用 aspnet_setreg.exe 工具以加密凭据的形式存储在注册表中。有关详细信息请参见本指南中的“ ASP.NET安全性 ”和 Microsoft 知识库文章 Q329290 “ HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings ”（如何做：使用 ASP.NET 工具加密凭证和会话状态链接字符串）。
2
3
4
5## ASP.NET 到 SQL Server
6
7在此方案中，人力资源数据库在同类 Intranet 中安全地提供每个用户的数据。应用程序使用受信任的子系统模型并代表原调用方执行调用。应用程序使用集成 Windows 身份验证来验证调用方的身份，并使用 ASP.NET 进程标识来调用数据库。由于数据本身所具有的机密性，因此，在 Web 服务器和客户端之间使用了 SSL。
8
9**图** **1** 显示此应用程序方案的基本模型。
10
11
12
13
14**图** **1\. ASP.NET** **到** **SQL Server**
15
16### 特点
17
18本方案具有以下特点：
19
20• |
21
22客户端上安装了 Internet Explorer。
23
24---|---
25• |
26
27用户帐户位于 Active Directory 中。
28
29• |
30
31应用程序提供每个用户的机密数据。
32
33• |
34
35只有经过身份验证的客户端能够访问应用程序。
36
37• |
38
39数据库委派该应用程序对用户进行正确的身份验证（即，应用程序代表用户对数据库进行调用）。
40
41• |
42
43Microsoft SQL Server 使用单个数据库用户角色进行授权。
44
45### 保护方案
46
47在此方案中，Web 服务器验证调用方的身份，并通过使用调用方的标识限制对本地资源的访问。要限制原调用方对资源的访问，您不必在 Web 应用程序中进行模拟。数据库验证 ASP.NET 默认进程标识（它是权限最少的帐户）的身份（即数据库信任 ASP.NET 应用程序）。
48
49表 1:安全措施
50---
51类别 | 详细信息
52
53身份验证
54
55|
56
57通过在 IIS 中使用集成 Windows 身份验证，在 Web 服务器上提供增强身份验证来验证原调用方的身份。
58在 ASP.NET 内使用 Windows 身份验证（不模拟）。
59通过将 SQL Server 配置为使用 Windows 身份验证，确保数据库连接的安全。
60数据库信任 ASP.NET 辅助进程以进行调用。可以在数据库中验证 ASP.NET 进程标识的身份。
61
62授权
63
64|
65
66使用绑定到原调用方的 ACL 在 Web 服务器上配置资源。为了简化管理，将用户添加到 Windows 组中并在 ACL 中使用组。
67Web 应用程序对原调用方执行 .NET 角色检查，以限制对页面的访问。
68
69安全通信
70
71|
72
73保护在 Web 服务器和数据库之间传送的机密数据
74保护在原调用方和 Web 应用程序之间传送的机密数据
75
76### 结果
77
78**图** **2** 显示了此方案的建议安全配置。
79
80
81
82
83**图** **2\. ASP.NET** **到** **SQL Server Intranet** **方案的建议安全配置**
84
85### 安全配置步骤
86
87在开始之前，您需要查看以下内容：
88
89• |
90
91创建自定义 ASP.NET 帐户（请参见本指南中的“ How To Create a Custom Account to Run ASP.NET ”）
92
93---|---
94• |
95
96创建一个权限最少的数据库帐户（请参见本指南中的“ 数据访问安全性 ”）
97
98• |
99
100在 Web 服务器上配置 SSL（请参见本指南中的“ How To Set Up SSL on a Web Server ”）
101
102• |
103
104配置 IPSec（请参见本指南中的“ How To Use IPSec to Provide Secure Communication Between Two Servers ”）
105
106配置 IIS
107---
108步骤 | 更多信息
109
110**禁用对** Web 应用程序的虚拟根目录的匿名访问
111启用集成的 Windows 身份验证
112
113|
114
115要使用 IIS 身份验证设置，请使用 IIS MMC 管理单元。右击应用程序的虚拟目录，然后单击“属性”。
116单击“目录安全性”选项卡，然后单击“匿名访问和验证控件”组中的“编辑”。
117
118配置 ASP.NET
119---
120步骤 | 更多信息
121
122**将** ASPNET 密码更改为一个已知的强密码值
123
124|
125
126ASPNET 是权限最少的本地帐户，默认情况下用来运行 ASP.NET Web 应用程序。
127通过使用“本地用户和组”将 ASPNET 帐户的密码设置为一个已知值。
128编辑位于 %windir%\Microsoft.NET\Framework\ v1.0.3705\CONFIG 中的 Machine.config 并重新配置 < **processModel** > 元素的 **userName** 和 **password** 属性
129
130
131默认
132
133
134 <!-- userName="machine" password="AutoGenerate" -->
135
136
137成为
138
139
140 <!--
141 userName="registry:HKLM\SOFTWARE\YourSecureApp\
142 processModel\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourSecureApp\
143 processModel\ASPNET_SETREG,password" -->
144
145
146注意，使用 aspnet_setreg.exe 工具以在加密密码的形式存储在注册表中。
147
148将 ASP.NET Web 应用程序配置为使用 Windows 身份验证
149
150|
151
152编辑应用程序的虚拟根目录下的 Web.config
153将 < **authentication** > 元素设置为：
154
155确保模拟处于关闭状态
156
157|
158
159默认情况下模拟处于关闭状态；不过，请执行如下操作，再次检查以确保它在 Web.config 中是关闭的：
160
161删除 < **identity** > 元素也能达到同样的效果。
162
163配置 SQL Server
164---
165步骤 | 更多信息
166
167**在** SQL Server 计算机上创建一个与 ASP.NET 进程帐户 (ASPNET) 匹配的 Windows 帐户
168
169|
170
171用户名和密码必须与 ASPNET 帐户匹配。
172
173给予该帐户以下权限：
174\- 从网络访问此计算机
175\- 拒绝本地登录
176\- 以批处理作业登录
177
178配置 SQL Server 以便进行 Windows 身份验证
179
180|
181
182为本地 ASPNET 帐户创建一个 SQL Server 登录
183
184|
185
186这将授予对 SQL Server 的访问权限
187
188创建一个新数据库用户，并将登录名映射到数据库用户
189
190|
191
192这将授予对指定数据库的访问权限
193
194创建一个新的用户定义的数据库角色，并将数据库用户添加到该角色
195
196|
197
198建立该数据库角色的数据库权限
199
200|
201
202授予最少的权限
203有关详细信息，请参见本指南中的“ 数据访问安全性 ”。
204
205配置安全通信
206---
207步骤 | 更多信息
208
209**配置** Web 站点的 SSL
210
211|
212
213请参见本指南中的“ How To Set Up SSL on a Web Server ”。
214
215配置 Web 服务器和数据库服务器之间的 IPSec
216
217|
218
219请参见本指南中的“ How To Use IPSec to Provide Secure Communication Between Two Servers ”。
220
221### 分析
222
223• |
224
225在此方案中，由于所有用户都使用 Windows 帐户并且使用的是 Microsoft Internet Explorer，所以在 IIS 中最好使用集成 Windows 身份验证。集成 Windows 身份验证的优点是从不通过网络传送用户的密码。此外，由于 Windows 使用当前交互式用户的登录会话，所以对于用户来说登录是透明的。
226
227---|---
228• |
229
230ASP.NET 作为权限最少的帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。
231
232• |
233
234要执行 .NET 角色检查或在 Windows ACL 中针对原调用方保证资源的安全，您不必在 ASP.NET 中进行模拟。为了对原调用方执行 .NET 角色检查，按如下所示从 HTTP 上下文中检索代表原调用方的 **WindowsPrincipal** 对象：
235
236
237 WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
238 if ( wp.IsInRole("Manager") )
239 {
240 // User is authorized to perform manager-specific functionality
241 }
242
243
244ASP.NET **FileAuthorizationModule** 针对原调用方在 ACL 中检查在 IIS 中映射到 aspnet_isapi.dll 的 ASP.NET 文件类型。对于静态文件类型（例如 .jpg、.gif 和 .htm 文件），IIS 充当关守，它根据文件的相关 NTFS 权限，使用原调用方的标识执行访问检查。
245
246• |
247
248对 SQL Server 使用 Windows 身份验证意味着，不必将凭据存储在文件中并通过网络将凭据传递到数据库服务器。
249
250• |
251
252在数据库服务器上使用重复的 Windows 帐户（与 ASP.NET 本地帐户匹配的帐户）会导致增加管理负担。如果一台计算机上的密码有改动，则必须在其他计算机上同步并更新它。在某些方案中，您可能能够使用权限最少的域帐户进行更简单的管理。
253
254• |
255
256当设置防火墙时（此时 Windows 身份验证所需的端口可能没有打开），重复的本地帐户方法同样有效。在此方案中可能无法使用 Windows 身份验证和域帐户。
257
258• |
259
260您需要确保 Windows 组的粒度与您的安全要求一样。由于基于 .NET 角色的安全性以 Windows 组成员身份为基础，所以此解决方案依赖于以正确的粒度设置 Windows 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。这里用来管理角色的 Windows 组可以是此计算机的本地组或域组。
261
262• |
263
264SQL Server 数据库用户角色优先于 SQL Server 应用程序角色，这样可以避免与使用 SQL 应用程序角色有关的密码管理和连接池问题。
265
266应用程序通过用角色名和密码调用内置的存储过程，来激活 SQL 应用程序角色。因此，必须安全地存储密码。当使用 SQL 应用程序角色时，还必须禁用数据库连接池，因为它会严重影响应用程序的可伸缩性。
267
268有关 SQL Server 数据库用户角色和 SQL Server 应用程序角色的详细信息，请参见本指南中的“ 数据访问安全性 ”。
269
270• |
271
272将数据库用户添加到数据库用户角色中，并且为角色指定了权限，因此，当数据库帐户更改时，您不必更改所有数据库对象的权限。
273
274### 问与答
275
276• |
277
278**为什么我不能启用** **Web** **应用程序模拟，以便使用配置的** **ACL** **针对原调用方来保护** **Web** **应用程序所访问的资源？**
279
280如果启用模拟，则模拟的安全性上下文不具有网络凭据（假定未启用委派并且您使用的是集成 Windows 身份验证）。因此，对 SQL Server 的远程调用将使用 NULL 会话，而这将会导致调用失败。如果禁用模拟，则远程请求使用 ASP.NET 进程标识。
281
282上述方案使用 ASP.NET **FileAuthorizationModule** ，它使用 Windows ACL 针对原调用方标识执行授权，并且不要求进行模拟。
283
284如果您使用基本身份验证而不是集成 Windows 身份验证 (NTLM)，并且确实启用了模拟，则每个数据库调用都将使用原调用方的安全性上下文。每个用户帐户（或用户所属的 Windows 组）都要求使用 SQL Server 登录。需要限制 Windows 组（或原调用方）访问数据库对象的权限以确保安全性。
285
286---|---
287• |
288
289**数据库不知道谁是原始调用方。我如何能创建一条审核记录？**
290
291审核 Web 应用程序中的最终用户活动，或者将用户标识作为数据访问调用的参数明确地进行传递。
292
293### 相关方案
294
295非 Internet Explorer 浏览器
296
297对 IIS 执行集成 Windows 身份验证需要使用 Internet Explorer。在混合浏览器环境中，您的典型选项包括：
298
299• |
300
301**基本身份验证和** **SSL** **。** .大多数浏览器都支持基本身份验证。由于用户的凭据是通过网络传递的，所以必须使用 SSL 来保证此方案的安全。
302
303---|---
304• |
305
306**客户端证书。** .可以将各个客户端证书映射到唯一的 Windows 帐户，或者使用单个 Windows 帐户来代表所有客户端。T使用客户端证书还要求使用 SSL。
307
308• |
309
310表单身份验证。表单身份验证可以根据自定义数据存储（如数据库）或 Active Directory 来验证凭据。
311
312如果根据 Active Directory 进行身份验证，请确保仅检索与应用程序有关的必要的组。正如不应该使用 SELECT * 子句对数据库执行查询一样，不应盲目地从 Active Directory 中检索所有的组。
313
314如果根据数据库进行身份验证，您需要仔细分析 SQL 命令中使用的输入值，以防止 SQL 注入攻击，并且应该在数据库中存储密码哈希值（带有 salt），而不是存储明文密码或加密密码。
315
316有关使用 SQL Server 作为凭据存储和将密码存储在数据库中的详细信息，请参见本指南中的“ 数据访问安全性 ”。
317
318注意，在所有情况中，如果您没有使用集成 Windows 身份验证（其中，由平台为您管理凭据），则最后将使用 SSL。不过，此优点仅限于身份验证过程。如果您通过网络传递安全机密数据，则仍须使用 IPSec 或 SSL。
319
320### 对数据库的 SQL 身份验证
321
322在有些方案中，您可能必须使 数据访问安全性 而不是首选的 Windows 身份验证。例如，在 Web 应用程序和数据库之间可能设置了防火墙，或者由于安全原因，Web 服务器可能不属于您所在的域。这也会妨碍 Windows 身份验证。这种情况下，您可以在数据库和 Web 服务器之间使用 SQL 身份验证。为保证此方案的安全，您应该：
323
324• |
325
326使用数据保护 API (DPAPI) 来保护包含用户名和密码的数据库连接字符串。有关详细信息，请参阅以下内容：
327
328| • |
329
330请参见本指南中的“ 数据访问安全性 ”中的“安全存储数据库连接字符串”。
331
332---|---
333• |
334
335" How To Use DPAPI (Machine Store) from ASP.NET "
336
337• |
338
339" How To Use DPAPI (User Store) from ASP.NET with Enterprise Services "
340
341• |
342
343" How To Create a DPAPI Library "
344
345• |
346
347在 Web 服务器和数据库服务器之间，使用 IPSec 或 SSL 来保护通过网络传递的明文凭据。
348
349### 将原调用方传递到数据库
350
351在此方案中，使用原调用方的安全性上下文从 Web 应用程序调用数据库。使用此方法时，一定要注意以下几点：
352
353• |
354
355如果选择此方法，则需要使用 Kerberos 身份验证（将帐户配置为使用委派）或基本身份验证。
356
357本章后面的“ 将原调用方传递到数据库 ”部分讨论了委派方案。
358
359---|---
360• |
361
362还必须在 ASP.NET 中启用模拟。这意味着使用原调用方的安全性上下文执行本地系统资源访问，因此需要正确地配置本地资源（例如注册表和事件日志）的 ACL。
363
364• |
365
366由于原调用方无法共享连接，因此数据库连接池受到限制。每个连接都与调用方的安全性上下文关联。
367
368• |
369
370另一种传递用户安全性上下文的方法是在应用程序级别传递原调用方的标识（例如，通过使用方法和存储过程参数）。
371
372
373
374## ASP.NET 到 Enterprise Services 到 SQL Server
375
376在此方案中，ASP.NET 页面调用 Enterprise Services 应用程序中驻留的业务组件，而 Enterprise Services 应用程序又连接到数据库上。例如，请看一个内部定单系统，它通过 Intranet 进行交易并允许内部部门下定单。 **图** **3** 中显示了此方案。
377
378
379
380
381**图** **3\. ASP.NET** **会在** **Enterprise Services** **中调用一个组件，该组件将调用该数据库**
382
383### 特点
384
385本方案具有以下特点：
386
387• |
388
389用户安装了 Internet Explorer。
390
391---|---
392• |
393
394在 Web 服务器上部署了组件。
395
396• |
397
398应用程序处理机密数据，在传输过程中必须保护这些数据的安全。
399
400• |
401
402业务组件使用 Windows 身份验证连接到 SQL Server。
403
404• |
405
406基于调用方的标识来限制这些组件中的业务功能。
407
408• |
409
410将服务组件配置为服务器应用程序（进程外）。
411
412• |
413
414件使用服务器应用程序的进程标识连接到数据库。
415
416• |
417
418在 ASP.NET 中启用模拟（确保基于 Enterprise Services 角色的安全性）。
419
420### 保护方案
421
422在此方案中，Web 服务器验证原调用方的身份，并将调用方的安全性上下文传递到服务组件。服务组件基于原调用方的标识授予业务功能的访问权限。数据库根据 Enterprise Service 应用程序的进程标识进行身份验证（即数据库信任 Enterprise Services 应用程序中的服务组件）。当服务组件调用数据库时，它在应用程序级别传递用户的标识（通过使用受信任的查询参数）。
423
424表 2:安全措施
425---
426类别 | 详细信息
427
428身份验证
429
430|
431
432使用集成 Windows 身份验证在 Web 服务器上提供增强身份验证。
433将原调用方的安全性上下文传递到服务组件以支持 Enterprise Services (COM+) 角色检查。
434使用 Windows 身份验证保护数据库连接的安全。
435数据库信任服务组件的标识以调用数据库。数据库验证 Enterprise Services 应用程序进程标识的身份。
436
437授权
438
439|
440
441使用 Enterprise Services (COM+) 角色授予业务逻辑的访问权限。
442
443安全通信
444
445|
446
447使用 SSL 保护用户和 Web 应用程序之间传送的机密数据。
448使用 IPSec 保护在 Web 服务器和数据库之间传送的机密数据。
449
450### 结果
451
452**图** **4** 显示了此方案的建议安全配置。
453
454
455
456
457**图** **4\. ASP.NET** **到本地** **Enterprise Services** **到** **SQL Server** **的** **Intranet** **方案的建议安全配置**
458
459### 安全配置步骤
460
461在开始之前，您需要查看以下内容：
462
463• |
464
465创建一个权限最少的数据库帐户（请参见本指南中的“ 数据访问安全性 ”）
466
467---|---
468• |
469
470在 Web 服务器上配置 SSL（请参见本指南中的“ How To Set Up SSL on a Web Server ”）
471
472• |
473
474Configuring IPSec (see the module, " How To Use IPSec to Provide Secure Communication Between Two Servers ")
475
476• |
477
478配置 IPSec（请参见本指南中的“ How To: Use Role-Based Security with Enterprise Services ”）
479
480配置 IIS
481---
482步骤 | 更多信息
483
484**禁用对** Web 应用程序的虚拟根目录的匿名访问
485
486启用集成的 Windows 身份验证
487
488|
489
490配置 ASP.NET
491---
492步骤 | 更多信息
493
494将 ASP.NET Web 应用程序配置为使用 Windows 身份验证
495
496|
497
498编辑应用程序的虚拟根目录下的 Web.config
499将 < **authentication** > 元素设置为：
500
501配置 ASP.NET Web 应用程序的模拟
502
503|
504
505编辑 Web 应用程序的虚拟目录下的 Web.config
506将 < **identity** > 元素设置为：
507
508配置 ASP.NET DCOM 安全性，确保 Enterprise Services 调用支持调用方模拟
509
510|
511
512编辑 Machine.config 并找到 < **processModel** > 元素。确认将 **comImpersonationLevel** 属性设置为 **Impersonate** （默认设置）
513
514
515 < comImpersonationLevel="Impersonate">
516
517
518配置 Enterprise Services
519---
520步骤 | 更多信息
521
522**创建一个用于运行** Enterprise Services 的自定义帐户
523
524|
525
526**注** 如果使用本地帐户，则还必须在 SQL Server 计算机上创建一个重复的帐户。
527
528将 Enterprise Services 应用程序配置为服务器应用程序
529
530|
531
532这可以通过使用“组件服务”工具，或通过位于服务组件程序集中的以下 .NET 属性进行配置。
533
534
535 [assembly: ApplicationActivation(ActivationOption.Server)]
536
537
538配置 Enterprise Services (COM+) 角色
539
540|
541
542使用“组件服务”工具或脚本将 Windows 用户和/或组添加到角色中。
543可以使用服务组件程序集中的 .NET 属性来定义角色。
544
545将 Enterprise Services 配置为以自定义帐户运行
546
547|
548
549必须使用“组件服务”工具或脚本进行配置。不能使用服务组件程序集中的 .NET 属性。
550
551配置 SQL Server
552---
553步骤 | 更多信息
554
555**在** SQL Server 计算机上创建一个与 Enterprise Services 进程帐户匹配的 Windows 帐户
556
557|
558
559用户名和密码必须匹配自定义 Enterprise Services 帐户。
560给予该帐户以下权限：
561\- 从网络访问此计算机
562\- 拒绝本地登录
563\- 以批处理作业登录
564
565配置 SQL Server 以便进行 Windows 身份验证
566
567为 Enterprise Services 帐户创建一个 SQL Server 登录
568
569|
570
571这将授予对 SQL Server 的访问权限。
572
573创建一个新数据库用户，并将登录名映射到数据库用户
574
575|
576
577这将授予对特定数据库的访问权限。
578
579创建一个新的数据库用户角色，并将数据库用户添加给该角色
580
581|
582
583建立数据库用户角色的数据库权限
584
585|
586
587授予最少的权限
588有关详细信息，请参见本指南中的“ 数据访问安全性 ”。
589
590配置安全通信
591---
592步骤 | 更多信息
593
594**配置** Web 站点的 SSL
595
596|
597
598请参见本指南中的“ How To Set Up SSL on a Web Server ”。
599
600配置 Web 服务器和数据库服务器之间的 IPSec
601
602|
603
604请参见本指南中的“ How To: Use IPSec to Provide Secure Communication Between Two Servers ”。
605
606### 分析
607
608• |
609
610ASP.NET 和 Enterprise Services 作为权限最少的帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。当任何一方的进程标识遭到攻击时，由于帐户仅具有有限的权限，因此缩小了危害的范围。另外，在 ASP.NET 中，如果注入了恶意脚本，也可以限制潜在的危害。
611
612---|---
613• |
614
615要将原调用方的安全性上下文传递到 Enterprise Services 组件（以支持基于 Enterprise Services (COM+) 角色的授权），必须配置 ASP.NET 应用程序以支持模拟。如果不进行模拟，则对进程标识（即 ASP.NET 辅助进程）进行角色检查。模拟影响被授予资源访问权限的对象。
616
617• |
618
619在未进行模拟时，针对 ASP.NET 进程标识进行系统资源检查。在进行模拟时，针对原调用方进行系统资源检查。有关从 ASP.NET 访问系统资源的详细信息，请参见本指南中的“ ASP.NET安全性 ”。
620
621• |
622
623通过使用 Enterprise Services (COM+) 角色，将访问检查推到中间层（业务逻辑所在的位置）进行。在这种情况下，在入口处检查调用方，将其映射到角色，以及基于角色调用业务逻辑。这可避免不必要的后端调用。Enterprise Services (COM+) 角色的另一优点是：可以在部署时使用组件服务管理器创建和管理角色。
624
625• |
626
627对 SQL 的 Windows 身份验证意味着，可以避免在文件中存储凭据并通过网络进行传送。
628
629• |
630
631当设置了防火墙时（此时 Windows 身份验证所需的端口可能没有打开），仍然可以使用本地帐户运行 Enterprise Services 应用程序，以及在数据库服务器上使用重复的帐户。在此方案中可能无法使用 Windows 身份验证和域帐户。
632
633### 缺陷
634
635• |
636
637在数据库服务器上使用重复的 Windows 帐户（与 Enterprise Services 进程帐户匹配的帐户）会导致增大管理负担。密码应当定期手动更新并同步。
638
639---|---
640• |
641
642由于基于 .NET 角色的安全性以 Windows 组成员身份为基础，此解决方案依赖于以正确的粒度设置 Windows 组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。
643
644
645
646## ASP.NET 到 Web Services 到 SQL Server
647
648在此方案中，运行 ASP.NET 页的 Web 服务器连接到远程服务器上的 Web 服务。该服务器又连接到远程数据库服务器。例如，请看一个提供用户特定机密数据的人力资源 Web 应用程序。此应用程序依赖 Web 服务进行数据检索。图 5 显示了此应用程序方案的基本模型。
649
650
651
652
653**图** **5\. ASP.NET** **到远程** **Web** **服务到** **SQL Server**
654
655**Web** **服务公开一个允许个别雇员检索他或她的个人详细信息的方法。必须使用** **Web** **应用程序只给通过身份验证的个人提供详细信息。** **Web** **服务还提供了一个支持任何雇员详细信息检索的方法。只有人力资源或工资部门的成员可以使用此功能。在此方案中，将雇员分为三个** **Windows** **组：**
656
657• |
658
659**HRDept** （人力资源部门的成员） 该组的成员可以检索有关任何雇员的详细信息。
660
661---|---
662• |
663
664**PayrollDept** （工资部门的成员） 该组的成员可以检索有关任何雇员的详细信息。
665
666• |
667
668**Employees** （所有雇员） 该组的成员只能检索他们自己的详细信息。
669
670由于数据本身所具有的保密性，应保证所有节点之间通信的安全。
671
672### 特点
673
674• |
675
676用户安装了 Internet Explorer 5.x 或更高版本。
677
678---|---
679• |
680
681所有计算机运行的都是 Windows 2000 或更高版本。
682
683• |
684
685用户帐户位于单一目录林的 Active Directory 中。
686
687• |
688
689应用程序将原调用方的安全性上下文一直传递到数据库。
690
691• |
692
693所有层都使用 Windows 身份验证。
694
695• |
696
697将域用户帐户配置为使用委派。
698
699• |
700
701数据库不支持委派。
702
703### 保护方案
704
705在此方案中，驻留 ASP.NET Web 应用程序的 Web 服务器验证原调用方的标识，并将它们的安全性上下文传递到驻留 Web 服务的远程服务器。这样就可以对 Web 方法应用授权检查，以允许或拒绝对原调用方的访问。数据库验证 Web 服务进程标识的身份（数据库信任 Web 服务）。Web 服务反过来调用数据库，并使用存储过程参数在应用程序级别传递用户的标识。
706
707表 3:安全措施
708---
709类别 | 详细信息
710
711身份验证
712
713|
714
715Web 应用程序在 IIS 中使用集成 Windows 身份验证来验证用户的身份。
716Web 服务在 IIS 中使用集成 Windows 身份验证。它对 Web 应用程序所委派的原调用方安全性上下文进行身份验证。
717可以使用 Kerberos 身份验证协议，通过委派将原调用方安全性上下文从 Web 应用程序传递到 Web 服务。
718可以使用 Windows 身份验证，通过 ASP.NET 进程帐户连接到数据库。
719
720授权
721
722|
723
724Web 应用程序对原调用方执行角色检查，以限制对页面的访问。
725通过使用基于原调用方 Windows 组成员身份的 .NET 角色，控制对 Web 服务方法的访问。
726
727安全通信
728
729|
730
731可通过使用 SSL 来保护在原调用方和 Web 应用程序及 Web 服务之间传送的机密数据。
732可通过使用 IPSec 来保护在 Web 服务和数据库之间传送的机密数据。
733
734### 结果
735
736**图** **6** 显示了此方案的建议安全配置。
737
738
739
740
741**图** **6\. ASP.NET** **到** **Web** **服务到** **SQL Server** **的** **Intranet** **方案的建议安全配置**
742
743### 安全配置步骤
744
745在开始之前，您需要查看以下内容：
746
747• |
748
749在 Web 服务器上配置 SSL（请参见本指南中的“ How To Set Up SSL on a Web Server ”）
750
751---|---
752• |
753
754配置 IPSec （请参见本指南中的“ How To Use IPSec to Provide Secure Communication Between Two Servers ”）
755
756配置 Web 服务器（它驻留 Web 应用程序）
757---
758配置 IIS |
759
760**步骤**
761
762|
763
764**更多信息**
765
766禁用对 Web 应用程序的虚拟根目录的匿名访问
767
768对 Web 应用程序的虚拟根目录启用 Windows 集成身份验证
769
770|
771
772**配置** **ASP.NET**
773
774|
775
776**步骤**
777
778|
779
780**更多信息**
781
782将 ASP.NET Web 应用程序配置为使用 Windows 身份验证
783
784|
785
786编辑 Web 应用程序的虚拟目录下的 Web.config
787将 < **authentication** > 元素设置为：
788
789配置 ASP.NET Web 应用程序的模拟
790
791|
792
793编辑 Web 应用程序的虚拟目录下的 Web.config
794将 < **identity** > 元素设置为：
795
796配置应用程序服务器（它驻留 Web 服务）
797---
798配置 IIS |
799
800**步骤**
801
802|
803
804**更多信息**
805
806禁用对 Web 服务的虚拟根目录的匿名访问
807
808对 Web 服务的虚拟根目录启用 Windows 集成身份验证
809
810|
811
812**配置** **ASP.NET**
813
814|
815
816**步骤**
817
818|
819
820**更多信息**
821
822将 ASPNET 密码更改为一个已知值
823
824|
825
826ASPNET 是权限最少的本地帐户，默认情况下用来运行 ASP.NET Web 应用程序。
827通过使用本地用户和组将 ASPNET 帐户的密码改为一个已知值。
828编辑位于 %windir%\Microsoft.NET\Framework\ v1.0.3705\CONFIG 中的 Machine.config
829并重新配置 < **processModel** > 元素的 **userName** 和 **password** 属性：默认值
830
831
832 <!-- userName="machine" password="AutoGenerate" -->
833<!--
834 userName="registry:HKLM\SOFTWARE\YourSecureApp\
835 processModel\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourSecureApp\
836 processModel\ASPNET_SETREG,password" -->
837
838
839将 ASP.NET Web 服务配置为使用 Windows 身份验证
840
841|
842
843编辑 Web 服务的虚拟目录下的 Web.config
844将 < **authentication** > 元素设置为：
845
846确保模拟处于关闭状态
847
848|
849
850默认情况下模拟处于关闭状态；不过，请执行如下操作，再次检查以确保它在 Web.config 中是关闭的：
851
852<P</processmodel>