翻译:中国科学技术大学信息安全专业老师 第四部分理论 第14章数据库安全 数据库不仅仅存储数据,事实上它为用户提供信息。因此,数据库安全不仅要考虑保护敏感数据,而且要考虑 使用户以受控制的方式检索数据的机制。这里强调了把数据库安全和操作系统安全区分开来。比起对数据的访问控 制,我们应该更强调对信息的访问控制。尽管保护数据的安全是一个重要问题,但我们绝对应该把控制集中在请求 访问的目标上 目标 分析数据库系统特有的安全问题 理解各种安全观点如何应用到关系数据库系统的访问控制上去 分析在统计数据库中保护信息安全的问题 考察在数据库管理系统和操作系统中的安全机制之间潜在的相互作用 141简介 数据库是以某种有特定意义的方式组织起来的数据的集合。一个数据库管理系统(DBMS)负责管理数据并给用 户以检索信息的手段。如果对信息的访问完全失控,用户将不再把某些数据放入数据库中,数据库只能提供很少有 用的服务了。例如,数据库常常存储了许多个人信息,像公司雇员档案、大学学生档案,以及税务局税收资料等。 很多国家已经制定了个人隐私法案,强制维护这种数据库的机构承担保护个人数据安全的责任。因此,很早以来, 数据库安全就在计算机安全中占有重要的一席之地。这是一个特别的一席之地,因为数据库安全是不同于操作系统 安全的。下面对这种说法给予具体说明。 操作系统确实管理数据。用户执行操作系统功能,创建文件、删除文件,或者为读、写访问而打开一个文件。 但是这些操作都不涉及文件的内容。说得更明确一些,访问控制的决定是由操作系统做出的,这些决定取决于对用 户的识别、文件属性的定义、访问控制列表、安全标识符等等,但是与文件内容无关。这样做不是因为基于某种基 本的安全理论,而只是一种合理的工程考虑 数据库中的表项携带有信息。数据库用户执行的是与数据库表项内容有关的操作。数据库最典型的应用恐怕要 算是数据库搜索了。因此,由数据库管理系统在同时考虑数据库表项内容的情况下做出访问控制的决定就是十分合 理的了。一个很通俗的例子就是工资数据库,达到一定数额的工资就需要保密了。总之,在人机环境中,数据库安 全是侧重在用户端的(见图141 初看起来,在数据库中保护敏感信息似乎很容易。在工资数据库中,你只要简单地往查询语句上增加条件来检 查工资额。如果你知道要保护哪些数据,这种方法确实是可行的。然而,入侵者可能会对许多信息的不同片断感兴 趣。下面列出了可能的信息源 准确的数据:存储在数据库中的数值。 边界:数值的下界或上界,像工资就是有用的信息。 负面的材料:如果数据库包含罪犯定罪数字,那么,这种涉及某人有罪的信息就是敏感的 存在性:数据的存在性本身也可能是敏感信息。 可能的数值:能够从其他查询的结果中猜测一些信息。 最后,你必须防止所有的不测事件。如果数据库允许统计查询,信息的保护就变得更加困难。比如,一次统计 查询返回所有工资总和,或者所有工资的平均数。这种查询的巧妙组合可能会暴露你试图保护的信息。这个话题我 们将在144节中进一步讨论 我们已经对敏感信息可能会从数据库泄露的许多途径提出了警告。你应该很重视安全性问题,然而,你也不要 忘了数据库就是要为正当目的提供服务的。如果对数据的访问限制得过严,虽然不会泄露敏感信息,但是会降低数 第1页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 1 页 共 31 页 创建日期：2003-11 第四部分 理论 第 14 章 数据库安全 数据库不仅仅存储数据，事实上它为用户提供信息。因此，数据库安全不仅要考虑保护敏感数据，而且要考虑 使用户以受控制的方式检索数据的机制。这里强调了把数据库安全和操作系统安全区分开来。比起对数据的访问控 制，我们应该更强调对信息的访问控制。尽管保护数据的安全是一个重要问题，但我们绝对应该把控制集中在请求 访问的目标上。 目标： ⚫ 分析数据库系统特有的安全问题 ⚫ 理解各种安全观点如何应用到关系数据库系统的访问控制上去 ⚫ 分析在统计数据库中保护信息安全的问题 ⚫ 考察在数据库管理系统和操作系统中的安全机制之间潜在的相互作用 14.1 简介 数据库是以某种有特定意义的方式组织起来的数据的集合。一个数据库管理系统(DBMS)负责管理数据并给用 户以检索信息的手段。如果对信息的访问完全失控，用户将不再把某些数据放入数据库中，数据库只能提供很少有 用的服务了。例如，数据库常常存储了许多个人信息，像公司雇员档案、大学学生档案，以及税务局税收资料等。 很多国家已经制定了个人隐私法案，强制维护这种数据库的机构承担保护个人数据安全的责任。因此，很早以来， 数据库安全就在计算机安全中占有重要的一席之地。这是一个特别的一席之地，因为数据库安全是不同于操作系统 安全的。下面对这种说法给予具体说明。 操作系统确实管理数据。用户执行操作系统功能，创建文件、删除文件，或者为读、写访问而打开一个文件。 但是这些操作都不涉及文件的内容。说得更明确一些，访问控制的决定是由操作系统做出的，这些决定取决于对用 户的识别、文件属性的定义、访问控制列表、安全标识符等等，但是与文件内容无关。这样做不是因为基于某种基 本的安全理论，而只是一种合理的工程考虑。 数据库中的表项携带有信息。数据库用户执行的是与数据库表项内容有关的操作。数据库最典型的应用恐怕要 算是数据库搜索了。因此，由数据库管理系统在同时考虑数据库表项内容的情况下做出访问控制的决定就是十分合 理的了。一个很通俗的例子就是工资数据库，达到一定数额的工资就需要保密了。总之，在人机环境中，数据库安 全是侧重在用户端的(见图 14.1)。 初看起来，在数据库中保护敏感信息似乎很容易。在工资数据库中，你只要简单地往查询语句上增加条件来检 查工资额。如果你知道要保护哪些数据，这种方法确实是可行的。然而，入侵者可能会对许多信息的不同片断感兴 趣。下面列出了可能的信息源： ⚫ 准确的数据：存储在数据库中的数值。 ⚫ 边界：数值的下界或上界，像工资就是有用的信息。 ⚫ 负面的材料：如果数据库包含罪犯定罪数字，那么，这种涉及某人有罪的信息就是敏感的。 ⚫ 存在性：数据的存在性本身也可能是敏感信息。 ⚫ 可能的数值：能够从其他查询的结果中猜测一些信息。 最后，你必须防止所有的不测事件。如果数据库允许统计查询，信息的保护就变得更加困难。比如，一次统计 查询返回所有工资总和，或者所有工资的平均数。这种查询的巧妙组合可能会暴露你试图保护的信息。这个话题我 们将在 14.4 节中进一步讨论。 我们已经对敏感信息可能会从数据库泄露的许多途径提出了警告。你应该很重视安全性问题，然而，你也不要 忘了数据库就是要为正当目的提供服务的。如果对数据的访问限制得过严，虽然不会泄露敏感信息，但是会降低数
翻译:中国科学技术大学信息安全专业老师 据库的价值。因此,你不得不力求准确,也就是说,在尽可能只泄露无用信息的情况下保护好敏感信息。 图14.1在人一机标度中数据库安全的位置 数据库表项携带了实体外部到计算机系统的信息,像仓库的库存,学生考试成绩,银行帐户结余,或者航班的 空座数。数据库表项应该正确地反映这些客观的事实。数据库安全结合特定应用的完整性保护来达到: 内部的一致性:数据库表项遵循某些事先确定的规则。比如,库存值不能小于零 外部的一致性:数据库表项必须是正确的。比如,数据库中的库存值必须与仓库中的库存一致。当更新数 据库时数据库管理系统可以避免一些错误,但是你不能仅仅依赖数据库管理系统来保持数据库处于一致性 的状态。这种特性称为精确性。 在1.4节的分层模型中,数据库管理系统DBMS可以放在操作系统之上的服务层中。DBMS 必须满足操作系统无法解决的特定数据库(数据库特定的, database- specific)安全需求。DBMS可以结合在操作 系统中的几种保护机制来加强安全性,如果操作系统不具备适当的控制机制或者如果这样做变得很麻烦的话,就依 靠DBMS自身的机制。此外,DBMS可以是在应用层定义安全控制的工具。图14.2揭示了这样的事实:数据库安 全包括了在相当不同的抽象层次中的安全机制 图142数据库安全的位置 142关系数据库 在构造数据库的各种模型中,使用得最为广泛的是关系模型。我们再次假定读者熟悉关系数据库的有关概念 里仅对其作简要介绍。详细叙述请见参考文献[37] 关系数据库:关系数据库是一个被它的用户感知为一个表集合的数据库,并且只是各种表而已。 关系数据库的定义归诸于用户对它的理解,而不是它的实际的(物理, physical)组织。这样也恰好成为讨论 数据库安全的适当的抽象。 形式上,一个关系R,是D×…XDn的子集,这里D2…,D是n维属性域。关系中的元素是n元组(v1…,v) 其中ν∈D,也就是说,第ⅰ个属性值是来自D的元素。元组中的元素通常被称为域。当一个域没有任何值时, 我们会在这个位置上放一个特殊的值一一空值来表示。空值的含义是“这里没有该项”,而不是“该项是未知的”。 在图143中的关系表是一家旅行社数据库的一部分。关系Day有四个属性,name,day, flight和 status,每 个属性的取值范围如下 Name:所有有效的客户名 Day:一周中的每一天,比如,Mon,Tue,wed,mhu,Fri,Sat,sune Flight:航班号,两个字符后再加上1-4个数字。 Status:公务( business)或是私人( private) 用来描述如何在关系数据库中检索和更新信息的标准语言是SQL语言,在文献[52]中又被称为结构化查询语言。 SQL对数据处理的操作包括了以下几个方面 SELECT:从一个关系中检索数据 例如 SELECT Name Status FROM Diary WHERE Day ="Mon 返回结果 Status business 图143 第2贝共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 2 页 共 31 页 创建日期：2003-11 据库的价值。因此，你不得不力求准确，也就是说，在尽可能只泄露无用信息的情况下保护好敏感信息。 图 14.1 在人－机标度中数据库安全的位置 数据库表项携带了实体外部到计算机系统的信息，像仓库的库存，学生考试成绩，银行帐户结余，或者航班的 空座数。数据库表项应该正确地反映这些客观的事实。数据库安全结合特定应用的完整性保护来达到： ⚫ 内部的一致性：数据库表项遵循某些事先确定的规则。比如，库存值不能小于零。 ⚫ 外部的一致性：数据库表项必须是正确的。比如，数据库中的库存值必须与仓库中的库存一致。当更新数 据库时数据库管理系统可以避免一些错误，但是你不能仅仅依赖数据库管理系统来保持数据库处于一致性 的状态。这种特性称为精确性。 在 1.4 节的分层模型中，数据库管理系统 DBMS 可以放在操作系统之上的服务层中。DBMS 必须满足操作系统无法解决的特定数据库（数据库特定的，database－specific）安全需求。DBMS 可以结合在操作 系统中的几种保护机制来加强安全性，如果操作系统不具备适当的控制机制或者如果这样做变得很麻烦的话，就依 靠 DBMS 自身的机制。此外，DBMS 可以是在应用层定义安全控制的工具。图 14.2 揭示了这样的事实：数据库安 全包括了在相当不同的抽象层次中的安全机制。 图 14.2 数据库安全的位置 14.2 关系数据库 在构造数据库的各种模型中，使用得最为广泛的是关系模型。我们再次假定读者熟悉关系数据库的有关概念， 这里仅对其作简要介绍。详细叙述请见参考文献[37]。 关系数据库：关系数据库是一个被它的用户感知为一个表集合的数据库，并且只是各种表而已。 关系数据库的定义归诸于用户对它的理解，而不是它的实际的（物理，physical）组织。这样也恰好成为讨论 数据库安全的适当的抽象。 形式上，一个关系 R，是 D D 1 n 的子集，这里 1 ,..., D D n 是 n 维属性域。关系中的元素是 n 元组 1 ( ,..., ) n v v ， 其中 i i v D ，也就是说，第 i 个属性值是来自 Di 的元素。元组中的元素通常被称为域。当一个域没有任何值时， 我们会在这个位置上放一个特殊的值——空值来表示。空值的含义是“这里没有该项”，而不是“该项是未知的”。 在图 14.3 中的关系表是一家旅行社数据库的一部分。关系 Diary 有四个属性，name，day，flight 和 status，每 个属性的取值范围如下： ⚫ Name：所有有效的客户名。 ⚫ Day： 一周中的每一天，比如，Mon，Tue，Wed，Thu，Fri，Sat，Sun。 ⚫ Flight：航班号，两个字符后再加上 1—4 个数字。 ⚫ Status：公务（business）或是私人（private）。 用来描述如何在关系数据库中检索和更新信息的标准语言是 SQL 语言，在文献[52]中又被称为结构化查询语言。 SQL 对数据处理的操作包括了以下几个方面。 SELECT：从一个关系中检索数据 例如： SELECT Name, Status FROM Diary WHERE Day = ‘Mon’ 返回结果 图 14.3 Name Status Alice Private Bob business
翻译:中国科学技术大学信息安全专业老师 UPDATE:更新一个关系中的域值 例如 UPDAT SET St WHERE Day ="Sun 把所有星期天的旅游团标记为私人旅游团(长途旅行, Journey) DELETE:从一个关系中删除元组 例如 DELETE FROM Diary WHERE Name='Alice 从 Diary中删除所有Alce参加的旅游团。 NSERT:在一个关系中添加元组 例如 INSERT INTO Flights(Flight, Destination, Days) 在关系 Flights中插入了一个新的元组,其中 Departs域仍然未给出。 在所有情况下,可能有更复杂的结构。本书的目的并不在于阐述SQL的复杂性,对此我们只会给出一个例子 加以说明。比如,为找出谁会去 Thule,执行以下语句: SELECT Name FROM Diary WHERE Flight In (SELECT Flight ROM FIN WHERE Destination="THU) 数据关系常常用表来表示。属性相当于表中的列,用属性名作为列的标题。表中的行相当于数据库中的元组(记 录)。在关系模型中,一个关系不包括到指向其他表的连接或指针。表与表之间的关系( relations)只能通过另一个关 系给出。在关系数据库里,可能存在不同种类的关系 ●基本关系:又被称为实际关系( real relations),它们是被命名的自主(自治的, autonomous)关系:它们 本来就存在,而不是从其他关系导出的,它们有其自身的存储数据 视图:它们是被命名的导出关系,根据其他被命名的关系定义:它们没有其自身的存储数据。 快照:与视图一样,快照是被命名的导出关系,根据其他被命名的关系定义:它们有其自身的存储数据 查询结果:一个查询操作的结果:它们可能有也可能没有名字。本质上它们不是常驻在数据库中的 例如:一个在 Diary表中查询谁以及何时正在旅行的快照操作定义如下 CREATE SNAPSHOT Travellers AS SELECT name, day FROM Diary 14.2.1数据库关键字 在每个关系中,我们必须找到一个能识别所有元组的唯一方式。有时,一个单独的属性可以用来作为这样的标 识符。甚至可能像这样的属性有很多,我们可以从中选取一个来达到识别的目的。而另一方面,我们也许需要不止 一个属性一起来组成一个唯一的标识符。 定义一个关系的主关键字是指该关系的一个唯一的、最小的标识符。关系R中的主关键字K必须满足以下条 件 唯一性:在任何时候,关系R中没有一个元组的值对K而言是相同的 第3页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 3 页 共 31 页 创建日期：2003-11 UPDATE：更新一个关系中的域值 例如： UPDATE Diary SET Status = private WHERE Day = ‘Sun’ 把所有星期天的旅游团标记为私人旅游团（长途旅行，journey）。 DELETE：从一个关系中删除元组 例如： DELETE FROM Diary WHERE Name = ‘Alice’ 从 Diary 中删除所有 Alice 参加的旅游团。 INSERT：在一个关系中添加元组 例如： INSERT INTO Flights (Flight, Destination, Days) VALUES (‘GR005’, ‘GOH’, ‘12-45-’) 在关系 Flights 中插入了一个新的元组，其中 Departs 域仍然未给出。 在所有情况下，可能有更复杂的结构。本书的目的并不在于阐述 SQL 的复杂性，对此我们只会给出一个例子 加以说明。比如，为找出谁会去 Thule，执行以下语句： SELECT Name FROM Diary WHERE Flight IN (SELECT Flight FROM Flights WHERE Destination = ‘THU’) 数据关系常常用表来表示。属性相当于表中的列，用属性名作为列的标题。表中的行相当于数据库中的元组（记 录）。在关系模型中，一个关系不包括到指向其他表的连接或指针。表与表之间的关系(relations)只能通过另一个关 系给出。在关系数据库里，可能存在不同种类的关系： ⚫ 基本关系：又被称为实际关系（real relations），它们是被命名的自主（自治的，autonomous）关系：它们 本来就存在，而不是从其他关系导出的，它们有其自身的存储数据。 ⚫ 视图：它们是被命名的导出关系，根据其他被命名的关系定义：它们没有其自身的存储数据。 ⚫ 快照：与视图一样，快照是被命名的导出关系，根据其他被命名的关系定义：它们有其自身的存储数据。 ⚫ 查询结果：一个查询操作的结果；它们可能有也可能没有名字。本质上它们不是常驻在数据库中的。 例如：一个在 Diary 表中查询谁以及何时正在旅行的快照操作定义如下： CREATE SNAPSHOT Travellers AS SELECT name, day FROM Diary 14.2.1 数据库关键字 在每个关系中，我们必须找到一个能识别所有元组的唯一方式。有时，一个单独的属性可以用来作为这样的标 识符。甚至可能像这样的属性有很多，我们可以从中选取一个来达到识别的目的。而另一方面，我们也许需要不止 一个属性一起来组成一个唯一的标识符。 定义 一个关系的主关键字是指该关系的一个唯一的、最小的标识符。关系 R 中的主关键字 K 必须满足以下条 件： ⚫ 唯一性：在任何时候，关系 R 中没有一个元组的值对 K 而言是相同的
翻译:中国科学技术大学信息安全专业老师 最小性:如果K是一组合关键字,在满足唯一性的条件下,K中的每个成员都不能少。 在上面关系 Diary的例子中,名字和日期的组合可以作为主关键字(假定旅客每天只能跟一个旅游团出行)。在关 系 Flights中,主关键字是飞机的航班号 每个关系必须有一个主关键字,就像没有关系会包含复合元组( duplicate tuples)一样。这是由我们对关系 的正规定义得出来的。当一个关系的主关键字作为另一关系中的一个属性时,那么它就是那个关系的外关键字。在 我们的例子中,飞机的航班号在关系 Flights中是主关键字,但在关系 Diary中就是外关键字 14.2.2完整性规则 在关系数据库中,你可以通过定义完整性规则来实现内部的一致性,并且帮助保持外部的一致性(精确性) 这些规则的大多数是针对应用程序而言,但有两条规则是关系数据库模型特有的 实体完整性规则基本关系的主关键字属性组合中的任一属性或属性组合子集都不允许有空值。 这个规则可以保证我们能在基本关系中找到所有的元组。这些在基本关系中的元组与“现实”中的实体一一对 应,并且我们不会在数据库中建立一个我们不能识别的实体描述 引用完整性规则数据库中不能包含不匹配的外关键字值。 个外关键字值申明了一个进入其他表的引用( reference)。一个不匹配的外关键字值是指,在被引用的表中 它不是作为一个主关键字值。它是一个对不存在元组的引用。 除这两条规则外,人们可能需要更多的特定应用的(应用特定的/专用的, application- specific)完整性规 则。这些完整性规则非常重要,因为它们能让数据库一直处于可用状态。典型地,你会使用这些完整性规则做以下 事情 域检査:防止错误的数据输入。在我们的例子中,可以通过一条规则来检查输入值是否是 business或 private, 从而防止向 Diary关系的 status属性插入任意值。 范围检査:在统计数据库中,你可能需要一些规则来检査,查询结果是否是基于一个足够大的样本空间来计算 的。先来看图14.4的 Students关系,你可以定义这样一条规则,当样本空间不大于三时,就返回平均成绩的 默认值67。 一致性检查:在不同关系中的表项可能指的是外界的同一个方面,因此,也应该在这方面表现出一致性。在我 们的例子中,可以检查旅客启程旅行的日期是否与他们航班起飞的日期相吻合。例如, Alice乘坐的星期一的 GR123型航班,就与该航班只在星期一和星期四起飞相一致。而 Carol预定星期二的Bx20l型航班,就与该航 班在星期一、星期三和星期六起飞不一致。一条像这样比较各自的域的完整性规则,可以避免旅行社发生这样 的错误 像这类的完整性规则是在应用层中控制的。数据库管理系统为指定和实现这些规则提供了基础。例如,完整性 触发器就是这样的一个程序,它可以附带在一个数据库的对象中,用来检査该对象的一些特殊的完整性特性。当 个更新( UPDATE)、插入( INSERT)或删除( DELETE)操作企图更改该对象时,这个程序就被触发并执行这一检查。 在指出了关于机密性和完整性之间的潜在冲突之后,我们将不再就这个话题做更深入的探讨。当计算一个完整 性规则而要求访问敏感信息时,你就会面临这样的两难境地:是为了保护敏感信息而不完全(和不正确)地计算规 则,还是为了维护数据库的一致性而泄漏一些敏感信息 143访问控制 为保护敏感信息,数据库管理系统必须对用户如何访问数据库进行控制。要弄清楚这些控制是如何实现的,你 可以分两个层次来考虑访问数据库: 对基本关系的数据处理操作 复合操作,如视图或快照操作 简短回顾一下1.4.1节。你可以从两个角度来看访问控制: 第4页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 4 页 共 31 页 创建日期：2003-11 ⚫ 最小性：如果 K 是一组合关键字，在满足唯一性的条件下，K 中的每个成员都不能少。 在上面关系 Diary 的例子中，名字和日期的组合可以作为主关键字（假定旅客每天只能跟一个旅游团出行）。在关 系 Flights 中，主关键字是飞机的航班号。 每个关系必须有一个主关键字，就像没有关系会包含复合元组（duplicate tuples）一样。这是由我们对关系 的正规定义得出来的。当一个关系的主关键字作为另一关系中的一个属性时，那么它就是那个关系的外关键字。在 我们的例子中，飞机的航班号在关系 Flights 中是主关键字，但在关系 Diary 中就是外关键字。 14.2.2 完整性规则 在关系数据库中，你可以通过定义完整性规则来实现内部的一致性，并且帮助保持外部的一致性（精确性）。 这些规则的大多数是针对应用程序而言，但有两条规则是关系数据库模型特有的。 实体完整性规则 基本关系的主关键字属性组合中的任一属性或属性组合子集都不允许有空值。 这个规则可以保证我们能在基本关系中找到所有的元组。这些在基本关系中的元组与“现实”中的实体一一对 应，并且我们不会在数据库中建立一个我们不能识别的实体描述。 引用完整性规则 数据库中不能包含不匹配的外关键字值。 一个外关键字值申明了一个进入其他表的引用（reference）。一个不匹配的外关键字值是指,在被引用的表中 它不是作为一个主关键字值。它是一个对不存在元组的引用。 除这两条规则外，人们可能需要更多的特定应用的（应用特定的/专用的，application-specific）完整性规 则。这些完整性规则非常重要，因为它们能让数据库一直处于可用状态。典型地，你会使用这些完整性规则做以下 事情： ⚫ 域检查：防止错误的数据输入。在我们的例子中，可以通过一条规则来检查输入值是否是 business 或 private, 从而防止向 Diary 关系的 status 属性插入任意值。 ⚫ 范围检查：在统计数据库中，你可能需要一些规则来检查，查询结果是否是基于一个足够大的样本空间来计算 的。先来看图 14.4 的 Students 关系，你可以定义这样一条规则，当样本空间不大于三时，就返回平均成绩的 默认值 67。 ⚫ 一致性检查：在不同关系中的表项可能指的是外界的同一个方面，因此，也应该在这方面表现出一致性。在我 们的例子中，可以检查旅客启程旅行的日期是否与他们航班起飞的日期相吻合。例如，Alice 乘坐的星期一的 GR123 型航班，就与该航班只在星期一和星期四起飞相一致。而 Carol 预定星期二的 BX201 型航班，就与该航 班在星期一、星期三和星期六起飞不一致。一条像这样比较各自的域的完整性规则，可以避免旅行社发生这样 的错误。 像这类的完整性规则是在应用层中控制的。数据库管理系统为指定和实现这些规则提供了基础。例如，完整性 触发器就是这样的一个程序，它可以附带在一个数据库的对象中，用来检查该对象的一些特殊的完整性特性。当一 个更新（UPDATE）、插入（INSERT）或删除（DELETE）操作企图更改该对象时，这个程序就被触发并执行这一检查。 在指出了关于机密性和完整性之间的潜在冲突之后，我们将不再就这个话题做更深入的探讨。当计算一个完整 性规则而要求访问敏感信息时，你就会面临这样的两难境地：是为了保护敏感信息而不完全（和不正确）地计算规 则，还是为了维护数据库的一致性而泄漏一些敏感信息。 14.3 访问控制 为保护敏感信息，数据库管理系统必须对用户如何访问数据库进行控制。要弄清楚这些控制是如何实现的，你 可以分两个层次来考虑访问数据库： ⚫ 对基本关系的数据处理操作； ⚫ 复合操作，如视图或快照操作。 简短回顾一下 1.4.1 节。你可以从两个角度来看访问控制：
翻译:中国科学技术大学信息安全专业老师 限制用户可获得的操作,或者 为每个单独的数据项定义保护的要求。 在一个数据库管理系统中,对复合操作的控制规范了用户可以如何使用数据库。另一方面,对基本关系的操作 检査更能保护数据库中的表项。通过选取你想要控制的访问操作类型,你也影响了将要被执行的策略的重点所在 反之,策略的重点也会影响你要控制的操作类型。不管如何选择,有两个特性是你应该争取达到的: 完全性:保护数据库中的所有的域 致性:没有相互冲突的对数据项的访问进行管理的规则。 如果在数据库中没有元素会被以不同的方式访问,从而导致不同的访问控制的选取,这样的安全策略才是一致 的。合理的访问要求不应被阻止,也不能使指定的访问策略让人有机可乘 14.3.1SQL的安全模型 基本的SL安全模型和关系数据库的安全模型很相似。它基于三个实体实现了自主访问控制( discretionary access control ) ●用户实体:数据库的用户。在登录过程中用户身份得到认证。数据库管理系统可以运行自己的登录进程,或是 接受由操作系统认证的用户身份。 操作实体:包括选取( SELECT)、更新( UPDATE)、删除( DELETE)和插入( INSERT) 对象实体:表、视图、以及表和视图的列(属性)。SQL3还将进一步包括用户定义的约束条件( constructs)a 用户会在对象上执行一些操作,而数据库管理系统应该决定是否允许这样的操作。当用户创建了一个对象,该用户 就被指定为此对象的所有者,并且最初只有此对象的所有者可以访问它。其他用户必须先被授予优先权( privilege) 才可以访问它。优先权的形式如下: (授权者,被授权者,对象,操作,优先权级别) SL安全模型的两大支柱是优先权和视图。它们为定义面向应用的安全策略提供了框架。 14.3.2优先权的颁发与撒销 在SL中,我们通过 GRANT和 REVOKE操作来管理优先权。优先权对应着特殊的操作,并且可以将它限制到表 中的某个属性。在我们的例子中,允许两个旅行社Art和Zoe,检查和更新表 Diary中的某些部分: GRANT SELECT, UPDATE(Day, Flight) ON TABLE Diary TO Art. Zoe 优先权可以有选择地被撤销: REVOKE UPDATE ON TABLE Diary FROM Art 更特别的是,可以让被授予优先权的人再去颁发优先权给第三者。在SQL中是由 GRANT操作来实现的。例如: GRANT SELECT ON TABLE Diary TO Art WITH GRANT OPTION 旅行社Art可以依次把对表 Diary的优先权颁发给Zoe, GRANT SELECT ON TABLE Diary to Zoe WITH GRANT OPTION 当表 Diary的所有者将颁发给Art的优先权撤销时,所有由Art颁发的优先权也会被撤销。因此,优先权被一 层一层地撤销( cascade),而撤销时所需要的信息被保存在数据库中 你还应该注意到,一旦其他用户被授权访问数据,这些数据的所有者就再无法控制从这些数据导出的信息将会 如何被使用,即使所有者对原始数据仍有一定的控制。你不再需要任何对访问原始表的“写”命令要求,而可以直 第5页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 5 页 共 31 页 创建日期：2003-11 ⚫ 限制用户可获得的操作，或者 ⚫ 为每个单独的数据项定义保护的要求。 在一个数据库管理系统中，对复合操作的控制规范了用户可以如何使用数据库。另一方面，对基本关系的操作 检查更能保护数据库中的表项。通过选取你想要控制的访问操作类型，你也影响了将要被执行的策略的重点所在。 反之，策略的重点也会影响你要控制的操作类型。不管如何选择，有两个特性是你应该争取达到的： ⚫ 完全性：保护数据库中的所有的域。 ⚫ 一致性：没有相互冲突的对数据项的访问进行管理的规则。 如果在数据库中没有元素会被以不同的方式访问，从而导致不同的访问控制的选取，这样的安全策略才是一致 的。合理的访问要求不应被阻止，也不能使指定的访问策略让人有机可乘。 14.3.1 SQL 的安全模型 基本的 SQL 安全模型和关系数据库的安全模型很相似。它基于三个实体实现了自主访问控制（discretionary access control）： ⚫ 用户实体：数据库的用户。在登录过程中用户身份得到认证。数据库管理系统可以运行自己的登录进程，或是 接受由操作系统认证的用户身份。 ⚫ 操作实体：包括选取（SELECT）、更新（UPDATE）、删除（DELETE）和插入（INSERT）。 ⚫ 对象实体：表、视图、以及表和视图的列（属性）。SQL3 还将进一步包括用户定义的约束条件（constructs）。 用户会在对象上执行一些操作，而数据库管理系统应该决定是否允许这样的操作。当用户创建了一个对象，该用户 就被指定为此对象的所有者，并且最初只有此对象的所有者可以访问它。其他用户必须先被授予优先权（privilege） 才可以访问它。优先权的形式如下： （授权者，被授权者，对象，操作，优先权级别） SQL 安全模型的两大支柱是优先权和视图。它们为定义面向应用的安全策略提供了框架。 14.3.2 优先权的颁发与撤销 在 SQL 中，我们通过 GRANT 和 REVOKE 操作来管理优先权。优先权对应着特殊的操作，并且可以将它限制到表 中的某个属性。在我们的例子中，允许两个旅行社 Art 和 Zoe，检查和更新表 Diary 中的某些部分： GRANT SELECT, UPDATE (Day, Flight) ON TABLE Diary TO Art, Zoe 优先权可以有选择地被撤销： REVOKE UPDATE ON TABLE Diary FROM Art 更特别的是，可以让被授予优先权的人再去颁发优先权给第三者。在 SQL 中是由 GRANT 操作来实现的。例如： GRANT SELECT ON TABLE Diary TO Art WITH GRANT OPTION 旅行社 Art 可以依次把对表 Diary 的优先权颁发给 Zoe, GRANT SELECT ON TABLE Diary TO Zoe WITH GRANT OPTION 当表 Diary 的所有者将颁发给 Art 的优先权撤销时，所有由 Art 颁发的优先权也会被撤销。因此，优先权被一 层一层地撤销（cascade），而撤销时所需要的信息被保存在数据库中。 你还应该注意到，一旦其他用户被授权访问数据，这些数据的所有者就再无法控制从这些数据导出的信息将会 如何被使用，即使所有者对原始数据仍有一定的控制。你不再需要任何对访问原始表的“写”命令要求，而可以直
翻译:中国科学技术大学信息安全专业老师 接从一张表中读出数据,以及将这些数据拷贝到另一张表中 14.3.3通过视图的访问控制 视图是导出关系。SQL中创建视图的操作格式如下 CREATE VIEW view name[(column[, column].] query [WITH CHECK OPTION] 你可以在关系数据库中通过直接对基本关系中的表项授予优先权来实现访问控制。然而,很多安全策略可以更好地 由视图以及这些视图的优先权来表现。在视图中的子查询定义可以描述非常复杂的访问条件。举一个简单的例子 我们在关系 Diary中组建一个包括所有公务旅行的视图: CREATE VIEW business trips as SELECT FROM Diary Where status=' business WITH CHECK OPTIO 通过视图,访问控制可以适当地被放置在应用层。数据库管理系统只提供执行这些控制的工具。视图吸引我们的原 因有以下几点: 视图很灵活,并且允许我们在描述层定义访问控制,这样可以更贴近应用的要求 视图可以实现上下文依赖的和数据依赖的安全策略。 视图可以执行控制调用( controlled invocation) 安全的视图可以取代安全标识(标签, security labels) 可以很容易地对数据进行重新分类。 在图14.4给出的例子中,面向应用的访问控制可以通过视图表示如下, CREATE VIEW High Flyers As SELECt *k FROM Students Where Grade (SELECT Grade FROM Students WHERE Name=current user O) 结果只显示那些平均成绩比正在使用该视图的学生成绩高的学生,或者: CREATE VIEW My Journeys As SELECT FROM Diary WHERE Customer=current user O 只显示在图14.3中由正在使用此视图的旅客预订的那些旅行线路。可以通过在数据库中添加访问控制表来实现自 主访问控制。这儿的视图指的就是此关系。通过这种方式,你可以实现基于组成员关系的访问控制,也可以通过策 略来调整用户的权限使其和颁发和撤销访问权限一样。 图144关系 Student 进一步说,视图可以定义为或指的就是安全标识。在我们的例子中,可以通过创建视图把到 Thule的商业航班 标记为机密的 CREATE VIEW Flights 2 CONFIDENTIAL AS SELECT s FROM Diary WHERE Destination= thu aNd Status= business 通过视图来控制读取访问时,除了正确地获取安全政策外,便不会再有其他技术上的特殊困难了。当视图使用插入 ( INSERT)或更新( UPDATE)操作对数据库进行写入时,情况就不同了。首先,存在一些不能更新的视图,因为它 们不包含这样的信息,这些信息对于维护相应的基本关系的完整性是必需的。例如,一个不包含基本关系的主关键 字的视图是不能被更新的。其次,即使一个视图是可更新的,仍会有一些有趣的安全问题在里面。一个可以访问 Diary数据库的旅行社只能通过 business_ trips视图查看到列在表14.5中的数据。是否应该允许旅行社通过以下 操作来更新视图? UPDatE business trips SET Status=’ private 第6页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 6 页 共 31 页 创建日期：2003-11 接从一张表中读出数据，以及将这些数据拷贝到另一张表中。 14.3.3 通过视图的访问控制 视图是导出关系。SQL 中创建视图的操作格式如下： CREATE VIEW view_name[(column[,column]…)] AS subquery [WITH CHECK OPTION]; 你可以在关系数据库中通过直接对基本关系中的表项授予优先权来实现访问控制。然而，很多安全策略可以更好地 由视图以及这些视图的优先权来表现。在视图中的子查询定义可以描述非常复杂的访问条件。举一个简单的例子， 我们在关系 Diary 中组建一个包括所有公务旅行的视图： CREATE VIEW business_trips AS SELECT * FROM Diary WHERE status=’business’ WITH CHECK OPTION; 通过视图，访问控制可以适当地被放置在应用层。数据库管理系统只提供执行这些控制的工具。视图吸引我们的原 因有以下几点： ⚫ 视图很灵活，并且允许我们在描述层定义访问控制，这样可以更贴近应用的要求。 ⚫ 视图可以实现上下文依赖的和数据依赖的安全策略。 ⚫ 视图可以执行控制调用（controlled invocation）。 ⚫ 安全的视图可以取代安全标识（标签，security labels）。 ⚫ 可以很容易地对数据进行重新分类。 在图 14.4 给出的例子中，面向应用的访问控制可以通过视图表示如下， CREATE VIEW High_Flyers AS SELECT * FROM Students WHERE Grade > (SELECT Grade FROM Students WHERE Name=current_user()); 结果只显示那些平均成绩比正在使用该视图的学生成绩高的学生，或者： CREATE VIEW My_Journeys AS SELECT * FROM Diary WHERE Customer=current_user(); 只显示在图 14.3 中由正在使用此视图的旅客预订的那些旅行线路。可以通过在数据库中添加访问控制表来实现自 主访问控制。这儿的视图指的就是此关系。通过这种方式，你可以实现基于组成员关系的访问控制，也可以通过策 略来调整用户的权限使其和颁发和撤销访问权限一样。 图 14.4 关系 Student 进一步说，视图可以定义为或指的就是安全标识。在我们的例子中，可以通过创建视图把到 Thule 的商业航班 标记为机密的： CREATE VIEW Flights_≥CONFIDENTIAL AS SELECT * FROM Diary WHERE Destination=’THU’ AND Status=´business´; 通过视图来控制读取访问时，除了正确地获取安全政策外，便不会再有其他技术上的特殊困难了。当视图使用插入 （INSERT）或更新（UPDATE）操作对数据库进行写入时，情况就不同了。首先，存在一些不能更新的视图，因为它 们不包含这样的信息，这些信息对于维护相应的基本关系的完整性是必需的。例如，一个不包含基本关系的主关键 字的视图是不能被更新的。其次，即使一个视图是可更新的，仍会有一些有趣的安全问题在里面。一个可以访问 Diary 数据库的旅行社只能通过 business_trips 视图查看到列在表 14.5 中的数据。是否应该允许旅行社通过以下 操作来更新视图? UPDATE business_trips SET Status=’private’
m正Em=1大全一 如果允许的话,那么 Alice的记录就会从视图中消失。事实上,在这种情况下是不允许修改的,因为视图的定义已 经指定了检查( CHECK)选项。如果一个视图的定义包含了 WITH CHECK OPTION,那么更新( UPDATE)和插入( INSERT) 操作只能对数据库写入那些符合视图定义的表项。如果检査( CHECK)选项被忽略了,就可能出现盲写(blid writes) 在S哑L安全模型中,视图不仅是一个对象,同时还被看成是一个程序。当使用视图所有者的优先权,而不是用 调用该视图的用户的优先权来计算该视图时,那么你会找到另一种实现控制调用的方法。 图145视图(vew)示例 视图的访问条件必须在SL的限定范围内加以说明。如果这种做法过于严格,那么用更易读的语言编写的软件 包(存储的过程)就是数据库管理系统为控制数据库的访问而提供的另一选择。同样,用户被授予执行软件包的权 利(特权, privilege),而软件包运行时具有其所有者的权限 计算机系统的任何一层都有控制调用。它在微处理器系统和数据库管理系统中同样有用。258页 迄今为止,我们阐述了如何使视图作为一个有效的安全机制的各方面的问题。很自然,视图也有它自身的缺点: 访问检查会变得相当复杂,而且很慢 视图定义要求必须检査“正确性”。它们真的揭示了我们想要的安全策略吗 由于完全性和一致性不是自动实现的,视图之间可能会重叠或是不能描述整个数据库 ●数据库管理系统中的安全相关部分(TCB)会变得很庞大 视图适合于用在“普通的商业”环境中。它们可以根据应用的需要而剪裁而不要求对数据库管理系统做任何更改。 因此视图的定义是数据库结构定义通用方法中的一部分,它最好地满足了商业需求 然而,当要确定谁可以访问单个数据项时,可能就变得困难。因此,视图不适合这种情况,即当认为保护数据 项比控制用户的操作更有必要时。在第15章中,我们将会把数据库的安全集中在保护数据项上 144统计数据库的安全性 本书迄今为止还未考虑统计数据库中出现的安全问题。统计数据库一个最显著的特点是信息可以经由一张表中 某个属性(列)的统计(聚集)查询重新获得。在SQL中的聚集函数有: COUNT 列中值的个数 SUM 列中值的求和, 列中值的平均 一列中的最大值, MIN 列中的最小值。 统计查询的査询谓词( query predicate)专指那些将被用于聚集计算的元组,査询集合( query set)是指和査询 谓词匹配的元组。在内核中,统计数据库提出以下的安全问题 数据库包含的数据通常是敏感的,因此不允许直接对数据项进行访问。 对数据库的统计査询是允许的,正由于统计查询自身的特点,这些查询读取单个数据项。 在这种情况下,推断信息( infer information)就成为可能,我们还将说明单个地管理访问请求将不再有效。我 们也会采用更加实用的信息流的观点讨论问题。第4章中的机密性模型对无论什么样的信息流都尽力阻止。在统计 数据库中,必须有一些信息流从数据流向它们的聚集。我们只能尽量把这种情况减小到一个可以接受的水平。 图14.4中的 Students数据库将为这节提供例子。我们允许对所有属性的统计查询,除了在 Units和 Grade ave 中的单个表项。列不能被直接读取。下面的统计查询是计算所有MBA学生的平均成绩: Q1: SELECT AVG (Grade Ave) FROM Students WHERE Programme=’MBA 第7页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 7 页 共 31 页 创建日期：2003-11 WHERE Name=’Alice’ AND Day=’Thu’ 如果允许的话，那么 Alice 的记录就会从视图中消失。事实上，在这种情况下是不允许修改的，因为视图的定义已 经指定了检查（CHECK）选项。如果一个视图的定义包含了 WITH CHECK OPTION，那么更新（UPDATE）和插入（INSERT） 操作只能对数据库写入那些符合视图定义的表项。如果检查（CHECK）选项被忽略了，就可能出现盲写（blind writes）。 在 SQL 安全模型中，视图不仅是一个对象，同时还被看成是一个程序。当使用视图所有者的优先权，而不是用 调用该视图的用户的优先权来计算该视图时，那么你会找到另一种实现控制调用的方法。 图 14.5 视图（View）示例 视图的访问条件必须在 SQL 的限定范围内加以说明。如果这种做法过于严格，那么用更易读的语言编写的软件 包（存储的过程）就是数据库管理系统为控制数据库的访问而提供的另一选择。同样，用户被授予执行软件包的权 利（特权，privilege），而软件包运行时具有其所有者的权限。 计算机系统的任何一层都有控制调用。它在微处理器系统和数据库管理系统中同样有用。 258 页 迄今为止，我们阐述了如何使视图作为一个有效的安全机制的各方面的问题。很自然，视图也有它自身的缺点： ⚫ 访问检查会变得相当复杂，而且很慢。 ⚫ 视图定义要求必须检查“正确性”。它们真的揭示了我们想要的安全策略吗？ ⚫ 由于完全性和一致性不是自动实现的，视图之间可能会重叠或是不能描述整个数据库。 ⚫ 数据库管理系统中的安全相关部分（TCB）会变得很庞大。 视图适合于用在“普通的商业”环境中。它们可以根据应用的需要而剪裁而不要求对数据库管理系统做任何更改。 因此视图的定义是数据库结构定义通用方法中的一部分，它最好地满足了商业需求。 然而，当要确定谁可以访问单个数据项时，可能就变得困难。因此，视图不适合这种情况，即当认为保护数据 项比控制用户的操作更有必要时。在第 15 章中，我们将会把数据库的安全集中在保护数据项上。 14.4 统计数据库的安全性 本书迄今为止还未考虑统计数据库中出现的安全问题。统计数据库一个最显著的特点是信息可以经由一张表中 某个属性（列）的统计（聚集）查询重新获得。在 SQL 中的聚集函数有： COUNT： 一列中值的个数， SUM： 一列中值的求和， AVG： 一列中值的平均， MAX： 一列中的最大值， MIN： 一列中的最小值。 统计查询的查询谓词（query predicate）专指那些将被用于聚集计算的元组，查询集合（query set）是指和查询 谓词匹配的元组。在内核中，统计数据库提出以下的安全问题： ⚫ 数据库包含的数据通常是敏感的，因此不允许直接对数据项进行访问。 ⚫ 对数据库的统计查询是允许的，正由于统计查询自身的特点，这些查询读取单个数据项。 在这种情况下，推断信息（infer information）就成为可能，我们还将说明单个地管理访问请求将不再有效。我 们也会采用更加实用的信息流的观点讨论问题。第 4 章中的机密性模型对无论什么样的信息流都尽力阻止。在统计 数据库中，必须有一些信息流从数据流向它们的聚集。我们只能尽量把这种情况减小到一个可以接受的水平。 图 14.4 中的 Students 数据库将为这节提供例子。我们允许对所有属性的统计查询，除了在 Units 和 Grade Ave 中的单个表项。列不能被直接读取。下面的统计查询是计算所有 MBA 学生的平均成绩： Q1: SELECT AVG(Grade Ave.) FROM Students WHERE Programme=’MBA’
翻译:中国科学技术大学信息安全专业老师 在这个例子中,查询谓词是: Programme=’MBA 14.4.1聚集和推断 统计数据库安全的两个重要概念是聚集和推断。聚集( Aggregation)提出一个观察结果,即对数据库中一组 值计算结果的聚集的敏感度,可能和单个元素的敏感度不同。你通常会遇到这种情况,聚集的敏感度低于单个元素 的敏感度。当聚集作是从敏感度低的商业数据的收集中推导出来敏感的可用的信息时,与之相反的情况也会发生。 聚集是数据库中的另一种关系,例如视图。因此,你可以使用在这一章中建议的安全机制来控制对聚集的访问 然而,一个攻击者可以探究不同的敏感度从而获得对更多的敏感项的访问。推断问题( inference problem)是指 从非敏感数据中导出敏感信息。考虑以下的攻击类型 直接攻击:在一个小样本空间里执行聚集计算导致关于单个数据项的信息被泄漏 间接攻击:这种攻击组合和几个聚集操作相关的信息。 跟踪攻击:间接攻击中特别有效的一种类型 线性系统脆弱性攻击:这种方法比跟踪攻击更进一步,利用查询集合间的代数关系来构造等式,以产生所 想要的信息 14.4.2跟踪攻击 我们现在来说明如何利用统计查询从图14.4给出的学生关系的例子中来得到敏感信息。假设我们知道 Carol 是计算机科学系的女生。通过组合下面的两个合法查询: SELECT COUNT(*) FROM Students HERE Sex=’F’ AND Programme=’CS SELECT AVG (Grade Ave FROM Students WHERE Sex= AND Programme=’CS 我们从Q1中知道,在数据库中计算机科学系只有一名女生,因此从Q2返回的值70就肯定是该女生的平均成绩 这里的问题是选取标准允许一个集合可以只包含一个元素。所以,仅当统计查询覆盖了一个足够大的子集时,它才 被允许执行。然而,我们可以忽略选取标准而简单地査询它的补集,可以像刚才一样从对整个数据库的查询结果和 对我们真正感兴趣的集合的补集查询的结果之间的不同中,得到同样的结果。因此,你不仅要求查询所需的元组集 合要足够大,而且它的补集也要足够大。 不幸的是,即使这样也不够好。假设每个查询集合和它的补集都必须至少包含三个元素。下列4个查询依次返 回的值为:Q3:4,Q4:3,Q5:61,Q6:58 SELECT COUNT(*) FROM Students WHERE Programme=’CS Q4: SELECT COUNT (=* FROM Students WHERE Programme=’CS’ AND Sex=’M Q5: SELECT AVG (Grade Ave FROM Students WHERE Programme=’CS Q6: SELECT AVG(Grade Ave FROM Students WHERE Programme=’CS’ AND Sex=’M 所有操作都是在一个足够大的元组集合里考虑的,因此这些操作是允许的。然而,通过组合上面的四个结果,我们 能够计算出 Carol的平均成绩是:4*61-3*58=70。 也许你会觉得我们在这个例子中是侥幸的,而且只能创建这样的查询集合,因为 Carol是计算机科学系中唯 的女生。现在我们将向读者说明,如何用一种系统的方法组织一次攻击。首先,我们需要一个跟踪者 定义一个允许对单个元组追踪信息的查询谓词T被称为对那个元组的单个追踪者( individual tracker)。 第8页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 8 页 共 31 页 创建日期：2003-11 在这个例子中，查询谓词是：Programme=’MBA’。 14.4.1 聚集和推断 统计数据库安全的两个重要概念是聚集和推断。聚集（Aggregation）提出一个观察结果，即对数据库中一组 值计算结果的聚集的敏感度，可能和单个元素的敏感度不同。你通常会遇到这种情况，聚集的敏感度低于单个元素 的敏感度。当聚集作是从敏感度低的商业数据的收集中推导出来敏感的可用的信息时，与之相反的情况也会发生。 聚集是数据库中的另一种关系，例如视图。因此，你可以使用在这一章中建议的安全机制来控制对聚集的访问。 然而，一个攻击者可以探究不同的敏感度从而获得对更多的敏感项的访问。推断问题（inference problem）是指 从非敏感数据中导出敏感信息。考虑以下的攻击类型： ⚫ 直接攻击：在一个小样本空间里执行聚集计算导致关于单个数据项的信息被泄漏。 ⚫ 间接攻击：这种攻击组合和几个聚集操作相关的信息。 ⚫ 跟踪攻击：间接攻击中特别有效的一种类型。 ⚫ 线性系统脆弱性攻击：这种方法比跟踪攻击更进一步，利用查询集合间的代数关系来构造等式，以产生所 想要的信息。 14.4.2 跟踪攻击 我们现在来说明如何利用统计查询从图 14.4 给出的学生关系的例子中来得到敏感信息。假设我们知道 Carol 是计算机科学系的女生。通过组合下面的两个合法查询： Q1: SELECT COUNT(*) FROM Students WHERE Sex=’F’ AND Programme=’CS’ Q2: SELECT AVG(Grade Ave.) FROM Students WHERE Sex=’F’ AND Programme=’CS’ 我们从 Q1 中知道，在数据库中计算机科学系只有一名女生，因此从 Q2 返回的值 70 就肯定是该女生的平均成绩。 这里的问题是选取标准允许一个集合可以只包含一个元素。所以，仅当统计查询覆盖了一个足够大的子集时，它才 被允许执行。然而，我们可以忽略选取标准而简单地查询它的补集，可以像刚才一样从对整个数据库的查询结果和 对我们真正感兴趣的集合的补集查询的结果之间的不同中，得到同样的结果。因此，你不仅要求查询所需的元组集 合要足够大，而且它的补集也要足够大。 不幸的是，即使这样也不够好。假设每个查询集合和它的补集都必须至少包含三个元素。下列 4 个查询依次返 回的值为：Q3:4,Q4:3,Q5:61,Q6:58。 Q3: SELECT COUNT(*) FROM Students WHERE Programme=’CS’ Q4: SELECT COUNT(*) FROM Students WHERE Programme=’CS’ AND Sex=’M’ Q5: SELECT AVG(Grade Ave.) FROM Students WHERE Programme=’CS’ Q6: SELECT AVG(Grade Ave.) FROM Students WHERE Programme=’CS’ AND Sex=’M’ 所有操作都是在一个足够大的元组集合里考虑的，因此这些操作是允许的。然而，通过组合上面的四个结果，我们 能够计算出 Carol 的平均成绩是：4*61-3*58=70。 也许你会觉得我们在这个例子中是侥幸的，而且只能创建这样的查询集合，因为 Carol 是计算机科学系中唯一 的女生。现在我们将向读者说明，如何用一种系统的方法组织一次攻击。首先，我们需要一个跟踪者。 定义 一个允许对单个元组追踪信息的查询谓词 T 被称为对那个元组的单个追踪者（individual tracker）
翻译:中国科学技术大学信息安全专业老师 一个通用追踪者( general tracker)是指一个谓词,它可以使用任何不允许的查询来找到答案 假设T是一个通用追踪者而R是一个谓词,它唯一标识了我们想要获取的元组r。在我们的例子中,这个谓词 是Name=‘ Carol’。我们使用谓词R∨T和R∨NOT(T)对数据库做两条查询。我们的目标r是这两条查询都使用的 唯一元组。为保证这两条査询都是被允许的,我们选择T以便查询集合和它的补集都足够大,这样查询操作才被允 许。对整个数据库的最后一个查询给我们所有的数据来完成攻击。在我们的例子中: Sex=’F’ AND Programme=’CS 是一个对 Carol的个体追踪者,而 Programme=’MIS’是很多通用追踪者中之一。我们继续以下查询 Q7: SELECT SUM(Units) FROM Students WHERE Name=’ Carol’ OR Programme=’MIS Q8: SELECT SUM (Units) FROM Students WHERE Name=’ Carol’ OR NOT( Programme=’MIS Q9: SELECT SUM(Units) OM Students 并得到Q7:75,Q8:77,以及Q9:136。因此 Carol一定已经取得了(75+77)-136=16个学分。经验表明:几乎所有的 统计数据库都有一个通用追踪者。 14.4.3对策 关于统计推断攻击的分析已经在早期的关于数据库安全的文献里介绍了很多。其后,研究者们把他们的注意力 转移到其他领域,并不是因为已经找到并且实现了完全安全的解决方法,而是因为他们不得不承认在防止推断攻击 的对策上他们是心有余而力不足。由于这些局限,你还能对推断问题实际做点什么呢 首先,你很明显地应该保护好( suppress,镇压,抑制,查禁,使止住,不让人知道,隐匿抑制,忍住;隐瞒 (证据等),不容许存在)敏感信息。这意味着你知道哪些信息是敏感的,哪些是最可能被攻击的,以及这些信息可 以怎样被导出。至少,你应该在给出一个统计查询的结果前先检查该查询集合的大小 其次,你可以伪装数据。你可以随机交换数据库中的表项,这样尽管对于统计査询仍然是对的,但单个査询却 会给出错误的结果。还有另一种方法,你可以在査询结果中随机的加入少量的干扰数据,这样返回值就接近于真实 值但不完全相等。这些技术的一个缺点是,它们与准确性和可用性相冲突。你可不想在医学数据库中随机交换数据 通过对设计数据库机制( schema,模式)的选取,可以减少一些聚集问题(参见文献[90])。对数据库结构的 静态分析( static analysis)可以发现属性间的敏感关系。然后将那样的属性分别放在不同的表中。只能访问一 个表的用户不能再将这些属性联系起来。当然,一个可以对所有相关的表进行访问的用户仍然可以得到相关信息 但作为数据库管理员,在分配优先权时可以更准确,以避免出现上述情况。在我们的例子中,名字和学习成绩之间 的关系是敏感的。我们把表 Students分成两个表,如图14.6所示,由学生的ID( identity number)连接 现在将第一个表的安全级设置得足够高,因而只有那些被授权的用户才能把名字和学习成绩联系起来。 最后,可以看到,单个查询并不会引起太多的推断问题,而对几个查询的巧妙组合可能会引起问题。因而你需 要追踪用户所知道的内容,或许这可以提供最好的安全性,但这也是最昂贵的选择。你可以在一个审计日志里记录 用户的行为,如果检测到一个可疑的査询序列时,你执行查询分析( query analysis)来进行干预。当然,你首先 得知道哪些査询会形成可疑的查询序列。要得到更好的保护措施,你的查询分析还将必须考虑两个用户,或一组用 户他们同时知道些什么。 图14.6对学生数据的分离的表 14.5结合操作系统的完整性 当你从操作系统的角度去看数据库时,你会看见大量的拥有数据表项的操作系统进程和内存资源。从很多方面 第9页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 9 页 共 31 页 创建日期：2003-11 一个通用追踪者（general tracker）是指一个谓词，它可以使用任何不允许的查询来找到答案。 假设 T 是一个通用追踪者而 R 是一个谓词，它唯一标识了我们想要获取的元组 r。在我们的例子中，这个谓词 是 Name=‘Carol’。我们使用谓词 R∨T 和 R∨NOT(T)对数据库做两条查询。我们的目标 r 是这两条查询都使用的 唯一元组。为保证这两条查询都是被允许的，我们选择 T 以便查询集合和它的补集都足够大，这样查询操作才被允 许。对整个数据库的最后一个查询给我们所有的数据来完成攻击。在我们的例子中： Sex=’F’ AND Programme=’CS’ 是一个对 Carol 的个体追踪者，而 Programme=’MIS’是很多通用追踪者中之一。我们继续以下查询： Q7: SELECT SUM(Units) FROM Students WHERE Name=’Carol’ OR Programme=’MIS’ Q8: SELECT SUM(Units) FROM Students WHERE Name=’Carol’ OR NOT (Programme=’MIS’) Q9: SELECT SUM(Units) FROM Students 并得到 Q7:75,Q8:77,以及 Q9:136。因此 Carol 一定已经取得了（75+77）-136=16 个学分。经验表明：几乎所有的 统计数据库都有一个通用追踪者。 14.4.3 对策 关于统计推断攻击的分析已经在早期的关于数据库安全的文献里介绍了很多。其后，研究者们把他们的注意力 转移到其他领域，并不是因为已经找到并且实现了完全安全的解决方法，而是因为他们不得不承认在防止推断攻击 的对策上他们是心有余而力不足。由于这些局限，你还能对推断问题实际做点什么呢？ 首先，你很明显地应该保护好（suppress，镇压, 抑制, 查禁, 使止住，不让人知道，隐匿抑制, 忍住; 隐瞒 (证据等)，不容许存在）敏感信息。这意味着你知道哪些信息是敏感的，哪些是最可能被攻击的，以及这些信息可 以怎样被导出。至少，你应该在给出一个统计查询的结果前先检查该查询集合的大小。 其次，你可以伪装数据。你可以随机交换数据库中的表项，这样尽管对于统计查询仍然是对的，但单个查询却 会给出错误的结果。还有另一种方法，你可以在查询结果中随机的加入少量的干扰数据，这样返回值就接近于真实 值但不完全相等。这些技术的一个缺点是，它们与准确性和可用性相冲突。你可不想在医学数据库中随机交换数据！ 通过对设计数据库机制（schema，模式）的选取，可以减少一些聚集问题（参见文献[90]）。对数据库结构的 静态分析（static analysis）可以发现属性间的敏感关系。然后将那样的属性分别放在不同的表中。只能访问一 个表的用户不能再将这些属性联系起来。当然，一个可以对所有相关的表进行访问的用户仍然可以得到相关信息， 但作为数据库管理员，在分配优先权时可以更准确，以避免出现上述情况。在我们的例子中，名字和学习成绩之间 的关系是敏感的。我们把表 Students 分成两个表，如图 14.6 所示，由学生的 ID（identity number）连接。 现在将第一个表的安全级设置得足够高，因而只有那些被授权的用户才能把名字和学习成绩联系起来。 最后，可以看到，单个查询并不会引起太多的推断问题，而对几个查询的巧妙组合可能会引起问题。因而你需 要追踪用户所知道的内容，或许这可以提供最好的安全性，但这也是最昂贵的选择。你可以在一个审计日志里记录 用户的行为，如果检测到一个可疑的查询序列时，你执行查询分析（query analysis）来进行干预。当然，你首先 得知道哪些查询会形成可疑的查询序列。要得到更好的保护措施，你的查询分析还将必须考虑两个用户，或一组用 户他们同时知道些什么。 图 14.6 对学生数据的分离的表 14.5 结合操作系统的完整性 当你从操作系统的角度去看数据库时，你会看见大量的拥有数据表项的操作系统进程和内存资源。从很多方面
翻译:中国科学技术大学信息安全专业老师 看,数据库管理系统和操作系统有很多相似的职责。其中之一就是防止用户间的相互干扰以及用户和数据库管理系 统间的干扰。 如果你不想浪费精力,就应该把这些任务交给操作系统。在这种方式里,DBMS作为操作系统进程的一个集合 (的一组进程)运行。这里有通用的数据库管理任务系统进程,而每个数据库用户被映射为单独的操作系统进程(见 图14.7)。现在,操作系统可以区分不同的用户,如果用户要在它自己的文件里存储每一个数据库对象,那么操作 系统可以执行所有的访问控制。DBMS只需要把用户的査询翻译成操作系统能够理解的操作。 给每个数据库用户分配一个单独的操作系统进程既浪费内存资源也不能满足众多用户的需求。因此,你需要这 样的操作系统进程,它可以处理多个用户的数据库请求(见图14.8)。你节约了内存,但访问控制的责任现在却落 在了DBMS上。数据库对象的存贮也有同样的问题。如果对象很小,那么给每个对象分配一个单独的文件很浪费。 旦操作系统失去了对数据库用户的访问控制功能,你就可以自由地在一个操作系统文件中收集一些数据库对象的 资料 图14.7由操作系统隔离数据库用户 进一步的阅读 如果读者需要复习关系数据库模型,则可以参考文献[37]。关于数据库安全方面的很多实践材料都收集在文献 [25]中。文献[39]是一本较早关于数据库安全方面的书,但它仍然很有用。它在统计数据库安全方面有很好的参考 价值。关于统计数据库安全方面更有用的一本书是文献[90]。 所有主要的数据库方面的销售商都有主页,在其主页上有关于它们产品的信息和对数据库安全很好的介绍。通 过了C2评定的数据库销售商的主页如下: http://www.informix.com http://www.sybasecom 图148由DBMS隔离数据库用户 练习题 练习14.1假设有个账户数据库,有记录(用户名,账号,余额,信用度)和使用者(用户,职员,管理者)。定 义一个访问结构,例如通过视图,实现 用户可以读取他们自己的账户 职员可以读取除了信用度以外的所有属性,还可以修改所有账户的余额, 管理者可以创建一个新纪录,读取所有属性,以及为所有账户更新信用度 练习14.2考虑一个有学生纪录的数据库,它包含学生的姓名以及所有课程的成绩。通过视图可以看到所有学生还 有谁的课程论文没有成绩。这个视图可以定义为 WITH CHECK OPTION吗?对决定是否使用 CHECK OPTION的通用标 准给出你的建议 练习14.3在 Students关系(见图14.4)上的所有统计查询,其查询集合至少要有三个元组,只有对属性 Grade ave 的AVG查询例外。找出一个新的通用追踪者并对 Homer的平均成绩构造一次追踪攻击 练习14.4在数据库安全问题里,你已经见到了对应用层安全控制的例子。这种方法有什么问题? 练习14.5考虑这样一个数据库,聚集操作被放在了比导出的数据项更高的敏感级别上。一个有权访问数据项的用 户,它会潜在地通过单独对数据项的访问来计算聚集函数。你怎样防止这类攻击 练习14.6给你一个数据库,可以对表中的每一行单独定义访问权限。访问控制将使用和操作系统一样的安全机制 如果数据库对象存储在操作系统文件中,这种设计会有什么样的后果?(作为准绳,考虑一个为每个文件使用100 字节的管理数据的操作系统,和有一千万个纪录的数据库。)这是一个可行的设计方案吗? 第15章多级安全数据库 在本章中,我们将把注意力全部放在数据库目录( entries)的控制上。多级安全政策控制了对数据库的访问 第10页共31页创建日期:2003-11
翻译：中国科学技术大学信息安全专业老师 第 10 页 共 31 页 创建日期：2003-11 看，数据库管理系统和操作系统有很多相似的职责。其中之一就是防止用户间的相互干扰以及用户和数据库管理系 统间的干扰。 如果你不想浪费精力，就应该把这些任务交给操作系统。在这种方式里，DBMS 作为操作系统进程的一个集合 （的一组进程）运行。这里有通用的数据库管理任务系统进程，而每个数据库用户被映射为单独的操作系统进程（见 图 14.7）。现在，操作系统可以区分不同的用户，如果用户要在它自己的文件里存储每一个数据库对象，那么操作 系统可以执行所有的访问控制。DBMS 只需要把用户的查询翻译成操作系统能够理解的操作。 给每个数据库用户分配一个单独的操作系统进程既浪费内存资源也不能满足众多用户的需求。因此，你需要这 样的操作系统进程，它可以处理多个用户的数据库请求（见图 14.8）。你节约了内存，但访问控制的责任现在却落 在了 DBMS 上。数据库对象的存贮也有同样的问题。如果对象很小，那么给每个对象分配一个单独的文件很浪费。 一旦操作系统失去了对数据库用户的访问控制功能，你就可以自由地在一个操作系统文件中收集一些数据库对象的 资料。 图 14.7 由操作系统隔离数据库用户 进一步的阅读 如果读者需要复习关系数据库模型，则可以参考文献[37]。关于数据库安全方面的很多实践材料都收集在文献 [25]中。文献[39]是一本较早关于数据库安全方面的书，但它仍然很有用。它在统计数据库安全方面有很好的参考 价值。关于统计数据库安全方面更有用的一本书是文献[90]。 所有主要的数据库方面的销售商都有主页，在其主页上有关于它们产品的信息和对数据库安全很好的介绍。通 过了 C2 评定的数据库销售商的主页如下： http://www.informix.com http://www.oracle.com http://www.sybase.com 图 14.8 由 DBMS 隔离数据库用户 练习题 练习 14.1 假设有个账户数据库，有记录（用户名，账号，余额，信用度）和使用者（用户，职员，管理者）。定 义一个访问结构，例如通过视图，实现： ⚫ 用户可以读取他们自己的账户， ⚫ 职员可以读取除了信用度以外的所有属性，还可以修改所有账户的余额， ⚫ 管理者可以创建一个新纪录，读取所有属性，以及为所有账户更新信用度。 练习 14.2 考虑一个有学生纪录的数据库，它包含学生的姓名以及所有课程的成绩。通过视图可以看到所有学生还 有谁的课程论文没有成绩。这个视图可以定义为 WITH CHECK OPTION 吗？对决定是否使用 CHECK OPTION 的通用标 准给出你的建议。 练习 14.3 在 Students 关系(见图 14.4)上的所有统计查询，其查询集合至少要有三个元组，只有对属性 Grade Ave. 的 AVG 查询例外。找出一个新的通用追踪者并对 Homer 的平均成绩构造一次追踪攻击。 练习 14.4 在数据库安全问题里，你已经见到了对应用层安全控制的例子。这种方法有什么问题？ 练习 14.5 考虑这样一个数据库，聚集操作被放在了比导出的数据项更高的敏感级别上。一个有权访问数据项的用 户，它会潜在地通过单独对数据项的访问来计算聚集函数。你怎样防止这类攻击？ 练习 14.6 给你一个数据库，可以对表中的每一行单独定义访问权限。访问控制将使用和操作系统一样的安全机制。 如果数据库对象存储在操作系统文件中，这种设计会有什么样的后果？（作为准绳，考虑一个为每个文件使用 100 字节的管理数据的操作系统，和有一千万个纪录的数据库。）这是一个可行的设计方案吗？ 第 15 章 多级安全数据库 在本章中，我们将把注意力全部放在数据库目录（entries）的控制上。多级安全政策控制了对数据库的访问