翻译:中国科学技术大学信息安全专业老师 接从一张表中读出数据,以及将这些数据拷贝到另一张表中 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）的控制上。多级安全政策控制了对数据库的访问