Database Security

Concepts and Approaches

Jef Van Loon

University of Zurich, Department of Informatics

Abstract. Security in databases becomes increasingly important as da-

tabases are being connected over computer networks. This paper dis-
cusses requirements for database security solutions and presents ap-
proaches to meet these requirements. An attempt is made to identify
and summarize the relevant trade-offs which drive the approaches. The
focus of this paper are access control mechanisms which are the most
prominent exponents of security systems for databases.

Seminar in Database Systems

University of Zurich Prof. Dr. C-C. Kanne
Department of Informatics Ch. Sturm
Autumn Term 2008
 Table of Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 The Significance of Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Summary: Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Properties and Basic Principles of Access Control Mechanisms . . 7
2.2 Discretionary Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . 8
2.3 Role-Based Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Mandatory Access Control Mechanisms . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Comparison of DAC, RBAC and MAC . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Security in Advanced Data Management Systems . . . . . . . . . . . . . . . . . . 16
3.1 Access Control Systems for XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Challenges Beyond Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
 Database Security: Concepts and Approaches 3

1 Introduction

1.1 Motivation

Security is an important requirement in today’s information systems infrastruc-

ture. Almost every month, media report some form of security incident related
to the use of information systems. Recently, the theft of 17 million customer
records at Deutsche Telekom1 was made public. The stolen data included sen-
sitive information such as names, addresses and (secret) phone numbers. Even
though no misuse of the data has been reported, this incident has caused a severe
loss of confidence for the company and for the affected customers, it is a severe
violation of their privacy.
As stated by Oppliger [9], security is not a product or service but an engi-
neering and management problem. This paper discusses the engineering aspect
of security and presents basic mechanisms to protect databases against unau-
thorized access. These mechanisms are the enablers for the desired managerial
processes that need to be established to ensure a comprehensive security archi-
tecture within an organization.
As stated by Bertino and Sandhu [2], the broad adoption of database systems
for business operation and decision making requires that security-related issues
be considered to protect valuable data from disclosure, modification or damage.
Elmasri and Navate [4] mention that database security is a very broad area,
which needs to address the following issues:

– Legal and ethical issues regarding the right to access certain information.
The main observation regarding this point is, that access to some data is
subject to different laws governing privacy of information.
– Policy issues at the governmental, institutional and corporate level regard-
ing the question what information should be made publicly available.
– Organizational issues refer to the requirements of some organizations that
data and users be categorized and appropriate security levels be established.
– System-related issues refer to the question at which levels security func-
tions should be enforced. For example, security constraints can be enforced
at the hardware or the software level. If they are handled at the software
level, it must be decided whether enforcement occurs at the operating system
level or within the Database Management System (DBMS).

It is easy to recognize that all of the issues given above are relevant to the
incident at Deutsche Telekom. The disclosure of customer data to a third party
will probably have legal consequences for the company and – if they are ever
determined – the individuals who have illegally accessed the data. Also, the
disclosure of data could be classified as a violation of governmental (the laws)
and corporate policies regarding data and privacy protection. Organizational and
system-related questions must be addressed to improve the current situation and
1
http://www.nzz.ch/nachrichten/panorama/mehr als 17 millionen kundendaten
bei deutscher telekom gestohlen 1.1023080.html, last accessed October 25, 2008
4

to determine which corporate users should have access to which customer infor-
mation and how this policy will be implemented and enforced at the technical
level.
In addition to the contextual issues of database security, it is possible to
categorize the threats to databases as follows [2], [4]:

– Unauthorized data observation (loss of confidentiality) results in the

disclosure of data to unauthorized users. The impact of unauthorized data
observation can range from violation of laws to the exposure of public secu-
rity. This in turn can lead to the loss of confidence, embarrassment, or even
legal action against the organization.
– Incorrect data modification (loss of integrity) – intentional or uninten-
tional – results in an incorrect database. The use of incorrect information
may result inaccuracies, erraneous decisions, which in turn can lead to fi-
nancial losses but also to a loss of confidence.
– Data unavailability (loss of availability) refers to a situation in which data
required for the proper functioning of an organization cannot be accessed –
be it, that data is not accessible by human users or by programs. These
issues are especially relevant within a business context and can also result
in heavy financial losses or the loss of confidence.

Again, relating the case at Deutsche Telekom to the threats mentioned above,
it becomes obvious that the incident can be classified as unauthorized data ob-
servation with the respective consequences of embarassment, loss of confidence
and legal action against the company. From the facts that are known to the
public, apparently no incorrect data modification has been made and the com-
pany didn’t have any problems with respect to data unavailability because at
any point in time, all data required for business operations has been available.
From the issues outlined above, it is possible to derive the following require-
ments for security solutions in the context of a database system [2]:

– Secrecy or confidentiality. The solution must offer facilities to protect

data against unauthorized disclosure. This aspect is mainly addressed by
access control mechanisms and supported by the use of encryption techniques
that are applied to data stored in primary or on secondary storage and data
being transmitted over communication networks.
– Integrity. The solution must contribute to the prevention of unauthorized
and improper data manipulation. Data manipulation encompasses insertion,
modification and deletion of data. Access control mechanisms contribute to
integrity but they are not sufficient to ensure it because they cannot prevent
users from entering semantically incorrect data. Therefore access control
needs to be supported by a semantic integrity subsystem. Whenever a user
inserts or modifies data, this system checks whether the new data conforms
to the integrity constraints and denies any non-conform data.
– Availability. The solution must include mechanisms to prevent and re-
cover from hardware and software failure as well as mechanisms to mitigate
 Database Security: Concepts and Approaches 5

malicious data access denials which make the database system unavailable.
Backup and recovery scenarios aid in recovering from hard- or software fail-
ures and avoid the loss of data. In order to prevent denial-of-service attacks,
additional techniques must be used which are often based on machine learn-
ing.
The following two scenarios, as given by Bertino and Sandhu [2], illustrate
these requirements.
Consider a database that stores payroll information. It is important that
salaries of individual employees not be released to unauthorized users
(secrecy, confidentiality), that salaries be modified only by the users
that are properly authorized (integrity, confidentiality), and that pay-
checks be printed on time at the end of the pay period (availability).
Consider the Web site of an airline company. Here, it is important that
customer reservations only be available to the customers they refer to
(authorization, confidentiality), that reservations of a customer not
be arbitrarily modified (integrity), and that information on flights and
reservations always be available (availability).
Another requirement, that is relevant today is privacy. The term privacy is
often used as a synonym for confidentiality, but actually, the two requirements
are different: Privacy means that it is not possible to deduce from a disclosed
set of data the original entity. Confidentiality can be achieved by – partially or
entirely – withholding data from access, but is not necessarily sufficient to assure
privacy. Issues related to privacy protection will be discussed in section 4.

1.2 The Significance of Trade-Offs

From the variety of security-related issues and requirements, it is obvious that
not every aspect can be considered equally important when implementing secu-
rity in database systems. There is always a trade-off involved which in general
means: ”Doing one thing implies not being able to do another” [10]. In terms of
security solutions for information systems, this means that achieving a certain
security quality will most likely lead to the decrease of another quality. Achieving
all desired qualities to an equal degree is difficult or even impossible.
The explicit consideration of trade-offs is a fundamental activity in engi-
neering in general and their presentation is also an important ingredient of the
well-known design patterns in Software Engineering. Design patterns capture
the essence of common problems and solutions found during software design.
Gamma et al. [5] emphasize the importance of trade-offs as follows:
The consequences are the results and trade-offs of applying the pattern.
Though consequences are often unvoiced when we describe design deci-
sions, they are critical for evaluating design alternatives and for un-
derstanding the costs and benefits of applying a pattern. The conse-
quences for software often concern space and time trade-offs. [...] the
6

consequences of a pattern include its impact on a system’s flexibility, ex-

tensibility or portability. Listing these consequences explicitly helps you
understand and evaluate them.

Buschmann et al. [3] discuss the importance of the consideration of benefits

and liabilities and mention that

A discussion of the benefits and potential liabilities of a pattern highlight

the consequences of its application. This provides us with information to
help us decide whether we can use the pattern to provide an adequate
solution to a specific problem.

Realizing that security problems and possible solutions can be seen as a form
of patterns, an attempt is made to conclude every section of this paper with the
identification and summary of the relevant trade-offs.

1.3 Summary: Trade-Offs

It is possible to determine from the context and requirements given in section

1.1 the following trade-offs:

– Ease-of-use vs. security. When security mechanisms are introduced in an

information system, its ease-of-use is decreased because, in general, security
systems make it more difficult to access the data stored in the system.
– Confidentiality vs. performance. Confidentiality requires the enforce-
ment of authorization policies as well as the protection of data in memory,
on external storage media or during transmission. The enforcement of poli-
cies through an authorization subsystem and the protection of data using
encryption can impose a performance penalty.
– Integrity vs. performance. The verification and enforcement of semantic
integrity constraints needs processing power which can reduce the overall
performance of the system.
– Availability vs. performance. Providing mechanisms for recovering from
failures usually includes numerous logging mechanisms which can decrease
the performance of a system because of the cost of the required input/output
operations.
– Confidentiality vs. availability. Confidentiality means that no data is dis-
closed to unauthorized parties. Introducing mechanisms for recovery means
that data is replicated to different locations, for example log files which,
if not properly protected, can be used to access data in an unauthorized
manner.
– System complexity vs. implementation effort. Introducing security
mechanisms into an information system increases the system’s overall com-
plexity. Higher complexity negatively affects implementation effort in terms
of costs and implementation time.
 Database Security: Concepts and Approaches 7

Structure of the Paper

This paper focuses mainly on the confidentiality requirement and discusses sev-
eral access control mechanisms that can be used to address issues related to this
requirement. It is mostly based on the paper [2], written by Bertino and Sandhu.
Section 2 discusses foundations and concrete occurrences of access control mech-
anisms. Security issues and approaches for advanced data management systems,
such as object-based database management systems and XML are covered in
section 3, followed by an overview of challenges beyond access control. Section
5 presents a summary of the discussed topics.

2 Access Control Mechanisms

Access control mechanisms regulate who can access which data. The need for
such mechanisms can be concluded from the variety of actors that work with a
database system. These include [12]:
– Database administrators who are responsible for all aspects related to
the database system’s operation, independent from any concrete application
program. They also manage the conceptual and internal schemata.
– Application administrators who are responsible for defining and main-
taining the external schemata used by application programs.
– Application programmers who use the external schemata to create ap-
plication programs.
– Users who use application programs to access the data stored in the database.
They typically do not have any technical knowledge and it is required that
they can only access and modify data for which they are authorized.
Based on their characteristics, access control mechanisms can be divided into
three categories – Discretionary Access Control (DAC), Role-Based Access Con-
trol (RBAC) and Mandatory Access Control (MAC). This section discusses basic
principles of access control mechanisms and then presents each of those classes
in greater detail.

2.1 Properties and Basic Principles of Access Control Mechanisms

Early research in the area of access control models and data confidentiality fo-
cused on the development of discretionary and mandatory access control models.
A large amount of the research was done in the context of the relational model,
whose high-level and declarative nature for logically specifying data also had an
impact on the development of access control models [2].
Important principles were introduced that distinguish access control models
of database systems from the access control models offered by operating systems.
1. Access control mechanisms for database systems should be expressed in
terms of the logical data model. As a consequence, e.g. authorizations for
relational databases need to be expressed in terms of relations, attributes
and tuples.
8

2. In addition to name-based access control, content-based access control is to

be supported. In name-based access control, objects are specified by giving
their names, in content-based access control, the system determines permis-
sion or denial of access based on the contents of the respective objects.

The basic concepts in access control models are authorizations, subjects and
objects. An authorization is a statement whether a given subject can perform a
particular action on an object. The subject is a user and the object is the data
item this user is trying to access. Thus the subject is the active and the object
the passive entity in an authorization. Authorizations can be managed centrally
by an administrator or by the creator (owner) of a data object. The first is
referred to as centralized administration, the latter as ownership administration.
Differences and impacts of these adminstration models are especially relevant
to discretionary access control models and will be discussed in the appropriate
sections.
Another important aspect of access control models is that not only the data
but also the schema may contain sensitive information, and accesses to the latter
need to be restricted according to some security policies. Finally, it is important
to realize that also the the access control policies themselves can reveal sensitive
information and therefore must be protected too.
The fact that not only the data can contain sensitive information, but also
the schema and the access control policies, can be seen as some form of covert
channel. A covert channel is any component or feature that can be used to rep-
resent information for unauthorized transmission without violating any existing
access control policy. In general, it is possible to categorize covert channels as
follows [4]:
– In timing channels, information is conveyed through the timing of events
and processes.
– In storage channels, information is conveyed by the access to system in-
formation.

Resolving this problem is not easy because many components or features of

a system can be misused to reveal the presence or contents of sensitive data –
the system clock, the operating system’s interprocess communication primitives,
error messages, the existence or non-existence of particular files and even the
concurrency control mechanism [2].

2.2 Discretionary Access Control Mechanisms

Discretionary access control mechanisms – abbreviated as DAC, and used in
many relational Database Management Systems – govern access to data based
on the identity of the subject and authorization rules. The mechanisms are dis-
cretionary in the sense that they allow subjects to grant access to data to other
subjects.
The authorization model of System R [1] was one of the first access con-
trol models for relational databases [6]. This framework has been adopted and
 Database Security: Concepts and Approaches 9

extended and its concepts can still be found in nowaday’s database systems. Ob-
jects to be protected, are tables and views, referred to as virtual tables. Subjects
can exercise access modes on objects. These access modes correspond to the SQL
operations that can be executed on tables and – if applicable – on views:

– select: retrieve tuples from a table

– insert: add tuples to a table
– delete: remove tuples from a table
– update: update tuples in a table

Operation
1
*
Subject * * Permission
*
1
Object

Fig. 1. Illustration of Discretionary Access Control. A subject has an arbitrary number

of permissions (authorizations) which relate operations (access modes) to objects. A
permission relates one operation to one object but an operation or an object can be
used in multiple permissions.

The process of granting or revoking authorizations is called authorization

administration. As mentioned in section 2.1, authorization administration can
be performed in a centralized (centralized administration) and a decentralized
(ownership administration) manner. In the first case, only some privileged sub-
jects – such as the database administrators – may grant or revoke authorizations.
In the latter case, an object’s owner grants or revokes authorizations. Ownership
administration is often complemented by administration delegation in which a
subject that has been granted a certain privilege can delegate the latter to other
subjects. In the system R model this option is referred to as the grant option.
The introduction of administration delegation into an access control mech-
anism leads to interesting questions concerning the semantics of the revoke op-
eration: what happens when a user that has delegated authorizations looses his
or her authorizations? What happens to the authorizations this subject granted
to other subjects? One possibility is to consider only valid the authorizations
that would have been present if the revoker had never granted the revokee the
privilege. Thus, every time an authorization is revoked, granted authorizations
are revoked recursively. This approach can be very disruptive and an extension
10

of the System R model deals with this issue. The proposed semantics start with
the assumption that the authorizations a user possesses, are related to his func-
tion within an organization. Thus, if a user changes his function, it would be
sensible that only the authorizations of this particular user be removed. In this
non-cascading revoke, the authorizations granted by the revokee are respecified
as if they had been granted by the revoker.
Access control mechanisms must be able to deal with cases in which no
authorizations for a subject on a given object are found. Most database man-
agement systems adopt a closed-world policy which means that access is denied
if no authorization is found. Thus the lack of authorization is interpreted as
no authorization. This however does not prevent a user from receiving such an
authorization at some point in future because any subject in charge for au-
thorization can grant any other subject the authorization to access a particular
object. The introduction of negative authorizations can overcome this drawback.
Negative authorizations state an explicit denial for a subject to access a partic-
ular table under a certain access mode. Negative authorizations can be used to
block positive authorizations of a subject and to specify exceptions to positive
ones.
This can lead to conflicts between positive and negative authorizations which
in turn can be addressed in several ways:
– Denials-take-precedence: Whenever a subject has a positive and a nega-
tive authorization for a given access mode on a given object, access is denied.
Thus negative authorizations always override positive authorizations.
– More specific authorization: This concept introduces a partial order re-
lation between authorizations which is taken into account when dealing with
authentication conflicts. For example, an authorization given directly to a
user is more specific than an authorization given to a group this user is a
member of. This implies that a negative authorization can be overridden by
a positive one if the latter is more specific. The negative authorization is
selected if the two authorizations in question cannot be compared under the
order relation.
In the context of the Sea View [7] system, explicit denial exists in the fol-
lowing shape: Authorizations specify which users or groups can access particular
tables and which users and groups are denied for particular tables. Negative
authorizations cannot specify an access mode and a special access mode, called
null, is introduced to indicate a negative authorization. Conflicts are handled
according to a more specific authorization policy and a denials-take-precedence
policy. This means that authorizations granted to a user take precedence over
authorizations granted to this user’s groups and null mode authorizations over-
ride any positive authorizations granted to the subject. A different approach to
these difficulties is the introduction of roles and the assignment of privileges to
roles instead of directly to users. These mechanisms are known as role-based
access control (RBAC) and will be discussed in section 2.3.
Another extension of the System R model deals with the duration of au-
thorizations. Typically, an authorization is valid from the moment it is entered
 Database Security: Concepts and Approaches 11

into the system by a grant operation until it is removed by a revoke operation.

However, for some applications, it may be desirable that permissions hold only
for specific, eventually periodic, time intervals. That is, permissions need to be
adapted to the activity patterns of users which should only be able to access data
objects during the time period they are expected to need access. Such tempo-
ral access control policies are not realized in most current DBMS and therefore
need to be implemented in application programs, which in turn makes it hard
to verify and modify them.
As stated in section 2.1, content-based access control is a central require-
ment in data mangement systems. The essence of such authorization schemes is
that access control decisions are based on the data being accessed. Bertino and
Sandhu [2] use the following scenario to emphasise the significance of content-
based authorization:

Consider an example of a table recording information about employees of

a company; a content-based access control policy would be the one ”stat-
ing that a manager can only access the employees that work in the project
that he manages.” Whenever a manager issues a query, the system has
to filter the query result by returning only the tuples related to the em-
ployees that verify the condition of working in the project managed by
this manager.

Content-based authorization can be implemented in today’s relational da-

tabase systems using views. In the case of authorization, protection views are
used, as opposed to shorthand views defined to simplify querying the database.
Views can be seen as windows on a specific subset – rows or columns – of data
and are defined by a view definition query. As a consequence, when running
queries against a view, their predicates are combined with the predicates of the
respective view definition query through an AND connective. This is called view
composition and results in a filtering of the original table’s tuples against the
protection view and the new query.
The advantage of the content-based approach using views is, that access con-
trol policies don’t need to be updated as data changes. The major disadvantage
of the approach is the large amount of view definitions required as a conse-
quence of different users or user groups requiring different authorizations. Also,
data independence is negatively affected because, depending on the user, appli-
cation programs need to issue queries against different views. This finally results
in high maintenance efforts because application programs need to be modified
when views are created or removed. This issue can be mitigated using automatic
reformulation of queries formulated against the original tables as queries issued
against the appropriate view.

DAC for Object-Based Database Systems: Object-oriented systems have

a fundamental property: they advocate encapsulation, which basically means a
separation between an object’s status and it’s interface. This is also known as
information hiding and its significant advantage is data protection. Arbitrarily
12

complex authorization policies can be supported and the support of content-

based authorization is considered relatively easy. Authorization administration
and application program maintenance efforts can be minimized because the ob-
jects are stored centrally within the database and the associated authorization
policies are not spread throughout the application programs.

2.3 Role-Based Access Control Mechanisms

Role-based access control, widely known as RBAC, is a result of the need to
simplify administration authorization and is able to model access control policies
of organizations directly.
The central concept of RBAC is the role which represents a specific function
of a subject within an organization. It aggreggates the set of actions and respon-
sibilites associated with this function. All authorizations for a given activity are
granted to the role that is associated with the activity. Authorizations are not
granted directly to users. Rather, each user is authorized to play certain roles
and based on these roles he can exercise access rights. The RBAC approach
simplifies authorization: whenever a user needs to perform a particular task or
function, he only needs to be granted the permission to play the role associated
with the task or function. If the task or function changes, only the right to play
a given role needs to be revoked.

Operation
1
* *
Role * * Permission
*
* *
* 1
Subject Object

Fig. 2. Illustration of Role-Based Access Control. A subject is assigned a role (or

multiple roles). Each role contains permissions that relate a particular operation to
a particular object. Roles can contain other roles which establishes role hierarchies.
The cardinality constraints indicate that a user can have multiple roles which in turn
can have several super- or sub-roles. Every role can contain several permissions which
relates one operation to one object. One object or operation can be used in several
permissions.

Most RBAC models also include the concept of role hierarcies, allowing to
express role-subrole relationships. This allows for authorization inheritance and
separation of duty (SoD) constraints which prevents a subject from receiving too
 Database Security: Concepts and Approaches 13

many authorizations. This is especially relevant in case of a user with many au-
thorizations being compromised. In that case, a substantial part of the database
would also be compromised. Limiting the amount of authorizations mitigates
the impacts of an attack directed at a particular subject.
SoD can be classified into static and dynamic SoD:

– Static SoD constraints impose limits on role intersections and the number
of users that can be assigned to a particular role. For example, two roles
cannot have a common user or a given role can only be assigned to a certain
number of users.
– Dynamic SoD constraints are based on the notion of sessions. A session is
a set of accesses performed by a user under one or more roles. Dynamic SoD
restricts access to roles based on the history of the user’s role usage during
the current or previous sessions. This can be considered as exploitation of
contextual information.

2.4 Mandatory Access Control Mechanisms

Mandatory Access Control – abbreviated as MAC – determines access to data

based on classifications of subjects and objects. The classification defines a par-
tially ordered set of access classes (or labels, security classes [4]). These labels,
are assigned to each subject and object in the system. The classification of a
data object is related to its sensitivity.
The most widely used model for MAC is the Bell-LaPadula model. To illus-
trate this model, consider a security classification with the four security levels
Top Secret (TS), Secret (S), Confidential (C) and Unclassified (U). These classes
are given the order TS > S > C > U. In the Bell-LaPadula model, two restric-
tions are enforced [4], which are also illustrated in figure 3:

– No read-up. A subject can only read objects if class(Subject) >= class(Ob-

ject). Thus a subject with the classification Secret (S) can only access objects
classified as Secret (S), Confidential (C) and Unclassified (U). This is also
known as the simple security property.
– No write-down. A subject can only write objects if class(Subject) <=
class(Object). Thus a subject with access classification Secret (S) can only
write objects with the access classification Secret (S) and Top Secret (TS).
This is also known as the star property.

Using MAC in the relational model imposes some difficult issues that need
modifications to the relational model [2], the so-called multilevel relational model.
A relation in the multilevel relational model is characterized by the fact that
different tuples can have different access classes, resulting in a partitioning into
different security partitions. For the different partitions, the same rules as for-
mulated above hold: A subject whose access class is c can read all tuples of
partitions that have access classes equal to or lower than c and it can write tu-
ples in classes that are equal to or higher than c. These restrictions are similar to
14

Objects Subject

Top Secret (TS)

Write

Secret (S) Secret (S)

Confidential (C) Read

Unclassified (U)

Fig. 3. Illustration of Mandatory Access Control. The subject having a security clas-
sification of Secret can read any object with a security classification less than or equal
to Secret and only write objects with a security classification greater than or equal to
Secret.

protection views. Sometimes, write operations to higher classes are restricted to

assure integrity. The multilevel relational model can be further complicated if at-
tributes of a relation belong to different access classes. As a consequence, a tuple
could belong to different partitions of a multilevel relation (poly-instantiation).

MAC for Object-Based Database Systems: The application of MAC in

object-based systems is difficult because of the semantic richness of the data
models. Bertino and Sandhu [2] report that the differences in theory and imple-
mentation between object-oriented and object-relational database systems make
it difficult to formulate general principles for MAC in these systems. However,
they mention one particular characteristic of object-based systems that is ben-
eficious to MAC-based mechanisms: information exchange or information flow
between objects happens in terms of message exchange. MAC models could be
developed based on filtering these messages.

2.5 Comparison of DAC, RBAC and MAC

Discretionary Access Control mechanisms offer a high degree of flexibility that

makes them suitable in many application domains. However, they are vulnerable
to malicious attacks because they do not impose any control on how information
is propagated after it is accessed by authorized users [4] due to the possibility do
delegate authorization administration. Mandatory Access Control mechanisms
on the other hand prevent this illegal flow of information, but tend to be inflexible
because they require a rigid classification of subjects and objects in security
classes and enforce the constraints described in section 2.4. This restricts their
applicability.
 Database Security: Concepts and Approaches 15

Role-based Access Control mechanisms are a flexible alternative to MAC

and DAC. The main difference between DAC and RBAC is, that authorization
policies usually are not assigned to individual users but to groups of users, also
known as roles. Each user is entitled to play one or more roles and exercise the
associated authorizations. Elmasri and Navathe [4] report the following desirable
properties of RBAC mechanisms: flexibility, policy neutrality, good support for
security management and administration. RBAC can represent DAC and MAC
policies as well as user-defined or organization-specific policies, which makes it
a superset of DAC and MAC models.

2.6 Trade-Offs
The study of access control mechanisms reveals the following trade-offs:

– Granularity of authorization vs. ease of administration. Fine-grained

authorizations, for example at the level of individual subjects and objects,
in general lead to a large amount of policies that need to be managed. On
the other hand, the ease of administration can be increased by reducing the
granularity of the authorizations.
– Granularity of authorization vs. flexibility. Fine-grained authoriza-
tions lead to an increase in the number of active policies. All of the policies
need to be updated to reflect changes in authorization. If this is not possible,
the flexibility of a system, that is, its ability to adapt to new authorization
requirements within a reasonable amount of time, is decreased.
– Centralized administration vs. decentralized authorization admin-
istration. The decision whether the system supports centralized or decen-
tralized authorization administration affects several aspects of the system.
Centralized administration reduces the possibility that subjects grant au-
thorizations to subjects which should not receive the respective permission.
This comes at the cost of an increased administration effort. On the other
hand, decentralized authorization administration reduces the administration
effort at the risk of a subject not intended to receive a particular authoriza-
tion receiving the latter from another user. Decentralized administration also
introduces more complexity because the semantics of authorization revoka-
tion must be defined and implemented as well as the resolution of conflicting
authorizations.
– Open-world vs. closed world policy. A database system must be able to
deal with situations in which no matching authorization policy for a given
subject can be found. In a closed-world environment, the system will deny
access if no authorization for the given subject and object is found. Even
though such an approach is beneficial for confidentiality it may for example
negatively impact ease-of-use. In an open-world environment, access would
not be denied, increasing the system’s ease-of-use but being disadvantageous
for data confidentiality.
– Complexity of the data model vs. ease of implementation. A com-
plex data model allows the storage of semantically richer data. An important
16

principle for access control mechanisms requires that authorizations be ex-

pressed in terms of the underlying data model. If the semantic capabilities
of the data model become richer, it will also be possible to implement richer
and more complex access control policies but at the cost of an increased
implementation effort.
– Complexity of the data model vs. performance. As data models be-
come increasingly complex, their implementation is probably also subject to
a higher complexity which can cause a performance penalty.

3 Security in Advanced Data Management Systems

This section discusses specific security requirements for advanced data manage-
ment systems, that is, data management systems that go beyond the scope of
the relational data model. These systems have been driven by the requirements
of modern applications to manage complex data such as multimedia objects and
to provide advanced data analysis facilities, such as data mining for data ware-
housing and descision support systems. Another important factor is the advent
of internet and web-based applications and the requirement for inter-system op-
eration. According to [2], the requirements for such advanced systems can be
summarized as follows:

– Fine-grained and flexible authorization models for complex, mul-

timedia objects. This requirement is driven by complex object structures
that are at the heart of modern applications. The structure of the data,
contained for example in XML and object database systems, is more com-
plicated than a flat relational structure. Access to this data structures often
happens at various granularity levels and needs a concise formulation of
authorizations.
– Flexible user specification mechanisms based on user credentials
and profiles are especially relevant to web-based applications which are
characterized by very heterogeneous and dynamic user groups. Traditional
authorization mechanisms, based on user names and passwords, are no longer
sufficient because they require the definition and management of a large
number of authorization policies. Therefore it is necessary to ground the
definition, management and enforcement of authorizations on properties of
a subject other than user names and passwords. The set of properties that
are relevant for security purposes is called a credential [4] and can also be
considered a partial identity [2]. For example, credentials enable the for-
mulation of fine-grained policies such as: Only permanent staff with more
than five years of experience can access documents related to the internals of
the system (example taken from [4]). In this case, the elements of the user
credential are experience and the type of staff.
– Access control mechanisms tailored to information dissemination
strategies and third-party publishing architectures. A dissemination
strategy regulates how a data source delivers data to subjects. Conventional
 Database Security: Concepts and Approaches 17

database systems use a pull strategy where data is delivered upon explicit re-
quest. In a network environment, alternative strategies can be used which are
more suitable for delivering data to a large number of subjects. An example
for such a strategy is the push strategy, which is also known as publish-
subscribe. The data source delivers data to subjects periodically or when
particular events happen. There’s no need for an explicit request. Another
aspect is outsourcing of data publication to third parties. In this case, the
data’s owner outsources its publication to a third party which processes the
user queries (e.g. UDDI). Notable challenges include ensuring the confiden-
tiality and integrity of the data.
– Support for distributed cooperative data modifications and com-
plex workflow-based activities is driven by the new types of applica-
tions the web has enabled. Examples include business-to-business (B2B) and
business-to-customer (B2C) e-commerce, virtual organizations, e-contracting
and e-procurement whose main characteristic is a collaborative process across
organization boundaries. Such applications, in addition to secure data ex-
change, need data flow policies stating which party has to receive and modify
data in which order.

Extensions to the relational versions of the access control models have been
discussed in section 2. The next section discusses access control mechanisms for
XML which is the common representation language for document exchange over
the web [4].

3.1 Access Control Systems for XML

The extensible markup language (XML) is the standard language for todays in-
formation exchange across the internet. It is used for the exchange of documents
as well as accessing remote services over XML-RPC, SOAP, WSDL or UDDI
[11]. XML’s main characteristic is the notion of semantic tags. These tags allow
marking portions of a document and assigning meaningful names to the result-
ing data elements and can be nested to build hierarchical structures. A data
model for an XML document can be specified using a Document Type Definition
(DTD) or an XML Schema. Other standards include Schematron for rule-based
validation or Relax NG for pattern-based validation of XML documents [11].
Bertino and Sandhu [2] report that the relevant factors concerning the re-
quirements for access control models and mechanisms are found in XML’s hierar-
chical content model and its main application context – web-based environments.
A protection system must support fine-grained levels of protection granularity,
based on the structure and the contents of the data. For example, it should be
possible to protect one document, a set of documents, an element of a document
or even a particular attribute. In addition, it should be possible to exploit the
description provided by a DTD or XML Schema to specify the objects to be
protected.
Proposed access control models, according to Bertino and Sandhu [2], pro-
vide positive/negative authorizations and explicit/implicit authorizations that
18

can be associated with a DTD, an XML Schema, a document or its parts. If

authorizations are associated with a particular DTD or Schema, one has to con-
sider those cases where data does not necessarily obey the DTD or Schema. In
case the authorization system uses a closed-world access control policy, users will
unnecessarily be denied access to those elements.

3.2 Trade-Offs

The requirements for advanced data systems reveal the following trade-offs:

– Data richness vs. implementation effort. In advanced data management

systems, data tends to be semantically rich. With the increased richness of
data comes an increased complexity of the data models which in turn intro-
duces the need for more complex authorization mechanisms. More complex
mechanisms have a negative impact on the required implementation effort.
– Explicit user authorization vs. ”implicit” user authorization. An
explicit user identification with login name and password is a straightfor-
ward approach that can easily be implemented. However, it does not scale
in environments with many users, where it leads to significant efforts for
the management of the authorizations. This problem can be approached us-
ing additional characteristics of the subject (credentials) for authorization
purposes. While this reduces administration effort because there is a rela-
tively small set of policies to be managed, it increases the risk of accidentally
authorizing a user that should not be authorized.
– Isolated vs. collaborative data processing. Isolated processing of data
within a single organization implies less possibilities for data disclosure. On
the other hand, a large amount of business processes involve multiple or-
ganizations and as a consequence, data stored and processed at one site
exclusively, is of little value. As data must be transferred, additional points
of disclosure or unauthorized modification are introduced.

4 Challenges Beyond Access Control

This section briefly presents some challenges related to database security that
arise in the context of networked environments, ubiquitous and mobile comput-
ing as well as increasing data sizes [2].
One major point of concern regarding database security is the disintermedia-
tion of data access where subjects access their data directly without intervention
of an intermediate person. For example, orders can be placed directly by subjects
over the web or users can query databases themselves to retrieve the status of
their orders or reservations. This opens up a new kind of problem: as opposed
to e.g. a company’s employees, users are unknown to the data providing party
and do not necessarily obey a data access policy. Therefore, it can be difficult
to distinguish legitimate from illegitimate data access.
 Database Security: Concepts and Approaches 19

Ubiquitous and mobile computing contribute to the difficulty of database

protection. Put simple, data must be available to anyone, anywhere and at ev-
ery time. Not only do access models need to reflect these issues and need to be
enhanced with identity management capabilities, but also appropriate mecha-
nisms need to be established to protect data in transit over wired and wireless
networks. To accomplish protection of data in transit, encryption can be used.
As Elmasri and Navate [4] state, ”encryption is a means of maintaining secure
data in an insecure environment”.
Another important point, not related to access control and data protection is
the subject of data quality and completeness. Everyday’s applications are depen-
dent on some form of data contained in some database. Therefore, it is important
to define techniques and organizational structures to assess and attest the quality
of data, such as integrity and consistency checking.
Because a data set often is the result of an individual’s or company’s work,
protection of intellectual property rights become increasingly important. Wa-
termarking and fingerprinting are mechanisms to prevent unauthorized use of
data.
As mentioned in section 1, privacy – the impossibility to deduce from a dis-
closed set of data the original entry – is a crucial point. Data should be used
only for sanctioned purposes and not misused for different purposes. Accord-
ing to Neumann [8], ”part of the privacy issue comes from the potential for
misuse” and ”abuses of privacy are insidious, because they can happen to any-
one and their effects can significantly alter the course of a person’s life”. He
also reports that ”The risks of privacy problems tend to increase in scope and
magnitude as databases are increasingly linked together and as communications
become a fundamental part of our lives.” We can easily verify this fact from our
own experience: an increasing number of organizations collects data and uses it
for various purposes such as scientific research or marketing. For this kind of
databases whose main purpose is to produce statistics on various populations,
Elmasri and Navathe [4] introduce the notion of statistical databases. These data
sets may not only be used within the organization that collects and owns them
but access may also be granted to third parties.
Privacy-preserving data management techniques are required to minimize the
risk of privacy violations. Neumann [8] identifies the following causes of privacy
abuse:
– Inadequate system security, such as for example the absence of differ-
entiated user privileges. This can be addressed by applying suitable access
control mechanisms as outlined in section 2.
– Misuse or inadvertent use by individuals, that is the use of data for
unintended purposes by authorized or unauthorized people. Unauthorized
access can be prevented using access control and encryption technologies.
Different techniques need to be applied to mitigate the impacts of legally
disclosed data.
One class of techniques focuses on preserving privacy when releasing data
to third-parties. In that case, the data is no longer under control of the owning
20

organization, which also is no longer able to control data usage. The most com-
mon approach is data anonymization, however it may not be enough to simply
remove identity information. The second group of techniques deals with privacy-
preservation in the context of data mining because data mining techniques may
enable the recovery of removed information. The general approach is to modify
data to reduce the possibility that sensitive associations can be recovered. The
main challenge with these approaches is, that too extensive modification may
render data useless.
In case, one would not want to release data, distributed data mining tech-
niques can be used which operate on distributed and encrypted data. These al-
gorithms operate on some shared data to compute correct results but the shared
data does not include any private data [2].

4.1 Trade-Offs
Challenges for database security result from the following trade-offs:
– Data quality vs. data amount. Data quality is the suitability of available
data for a given purpose and must be achieved through dedicated activi-
ties during data collection or preparation and through the use of semantic
integrity constraints in database systems. As the amount of data to be pro-
cessed grows, it becomes increasingly difficult to assure a given degree of
quality because more time and resources are required to perform quality-
preserving or quality-improving processing.
– Distributed vs. centralized data processing. While centralized storage
reduces the amount of possible data disclosure places, linking different data
sources or sharing data can improve their usefulness. Additionally, in nowa-
days business context, lots of business processes have a collaborative nature
and span several organizations. Therefore data is distributed or shared and as
a consequence there is a greater probability that data is subject to disclosure
or unauthorized modification. Appropriate countermeasures must be intro-
duced to minimize these risks. But at the same time, additional mechanisms
increase complexity of a system and potentially influence implementation
effort, performance and ease-of-use in a negative manner.
– Direct vs. indirect access. When subjects can access data directly and
without intermediary, they perceive a greater ease-of-use. At the same time,
any direct access to data introduces the risk of unauthorized data access and
modification. Indirect access to data through a trusted intermediary reduces
these risks at the cost of increasing the time to retrieve desired data and
decreasing the system’s overall ease-of-use.
– General availability vs. intellectual property. When data is made pub-
licly available, it is difficult to enforce intellectual property rights.

5 Summary
When thinking about database security, the issue that immediately comes to
mind is confidentiality of data. This requirement is addressed by access control
 Database Security: Concepts and Approaches 21

mechanisms wich regulate access to data, either based on explicit assignment of

authorizations to users or user roles or depending on the actual data items. The
three main classes of access control mechanisms are Discretionary Access Con-
trol, Role-Based Access Control and Mandadory Access Control. The optimal
choice of an access control mechanism depends on the application context. For
example in highly sensitive environments, such as military or government, it may
be desirable to use rigid Mandatory Access Control. In environments with a lim-
ited number of users and less severe security constraints, the use of discretionary
mechanisms can be considered. Role-based policies are best applied when the
authorizations of a particular user are linked to his role or function within an
organization. These organizational structures can be mapped to corresponding
roles in a database system.
One important principle for the design of access control mechanisms states
that authorizations be expressed in terms of the logical data model. Today,
the relational model is well-established and widely deployed for production use.
Consequently, access control mechanisms for relational database systems are
well-understood. New requirements for applications have led to more complex
data structures that need to be stored within database systems. This in turn has
driven the development of more advanced, object-based data models. Following
the given principle, existing access control models had to be extended to exploit
the specific characteristics of those new data models. It has been shown that the
adaption of the well-known DAC, RBAC and MAC models is possible, but in
most cases does introduce new problems to be addressed.
With XML being the de-facto standard for data exchange over the web,
access control models specifically developed to exploit the characteristics of XML
are being investigated. These models are characterized by the fact that they
are supposed to take into account the hierarchical structure of XML and offer
different levels of granularity for different access levels.
Finally, it is important to realize that database security is not only about
the confidentiality of data but that also data protection and recovery from mal-
functions are important aspects. Other relevant aspects and challenges include
privacy issues as well as the disintermediation of database access and intellectual
properties rights in networked environments.
22

References
1. M.M. Astrahan, M.W. Blasgen, D.D. Chamberlin, J.N. Gray, W.F. King, B.G.
Lindsay, R.A. Lorie, J.W. Mehl, T.G. Price, G.R. Putzolu, M. Schkolnick, P.P.
Selinger, D.R. Slutz, H.R. Strong, P. Tiberio, I.L. Traiger, B.W. Wade, and
R.A. Yost. System R: A Relational Data Base Management System. Computer,
12(5):42–48, May 1979.
2. E. Bertino and R. Sandhu. Database security - concepts, approaches, and chal-
lenges. Dependable and Secure Computing, IEEE Transactions on, 2(1):2–19, Jan.-
March 2005.
3. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-
Oriented Software Architecture: A System of Patterns. John Wiley Sons, Ltd.,
1996.
4. R. Elmasri and S.B. Navathe. Fundamentals of Database Systems. Addison Wesley,
4th edition, 2004.
5. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison Wesley, 1994.
6. Patricia P. Griffiths and Bradford W. Wade. An authorization mechanism for a
relational database system. ACM Trans. Database Syst., 1(3):242–255, 1976.
7. T.F. Lunt, D.E. Denning, R.R. Schell, M. Heckman, and W.R. Shockley. The
seaview security model. Software Engineering, IEEE Transactions on, 16(6):593–
607, Jun 1990.
8. P. G. Neumann. Computer Related Risks. ACM Press, New York, USA, 1995.
9. R. Oppliger. IT security: in search of the Holy Grail. Commun. ACM, 50(2):96–98,
2007.
10. R. Pfeifer and C. Scheier. Understanding Intelligence. MIT Press, Cambridge,
Massachusetts, 2001.
11. E. T. Ray. Einführung in XML. O’Reilly, Köln, 2nd edition, 2004.
12. C. Türker and G. Saake. Objektrelationale Datenbanken. dpunkt.verlag, Heidel-
berg, 1st edition, 2006.