中国科学技术大学：《计算机安全》课程教学资源（教案讲义）第十四章 数据库安全

翻译:中国科学技术大学信息安全专业老师 第四部分理论 第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），而撤销时所需要的信息被保存在数据库中。 你还应该注意到，一旦其他用户被授权访问数据，这些数据的所有者就再无法控制从这些数据导出的信息将会 如何被使用，即使所有者对原始数据仍有一定的控制。你不再需要任何对访问原始表的“写”命令要求，而可以直