第 6 章数据库安全

第6章数据库安全

本章要点 • 数据库完整性：记录完整性、数据正确性和更新完整性 • 数据库安全：访问控制、推理和聚集 • 多级安全数据库：分区、加密封装和过滤数据 • 数据挖掘应用的安全

保护数据是大多数安全系统的核心，许多用户依靠数据库管理系统(DBMS, database management system)来管理并保护数据。基于此原因，我们重点研究数据库管理系统的安全，并将其作为一个示例来说明如何设计并实现完成特殊任务的应用程序的安全。然而，数据库管理系统仅提供一个综合保护效果。长期以来，我们已经深化了对数据库安全问题的理解，并且获得了一些好的控制方法。但是，也有一些仍然无法控制的安全隐患。

6.1 数据库简介 6.1.1 数据库概念数据库(database)是数据以及按某种指定关系组织数据的一组规则的集合。用户使用这些规则来描述数据的逻辑格式。数据项存储在文件中，但是用户不必关心文件的精确物理格式。数据库管理员(database administrator)负责定义组织数据的规则和控制对数据库的访问。用户通过数据库管理器(database manager)或数据库管理系统(DBMS)程序[非正式地称为前端(front end)]使用数据库。

6.1.2 数据库组成 数据库文件由记录(record)组成，每个记录包含了一组相关的数据。每个记录包含域(field)或元素(element)，即它们的基本数据项。表 6.1 一个数据库的实例

6.1.2 数据库组成(续) 并非所有数据库都可以非常容易地用一张单一、紧凑的表来表示。图 6.1 一个数据库的相关部分

6.1.2 数据库组成(续) 数据库的逻辑结构称为模式(schema)。一名特殊的用户可能只允许访问数据库的一部分，称之为子模式(subschema)。表 6.2 图6.1中的数据库模式

6.1.2 数据库组成(续) 数据库的规则要求以列名识别列，列名也称为数据库的属性(attribute)，列的集合构成了一个关系(relation)。关系描述了有关数据值的簇(cluster)，每一簇可能会是2、3、4、n元组(n表示任意值)。表6.3 数据库中的关系

6.1.2 数据库组成(续) 查询操作用户通过DBMS的命令与数据库交互，命令有：检索、修改、增加或删除数据库中的域和记录。查询(query)是一个命令，数据库管理系统有构成查询语句的精确的语法规则。大多数查询语言使用类英语符号表示，其中很多以SQL语言为基础。查询结果为一个子模式，该模式由满足给定条件的记录构成。

6.1.2 数据库组成(续) 表6.4 选择查询的结果例如，SELECT ZIP=‘43210’。另外，更复杂的选择条件包含逻辑运算，如()或()以及比较运算符(<)。例如，SELECT (ZIP=‘43210’)(NAME=‘ADAMS’) 。

6.1.2 数据库组成(续) 在选择了记录后，我们可以对这些记录的一个或多个属性进行投影(project)运算。投影操作是从这些满足条件的记录中选取满足条件的列(域)。选择-投影操作的结果是选择的记录在指定属性上值的集合。例如， SHOW NAME, FIRST WHERE ZIP=‘43210’。表6.5 选择-投影查询结果

6.1.2 数据库组成(续) 我们也可以使用连接(join)查询来根据相同的元素合并两个模式。该操作的结果是一个子模式，该子模式在相同元素上有相同的值。例如， SELECT NAME, AIRPORT FROM NAME-ZIP JOIN ZIP-AIPORT ON NAME-ZIP.ZIP=ZIP-AIPORT.ZIP。图 6.2 选择-投影-连接查询的结果

6.1.3 数据库的优点 数据库是数据的一个集合，它被集中存储和维护，以满足人们的访问需求。这样，与简单的文件系统相比，数据库提供了很多好处：共享访问：以便用户使用一些公共、集中的数据。最小冗余：使用户不必自己收集和保存数据集。数据一致性：改变一个数据值将影响所有使用该数据值的用户。数据完整性：保护数据值，使偶然或恶意的行为不会改变数值。访问控制：只有授权用户才允许浏览或修改数据值。 # 数据库的安全利益和性能之间存在冲突。这种冲突不足为怪，因为加强安全措施通常要增加计算机系统的规模和复杂度。

6.2 安全需求 以下为数据库的一些安全需求： (1) 数据库的物理完整性：数据库中的数据不受停电之类影响，并且人们可以重建被破坏的数据库。 (2) 数据库的逻辑完整性：保护数据库的结构。 (3) 元素的完整性：每个元素中包含的数据都是正确的。 (4) 可审计性：可追踪谁访问了数据库中的哪些元素。 (5) 访问控制：用户只能访问被授权的用户。 (6) 用户鉴别：对每个用户都必须鉴别。 (7) 可用性：用户可以访问数据库中的授权数据和一般数据。

6.2.1 数据库完整性 如果数据库以集中的数据仓库方式提供数据访问服务，则用户必须相信其中的数据值是正确的。有两种情况会影响数据的完整性：整个数据库被损坏以及单个数据项变得不可读。整个数据库的完整性由DBMS、操作系统和计算系统管理员负责。保护整个数据库的方法之一是定期备份数据库系统中的所有文件。有时，能够在故障点重建数据库非常重要。DBMS需要维护一个事务日志。在系统发生故障后，可通过重新装入数据库的后备副本并重新执行“日志”记录所有的事务，而获得用户的正确状态。

6.2.2 元素完整性 元素完整性指数据库元素的正确性或准确性。DBMS采用三种方式来维护数据库中每个元素的完整： (1) DBMS可以利用域检查(field check)，确保某个域的所有值在合适的范围之内。域检查确保了值在指定界内或不大于另外两个域的值之和，也可防止一些简单的错误，如用户输入数据错误。

6.2.2 元素完整性(续) (2) 访问控制(access control)以及集中管理的方式。但谁该共享重要的文件？谁拥有更新元素的权限？如果两个用户更改时相互冲突，如何解决？如何检查和处理重复记录？都是数据库管理员需要解决的问题。 (3) 更改日志(change log)。更改日志维护和保存了数据库的每次修改，同时记录初始值和更新值。

6.2.3 可审计性 在某些应用中，需要产生关于数据库的所有访问(或读写)的审计记录，这个记录可以协助维护数据库的完整性，至少可以在发生故障后，为分析解决问题提供依据。另一个优点是可以掌握用户不断增加对被保护数据的访问。单一的访问不会暴露被保护的数据，但在一系列连续的访问后，将数据综合起来就可能发现被保护的数据。在这种情况下，审计追踪可以确定用户已经获得的数据线索，然后指导做出是否还应该允许用户做进一步查询的决定。

6.2.3 可审计性 (续) 审计粒度是审计的障碍。数据库的审计踪迹应该包括对记录、域甚至元素级的访问，大多数数据库的应用不能达到这种程度。此外，在例如用户执行选择操作时，用户可以访问数据但并未获得数据的具体值[访问一个记录或元素后，系统不将结果数据传递给用户，这种情况称穿过问题(pass-through problem)]。同时，用户也可以不直接访问元素而获得它们的值。因此，只记录所有直接访问的日志可能夸大或低估了用户对数据库的实际了解情况。

6.2.4 访问控制 数据库通常按照用户的访问权限进行逻辑分割。限制访问是数据库集中管理形式的职责和优势。DBMS需要实施这样的访问策略：授权访问所有指定的数据，阻止访问禁止的数据。数据库管理员需要分别以视图、关系、域、记录、甚至元素级给予说明。用户或程序可能拥有的权限包括：读、改变、删除或附加一个值、增加或删除整个域或记录、重组数据库。

6.2.4 访问控制(续) 对数据库的访问控制比对操作系统的访问控制更为复杂。虽然在操作系统中用户通常不可能通过读一个文件来推理其他文件的内容，但在数据库中则可能通过读其他元素的值而推知另一个元素的值。从已获得的数据值推断更多的值，称为推理(inference)。限制推理意味着要禁止一些特定的路径来阻止可能的推理，但也限制了某些用户的正常查询，这样做实际降低了DBMS的性能。因为数据库中的每个文件可能还包含几百个数据域，访问控制的实现要比操作系统困难得多，粒度的大小影响了处理的效率。

6.2.5 用户鉴别 通常，数据库作为应用程序运行在操作系统之上。这种设计意味着DBMS和操作系统之间没有可信路径，所以DBMS必须对所有接收到的数据持怀疑态度，包括用户鉴别。因此，DBMS不得不自己进行用户鉴别。

6.2.6 可用性 对于许多用户来说，DBMS 是可执行的应用程序。用户通常把DBMS看作是用来执行特殊任务的基本工具。当系统不可用时，用户会清楚地意识到此时BDMS是不可用的。这实际上是要求DBMS有高可用性。

6.2.7 完整性/机密性/可用性 每个元素以至于整个数据库都要求完整性，因此，完整性是设计BDMS时主要关心的问题。由于存在推理攻击，所以用户可以通过推理间接获取敏感数据，机密性成为数据库的关键问题。数据库开发的初衷就是为了更好利用共享访问，所以可用性也是一个关键问题，然而，可用性和机密性相互冲突。

6.3 可靠性和完整性 软件可靠性(reliability)是指软件能够长时间无故障地运行。DBMS有几种方法保护数据以防止丢失或被破坏。数据库的可靠性和完整性可以从以下三个级别来考察： (1) 数据库完整性：在磁盘驱动器或数据库主索引损坏后，保障整个数据库不受损害。 (2) 元素完整性：只有授权用户可以写或修改一个特殊的数据元素。 (3)元素正确性：只有正确的值才能写入数据库。检查元素值可以防止插入不适当的值。同时，设定的限制条件也可以发现错误值。

6.3.1 操作系统提供的保护特性 操作系统对所有计算系统的资源提供保护。当操作系统负责管理时，数据库文件会被周期性备份。操作系统使用标准访问控制工具保护文件，以免文件在正常的执行过程中被外界访问。在正常读写I/O设备时，操作系统将对所有数据进行完整性检查。

6.3.2 两阶段更新 对数据库管理器来说，在修改数据的途中计算系统出现故障是一个严峻的问题。它可能导致一个数据项的部分元素已经更新，而另部分却没有更新的问题，而发现并更正这一问题比较困难。为此，Lampson 和Sturgis提出了两阶段更新方案解决这个问题，大部分DBMS采用了这种方案。

6.3.2 两阶段更新(续) 更新技术第一阶段称为意向(intent)阶段，DBMS收集所有执行更新需要的资源。做足更新前的一切准备工作，但并没有对数据库做任何改变。因为每个步骤都并未永久地更新数据，所以第一阶段可以重复无数次。第一阶段的最后事件是提交(committing)，包括为数据库做提交标记(commit flag)。提交标记意味着DBMS通过了不需要撤消的点。

6.3.2 两阶段更新(续) 第二阶段实现永久更新。如果在这个阶段出现故障，数据库可能包含不完整的数据，但系统可以重新执行第二阶段的所有动作以修复数据。第二阶段结束，数据库更新完毕。

6.3.2 两阶段更新(续) 两阶段更新的实例假定某公司有一个办公用品管理系统，其数据库中包含公司的办公用品清单，中心仓库管理员需要管理办公用品分发以及监控现有的供应量，以便在库存不足时定货。假定现有库存107箱文件夹，而低于100箱时需要定货。假定会计部提出申请需要50箱文件夹。仓库管理员处理请求的步骤为： (1) 仓库和数据库是否有50箱文件夹库存。没有，拒绝请求结束事物。 (2) 如果库存充足，从数据库中的存货中扣除50箱文件夹。 (3) 仓库从会计部预算中收取50箱文件夹的费用。 (4) 仓库检查剩余的库存57箱文件夹(107-50=57)是否低于定货界限。如果是，将产生一个定货提示，并将数据库中的文件夹项标记为“定货中”。 (5) 准备好交货，把50箱文件夹送到会计部。

6.3.2 两阶段更新(续) 当进行两个阶段提交时，可用影子值(shadow value)来保存关键数据。如下所示：意向： (1) 检查数据库中的COMMIT-FLAG。如果该值已经设置，则不进行意向阶段，直到其被清零。 (2) 比较库存文件夹箱数和需求量，如果需求大于库存，停止。 (3) 计算剩余文件夹箱数TCLIPS = ONHAND -REQUISITION。 (4) 获得会计部的预算BUDGET ，计算结余TBUDGET = BUDGET - COST。 (5) 检查TCLIPS是否低于定货界限，如果是，设置TREORDER =TRUE ；否则，设置TREORDER = FALSE。

6.3.2 两阶段更新(续) 提交： (1) 在数据库中设置COMMIT-FLAG。 (2) 复制TCLIPS到数据库的CLIPS。 (3) 复制TBUDGET到数据库的BUDGET。 (4) 复制TREORDER到数据库的REORDER 。 (5) 准备向会计部发送文件夹的通知。在日志中表明完成事务。 (6) 清除COMMIT-FLAG。 # 每个T开头的变量是只在事务阶段使用的影子变量。

6.3.3 冗余/内在一致性 许多DBMS通过维护附加信息来检测数据内在的不一致性。检错与纠错一种冗余形式是检错码或纠错码，可应用于单个域、记录或整个数据库，比如，奇偶效验码、海明(Hamming)编码、循环冗余检查。检验码提供的信息越多，所占的存储空间越大。影子域在数据库中可以复制整个属性或记录。这里冗余域显然需要大量的存储空间。

6.3.4 恢复 除了这些纠错过程外，DBMS还需要维护用户的访问日志，尤其是更改日志。在发生故障后，从后备副本中重新装载数据库，并根据日志将数据库恢复到故障前的最后一个正确状态。

6.3.5 并发性/一致性 DBMS使用了简单的封锁技术来保证共享数据库安全。如果两个用户需要对相同数据项进行读访问，则他们之间没有冲突，因为他们将获得相同的值。如果两个用户尝试修改相同的数据，我们通常假定用户间没有冲突，因为每个用户都知道写什么值；同时，认为写入的值不依赖于数据项先前的值。然而，这个假定往往不总是正确的。

6.3.5 并发性/一致性(续) 假如有一个特定航班的订座数据库。代理人A将为乘客Mock预订座位，向数据库提交了一个查询，请求过道右边的座位发现了5D、11D、14D。同时另一个代理人B想为一家三口预订三个相邻的位置，发现了8A-B-C和11D-E-F是未预约的。这时代理A提交了订座命令订下11D，而代理B提交了订座命令订下11D-E-F。这时就产生了问题。而出现这种问题的原因，在于从数据库中读数据和改写数据之间的时间延迟。在延迟时段中，另外的用户可访问同一个数据。

6.3.5 并发性/一致性(续) 为了解决这个问题，DBMS把整个查询/更新周期看做一个原子操作。读/修改周期必须在一个未受干扰的情况下完成，禁止其他用户对11D的访问。直到第一个代理成功预订后才开始考虑第二个代理人的请求。此外，如果一个用户A正在读时，另一个用户B正在写，那么用户A将读到部分更新的数据。因此，DBMS将锁定读请求直到写操作完成后。

6.3.6 监视器 监视器(monitor)是DBMS中负责数据库结构完整性的单元。范围比较范围比较监视器检测每个新产生的值，确保每个值在可接受的范围内。如果一个数据值在范围之外，监视器会拒绝该数据值，并不将它输入数据库。范围比较可用于保障数据库的内在一致性。如果怀疑数据库中的某些数据已经遭到破坏，范围检查可以识别所有可疑记录的数据。

6.3.6 监视器(续) 状态约束状态约束(state constraint)描述了整个数据库的约束条件。数据库的值不能违反这些约束。也就是说，如果不满足这些约束，数据库中的一些数值会出错。两阶段更新中的提交标记就是一种状态约束，因为在每个事务结束时都需要判断提交标记是否被设置。提交标记在数据库中的身份是一种完整性约束。另一个例子是，无论何时雇员中“总裁” 的数量都是一个。如果由于机器故障，数据库被部分复制了，那么通过测试数据库的状态，DBMS可能识别到存在两个相同的雇员编号或有两名“总裁”。

6.3.6 监视器(续) 转换约束转换约束(transition constraint)则描述了改变数据库之前的必需条件。例如，在数据库中加新员工之前，必须有一个职位是空缺的。添加雇员后，数据库中相应的职位应该从“空缺”改为该雇员编号。 # 大多数数据库管理系统都要执行简单的范围检查。然而，较复杂的状态和转换约束需要专门的程序进行测试。

6.4 敏感数据 某些数据库保存了所谓不能公开的敏感数据(sensitive data)。决定哪个数据项或域为敏感取决于数据库和数据的含义。最容易处理的两个实例是：根本没有敏感数据或者全部都是敏感数据。更困难的情况是，在实际中，数据库中的元素常常是部分而不是全部为敏感数据，而且敏感的程度各有不同。

6.4 敏感数据(续) 表 6.6 一个数据库的样本数据 # 安全需求可能要求：有少部分人具有访问单个域的权限，但是没有人同时具有访问所有域的权限

6.4 敏感数据(续) 使数据敏感的几个因素包括： (1) 固有的敏感性：因数据值本身具有揭露性而为敏感数据。 (2) 来自敏感源：数据的来源预示了对机密性的要求。 (3) 声明的敏感性：数据库管理员或数据所有者声明该数据为敏感数据。 (4) 敏感属性或敏感记录中的部分：在数据库中，整个属性或记录可以归类为敏感的。 (5) 与已经泄露信息相关的敏感性：有些数据在某些数据面前变得敏感。

6.4.1 访问决策 数据库管理员的决策是以访问策略为基础的。数据库管理器或DBMS是程序，对数据库和辅助的控制信息进行操作，以实现访问策略的决策。DBMS在决定是否允许访问时要考虑几个因素：数据的可用性一个或多个被请求的元素可能存在不可访问的问题。例如，数据更新就会出现这样的问题。如果正在进行数据更新的用户在中途中断了更新事务，其他用户对这些记录的访问将被永远阻塞。这种由中断服务造成的不确定延期也是一个安全问题，它将导致拒绝服务攻击。

6.4.1 访问决策(续) 可接受的访问记录中一个或多个值可能是敏感数据，但是，确定什么样的数据是敏感数据似乎并不容易，因为有时并不需要对敏感域直接访问就可获得敏感数据。用户也可以通过不敏感的统计数据推理敏感数据。保证真实性当允许访问时，可能要考虑数据库用户的某些外在特性。

6.4.2 泄露类型 数据具有敏感性，数据的特性也同样具有敏感性。我们将了解即使是数据相关信息的描述也是一种泄露形式。准确数据这种情形的结果只有一个：破坏了敏感数据的安全。范围一种暴露是揭露了敏感数据的范围，另一种情况是，只揭露一个值超过某个总量。然而，有时在提供敏感数据时，只给出一个范围是有用的。

6.4.2 泄露类型(续) 否定结果有时，我们会执行查询确定一个否定的结果，同样可能泄露敏感信息。存在性有时，与数据的具体值无关，数据的存在性本身就是敏感数据。大概值假定想确定总统是否为保皇党成员，可以做如下查询： How many people have 1600 Pennsylvania Avenue as their official residence? (Response: 4) How many people have 1600 Pennsylvania Avenue as their official residence and have YES as the value of TORY? (Response: 1) 通过上述结果，知道总统是保皇党成员的可能性为25%。部分泄露的小结成功的安全策略必须能够同时防止直接泄露和间接泄露敏感数据。

6.4.3 安全与精确度 确定一个数据是否是敏感数据以及怎样保护这些敏感数据是十分困难的。这实际鼓励了保守的观点：透露的数据越少越好。保守的观点建议拒绝一切敏感域的查询。但我们同时也希望尽可能显示数据以满足数据库用户的需求，这个目标称为精确度(precision)，旨在保护所有敏感数据的同时尽可能多地揭示非敏感数据。安全与精确度的理想结合要求维护完善的机密性与最大的精确性，也就是揭示所有、但仅非敏感数据。

6.4.3 安全与精确度(续) 图6.3 安全与精确度

6.5 推理 推理(inference)是一种通过非敏感数据推断或推导敏感数据的方法。推理问题是数据库安全中一个很微妙的弱点。回顾表6.6中的数据库，我们假定AID，FINES和DRUGS都是敏感域，但这些域只有和固定个体关联后才是敏感的。

第 6 章 数据库安全