开发人员从SQL Server 6.5升级到SQL Server 7.0应该注意哪些问题？ 对于一般帐号来说升级程序工作得非常棒。在升级到SQL Server 7.0过程中，SQL Server 6.5中的别名被转换成角色成员。例如，如果你的一个别名是“dbo”， SQL Server将把你作为“db_owner”固定服务器角色中的成员。如果你有数个登录名别名是“sales”， SQL Server 7.0升级程序将创建一个“sales”角色，并为这些用户创建帐号，然后把他们都放入到“sales”角色中。SQL Server 6.5中的“sales”帐号所拥有的权限中被分配给SQL Server 7.0中的“sales”角色。升级过程中SQL Server还清理系统权限的模式位，以消除重复的权限。
比较困难的情况是有人可能会把来自不同机器的10个数据库恢复到单个的SQL Server中，然后再升级。在SQL Server 6.5中，用户帐号必须匹配master数据库中的“syslogins”系统表和每个数据库中的“sysusers”系统表。不幸的是，当你在SQL Server 6.5中恢复来自其他服务器的数据库时，它们不能够匹配。当这种情况下数据库被恢复后，其安全系统已经损坏，升级到SQL Server 7.0后仍然是损坏的。
诀窍是在升级前保证你的SQL Server 6.5系统是工作良好的。升级前你还应该运行“sp_change_users_login”系统存储过程来确保数据库用户和登录名存在正确的映射关系。
使用SQL Server 7.0建立一个安全的数据库的最好方法是什么？ 永远不要给用户直接访问表的权限。如果你希望让用户使用交互式工具如Microsoft Acess 2000来访问数据库，可以只给他们访问视图和存储过程的权限，而不是对表的直接访问权限。如果存储过程的拥有者是“dbo”，而且存储过程所引用的表和视图的拥有者也都是“dbo”，给予用户对存储过程的执行（EXECUTE）权限就足够了。这样就根本不用检查对表的访问权限了。
你还可以使用其它安全特性，比如通过在存储过程中加入商业逻辑来控制哪些字段或行能够被访问。视图是阻止用户直接访问表的另一种途径。与存储过程的区别是，你可以为视图授予SELECT、INSERT、UPDATE或DELETE权限，而存储过程则只能授予EXECUTE权限。
还有一件需要注意的事情是，如果你在另外一个数据库中执行SELECT语句，数据库对象拥有者的的链式关系仍然适用。比如说，在由SQL Server登录名“sa”所拥有的pubs数据库中，你就不能执行跨表查询连接至被一个NT登录名所拥有的数据库中，即使两个登录名都是“sysadmin”角色的成员。如果你希望连接来自3个不同数据库的表，那么这3个数据库的拥有者应该是同一个帐号。如果需要的话你可以使用存储过程“sp_changedbowner”来改变数据库的拥有者。
还有其它值得提到的新特性吗？
我们还增加了DENY语句，可以被管理员用来禁止某个用户对一个对象的所有访问权限。在SQL Server 6.5中你可以在一行上运行两次REVOKE语句来在某种程度上仿效DENY语句。
在SQL Server 7.0中，如果你想阻止某人查看某一个表，你可以使用DENY来禁止他的SELECT权限。使用DENY语句时应当非常小心。举个例子：假如你在AUTHORS表上有SELECT和INSERT的权限，而且作为某个NT组的成员，你还拥有UPDATE权限。然而，你所在的另一个NT组被DENY语句禁止了INSERT和UPDATE权限。结果是，你只有SELECT权限了。DENY语句会禁止对数据库对象的访问，因此你要确保没有对PUBLIC组使用DENY语句，因为任何用户都总是PUBLIC组中的成员。许多没有经验的管理员这样做了，然后他们只好打电话来向我们求助。
DENY不仅可以用于数据库对象，它还可以用于登录名。例如，你授予了NT组“domain users”登录到SQL Server的权限。Joe刚刚被解雇了但是他还不知道。你不能简单地使用REVOKE语句来取消Joe的登录权限，因为他没有被单独授予登录权限，而是和其他成员一起作为“domain users”组中的一个成员被一起授予登录权限。这时你就可以特别地对Joe使用DENY语句。这样他不能登录到SQL Server了，而同一个组的其他成员仍然可以。
应用程序角色是如何工作的？
可能解释应用程序角色的最好方式是在实际情况中说明。比方说你想做一个职工工资单的应用程序，可以允许用户更新工资。当然你不希望允许用户简单地登录到SQL Server中然后更改工资。如果雇员能够那样做的话，他就可能试图去更改他自己的工资了。更合适的方法是使用一个工资单应用程序，它能够执行特定的安全检查，例如，不允许用户更新他们自己的工资。
它是这样工作的。你的工资单应用程序以使用者的安全级别登录到SQL Server，以便服务器审计追踪工具能够知道到底是谁在登录到SQL Server。然后你的应用程序切换到适当的数据库并调用系统存储过程“sp_setapprole”来启动应用程序角色。应用程序角色是受密码保护的，所以你需要把密码作为参数传递给sp_setapprole。当数据在网上传输时，你也可以对密码进行加密。
一旦启动了应用程序角色，用户现有的权限被关闭，应用程序角色的安全权限被相应打开。你的应用程序现在就可以使用应用程序角色来执行修改数据库的操作了。
需要注意的一个问题是，应用程序角色是特定于连接的。假如你同时打开了两个到SQL Server的连接，你必须保证每个连接的应用程序角色都被打开了。使用应用程序角色时，一旦打开连接并转换到适当的数据库后，第一件事情就是调用“sp_setapprole”存储过程。如果不启动应用程序角色，你就不能够访问任何应用程序角色所专有的数据。
在SQL Server 7.0中，角色是一个新概念。使用数据库角色有什么意义呢？
我们新增了7个固定的服务器角色和9个固定的数据库角色。服务器角色是分散系统管理员工作的一个办法。在SQL Server 6.5和更早的版本中，有一个叫做“sa”的帐号，这个帐号可以在数据库服务器上做任何事情。在那时，你可以有10个Windows NT用户被映射成“sa”，这意味着这10个用户都可以在任何时间做任何事情，然而服务器审计工具只会记录成“sa”的操作。你没有任何办法来确认到底是谁做了什么操作。
SQL Server 7.0改进了这一点。不是像以前那样使“sa”具有所有的特权，权限是通过角色成员来获得的。我们还把系统管理员的特权划分成了多个角色。例如，为了在SQL Server 7.0中让某人获得系统管理员权限，你只需要把他加入到“sysadmin”这个固定服务器角色中即可。
还有其它角色，例如“dbcreator”是用来创建和更改数据库的；“securityadmin”是用来增加新的登录或者重置缺省数据库的。“sa”登录仍然存在，是为了保持向后兼容性。但该权限是通过成为“sysadmin”角色中的成员来获得的。服务器的审计追踪功能将根据你的Windows NT或者SQL Server登录名来跟踪所做的改变，而不管分配给该帐号的安全特权。
在单个数据库这一级别上情况也非常相似。在以前版本中，人们会把自己化名为“dbo”来获得对数据库的所有权限。现在用户可以被分配成“db_owner”角色，同样可以拥有对单个数据库的完全控制权限。而且，还有更具体的角色，比如“db_acessadmin”用来控制对数据库的访问，“db_securityadmin”用来给予其他用户访问权限，“db_backupoperator”用于备份数据。我们还增加了用户自定义的和应用程序角色，而且允许用户可以同时成为多个数据库角色的成员。
与Windows NT集成是使SQL Server 7.0安全性更易于实施还是使它更为强健呢？
两者都是。你应该使用7.0版的集成安全的原因之一就是，6.5及更早版本的标准安全模式没有提供一些最基本的功能。
关于安全方面的一个基本原则就是口令应该在一定的时间后过期。SQL Server标准安全模式没有这个功能。另外，它也不禁止为空的口令，不要求口令必须长于一定数目的字符，也不提供任何其它高级口令管理功能。我们希望能够利用Windows NT，它已经包括所有这些功能。现在，当你锁定使用Windows NT的口令政策时，你通过集成安全同时也锁定了SQL Server。从这个角度来说，它确实增强了安全性。
从使用的角度来说，增加整个域的用户到SQL Server中去要比以前容易的多，而且该过程是动态的。在SQL Server 6.5中，如果你使用SQL Server的安全管理器来增加一组用户，它将列举在那个组中的所有用户。假如该NT组中有人被新增或者被删除，你必须重新执行以上的操作。而现在呢，举个例子：假如你把“domain user”组加入作为一个SQL Server登录，而“domain user”这个NT组中有用户被删除，你不需要在SQL Server中做任何改动来防止该用户获得对SQL Server的
你认为SQL Server 7.0与以前的版本相比，安全模式中最重要的改变是什么？
应该是它与Windows NT的完全集成。在SQL Server 6.5及更早的版本中，与Windows NT的安全集成是不是直接处理的。
在SQL Server 6.5中由两个选择。你要么是系统管理员，要么是普通用户。如果你对SQL Server的主注册表项有完全的控制权限，那么你是以“sa”登录的，即系统管理员。对于某些IT机构来说，这样做就下放了太多的控制权限。在另一方面，如果你对主注册表项只有只读权限，SQL Server把你作为一个映射登录来处理，即在你的Windows NT登录名和SQL Server登录名之间的映射。
从实际操作上来说，你不需要登录两次，即登录到Windows NT后再登录到SQL Server。但事实上在SQL Server 6.5中你仍然在使用标准安全模式登录，而没有使用Windows NT安全模式。当你使用Windows NT组用户身份登录时，在该NT组的所有人都被映射到相同的SQL Server 7.0登录。否则的话该组的每个用户都需要单独的登录。这导致了大量额外的数据库管理任务。
在SQL Server 7.0中我们最重要的目标就是与Windows NT安全性完全集成。我们把所有的安全特性都集成到SQL Server自身。当你登录到SQL Server，数据库管理系统将检查你的实际Windows NT访问标识，把你的主安全标识号（SID）和相关的从安全表识号列表映射到SQL Server 7.0 Master数据库的sysxlogins表中的登录名。总的说来就是SQL Server 7.0直接使用Windows NT的安全机制，去掉了以前附加的映射层。这意味着大量减少了用于安全管理的时间、减少了出错的可能而且它确实可以很好地工作。
责任编辑：小草
