网络安全 频道

数据库安全性实战

    数据库安全一直是数据库管理员的噩梦。数据丢失、数据库被非法侵入等安全事件总使得他们身心俱疲。系统安全保护措施是否有效是数据库系统的主要指标之一。数据库的安全性和计算机系统的安全性,包括操作系统、网络系统的安全性是紧密联系、相互支持的。

  一、身份验证

  1.各层SQL Server安全控制策略是通过各层安全控制系统的身份验证实现的。身份验证是指当用户访问系统时,系统对该用户的账号和口令的确认过程。身份验证的内容包括确认用户的账号是否有效、能否访问系统、能访问系统的哪些数据等。

  2. 身份验证方式是指系统确认用户的方式。SQL Server系统是基于Windows NT/2000操作系统的,现在的SQL Server系统可以安装在Windows 95(需要安装Winsock升级软件)、Windows 98和Windows ME之上(此时,将没有第一层和第二层的安全性控制),但旧的SQL Servers系统只能运行在Windows NT/2000操作系统上。Windows NT/2000对用户有自己的身份验证方式,用户必须提供自己的用户名和相应的口令才能访问Windows NT/2000系统。

  这样SQL Server的安全系统可在任何服务器上通过两种方式实现:SQL Server和Windows结合使用(SQL Server and Windows)以及只使用Windows(Windows Only)。访问Windows NT/2000系统用户能否访问SQL Server系统就取决于SQL Server系统身份验证方式的设置。

  二、恢复模型

  1、在你开始备份一个SQL Server数据库之前,你需要知道该数据库使用了哪个恢复模型。这里有三种不同的恢复模型:FULL、BULK_LOGGED和SIMPLE。

  (1) FULL恢复模型向你提供了最大的恢复灵活性。新数据库默认使用的就是这种恢复模型。利用这种模型,你可以恢复数据库的一部分或者完全恢复。假设交易记录(transactions log)还没有被破坏,你还可以在失败之前恢复出最后一次的已提交(committed)交易。在所有的恢复模型中,这种模型使用了最多的交易记录空间,并轻微影响了SQL Server的性能。

  (2) BULK_LOGGED恢复模型比FULL模型少了一些恢复选项,但是进行批操作(bulk operation)时它不会严重影响性能。在进行某些批操作时,由于它只需记录操作的结果,因此它使用了较少的记录空间。然而,用这种模型,你不能恢复数据库中的特定标记,也不能仅仅恢复数据库的一部分。

  (3) SIMPLE恢复模型是这三种模型中最容易实施的,它所占用的存储空间也最小。然而,你只能恢复出备份结束时刻的数据库。

  2、为了找出你所用数据库的恢复模型,可以运行下面的命令,该命令应该返回FULL、BULK_LOGGED和SIMPLE这三个值中的某一个:

  SELECT dbpropertyex("database", "recovery")

  为了改变数据库的恢复选项,运行下面的命令:

  ALTER DATABASE database name SET RECOVERY {FULL SIMPLE BULK_LOGGED}

  除数据之外,SQL Server备份还包括数据库大纲(schema)和数据库元数据(即数据库文件、文件组和它们的位置)。SQL Server允许在备份时用户依然使用数据库,所以在备份期间发生的交易也记录到备份中去了。

  三、备份数据库

  (一)备份整个数据库

  你可以运行BACKUP命令。BACKUP命令有许多选项,它的基本语法是:

  BACKUP DATABASE { database_name }

  TO < backup_device >

  backup_device可以是磁盘或者磁带——或者它也可以是一个用磁盘文件、磁带或者已命名管道表示的逻辑上的备份设备。

  如果你想做一个快速、一次性的备份,那么向下面那样使用磁盘文件:

  BACKUP DATABASE Northwind TO DISK = "c:backupNorthwind.bak"

  如果你想把数据库备份到另外一台服务器上,可以使用UNC名字:

  BACKUP DATABASE Northwind TO DISK = "FILESERVERSharedBackupNorthwind.bak"

  如果想进行有规律、有计划的备份,就需要使用逻辑备份设备。一个逻辑备份设备可以保存若干个数据库备份并驻留在磁盘、磁带或者已命名管道上。如果你使用磁带设备,磁带驱动器必须在同一台物理服务器上

  (二)频繁变动的大数据库的备份

  如果数据库很大并且频繁变动,由于时间和空间的限制,频繁进行全数据库备份是不现实的。当数据库失败时,可能会造成大量数据丢失。

  在这种情况下,有两种提高可恢复性的途径,这两个途径都要求全数据库备份。而且这两种方法都要求数据库恢复模型为FULL或者BULK_LOGGED。

  1. 采用差异数据库备份

  它只捕获并保存全数据库备份后改变的数据。由于它的文件较小而且信息简明,用它进行数据恢复的速度非常快。

  下面的例子在一个名为DiffBackupDevice的逻辑备份设备上创建了一个差异备份:

  BACKUP DATABASE Northwind TO DiffBackupDevice WITH DIFFERENTIAL

  2. 采用交易记录备份(事务日志备份)

  交易记录的目的就是记录发生在数据库中所有交易。交易记录允许COMMIT和ROLLBACK正确工作。为了达到这个功能,该数据的变化前后的数值必须随同操作类型、交易开始(时间)等一齐被记录下来。

  备份技巧

  利用下面的列出的技巧来确保你不会在每周一次的数据库备份过程中忘记关键步骤。

  每周一次备份主数据库。如果你创建、修改或者停止一个数据库,添加新的SQL Server消息,添加或者停止连接服务器,或者添加记录设备,那就进行手工备份。

  每天备份一次msdb数据库。它一般非常小,但很重要,因为它包含了所有的SQL Server工作、操作和计划任务。

  只有当你修改它时,才有必要备份模型数据库。

  用SQL Server Agent来安排你的备份工作的时间表。

  如果在你的生产(production)环境中有现成资源,备份生产数据库到本地磁盘或者网络服务器(用同一个开关)。然后,把备份文件/设备拷贝到磁带上。在存在许多硬件故障(特别是在RAID系统中)的情况下,磁盘常常是完好的(inact)。如果备份文件是在磁盘上,那么恢复时的速度会提高很多。

  备份开发和测试数据库至少要用到SIMPLE恢复模型。

  除了有计划的定时备份外,在进行未记录的(nonlogged)批操作(如,批拷贝)、创建索引、或者改变恢复模型后要备份用户数据库。

  如果你使用的是SIMPLE恢复模型,记住在截短(truncate)交易记录之后备份你的数据库。

  用文档记录你的恢复步骤。至少要大概记录这些步骤,注意所有的重要文件的位置。

  在截短记录之前,也就是所有的已提交(committed)交易从记录中清空之前,所有的这些信息都保存在交易记录中。在SIMPLE恢复模型中,记录在一个CHECKPOINT期间内截短(在SQL Server内存缓冲写道磁盘时),它是自动发生的,但也可以手动执行。这也就是SIMPLE恢复模型不支持时间点(point-in-time)恢复的原因。在FULL和BULK_LOGGED恢复模型下,当交易记录被备份时,交易记录被截短,除非你明确指出不进行截短。

  为了备份交易记录,使用BACKUP LOG命令。其基本语法与BACKUP命令非常相似:

  BACKUP LOG { database } TO

  下面是如何把交易记录备份到一个名为LogBackupDevice的逻辑设备上的例子:

  BACKUP TRANSACTION Northwind TO LogBackupDevice

  如果你不希望截短交易记录,使用NO_TRUNCATE选项,如下所示:

  BACKUP TRANSACTION Northwind TO LogBackupDevice WITH NO_TRUNCATE

  二、(一)图形界面备份数据库

  1、打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server

  2、SQL Server组--&gt;双击打开你的服务器--&gt;双击打开数据库目录

  3、选择你的数据库名称(如财务数据库cwdata)--&gt;然后点上面菜单中的工具--&gt;选择备份数据库

  4、备份选项选择完全备份,目的中的备份到如果原来有路径和名称则选中名称点删除,然后点添加,如果原来没有路径和名称则直接选择添加,接着指定路径和文件名,指定后点确定返回备份窗口,接着点确定进行备份。

  (二)图形界面还原数据库

  1、打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server;

  2、SQL Server组--&gt;双击打开你的服务器--&gt;点图标栏的新建数据库图标,新建数据库的名字自行取;

  3、点击新建好的数据库名称(如财务数据库cwdata)--&gt;然后点上面菜单中的工具--&gt;选择恢复数据库;

  4、在弹出来的窗口中的还原选项中选择从设备--&gt;点选择设备--&gt;点添加--&gt;然后选择你的备份文件名--&gt;添加后点确定返回,这时候设备栏应该出现您刚才选择的数据库备份文件名,备份号默认为1(如果您对同一个文件做过多次备份,可以点击备份号旁边的查看内容,在复选框中选择最新的一次备份后点确定)--&gt;然后点击上方常规旁边的选项按钮;

  5、在出现的窗口中选择在现有数据库上强制还原,以及在恢复完成状态中选择使数据库可以继续运行但无法还原其它事务日志的选项。在窗口的中间部位的将数据库文件还原为这里要按照你SQL的安装进行设置(也可以指定自己的目录),逻辑文件名不需要改动,移至物理文件名要根据你所恢复的机器情况做改动,如您的SQL数据库装在D:Program FilesMicrosoft SQL ServerMSSQLData,那么就按照您恢复机器的目录进行相关改动改动,并且最后的文件名最好改成您当前的数据库名(如原来是cw123_data.mdf,现在的数据库是cwdata,就改成cwdata_data.mdf),日志和数据文件都要按照这样的方式做相关的改动(日志的文件名是*_log.ldf结尾的),这里的恢复目录您可以自由设置,前提是该目录必须存在(如您可以指定d:sqldatacwdata_data.mdf或者d:sqldatacwdata_log.ldf),否则恢复将报错;

  6、修改完成后,点击下面的确定进行恢复,这时会出现一个进度条,提示恢复的进度,恢复完成后系统会自动提示成功,如中间提示报错,请记录下相关的错误内容并询问对SQL操作比较熟悉的人员,一般的错误无非是目录错误或者文件名重复或者文件名错误或者空间不够或者数据库正在使用中的错误,数据库正在使用的错误您可以尝试关闭所有关于SQL窗口然后重新打开进行恢复操作,如果还提示正在使用的错误可以将SQL服务停止然后重起看看,至于上述其它的错误一般都能按照错误内容做相应改动后即可恢复。

  四、数据库角色

    角色是一个强大的工具,使您得以将用户集中到一个单元中,然后对该单元应用权限。对一个角色授予、拒绝或废除的权限也适用于该角色的任何成员。可以建立一个角色来代表单位中一类工作人员所执行的工作,然后给这个角色授予适当的权限。当工作人员开始工作时,只须将他们添加为该角色成员,当他们离开工作时,将他们从该角色中删除。而不必在每个人接受或离开工作时,反复授予、拒绝和废除其权限。权限在用户成为角色成员时自动生效。

  数据库角色从概念上与操作系统用户是完全无关的。在实际使用中把它们对应起来可能比较方便,但不是必须的。 数据库角色在整个数据库集群中是全局的(而不是每个库不同)。

  1. 要创建一个角色,使用 SQL 命令 CREATE ROLE:

  CREATE ROLE name;

  name 遵循 SQL 标识的规则: 要么完全没有特殊字符,要么用双引号包围(实际上你通常会给命令增加额外的选项,比如 LOGIN)。 要删除一个现有角色,使用类似的命令 DROP ROLE:

  DROP ROLE name;

  为了方便,程序 createuser 和 dropuser 提供了对了这些 SQL 命令的封装。 我们可以在 shell 命令上直接调用它们:


  createuser name dropuser name

  要判断一套现有用户,检查 pg_role 系统表,比如

  SELECT usename FROM pg_role;

  psql 的元命令 du 也可以用于列出现有角色。

  为了能初创数据库系统,新建立的数据库总是包含一个预定义的角色。 这个角色将总是"超级用户",并且缺省时(除非在运行 initdb 时更改过)他将和初始化该数据库集群的用户有相同的名称。通常,这个角色叫postgres。 为了创建更多角色,你必须首先以这个初始用户角色联接。

  每一个和数据库的连接都必须由一个角色身份进行,这个角色决定在该连接上发出的命令的初始权限。 和特定数据库联接的角色名是由初始化联接请求的应用以相关的方式声明的, 比如,psql 程序使用-U命令行选项声明它代表的进行联接的角色。许多应用以当前操作系统的用户名为缺省(这样的应用包括 createuser 和 psql)。 所以,在系统用户和数据库角色之间有某种命名关系会让我们工作方便很多。

  一个客户端联接可以用来联接的数据库角色集合是由客户认证设置决定的, 在 Chapter 20 里面有解释。 (因此,一个客户端并不局限于以它的操作系统用户同名的角色进行联接, 就象你登录系统的名称不一定要是你的真实姓名一样。) 因为角色的身份决定了一个已连接地客户端可用的权限, 所以在多用户环境里仔细配置这些内容是非常重要的。

0
相关文章