在ASP.NET2.0中结合数据库SQL Server相关安全性的阐述
SQL Server的安装有两个关于安全模式的选项。它们之间的差别在于由哪一个软件执行认证过程。认证是一个确认将要连接SQL Server的用户身份的过程。一旦执行了认证，SQL Server就能验证这个用户是否具有许可来连接一个被请求的资源，例如一个数据库。如果用户具有连接数据库的许可，那么SQL Server将允许连接请求成功，否则，连接失败。这个验证用户许可的过程还被称为授权。
· Windows Authentication(还被称为Trusted Authentication或者Integrated Security)使用进行连接请求过程的Windows用户身份来执行对数据库的授权。在这种情况下，连接字符串不必提供显式的用户名和密码。ASP.NET以一个名为"ASPNET"的本地用户来运行(或者在IIS 6.0当中使用用户名"Network Service")，所以当使用Windows Authentication时，SQL将会检查这个用户是否拥有使用数据库的许可。此时，所有的ASP.NET应用程序都用这个相同的用户运行，所以该安全模式对这些应用程序一视同仁。虽然可以在单独的ASP.NET进程中运行每一个应用程序(单独的用户运行每个程序)，或者可以模拟进行连接请求的浏览器客户的Windows用户身份，但是这些内容都超出了本书所要讲述的范围。不过，客户模拟的情况在Web应用程序中是Windows Authentication最常见的使用方式。
· SQL Authentication针对在SQL Server内配置的用户来检查显式提供的用户名和密码(无需涉及操作系统)。在这种情况下，在ASP.NET进程中运行的每个应用程序都能以单独的证书来连接数据库，这样就把应用程序合理地隔离开了(应用程序A如果没有B的用户名和密码就不能连接至B的数据库)。这是用于部署的Web应用程序的最常见认证模式，特别是在共享宿主的情况下。它的一个小缺点就是需要应用程序保留用于连接的用户账户的密码，并且如果该密码被恶意用户获取，那么将危及数据库的安全。但是，在本书后面将会看到，ASP.NET提供了一个安全的方式，将SQL Authentication密码以加密的格式保存在Web.config文件中，这样就降低了密码被获取的风险。
· Mixed Mode是SQL Server的配置，它既允许Windows Authentication，也允许SQL Authentication。
在安装SQL Server或者SSE时，要选择一种认证模式。在SQL Server中，有向导会在安全步骤中帮助选择，而在SSE中，默认选择是Windows Authenti cation。如果要安装SQL Authentication，就必须显式地配置。本文使用的是Windows Authentication。
如果已经安装了SQL Server或者SSE，就能通过打开RegEdit来查看所指定的认证模式(当然需要先备份)，找到HKey_Local_Machine/Software/Microsoft/Microsoft SQL Server并搜索LoginMode。值为1的注册子键表示Windows Auth entication，而值2表示Mixed Authentication模式。
Windwos Authentication
SQL Authentication
可替换名称
Trusted Authentication
Integrated Security
没有，但是Mixed Mode Authen tication允许使用Windows或者SQL Authentication
典型环境
内部网
因特网
用户和认证过程列表的位置
Windows
SQL Server
SSE安装
默认安装
需要指定安装
连接字符串
Trusted_connection=true或者Integrated Security=true
user=username;
password=password
ASP.NET Web应用程序的用户
ASP.NET进程、ASPNET(IIS 5.x)或者Network Service(IIS 6)
SQL用户
优势
较好的安全性；可以对用户在SQL事件和Windows事件中的活动进行跟踪
无需创建新账户即可在宿主机上部署；独立于操作系统
宿主的内部网站点只需一般技术
为应用程序提供更加灵活的方式以不同的证书来连接每个数据库
劣势
给予Web应用程序Windows证书有可能会将OS中的权限范围设置过大
密码存储在Web应用程序中(在Windows认证中则不是)。确认密码保存在Web.config文件中并已加密。
允许使用sa证书的Web应用程序的低级操作。总是为ASP.NET Web应用程序创建新的证书并只给予所需的权限
现在，知道了SQL使用安全的方式，我们来考虑数据使用者(DataSource控件)将如何满足需求。首先，使用从VWD和VWD Web Server(Cassini)获取的数据，主要是在设计和测试的时候。第二，在部署之后应当从IIS访问数据。这两个数据使用者有不同的用户名。VWD和VWD Web Server使用登录进Windows的人员的名称，而IIS程序使用名称ASPNET。
如果SQL Server使用Windows认证，那么SqlDataSource控件需要在连接字符串中包含如下代码：Integrated Security=true(或者Trusted_connection=true)。这个参数将指示SQL Server根据请求者的Windows登录账户对数据请求进行认证。如果是登录安装SSE的用户，其证书将授予访问SSE的权限。使用VWD和VWD Web Server将一切顺利，因为VW Web Server的用户被认为是登录进Windows的程序人员，于是具有SSE上的账户。但是，即使是应用程序在VWD之外工作正常，当站点迁移至IIS后，也会不正常。IIS是在名为ASPNET的用户账户下运行的(或者是在IIS6/Windows 2003 Server中的Network Service)。因此，运行着IIS的机器的管理员必须添加ASP.NET用户并授予其许可。这个过程超出了本书讲解的范围，但是在很多IIS管理员手册中都有详细的描述。总而言之，如果SQL Server使用的是Windows认证，就能使用VWD和VWD Web Server进行本书的练习。只有在授予了访问数据库的ASP.NET进程账户许可之后，您的页面才可以在IIS上运行。
如果SQL Server使用的是SQL认证，SQL将进行自己的认证过程。这个过程将不依靠Windows的用户列表。连接字符串中包含了两个参数：user=username， password=password。现在就可以从VWD、VWD Web Server或者IIS中使用页面了，因为不需要在Windows中创建用户账户。但是，我们还要使用SQL Server中的账户。惟一的默认账户是sa。在部署之前，应当在SQL Server中创建另外一个账户，该账户只拥有执行ASPX页面的权限。如果不创建sa以外的替换账户(和密码以保护sa)，那么将会使站点处于最知名、最易于利用的安全漏洞之中。任何黑客都知道使用空密码的userID='sa'来登录。
对两种认证模式来说，当使用前面所述的连接字符串时，用户将以初始账户登录进SQL Server。这个账户就是sa，表示系统管理员，从名称上可以看出，它具有对所有对象的所有权限。在当前的SQL Server版本中，不能以密码为NULL的sa来安装服务。而在SSE中，必须以参数SAPWD="MyStrongPassword"来安装。这里的强密码表示至少不为NULL。最好使用不少于七位的字符并确保使用字母、数字和符号的混和形式。在学生练习之外的大多数情况下，需要为每个数据库和应用程序指定一个账户。应避免让一个应用程序拥有可以访问其他应用程序数据的权限。