专利名称：对关系数据库进行访问控制的方法
技术领域：
本发明涉及信息处理系统，具体来说，涉及在数据库管理系统中提供访问控制。
背景技术：
随着万维网(“web”)和电子商务解决方案的发展，数据库安全性和保密性变得越来越重要。在服务器上托管Web站点，被称为Web托管，是扩大数据库安全性的重要性的另一个趋势。Web服务器包括在许多相关表中存储了客户的数据的关系数据库。Web托管公司被推动将来自许多客户的数据存储在单数据库管理系统中，以便最大限度地减小其费用。然而，随着客户的数量越来越多，需要的安全性比通常由托管公司使用的数据库管理系统的安全性更高，特别是当使用数据库管理系统来托管一个以上的客户的Web站点和数据时。
某些客户需要实现强制性访问控制，其中，对诸如数据库行之类的数据项的所有访问都要受到控制。许多客户还需要使用层次型的安全性方案，该方案同时支持多个级别的访问控制。这些强制性访问控制和层次型安全性方案已为大家所熟知。在国防部标准DoD5200.28-STD，1985年12月发表的Department of Defense TrustedComputer System Evaluation Criteria中对它们进行了描述，在此进行了全文引用作为参考。
诸如授予汤姆逊等人的美国专利No.5,751,949中所描述的数据库之类的常规关系数据库提供了基于表和那些表的视图的安全性。可以使用视图来限制对一个或多个数据库表内的所选择的行和列的访问。例如，在汤姆逊等人的专利中，使用视图来将数据表与包含用户授权信息的安全性表联接起来。然而，诸如系统管理员之类的某些用户可以绕过视图并直接对表进行访问，从而绕过了由视图提供的访问控制。此外，数据库管理员和应用程序设计员建立具有所希望的级别的粒度的视图常常是比较麻烦的。虽然视图对于只读访问比较有效，但是，对于更新、插入和删除，视图定义起来就比较困难。对于更新控制，常常需要触发器、数据库限制和存储过程。
虽然许多应用需要关系数据库内的行级别的安全性，以便单个的用户访问可以被限制于特定的行集，但是，仍需要实施强制性的安全控制。利用强制性访问控制，用户、应用程序设计员和数据库管理员都不能绕过行级别的安全机制。
发明内容
根据本发明，提供了一种控制对关系数据库的访问的方法，包括接收对数据库中的数据进行访问的用户请求，该请求包括执行数据库操作的请求和用户安全标记；基于用户安全标记，确定用户安全信息；响应用户请求，从数据库中的表中检索至少一行数据，所述至少一行具有安全标记；基于至少一个检索到的行的安全标记，确定至少一个检索到的行的行安全信息；对于至少一个检索到的行，基于用户安全信息和行安全信息，判断用户是否被授权访问该行；如果判断用户具有访问授权，则返回所述至少一行。
优选情况下，请求不包含对视图的查询。优选情况下，请求不要求包含访问控制信息的表的联接，以便限制用户对数据库进行访问。在优选实施例中，数据库操作是查询。在另一个优选实施例中，数据库操作涉及行更新。
优选情况下，所述确定行安全信息包括检查高速缓存中是否有对应于行的安全标记的行安全信息。优选情况下，每一个用户或行安全标记是分别以安全级别的层次结构排列的多个用户或行安全标记中的一个。优选情况下，只有在用户安全标记对应的安全级别具有大于等于检索到的行的安全标记指示的安全级别的访问权等级的情况下，才判断用户被授权访问检索到的行。
在优选实施例中，只有在检索到的行的安全标记对应的安全类别是对应于用户安全标记的安全类别的真子集的情况下，才判断用户被授权访问检索到的行。
优选情况下，提供了一种在具有数据管理器和数据库的数据库管理系统内使用的设备，用于判断用户是否被授权对数据库内的一行数据执行请求的操作，用户与用户安全标记关联，行具有行安全标记，该设备包括记录了安全标记层次结构的用户安全性单元；读取安全性单元，该单元连接到用户安全性单元，并位于数据管理器和数据库之间，并被配置为，只有用户安全标记在层次结构中级别的权限大于或等于行安全标记所在的层次结构中的级别的权限的情况下，才将行从数据库返回到数据管理器。
在一个实施例中，安全性层次结构内的安全标记指出与安全标记关联的安全类别，其中，读取安全性单元被配置为，只有在与行安全标记关联的安全类别是与用户安全标记关联的安全类别的真子集情况下，才将请求的行从数据库返回到数据管理器。
优选情况下，设备进一步包括写入安全性单元，该单元连接到数据安全性单元，并位于数据管理器和数据库之间，并被配置为，如果请求的操作是行更新操作，则将行安全标记设置为与用户安全标记相同的值。优选情况下，写入安全性单元被进一步配置为，如果用户被授权更新具有较低级别的安全标记的行，并且如果为较低级别的安全标记指定的安全类别是与用户安全标记关联的安全类别的真子集，则以低于用户安全级别的级别设置行安全标记。
优选情况下，提供了一个在计算机可读的介质上实现的程序产品，用于控制对关系数据库的访问，包括用于接收对数据库中的数据进行访问的用户请求的程序指令，该请求包括执行数据库操作的请求和用户安全标记；用于根据用户安全标记确定用户安全信息的程序指令；用于响应用户请求，从数据库中的表中检索满足数据库操作的数据行的程序指令，在这些行中，每一行都具有安全标记；用于基于行的安全标记，确定每一个检索到的行的行安全信息的程序指令；对于每一个检索到的行，用于基于用户安全信息和行安全信息，判断用户是否被授权访问该行的程序指令；以及只返回判断用户具有对其进行访问的授权的那些行的程序指令。
在优选实施例中，提供了一种控制对数据库的至少一行中数据的访问的方法，其中，所述至少一行与行级别的访问控制信息关联，该方法包括接收来自用户对数据库进行操作的请求；对于满足请求的数据库的每一行，通过将与用户关联的安全级别和与行关联的安全级别进行比较，对满足请求的数据库的行应用强制性访问控制规则；如果与行关联的安全级别至少是用户的安全级别的子集，则从行返回数据。
优选情况下，请求不是对数据库的预定义的视图的请求，以限制对数据库的所述至少一行的访问。优选情况下，该方法不修改接收到的请求，以限制对数据库的所述至少一行的访问。优选情况下，请求是结构化查询语言(SQL)查询。在优选实施例中，数据库包括多个表，接收到的请求包括对多个表中的至少一个表进行访问的请求。
优选情况下，提供了一种控制用户的对数据库中的行中的数据的访问的方法，其中，每一行都与访问级别层次结构内的第一访问级别关联，用户与访问级别层次结构内的第二访问级别关联，其中，每一个访问级别都与一个或多个权限关联，访问级别以层次方式相关，该方法包括接收来自用户对数据库进行操作的请求；通过判断与第一访问级别关联的权限是否包括在与第二访问级别关联的权限中，判断用户是否被授权对满足请求的数据库的行进行操作；并且只有在判断用户被授权对行进行操作的情况下才从行返回数据。
这里所描述的系统和技术提供了关系数据库内的强制性的行级别的安全性。它们与当今所流行的常规数据库系统相比具有许多优点。它们可以提供安全性强制机制，该机制是强制性的，并且是自动的，可以实现以传统的结构化查询语言(SQL)视图或查询难以表达的安全性方案，并实现了性能优化，可以最小化与进行行级别的安全性检查关联的处理要求和消逝时间开销。这里所描述的系统和技术还提供了安全性强制机制，该机制不必依赖特殊的视图或数据库会话变量就能提供行级别的安全控制。
本发明的实施例涉及控制对关系数据库的访问的方法。该方法包括接收对数据库中的数据进行访问的用户请求，其中，请求包括执行数据库操作的请求和用户安全标记。用户安全信息是根据用户安全标记确定的。响应用户请求，从数据库中的表中检索满足数据库操作的数据行，其中，在这些行中，每一行都具有安全标记。该方法进一步包括基于行的安全标记，确定每一个检索到的行的行安全信息。对于每一个检索到的行，该方法基于用户安全信息和行安全信息，判断用户是否被授权访问该行。只返回判断用户具有对其进行访问的授权的那些行。
在另一个实施例中，一种在具有数据管理器和数据库的数据库管理系统内使用的设备，判断用户是否被授权对数据库内的一行数据执行请求的操作。用户与用户安全标记关联，行具有行安全标记。该设备包括记录了安全标记层次结构的用户安全性单元。它还包括连接到用户安全性单元并位于数据管理器和数据库之间的读取安全性单元。读取安全性单元被配置为，只有在用户安全标记位于层次结构中其权限大于或等于行安全标记所在的层次结构中的一个级别的权限的级别中的情况下，才将行从数据库返回到数据管理器。
来自用户的请求不需要包含视图的查询，也不要求包含访问控制信息的表的联接，以便限制用户对数据库进行访问。
在考虑下列描述和特定实施例的描述图的情况下，本发明的特征和优点将变得显而易见。尽管这些描述讨论了本发明的具体细节，但是，应该理解，可以有各种变化，基于这里的描述，对那些本领域技术人员来说显而易见。
现在将通过示例，并参考其优选实施例，描述本发明，如下面的图形所示，其中
图1是显示了具有管理了一个以上的Web站点的常规数据库管理系统的Web主机的方框图。
图2A-D分别显示了创建在传统的用于限制用户对数据库表中的某些数据行进行访问的方法中所使用的视图、查询的数据库表、SQL语句。
图3是显示访问控制系统的方框图，该系统包括具有读取强制性安全实施单元和写入强制性安全实施单元的数据库管理系统，这些单元支持实现强制性访问控制的行级别的访问控制。
图4显示了图3所示的访问控制系统支持的安全性层次结构方案的示例。
图5A和B显示了使用图4中所显示的安全性层次结构的查询、数据库表和安全机制。查询可以应用于使用安全机制所提供的强制性的行级别安全性实施方案的数据库表。
图6显示了在图3所示的数据库管理系统中使用高速缓存来在提供行级别的强制性访问控制时改进性能。
图7A和B是用于查询提供强制性的行级别的访问控制的数据库管理系统的流程图。
图8A-C是显示在提供强制性的行级别的访问控制的数据库管理系统中发送行更新请求和更新行的流程图。
具体实施例方式
下面将参考上面的图形描述下面的实施例，其中，相同的附图标记表示相同的部件。
某些常规数据库管理系统(DBMS)提供了某些限制访问数据库内的行的能力。然而，这些常规系统依赖数据库管理员创建限制对所希望的行进行访问的视图。然后，应用程序设计员必须使用这些特殊视图来实施安全控制。应用程序设计员常常必须用视图用来控制对数据行的访问的值来填充会话变量。虽然这样的常规系统确实可使程序员控制对数据的访问，但是，这些常规系统却具有多个缺点。
例如，常规DBMS使用视图来控制对数据库的访问。使用视图来控制对数据库的访问对于数据库管理员和应用程序设计员实现起来比较麻烦。例如，常常必须在安全方案中为每一个安全级别创建单独的视图(例如，TOP_SECRET VIEW、SECRET VIEW等等)。
使用视图来控制访问还易于出错，因为容易不正确地实现视图从而无意中地允许对错误的数据行进行访问。此外，某些安全方案也难以表示成视图或用户查询上的其他谓词。需要自动实施对数据的访问，以便不需要对用户应用逻辑或视图进行任何更改。
使用视图实现的安全策略只是可自行选用的，而不是强制性的。具有数据库管理员权限的人不使用实现安全机制的特殊视图就能够查看数据库中的数据。需要提供强制性安全控制，以防止最终用户、应用程序设计员和数据库管理员进行未经授权的访问。为了限制具有访问数据库中的数据的权限的用户数量，系统安全管理员应该是具有数据进行无限制的访问权限的个人。
图1显示了常规数据库应用的系统级别的图表，涉及托管了多个Web站点(即，Web站点12a、Web站点12b和Web站点12c)的Web服务器10。Web服务器连接到诸如因特网之类的数据通信网络14，该网络给诸如客户端16a和16b之类的多个客户端提供连接。Web服务器包括为每一个Web站点提供服务的单个DBMS 18。DBMS管理由多个Web站点所使用的数据。由于许多Web站点被Web服务器托管，而由单个DBMS提供服务，因此，必须提供安全性，以防止一个人从一个Web站点使用Web服务器10托管的另一个Web站点进行未经授权的访问。在常规Web服务器中，DBMS包括查询处理器20和数据管理器22。DBMS 18连接到保存了由DBMS进行管理的数据的数据仓库24。
查询处理器20处理包含在Web站点从客户端接收到的查询的请求。例如，典型的查询可以是在Web站点接收到的结构化查询语言(SQL)查询。SQL查询被传递到查询处理器20，以便进行分析，并由DBMS执行。基于查询，查询处理器20控制数据管理器22，以便与数据仓库24进行交互，以处理满足查询的相应的数据。
图2A显示了图1所示的DBMS内保存的常规用户表(USER.TABLE)26的示例。该表包含标记为图2A所示的Col1、Col2和Col3的各种数据列。用户表还包括安全标记(SECLABEL)列。每一行都与特定安全标记关联。这里，安全标记可以是诸如红色、蓝色、黄色、绿色之类的各种颜色的名称。每一个颜色名称都代表与用户表行关联的特定安全权限集。例如，“红色”的安全标记可能具有与该标记关联的一个访问权限集，而诸如“蓝色”安全标记之类的另一个安全标记与另一个权限集关联。
对常规DBMS中的USER.TABLE的访问由数据库视图进行控制。系统管理员创建数据库内的相关表的视图，以便基于用户的安全标记限制访问。
系统管理员通过使用如图2B所示的SQL语句来创建表。这里，系统管理员创建一个叫做USER.VIEW 28a的视图，其中，视图是从三个列(即，U.COL1、U.COL2、U.COL3)中选出来的，如图2的线28b所示。这些列是从图2A所示的USER.TABLE中选出来的。安全性表(SECURITY.TABLE)30将用户ID(USERID)与诸如“红色”、“蓝色”或“绿色”安全标记之类的安全标记(SECLABEL)相关。这显示在图2B的线28c中。图2B的线28d要求用户安全标记等于安全性表中定义的安全标记，安全性表中的用户ID等于当前用户。这就将访问只限制于图2A的USER.TABLE中的具有等于当前用户的安全标记的安全标记的那些行。虽然这种常规访问控制方案提供了一定程度的访问控制，但是，它却不支持层次型安全性方案。
图2C显示了当将图2B的SQL语句应用于USER.VIEW32时安全性表30和所产生的视图之间的关系。如果对于用户“SALLY”访问USER.TABLE 26应用图2B的视图，则结果如图2C所示。这里，在图2C中，当用户SALLY请求访问USER.TABLE时，图2B的视图将表26的SALLY的视图限制到如图2C所示的USER.VIEW 32。当将视图表26时，USER.TABLE26与SECURITY.TABLE 30联接，以产生USER.VIEW 32。
图2D显示了用户SALLY请求的示例查询34。SALLY的查询包括从USER.VIEW中选择所有行的选择SQL子句。常规DBMS系统通过将如图2B所示的视图应用到如图2A所示的USER.TABLE 26来进行工作。如图2C的SECURITY.TABLE 30所示，SALLY的安全标记是“蓝色”，相应地，所产生的用户视图32只包括USER.TABLE 26的具有等于安全标记“蓝色”的安全标记的那些行。如此，常规DBMS将用户的访问限制到只能对某些行进行访问。然而，此常规的访问控制技术不支持层次型的安全性方案，它要求使用视图来限制访问。
常规数据库管理系统所存在的这些问题可以使用下列概念提供行级别的安全性来加以克服。
1.给数据库管理系统的每一个最终用户分配一个SECURITY_LABEL。该标记识别多级别安全性方案内的用户的安全级别，并定义访问数据库中的数据的某些权限。该安全标记还识别该安全级别内允许用户访问的安全性安全类别。安全类别的一个示例是用户被授权对其进行处理的软件开发项目。例如，一个给定用户可以被允许查看某些安全级别指定的数据，如安全级别TOP SECRET、SECRET和UNCLASSIFIED。该用户还可以被允许访问属于某些类别的(如项目ABC、DEF和XYZ)的数据。安全标记中存储的值以向安全系统表示安全级别和类别信息的方式进行编码。这样的编码的示例是标记SECRETABC，其中，“SECRET”指定安全级别，“ABC”指定安全类别A、B和C，这可以是分配用户对其进行处理的项目的标识符。
用户的安全标记可以使用不同技术来确定。例如，用户的安全标记可以使用关系DBMS目录进行查询；通过对外部安全管理器进行安全性调用；或通过对信任的安装出口例程的调用来确定。可以理解，可以使用其他技术来确定用户的安全标记。
2.安全表内的每一行都与安全标记关联，这可以是该安全性表内的一列。例如，该列可以具有预先确定的名称(例如，SECURITY_LABEL)或者，当定义表时，它可以通过SQL子句来识别(例如，CREATE TABLE列定义上的AS SECURITY LABEL子句)。可以理解，也可以使用其他技术来将安全标记与行关联。
行中的SECURITY_LABEL列识别行中包含的数据的安全级别，以及行向其中应用的安全类别。例如，行可以包含属于项目ABC和XYZ(安全类别)的具有安全级别“SECRET”的数据。SECURITY_LABEL中存储的值以向安全系统表示安全级别和类别信息的方式进行编码。
3.强制性安全强制机制控制对安全数据行的读取访问。当已知关系数据库表包括SECURITY_LABEL列时，自动激活该机制。此读取安全性强制机制将用户的安全标记与行的安全标记进行比较，以判断是否应该允许访问。只有在用户的安全性优于行的安全性的情况下，才允许进行读取访问，其中，下列两个条件都为truea.用户的安全标记指示的安全级别大于或等于行的安全标记指示的安全级别。
b.与行的安全标记关联的安全类别是与用户的安全标记关联的安全类别的真子集。
写访问权限是单独地进行控制的，以便用户可以遵循不从具有比用户更高的安全级别的行读取或写入到具有比用户更低的安全级别的行中的一般规则。
读取和写入访问安全机制可以使用一些其他技术来实施访问方案，如通过使用关系DBMS目录进行查询；通过对外部安全管理器进行安全性调用；或通过对信任的安装出口例程的调用。
4.强制性安全强制机制控制对安全数据行的写入访问。当已知关系数据库表包括特定列名时，自动激活此机制。该机制判断哪一个安全标记记录在要写入到数据库中的更新数据行中。此写访问安全机制强制那些更新的行中的每一行包含下列可能的值之一a.与用户的安全标记相同的安全标记被用作更新的行的安全标记。
b.如果用户经过特别授权，则该用户被允许使用具有比用户的当前安全标记较低级别的行安全标记更新行。在允许行更新之前，写访问安全机制验证用户的安全性是否优于行的安全性，以便下列所有条件都为true。
i)用户经过特别授权，以在具有为低于与用户的安全标记关联的安全级别的安全级别指定的安全标记的行中写入数据。
ii)为行指定的安全标记具有小于或等于与用户的安全标记关联的安全级别的安全级别。
iii)为行指定的安全标记的安全类别是与用户的安全标记关联的安全类别的真子集。即，与行的标记关联的所有安全类别也与用户的安全标记关联。
写访问安全机制使用一些不同的技术来实施访问方案。例如，它可以使用关系DBMS目录来进行查询；对外部安全管理器进行安全性调用；或对信任的安装出口例程进行调用。
图3中显示了支持行级别的强制性访问控制的DBMS。这里，DBMS 18，除了查询管理器20和数据管理器22外，还包括读取强制性安全单元36和写入强制性安全单元38。DBMS 18的示范性实施例是针对z/OS操作系统的DB2。(DB2和z/OS是IBM公司的注册商标)。每一个强制性安全单元都连接到数据管理器22和数据存储单元24。强制性安全单元根据层次型安全性方案控制用户或诸如Web站点之类的应用40对数据的访问。
通过在数据管理器22和数据仓库24之间放置强制性安全单元，便实现了强制性访问控制。如果数据管理器22试图从数据存储单元24读取一行数据，则请求通过读取强制性安全单元36进行定向。该安全性单元将由数据管理器传递的用户的安全标记和与数据存储单元24中的请求的数据行关联的安全标记进行比较。如果满足了上文讨论的条件，则授予对行的访问权限。即，读取强制性安全单元36根据用户的安全标记判断用户的安全级别和安全类别。它还根据行的安全标记判断行安全级别和行安全类别。如果用户的安全级别大于或等于行的安全级别，并且如果与行关联的安全类别是与用户的安全级别关联的安全类别的真子集，则允许进行读取访问。由于每个尝试的对数据的读取访问都经过读取强制性安全单元，因此，便实现了强制性访问控制。
同样，当将更新的行写入到数据库时，写入强制性安全单元38从数据管理器22接收将行存储在数据存储单元24中的请求。写入强制性安全单元38确保了在允许行在数据存储单元24中更新之前满足上文讨论的条件。即，写入强制性安全单元确保了用户的安全标记指出用户的安全级别和安全类别对应于由要更新的行的安全标记指出的安全级别和安全类别。
在图4中在概念上显示了层次型的安全性方案。这里，安全性方案显示了使用颜色的名称标记的安全级别。例如，安全级别42带有“红色”标记，安全级别44带有“橙色”标记，安全级别46带有“黄色”标记。同样，安全级别48带有“绿色”标记，级别50带有“蓝色”标记，级别52带有“靛青”标记，级别54带有“紫罗兰”标记。这些安全级别，即，颜色名称，类似于在常规数据库中使用的如图2A所示的安全标记。然而，如图4所示的方案是层次型的安全性方案，其中，安全级别被组合在一起，创建了多级别安全系统中的不同的安全级别。例如，带有“日落”标记的安全级别56包括其分支内的较低级别的安全标记(即，红色、橙色和黄色)的所有访问权限。相应地，安全标记“日落”在安全方案中位于比安全标记“红色”、“橙色”和“黄色”更高的级别中。同样，标记为“大青”的安全级别58包括其分支中较低级别的安全标记(即，安全标记“蓝色”、“靛青”和“紫罗兰”)的所有权限。如此，安全标记“大青”在层次型的安全方案中位于比安全标记“蓝色”、“靛青”和“紫罗兰”更高的级别中。
标记为“彩虹”的安全级别60位于安全层次结构的最高级别。如图4所示，“彩虹”标记包括如图4所示的树结构中的每个安全标记的所有权限。此层次型安全方案支持多级别访问控制。
在使用这里所描述的强制性安全访问控制的DBMS中，用户可以直接查询DBMS表，并自动执行强制性访问控制。这就允许诸如图5A所示的查询62之类的查询应用于DBMS，而不必如在常规DBMS中那样使用视图来控制访问。这里，图5A所示的来自“BOSS2”的查询包括SELECT子句62。SELECT子句用于从用户表“USER.TABLE”中选择所有数据。如果DBMS不包括任何访问控制，则将返回整个表的内容，不管用户的安全级别如何。然而，当此查询应用于具有强制性访问控制的DBMS时，如图3所示，返回的数据行只是用户被授权访问的行。
图5B中显示了此控制方面。这里，用户表26包括行，每一行都带有安全标记，即，安全标记“红色”、“蓝色”、“黄色”等等。当由DBMS接收到从用户或应用40发出的图5A所示的查询时，查询处理器20处理查询，并向数据管理器22发送请求，以选择USER.TABLE 26的所有行。然而，读取安全单元36基于安全机制64进行操作，以限制返回的用户表的行。可以使用各种各样的安全机制，如图5B所示的表，该表将用户ID与用户的安全标记相关。但是，可以理解，也可以使用其他安全机制来确定与用户关联的安全标记。
安全标记可以是图4所示的层次结构中的叶节点上的安全级别，如安全标记“红色”。然而，安全标记也可以是诸如安全机制64的行64b中显示的安全级别“彩虹”之类的较高级别的标记。例如，用户“BOSS 1”具有表64中行64b中的由标记“彩虹”定义的访问权限，从而给该用户提供了高度的访问权限。同样，另一个用户，例如，“BIG BOSS”也可以使用相同的高级别标记，如“彩虹”安全级别，如行64c所示。
在用户ID“BOSS 2”的行64d中显示了层次型安全级别的另一个示例。BOSS 2具有安全标记“日落”。如图4所示，具有“日落”安全标记的BOSS 2具有包括安全标记“红色”、“橙色”和“黄色”的所有权限的访问权限。相应地，当BOSS 2提交图5A所示的查询时，读取强制性安全单元将BOSS 2的安全标记与USER.TABLE 26中的每一行的安全标记进行比较。由于“日落”标记包括“红色”、“黄色”和“橙色”安全标记的所有权限，读取强制性安全单元36返回具有安全标记“红色”的行26a，具有“黄色”安全标记的行26c，和具有安全标记“红色”的行26g。由于那些安全标记在层次结构中从属于“日落”标记，如图4所示，不返回其他行，即，行26b、26d、26e、26f和26h，因为这些行的安全标记不图4所示的层次结构的“日落”分支内。如此，用户BOSS 2可以提交图5A所示的查询62，而不使用视图来将访问限制到具有和与BOSS 2关联的安全标记相同的安全级别或更低级别的安全级别的那些行。
图6显示了图3所示的DBMS系统的另一个实施例。这里使用高速缓存来提高性能。高速缓存进行操作，以将安全标记信息存储在可以轻松地获得的内存中，以便每次访问行时，都不必解释安全标记，无论是通过调用外部例程还是执行查询来确定安全级别和关联的权限，以及与特定安全标记关联的类别。这里，DBMS包括高速缓存66，用于保存为特定用户处理的每一个查询确定的安全标记信息。
在图6所示的实施例中，用户向DBMS提交SQL查询68。查询处理器20以常规的方式处理接收到的查询。如图6所示，查询从打开光标和执行循环开始。循环包括获取下一行，该行导致与图6所示的数据管理器/强制性安全单元70进行交互。数据管理器/强制性安全单元70可以包括图3所示的数据管理器和读取强制性安全单元36和写入强制性安全单元38的功能，可以是单独的功能，也可以是组合功能。这里，在图6中，它们显示在同一个单元中。为便于描述，数据管理器/强制性安全单元70将被简称为“数据管理器”70。
数据管理器70从数据存储单元24中检索下一行。在从数据存储单元24中检索行时，数据管理器70执行检查返回的行是否包括安全标记的强制性安全功能。如果包括，则对高速缓存66进行搜索，以判断与该安全标记关联的信息是否已经存在于高速缓存中。如果存在，则使用高速缓存内的安全信息来将用户安全级别和与检索到的行关联的安全级别进行比较。如果在高速缓存中没有找到安全标记，则数据管理器70确定与安全标记关联的信息。这可以以各种方式执行，如通过调用安全层，如图6所示。然后，将安全标记信息判断的结果放在高速缓存66中，从而将安全标记调用的结果高速缓存起来。
一旦安全信息可用，则将与检索到的行关联的标记的安全级别和类别和与用户的安全标记关联的安全级别和类别进行比较。然后，就是否允许用户访问该行作出判断。
如果比较的结果是将允许用户进行访问，然后，将行返回到查询处理器20，以便返回到用户。然后，查询处理器20中所显示的循环持续执行，直到查询完成。
当查询完成时，查询处理器通知数据管理器，然后，数据管理器清空高速缓存。如此，高速缓存信息只用于单个用户进行的单一查询。换句话说，对于用户进行的每一个查询，将刷新高速缓存中保存的安全标记信息，以便高速缓存中信息只在处理用户的查询的过程中存在。在执行查询的过程中，假设用户的安全级别和行的安全级别保持不变。然而，通过在每一次查询之后清空高速缓存，可以对用户的安全级别和数据中的行的安全级别作出更改，而不必使高速缓存中保存的信息失效。
下面是可以用来给行级别的安全提供强制性访问控制的过程的示例。
当数据库管理员创建图3所示的DBMS中的表时，管理员在表中包括SECURITY_LABEL列。管理员还将SECURITY_LABEL列添加到表中，以便加以保护。DBMS使用SECURITY_LABEL列的存在来自动激活行级别的安全。如此，由SECURITY_LABEL列的存在和数据行的内容驱动行级别的安全机制。SECURITY_LABEL列允许对数据库中的行使用安全控制，而不依赖于数据库管理员创建识别允许每一个用户访问的行的特殊视图。每当安全标记存在时，这样的安全控制使得行级别的安全对于表都是强制性的，无法通过直接访问表(即，使用或避免控制行访问的特殊视图)来绕过这些控制。每一行中存储的安全标记都具有编码值，该值封装了下列两个具体信息片段。
a.行中包含的数据的安全级别。这就可以实现多级别、层次型的安全方案(例如，TOP SECRET、SECRET、UNCLASSIFIED)。
b.此行数据所适用的安全类别。例如，一行数据可以与六个安全等级关联(例如，在其上面使用该行的项目A、B、C、D、E、F)。安全标记可以以这样的方式编码，以便允许安全机制确定此行数据所属的可能的安全等级的子集。
当最终用户登录到DBMS上时，用户将提供向DBMS标识用户的身份验证令牌(例如，用户ID/密码、KERBEROS票据等等)。一旦确定了用户的身份，DBMS确定与最终用户关联的安全标记。这可以使用许多不同的技术来完成，如通过DBMS的授权表中的表查询；通过对外部安全产品进行安全检查；或通过信任的用户出口例程。与行的安全标记相同，对用户的安全标记进行编码，以封装下列信息。
a.用户被授权访问的数据的安全级别。这就可以实现多级别、层次型的安全方案(例如，TOP SECRET、SECRET、UNCLASSIFIED级别)。
b.用户与其关联的并被授权访问的安全类别。例如，用户可以与三个不同的项目关联(例如，项目A、B和C，其中每一个项目都可以作为一个安全类别来指定)。
图7A显示了用户查询其中存在强制性访问控制的数据库的过程。用户在操作72中，准备查询，以便提交到具有包括SECURITY_LABEL列的表的DBMS。用户通过登录到DBMS或通过另一种方法向DBMS标识。在操作74中使用前面所描述的技术来确定用户的安全级别和安全类别。由客户端在客户端/服务器系统中在操作76中准备具有用户的查询的请求。除了查询外，请求还包括用用户的安全级别和安全类别编码的用户安全标记。在操作78中将请求发送到DBMS。
请参看图7B，DBMS在操作80中接收用户的请求。在操作82中，DBMS通过查询处理器和数据管理器，处理查询，并扫描请求的表，以查找满足用户的查询谓词的行。在将任何数据返回到用户应用之前，DBMS调用安全机制，以判断用户是否被授权查看数据。在操作84中，第一判断是判断数据库表是否具有SECURITY_LABEL列。如果表没有SECURITY_LABEL列，那么，在操作86中以常规方式处理查询，并在操作88中将查询的结果返回到用户。
如果该表具有SECURITY_LABEL列，那么，在操作90中调用安全机制，通过对用户的安全标记进行解码来确定用户的安全级别和安全类别。从SECURITY_LABEL列检索行的安全标记，并对其进行解码。安全机制可以以许多方式实现，如通过DBMS的授权表内的查询，通过对外部安全产品的调用，或通过安装出口例程等。安全机制负责检查行的安全标记，以判断用户是否被授权检索该特定行。这是在操作92中通过比较用户的安全级别与行的安全级别来完成的。对于每一行，有两种可能的情况。
a.行的安全标记具有一个在对用户可以访问的值的范围内的值。当用户的安全性优于行的安全性，并且下列两个条件都为true时，就是这种情况1)用户的安全标记指示的安全级别大于或等于行的安全标记指示的安全级别，如在操作94中所判断的那样。如果不，则在操作96中拒绝用户访问该行。如果是，则在操作98中测试下一个条件。
ii)与行的安全标记关联的安全类别是与用户的安全标记关联的安全类别的真子集，如在操作98中所判断的那样。如果是这种情况，则在操作102中DBMS处理该行，并检索被请求的数据值，并将结果返回给用户。如果不，则在操作100中拒绝用户访问该行。
b.与该行关联的安全标记位于对应于用户的安全标记的值的范围之外。在此情况下，DBMS要么忽视该行，要么声明尝试违反了安全性，具体情况取决于为数据库管理系统使用的安全策略。如此，拒绝用户对保护的行进行访问，如操作96和100所示。
为使与行级别的安全检查关联的计算机处理器使用和消逝时间，DBMS可以在处理用户的事务的过程中将在事务的运行过程中成功地经过验证的行安全标记值高速缓存在图6所示的高速缓存66中。如果遇到具有已经存在于用户的高速缓存中的安全标记值的随后的行，则可以绕过安全检查，因为该特定安全标记值已经通过了安全检查。在数据库提交和回滚边界中销毁经过验证的安全标记值的高速缓存，以便安全策略中的随后的变化反映在下一个工作单元中。
让安全机制检查安全级别和安全类别可以给安全机制在支持各种安全策略时提供很大的灵活性。这种情况包括下列示例。
a.安装可以选择允许只在正好匹配的情况下(用户安全标记＝“红色”，而安全标记＝“RED”)进行访问。
b.安装可以选择只有在行的安全标记是用户的安全标记的真子集的情况下(用户安全标记＝“彩虹”，这就意味着“红色”、“橙色”、“黄色”、“绿色”、“蓝色”、“靛青”和“紫罗兰”是此用户的行安全标记的允许值)才允许进行访问。
c.安装可以选择允许基于层次结构进行访问。例如，用户的“TOP SECRET”安全标记将允许对该相同的级别和下面的级别即，“TOP SECRET”“SECRET”和“UNCLASSIFIED”行安全标记值的所有安全级别进行访问。
d.还可以使用上面的方案的组合，具体情况取决于应用。
现在请参看图8A，当用户在操作104中请求对数据库表中的一行中的数据进行更新时，要么对行中的数据进行更改，要么插入行，在操作106中识别用户，并确定用户的安全级别和安全类别。在操作108中准备请求，该请求包括行更新以及用户的安全级别和类别。然后，在操作110中将该请求发送到DBMS。
现在请参看图8B，一旦用户发出更新请求，如更新数据的SQL请求(INSERT、UPDATE等等)，DBMS在操作112中接收该请求。该请求包括对行中的数据进行更新和指出用户的安全级别和安全类别的用户的安全标记。安全机制在操作114中判断安全标记更新的行关联。在此实施例中，用户的安全标记被用作更新的行的安全标记。或者，也可以基于适于应用和操作环境的标准，选择不同的安全标记。在操作116中，安全机制判断要更新的行是否包含SECURITY_LABEL列。如果不包含，则在操作118中以常规方式对更新进行处理。
如果行包括SECURITY_LABEL列，则执行操作120，判断用户的安全标记是否等于行的安全标记。如果是，则在操作122中执行更新，并将行的安全标记设置为等于用户的安全标记。
如果用户的安全标记不等于行的安全标记，则在操作124中判断用户是否被特别授权记录具有不同于用户的安全级别的安全级别的更新。如果用户没有被特别授权，则在操作126中拒绝对表进行更新的访问。然而，如果用户被特别授权，则将根据用户的安全标记确定的用户的安全级别与要更新的行的安全级别进行比较，在操作128中判断用户的安全性是否优于行的安全性。在此操作中，对用户的安全标记和行的安全标记进行解码，以确定编码在其中的安全信息。可以使用许多不同的技术来实现此解码操作，如通过DBMS内的授权表中的查询；通过对外部安全产品进行调用；或通过安装出口例程。在操作128中比较诸如安全级别信息之类的经过解码的安全标记的信息。
顺着图8C的连接符“A”往下进行，在操作130中，基于比较结果，判断用户的安全级别是否大于或等于行的安全级别。如果不，则在操作132中拒绝用户对行进行更新的访问。然而，如果用户的安全级别大于或等于行的安全级别，则执行操作134，比较安全类别。
在操作134中，如果要更新的行的安全类别构成了用户的安全类别的真子集，则在操作136中将更新的行记录在数据库中。如果行的所有安全类别都包括在用户的安全类别集中，则行的安全类别构成用户的安全类别的真子集。然而，如果行的安全类别没有构成用户的安全类别的真子集，则在操作138中拒绝用户对行进行更新的访问。
在更新行时，不仅可以给诸如图3所示写入强制性安全单元38之类的安全机制提供用户的安全标记值，而且还可以提供行的安全标记的建议的值。该建议的值可以通过用户的SQL更新操作来提供。安全机制可以选择允许行的安全标记在不作更改的情况下进行记录，也可以选择基于安装的安全策略将不同值施加到行的安全标记中。这就允许安装使用任何希望的安全策略。例如，可以选择安全策略，以迫使所有更新记录在修改的行的安全标记的所有更新成为进行更新的用户的安全标记。也可以选择另一个安全策略，以允许选定用户用不同于用户的安全标记的行安全标记值进行更新。这样的安全标记值的示例是用户的安全标记值的真子集的值，以及小于或等于用户的安全级别的值。
资源访问控制程序(RACF)(RACF是IBM公司的注册商标)是可以用来执行强制性安全单元的功能的产品的示例。根据一个实施例，数据库表可以通过添加因为安全标记的特别命名的列来激活行级别的安全支持。使用RACF出口来检查在光标内访问的每一个安全标记值，并判断提交SQL查询的SQL查询请求者是否被允许对数据行进行访问。RACF中的安全层将理解诸如代表图4中显示的彩虹的颜色的层次结构的层次关系。
利用RACF中建立的层次结构，DBMS理解，具有访问“大青”信息的权限的用户可以访问与“蓝色”、“靛青”、“紫罗兰”或“大青”关联的任何行。利用这些功能，可以实现该安全方案类型，而要求应用使用特殊的视图或谓词访问数据。
在描述了在关系数据库管理系统中提供行级别的安全的设备、产品和方法后，可以相信，那些本领域技术人员在考虑到这里所阐述的原理的情况下，可以进行其他修改。因此，可以理解，所有这样的变化、修改和更改都在如所附的权利要求所定义的本发明的范围内。虽然这里使用了特定的术语，但是它们只是在作为通用和描述性的意义上使用的，除非以不同的方式进行明确的定义，而不是起限制作用。
权利要求
1.一种控制关系数据库的访问的方法，包括接收对数据库中的数据进行访问的用户请求，该请求包括执行数据库操作的请求和用户安全标记；基于用户安全标记，确定用户安全信息；响应所述用户请求，从数据库中的表中检索至少一行数据，所述至少一行具有安全标记；基于至少一个检索到的行的安全标记，确定所述至少一个检索到的行的行安全信息；对于所述至少一个检索到的行，基于用户安全信息和行安全信息，判断用户是否被授权访问该行；以及如果判断用户具有访问授权，则返回所述至少一行。
2.根据权利要求1所述的方法，其中，每一个用户或行安全标记都是分别以安全级别的层次结构排列的多个用户或行安全标记中的一个。
3.根据权利要求2所述的方法，其中，只有在用户安全标记对应的安全级别具有大于等于检索到的行的安全标记指示的安全级别的访问权等级的情况下，才判断用户被授权访问检索到的行。
4.根据权利要求1到3中的任何一个权利要求所述的方法，其中，每个用户或行安全标记都指示一个或多个安全类别。
5.根据权利要求4所述的方法，其中，只有在检索到的行的安全标记对应的安全类别是对应于用户安全标记的安全类别的真子集的情况下，才进一步判断用户被授权访问检索到的行。
6.根据前面的任何一个权利要求所述的方法，进一步包括下列步骤如果请求的操作是行更新操作，则将行安全标记设置为与用户安全标记相同的值。
7.根据权利要求4到6中的任何一个权利要求所述的方法，进一步包括这样的步骤如果用户被授权更新具有较低级别的行安全标记的行，并且如果为较低级别的行安全标记指定的安全类别是与用户安全标记关联的安全类别的真子集，则以低于用户安全级别的级别设置行安全标记。
8.一种计算机程序，包括用于当所述程序在计算机上运行时执行权利要求1到7中的任何一个权利要求的步骤的程序代码装置。
全文摘要
访问控制系统和访问控制方法为数据库管理系统提供了多级别和强制性访问控制。访问控制技术提供了关系数据库表中的行级别的访问控制。数据库表包含安全标记列，在该列内记录了在层次型安全方案内定义的安全标记。用涉及用户的安全信息对用户的安全标记进行编码。当用户请求对行进行访问时，安全机制将用户的安全信息与行中的安全信息进行比较。如果用户的安全性优于行的安全性，则允许用户访问该行。
文档编号G06F19/00GK1729469SQ03820905
公开日2006年2月1日 申请日期2003年9月2日 优先权日2002年9月4日
发明者库尔特·科特纳, 罗杰·L·米勒 申请人:国际商业机器公司