在改进SQL Server 7.0系列所实现的安全机制的过程中,Microsoft建立了一种既灵活又强大的安全管理机制,它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理。按照本文介绍的步骤,你可以为SQL Server 7.0(或2000)构造出一个灵活的、可管理的安全之门,而且它的安全性经得起考验。
一、验证方法选择
本文对验证(authentication)和授权(authorization)这两个概念作不同的解释。验证是指检验用户的身份标识;授权是指允许用户做些什么。在本文的讨论中,验证过程在用户登录SQL Server的时候出现,授权过程在用户试图访问数据或执行命令的时候出现。
构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户。SQL Server的验证是把一组帐户、密码与Master数据库Sysxlogins表中的一个清单进行匹配。Windows NT/2000的验证是请求域控制器检查用户身份的合法性。一般地,如果服务器可以访问域控制器,我们应该使用Windows NT/2000验证。域控制器可以是Win2K服务器,也可以是NT服务器。无论在哪种情况下,SQL Server都接收到一个访问标记(Access Token)。访问标记是在验证过程中构造出来的一个特殊列表,其中包含了用户的SID(安全标识号)以及一系列用户所在组的SID。正如本文后面所介绍的,SQL Server以这些SID为基础授予访问权限。注意,操作系统如何构造访问标记并不重要,SQL Server只使用访问标记中的SID。也就是说,不论你使用SQL Server 2000、SQL Server 7.0、Win2K还是NT进行验证都无关紧要,结果都一样。
如果使用SQL Server验证的登录,它最大的好处是很容易通过Enterprise Manager实现,最大的缺点在于SQL Server验证的登录只对特定的服务器有效,也就是说,在一个多服务器的环境中管理比较困难。使用SQL Server进行验证的第二个重要的缺点是,对于每一个数据库,我们必须分别地为它管理权限。如果某个用户对两个数据库有相同的权限要求,我们必须手工设置两个数据库的权限,或者编写脚本设置权限。如果用户数量较少,比如25个以下,而且这些用户的权限变化不是很频繁,SQL Server验证的登录或许适用。但是,在几乎所有的其他情况下(有一些例外情况,例如直接管理安全问题的应用),这种登录方式的管理负担将超过它的优点。