第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 一个数据库的实例 ADAMS 212 Market St. Columbus OH 43210 BENCHLY 501 Union St. Chicago IL 60603 CARTER 411 Elm St.

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

数据库的逻辑结构称为模式(schema)。一名特殊的用户可能只允许访问数据库的一部分，称之为子模式(subschema)。 6.1.2 数据库组成(续) 数据库的逻辑结构称为模式(schema)。一名特殊的用户可能只允许访问数据库的一部分，称之为子模式(subschema)。 表 6.2 图6.1中的数据库模式 Name First Address City State Zip Airport ADAMS Charles 212 Market St. Columbus OH 43210 CMH Edward BNCHLY Zeke 501 Union St. Chicago IL 60603 ORD CARTER Marlene 411 Elm St. Beth Ben Lisabeth Mary

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

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

6.1.2 数据库组成(续) 例如，SELECT ZIP=‘43210’。 表6.4 选择查询的结果 Name First Address City State Zip Airport ADAMS Charles 212 Market St. Columbus OH 43210 CMH Edward CARTER Marlene 411 Elm St. Beth Ben Lisabeth Mary 另外，更复杂的选择条件包含逻辑运算，如()或()以及比较运算符(<)。例如，SELECT (ZIP=‘43210’)(NAME=‘ADAMS’) 。

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

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 一个数据库的样本数据 Name Sex Race Aid Fines Drugs Dorm Adams M C 5000 45. 1 Holmes Bailey B 0. Grey Chin F A 3000 20. West Dewitt 1000 35. 3 Earhart 2000 95. Fein 15. Groff 4000 Hill 10. 2 Koch Liu Majors # 安全需求可能要求：有少部分人具有访问单个域的权限，但是没有人同时具有访问所有域的权限

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.5.1 直接攻击 直接攻击是指用户试图通过直接查询敏感域，根据产生的少量记录决定敏感域的值。最成功的技术是形成一个与数据项精确匹配的查询。一个查询可能是： List NAME where SEX=MDRUGS=1 一个比较隐蔽的查询是： List NAME where (SEX=M  DRUGS=1)(SEX≠MSEX≠ F) (DORM=AYRES) # 这引出了“n个同属一类数据项超过k%”规则，它表明：如果n个一类数据项代表了超过k%的报告结果，则结果数据应该被保留而不能公布。

通过“和”攻击，试图从已知的和推理单个值。 6.5.2 间接攻击 间接攻击是根据一个或多个中间的统计值推理最后结果。这种方法要求做一些数据库之外的工作。特别是，统计间接攻击需要利用某些有明显统计特征的方法来推理单个数据。 和 通过“和”攻击，试图从已知的和推理单个值。 表 6.7 按寝室和性别查询助学金之和 Holmes Grey West Total M 5000 3000 4000 12000 F 7000 11000 8000 23000

6.5.2 间接攻击(续) 计数 计数可以和总数结合来揭露更多的结果，而通常数据库给出这两个统计量，方便用户确定平均值。 平均值 假设知道员工的数量、公司的工资平均值和除总裁外所有员工的工资平均值，则可以很容易地计算总裁的工资。 表 6.8 按寝室和性别查询的学生计数值 Holmes Grey West Total M 1 3 5 F 2 6 4 11

通过稍微复杂的程序，我们可以根据中值得出个别值。这种攻击要求所选择的数据中有一个数据刚好在中值的交集中。 6.5.2 间接攻击(续) 中值 通过稍微复杂的程序，我们可以根据中值得出个别值。这种攻击要求所选择的数据中有一个数据刚好在中值的交集中。 图 6.4 中值的交集

6.5.2 间接攻击(续) 表 6.9 利用两个表的中间值进行推理 Name Sex Drugs Aid Bailey M Dewitt 3 1000 Majors 2 2000 Groff 4000 Adams 1 5000 Liu F Hill # 如果查询者已经知道Majors为男性和drug-use为2，且Majors出现在两个列表的中间值。则通过q = median(AID where SEX = M)和p = median(AID where DRUGS = 2)，可得到Majors奖学金为$2000。

6.5.2 间接攻击(续) 追踪攻击 追踪攻击(tracker attack)通过使用额外的、产生更少结果的查询欺骗数据库管理器，从而找到想要的数据。一个典型方法是，追踪者进行两次查询，让一次查询结果与另一次查询结果相比增加了一些记录；去掉两组纪录中的相同部分，就只留下统计数据或想要的数据。这个方法利用了两次查询结果的“间隙”部分。

6.5.2 间接攻击(续) 例如，查询 count ((SEX=F)(RACE=C)(DORM=Holmes)) DBMS可能会发现结果只是1，拒绝查询。由于q = count(abc)=count(a)-count(a¬ (b  c)) ，所以查询等于： count (SEX=F) (6) 减去 count ((SEX=F)((RACE≠C)(DORM≠Holmes))) (5)。

6.5.2 间接攻击(续) 使用逻辑与代数知识，加上数据库内容在分布上的特点，可以确定一系列查询，这些返回结果与几个不同的集相关，例如， 线性系统的脆弱性 使用逻辑与代数知识，加上数据库内容在分布上的特点，可以确定一系列查询，这些返回结果与几个不同的集相关，例如， 可以解出各个值。事实上，这种攻击也可以用于非数值的情形。“与”()和“或”()是数据库查询操作的典型运算，我们可以利用逻辑规则从一系列逻辑表达中获得结果。

6.5.2 间接攻击(续) 控制统计推理攻击 防止推理攻击的方法有：进行查询控制，或者对数据库里的单个项进行控制。很难确定一个查询是否会揭露敏感数据。因此，查询控制主要对直接攻击有效。对数据项的控制包括禁止查询和隐藏。禁止查询方式就是不提供敏感数据，对敏感数据的查询以不响应的方式拒绝。隐藏方式就是提供的结果接近但不是精确的实际数据值。这两种控制反映了精确与安全两者的矛盾。

6.5.2 间接攻击(续) 有限响应禁止 根据n项超k%的规则，不显示所占有百分比过大的元素。 表 6.10 按寝室和性别查询的学生人数(禁止显示计数低的单元) Holmes Grey West Total M - 3 5 F 2 6 4 11 # 如果一个表既有按行计算的总数，又有按列计算的总数，则只禁止查询其中一个单元的数据，仍然可以通过计算获得被禁止显示的数据。因此，在样本数据很少的表中，除了总数单元外所有的单元都不得不禁止查询，而没有提供总数，则可只禁止其中一个单元。

一种控制方法是组合行或列以保护敏感数据。 6.5.2 间接攻击(续) 组合结果 一种控制方法是组合行或列以保护敏感数据。 表 6.11 按性别和吸毒查询的学生人数 表 6.12 通过组合数据抑制推理 Sex Drug Use 1 2 3 M F Sex Drug Use 0 or 1 2 or 3 M 2 3 F 4

6.5.2 间接攻击(续) 另一个组合结果的方法是显示一个结果的范围。例如，发布助学金的结果时，给出金额的范围＄0~1999，＄2000~3999，以及＄4000以上，而不是准确的数值。还有一种方法是舍入。这项技术实际上是范围组合中相当有名的实例。如果数字的范围最接近10的倍数，则有效范围是0~5，6~15，16~25，等等。实际值可以根据最接近的基数向上或向下归入某个组。

6.5.2 间接攻击(续) 随机样本 使用随机样本控制方法，查询结果不是直接从整个数据库获得，而是从数据库的随机样本上计算出来的。因为样本毕竟不是整个数据，依据样本的查询不一定与在整个数据库中查询的结果相一致。通过重复相同的查询可以进行平均数攻击。为了防止这种攻击，相同的查询应该选择相同的样本。

6.5.2 间接攻击(续) 随机数据扰乱 有时，用一个小错误扰乱数据库的值还是有用的。xi 是数据库中数据项i的真实值，我们可以产生一个随机数据i附加在xi上作为统计结果。像“和”以及平均值这些统计方法可能使结果接近真实值，但又不是精确值。为了使相同的查询产生相同的结果，必须存储所有值。由于存储该值很容易，所以数据扰乱比随机样本选择更容易使用。

6.5.2 间接攻击(续) 查询分析 更复杂的安全形式是查询分析。这个方法要求维护每个用户过去的查询，根据过去查询的结果判断这个查询可能推理出的结果。 推理问题的总结 对于推理问题没有完善的解决方法，可以按下述三种思路来控制推理问题。 (1) 禁止明显的敏感数据：行动相当容易，但常常错误地选择了要禁止的数据，因而降低了可用性。

6.5.2 间接攻击(续) (2) 追踪用户已知的数据：虽然这种方法在提供数据时可能有最大的安全性，但是实现它的代价十分昂贵。 (3) 伪装数据：随机数扰乱或舍入可以限制依靠精确值进行逻辑和代数运算的统计攻击。但得到的数据是不精确或可能不一致的结果。 # 与安全中的其他问题一样，重视推理问题有助于理解控制这个问题的目的，同时对这个问题带来的潜在威胁更为敏锐，然而也不意味可以实现保护以防止这些攻击。

6.5.3 聚集 聚集(aggregation)意味着从较低敏感性的输入构造出敏感数据，它与推理问题相关。解决聚集问题很困难，因为它要求数据库管理系统追踪每个用户获得了哪些数据，以便回避一些可以让用户推导出更多敏感信息的数据。对聚集计算尤其困难，因为聚集是在系统外发生的。几乎没有什么方法提出来阻止聚集攻击。 最近对数据挖掘(data mining)的兴趣使聚集问题重新得到重视。数据挖掘是指在多个数据库中过滤数据并在相关联的数据元素中找到有用的信息。在一定事实的聚集下，要使谎言有说服力是很困难的。

6.6 多级数据库 到此为止，我们主要考虑了两种类型的数据：敏感数据和非敏感数据。我们提到一些数据项比其他数据项更敏感，但是只有允许访问和拒绝访问两种选择。 表 6.13 属性级敏感性(具有敏感性的属性加有阴影) Name Department Salary Phone Performance Hogers training 43,800 4-5067 A2 Jenkins research 62,900 6-4281 D4 Poling 38,200 4-4501 B1 Garland user services 54,600 6-6600 A4 Hilten 44,500 4-5351 Davis administration 51,400 4-9505 A3

6.6.1 区分安全级别的实例 表 6.14 数据与属性级敏感性(具有敏感性的属性加有阴影) Name Department Salary Phone Performance Hogers training 43,800 4-5067 A2 Jenkins research 62,900 6-4281 D4 Poling 38,200 4-4501 B1 Garland user services 54,600 6-6600 A4 Hilten 44,500 4-5351 Davis administration 51,400 4-9505 A3

6.6.1 区分安全级别的实例(续) 数据库显现出三个安全特性： (1) 一个元素的敏感度可能不同于同一记录的其他元素或同一属性的其他值。这种情形暗示了应该对每个元素单独实现安全保护。 (2) 敏感和不敏感两种级别不足以描述某些安全情况，而是需要多个安全级别。这些安全级别常常形成格。 (3) 数据库中的和、计数或一组值，其安全可能不同于单个元素的安全。集合安全可能高于也可能低于单个元素的安全。

6.6.2 粒度 为整个数据库中的每个数据定义敏感级别，类似于在一个文件中为每个词定义敏感级别。而且实际问题更加复杂，不仅每个元素有不同的敏感性，而且元素之间不同的组合也具有特殊的敏感性。此外，元素的组合敏感性可能高于或低于组成它的任何一个子元素。 保护每个元素的方法是：首先，需要访问控制策略来指定每个用户允许访问的数据。实现这一策略通常是为每个数据项定义访问限制。其次，需要保证元素值不会被未授权用户改变。这两个要求都涉及机密性和完整性。

6.6.3 安全问题 机密性/完整性 将*-特性应用于数据库中，访问控制原则描述成高级别的用户不允许写低级别的数据元素。但这种描述却常常出现问题，例如，DBMS因为如下原因必须能够读写所有记录并写新记录：备份数据、扫描数据库以响应查询、根据用户进程的需要重组数据库或更新数据库中的所有记录。在此可以考虑两种方法：高级别的进程不允许写低级别的数据，或者进程必须是“可信任的”即计算机如同具有安全许可的人一样。

6.6.3 安全问题(续) 一些保护机密性的措施是对数据做细微的修改。因此，在多级别数据库中，两个不同安全执行级别的用户可能执行相同的查询而得到不同的结果。为了保证机密性，不得不牺牲精确性。 加强机密性也导致了不易察觉的冗余。多重实例化(polyinstantiation)，意思是一个记录可以(被实例化)出现多次，每次有不同的机密级别。

6.6.3 安全问题(续) 表 6.15 多重实例化记录 Name Sensitivity Assignment Location Hill, Bob C Program Mgr London TS Secret Agent South Bend # 我们还可以找到导致多重实例化的其他原因，这些原因与敏感级别无关。因此，在减少多重实例化的同时，必须注意不能清除其中的合法记录。

6.7 关于多级安全的建议 6.7.1 分离 分区 一个大的数据库被分成几个分离开的数据库，每个都有自己的敏感级别。这种方法类似于把不同的文件保存在不同的文件柜里。这种控制机制失去了数据库的基本优点：消除冗余数据以及提高数据的正确性。数据库希望修改数据时，只需更新一个域即可。此外，这个控制机制没有解决高级别的用户，需要访问低级别的数据并与高级别的数据合并使用的问题。

6.7.1 分离(续) 加密 每个级别的敏感数据可以存储在一个加密表中，该表使用与敏感级别相对应的唯一密钥加密。但是加密也有一些不利的方面，如可能存在选择明文攻击的问题。为了克服这个缺点可以选择抵抗选择明文攻击的密码算法，也可以为记录的每个域使用不同的密钥加密，还可以为一个记录的所有域使用密码链加密。

6.7.1 分离(续) 图 6.5 密码分离：不同的加密密钥 图 6.6 密码分离：块链加密

6.7.1 分离(续) 这种方法的缺点是：当用户执行数据库的标准操作如“选择薪水大于10000的所有记录”时，查询必须为每个加密域解码 。这增加了查询操作的时间，因此，加密机制不常用来实现数据库的分离。

6.7.1 分离(续) 完整性锁 完整性锁(integrity lock)是美国空军在对数据库安全进行研究时首次提出的。完整性锁的数据项由三个部分组成：实际的数据本身、敏感性标签、以及校验和。敏感性标签定义了数据的敏感性，校验和的计算包括了数据和敏感性标签，以防止未授权者对数据或标签的篡改。为了提高效率，实际的数据项以明文方式存储。 图 6.7 完整性锁

6.7.1 分离(续) 敏感性标签应该是： (1) 不能被伪造的：恶意的主体不能为一个元素产生新的敏感级别。 (2) 唯一的：恶意的主体不能从其他元素复制敏感级别。 (3) 隐蔽的：恶意的主体不能确定任意元素的敏感级别。 完整性锁的第三个部分是一个检错码，称为密码校验和(cryptographic checksum)。为了保证数据值或其敏感级别未被修改，校验和对于每个元素必须是唯一的，必须包含数据值和数据值在数据库中的位置的指示。

6.7.1 分离(续) 一个合适的密码校验和应该包括：记录的唯一标识符(记录号)、记录中数据域的唯一标识符(域的属性名)、元素值以及元素的敏感级别。校验和可以用强密码算法计算。 图 6.8 密码校验和

6.7.1 分离(续) 敏感性锁 敏感性锁(sensitivity lock)由唯一的标识符(如记录号)和敏感级别组成。因为标识符是唯一的，每一个锁与一个特定的记录相关。敏感性锁与一个特定的记录相关，并且保证了该记录的敏感级别的保密性。 图 6.9 敏感性锁

6.7.2 多级安全数据库的设计 完整性锁 完整性锁的目的是能够让用户使用任何一个(不可信的)数据库管理器，该管理器有处理访问控制的可信任程序。用加密的方法隐藏数据以保护数据项及其敏感性。在这种方法中，因为只有访问程序可以实施或授权对敏感数据的访问，所以只需要它是可以信赖的。

6.7.2 多级安全数据库的设计(续) 图 6.10 可信数据库管理器

6.7.2 多级安全数据库的设计(续) 完整性锁的缺点： (1) 系统必须扩大存储数据的空间以容纳敏感性标签。 (2) 完整性锁处理时间的效率也是一个棘手的问题。为了保证访问的合法性，每次为用户传递一个数据时都需要对敏感性标签解码一次。 (3) 另一个难点是不可信的数据库管理器可以看到所有数据，因此，易遭受特洛伊木马的攻击，使数据通过隐蔽的信道被泄漏。

6.7.2 多级安全数据库的设计(续) 可信前端 前端也称为守卫(guard)，类似引用监视器。前端概念利用已有工具和专门技术，以微小的改变达到加强已存在数据库系统安全的目的。可信任前端的服务像是个单向过滤器，把用户不具有访问权限的数据筛选出来。因为需要先获得大量数据然后再丢弃用户不具访问权限的数据，所以这个方案的效率很不理想。

6.7.2 多级安全数据库的设计(续) 图 6.11 可信前端

6.7.2 多级安全数据库的设计(续) 用户、可信前端和DBMS之间的交互包括以下这些步骤： (1) 用户识别前端，前端鉴别用户身份。 (2) 用户向前端发出查询。 (3) 前端验证用户的授权数据。 (4) 前端向数据库管理器发出查询。 (5) 数据库管理器执行I/O访问，并与低级别的访问控制交互完成对实际数据的访问。 (6) 数据库管理器把查询的结果返回给可信前端。 (7) 前端分析结果中数据项的敏感级别，并选择出与用户安全级别相一致的数据。 (8) 前端把选择的结果传递给不可信前端以完成数据的格式化。 (9) 不可信前端把格式化后的数据传递给用户。

6.7.2 多级安全数据库的设计(续) 交换式过滤器 交换式过滤器(commutative filter)是一个程序，形成了用户和DBMS之间的接口。与可信前端不同，过滤器试图尽量考虑DBMS的效率。过滤器筛选了用户的请求，必要时就重新格式化请求，以使数据库管理器尽可能筛选掉许多不符合条件的数据。返回数据再经过过滤器二次筛选。过滤器可用于几个级别的安全：记录级、属性级或元素级： (1) 在记录级，过滤器请求希望的数据以及密码校验和信息，之后根据用户权限决定是否允许用户访问。 (2) 在属性级，过滤器检查用户查询的所有属性是否都是用户可以访问的。删除用户没有访问权限的所有域，之后传递给DBMS查询。 (3) 在元素级，系统请求希望的数据和密码校验和信息，将符合要求的元素返回给用户。

当然这些附加条件是前端过滤器添加的，用户是看不见的。 6.7.2 多级安全数据库的设计(续) 例如，对用户的查询： retrieve NAME where ((OCCUP=PHYSICIST) (CITY=WASHDC)) 过滤器可以转换为： retrieve NAME where ((OCCUP=PHYSICIST) (CITY=WASHDC)) from all records R where (NAME-SECRECY-LEVEL (R)≤USER-SECRECY-LEVEL) (OCCUP-SECRECY-LEVEL (R)≤USER-SECRECY-LEVEL)(CITY-SECRECY-LEVEL (R)≤USER-SECRECY-LEVEL)) 当然这些附加条件是前端过滤器添加的，用户是看不见的。

6.7.2 多级安全数据库的设计(续) 图 6.12 交换式过滤器 交换式过滤器的优点是允许选择查询、进行优化并且由DBMS处理一些子查询。这种职责的委托使安全过滤器保持很小，减少了DBMS和过滤器之间的冗余量，并且提高了整个系统的效率。

6.7.2 多级安全数据库的设计(续) 分布式数据库 分布式(distributed)或联合式数据库(federated database)的可信前端控制着两个商业DBMS的访问：一个负责敏感度低的数据，另一个负责敏感度高的数据。前端接收用户的查询，并把它们制定为一个合适的数据库的单级查询。如果用户可以访问高敏感度的数据，前端就同时向高、低敏感级两个数据库提交查询。其他情况，只能访问低敏感级数据库。如果从两个后台数据库获得结果，前端需要把结果适当组合起来。 因为前端必须可信，也很复杂，并且可能包括整个DBMS的大部分功能，所以分布式数据库的设计并不流行。另外，由于各个敏感级别的数据必须分别保存在所属级别的数据库中，所以这个设计也不适合于敏感级别很多的情况。

6.7.2 多级安全数据库的设计(续) 例如，航空公司的部分数据允许旅行社访问，可以为旅行社定义视图： 视窗/视图 视窗(window)或视图(view)的概念也是多级数据库访问的一个组织原则。视窗是数据库的一个子集，包含了用户授权访问的准确信息，用户的所有查询访问都只能针对这个子集。视图是数据库中一系列关系的详细描述，因此，一旦数据库中的数据改变，视图子集也随之发生改变。 例如，航空公司的部分数据允许旅行社访问，可以为旅行社定义视图： view AGENT-INFO FLTNO:=MASTER.FLTNO ORIG:=MASTER.ORIG DEST:=MASTER.DEST DEP:=MASTER.DEP ARR:=MASTER.ARR CAP:=MASTER.CAP where MASTER.TYPE='PASS' class AGENT auth retrieve

6.7.2 多级安全数据库的设计(续) 表 6.16 航班信息数据库 (a) 航空公司视图 (b) 旅行社视图 FLT# ORIG DEST DEP ARR CAP TYPE PILOT TAIL 362 JFK BWI 0830 0950 114 PASS Dosser 2463 397 ORD 1020 Bottoms 3621 202 IAD LGW 1530 0710 183 Jevins 2007 749 LGA ATL 0947 1120 CARGO Witt 3116 286 STA SFO 1150 117 Gross 4026 … (b) 旅行社视图 FLT# ORIG DEST DEP ARR CAP 362 JFK BWI 0830 0950 114 397 ORD 1020 202 IAD LGW 1530 0710 183 286 STA SFO 1150 117 …

6.7.2 多级安全数据库的设计(续) 在过滤(filtering)原始数据库的内容之后，把用户应获得的数据呈现给用户。除非用户有权访问至少一个元素，否则所有属性(列)都不能提供给用户。 对于记录(行)也是一样。保留用户无权访问的所有元素，元素值用UNDEFINED替代。最后一步不危及安全，因为用户知道这个属性的存在(至少有一个元素用户可以访问)并且也知道这个记录的存在(同样，至少有一个元素用户可以访问)。 视图还可以从新的和已存在的属性及元素中创建新的关系。这些新关系依据标准的访问权限，允许其他用户查询访问。用户只能在视图定义的数据库子集上操作，而且只能执行视图中授权的操作。

6.7.2 多级安全数据库的设计(续) Sea视图方案用分层方法实现了一个可信的数据库管理系统。最低层是引用监视器，第二层实现数据库基本索引和计算功能，第三层把视图转化为数据库的基本关系。这三个层次组成了系统的可信计算基(Trusted Computing Base, TCB)。其余的层实现了标准DBMS的功能和用户接口。这种分层方法使视图既是数据库的逻辑分离又是一项功能服务。

6.7.2 多级安全数据库的设计(续) 图 6.13 安全数据库的分层方法

6.7.3 应用问题 目前的结果是，多级安全数据库主要用于研究并且只具有历史意义。 多级数据库的概念非常重要，我们可以根据重要程度来区分数据。同样，我们需要一种方法能将不同敏感度的数据集成到一个数据库中。当大型数据库包含更多的敏感信息，特别存在涉及隐私问题时，随着时间的增长，这种需求将增加。

6.8 数据挖掘 大量数据被收集保存，而网络和互联网允许人们共享数据库，甚至是用以前无法想象的方式共享数据。但找到需要的数据就像大海捞针一样困难，因此，需要对数据进行智能分析和查询，于是数据挖掘(data mining)应运而生。数据挖掘应用以几乎自动的方式检索和搜索数据。

6.8 数据挖掘(续) 数据挖掘使用统计学、机器学习、数学模型、模式识别及其他技术发现一个大的数据集中的模式和相互关系。数据挖掘工具常常使用关联(某一事件常与另一事件同时发生)、序列(某一事件常导致另一事件发生)、分类(事件常表现出某种模式，如一致性)、聚类(有些数据项具有相同的特征)和预测(已经发生的事件预示未来将发生某一件事)等技术。数据挖掘应用与数据库的区别已越来越模糊。通常来说，数据库查询是人工的，而数据挖掘更加自动化。 数据挖掘提供一种可能关系，但它们是否属于因果关系，最终需要人来判断。

6.8 数据挖掘(续) 数据挖掘可使计算机更安全。数据挖掘广泛应用于系统数据分析，如审计日志，从而识别相关的攻击模式。发现攻击先兆可以帮助我们开发出更好的防攻击工具和技术，察觉到攻击相关的行为能帮助有效控制系统脆弱点阻止真正攻击的发生。

6.8.1 保密性与敏感性 因为数据挖掘的目标常常是综合结果，因此，看似不属于单个数据项的敏感性问题，但事实常常并非如此。个体保密存在前面提到的推理和聚集的问题。此外，通过推理和聚集得到的结果还可能影响公司、组织及政府。例如，来自超市的客户信息可以反映对厂商、广告商、健康研究者、政府食品监管机构、金融机构和研究人员等有用的市场结果。 但超市可以将这些结果提供给任何第三方。 对数据挖掘敏感性的研究非常少，一般方法是产生接近但不精确的聚集结果，从而避免公开敏感信息。

6.8.2 数据正确性和完整性 校正错误数据 当数据库为复制版本时，彻底纠正其中的错误是比较困难的。数据挖掘将恶化这种情况，推导出错误的结论。数据库的一个重要目标是：在一个地方只存在一份记录，以便在一处校正后所有的都能使用。数据挖掘的结果是来自多个数据库的一个聚集。没有一个自然的方法能从数据挖掘的结果追溯到合并前的数据库，发现并纠正错误。

6.8.2 数据正确性和完整性(续) 使用比较数据 数据挖掘时，另一个重要因素是数据语义。比如，两个包含家庭收入的数据库，一个以“元”为单位，另一个以“千元”为单位，合并原始数据库可能导致错误；还有一种情况，一个数据库的等级用“高/中/低”表示，另一个用“1”到“5”表示，它们之间又如何对应呢？ 消除错误的匹配 一致性并不是相关性或因果关系。两件事同时发生，并不意味一件事引发了另一件事。因此，在数据挖掘中错误匹配和错误连接也可能发生。挖掘结果的正确性和对结果的正确解释是数据挖掘安全的主要问题。

6.8.3 数据的可用性(续) 在不同数据库之间的互操作是数据挖掘的第三个安全问题。只有数据库在结构及语义上兼容才可能进行数据挖掘。缺失或不兼容的数据将导致数据挖掘结果不正确，在这种情况下，没有结果或许更为妥当。

6.9 本章总结 本章重点研究了DBMS三个方面的安全问题：特定数据库应用软件的机密性和完整性问题、统计数据库的推理问题、一个数据库中不同敏感级别的用户和数据问题。 本章讨论的几种技术主要针对数据库管理系统。解决任何应用软件的安全需求的典型方法是先分析问题，然后找到解决技术。在某种意义上，必须做出威胁分析，一旦猜测出破坏安全的方法，就可能研究出加强安全的方法，再将其内置到应用设计中，而不是在安全被破坏后才来补救。

谢谢！