Database fine-grained access control

Details Database fine-grained access control Database fine-grained access control

2002-09-18

2003-10-07

Kindred, Alford (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C707S793000, C707S793000

Reexamination Certificate

active

06631371

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to database management systems and, more particularly, to controlling access to information within database management systems.
BACKGROUND OF THE INVENTION
In a database management system (DBMS), data is stored in one or more data containers, each container contains records, and the data within each record is organized into one or more fields. In relational database systems, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
Systems that implement the present invention are not limited to any particular type of data container or database architecture. However, for the purpose of explanation, the examples and the terminology used herein shall be that typically associated with relational databases. Thus, the terms “table”, “row” and “column” shall be used herein to refer respectively to the data container, record, and field.
For various reasons, it may not be desirable for all users to have access to all of the rows of a particular table. For example, some rows in a table may contain text in English, while other rows contain text in Spanish. In this case, it would be convenient to limit the access of English-speaking users to the rows containing English, and the access of Spanish-speaking users to the rows containing Spanish.
It may also be desirable to restrict access to certain rows for security reasons. For example, certain rows of a table may contain top secret information, other rows may contain secret information, while other rows contain unclassified information. Under these conditions, the rows made available to any given user should be dictated by the security clearance of that user.
Both of the situations described above require row-level filtering of data, and the second situation also requires that the filtering enforce an access-control policy. To enforce row-level access-control policies, a database server must have a mechanism for restricting users to particular subsets of the rows within tables. One technique for implementing row-level access-control policies involves causing all access to a table to be performed indirectly through “views”.
A view is a logical table. As logical tables, views may be queried by users as if they were a table. However, views actually present data that is extracted or derived from existing tables. A view is defined by metadata referred to as a view definition. The view definition contains mappings to one or more columns in the one or more tables containing the data. Typically, the view definition is in the form of a database query. Columns and tables that are mapped to a view are referred to herein as base columns and base tables of the view, respectively.
To restrict a user to a particular subset of rows within a table, the user may be granted rights to access a view that extracts from the table only those rows that belong to that particular subset. For example, assume that a table “t” has two columns “text” and “lang”. The “text” column of each row stores textual information, and the “lang” column of each row stores data indicating the language of the text of that row. Under these conditions, English speaking users may be restricted to accessing table “t” through a view defined as follows:
V
1
:
SELECT * from t
WHERE t.lang=‘English’
while Spanish speaking users may be restricted to accessing table “t” through a view defines as follows:
V
2
:
SELECT * from t
WHERE t.lang=‘Spanish’
Each of these view definitions contain a WHERE clause that specifies conditions that restrict the rows of table t that are retrieved by the views. These conditions are referred to as the “predicates” of the view definitions.
Views offer a convenient way to provide row-level access control when the users fall into a relatively small number of categories. For example, if users are categorized solely on the basis of language and only two languages are supported, then only two views need to be created. However, many access policies require users to be divided into a large number of categories based on multiple criteria.
For example, an access policy may require access to be determined based on a user's language, security clearance, and department. If the database system supports 20 languages, 5 security clearance levels, and 15 departments, the number of views required to implement the access policy would be 20*5*15=1500. For example, the view that would be used by English speaking users with security clearance of 3 that belong to the Insurance department may be defined as follows:
V
3
:
SELECT * from t
WHERE t.lang=‘English’
AND t.security_level<=3
AND t.dept=‘Insurance’
View V
3
uses “hard-coded” literals, such as ‘English’,
3
, and ‘Insurance’. The use of hard-coded literals in view definitions can have serious performance implications. Specifically, the use of literals renders similar queries (that would otherwise be able to share query plans and resources) into distinct queries that can share no resources.
In some cases, access policies may dictate that every individual is to be treated differently. For example, an access policy may dictate that every user is only able to access rows that contain his or her user_id. Under these circumstances, a separate view would have to be created for every user. The view for a particular user would, for example, be defined as follows:
V
4
:
SELECT * from t
WHERE t.user_id=5837392
Under certain conditions, the proliferation of views may be avoided through the use of bind variables. This requires that the database application issue SQL containing bind variables, such as in the following example:
V
5
:
SELECT * from t
WHERE t.user_id=:BINDVAR
In the query V
5
, BINDVAR is a bind variable that may be set to a value by the user prior to submitting the query V
5
. For example, the user that has the user_id of 5837392 can set BINDVAR to 5837392 prior to accessing data using query V
5
. In this case, query V
5
would extract from table t the same rows as the query that defines view V
4
, in which the user_id value is hard-coded.
Note that the bind variable solution depends entirely on ubiquitous coding in the database application itself. This is not only potentially weaker from a security standpoint, but it is tedious and difficult to code for the application programmers.
Because each user can tailor query V
5
by setting BINDVAR to his or her own user_id, only one query is required to implement a policy that would otherwise have required one view per user.
Unfortunately, if the user with the user_id of 5837392 can set BINDVAR to 5837392, then it may be possible for other users to do so as well. When bind variables are used in queries that implement an access policy, the entity that has power to set the bind variables typically also has the power to violate the policy. In many instances, the entity that sets the bind variables is a database application. If the database application is not secure, or if it is possible for users to circumvent the database application, then the data protected by the access policy is not secure.
Another approach to avoid the use of multiple views to implement an access control policy involves the use of a “session” table. When a session is started, a row is added to the session table for the newly started session. The row indicates the session_id of the new session, as well as any other values that are factors used in the access control policy. For example, the session table entry may include the user_id, language, and department of the user that has established the session. All users are then required to access the protected table through a view that performs a join between the session table and the protected table. Such a view may be defined as follows:
V
6
:
SELECT * from t, sessio

Affiliated with

Also associated with

Rating

Database fine-grained access control does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Database fine-grained access control, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database fine-grained access control will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3152675