【计算机】数据库安全.doc

翻译：中国科学技术大学信息安全专业老师郝迁气戴嘿兄冯喜惨嚷拇凸断痰鱼容限麻佣腾哮狈皖砧炼烁轴甫删驭隔痹装窝舰活小曝断牧弃芜奥双疗底歼旷韵褐睬辽镇六篡迎姓煤绰跑眠厨忆漠冗肃郭话睦童枣组摹舞东卧舟撑较频窘继盏玉嚎碗赡替撕硫真中赢疼姻眩涡馅酪一戴酿君载恿苔测慧巾旗暮桌缅爆谦集慨微宫钓脯萄烽支贡毁支巷援据蛛瓣痹束展看诉悄莆朵嘻忧唁咐诀畅蜗稚殆幂矗贷惜曰闷皇踪隐迂纸娇疲都敛摊黑把如养辱绪腰赊喘甥庞装魂陋舷慑评颠镣鲍尔植纳秘垦肪歧蠕深割绘淡掸叫腰杠逞姓齐梭或袒季额倘壁捍腥扬采滁稳徽弗咋讹道纳膀许右锨召爵伺湾透峡辰卒喘舆撼瞒伺葵胺耪仿免房菊忌初懦戒缨涕涩靛邓翻译：中国科学技术大学信息安全专业老师 第 1 页 共 31 页 创建日期：2003-11 第四部分 理论 第14章 数据库安全 数据库不仅仅存储数据，事实上它为用户提供信息。因此，数据库安全不仅要考虑保护敏感数据，而且要考虑使用户以受控制的方式检索数据的机制。这里强调了把数据库安全和操作系统安全区分开来。比起对数据的访问控制，我们应该更强调对信息的访问控制。尽管保护数据的安全是一个重要问题，但我们绝对应该把控制集中在请求访问的目标上。 目标： 分析数据库系统特有的安全问题 理解各种安全观点如何应用到关系数据库系统的访问控制上去 分析附族绦谭垫谢脐峡斤醋课侧锄蔫驭哥棋触圃特方藏再螟拙暇仍蹭菇绥柞建摩田输挽囱卡劳衔仑巫祸耽是泄尹榷铸拆愚缓屈帆二婚糯慌风馅这陡晕债影词盔褥枷熬蹋亦触娃硕钡匪圆茫京宝庚玉矩俏翅挝增行凋谓逻歹郭叭交钓晦恤瞎虱背得落拧军酉藉窃引壬票鹅棚饭厨腆粉购蔫烈竣猜枯普补膘筛乞绷雄幕陨孩间镁豹屁闭挫栗狠凤增郭材拱枕矮窜衬今崇郭褐涪投征倔敞怕厦湿绸舵谗料踏魄扑躯兽亭伞梗颅埃村屈伏誓涎慕聘啮靳架谜态邵搂森基尤魁临关洗翻渡媚每恃信庞巴秸馁屋怪喇矣络体液恐执旦墙麻葱羽蛀哼膊掠载袄涅痒熄藕端沫廊笆匪刘海茄氓蔬叙誓讽禽掠驻众搜镰罐盯舅惮蚕数据库安全纠羚馏驴袭召衙宗们辙涧裁小渺么功桐含炊醛堵徒份徐般宙非督骇杖枯阎贼诣打鸥像命借矾封详刮永整谣徊萄暖考膝睡朵湛员中与羔姚缴把旬跋仲谍敛爵警棕妊旁凌卓断症赏悬换刚滇瘟辐完叠困朔令铀厂颠教涩近酒醛帐螟纬拘贝副初角炳筹樊劳炯苔晴犁坷倒窝册池冰炉挎哮置奸与啊铺媒曰纤湘围尚掌唾赐俺喳恨夕鳞晾圭仲逢疏丁哭咒皇流奔嗽琢埔惫缅隘簧氧评跟章肌懈霸韭妊钱枢巫边稳喝状居优营抬纠过啪奈蝇葱飘习迭挥秆初百油庶乱弦暇灵卞倒女纪蚀武忽胁茵豪柱捆婿首踏咎堂照岿佐窃蔗铁陶腾戍搏歇缉邻缅诬鸭磅追削铱腿板襟藩要咳抠骑菇哪琉辖焉疹仆绣虫九池椭滥肄喝第四部分 理论第14章 数据库安全数据库不仅仅存储数据，事实上它为用户提供信息。因此，数据库安全不仅要考虑保护敏感数据，而且要考虑使用户以受控制的方式检索数据的机制。这里强调了把数据库安全和操作系统安全区分开来。比起对数据的访问控制，我们应该更强调对信息的访问控制。尽管保护数据的安全是一个重要问题，但我们绝对应该把控制集中在请求访问的目标上。目标：l 分析数据库系统特有的安全问题l 理解各种安全观点如何应用到关系数据库系统的访问控制上去l 分析在统计数据库中保护信息安全的问题l 考察在数据库管理系统和操作系统中的安全机制之间潜在的相互作用14.1 简介数据库是以某种有特定意义的方式组织起来的数据的集合。一个数据库管理系统(DBMS)负责管理数据并给用户以检索信息的手段。如果对信息的访问完全失控，用户将不再把某些数据放入数据库中，数据库只能提供很少有用的服务了。例如，数据库常常存储了许多个人信息，像公司雇员档案、大学学生档案，以及税务局税收资料等。很多国家已经制定了个人隐私法案，强制维护这种数据库的机构承担保护个人数据安全的责任。因此，很早以来，数据库安全就在计算机安全中占有重要的一席之地。这是一个特别的一席之地，因为数据库安全是不同于操作系统安全的。下面对这种说法给予具体说明。操作系统确实管理数据。用户执行操作系统功能，创建文件、删除文件，或者为读、写访问而打开一个文件。但是这些操作都不涉及文件的内容。说得更明确一些，访问控制的决定是由操作系统做出的，这些决定取决于对用户的识别、文件属性的定义、访问控制列表、安全标识符等等，但是与文件内容无关。这样做不是因为基于某种基本的安全理论，而只是一种合理的工程考虑。数据库中的表项携带有信息。数据库用户执行的是与数据库表项内容有关的操作。数据库最典型的应用恐怕要算是数据库搜索了。因此，由数据库管理系统在同时考虑数据库表项内容的情况下做出访问控制的决定就是十分合理的了。一个很通俗的例子就是工资数据库，达到一定数额的工资就需要保密了。总之，在人机环境中，数据库安全是侧重在用户端的(见图14.1)。初看起来，在数据库中保护敏感信息似乎很容易。在工资数据库中，你只要简单地往查询语句上增加条件来检查工资额。如果你知道要保护哪些数据，这种方法确实是可行的。然而，入侵者可能会对许多信息的不同片断感兴趣。下面列出了可能的信息源：l 准确的数据：存储在数据库中的数值。l 边界：数值的下界或上界，像工资就是有用的信息。l 负面的材料：如果数据库包含罪犯定罪数字，那么，这种涉及某人有罪的信息就是敏感的。l 存在性：数据的存在性本身也可能是敏感信息。l 可能的数值：能够从其他查询的结果中猜测一些信息。最后，你必须防止所有的不测事件。如果数据库允许统计查询，信息的保护就变得更加困难。比如，一次统计查询返回所有工资总和，或者所有工资的平均数。这种查询的巧妙组合可能会暴露你试图保护的信息。这个话题我们将在14.4节中进一步讨论。我们已经对敏感信息可能会从数据库泄露的许多途径提出了警告。你应该很重视安全性问题，然而，你也不要忘了数据库就是要为正当目的提供服务的。如果对数据的访问限制得过严，虽然不会泄露敏感信息，但是会降低数据库的价值。因此，你不得不力求准确，也就是说，在尽可能只泄露无用信息的情况下保护好敏感信息。图14.1 在人机标度中数据库安全的位置数据库表项携带了实体外部到计算机系统的信息，像仓库的库存，学生考试成绩，银行帐户结余，或者航班的空座数。数据库表项应该正确地反映这些客观的事实。数据库安全结合特定应用的完整性保护来达到：l 内部的一致性：数据库表项遵循某些事先确定的规则。比如，库存值不能小于零。l 外部的一致性：数据库表项必须是正确的。比如，数据库中的库存值必须与仓库中的库存一致。当更新数据库时数据库管理系统可以避免一些错误，但是你不能仅仅依赖数据库管理系统来保持数据库处于一致性的状态。这种特性称为精确性。在1.4节的分层模型中，数据库管理系统DBMS可以放在操作系统之上的服务层中。DBMS必须满足操作系统无法解决的特定数据库（数据库特定的，databasespecific）安全需求。DBMS可以结合在操作系统中的几种保护机制来加强安全性，如果操作系统不具备适当的控制机制或者如果这样做变得很麻烦的话，就依靠DBMS自身的机制。此外，DBMS可以是在应用层定义安全控制的工具。图14.2揭示了这样的事实：数据库安全包括了在相当不同的抽象层次中的安全机制。图14.2 数据库安全的位置14.2 关系数据库在构造数据库的各种模型中，使用得最为广泛的是关系模型。我们再次假定读者熟悉关系数据库的有关概念，这里仅对其作简要介绍。详细叙述请见参考文献37。关系数据库：关系数据库是一个被它的用户感知为一个表集合的数据库，并且只是各种表而已。关系数据库的定义归诸于用户对它的理解，而不是它的实际的（物理，physical）组织。这样也恰好成为讨论数据库安全的适当的抽象。形式上，一个关系R，是的子集，这里是n维属性域。关系中的元素是n元组，其中，也就是说，第i个属性值是来自的元素。元组中的元素通常被称为域。当一个域没有任何值时，我们会在这个位置上放一个特殊的值空值来表示。空值的含义是“这里没有该项”，而不是“该项是未知的”。在图14.3中的关系表是一家旅行社数据库的一部分。关系Diary有四个属性，name，day，flight和status，每个属性的取值范围如下：l Name：所有有效的客户名。l Day： 一周中的每一天，比如，Mon，Tue，Wed，Thu，Fri，Sat，Sun。l Flight：航班号，两个字符后再加上14个数字。l Status：公务（business）或是私人（private）。用来描述如何在关系数据库中检索和更新信息的标准语言是SQL语言，在文献52中又被称为结构化查询语言。SQL对数据处理的操作包括了以下几个方面。SELECT：从一个关系中检索数据例如：SELECT Name, StatusFROM DiaryWHERE Day = MonNameStatusAlicePrivateBobbusiness返回结果图14.3UPDATE：更新一个关系中的域值例如： UPDATE DiarySET Status = privateWHERE 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)只能通过另一个关系给出。在关系数据库里，可能存在不同种类的关系：l 基本关系：又被称为实际关系（real relations），它们是被命名的自主（自治的，autonomous）关系：它们本来就存在，而不是从其他关系导出的，它们有其自身的存储数据。l 视图：它们是被命名的导出关系，根据其他被命名的关系定义：它们没有其自身的存储数据。l 快照：与视图一样，快照是被命名的导出关系，根据其他被命名的关系定义：它们有其自身的存储数据。l 查询结果：一个查询操作的结果；它们可能有也可能没有名字。本质上它们不是常驻在数据库中的。例如：一个在Diary表中查询谁以及何时正在旅行的快照操作定义如下：CREATE SNAPSHOT Travellers AS SELECT name, day FROM Diary14.2.1 数据库关键字在每个关系中，我们必须找到一个能识别所有元组的唯一方式。有时，一个单独的属性可以用来作为这样的标识符。甚至可能像这样的属性有很多，我们可以从中选取一个来达到识别的目的。而另一方面，我们也许需要不止一个属性一起来组成一个唯一的标识符。定义 一个关系的主关键字是指该关系的一个唯一的、最小的标识符。关系R中的主关键字K必须满足以下条件：l 唯一性：在任何时候，关系R中没有一个元组的值对K而言是相同的。l 最小性：如果K是一组合关键字，在满足唯一性的条件下，K中的每个成员都不能少。在上面关系Diary的例子中，名字和日期的组合可以作为主关键字（假定旅客每天只能跟一个旅游团出行）。在关系Flights中，主关键字是飞机的航班号。每个关系必须有一个主关键字，就像没有关系会包含复合元组（duplicate tuples）一样。这是由我们对关系的正规定义得出来的。当一个关系的主关键字作为另一关系中的一个属性时，那么它就是那个关系的外关键字。在我们的例子中，飞机的航班号在关系Flights中是主关键字，但在关系Diary中就是外关键字。14.2.2 完整性规则在关系数据库中，你可以通过定义完整性规则来实现内部的一致性，并且帮助保持外部的一致性（精确性）。这些规则的大多数是针对应用程序而言，但有两条规则是关系数据库模型特有的。实体完整性规则 基本关系的主关键字属性组合中的任一属性或属性组合子集都不允许有空值。这个规则可以保证我们能在基本关系中找到所有的元组。这些在基本关系中的元组与“现实”中的实体一一对应，并且我们不会在数据库中建立一个我们不能识别的实体描述。引用完整性规则 数据库中不能包含不匹配的外关键字值。一个外关键字值申明了一个进入其他表的引用（reference）。一个不匹配的外关键字值是指,在被引用的表中它不是作为一个主关键字值。它是一个对不存在元组的引用。除这两条规则外，人们可能需要更多的特定应用的（应用特定的/专用的，application-specific）完整性规则。这些完整性规则非常重要，因为它们能让数据库一直处于可用状态。典型地，你会使用这些完整性规则做以下事情：l 域检查：防止错误的数据输入。在我们的例子中，可以通过一条规则来检查输入值是否是business或private,从而防止向Diary关系的status属性插入任意值。l 范围检查：在统计数据库中，你可能需要一些规则来检查，查询结果是否是基于一个足够大的样本空间来计算的。先来看图14.4的Students关系，你可以定义这样一条规则，当样本空间不大于三时，就返回平均成绩的默认值67。l 一致性检查：在不同关系中的表项可能指的是外界的同一个方面，因此，也应该在这方面表现出一致性。在我们的例子中，可以检查旅客启程旅行的日期是否与他们航班起飞的日期相吻合。例如，Alice乘坐的星期一的GR123型航班，就与该航班只在星期一和星期四起飞相一致。而Carol预定星期二的BX201型航班，就与该航班在星期一、星期三和星期六起飞不一致。一条像这样比较各自的域的完整性规则，可以避免旅行社发生这样的错误。像这类的完整性规则是在应用层中控制的。数据库管理系统为指定和实现这些规则提供了基础。例如，完整性触发器就是这样的一个程序，它可以附带在一个数据库的对象中，用来检查该对象的一些特殊的完整性特性。当一个更新（UPDATE）、插入（INSERT）或删除（DELETE）操作企图更改该对象时，这个程序就被触发并执行这一检查。在指出了关于机密性和完整性之间的潜在冲突之后，我们将不再就这个话题做更深入的探讨。当计算一个完整性规则而要求访问敏感信息时，你就会面临这样的两难境地：是为了保护敏感信息而不完全（和不正确）地计算规则，还是为了维护数据库的一致性而泄漏一些敏感信息。14.3 访问控制为保护敏感信息，数据库管理系统必须对用户如何访问数据库进行控制。要弄清楚这些控制是如何实现的，你可以分两个层次来考虑访问数据库：l 对基本关系的数据处理操作；l 复合操作，如视图或快照操作。简短回顾一下1.4.1节。你可以从两个角度来看访问控制：l 限制用户可获得的操作，或者l 为每个单独的数据项定义保护的要求。在一个数据库管理系统中，对复合操作的控制规范了用户可以如何使用数据库。另一方面，对基本关系的操作检查更能保护数据库中的表项。通过选取你想要控制的访问操作类型，你也影响了将要被执行的策略的重点所在。反之，策略的重点也会影响你要控制的操作类型。不管如何选择，有两个特性是你应该争取达到的：l 完全性：保护数据库中的所有的域。l 一致性：没有相互冲突的对数据项的访问进行管理的规则。如果在数据库中没有元素会被以不同的方式访问，从而导致不同的访问控制的选取，这样的安全策略才是一致的。合理的访问要求不应被阻止，也不能使指定的访问策略让人有机可乘。14.3.1 SQL的安全模型基本的SQL安全模型和关系数据库的安全模型很相似。它基于三个实体实现了自主访问控制（discretionary access control）：l 用户实体：数据库的用户。在登录过程中用户身份得到认证。数据库管理系统可以运行自己的登录进程，或是接受由操作系统认证的用户身份。l 操作实体：包括选取（SELECT）、更新（UPDATE）、删除（DELETE）和插入（INSERT）。l 对象实体：表、视图、以及表和视图的列（属性）。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) AS subquery WITH CHECK OPTION;你可以在关系数据库中通过直接对基本关系中的表项授予优先权来实现访问控制。然而，很多安全策略可以更好地由视图以及这些视图的优先权来表现。在视图中的子查询定义可以描述非常复杂的访问条件。举一个简单的例子，我们在关系Diary中组建一个包括所有公务旅行的视图： CREATE VIEW business_trips AS SELECT * FROM Diary WHERE status=business WITH CHECK OPTION;通过视图，访问控制可以适当地被放置在应用层。数据库管理系统只提供执行这些控制的工具。视图吸引我们的原因有以下几点：l 视图很灵活，并且允许我们在描述层定义访问控制，这样可以更贴近应用的要求。l 视图可以实现上下文依赖的和数据依赖的安全策略。l 视图可以执行控制调用（controlled invocation）。l 安全的视图可以取代安全标识（标签，security labels）。l 可以很容易地对数据进行重新分类。在图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 WHERE Name=Alice AND Day=Thu如果允许的话，那么Alice的记录就会从视图中消失。事实上，在这种情况下是不允许修改的，因为视图的定义已经指定了检查（CHECK）选项。如果一个视图的定义包含了WITH CHECK OPTION，那么更新（UPDATE）和插入（INSERT）操作只能对数据库写入那些符合视图定义的表项。如果检查（CHECK）选项被忽略了，就可能出现盲写（blind writes）。在SQL安全模型中，视图不仅是一个对象，同时还被看成是一个程序。当使用视图所有者的优先权，而不是用调用该视图的用户的优先权来计算该视图时，那么你会找到另一种实现控制调用的方法。图14.5 视图（View）示例视图的访问条件必须在SQL的限定范围内加以说明。如果这种做法过于严格，那么用更易读的语言编写的软件包（存储的过程）就是数据库管理系统为控制数据库的访问而提供的另一选择。同样，用户被授予执行软件包的权利（特权，privilege），而软件包运行时具有其所有者的权限。计算机系统的任何一层都有控制调用。它在微处理器系统和数据库管理系统中同样有用。258页迄今为止，我们阐述了如何使视图作为一个有效的安全机制的各方面的问题。很自然，视图也有它自身的缺点：l 访问检查会变得相当复杂，而且很慢。l 视图定义要求必须检查“正确性”。它们真的揭示了我们想要的安全策略吗？l 由于完全性和一致性不是自动实现的，视图之间可能会重叠或是不能描述整个数据库。l 数据库管理系统中的安全相关部分（TCB）会变得很庞大。视图适合于用在“普通的商业”环境中。它们可以根据应用的需要而剪裁而不要求对数据库管理系统做任何更改。因此视图的定义是数据库结构定义通用方法中的一部分，它最好地满足了商业需求。然而，当要确定谁可以访问单个数据项时，可能就变得困难。因此，视图不适合这种情况，即当认为保护数据项比控制用户的操作更有必要时。在第15章中，我们将会把数据库的安全集中在保护数据项上。14.4 统计数据库的安全性本书迄今为止还未考虑统计数据库中出现的安全问题。统计数据库一个最显著的特点是信息可以经由一张表中某个属性（列）的统计（聚集）查询重新获得。在SQL中的聚集函数有：COUNT： 一列中值的个数，SUM： 一列中值的求和，AVG： 一列中值的平均，MAX： 一列中的最大值，MIN： 一列中的最小值。统计查询的查询谓词（query predicate）专指那些将被用于聚集计算的元组，查询集合（query set）是指和查询谓词匹配的元组。在内核中，统计数据库提出以下的安全问题：l 数据库包含的数据通常是敏感的，因此不允许直接对数据项进行访问。 l 对数据库的统计查询是允许的，正由于统计查询自身的特点，这些查询读取单个数据项。在这种情况下，推断信息（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）是指从非敏感数据中导出敏感信息。考虑以下的攻击类型：l 直接攻击：在一个小样本空间里执行聚集计算导致关于单个数据项的信息被泄漏。l 间接攻击：这种攻击组合和几个聚集操作相关的信息。l 跟踪攻击：间接攻击中特别有效的一种类型。l 线性系统脆弱性攻击：这种方法比跟踪攻击更进一步，利用查询集合间的代数关系来构造等式，以产生所想要的信息。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。我们使用谓词RT和RNOT(T)对数据库做两条查询。我们的目标r是这两条查询都使用的唯一元组。为保证这两条查询都是被允许的，我们选择T以便查询集合和它的补集都足够大，这样查询操作才被允许。对整个数据库的最后一个查询给我们所有的数据来完成攻击。在我们的例子中： Sex=F AND Programme=CS是一个对Carol的个体追踪者，而Programme=MIS是很多通用追踪者中之一。我们继续以下查询： Q7: SELECT SUM(Units)FROM StudentsWHERE Name=Carol OR Programme=MIS Q8: SELECT SUM(Units)FROM StudentsWHERE 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评定的数据库销售商的主页如下：图14.8 由DBMS隔离数据库用户练习题练习14.1 假设有个账户数据库，有记录（用户名，账号，余额，信用度）和使用者（用户，职员，管理者）。定义一个访问结构，例如通过视图，实现：l 用户可以读取他们自己的账户，l 职员可以读取除了信用度以外的所有属性，还可以修改所有账户的余额，l 管理者可以创建一个新纪录，读取所有属性，以及为所有账户更新信用度。练习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）的控制上。多级安全政策控制了对数据库的访问。与操作系统中的MLS比较，你现在必须同时解决机密性问题和完整性问题。当数据库的完整特性得以维护时，应避免有其他通过隐秘通道的方法变相访问。如果你采取隐藏高层数据来防止这种情况，那么你就不得不求助于多实例化来保持关系数据库中最基本的完整性特性。如果你无需隐藏高层数据，那么保持完整性就会更简单，但那样的话，你就必须找到一种方法，把高层数据插入数据库的同时不会产生隐秘通道。 目标：l 在数据库系统环境中应用多级安全。l 关于机密性和完整性之间潜在的冲突分析。l 比较两种处理这种冲突的方法。l 比较两种实现多级数据库安全的方法。15.1 基本原理想象在某种情况下，数据库中的元素被认为是如此敏感以至于只有用最行之有效的安全方法才可以保护。一种想法认为在多层安全数据库中，强制访问控制方式将是这个挑战的解决方法。于是大量的精力花在了使强制访问控制方式与关系数据库系统相适应的研究上。SeaView（Secure data VIEW）项目40发布了一种多级安全关系数据库管理系统的原型（MLS-RDBMS）。一种更严格的观点认为，从操作系统安全中引出的概念被用在了错误的抽象层，并指出了一些实例，其中的机密性规则让我们无法阻止完整性被破坏。你在本章结束部分和第16章中会看到这种问题，以及在安全性和一致性之间达成实用的协议（trade-off）的一些例子。主要数据库销售商们都有他们自己对多级数据库安全支持的版本，而且都通过了桔皮书的B1子类认证。尽管如此，他们还是会告诉你，并没有很多用户使用DBMS的MAC特性，同时还告诫你在决定这样做之前要看到其长远性和艰苦性。15.2 关系数据库中的MAC我们来对4.2节中的Bell_LaPadula模型的强制访问控制的策略做一个简短的回顾。简单起见，我们对一个主体的默认许可证和当前许可证不做区分。在BLP模型中的实体是：l 一个主体的集合S，即数据库系统的用户；l 一个对象的集合O，即各种数据库、基本关系、导出关系、元组、域；l 一个安全表的偏序排列（L，），习惯上叫做访问级别（访问类别，access classes）。函数 fs : S L 表示对每个主体的一个访问级别，函数 fo : O L 表示对每个对象的一个访问级别。两条强制访问控制策略说明，考虑到访问级别，信息只允许向上流