Security in Data Warehouses - Data Warehousing Design and Advanced Engineering Applications - page 275

Coexistence with MAC / DAC if dealing with permissions on a per-user basis.

In fact, a conflict of interest among permissions
on an individual basis is hard if not impossible to
determine. Separation of duties among roles (i.e.,
defining mutually exclusive roles) provides the
administrator with enhanced capabilities to specify
and enforce enterprise policies. Since RBAC has
static (user-role membership) and dynamic (role
activation) aspects, the following two possibilities
can be distinguished accordingly.
First, Static Separation of Duties (SSD) is based
on user-role membership. It enforces constraints on
the assignment of users to roles. This means that if a
user is authorized as a member of one role, the user
is prohibited from being a member of a second role.
Constraints are inherited within a role hierarchy.
Second, Dynamic Separation of Duties (DSD)
is based on role activation. It is employed when
a user is authorized for more roles that must not
be activated simultaneously. DSD is necessary
to prohibit a user from circumventing a policy
requirement by activating another role.

Mandatory access control is based on distinct
levels of security to which subjects and objects
are assigned. Discretionary access control (DAC)
controls access to an object on the basis of an
individual user's permissions and/or prohibitions.
RBAC, however, is an independent component of
these access controls and can coexist with MAC
and DAC. RBAC can be used to enforce MAC
and DAC policies as shown in (2000). The au-
thors point out the possibilities and configurations
necessary to use RBAC in the sense of MAC or
DAC. For a detailed discussion on defining and
organizing roles please refer to Nyanchama and
Osborn (1994), who introduce a formal role graph
to facilitate role administration. Ferraiolo and
Kuhn (1992), for example, published fundamental
concepts on granting and revoking membership
to the set of specified named roles.

SCIENTIFIC CONCEPTS

Administrating RBAC

Classic access control is still the mechanism of
choice to protect not only databases but also data
warehouses. The difference between a database
and a data warehouse is that database is designed
and optimized to process individual tuples and
the data warehouse is optimized to respond to
queries that analyze aggregated data. OLTP (On-
Line Transaction Processing) systems are secured
by controlling access to individual tuples but for
data warehouses the issue of data protection is
more complex. For typical access control there
are several shortcomings. First and foremost,
users can do anything with the data once they
have access to it; Second, even if access to fine
grained detail data is not permitted, querying dif-
ferent similar datasets can reveal fine details; this
is also known as inference attacks. The first issue
can be addressed—in theory—by usage control as
described by Park and Sandhu (2004), the second
by several methods of statistical database security.

Definition of roles and constraints, assigning
permissions to roles, and granting membership to
roles are the most common administrative tasks in
RBAC. When a new employee enters the company,
the administrator simply adds this person to one
or more existing roles according to the users tasks
and needs. Similarly, users can be removed from
a role when they leave the company or added to
new roles when their functions change.
It is commonly agreed that one of RBAC's
biggest advantages is its easy administration.
Nonetheless, managing a large number of roles
can still be a difficult task. However, Sandhu and
Coyne (1996) present an intriguing concept that
shows how RBAC might be used to manage itself.
An administrative role hierarchy is introduced,
which is mapped to a subset of the role hierarchy
it manages.