ASP.NET2.0数据库之SQL Server安全性

7/13/2006来源:ASP.NET技巧人气:10441

  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模式。

  表3-1总结了这些模式之间的区别。

  表3-1

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。最好使用不少于七位的字符并确保使用字母、数字和符号的混和形式。在学生练习之外的大多数情况下,需要为每个数据库和应用程序指定一个账户。应避免让一个应用程序拥有可以访问其他应用程序数据的权限。