24 SQL数据库安全规划

《24 SQL数据库安全规划》由会员分享，可在线阅读，更多相关《24 SQL数据库安全规划（8页珍藏版）》请在装配图网上搜索。

1、1、SQL Server数据库安全规划全攻略 在改进SQL Server 7.0系列所实现的安全机制的过程中，Microsoft建立了一种既灵活又强大的安全管理机制，它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理。按照本文介绍的步骤，你可以为SQL Server 7.0（或2000）构造出一个灵活的、可管理的安全策略，而且它的安全性经得起考验。/from 一、验证方法选择 本文对验证（authentication）和授权（authorization）这两个概念作不同的解释。验证是指检验用户的身份标识；授权是指允许用户做些什么。在本文的讨论中，验证过程在用户登录SQL

2、 Server的时候出现，授权过程在用户试图访问数据或执行命令的时候出现。 构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户。SQL Server的验证是把一组帐户、密码与Master数据库Sysxlogins表中的一个清单进行匹配。Windows NT/2000的验证是请求域控制器检查用户身份的合法性。一般地，如果服务器可以访问域控制器，我们应该使用Windows NT/2000验证。域控制器可以是Win2K服务器，也可以是NT服务器。无论在哪种情况下，SQL Server都接收到一个访问标记（Access Token）。访问标记是在验证过程中构造出来的一个特殊列表，其中

3、包含了用户的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进

4、行验证的第二个重要的缺点是，对于每一个数据库，我们必须分别地为它管理权限。如果某个用户对两个数据库有相同的权限要求，我们必须手工设置两个数据库的权限，或者编写脚本设置权限。如果用户数量较少，比如25个以下，而且这些用户的权限变化不是很频繁，SQL Server验证的登录或许适用。但是，在几乎所有的其他情况下（有一些例外情况，例如直接管理安全问题的应用），这种登录方式的管理负担将超过它的优点。 /from 二、Web环境中的验证 即使最好的安全策略也常常在一种情形前屈服，这种情形就是在Web应用中使用SQL Server的数据。在这种情形下，进行验证的典型方法是把一组SQL Server登录名称

5、和密码嵌入到Web服务器上运行的程序，比如ASP页面或者CGI脚本；然后，由Web服务器负责验证用户，应用程序则使用它自己的登录帐户（或者是系统管理员sa帐户，或者为了方便起见，使用Sysadmin服务器角色中的登录帐户）为用户访问数据。 这种安排有几个缺点，其中最重要的包括：它不具备对用户在服务器上的活动进行审核的能力，完全依赖于Web应用程序实现用户验证，当SQL Server需要限定用户权限时不同的用户之间不易区别。如果你使用的是IIS 5.0或者IIS 4.0，你可以用四种方法验证用户。第一种方法是为每一个网站和每一个虚拟目录创建一个匿名用户的NT帐户。此后，所有应用程序登录SQL S

6、erver时都使用该安全环境。我们可以通过授予NT匿名帐户合适的权限，改进审核和验证功能。 第二种方法是让所有网站使用Basic验证。此时，只有当用户在对话框中输入了合法的帐户和密码，IIS才会允许他们访问页面。IIS依靠一个NT安全数据库实现登录身份验证，NT安全数据库既可以在本地服务器上，也可以在域控制器上。当用户运行一个访问SQL Server数据库的程序或者脚本时，IIS把用户为了浏览页面而提供的身份信息发送给服务器。如果你使用这种方法，应该记住：在通常情况下，浏览器与服务器之间的密码传送一般是不加密的，对于那些使用Basic验证而安全又很重要的网站，你必须实现SSL（Secure S

7、ockets Layer，安全套接字层）。 在客户端只使用IE 5.0、IE 4.0、IE 3.0浏览器的情况下，你可以使用第三种验证方法。你可以在Web网站上和虚拟目录上都启用NT验证。IE会把用户登录计算机的身份信息发送给IIS，当该用户试图登录SQL Server时IIS就使用这些登录信息。使用这种简化的方法时，我们可以在一个远程网站的域上对用户身份进行验证（该远程网站登录到一个与运行着Web服务器的域有着信任关系的域）。 最后，如果用户都有个人数字证书，你可以把那些证书映射到本地域的NT帐户上。个人数字证书与服务器数字证书以同样的技术为基础，它证明用户身份标识的合法性，所以可以取代NT

8、的Challenge/Response（质询/回应）验证算法。Netscape和IE都自动在每一个页面请求中把证书信息发送给IIS。IIS提供了一个让管理员把证书映射到NT帐户的工具。因此，我们可以用数字证书取代通常的提供帐户名字和密码的登录过程。 由此可见，通过NT帐户验证用户时我们可以使用多种实现方法。即使当用户通过IIS跨越Internet连接SQL Server时，选择仍旧存在。因此，你应该把NT验证作为首选的用户身份验证办法。三、设置全局组 构造安全策略的下一个步骤是确定用户应该属于什么组。通常，每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别。例如，会计应用

9、软件的用户一般包括：数据输入操作员，数据输入管理员，报表编写员，会计师，审计员，财务经理等。每一组用户都有不同的数据库访问要求。 控制数据访问权限最简单的方法是，对于每一组用户，分别地为它创建一个满足该组用户权限要求的、域内全局有效的组。我们既可以为每一个应用分别创建组，也可以创建适用于整个企业的、涵盖广泛用户类别的组。然而，如果你想要能够精确地了解组成员可以做些什么，为每一个应用程序分别创建组是一种较好的选择。例如，在前面的会计系统中，我们应该创建Data Entry Operators、Accounting Data Entry Managers等组。请记住，为了简化管理，最好为组取一个能

10、够明确表示出作用的名字。 除了面向特定应用程序的组之外，我们还需要几个基本组。基本组的成员负责管理服务器。按照习惯，我们可以创建下面这些基本组：SQL Server Administrators，SQL Server Users，SQL Server Denied Users，SQL Server DB Creators，SQL Server Security Operators，SQL Server Database Security Operators，SQL Server Developers，以及 DB_Name Users（其中DB_Name是服务器上一个数据库的名字）。当然，如果必

11、要的话，你还可以创建其他组。 创建了全局组之后，接下来我们可以授予它们访问SQL Server的权限。首先为SQL Server Users创建一个NT验证的登录并授予它登录权限，把Master数据库设置为它的默认数据库，但不要授予它访问任何其他数据库的权限，也不要把这个登录帐户设置为任何服务器角色的成员。接着再为SQL Server Denied Users重复这个过程，但这次要拒绝登录访问。在SQL Server中，拒绝权限始终优先。创建了这两个组之后，我们就有了一种允许或拒绝用户访问服务器的便捷方法。 为那些没有直接在Sysxlogins系统表里面登记的组授权时，我们不能使用Enterp

12、ris Managr，因为Enterprise Manager只允许我们从现有登录名字的列表选择，而不是域内所有组的列表。要访问所有的组，请打开Query Analyzer，然后用系统存储过程sp_addsrvrolemember以及sp_addrolemember进行授权。 对于操作服务器的各个组，我们可以用sp_addsrvrolemember存储过程把各个登录加入到合适的服务器角色：SQL Server Administrators成为Sysadmins角色的成员，SQL Server DB Creators成为Dbcreator角色的成员，SQL Server Security Ope

13、rators成为Securityadmin角色的成员。注意sp_addsrvrolemember存储过程的第一个参数要求是帐户的完整路径。例如，BigCo域的JoeS应该是bigcojoes（如果你想用本地帐户，则路径应该是server_namejoes）。 要创建在所有新数据库中都存在的用户，你可以修改Model数据库。为了简化工作，SQL Server自动把所有对Model数据库的改动复制到新的数据库。只要正确运用Model数据库，我们无需定制每一个新创建的数据库。另外，我们可以用sp_addrolemember存储过程把SQL Server Security Operators加入到db

14、_securityadmin，把SQL Server Developers加入到db_owner角色。 注意我们仍然没有授权任何组或帐户访问数据库。事实上，我们不能通过Enterprise Manager授权数据库访问，因为Enterprise Manager的用户界面只允许我们把数据库访问权限授予合法的登录帐户。SQL Server不要求NT帐户在我们把它设置为数据库角色的成员或分配对象权限之前能够访问数据库，但Enterprise Manager有这种限制。尽管如此，只要我们使用的是sp_addrolemember存储过程而不是Enterprise Manager，就可以在不授予域内NT帐

15、户数据库访问权限的情况下为任意NT帐户分配权限。 到这里为止，对Model数据库的设置已经完成。但是，如果你的用户群体对企业范围内各个应用数据库有着类似的访问要求，你可以把下面这些操作移到Model数据库上进行，而不是在面向特定应用的数据库上进行。 四、允许数据库访问 在数据库内部，与迄今为止我们对登录验证的处理方式不同，我们可以把权限分配给角色而不是直接把它们分配给全局组。这种能力使得我们能够轻松地在安全策略中使用SQL Server验证的登录。即使你从来没有想要使用SQL Server登录帐户，本文仍旧建议分配权限给角色，因为这样你能够为未来可能出现的变化做好准备。 创建了数据库之后，我们

16、可以用sp_grantdbaccess存储过程授权DB_Name Users组访问它。但应该注意的是，与sp_grantdbaccess对应的sp_denydbaccess存储过程并不存在，也就是说，你不能按照拒绝对服务器访问的方法拒绝对数据库的访问。如果要拒绝数据库访问，我们可以创建另外一个名为DB_Name Denied Users的全局组，授权它访问数据库，然后把它设置为db_denydatareader以及db_denydatawriter角色的成员。注意SQL语句权限的分配，这里的角色只限制对对象的访问，但不限制对DDL（Data Definition Language，数据定义语言

17、）命令的访问。 正如对登录过程的处理，如果访问标记中的任意SID已经在Sysusers系统表登记，SQL将允许用户访问数据库。因此，我们既可以通过用户的个人NT帐户SID授权用户访问数据库，也可以通过用户所在的一个（或者多个）组的SID授权。为了简化管理，我们可以创建一个名为DB_Name Users的拥有数据库访问权限的全局组，同时不把访问权授予所有其他的组。这样，我们只需简单地在一个全局组中添加或者删除成员就可以增加或者减少数据库用户。 五、分配权限 实施安全策略的最后一个步骤是创建用户定义的数据库角色，然后分配权限。完成这个步骤最简单的方法是创建一些名字与全局组名字配套的角色。例如对于前

18、面例子中的会计系统，我们可以创建Accounting Data Entry Operators、Accounting Data Entry Managers之类的角色。由于会计数据库中的角色与帐务处理任务有关，你可能想要缩短这些角色的名字。然而，如果角色名字与全局组的名字配套，你可以减少混乱，能够更方便地判断出哪些组属于特定的角色。 创建好角色之后就可以分配权限。在这个过程中，我们只需用到标准的GRANT、REVOKE和DENY命令。但应该注意DENY权限，这个权限优先于所有其他权限。如果用户是任意具有DENY权限的角色或者组的成员，SQL Server将拒绝用户访问对象。 接下来我们就可以加

19、入所有SQL Server验证的登录。用户定义的数据库角色可以包含SQL Server登录以及NT全局组、本地组、个人帐户，这是它最宝贵的特点之一。用户定义的数据库角色可以作为各种登录的通用容器，我们使用用户定义角色而不是直接把权限分配给全局组的主要原因就在于此。 由于内建的角色一般适用于整个数据库而不是单独的对象，因此这里建议你只使用两个内建的数据库角色,，即db_securityadmin和db_owner。其他内建数据库角色，例如db_datareader，它授予对数据库里面所有对象的SELECT权限。虽然你可以用db_datareader角色授予SELECT权限，然后有选择地对个别用户

20、或组拒绝SELECT权限，但使用这种方法时，你可能忘记为某些用户或者对象设置权限。一种更简单、更直接而且不容易出现错误的方法是为这些特殊的用户创建一个用户定义的角色，然后只把那些用户访问对象所需要的权限授予这个用户定义的角色。 /from 六、简化安全管理 SQL Server验证的登录不仅能够方便地实现，而且与NT验证的登录相比，它更容易编写到应用程序里。但是，如果用户的数量超过25，或者服务器数量在一个以上，或者每个用户都可以访问一个以上的数据库，或者数据库有多个管理员，SQL Server验证的登录不容易管理。由于SQL Server没有显示用户有效权限的工具，要记忆每个用户具有哪些权限

21、以及他们为何要得到这些权限就更加困难。即使对于一个数据库管理员还要担负其他责任的小型系统，简化安全策略也有助于减轻问题的复杂程度。因此，首选的方法应该是使用NT验证的登录，然后通过一些精心选择的全局组和数据库角色管理数据库访问。 下面是一些简化安全策略的经验规则： 用户通过SQL Server Users组获得服务器访问，通过DB_Name Users组获得数据库访问。 用户通过加入全局组获得权限，而全局组通过加入角色获得权限，角色直接拥有数据库里的权限。 需要多种权限的用户通过加入多个全局组的方式获得权限。 只要规划得恰当，你能够在域控制器上完成所有的访问和权限维护工作，使得服务器反映出你在

22、域控制器上进行的各种设置调整。虽然实际应用中情况可能有所变化，但本文介绍的基本措施仍旧适用，它们能够帮助你构造出很容易管理的安全策略。2、当SQLServer数据库崩溃时如何恢复? 摘要：当SQLServer数据库崩溃时如何恢复? 任何数据库系统都无法避免崩溃的状况，即使你使用了Clustered，双机热备仍然无法完全根除系统中的单点故障，何况对于大部分用户来说，无法承受这样昂贵的硬件投资。所以，在系统崩溃的时候，如何恢复原有的宝贵数据就成为一个极其重要的问题了。在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即

23、可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，恭喜你！你可以还原到崩溃前的状态。/from 一般的单位都是没有专职的DBA的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失

24、，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。不幸的很的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。那么就只好试一下这些方案了。当然，是要求至少你的数据文件是存在的，要是数据文件、日志文件和备份都没有了的话，别找我，你可以到楼顶上去唱“神啊，救救我吧”。首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气

25、馁，还是有别的方案的。我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。 不过系统表是不能随便改的，设置一下先Use MasterGosp_configure allow updates, 1reconfigure with overrideGo然后update sysdatabases set status = 32768 where name = 现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松

26、一口气了。虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。先把SQL Server 重新启动一下，然后检查你的数据库吧。先设置成单用户模式，然后做dbccsp_dboption , single user, trueDBCC CHECKDB()如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。update sysdatabases set status = 28 where name = -当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用sp_resetstatusgosp_configure al

27、low updates, 0reconfigure with overrideGocheckdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得REPAIR_ALLOW_DATA_LOSS，完成所有修复。chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。上面提到的命令、对象在Books Online中均有详细说明，请注意参看。